企业官网建设流程全解析

我把隐私门禁搬了六次位置。

这句话是对我最近大半年折腾本地推理与云端协同最精炼的总结。我在一个小团队里负责内部智能工具的架构，主要解决一个很实际的问题：同事们想用大模型的能力处理文档、代码、笔记，但公司内部资料、个人隐私数据又绝对不能随便流到外部服务里。这个“绝对不能流出去”的边界就是我说的大门禁。从最初全云端一把梭，到后来推理全部拉回本地，再到反复拆装门禁的位置，前后迭代了六轮，中间推翻过的方案、踩过的坑，比过去几年加起来都多。这篇不聊悬浮理论，只讲我实际搬这六次门禁的全过程，适合正打算搭本地推理服务器、或者一直纠结“到底哪些数据能上云”的人参考。

1. 门禁最初装在云端：一切从省事开始

很多人搭内部AI能力的第一反应都是调云端大模型接口，我也不例外。最初的方案非常简单：所有请求统一打到云端API，返回结果落到工单系统。好处很明显，接入成本低、模型效果稳定、不用管硬件，团队里谁要用，直接发一个链接就行。

当时我把隐私门禁放在了云端这一侧。具体做法是在调用前加了一层“关键词过滤”，用正则和敏感词表把明显涉密的请求拦截掉。看似有个门禁，实际上漏洞很大，因为过滤规则只能挡明文匹配，一句话把客户名称和项目代号藏在问题里，正则根本看不出来。

真正让我第一次意识到门禁位置放错，是有次同事让我帮忙分析一份内部产品需求文档。他把全文贴进对话窗口，文档里上百个内部术语、模块名、预算金额全被发去了云端。那个瞬间我明白了，过滤规则永远追不上人来发挥的创造性，只要分析和推理发生在云端，数据就必然出界。门禁装在门口，屋里东西却已经被搬走了。

那次之后，我下了决心：推理必须回本地。这就是第一次搬家。

2. 第一次搬家：推理全部拉回本地

全本地部署听起来简单，实际落地要解决三件事：模型从哪来、跑在哪、同事们怎么用。

2.1 本地推理的选型和硬件底子

我整理的思路是这样：先选一套能在本地运行的推理框架，再挑合适的开源权重模型，最后通过兼容层接回原来的应用。没有用太重型的方案，原因很简单，团队内网服务器只有一张专业显卡加一块旧工作站主板，显存和内存都有限，大型模型根本跑不动。

模型选型就更讲究。我当时的选型逻辑按三步走：

• 日常问答类任务，用7B到13B的量化模型，满足速度优先的要求。
• 文档摘要和情报抽取任务，上13B到30B之间的模型，追求效果。
• 直接用楼层里那台双路工作站做推理，高峰期任务排队时CPU也能兜底跑小模型。

量化在这步帮了大忙，把13B模型压到原来的六成体积，单张显卡勉强能跑。不是为了省那点硬盘，而是为了把显存占用压到安全线内。这个细节在初期极大缓解了硬件瓶颈，后面成了本地推理的默认姿势。

2.2 本地推理撞上的第一堵实墙

本地推理跑起来之后，门禁确实回到了自己手里，所有分析推理都在内网完成，再没有数据出境的风险。但代价很快就显现出来：

第一是效果落差。同事之前用云端大模型处理复杂合同、长代码逻辑，突然换成小模型，生成质量和理解能力断崖式下降。有人直接跟我说“这和之前根本不是一回事”。

第二是并发和延迟。本地推理服务器的算力有限，多人同时用时请求排队，一个长文档摘要任务能把整台机器卡到十分钟起步。团队里抱怨声四起。

第三是维护成本。模型版本更新、量化参数调整、显存溢出排查，全成了我的日常。每天光看着监控面板上飘红的指标就够焦虑。

我做了个简单统计：全本地部署的头两周，内部工具日活下降了四成。功能还在，大家不用了，原因就是慢和笨。这时我才意识到，全本地和全云端是两个极端，门禁搬回本地虽然堵住了隐私漏洞，却把效能也关在了门外。

于是第二次搬家开始酝酿。

3. 第二次搬家：门禁在云端和本地之间反复横跳

那段时间我几乎每周都在调整架构。今天觉得敏感数据全本地，明天觉得非敏感任务上云更高效，前后折腾了半个多月。现在回头看，问题核心不在门禁放哪边，而在于我没有一套判断“什么数据可以出去”的明确标准，自然每个方案都是临时补丁。

3.1 先分清什么样的数据是真的不能出本地

为了让路由规则可执行，我把团队里的数据分成了三大类。

• 保密级（本地强制）：含客户实名、内部财务信息、源码片段、未上线产品方案。
• 敏感级（脱敏后可上云）：不含直接身份信息但有业务上下文的技术问题、通用文档摘要、行业资料分析。
• 普通级（默认上云）：公开技术问答、常识性咨询、格式转换、翻译润色。

这套分类看起来简单，却是我搬了两次门禁之后最大的收获：先分级，再谈门禁。没有分级，任何规则都是沙上建塔。

3.2 路由规则雏形：第一批判定逻辑

有了分类，我开始写第一版路由判断。思路是一个极简的判定器，接收请求后按优先级检查上下文：

1. 命中保密级关键词，或者命中手机号、身份证号、卡号等敏感格式，直接走本地。
2. 命中公开场景模版（“把这段话润色成三条文案”这类），直接上云。
3. 剩下的一切，先走本地，本地模型明确表达低置信时再降级上云。

这个规则跑了一周，明显改善了速度问题，日活开始回升。但接着出了个标志性事故：某条请求里含一个内部项目代号，项目代号不在保密词表里，被规则归为普通级直接上云。结果项目代号连同问题描述一起去了云端接口。问题是没造成实际损失，但给我敲了一记警钟：词表匹配这条路走不通，门禁需要更聪明的判定。

4. 第三次搬家：门禁拆成两道，本地和云各守一道

这是整个思考的转折点。我开始明白，门禁不应该是一个“点”，而是一套“策略”。本地和云端之间，必须有一层显式存在的闸机，它负责理解请求内容，而不是机械地去查敏感词表。

4.1 智能判定器：用本地模型给门禁装大脑

最终我实现了一个判定中间层：请求先到本地模型，由它先做一轮意图分类和实体识别，再交给路由规则决策。

实际流程是这样：

1. 请求进入中间层，先用一套轻量本地模型做实体识别，把组织名、人名、金额、项目代号等实体标出来。
2. 标出的实体与保密级词表比对，哪怕没有完全命中，只要相似度超过阈值，就强制走本地。
3. 判定为普通级的请求，再额外抽取核心实体，用脱敏规则替换后转发云端。
4. 云端返回结果后，再在本地替换回来后回给用户。

这相当于把门禁从“一道门”换成了“两道闸”。第一道负责侦察内容里有没有涉密实体，第二道负责判断能不能出界，两道之间还有一层脱敏处理兜底。这一版落地后，因为敏感词漏判导致的数据出境问题基本绝迹。

4.2 脱敏层：让“不能出去”的东西也能出去

脱敏层是这轮架构里含金量最高的部分。以前我只会用正则把手机号、身份证号替换成星号。这次我把脱敏做成两层：

• 模式脱敏：正则命中固定格式，比如邮箱、电话、车牌、卡号，直接替换成对应占位符。
• 实体脱敏：由本地模型识别出的专名，统一替换成通用占位符，比如“某公司”“某人”“某项目”。同时生成一份“脱敏映射表”保留在本地，等云端结果回来之后再还原。

脱敏映射表的设计比较关键。比如原文里有“某项目X”，上云时替换成“项目A”，云端返回后可能说“项目A的预算偏高”，再由本地映射回“某项目X的预算偏高”。这样既保护了真实信息，又保住了上下文的语义连贯。

这轮迭代之后，我才觉得门禁有了真正的判断力，不再是个防君子不防小人的门槛了。

5. 第四次搬家：门禁升级成带缓存和降级的智能闸机

解决了“能不能出去”之后，新问题浮出水面：出去的请求太多，云端账单和延迟又开始失控。这轮搬家的重点从“堵”转为“疏”。

5.1 本地小模型守门，云端大模型攻坚

我重新梳理了任务分配策略，不再让路由规则把普通类请求一律扔云端，而是先让本地模型试跑一遍。

具体策略是这样的：

• 翻译、润色、标点修正这类“轻量任务”，本地模型直接出结果，根本不上云。
• 文档摘要、对比分析这类“重量任务”，先由本地模型做一次初步归纳，再带着本地生成要点上云细化。
• 需要联网检索最新资料或处理超长上下文的任务，本地模型识别出能力边界后，才整体转发云端。

这套“小模型先守门、大模型再攻坚”的分工，直接让云端调用量下降了近一半。同事体感上的速度反而变快了，因为大部分日常任务在本地就已经秒回。

5.2 缓存层：让常见问题根本不问云

这轮还顺手加了一个缓存层。思路很简单：把本地模型判定的“常见问题+脱敏后的标准答案”存成键值对，下次遇到相同或高相似度请求，直接命中缓存返回。

缓存命中率比我预期高得多。内部工具里很多问题是重复的，比如“周报的格式是什么样的”“报销流程怎么走”“某项目的上线时间”，这些标准化问题一旦被缓存，几乎永远不再访问云端。

我还给缓存设置了自然过期时间，业务规则变化频繁的内容放短缓存，技术常识类放长缓存。这个细节让我后来省了不少精力，没有因为缓存了过期信息被同事追着改文档。

5.3 降级策略：云端故障不能拖垮业务流程

门禁搬了这么多次，其中一个最有价值的教训是：所有依赖云端的环节都必须有降级方案。我见过一次云API超时，导致整个工具半小时不可用，所有请求堆在队列里最后超时丢弃。

从此我定下硬性规则：

• 云端服务超时时间缩短到五秒，超过直接切回本地模型。
• 本地模型即使生成质量一般，也必须先给用户一个可用结果。
• 所有转发云端失败的请求，记录日志并自动进入本地重跑队列。

这条规则看似简单，真正救过我好多次。后来有次云端接口异常，内部工具靠着本地兜底硬撑了几个小时，同事甚至没察觉。

6. 第五、六次搬家：从规则到策略，门禁真正安顿下来

最后两次搬家没有推翻架构，更多是做减法。我逐步意识到了门禁的控制点到底应该在哪一层，以及什么样的架构既安全又不牺牲效率。

6.1 可观测性：没有日志的隐私门禁等于没有门禁

坦白讲，前面几次搬家最大的问题是“门禁有没有拦住东西”完全不可见。我看不到有多少请求被挡、有多少请求被脱敏、有多少误判，所有决策都是盲打。

第五次搬家第一件事就是加可观测面板，把所有门禁事件落成结构化日志。具体盯四类指标：

• 本地/云端路由占比，掌握流量分布。
• 保密级拦截次数，监控敏感请求量级。
• 脱敏命中率和映射还原成功率，衡量脱敏层是否可靠。
• 云端超时和本地降级次数，判断协同的健康度。

这个面板上线后，我才第一次真正“看见”隐私门禁的工作状态。很多奇怪的规则问题也因此暴露，比如有同事的请求因为被误判为保密级而长期走本地，导致速度极慢但用户又不敢说，日志直接给出了答案。

6.2 第六次搬家：把门禁收拢成配置，而不是代码

第六次搬家，动了最根本的东西：把路由规则、脱敏策略、模型选择从硬编码里抽出来，做成一套可配置的策略文件。

之前的每次调整几乎都要改代码、重新发布，一个规则的修改经常要等上半天。现在我把策略抽象成三层：

• 模型策略：什么任务类型用哪个模型，优先级如何。
• 脱敏策略：哪些实体类型必须脱敏，哪些可以放行。
• 路由策略：各类型请求在本地、缓存、云端之间的流转顺序。

日常调整只需改配JSON再热加载，不用重新编译。这轮改动让门禁从一个“一次性修好的装置”变成可以长期迭代的系统。

6.3 最终架构长什么样

六次搬家之后，当前这版架构稳定运行了好几个月。核心组成你可以直接抄作业：

1. 请求接入层：统一接收内部所有工具请求。
2. 本地判定层：本地小模型做实体识别、意图分类、敏感度打分。
3. 路由决策层：根据判定结果，决定请求走缓存、本地推理还是云端。
4. 脱敏还原层：出境前脱敏，入境后还原，全程映射表留在本地。
5. 本地推理层：负责安全数据处理和轻量任务。
6. 云端协同层：负责复杂任务和长上下文，永远只看到脱敏后的内容。
7. 可观测层：记录所有门禁事件，支撑复盘和调优。

这套架构下，保密级数据从未出过内网，普通任务体验接近全云端方案，成本却低很多。

7. 常见问题与排查技巧实录

7.1 脱敏过度导致上下文残缺

有一次我开着脱敏功能分析一份技术方案，云端的摘要结果语义完全对不上。查了半天发现是所有实体都被替换成占位符，原文里用专名承载的关键逻辑链全部断裂了。

解决办法是在脱敏规则里加“上下文保留区”。专名第一次出现替换成占位符，但占位符会携带一个类别索引，比如“公司A(索引001)”，后面再次出现时保持同一个映射。这样云端看到的还是统一指代，不会把一个公司拆成“某公司1”和“某公司2”两个孤立符号。

7.2 本地推理服务器内存溢出

本地模型最怕并发叠加长文本。好几次用户同时提交大文档，直接触发显存溢出，服务直接崩溃。

最终解决方案是把请求队列做限流：本地推理最多同时跑两个任务，超出自动排队。同时对长文本任务做切片，超出设定长度先分段摘要再合并。这两个调整之后，服务器再也没崩溃过。

7.3 云端超时导致任务堆积

早期降级策略没做好时，云端一超时，所有请求堆在队列里，本地模型也连接被占满，整个服务雪崩。

排查后发现有两个问题：超时时间设得太长，以及没有做任务丢弃策略。我改成云端五秒钟不响应就快速失败，同时给每个请求设置总超时时间，超过即返回本地兜底结果。架构瞬间稳了很多。

7.4 隐私数据出界事故：一次正则漏网

最惊险的一次事故反而来自最简单的环节。我当时以为模式脱敏覆盖了所有格式，结果有份内部文档里的项目代号是“P2023-XM-08”这种格式，正则没匹配，直接从脱敏层漏过去了，文档原样上了云。

从那次之后我把脱敏判断改成双重校验：正则命中一种格式还不够，还要本地模型再去识别一遍，两个结果有一个命中保密实体，就强制走本地。这种事发生过一次就够，我不希望再来第二次。

8. 搬了六次门禁之后的一点实际感触

把隐私门禁来回搬了六次，我最核心的体感就是：安全和效率不是二选一，而是有序协作的两种模式。云端大模型确实强，但它应当被隔离在脱敏和路由之后；本地小模型确实笨，但它最适合守住隐私这条底线。

这套架构后续还可以继续扩展，比如接入更多云服务时可直接复用路由层，模型升级时只需换模型策略配置。逻辑上没有推翻重建的必要。

如果让我给一句话的建议，那就是：门禁的位置不是固定的，但它必须是一个让数据流向“可解释、可回看、可快速调整”的机制。走到这一步，才算是真正把隐私门禁安顿下来了。