换模型之前，先诊断回答为什么失败

坏答案是一条证据，不是诊断结果。每次失败都更换模型，会掩盖问题究竟来自输入、检索、指令、校验，还是回答之后的执行步骤。

诊断的目标不是为错误找到一个听起来合理的解释，而是找到一个能被反事实测试证伪的原因：只改变这一层、保持其他条件不变，失败是否消失？如果不能回答，就还没有定位到根因。

找到第一个出错的位置

保留这条案例的完整轨迹：用户输入、选中的资料、组装后的上下文、模型回答、工具调用、校验器，以及用户最后看到的结果。沿着顺序寻找实际行为第一次偏离预期的位置。

然后把失败归入六类：

1. **输入缺失：**完成任务需要的事实根本没有进入流程。
2. **证据错误：**检索选择了无关、过期或无权限资料。
3. **指令冲突：**两条规则要求不同方向的行为。
4. **能力边界：**即使输入正确，模型仍不能稳定完成转换。
5. **输出契约失败：**核心意思存在，但格式无法被下游使用。
6. **交接失败：**正确结果在下一步丢失、变形或被错误执行。

案例：回答了旧版制度

制度助手引用去年的报销上限。回答很顺畅，也完全符合格式。轨迹显示，检索把已归档的常见问题排在现行制度之前。

在 Prompt 中加入“请使用最新信息”只是在处理表面症状。修复应该发生在资料状态、检索过滤和时效检查。模型只是使用了它收到的证据。

案例：工具调用格式错误

Agent 找对了客户，也选对了操作，却把日期写成下游接口不接受的格式。接口拒绝请求，界面最后却显示“客户不存在”。

第一个错误不是推理，而是结构校验和错误翻译。更大的模型仍可能输出错误格式，也不会自动修复误导性的错误消息。

让修复动作回到对应层

• 输入缺失：改变采集方式或先提出澄清问题。
• 证据错误：调整资料筛选、排序和时效控制。
• 指令冲突：明确优先级并删除重复规则。
• 能力边界：缩小任务、加入确定性计算或比较其他模型。
• 契约失败：使用结构化输出和校验器。
• 交接失败：修复 schema、状态、重试和错误展示。

用最小改动验证诊断

先冻结原始案例，包括时间、工作流版本、模型配置与依赖返回。然后复制一次运行，只替换怀疑有问题的部分。怀疑资料过期，就固定回答逻辑并换成正确资料；怀疑模型能力，就保持输入与验收不变，再比较候选模型；怀疑下游交接，就绕过模型，手工送入一份符合契约的输出。

一次只改一个变量。若同时更换模型、重写 Prompt、更新知识库和调整解析器，即使结果变好，也无法知道哪项改变真正有效，更无法判断新问题来自哪里。

复测不能只运行那条失败案例。还应加入同一切片的常规案例和相邻边界案例，确认修复没有把一种错误换成另一种错误。例如提高“拒答”指令可能修复越权回答，却让资料齐全的正常请求也被拒绝。

可复制的失败记录

记录项	应填写的证据
预期行为	对应的验收规则与通过样例
实际结果	用户真正看到或系统真正执行的内容
首个偏离点	轨迹中第一次违反预期的位置
原因假设	可以通过单变量实验验证的陈述
最小实验	保持什么不变，只替换什么
防线缺口	哪个校验本应阻止问题继续传播
修复范围	受影响切片、负责人和回归案例
关闭条件	哪些证据足以确认问题已经解决

“模型产生幻觉”不适合作为原因假设，因为它没有说出输入、证据和控制为何允许错误抵达用户。更好的写法是：“检索没有排除归档制度，导致旧版本进入上下文；加入状态过滤后，同一问题及三个版本边界案例均选择现行文档。”

何时才值得更换模型

当输入完整、证据正确、指令不存在冲突、输出校验正常，并且多个代表性案例仍持续失败时，才把能力边界列为主因。此时比较模型也要沿用同一输入快照与同一验收契约，否则只是比较两套不同实验。

若新模型只让措辞更漂亮，却没有修复阻断性错误，不能算诊断成功。相反，如果一个确定性日期转换器能消除工具格式失败，就没有必要用更昂贵的模型承担本应由代码保证的工作。

常见问题

没有完整日志怎么办？ 先停止凭印象调参，补齐下一次能保存输入、检索结果、版本、工具调用与错误码的最小追踪；旧案例只能标记为“原因未确认”。

用户只说“答案不好”时从哪里开始？ 先把反馈改写成可观察差异：缺了哪项、哪句话没有证据、哪个动作不该发生，再沿轨迹查找首个偏离点。

同一问题有多个原因怎么办？ 标出主因、放大因素与失效防线，并分别验证。优先修复最早出现且影响范围最大的那一层。

不适用边界

一次失败可能有多个原因。分别记录最早原因，以及本应发现它却没有工作的后续防线。失败树不是用来追责，而是阻止团队在错误的层花费成本。