审查 AI 补丁：先看逻辑，再查完整差异

dev.to · AI#代码审查#GitHub#AI编程

Editor brief · 编辑速览

GitHub 新增可保存的空白差异偏好，便于减少格式变更对审查的干扰。文章建议先明确预期行为、审查逻辑，再检查被视图设置隐藏的改动及范围外变更。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

AI 修一个 Bug，却顺手重排了半个文件，审查者既要找出真正的逻辑修改，还要确认有没有夹带其他变化。原文借 GitHub 在 10 月 22 日公布的空白字符偏好设置，提出了一套两轮审查方法：先用聚焦视图理解行为，再恢复完整 diff 检查遗漏。

它的价值不在于教你隐藏空格，而在于提醒：界面上变得清爽，不代表修改已经查全。对经常接收 AI 补丁的程序员，这个区别直接影响合并判断。

作者建议，打开 diff 前，先用一句话写清预期行为。原文用一个虚构的预约应用举例：结束时间早于开始时间时拒绝保存，并保留用户已经填写的值。

这句话给审查划出了范围。如果补丁同时重写导航菜单、增加 analytics 依赖，就需要解释它们与修复的关系。AI 将这些动作称为「清理」，并不能替代解释。

接着才看实现：校验条件比较了哪些值，错误分支如何处理，用户修正时间后能否重新提交。如果格式调整淹没了这些逻辑，可以临时隐藏空白字符差异。

按原文对 GitHub 公告的转述，新设置支持保留空白差异、跨审查隐藏，以及只对单次 diff 隐藏；当前审查也可以恢复显示，而不改掉已经保存的偏好。分栏视图中的新增和删除文件，还能使用完整宽度。

这里最容易误判的是统计信息：启用过滤后，显示的文件数量和 diff 统计也会跟随过滤视图变化。

因此，不能看到界面上只剩几个文件，就认定补丁只有这些内容。第一轮更有用的产物是一段行为说明：保存前执行校验，输入无效时表单保持打开，修正后允许保存。如果连这条路径都解释不清，就还没到批准合并的时候。

理解核心逻辑后，作者建议重新显示空白字符、清除文件过滤，再检查全部变更，包括新增和删除的文件。

两轮分别解决不同的问题。第一轮帮助你从噪声里找出修复；第二轮检查刚才聚焦时容易漏掉的配置修改、被删除的测试、文本模板变化，以及无关文件的重新格式化。

空白字符也未必只是外观。原文引用 Python 的语言规则说明：行首缩进决定语句如何分组。一条操作即使文字完全没变，只要移出了条件分支，执行时机就可能变化。

放到预约应用里，保存操作原本应该只在校验成功后执行。如果缩进让它跑到条件之外，无效预约也可能被写入。审查时需要读完整函数，再提交一条无效预约，确认没有发生保存。

不过，作者明确保留了边界：他没有声称 GitHub 的过滤功能一定会遮住这个具体例子。这个例子说明的是，显示选项不能理解程序的全部语义，最后仍要判断修改后的文件会怎样运行。

要求 AI 尽量把格式变化和行为变化拆开，也能降低阅读成本。但拆开提交只是让修改更容易检查，不能证明任何一部分安全。

GitHub 支持逐个检查文件，并标记为已查看。作者建议把它当作进度记录：检查过相关内容后再标记，而不是把文件折叠起来，就视为功能验证完成。

原文为虚构修复提出了三类记录：

这三项分别回答「要改什么」「看过什么」「运行时发生了什么」。它们不能互相替代。

读懂补丁，能帮助解释实现；运行应用，能验证经过的一条路径。二者都不保证所有故障已经找完，但把它们分开记录，可以避免一句「看过了」混合多种未经确认的判断。

我认同作者把聚焦阅读和完整性检查分开。AI 补丁里混入格式调整时，审查者确实需要先定位行为，再回头确认范围。尤其是过滤后的统计也会改变，仅凭当前界面的文件数判断覆盖情况，依据并不充分。

但这是一套审查经验，不是效果已经得到量化验证的方法。原文没有提供真实团队的对照数据，没有测量漏检率或审查耗时；预约应用也是虚构案例。不能据此宣称两轮审查能降低多少缺陷。

它还有一个前提：补丁大小必须处于审查者能理解的范围内。作者也承认，第二轮会消耗额外注意力。遇到大补丁，更合理的处理可能是先要求缩小修复范围、分离格式修改，或解释无关变更。

与要求 AI 直接生成更小补丁相比，两轮审查是在接收补丁之后补上检查；与运行测试相比，它更关注变更范围和实现意图。几种做法可以配合，但不能把其中一项当成其余工作的凭证。对于本来就很小、容易检查的修改，也没必要为了形式机械拆分。