diff 审查 + 第二轮 Agent 或人工复核

这是一种什么做法

在 coding agent 完成一段代码改动之后，先用 Git diff 查看所有变更，再由人工或第二个 Agent 逐项审查：是否有遗漏（需求里要求的某条改动没做）、越界修改（动了不该动的文件或文件范围）、业务约束违反（能编译能测试但不符合业务规则），最后由作者在变更总结里记录判断。

适合哪些情况

• coding agent 改动覆盖多个文件，单看对话历史无法判断整体行为。
• 业务规则不能由通用测试覆盖，必须由了解项目的人来核对。
• 已有"测试通过"结论但仍怀疑实现是否符合真实意图。

标准步骤

1. 在 Agent 完成实现后，先看 git diff（或 PR diff），而不是先看 Agent 自述。
2. 检查三件事：遗漏、越界修改、业务约束。
3. 由人工进行第一轮 review，或派第二个 Agent 独立 review 同一段改动。
4. 在变更总结里写明审查结论、剩余风险、需要人工继续确认的点。
5. 复盘：把这次发现的规则补充到 项目级 Agent 指令文件（AGENTS.md / CLAUDE.md 同类）。

与现有 Wiki 的关系

• 由 程序员HaiJun 在 8 个月 Codex CLI 复盘中明确提出，作为"实现阶段"最后一步。
• 与 Codex CLI 的上下文漂移与“能跑但不符合业务”失败模式 直接对应：上下文漂移与业务规则遗漏正是这一步要拦下来的失败模式。
• 见 我用了 8 个月 Codex CLI，总结出这套 AI 编程工作流。

限制与检查点

• "测试通过"不等于"业务正确"，diff 审查是测试之外的第二道防线。
• 第二轮 Agent 复核仍可能重复第一轮的盲点，关键业务规则必须由了解项目的人最终确认。
• 不应替代单元测试、构建检查和页面验证——它是补足，不是替代。