企业AI上线几个月后，很多团队都会撞上同一堵墙：提示词改了一遍又一遍，指令越写越长，角色设定也加了，却始终摆脱不了换个问法就时准时不准的状态。

这种时候，问题几乎都不在问法，而在真正交到AI手里的信息。2026年被业界广泛使用的「上下文工程（Context Engineering）」一词，指的正是这部分工作。

本文先厘清什么是上下文工程、它与提示词工程和RAG有何不同，然后给出今天就能用在自家企业知识上的5个步骤。

本文要点

上下文工程的含义，以及它与提示词工程的区别
RAG是否已经过时，还是说它本就是上下文工程的一部分
企业AI回答不稳定时，应当排查的「4种失败模式」
盘点自家知识的具体操作方法
选择信息「投喂方式」（架构）时的判断依据

什么是上下文工程 -- 设计的不是「问法」，而是「交出去的全部信息」

上下文工程，指的是围绕目标，去设计AI在生成答案那一刻所看到的全部信息。

这里说的上下文，远不止用户输入的那句问题。AI生成一次回答时，实际上是把下面这些内容一并接收的。

要素	内容	由谁决定
指令	角色、回答规则、禁止事项	服务方或管理员
提问	用户当场输入的那句话	用户
企业信息	被引用到的企业文档内容	知识整备状况与检索机制
对话历史	此前的往来内容	自动
工具结果	检索、API等的执行结果	系统设计
输出格式	分点方式、出处标注方式	设计者

用户能接触到的，只有其中「提问」这一行。其余绝大部分都是设计者决定的，可现实中很多团队完全不碰那一侧，只想靠改问法提升准确率。提示词优化很快见顶，原因就在这里。

与提示词工程的区别

两者经常被混为一谈，但处理的范围完全不同。

	提示词工程	上下文工程
设计对象	提问与指令的写法	交给AI的全部信息及其收集方式
主要手段	角色设定、步骤明示、示例	信息取舍、时效管理、结构化、权限控制
见效场景	把一次性任务做漂亮	让同一项业务每天稳定运转
天花板	原始信息不存在时，怎么写都答不出来	需要投入精力整理信息

提示词工程并没有过时。只是，在企业知识这类「原始信息就在公司里」的场景中，真正起作用的压倒性地在上下文一侧。如果员工手册压根没有上传，问法再巧妙也不可能问出停职条件。

与RAG的关系 -- 不是对立，而是包含

有说法称「上下文工程来了，RAG就结束了」，这并不准确。RAG本身就是组装上下文的方法之一。

提示词工程：打磨要发送的文字写法
RAG：自动检索与问题相关的文档，补进上下文
上下文工程：设计交出什么、交多少、按什么顺序、以什么形态（是否使用RAG也属于这一层判断）

两者是上下层关系。RAG是手段之一，上下文工程是它之上的设计问题。那些被说成「RAG是白折腾」的案例，大多并非技术本身的问题，而是没有设计交出去的内容，只是加了个检索所导致的。这一论点在「RAG 不需要」是真的吗？企业知识 AI 选型的 6 个判断维度中有详细梳理。

为什么优化提示词也稳不下来 -- 4种失败模式

企业AI回答不稳定时，原因基本可归为以下四类。它们症状相似，对策却截然相反，所以请先判断属于哪一种。

失败1：不足 -- 信息压根没交过去

当企业AI回答「没有相关记载」时，多半是信息根本没有送达。有时是文档本身不存在，有时是它躺在某位同事的电脑或邮件里，从未被导入。

那些不成文的规矩（比如「这类申请要先过部门负责人」），大多根本没有形成文档。这不是检索精度问题，而是知识库存的问题。

失败2：过量 -- 塞得太多反而被稀释

反过来也会出问题。把所有可能相关的文档一股脑交出去，准确率反而下降。长输入中段的信息容易被忽略，这一现象被称为 "Lost in the Middle"，也就是说**「全都读一遍就会更准」并不成立**。

成本层面同理。每次提问都发送海量文档的设计，使用得越多费用膨胀得越快。这一点在RAG已经过时了吗?长文本上下文时代的知识库设计中结合数字做了推演。

失败3：污染 -- 旧版与新版并存

实务中最棘手的就是这一类。2024年版和2026年版的规程同时在库里，AI会把两者都当作「公司里正确的信息」。结果就是看起来像模像样，内容却是过时的。

更麻烦的是，这类错误从用户角度很难察觉。在运维上，比起「往里加」，**「把旧的清掉」**对准确率的作用更大。

失败4：形态不良 -- 写了，却读不出来

只做了扫描的图片PDF、以图片形式贴上去的表格、多个主题混在一起的超长文件。内容虽在，AI却无法正确提取。

写法细节如何影响回答准确率，我们用内容相同、只有写法不同的文档实际导入做过验证，结果整理在让AI能正确回答的公司文档写法。结论是：比起漂亮的行文，「一文件一主题」「第一行写清这是什么文档」要有效得多。

实践篇：上下文盘点的5个步骤

下面才是重点。上下文工程只停留在概念上毫无意义，必须套到自家业务上才会产生效果。想一次性整理全公司的知识必然半途而废，所以请把范围收敛到一项业务。

步骤1：只挑一个想交给AI的判断

「什么公司内部的事都能答的AI」这个目标太大了。请选择提问形态相对固定的业务。

判断某笔支出能否报销
回答年假、婚丧假、育儿假等假期相关咨询
针对询价给出标准价格与折扣条件
回答客户关于产品规格的提问

选择标准是「同样的问题一个月要来好几次」。频次越高，整备的效果越快体现在数字上。

步骤2：把人做判断时看的东西全部写出来

设想该业务的资深同事在做判断时，把他脑子里和手边的信息毫无遗漏地列出来。关键在于，没有形成文档的也一定要写进去。

以报销判断为例：

费用规程（有文档）
会计科目一览（Excel）
过去被批准或驳回的先例（在负责人的记忆里）
「超过5000日元要核对发票的品名栏」这类运营惯例（口头相传）
各部门的例外（只有一部分留在邮件里）

这份清单，就是该业务应当交给AI的上下文设计图。

步骤3：逐项检查「是否是能交给AI的形态」

把列出的条目按下面三列检查。抄进表格软件里填一遍就够了。

判断依据	是否有文档	最新版是否唯一	是否是AI可读的形态
费用规程	有	旧版仍留在文件夹里	PDF（文本）
会计科目一览	有	是	Excel表格
过往批准先例	无（记忆）	--	--
发票品名惯例	无（口头）	--	--
各部门例外	散落在邮件中	不明	不明

这张表填完的那一刻，AI为什么不稳定基本就能解释清楚了。上面的例子中，五项判断依据里有三项根本没交给AI，这是再怎么打磨提示词也解决不了的领域。

步骤4：补缺口 -- 不要追求完美

把检查出来的缺口补上，顺序是「从被问得最多的开始」。

口头相传的内容写成一页纸：不必追求完成度，分点写就够了。哪怕只有「品名栏为空的发票要求重开」这一行，AI就能回答了
清掉旧版：不想被引用的文档，从存放位置里移走是最可靠的做法
表格以文本形式保存：以图片形式贴上的表格，读取精度会下降
把散落的内容集中到一处：埋在邮件和聊天里的例外，找到多少先搬进文档多少

不需要全部补齐。判断依据凑齐八成，实务上就足够跑起来了。

步骤5：用10道真实问题验证，从答错的开始修

最后，准备10道该业务实际收到过的问题，交给AI并对答案。重要的是不要用假想问题，而要从咨询记录里把真实措辞搬过来。

答对的问题，直接投入日常使用
答错的，回到步骤3的表格，定位是哪项依据缺失
同时确认它是否会老实地回答「没有相关记载」（会靠推测作答的状态更危险）

这10道题请保留下来，作为每次新增或修订文档后都要跑一遍的回归测试。知识库每加一次内容都有可能被破坏，手里有一套固定的检查方式，运维才稳得住。

「怎么交」如何设计 -- 三种思路

盘点完材料，接下来要设计的是「每次如何收集、如何交出去」。大体上有三种思路，组织的文档量与权限要求不同，合适的选择也不同。

思路	收集方式	适合的情况	注意点
全部交出去（长文本上下文）	每次把文档整体投入	文档量少，且所有人都可查阅	量一大，成本与准确率会同时崩
检索后补充（RAG）	检索与问题相近的片段并投入	文档量大、需要区分权限	因片段化，对跨文档的问题较弱
顺着结构去取（导航型）	沿目录结构追踪并收集相关文档	文档有结构、需要出示依据	前提是文档已结构化

并不存在哪个绝对更优，答案取决于前面盘点的结果。判断维度的细节请参考「RAG 不需要」是真的吗？。

Monoshiri AI 的设计 -- 顺着目录组装上下文

Monoshiri AI 采用的是第三种导航型。上传的企业文档会被预先整理成层级结构（技能树），提问到来时，AI沿着这份目录追踪，只收集必要的文档，并作为依据出示。

这不是追技术潮流的选择，而是针对上面四种失败模式设计出来的应对。

应对过量：不是把可能相关的全部交出去，而是只交出追踪到的文档
应对污染：因为会出示以哪些文档为依据，一旦引用了旧版，用户能够察觉
应对不足：没有追踪到对应文档时，不做推测，直接回答「没有相关记载」

为什么会从检索方式迁移到这种方式，结合真实的失败案例写在什么是 Corpus2Skill？RAG 与 skill 模式的区别详解中。整理好的文档可以直接通过聊天组件或LINE来提问，因此盘点时整备好的知识能原样落到日常的业务动线上。

常见问题

Q. 没有专职工程师就做不了上下文工程吗？

不是。本文的5个步骤里不含技术性作业。核心是懂业务的人把判断依据写出来，反倒是一线负责人更胜任。工具设置属于服务方承担的部分。

Q. 应该先把文档整理好再引入AI吗？

建议反过来。先用起来，再从答不出的问题开始修，这样更可靠。该整备哪里在纸面上是想不出来的，实际答错的问题会告诉你。

Q. 做AI智能体也是同样的思路吗？

一样，而且重要性更高。智能体会自动跑多个步骤，每一步传入的信息不断累积，更容易出现失败2（过量）和失败3（污染）。它需要逐步骤决定交出什么的设计。

Q. 那打磨提示词已经没意义了吗？

有意义，只是顺序不同。**只有在上下文已经就位的状态下，提示词的打磨才会见效。**食材不够的菜，改菜谱也救不回来。

总结

上下文工程不是什么新技术，而是**「决定交给AI什么」这件理所当然、却经常被省略的设计工作**。要点如下。

上下文工程指的是设计AI回答时所看到的全部信息，提问只是其中一部分
提示词工程管「问法」，上下文工程管「交出去的全部信息」。企业知识场景中，后者效果更大
RAG不是对立概念，而是组装上下文的手段之一；「RAG是白折腾」的案例，多是没做设计只加了检索
回答不稳定的原因可归为不足、过量、污染、形态不良四类，症状相似但对策相反
实践时把业务收敛到一项，写出判断依据，检查能否交付，补上缺口，再用10道题验证

请先挑出眼下咨询量最大的一项业务，把资深同事究竟看着什么做判断写下来。那一页纸，就是决定企业AI准确率的最大因素。

什么是上下文工程？用企业知识落地的5个步骤