第 04 节:审阅 diff,再让它改

本节 objectives:

• 能用 diff 判断 Codex 是否只改了该改的地方。
• 能区分行为问题、测试问题和风格偏好。
• 能写出行级反馈让 Codex 精准修正。

先修:会看 Codex 的计划和状态 ｜ 上一节 << 03 ｜ 下一节 05 >>

diff 是你和 Codex 的共同事实

Codex app 的 Review pane 会显示 Git 仓库当前变化,不只显示 Codex 改的文件,也会显示你自己或其他未提交改动。官方文档明确提醒,review pane 反映的是 Git 仓库状态,默认关注未提交变化,也可以切到 branch changes、last turn changes、staged/unstaged 等范围。¹

这点很重要:你审 diff 时,先分清哪些是本轮任务的改动,哪些是已经存在的脏改。否则你可能让 Codex "修掉"别人正在做的工作。

讲解

审 diff 按四层看:

1. 文件范围:有没有碰不该碰的文件。
2. 行为变化:用户可见行为是否符合目标。
3. 验证变化:测试、fixture、文档是否跟行为匹配。
4. 维护性:命名、重复、边界是否合理。

Codex app 支持在 review pane 里对具体行留下 inline comment;官方建议留言后再回到 thread 明确发送"处理这些 inline comments,保持范围最小"之类的指令。¹ 如果你用 CLI 或 IDE,也可以复制 diff 片段,用文件路径和行附近内容描述问题。

反馈越靠近代码,修复越稳。不要写"这个不对";写"这里把空数组当成 null 处理,会让无结果状态显示 loading;请保持空数组为 done state"。

跟我做一遍(worked example)

你要求 Codex 修复 glossary.json 加载失败。diff 里出现:

- return []+ return fallbackGlossary

同时它还改了首页颜色。你的反馈:

请只保留 glossary 加载相关改动。首页颜色改动不在任务范围内,请撤回。
对 glossary 这行:不要用 fallbackGlossary 掩盖坏 JSON。坏 JSON 应该返回 [] 并在调用方降级显示;请补一个坏 JSON 的测试,证明不会抛错。

这段反馈同时处理了范围和行为。你没有要求它"重新来",而是告诉它该保留什么、撤掉什么、补什么证据。

换你补全(faded example)

Codex 改了 5 个文件,其中 2 个是任务外样式整理。请补全:

请把本轮 diff 收窄到 ____________________。撤回 ____________________。保留 ____________________。补充验证 ____________________。

参考答案:

请把本轮 diff 收窄到登录错误状态。撤回按钮圆角和全局 spacing 的整理。保留错误消息可见性和 aria-live 改动。补充验证错误状态出现时不会改变表单提交逻辑。

关键判断点是不要把"看起来顺手"的改动混进小修。

小结 + 通向下一节

diff 是 Codex 工作的证据面。你用范围、行为、验证、维护性四层审,再给具体反馈,它就能小步修正。

下一节看验证:Codex 说做完了,你怎么让测试和手动检查支撑这个结论。