审阅检查点清单：只报能行动的

对照一套固定检查点审 AI 的产出；只报可行动的 finding，别拿风格和假设性问题凑数。

审 AI 写的代码，最怕的是「凭感觉觉得哪里不对劲」然后一行行找。更快、更稳的做法是：照着一张固定清单打，有就是有，没有就是没有。这样既不漏、也不过度。

读完你能回答：

• 审 AI 产出，固定要点有哪些？
• 什么才算「能行动的 finding」？
• 怎么避免在 review 上过度投入？

一张固定检查单

① 对照接收标准

• 前面定义的完成标准，逐条打钩
• 「没达到」就直接判退，别在细节上绕

② 扫结构 + 数据流

• 改动改了哪几处、影响哪些调用方
• 有没有越界改了你不让动的地方

③ 查缺口与边界

• 输入校验、异常处理、权限检查
• 「该处理、但没处理」的地方

④ 依赖审查

• 有没有引不认识/不必要的重依赖

⑤ 收尾给结论

• 过 / 需改 / 退回，附上位置和具体建议

只报能行动的 finding

只报开发者能采取行动的问题：

• 位置 + 具体建议 → 报
• 风格偏好、假设性设计（"如果未来需求变了"）→ 不报
• 无法验证的担忧 → 不报

一条 finding 能不能让 AI 或你「立刻动手改」？能，才值得报；只是嘴上担心，先憋着，别污染反馈清单。

别过度审

• 不质疑已经定案的架构（那是设计评审的事，不是代码审）
• 不给完美主义挑刺
• 把精力留给「会出事」的 5%，别 100% 都当重点 google-patterns

审到第几轮该停

AI 写、AI 审的循环有个特点：两边都很勤快，于是能一直互相喂活。有团队实测过一个 PR 过夜跑了五十多轮；把「评审器反复标记的位置」逐个追查来源，发现约六成是第一轮就已经存在的旧代码——评审器不是在发现新 bug，只是每轮多翻出几个旧的。cc-review

所以「多审几轮总没坏处」是错觉。让它收敛有四条具体做法：

• 设轮次上限。比如三轮之后停下来，要求作者退一步重新考虑方案，而不是继续在评论里小修。
• 前几轮之后只审增量。第一次看完整 diff，之后只看这次新增的部分，避免反复重读同一片代码。
• 把同类问题标成一类，让作者一次改完所有实例，而不是每条各改一处。
• 不重复发布已发过的发现。上一轮提过、作者已驳回并说明理由的，不再出现。

判据不是「审了几轮」，而是每轮新增的有效发现是否在变少。如果第三轮还在大量报第一轮就该发现的问题，说明问题不在评审器，在源头的结构或需求。

按风险决定谁来审

不是所有改动都值得同样的人工投入。可行的分档是按改动本身定，而不是按作者是谁定：

配套两条纪律：审批绑定到具体提交——出现无法担保的新提交（agent 推的、人工解过冲突的）之后，原来的批准失效，要重新批；机器人的批准不能顶替必需的人工位，它可以清掉低风险变更，但不能填人的名额。

这套分档的价值在于把人的注意力换到真正需要判断的地方：该不该做、有没有碰高风险路径、架构会不会被人照着抄、证据够不够。至于「这段代码写得好不好」，交给专门做这件事的那层检查。

审完分两路

• 通过的 → 进入验证环节：一条命令跑全分层验证
• 没通过的 → 退回让 AI 改，改完再审，直到过

多轮审查要记账。每一轮报了哪些问题、哪些改了、哪些你驳回了、为什么驳回，都写下来；下一轮先读上一轮，别把已经驳回过的问题再提一遍。历史轮次不要改写——「第几轮放弃了什么」和「改了什么」一样，是下一步唯一用得上的信息。

审阅是「判断」环节的落地，验证是「证据」环节的落地。审完，就该让证据替你说话。