审查 AI 生成的代码

先读要求，再读摘要

从所需行为和验收标准开始，再检查实际 diff。智能体的摘要可以帮助定位内容，但可能遗漏修改，也可能错误描述检查情况。

确认正在审查的分支和提交。除了应用代码，也要检查配置、依赖、基础设施和测试的修改。看起来很小的功能，可能包含重大的权限或部署行为变化。

优先审查后果最重大的行为。格式和命名也重要，但不能因此忽略缺失的数据边界。

从身份追踪到资源

看这个不完整的虚构端点。示例用于说明审查问题，不是生产代码。

async function getInvoice(request) {
  const user = await requireSignedInUser(request);
  return database.invoice.findById(request.params.id);
}

函数获取了已通过身份验证的用户，但没有展示针对发票的授权决定。审查者必须检查其他层是否落实了这项决定。未使用的 user 值值得调查，但单凭这一点，不能证明存在可利用的缺陷。

沿实际系统追踪请求。识别可信的用户身份和所属组织。检查查询如何限制对所请求记录的访问。检查错误行为，以及禁止请求的测试。

不要假设隐藏按钮就能保护 API。调用者可以不使用界面而直接发送请求。也不要假设有效记录 ID 就意味着有权访问。

问清哪些证据能否定这项修改

通过的测试可能使用了管理员测试夹具，或模拟了授权。检查它是否真正覆盖重要边界。在适当情况下，添加使用不同组织和真实授权路径的案例。

对于界面修改，检查渲染结果。检查键盘操作、空状态、加载行为和错误。类型检查不能证明对话框能够通过键盘使用。

对于依赖修改，验证其必要性。审查版本、许可证和安全发现。不要仅因为智能体在任务中生成了某项无关升级，就接受它。

保持审查独立

第二个模型可以发现有价值的问题，也可能重复实现中的假设。为审查者提供要求和 diff，避免事先告诉它修改已经正确。

要求每项发现指出具体失败路径和相关代码。对缺乏证据的警告，应作为待调查问题处理。在重要判断得到证据支持前，自信的批准也只是另一种意见。

人工审查仍然是一项涉及责任的决定。审查者应充分理解修改，能够解释其行为、风险和验证情况。如果 diff 过大，就缩小范围，或拆分成可审查的修改。

针对最终修订完成审查

修正后，重新运行受影响的检查。检查修正是否引入新问题。按照代码仓库策略，确保要求的审查适用于最终修订版本。

用行为和证据说明接受决定。记录剩余限制，并明确负责人和下一步行动。不要把尚未解决的问题转述成“所有检查均已通过”。

检查真实修改前，先用代码审查练习训练识别缺失的决定。