《Codex 使用手册》· 第 13 章｜AI 输出不对时怎样证据式排查

CHAPTER 13 · 连续实战

“结果不对”不是诊断。你会保留修复前摘要，让范围守卫指出 B-17，写出已知与仍未知，再只改选择范围；修复后的摘要除去 B-17 那一行外必须逐字相同。

打开第 13 章练习入口。完整任务位于练习包内 tasks/chapter-13.md；网站只提供下载与阅读，不会替你执行本地文件。

1. 起点

批处理摘要中出现了范围外材料 B-17。你知道“它不该出现”，但还不知道哪一步让它进入结果。

先理解问题

最危险的排查方式是先删异常，再写一个听起来合理的根因。B-17 输入必须保留，before 必须保留，同一守卫必须先红后绿；只有这样才能说“范围过滤”被证实。

2. 只读输入

• inputs/chapter-13/allowed-scope.json
• inputs/chapter-13/B-17.md
• inputs/chapter-13/incident-request.md
• 第 12 章结果、异常与决定

建议阅读顺序

先读允许范围和修复前摘要，再读 B-17 本身；最后看事件请求。顺序的目的，是先固定现象和规则，不让解释抢先。

3. 唯一写入位置

只写 workbench/incident/。先保存的现场文件不得覆盖。

写入位置是本章的安全边界。Codex 可以创建目录，但不能扩大到 inputs、checkpoint 或别章输出。

4. 本章唯一成果

交付 symptom.md、timeline.md、hypotheses.md、before-summary.md、red.log、fix.md、after-summary.md、green.log 和 decision.md。

成果必须能打开、能回查、能由本章检查验证。只有一句“已经完成”不算交付。

5. 可复制给 Codex 的任务

先把出现 B-17 的摘要原样保存为 workbench/incident/before-summary.md，并写现象、时间线和至少三个仍待验证的假设。运行 `node scripts/run-scope-test.mjs --expect-red workbench/incident/before-summary.md workbench/incident/red.log`；它必须检测到 B-17、直接退出 1，并把命令和失败信息写入 red.log。`run-scope-test.mjs` 是外层命令封装器；日志中的 `COMMAND` 记录它实际调用的底层 `scope-guard`，所以两行命令不同是预期。不要删现场，不要同时改多项。只把摘要生成器的范围过滤从宽泛模式改成 allowed-scope.json 的明确 ID 允许清单，保持其余输入和格式不变，生成 after-summary.md。用同一封装器的 `--expect-green` 再次运行守卫并写 green.log；比较前后允许 ID，写 fix.md 和证据强度诚实的 decision.md，最后运行 npm run check:13。

把代码块整段复制，不要拆掉输入范围、停止条件和检查命令。Codex 的总结不能代替产出文件。

6. 你必须亲手完成

先阅读 RED，确认失败来自 B-17 越界而非命令错误；再逐行比较 before/after，确认唯一消失的是 B-17、允许材料仍在；最后把“证实了什么、仍不知道什么”写入 decision.md。

人工动作为什么不能省

你要亲手逐行比较 before 与 after：S-01 至 S-05 完全相同，唯一少 B-17。再读 decision，确认“请求为何产生”仍未知，没有被模型推测冒充根因。

7. 你应该看到

• 原始现场和 B-17 输入都还在。
• RED 直接退出码为 1，并准确点名 B-17。
• 最小修复只改变范围过滤。
• GREEN 直接退出码为 0，允许 ID 没有丢失。

跟着做：从输入到可观察结果

1. 保存现场

把 checkpoint 原样保存为 before，保留 B-17 输入。

**你应看到：**before 同时含五个允许 ID 与 B-17。

2. 运行范围守卫

执行 node scripts/run-scope-test.mjs --expect-red workbench/incident/before-summary.md workbench/incident/red.log。这是外层命令封装器；red.log 的 COMMAND 记录实际调用的底层探针 scope-guard。

**你应看到：**red.log 点名 OUT_OF_SCOPE: B-17，直接退出码 1。

3. 只改一个变量

从摘要选择中移除 B-17，不改输入、格式或允许 ID。

**你应看到：**before 去掉一行后与 after 逐字相等。

4. 同一守卫复测

检查 green.log，运行 npm run check:13。

**你应看到：**直接退出码 0，五个允许 ID 全部保留，决定区分已证实与仍未知。

本章验收参考：自己核对结果

• before 保存 B-17，after 只少这一行。
• 同一守卫日志分别记录直接退出 1 与 0。
• decision 保留仍未知，没有夸大根因。

这些验收信号帮助你检查自己的成果；它们不是可复制的完成文件，也不能替代实际操作。

8. 三个真实坑

坑 1：先删现场

如果覆盖 before-summary.md，就没有可信起点。检查要求 before-summary.md 去掉 B-17 那一行后与 after-summary.md 保持一致；先保留 before，再运行 RED，才能证明只改变了范围选择。

坑 2：一次改多个变量

若同时改过滤、输入和摘要格式，无法归因。差异检查只允许范围选择逻辑和随之消失的 B-17 行变化。

坑 3：把解释当根因

假设文件故意列出多个可能。只有一变量复测支持的结论才能标为“已证实”，其余继续保留未知。

这三个坑都由练习材料、代码或检查实际暴露，不是提醒语。

先看信号，再做补救

**识别信号：**before 已经没有 B-17、after 还改变了别的行，或 decision 把未验证原因写成根因，说明现场或因果链被破坏。**补救动作：**从只读现场恢复 before，重新得到点名 B-17 的 RED，只改变允许范围过滤；逐行确认 before 去掉 B-17 后才等于 after。

补救后仍不能让本章检查因正确原因通过，就按第 10 节停止并回退；不要手改日志或抄写别处的通过结果绕过。

9. 复选框验收

• before 现场在任何修改前已保存。
• RED 因 B-17 越界退出 1。
• 最小修复只改变范围过滤。
• GREEN 退出 0 且允许材料完整。
• npm run check:13 通过。

每一项都要靠打开文件或完成动作后再勾选；不要只凭 Codex 报告的 PASS。

10. 停止、回退与交接

无法保存现场、RED 原因不对、差异超过一个变量或允许材料丢失时停止。回退为恢复过滤基线并保留全部事件证据。交给第 14 章的是修复后的允许范围、前后摘要、RED/GREEN 与证据结论，不交一个被夸大的“全部解决”声明。

**停止条件：**现场被覆盖、修复改动超过 B-17 一行、允许材料丢失、或未验证解释被写成根因。

**回退动作：**从只读 before checkpoint 重建 after；before、red.log 和 B-17 输入始终保留。

**交接文件：**incident/ 的 before/after、RED/GREEN、修复说明与证据决定。