重写 Prompt 之前，先画清上下文

回答出错时，人们很容易先改离模型最近的那句话。真正的问题可能发生得更早：检索到了旧文档，系统规则和用户要求冲突，示例教错了格式，或者工具结果没有进入最后一步。

把一次模型调用拆成六条泳道

1. **系统指令：**长期有效的规则、身份和边界。
2. **当前任务：**用户这一次具体想完成什么。
3. **事实资料：**答案可以依据的内容。
4. **示例：**什么行为和格式被视为合格。
5. **历史与状态：**前面步骤留下的决定、事实和进度。
6. **工具与输出规则：**可以执行的动作，以及必须返回的结构。

每一项都写明负责人、更新时间、最大体积，以及它缺失或错误时会出现什么信号。

不只检查有没有，还要检查顺序

两条流程可能包含同样的事实，却因为重要限制被埋在很长的对话后面而产生不同结果。标记哪些信息固定存在、哪些在运行时选择、上下文过长时哪些可能被裁掉。

最终要画的是模型实际收到的组合，而不是散落在周围的数据库、Prompt 和文档列表。

案例：内部制度助手

系统规则要求每个答案引用现行制度。用户询问差旅报销，检索结果同时包含当前制度和旧版常见问题，历史里还保留着上一轮关于另一国家的问题。

上下文图会直接暴露三个修复动作：排除旧版资料、按地区过滤、禁止上一轮答案成为本轮证据。把 Prompt 改成“请务必准确”无法修复其中任何一个。

案例：销售跟进邮件

用户要求写一封简短跟进。CRM 里有客户明确说过的优先事项，会议记录中还有尚未承诺的探索想法；示例邮件则示范了过度确定的语气。

上下文图把“明确承诺”和“讨论中的可能性”分成不同类型，并要求在输出中使用不同标签。真正需要调整的是资料分类，不是写一条更长的写作 Prompt。

逐个检查交接处

每次信息改变形式的地方都加一个检查点：搜索结果变成片段、工具结果进入状态、状态组装进 Prompt、回答转成外部动作。记录这里可能发生的丢失、重复和顺序错误。

用一个失败案例重建模型实际看到的内容

固定一条能够重复的失败输入，保存当时的系统规则、用户请求、检索片段、工具返回、历史摘要、输出约束和配置版本。不要从代码仓库里的 Prompt 模板推测运行内容；要检查最终发送的请求以及调用前后发生的裁剪、拼接和转换。

为每条上下文记录六个问题：

检查项	要写清什么	失败时的表现
来源	信息从哪个系统、文件或人而来	无法解释结论依据
选择	哪条规则决定它进入本次调用	不相关或无权限内容混入
优先级	与其他信息冲突时谁胜出	旧规则覆盖当前任务
位置与体积	放在哪里，最多占用多少空间	关键限制被截断或淹没
时效	版本、生效日期与更新时间	回答使用过期事实
负责人	谁能修正或下线这项内容	发现问题却无人能处理

排查顺序从事实开始：先确认正确证据是否进入，再看冲突规则与示例，最后才调整措辞。每次只改变一层，用同一失败案例和几条回归案例复测。若同时重写 Prompt、替换资料和更换模型，即使结果改善，也无法知道真正的修复来自哪里。

上下文预算不是“能塞多少就塞多少”。先保护任务、边界与当前证据，再决定历史和示例的保留策略。稳定规则可以压缩成短结构，长工具结果应提取任务所需字段；任何摘要都要说明它可能丢失什么，并保留返回原始来源的方式。

常见问题：上下文越长，回答就越好吗？

上下文窗口和上下文图有什么区别？

窗口是模型一次能够接收的容量边界；上下文图描述真正进入这次调用的信息、顺序、来源和责任。窗口很大并不代表选择正确，也不代表旧资料、冲突指令和无关历史不会降低结果质量。

示例应该放多少个？

只保留能澄清关键行为、边界或格式差异的示例。多个近似示例会消耗空间，还可能让偶然措辞看起来像硬规则。为每个示例写明它要教什么，并用不符合条件的案例确认模型没有机械模仿。

长对话什么时候应该重新开始？

当任务目标、资料范围或权限发生变化，或者历史摘要已经无法说明哪些结论仍有效时，应建立新的任务状态，而不是继续追加聊天。需要保留的决定应转成有来源和状态的字段，而不是依赖模型从整段对话中猜测。

不适用边界

上下文图不能解决模型本身无法稳定完成的推理。如果正确、精简的证据已经存在，结果仍然不可靠，就应该缩小任务、增加确定性计算或测试其他方法，而不是无限增加上下文。