企业官网建设流程全解析

先说个现象：我们已经被“上传”驯化了。做文档分析，传文件；做会议纪要，传录音；想让AI写个季度总结，第一反应不是思考，而是先把几十个表格拖进对话框。AI越好用，这个动作就越自然——因为模型确实需要看到内容才能干活，云端的模型看不到硬盘里的文件，于是“上传”成了默认前提。

但它从来都不是唯一解。我最近把一个项目彻底翻了一遍，核心目标就一句话：让AI保持好用，但尽量少传文件、不传敏感文件、传也要传得明明白白。今天这篇不讲概念，直接拆这套方案怎么落地，包括我在实际改造中踩过的坑、绕过的弯、以及最终稳定运行的结构。

1. 为什么“上传”成了AI时代的默认动作

1.1 云端模型的工作机制决定了“你得把文件给它”

先别急着谈第三条路，得先把问题根源看清楚。现在主流的大模型，尤其是参数量比较大的对话式模型，基本都跑在云端数据中心里。你的浏览器页面和云端API之间传输的是文本、图片、文件内容，模型本身不会主动访问你电脑上的目录结构。

也就是说，当你在对话框里让它“分析这份合同的风险条款”，它真正拿到的是文件解码后的文本内容，而不是文件本身。这个设计本身没有错，反而是一种简化：你不用安装任何客户端，不用管模型文件放在哪，上传即服务。

但问题就出在这套机制的“简化”上——对话框中上传的文件，默认会进入模型服务的处理链路。虽然很多服务承诺“数据不用于训练”，但“数据经过服务端处理”这件事本身就是既定事实。对个人用户来说，这未必是问题；但放到企业场景、法律文档、招投标书、客户名单、技术图纸、薪酬表这些内容上，很多人是不愿意让它们出现在第三方服务器上的。

1.2 好用和安全的矛盾，本质是“全量可见”的问题

再往深一层看，我认为真正的矛盾不是“能不能上传”，而是“上传之后模型能看到多少”。

熟悉AI应用开发的朋友都知道RAG（检索增强生成）的流程：先把文档切片、做向量化，建立索引，然后用户提问时，通过语义相似度检索出相关片段，再把这些片段拼接给大模型生成回答。很多人会误解RAG是“AI读懂了整个文档”，其实不是，它每次都只看到检索出来的那几段。

但浏览器对话框里的上传不是这个逻辑。你直接丢进去的PDF，要么被模型按上下文窗口全量读取（长文档被截断或分块），要么被服务端的预处理管线解析并纳入索引。整个过程对用户是黑盒，你不知道它对文件做了什么、存了多久、谁能访问。

这就是我说的“全量可见”问题：对话框式上传，默认让AI服务端拿到了文件的完整内容控制权。哪怕它只生成了100字的总结，背后也是把全文解析了一遍。

所以“第三条路”的思路就清晰了——不是拒绝上传，也不是把AI换成纯本地版，而是改造数据流向：让AI吃到它该吃的那一部分，而不是全部；让AI拿到的是加工后的信息，而不是原始文件；让整个处理过程可记录、可审计、可撤回。

2. “第三条路”到底是什么

这条路不是一个新工具，也不是某个公司的黑科技，而是一套组合方案。我给它的命名是“文件代理层”，也可以叫“本地优先的数据接入层”。它解决的核心问题是：在不牺牲模型效果的前提下，把文件的内容控制权留在本地。

2.1 方案整体结构

把整个数据流拆开看，传统方案是：

本地文件 → 上传到对话框 → 云端模型解析 → 返回结果

第三条路是：

本地文件 → 本地解析与脱敏 → 按需切片 → 检索结果 + 脱敏文本 → 云端模型 → 返回结果

区别在哪里？传统方案里，原始文件完整经过云端；第三条路中，云端模型拿到的不是原始文件，而是一组经过筛选、脱敏、最小化的文本片段。这里的关键不是“完全不传”，而是“选择性传递”——传什么、传多少、传之前做了什么处理，全部由本地控制。

2.2 这套方案由四个核心模块组成

我认为四个模块缺一不可，但可以根据项目体量逐步引入：

• 本地解析器：负责把PDF、Word、Excel、PPT、音频转写稿等文件解析成本地文本。这一步完全在本地完成，不触发任何网络请求。
• 敏感信息扫描与脱敏引擎：用规则加模型双重识别文件里的身份证号、手机号、银行卡号、合同金额、客户名称等敏感字段。识别后不是简单打码，而是做“可逆替换”，例如把具体金额替换为“{金额A}”，把真实姓名替换为“{甲方}”，并在映射表里记录替换关系。
• 本地语义索引：把脱敏后的文本切片并做向量化，存入本地的向量数据库。切片粒度、索引策略都由本地配置控制。
• 按需投递接口：当用户提问时，先在本地检索出与问题相关的Top K片段，再决定“是否足够回答”和“是否允许外发”。这层接口就是你自己的AI网关，云端模型永远只能看到你允许它看到的那部分文本。

2.3 为什么不是干脆用本地模型

每次聊到这种方案，一定会有人问：那我把模型也跑到本地，不是更安全吗？

理论上是的，但实际操作有两个绕不开的现实。第一，大参数模型的本地推理需要较高硬件投入，至少需要大容量显存，除非用量化方案或者蒸馏小模型，否则效果会打折。第二，有些场景你根本不需要完全本地——比如你要AI帮你润色一段对外宣传文案，这段文案本来就是要公开的内容，传不传根本无所谓，反而用云端最强模型效果最好。

所以第三条路不是替代本地模型或云端模型，而是给你一个“分流阀门”。它根据文件内容敏感度，自动决定数据流向：

这个分级策略是我在项目里最核心的设计决策。它不搞一刀切“全部本地”或“全部上云”，而是用一套清晰规则，把不同文件导向不同路径。用户感知不到底层的路由逻辑，只知道自己问的问题都能得到回答，但原始敏感文件从头到尾没有出过内网。

3. 实操记录：从零搭建一套“文件代理层”

下面这部分是重点，我按实际动手顺序记录整个实施过程。这套方案我用的是最常见的开源组件组合，没有用任何商业私有方案，方便你在自己环境里复现或改造。

3.1 第一步：先把文件“拆”本地，这一步不能省

我拿到项目后，第一件事不是写代码，而是把文件解析流程从“上传后解析”改成“本地解析先行”。

这里有两个工具组合很关键。处理PDF和Word，我用的是解析库，它在本地跑，能把PDF里的文字段落、表格、图片位置都提取出来。这里有个细节很多人不知道：PDF里的扫描件是纯图片，不经过OCR是提取不出文字的。所以我还单独接入了一个本地OCR服务，跑在CPU上速度稍慢，但对于扫描合同这种场景，准确率已经够用。

处理Excel和处理PPT也一样，解析后统一转成Markdown格式。为什么要转成Markdown？因为后续做文本切片时，Markdown里的标题层级、表格结构能帮向量检索更好地理解文档结构。

实操建议：文本提取阶段务必保留段落顺序和标题层级信息，不要把所有文字压成一坨纯文本。这个顺序信息在后续检索时的作用非常明显，丢掉顺序等于丢掉了语义逻辑。

3.2 第二步：敏感信息脱敏，不是简单打码

这一块我花的时间最多，也是整个方案里最容易被低估的环节。

第一轮用正则规则做高置信度命中。手机号、邮箱、身份证、银行卡这类有固定格式的，正则命中率已经很高。我用的是国内常用号码规则组合，检测到就替换成{手机号}、{身份证}这种占位符。

但真正的难点在“非结构化敏感信息”。比如合同里写“甲方为某网络科技有限公司深圳市分公司”，这里的公司全称和地址，正则匹配不到，但语义上就是敏感字段。我是用一个小体量本地模型做命名实体识别来补这层能力——量级不大，跑在CPU上也能接受，识别出公司名、人名、地址、金额、日期这几类关键实体，然后统一做替换。

这里必须提醒一个坑：脱敏替换不是把原文删掉，而是要保留可恢复的映射关系。我在本地维护了一个脱敏映射表，每次替换都在表里记一条：原值、替换值、替换时间、命中的文档ID。目的是后续如果需要查证原文、或者用户解除脱敏，可以追溯回去。否则上来就把原词抹掉，后面想查谁都查不了。

固态硬盘上存一张映射表完全没压力，重要的是把表和向量库放在同一台机器上，不要又搞出一个跨网络传输的环节。

3.3 第三步：文本切片和向量化，两个参数决定检索质量

脱敏后的文本进入索引前，要先切成块。这里有两个参数直接影响后面检索效果：

• chunk_size：每块文本的长度，我取的是400个字符。
• overlap：相邻块的重复长度，我取80个字符。

为什么这样取？对中文文档来说，400字符大约能覆盖一个完整要点段落。太短，语义碎片化，检索时容易只命中半句话；太长，模型上下文被无关内容填充，既浪费Token又容易“带偏”。

overlap取80字符是为了弥补切块的边界损失——如果一块正好从段落中间切开，下一块开头重复的80字符可以保证那个被切开的语义点仍然完整出现在至少一个块里。

向量化模型的选择也很关键。我选的是一个开源的中文向量模型，维度适中，检索精度在几个模型对比里最好，同时跑在本地的耗时约每百块1秒，这个速度完全可以接受。要提一句的是：向量化模型和最终生成答案的云端大模型可以不是同一家，这个组合很常见，没有任何兼容问题，因为向量化和文本生成是两条逻辑。

索引存储用的是本地向量数据库，支持混合检索：既可以用向量做语义召回，也能用关键词做BM25精确匹配。实际场景里这两者经常互补，比如专利号这种精确值，靠向量检索反而容易误召回，靠关键词精确匹配才稳。

3.4 第四步：设计“按需投递”接口，云端只能看到片段

索引建好，接下来就是最核心的一层——AI网关。

我把这个接口单独做成一个服务，逻辑很简单：接收用户提问，先在本地向量库检索相关性最高的Top K片段，然后由一个本地路由规则决定走哪条通道。

通道规则大概是这样的：

• 如果检索到的片段全部来自“低敏”文档，直接把片段拼进Prompt，发送给云端大模型。
• 如果片段包含“中敏”文档，先把片段再次过一遍脱敏规则，确保无敏感实体残留，再发送。
• 如果片段包含“高敏”文档，直接启用本地问答模型，不向云端发送任何内容。

这个“不向云端发送任何内容”的判断逻辑，是整个方案安全性的基石。我调试阶段专门做过验证：高敏文档提问时，网卡监控里没有产生任何对外的API请求流量。看到这个结果，你才能说这条路真的把控制权夺回来了。

接口层还有一个细节值得做：对发送给云端的片段做“Minimization（最小化）处理”。本地检索Top K可能召回5个片段，但其中只有2个和问题直接相关，另外3个只是沾边。我在接口里加了基于本地小模型的二次相关性打分，低于阈值的片段直接丢弃，不进入Prompt。这既减少了云端模型的处理负担，也降低了敏感内容意外泄露的概率。

3.5 第五步：给谁看、谁能看，权限是最后一道阀

技术上的数据流控制解决了，还有一个业务层面的问题：同样一份文档，不同身份的人应该看到不同内容。

我在代理层加了一层文档级权限控制。每个文档入库时打上项目标签和可见范围标签，用户提问时，检索结果先经过权限过滤，只返回当前用户有权限访问的文档片段。权限在后端强制执行，界面上的按钮只是摆设。

这里要着重提醒：权限过滤必须在向量检索之前或之后分别加一层，但绝不能在发送给云端模型的环节只依赖模型自觉。云端模型是生成器，不是策略执行器。你让它“只根据允许的内容回答”它大概率会照做，但它的训练目标里没有“强制执行权限”这个约束，一旦检索片段里有不该出现的内容，它很可能就“顺手”引用了。所以权限控制必须靠代码硬隔离，不靠Prompt暗示。

4. 常见问题排查与优化记录

整套方案跑起来之后，我整理了四个最有代表性的问题。每一个都是实际踩过坑之后才定位到的，写出来帮你少走弯路。

4.1 切片把代码块和表格切碎了，怎么办

一开始我按纯文本均匀切片，结果遇到包含代码片段的技术文档，代码逻辑被切成两半，检索出来根本没法看。表格也是，一行表头切进上一块，数据行切进下一块，AI回答时经常张冠李戴。

解决方式是在切片前，先把Markdown格式里的代码块、表格、引用块识别出来，作为“不可分割单元”整体保留。然后再允许其他文本按400字符粒度切片。实现不复杂，就是解析Markdown的AST，根据节点类型决定切片策略。

我的体会是：“结构感知切片”对技术类文档的提升效果，比调大模型prompt明显得多。因为问题不在生成端，而在检索端输入质量。检索喂进去的就是断章残片，模型再强也无解。

4.2 脱敏把公司名替换后，AI回答质量明显变差

最开始我用占位符替换人名和公司名，结果发现AI在总结文档时经常出现“{甲方}公司认为……”这种生硬表达，回答质量明显下降。问题在于占位符打断了语言的自然流动，让模型的理解能力受到了影响。

优化方案是保留语义类型，把占位符替换成更自然的泛化词。例如：

• 人名 → “某负责人”
• 公司全称 → “某科技公司”
• 金额 → “某金额”

这样模型在生成时知道“某负责人”是个人、“某科技公司”是个企业，语义边界还在，回答流畅度恢复了很多。这个细节是我反复调了几轮才发现的关键，分享给做同类方案的人。

4.3 向量检索召回不准，Top K里一堆无关内容

这个问题的根因很多时候不在向量模型，而在文本本身。比如同一篇文档里，大量重复的表格描述、页眉页脚、重复模板语句，会被向量化后占据索引中的大量空间，导致检索时被“高相似度无意义内容”刷屏。

解法是在索引前加清洗步骤：去除页眉页脚、版权声明、重复出现的模板段落，同时将纯数字、超链接、无意义符号统一清理。已经建好的索引也不用重建，清洗后重新增量更新一遍即可。

另外还有个容易被忽略的参数：检索时的相似度阈值。默认阈值太低，什么都召回；阈值太高，正确内容出不来。我用本地验证集跑了一遍，把阈值定在0.32左右效果最好，不同的向量模型对应的最佳阈值会有浮动，建议用几十条真实问题样本做一次参数扫描再定值。

4.4 用户反馈“AI什么都知道，但就是不告诉我”

这是上线初期最常收到的一类反馈。排查之后发现不是模型能力问题，而是权限过滤把文档“滤没了”——用户提问的内容在本地索引里本来是有的，但他没有该文档的查看权限，代理层直接裁掉了相关片段，云端模型自然就拿不到素材。

这其实是正确行为，但“正确”不等于“体验好”。优化是在返回结果时明确提示“已找到相关内容，但当前账号无权查看”。用户如果确实需要，可以走文档权限申请流程。这个透明度很重要，否则用户会以为是AI能力倒退，其实是权限边界在生效。

5. 一些想分享给你的实践体会

整套方案从上手到稳定运行，花费的时间比预期多不少，但这部分时间花得值。

最深的体会是：不要把“数据安全”寄托在一款工具或一项设置上，而应把它设计成数据流向本身。当你把解析、脱敏、索引、过滤、路由、审计都放在同一个可控链路里，安全性就不再是某个开关，而是整条链路的默认属性。

另外，这套思路不需要一次到位。如果你的项目体量不大，可以先做两步：本地解析脱敏 + 按需切片投递。这两个点就能解决80%的敏感文件外发问题。向量索引和权限控制可以放在第二期，等数据量大起来、多人协作多起来再补也不迟。

还有一点是运维侧的经验：给代理层的每个环节加日志，尤其是“放行/拦截”记录。日志不用很复杂，每条记录里包含四个字段即可：用户ID、文档ID、动作、时间戳。一旦出了数据相关的问题，这份日志是排查的唯一依据。没有日志，再严密的方案出了问题也只能靠猜。

如果后续你想再进一步，可以考虑在代理层加入自动分类模型，让文件一进来就自动分级；也可以把整个链路打包成内部服务，提供给团队里其他人使用。但就眼下来说，能在保持AI效果不打折的前提下，把“上传全部内容”变成“只传该传的片段”，第三路就已经很值了。