AI 为什么越聊越乱：用一次后端排障理解上下文工程

AI 连续分析一个问题时，回答变乱，未必是提示词不够强。有时它收到的资料本身就互相冲突：前半段是昨天的日志，后半段是今天的配置，中间还夹着已经否定的猜测。要改善回答，先把“现在应该依据什么判断”说清楚。

上下文是需要维护的工作资料

#

上下文工程需要在模型工作时持续选择、更新有用的信息。任务指令、工具结果和历史消息会一起影响判断；任务越长，越需要区分当前依据、已经失效的资料，以及需要按需查询的原始记录。

工具定义和结果也会占用上下文；提示缓存改变计费方式，不会使相关内容退出上下文窗口。具体容量和压缩功能需要按实际模型核对。

把同样的资料交给同事，他能否分清当前事实和排查历史？如果人也要反复猜测时间、环境和结论状态，应该先修正资料组织方式。

先把“接口慢”改成可回答的问题

#

假设测试环境中的 catalog-api 最近出现超时。直接告诉 AI“帮我看看为什么慢”，它很容易围绕常见原因列一长串可能性。更有用的输入应明确现象、时间范围和允许动作：

目标：定位测试环境 catalog-api 在 10:00—10:15 的超时原因。
现象：部分商品查询返回超时，是否影响所有请求尚不清楚。
允许动作：读取已提供的日志、配置和指标。
交付：按证据强弱排序的假设，以及下一步需要什么数据。
边界：不改配置，不重启，不执行数据库写入。

这里没有指定结论，也没有要求模型扮演某种专家。它只是让工作有一个稳定边界。如果后来发现慢的是另一个接口，需要修改目标记录，并说明为什么调整，不能悄悄把两个问题混成一件事。

时间范围尤其重要。一次部署前的连接池配置与部署后的连接池指标，可能同时都是真实资料，却不能直接拿来解释同一时刻的现象。上下文的质量，首先取决于这些关联是否成立。

给每条证据一个“身份证”

#

可以为提供给 AI 的资料维护一个小清单：

清单中应写明每项资料的证明范围：一条日志只能证明某次请求发生了什么，不能自动证明所有请求都受影响；配置文件也不等于配置已经生效。

引用结论时，要求模型带上编号，例如“E2 支持连接等待假设，但缺少同时间段 SQL 执行耗时，尚不能判断数据库本身是否变慢”。这样读者能追溯判断过程，也能发现某个结论其实没有证据。

原始日志应单独保存。给模型的摘录可以删掉无关字段，但应保留请求标识、时间、服务和错误类型。若错误前后关系影响判断，就不能为了减少字数只截最后一行。

如果两份资料冲突，先把冲突本身记下来。例如配置快照显示上限为一个值，运行实例却读到另一个值，此时不能随意选择看起来更合理的那个。下一步应确认两份资料是否来自同一实例、同一版本，以及配置是否需要重启后才生效。这些检查做完前，结论应保留条件：它适用于哪份资料描述的状态。

此外，日志数量也不等于独立故障数量。同一请求可能在多个组件重复记录，若把每行错误都当成一次超时，会高估影响。为资料建立请求级关联，能让后续解释更接近真正发生的事情。

把假设与事实分开维护

#

排障最容易失控的地方，是一句“可能连接池太小”经过几轮讨论后，变成“已确认连接池太小”。可以用一个状态表阻止这种漂移：

H1：连接等待导致超时
状态：待验证
支持证据：尚未补齐
反证：尚未补齐
下一步：对齐连接等待指标与超时请求时间

H2：某类查询执行变慢
状态：待验证
下一步：获取相同时间范围的查询耗时分布

“没有找到反证”不等于“已经证明”。每次获得新资料，先更新假设状态，再写解释。否定一项假设时，应留下简短理由和证据编号，避免下一轮重新提出同一猜测。

这份表不需要持续增长。已经结束、不会影响后续决策的枝节可以收进历史记录；当前工作资料只保留仍然有区分价值的候选原因。这样整理的标准是能否帮助选择下一步检查，而不是字数越少越好。

长任务结束一阶段，就交接一次

#

一次排障可能跨越午休、换电脑或新的对话。交接记录应能让另一个人接着工作，而不必重读整段聊天。交接时可以记录这些内容：

任务：catalog-api 测试环境超时定位
当前资料范围：10:00—10:15
已确认：只写有证据编号支持的事实
已排除：假设编号 + 排除原因
仍未知：缺失信息及其影响
下一步：一项能区分剩余假设的检查
权限边界：仍为只读
原始资料：保存位置与版本标识

恢复任务时，不应把这份记录当作永远正确的事实。先核对环境和资料版本：如果服务又部署了一次，旧结论仍可解释旧故障，却未必适用于现在。记录中的路径也只是线索，读取不到文件时应明确报缺，不能用记忆补正文。

如果多类任务需要不同资料，可以分别维护入口。可以采用入口说明、当前状态和按需参考资料的分层目录。固定、重复使用的操作方法适合维护为技能；单次排障的时间线和临时假设，则留在该任务的记录里。

怎样判断这套组织方式是否有用

#

可以选几组虚构或脱敏资料，让同一模型分别读取杂乱版本与整理版本。先固定模型、问题和允许工具，再比较结果，避免把模型变化误判为资料整理的收益。

建议检查四件事：是否把旧配置当成当前配置，是否将待验证猜测写成结论，能否说明缺哪条证据，以及能否遵守只读边界。回答更长、术语更多，都不能直接算改进。

还可以故意加入两份不同时间的配置，观察模型是否主动询问适用时段。这类案例比“请总结这段文字”更能暴露上下文混淆。若整理版本依然答错，就根据错误调整资料，而不是继续添加大段“必须认真”的指令。

对于常做后端开发和运维的人，这种做法的直接收获，是把聊天变成可以复核的工作记录。AI 能否给出可靠判断，最终仍要落到证据是否相关、时间是否对齐、未知是否保留，以及下一步检查能否真正缩小问题范围。

参考来源

#

• Anthropic Applied AI 团队的 Prithvi Rajasekaran、Ethan Dixon、Carly Ryan、Jeremy Hadfield，《Effective context engineering for AI agents》，发布：2025-09-29。
• Anthropic，《Context windows》。
• Agent Skills 标准维护者，《Specification》。
• 配图：Anthropic，图片出处。