怎样看懂 Codex 的 diff 和修改总结

diff 是任务交付前最重要的证据之一。你不需要先成为 Git 专家，但必须知道 Codex 实际改了什么。

教程目标

完成后，你能从 diff 中确认修改范围、关键逻辑、意外删除和验证状态。

开始前准备

• 一个已经由 Git 管理的练习项目。
• 一次尚未提交的小改动。
• 确认改动中没有真实密钥或客户数据。

第 1 步：先看文件列表

请先只读检查当前 Git 改动，不要继续修改文件。

请输出：
1. git status 摘要。
2. 本次新增、修改、删除的文件列表。
3. 哪些文件属于本次目标，哪些可能越界。
4. 暂时不要给修复方案。

预期结果：先得到完整范围，而不是直接跳进某一段代码。

第 2 步：让 Codex 解释 diff

请解释当前 diff，按文件输出：
1. 改动前的行为。
2. 改动后的行为。
3. 关键增删行解决了什么问题。
4. 是否删除了仍然需要的逻辑。
5. 是否出现格式化、依赖、配置或生成文件等无关改动。
6. 哪些结论来自 diff，哪些还需要运行检查才能确认。

你要重点看 + 新增行、- 删除行，以及文件重命名和整段代码被替换的情况。

第 3 步：核对任务范围

把原始需求和 diff 放在一起判断：

检查项	通过标准
文件范围	只修改目标需要的文件
行为变化	与原始需求一致
删除内容	没有误删兼容逻辑、注释或测试
配置与依赖	有明确必要性和说明
用户已有改动	没有被覆盖或混入

发现越界时先让 Codex解释，不要立刻接受“顺手优化”。

第 4 步：补验证证据

根据当前 diff，列出最小且充分的验证计划。

要求：
1. 优先使用项目已有的 test、check、lint、build 命令。
2. 说明每条命令验证哪一类风险。
3. 运行安全且与本次改动相关的检查。
4. 分开报告通过、失败、未运行和项目原有问题。
5. 不要把“构建通过”写成“所有功能都正确”。

常见失败分支

• diff 混入大量格式化：先恢复或拆分无关格式化。
• 出现不认识的删除文件：停止交付，确认删除原因。
• 改动包含 .env、认证文件或密钥：立即停止并按泄露流程处理。
• Codex 只给总结但不展示证据：要求重新基于 git diff 和检查输出回答。

验收结果

你做到这里，如果看到下面 3 个结果，就说明本篇完成：

1. 你能列出每个改动文件和它与任务的关系。
2. 你确认没有越界文件、意外删除或敏感信息。
3. 修改总结明确区分了 diff 事实、检查结果和未验证内容。

下一篇看：Codex 修改错了怎么安全撤销。