一句话

合并前的五轴评审：correctness、readability、architecture、security、performance；发现按 Critical/Required/Optional/Nit/FYI 分级。

何时用

• 适合：任何改动进主干前；评审自己、别的 agent 或人的 diff、PR，甚至贴进来的内联 diff。
• 不适合：改动还没自测过；纯文档或配置变更可简化为抽查。

怎么用

评审一下当前分支的改动，按严重度分级给意见

1. 先懂上下文：读 spec、关联 ticket、被改代码的上下游。
2. 先评审测试再评审实现；测试不够的改动先打回。
3. 按五轴过实现，逐轴给结论。
4. 发现分五级：Critical: 阻断合并、无前缀即 Required 必改、Optional:/Consider: 建议、Nit: 小疵、FYI 仅参考。
5. 验证「验证本身」：测试是否真跑了、证据是否可信。

产出

• 一份分级评审意见，按 Review Checklist 模板组织，每条 finding 带轴和级别。

要点与坑

• 换模型复核：Multi-Model Review 让 Model B 审 Model A 的代码，抓单一模型的盲区。
• Change Sizing 把过大的 diff 本身列为问题；超大改动先谈拆分。
• 依赖纪律：新依赖单独审；评审要诚实，不做 yes-machine。

本机版本差异

仓库版在「先评审测试」一步新增变异测试：反转一个新增条件跑套件，仍全绿即记为漏测 finding；本机旧版没有这一步。

关联

• 上游：addy-test-driven-development · 下游：addy-shipping-and-launch · 同类：matt-code-review
• 所属：00-addy-概览 · 工作流：W1-快修、W3-多会话功能