让 AI 做一次像样的代码评审

这篇适合谁 / 不适合谁

适合：

• 自己写完想先过一遍再提交给人 review
• PR 在几十到几百行之间（超过 500 行建议拆）
• 团队还没有统一的 review 清单，需要一份基线

不适合：

• 期望它替代安全审计：AI 能发现明显的注入和越权，发现不了业务逻辑漏洞
• 改动全是自动生成的代码（protobuf、lockfile、migration 脚手架）：先排除再评审
• 想要它判断架构对不对：那是设计评审，不是代码评审

开始前准备什么

1. 只 diff，不要整个仓库。用 git diff main...HEAD 或 PR 的 diff。
2. 一句话说清意图：这个改动要解决什么问题。没有这句，AI 只能做语法层面的检查。
3. 跑一遍测试，把失败信息一起给 AI（如果有的话）。

操作步骤

1. 装 skill

两个 skill 都来自 obra/superpowers：requesting-code-review 与 receiving-code-review。

git clone --depth 1 https://github.com/obra/superpowers

把这两个目录复制到客户端技能目录：skills/requesting-code-review/、skills/receiving-code-review/。

2. 生成评审请求（而不是直接问"帮我看看"）

用 requesting-code-review 的方式整理这个 PR：

意图：修复订单导出时金额精度丢失（一句话，我提供）
改动范围：services/export.ts、utils/money.ts

输出：
1. 这段改动做了什么（3 行以内）
2. 风险点：按"会坏 / 会让人看不懂 / 见仁见智"三档分类，只保留前两档
3. 我希望 reviewer 重点看的 2 个地方
不要提风格建议，不要提"可以考虑加注释"这类泛泛意见。

重点是第 2 条的分档和最后那句"不要提风格建议"。

3. 跑一轮真正的代码评审

下面是 diff。只报两类问题，每条给出文件:行号和触发条件：

A. 会坏：空值/边界/并发/异常路径/资源泄漏/错误的错误处理
B. 会让人看不懂：命名与实际行为不符、隐含前提、缺少必要的失败说明

要求：
- 每条都要写"什么情况下会出问题"
- 不确定的标 [存疑]，不要编
- 不要报风格、不要报性能猜测、不要报"建议加注释"
- 如果只有 1 条，就只写 1 条，不要凑数

diff:
（粘贴）

会凑数是模型的默认行为，所以最后那句必须写。

4. 收到意见后先分档

把评审意见丢回去，用 receiving-code-review 的思路过滤：

把上面的评审意见分成三类：
1. 必须改（有明确的失败路径）
2. 需要我确认（依赖我没提供的上下文，列出它缺什么信息）
3. 可忽略（风格偏好、与本次改动无关）
对第 2 类，直接告诉我你需要我补充什么上下文。

第 3 类直接扔掉，不要为了让 AI 满意而改代码。

5. 改完让它自己验证

如果改动涉及页面行为，用 webapp-testing 跑一遍：

启动本地服务，用浏览器验证三条路径：正常下单、金额为 0、导出空列表。
每条给出截图和控制台报错（如果有）。

会踩的坑

FAQ

AI 评审能替代同事 review 吗？

不能，但能替代"提交前的自查"。它擅长穷举边界，不擅长判断这个改动是否该做。

为什么它总说"建议加注释"？

因为这是最安全的输出。在提示词里显式禁止，并要求每条都写触发条件，输出质量会明显上升。

能自动跑在 CI 上吗？

可以，但建议只让它报 A 类（会坏）问题，并且不阻断合并。自动评审一旦误报太多，很快就会被团队忽略。

它对什么语言最有效？

强类型语言（TypeScript、Go、Rust、Java）效果最好，因为类型信息本身就是上下文。Python 这类动态语言要额外给它函数签名和调用方。

评审意见和我相左怎么办？

让它给出触发条件。给不出具体失败路径的，基本就是偏好问题。