生成代码评审

AI 编码 PR 评审清单

不要用“看起来合理”来评审 AI 生成代码。应该把 diff 和规格、验收标准、允许文件、证据逐项对照。

更新日期：2026-05-25

ai-pr-review.md可复制

评审顺序：
1. 范围
2. 标准映射
3. 证据
4. 契约
5. 漂移

结论：
- 通过
- 要求修改
- 拆分 PR

按这个顺序评审

先看范围

先检查变更文件，再看风格或实现细节。

再看标准

把每个保留行为映射到一条验收标准。

最后看证据

每条标准都要有测试、截图、日志、指标或手工检查。

AI 评审需要不同的第一轮

AI 生成 diff 常把有用代码和悄悄扩张混在一起。普通的风格优先评审容易因为有用部分看起来正确而漏掉额外行为。

第一轮应该机械化：改了哪些文件、契约是否保持、标准是否满足、证据是否存在。之后才值得讨论命名、结构和实现品味。

Reviewer 停止信号

diff 触碰了允许写入范围外的文件。
某条验收标准没有对应证据。
agent 未经批准修改公开契约。
PR 把重构和目标行为打包在一起。
最终回复没有说明已知缺口或跳过的检查。

可复制 PR 评审清单

批准生成代码前，把这段放进 PR 描述或 reviewer 评论。

ai-pr-review.md

# AI 编码 PR 评审

Spec:
Agent/tool:
Reviewer:

## 1. 范围检查
- 允许文件：
- 实际修改文件：
- 越界改动：

## 2. 验收映射
- AC-1：
- AC-2：
- AC-3：

## 3. 证据
- 新增或更新测试：
- 测试命令和结果：
- 手工检查、截图、日志或指标：

## 4. 契约检查
- API shape 保持：
- DB schema 保持或迁移已评审：
- 事件、权限、错误码保持：

## 5. 结论
- Approve | Request changes | Split PR
- 后续负责人：
- 备注：

填好的示例

强评审记录能直接看出 agent 有没有遵守原始规格。

filled-example.md

## 范围检查
- 允许文件：services/refunds/*, tests/refunds/*
- 实际修改：services/refunds/retry.ts, tests/refunds/retry.test.ts
- 越界改动：无

## 验收映射
- AC-1 超时后重试一次：retry.test.ts "retries once"
- AC-2 连续超时响应：retry.test.ts "keeps retryable failure"
- AC-3 非法签名：现有签名测试仍通过

## 证据
- npm test -- refunds
- 手工：PR diff 未修改 provider API

## 结论
- 通过，后续补一个生产指标告警 spec。

这些情况应退回

行为没有映射

diff 增加了行为，但没有对应验收标准、非目标例外或已批准后续任务。

测试不可复核

PR 只说测试通过，没有命令、相关用例或 CI 结果。

悄悄改契约

响应字段、schema、权限或事件 payload 未经规格允许就发生变化。

AI PR 评审 FAQ

可以相信 AI 的最终总结吗？

不能直接相信。必须用命令、测试、截图、日志或 diff 证据支持。

如果额外行为很有用怎么办？

拆成后续 spec，或先更新当前 spec 再合并，不要藏在同一个 PR 里。

评审应该先看代码风格吗？

不要。先看范围、标准、证据和契约；边界清楚后再看风格。

生成 PR 到来时，先审规格，再审证据，最后审代码。

复制评审模板