用 Git diff 审阅，而不是只看 Agent 总结

建议用时：25 分钟（含练习）

学习目标

能够检查实际文件差异、未跟踪文件和测试结果，并识别越界改动。

本节产出

一份变更审阅记录

核心知识：总结告诉你意图，diff 告诉你改了什么

Agent 说“只修复了一处空态”，实际改动可能包含依赖、配置和多个组件。审阅不能只读最后的总结，应查看 Git 状态与差异，理解增加、删除和修改分别改变了什么。diff 不会自动解释业务正确性，但它给你一份可定位的事实基础。

Git 常见的比较对象包括工作区、暂存区和提交。

新建但尚未跟踪的文件不一定出现在这些差异里，因此还要看 git status --short。

下面这些是只读检查命令，可在练习仓库运行。它们不会提交、推送或删除文件。

git status --short
git diff --stat
git diff
git diff --cached
git diff --check

每条命令回答的问题不同：状态看范围，统计看体量，正文差异看行为，暂存差异看准备提交什么，--check 检查一类空白和冲突标记等问题。最后一项通过并不意味着逻辑正确，也不能替代测试。

图中最后仍回到待提交内容，是因为工作过程中暂存区可能与工作区不同。你刚修好了一个文件，但没有更新暂存内容，提交进去的仍可能是上一版。因此不要把曾经看过一次 diff 当成对最终提交的审阅。

按风险读，而不是只看行数

少量改动也可能影响很大，例如删掉一个权限条件；很多行变化也可能只是生成文件或格式化。先看文件角色，再看调用影响：是否修改了认证、支付、数据写入、网络请求或依赖执行路径？本课练习不操作这些生产功能，但应学会识别它们属于需要更严格审查的表面。

对于普通 UI 修改，检查文案、可访问名称、事件处理和状态分支是否一致；对于纯函数，检查输入边界、返回类型和调用方假设。不要只在新增行中寻找问题，删除的保护条件或被覆盖的错误处理同样重要。

案例：一个“空态修复”藏了额外修改

虚构 diff 在列表为空时增加提示，同时把接口错误统一转换为空数组。界面看起来不再报错，但真实失败现在也显示“还没有项目”。这不是一个可靠修复，因为它混淆了没有数据与请求失败。

审阅时可以提出具体反馈：“保留成功响应的空态提示，但恢复错误分支；为请求失败显示错误状态增加检查。”反馈定位行为与触发条件，而不是泛泛写“代码质量不好”。如果这是 Agent 做的改动，也应要求它修正后重新展示 diff 和测试。

另一个例子是顺手更新锁文件。先确认本次是否真的修改依赖；如果没有，锁文件变化可能来自使用了不同包管理器或版本。不要直接接受，也不要盲目恢复，先检查它是否包含他人的既存改动，再决定只处理本次造成的部分。

给审阅结论分级

结论	应提供的依据
可以接受	行为符合任务，相关检查通过，范围合理
需要修改	具体触发条件、错误结果和建议方向
需要补证据	哪项行为尚未运行或无法确认
超出范围	哪个文件或行为与任务无关

审阅者不必声称发现所有潜在问题，但要准确描述本次看过的范围。对于安全或数据敏感变更，独立审阅与更强验证可能必要；对于低影响改动，保持审查轻量而有效。

动手练习

1. 在练习仓库创建一个未跟踪文档，并修改一个已跟踪文件。比较状态和 diff 的输出，理解为什么只看 diff 会漏掉新文件。
2. 将一部分改动暂存后再修改同一文件，分别查看工作区和暂存差异。仅在无重要数据的练习仓库操作暂存。
3. 对“把所有接口错误转为空数组”的虚构改动写一条具体审阅意见，并提出应补的测试。

参考答案与推演

展开

完成检查

• 能区分工作区、暂存区和提交的比较关系。
• 状态检查包含新文件，没有只看新增行。
• 审阅关注行为、删除项和任务范围。
• 最终结论对应准备交付的实际版本与测试结果。

参考与来源

• Git：git-diff：各类差异比较与参数的官方说明。
• Git：git-status：理解已跟踪、暂存与未跟踪状态。