AI 编码评审模板

合并 AI 生成代码之前，用这份模板把 diff 和规格对照起来，而不是只判断代码看起来是否合理。

ai-coding-review.md

# AI Coding Review

Spec:
Agent or tool:
Reviewer:
Date:

## Scope Check
- Allowed files:
- Files changed:
- Out-of-scope changes:

## Spec Alignment
- Acceptance criteria satisfied:
- Criteria missing:
- Behavior added outside the spec:

## Evidence
- Tests added or updated:
- Test command:
- Manual check:
- Logs or screenshots:

## Review Decision
- Approve | Request changes | Split PR
- Follow-up owner:
- Notes:

什么时候使用这份模板

代码由 AI 助手或编码代理生成。
diff 修改了请求范围之外的文件。
评审者需要区分有用实现和规格外行为。
团队想为生成代码建立可重复门禁。

填好后应该是什么样

模板只有在写入真实决策、负责人和证据后才有价值。下面是一个可评审的片段。

## Scope Check
- Allowed files: services/refunds/*, tests/refunds/*
- Files changed: services/refunds/retry.ts, tests/refunds/retry.test.ts
- Out-of-scope changes: none

## Spec Alignment
- AC-2 重放幂等：已满足
- 规格外行为：无

实现前先检查这些点

修改文件符合允许列表，例外有说明。
每个新增行为都能回到规格。
测试覆盖验收标准，而不是只测实现细节。
无关重构被删除或拆成新任务。

弱写法 vs 强写法

弱写法

AI 写的代码看起来不错，测试也过了。

强写法

diff 只修改允许文件，AC-2 映射到 retry.test.ts，没有新增规格外渠道行为，并且 npm run test -- refunds 本地通过。

FAQ

可以相信 AI 的测试总结吗？

不应该只相信总结。模板要求写出命令和证据，让评审者能复现或检查。

多出来的行为怎么办？

删除、拆成新规格，或先更新当前规格再合并。

非 AI 代码能用吗？

可以。它也适合大 PR 或高风险改动，只是特别针对 AI 漂移。

编辑说明

这份模板面向 spec-driven development 工作流，示例用于展示结构，不代表特定公司的内部流程。

作者: Daniel Marsh
编辑政策: 我们如何审阅和更新内容

建议把它放在仓库的 /docs/specs/ 或 /.specs/ 下，并在实现过程中持续更新。最后更新：2026 年 5 月 11 日。