先看范围
先检查变更文件，再看风格或实现细节。
按这个顺序评审
再看标准
把每个保留行为映射到一条验收标准。
最后看证据
每条标准都要有测试、截图、日志、指标或手工检查。
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。
真实场景：AI 生成的用户搜索 PR
编码代理为后台页面添加账号搜索。diff 看起来有帮助，但它同时修改了共享查询 helper、改变默认排序，并在一个分支里移除了 tenant filter。
第一轮先看什么
先看变更文件列表，再读实现细节。共享 helper 和 tenant filter 是范围问题，不是代码风格问题。
证据映射
每个保留行为都要指向一条标准：空查询、租户隔离结果、延迟预算和权限拒绝。
评审结论
只有恢复 tenant filter 证据后才批准搜索行为；排序清理应拆到后续 spec，而不是顺手合并。
怎样评审生成 PR 而不被风格带偏
最安全的 AI PR 评审，第一轮应该故意无聊。Reviewer 先确认 diff 是否留在范围内、契约是否保持、证据是否存在，然后再讨论命名、格式、架构偏好或生成代码是否写得漂亮。
先打开变更文件列表
不要一上来读代码正文。先把文件列表和 spec 的允许写入范围对比，每个意外文件都标成问题。这样能避免 reviewer 先喜欢上一段看似有用的实现，随后忽略它已经越界。
要求证据，不要接受自信
AI 的最终总结通常听起来很确定。评审要看具体证明：命令输出、测试用例名、UI 状态截图、迁移日志、指标或手工 QA 记录。证据缺失时，正确结论是要求修改，而不是继续争论它“应该没问题”。
把漂移拆成新 spec
有些额外行为确实有价值，但仍然应该拆出去，除非当前 spec 已经更新并重新评审。悄悄合并额外行为，会让 agent 学到 review 等于允许扩范围，之后的 PR 会更难判断。
落地前的评审问题
AI 编码 PR 评审清单 不是只给 AI 看的一段提示词。它应该帮助人判断：这个任务是否已经可以进入实现、谁负责未决问题、哪些证据会随 PR 留下来。下面这些问题适合放在团队约定、PR 模板或实现前评审里。对搜索和广告审核来说，这类可复用、可执行的说明也能证明页面不是只有模板，而是有真实方法，并提高用户停留、复访、收藏和分享。
谁拥有决策？
在使用 AI 编码 PR 评审清单 前，先写清哪个人或角色可以批准范围变化。没有 owner 的开放问题会变成 AI 自行补空白的入口，也会让 reviewer 在合并前才发现产品、数据或权限决策还没有被确认。
什么会阻塞实现？
把必须回答的问题和可以带着风险继续的问题分开。阻塞项通常包括公开 API、数据迁移、权限边界、支付行为、回滚方案和用户可见文案。只要这些还没明确，就不要让 agent 直接生成生产代码。
PR 会留下什么证据？
最终 PR 至少应该链接 ai-pr-review.md、列出变更文件、说明跳过的检查，并把测试、截图、日志或指标映射回验收标准。否则未来的人只能读 diff 猜当时为什么这样做。
这些情况应退回
行为没有映射
diff 增加了行为，但没有对应验收标准、非目标例外或已批准后续任务。
测试不可复核
PR 只说测试通过，没有命令、相关用例或 CI 结果。
悄悄改契约
响应字段、schema、权限或事件 payload 未经规格允许就发生变化。
相关资源
把这份清单和 spec、验收标准搭配使用，评审才有事实来源。
AI PR 评审 FAQ
可以相信 AI 的最终总结吗？
不能直接相信。必须用命令、测试、截图、日志或 diff 证据支持。
如果额外行为很有用怎么办？
拆成后续 spec，或先更新当前 spec 再合并，不要藏在同一个 PR 里。
评审应该先看代码风格吗？
不要。先看范围、标准、证据和契约；边界清楚后再看风格。
生成 PR 到来时，先审规格，再审证据，最后审代码。
复制评审模板