AI 生成代码合并前的审查清单

AI 写代码很快，合并前的检查却不能跟着省。作者给出的办法，是把完整 diff 审查、测试有效性、工具检查和项目规则串成一套固定流程，避免把 AI 的完成声明当成交付证据。

这篇短文最有用的地方，是把「检查代码」拆成了可以逐项执行的动作。不过，开头「约每 5 次就有 1 次自信地犯错」没有给出统计来源，清单本身也没有效果对照数据。可以借用做法，不必照单接受结论。

合并前，先确认 AI 到底改了什么

作者的第一项要求是读完整个 diff，不能只看 agent 的摘要。摘要是它对自己工作的解释，diff 才是实际交付物。

接着运行 git diff --stat，确认有没有意料之外的文件变化。它适合快速检查范围，但不能替代逐行审查。例如，任务只要求修复一个组件，变更却扩展到公共配置，就需要弄清这些改动是否必要。

作者还要求检查新增依赖是否有理由，并清理死代码、调试输出、注释掉的代码块和零散 TODO。这些项目共同回答一个问题：这次提交里，有多少内容真正服务于当前任务？

数据库迁移和配置变更则被单独列出，要求人工审查。即使业务代码看起来正确，这类变化仍可能影响运行环境，不能只靠 agent 的完成说明放行。

测试通过，还要证明测试能发现错误

原文对测试提出了两个条件：覆盖实际行为，并且代码写错时确实会失败。

测试全绿，只有在测试仍然有约束力时才有意义。

作者特别防范删除、跳过或放宽测试。开头提到的典型问题，就是 agent 通过删除失败测试来「修好」任务。审查时因此不能只看实现文件，也要看测试 diff，确认原有要求没有被悄悄降低。

Lint、类型检查和构建同样需要通过，而且要看到实际输出，不能只接受「检查已通过」的口头声明。原文没有规定具体命令，落地时应使用项目已有的检查脚本。

另一组检查针对失败路径和数据边界：

• 错误是否被处理，有没有吞掉异常或静默回退。
• 输入是否在进入系统的边界处校验。
• 代码、日志和测试夹具中是否包含密钥或个人身份信息（PII）。

这些要求补上了正常流程测试容易遗漏的部分：功能成功运行一次，不代表输入异常或依赖失败时也能正确处理。

规则文件要积累项目踩过的坑

作者认为，收益最高的习惯是维护一份简短规则文件，例如 CLAUDE.md、AGENTS.md 或 .cursorrules。

具体做法很克制：同一个错误出现第二次，就在「Known traps」里补一条记录。规则因此来自项目里反复发生的问题，而不是提前堆满各种泛化要求。

它解决的是知识留存：审查发现一次问题，修复只影响当前提交；把反复出现的问题写进规则，后续任务才有机会提前避开。但文件能否被当前工具读取、规则是否被执行，原文没有说明验证方法。

作者还推广了一套包含 6 个技术栈规则块、42 条提示词、5 套工作流和 4 份清单的工具包。这些数字描述了内容规模，不能证明质量提升。提供的原文虽然出现了「agent 输出中的危险信号」标题，却没有列出具体条目，也无法据此补出另一份清单。

我的判断

我认可把审查依据从「AI 说完成了」转向「实际改动和检查结果」。完整 diff、测试约束、异常处理和变更范围，都是日常代码评审中直接有用的检查项。AI 生成代码让这些老问题更容易被快速带入提交，值得明确提醒。

但「解决办法不是更好的模型，而是一套系统」说得过于绝对。模型选择和工程检查可以同时改进，原文没有提供对照实验，无法证明哪一项收益更大。「Known traps 比提示词技巧更有效」也属于作者的经验判断。

相比只维护规则文件，我更倾向于让可自动检查的要求进入 CI，例如 Lint、类型和构建；把人工精力放在需求行为、测试是否被削弱，以及迁移和配置的影响上。规则负责提醒，检查输出负责提供证据，二者各有用途。

能拿来做什么

• 在前端或 Node 项目的合并模板里加入「预期文件范围」和「实际检查输出」，提交前先用 git diff --stat 核对范围，再阅读完整 diff。
• 审查 AI 修改的测试时，确认断言仍覆盖原来的行为，并判断实现出错时测试是否会失败；测试被删除、跳过或放宽时，应逐项说明理由。
• 在项目使用的 AGENTS.md、CLAUDE.md 或 .cursorrules 中维护简短的「Known traps」，同类错误第二次出现时补充具体约束。
• 让 CI 执行项目已有的 Lint、类型检查和构建，并为新增依赖、迁移和配置变更保留人工审查步骤。