为什么 AI 需要先读懂你的企业上下文

企业上下文，指的是把散落在业务系统、文档与流程里的专有信息，整理成 AI 能检索、能引用、并能按权限裁剪的结构。通用大模型写邮件、翻译、总结都不错，但一问到「这批订单的交付风险」就答不上来 —— 差距不在模型能力，而在这些信息从来没进过它的视野

通用模型缺的到底是什么

缺的东西有两类。一类是知识：某个客户的合同条款、某条产线的设备状态、某个项目的内部代号，这些不会出现在公开训练数据里。另一类是口径：同一件事在公司内部有特定叫法，比如「首检」「封样」「三单匹配」，模型不认识这些词，也就无法把公开知识与内部事实对上。前一类靠接入解决，后一类靠整理解决。

上下文的四类来源

把「上下文」当成一个笼统的东西，是多数项目做不下去的起点。它可以拆成四类，各自清点得出来：

• 系统数据：ERP、CRM、工单、财务系统里的结构化记录，决定「事实是什么」。
• 文档资料：合同、手册、制度、会议纪要，决定「规则怎么写的」。
• 权限关系：谁属于哪个部门、哪条业务线、能看什么等级的信息，决定「谁能知道」。
• 行为痕迹：历史问答、审批驳回理由、文档修订记录，决定「实际怎么做」—— 这一类最常被忽略，却最能反映真实口径。

质量取决于三件事

• 来源可信：每条信息都能追溯到权威出处，而不是「某份不知谁改过的表格」。
• 结构清晰：非结构化文档要拆成可检索的片段，并带上来源、时效、密级、责任人这类元数据。
• 更新及时：价格、政策、人员变动之后，AI 不能继续按旧版本作答，因此需要一条明确的生效链路。

这里有个常见误区：认为「文档越多越好」。未经筛选的知识库会引入大量噪声 —— 同一条规则有三个版本、同一份表格有五个副本 —— 反而降低回答质量。更好的做法是从高频业务场景出发，先整理最常被问到的几十个问题，再逐步扩展。

权限：同一个问题，不同人应该看到不同答案

同一份知识库，销售、法务与管理者看到的内容本就不同。这不是附加功能，而是上下文系统最早要做的取舍：权限过滤放在检索前还是检索后。放在检索前更安全但更容易漏答，放在检索后实现简单但风险更高 —— 这个选择会一直影响到后面的每一步。

验收口径

• 高频问题能在知识库里命中，并把出处指给提问的人看。
• 越权的问题会被拒绝，而不是被绕过或被含糊作答。
• 知识发生变更后，有一条可查的生效时间，而不是只能靠人回忆。

上下文解决不了的事

它不提升模型本身的推理上限，也不能替一个职责没定清楚的组织把流程理顺。如果一件事在公司里至今没有明确的责任人与口径，上下文只会把这个模糊原样放大。所以推进顺序通常是：先定规则与责任人，再谈把这些规则交给 AI。