看懂 Claude Code 的 diff

让 Claude Code 改代码之后，真正的关键是看懂 diff：哪些文件被改了、为什么改、有没有越界、有没有漏掉验收。

Claude Code 修改完成后，不要只看它的总结。真正要看的，是 diff。

diff 是本次任务最重要的交付证据。它告诉用户：CC 到底改了哪些文件、每个文件改了什么、是否超出任务范围、有没有引入新风险。

不会看 diff，就不适合直接把 CC 带进真实项目。因为 CC 说“已完成”只是描述，diff 才是事实。

先看文件范围

第一步不是看代码细节，而是先看文件清单。

可以直接让 CC 汇报：

请先不要继续修改。

请汇总本次 diff：
1. 修改了哪些文件。
2. 每个文件为什么需要改。
3. 哪些文件是核心改动。
4. 哪些文件只是配套调整。
5. 是否有任何文件超出原始任务范围。

如果文件范围和任务目标不匹配，先不要进入细节审查。

越界改动通常长这样：

可以这样要求 CC 自查：

请检查本次 diff 是否存在越界修改。

对每个修改文件判断：
1. 是否和原始目标直接相关。
2. 如果只是间接相关，为什么必须改。
3. 如果不必要，请建议回退。
4. 不要为了证明自己合理而强行解释。

越界不一定都是错，但必须说得清楚。

审查 diff 时，不要所有文件都用同一个标准。

让 CC 按文件角色解释 diff，会比让它泛泛总结更有用。

很多风险藏在删除里：

可以这样问：

请重点解释本次 diff 里的删除内容。

请说明：
1. 删除了哪些逻辑。
2. 为什么可以删除。
3. 有没有用户场景会受到影响。
4. 有没有测试或验证覆盖这个删除。

如果 CC 解释不清楚删除原因，应该要求重新确认。

“顺手优化”是 CC 常见问题。它可能不是恶意，但会扩大风险。

常见表现：

遇到这种情况，可以直接收敛：

本次任务只要求完成原始目标。

请检查 diff 中是否有顺手优化：
1. 如果有，请列出来。
2. 判断是否必须保留。
3. 不必要的请建议回退。
4. 保留的必须说明它和任务目标的直接关系。

真实项目里，小改动比大改动更容易安全交付。

可以让 CC 给每个改动打风险等级：

请按风险等级审查本次 diff。

格式：
| 文件 | 改动摘要 | 风险等级 | 风险原因 | 验收方式 |

风险等级使用：
- 低：文案、局部样式、无业务逻辑。
- 中：页面逻辑、状态、接口调用。
- 高：权限、数据库、支付、登录、部署、全局配置。

这个表格很适合提交前看一遍。

看到这些信号要停一下：

可以直接让 CC 做危险信号检查：

请检查本次 diff 是否出现危险信号。

重点看：
1. 密钥或隐私信息。
2. 无关文件。
3. 新依赖。
4. 配置变化。
5. 公共组件影响面。
6. 测试或验证缺失。

diff 审查完成后，不要马上结束任务，还要连到验证和代码审查。

收尾模板：

请基于本次 diff 给出收尾建议。

请输出：
1. diff 是否符合原始目标。
2. 是否有建议回退的改动。
3. 还需要执行哪些验证。
4. 是否需要进入 /code-review。
5. 是否可以进入提交前检查。

这样任务就不会停在“改完了”。