请审, 评审, 收审的完整闭环
请审, 评审, 收审的完整闭环
superpowers 核心技能 · code-review
一句话: 写完代码自我感觉好不算数. 让独立子代理审一遍; 而你收到意见要"先验证再改", 不无脑认错.
场景: 优惠券"核销"功能刚写完
AI 刚写完优惠券核销的代码, 自己说"测试都过了, 没问题". 但核销这种地方最怕隐患: 同一张券会不会被并发用两次? 金额边界对不对? 自己审自己天然有盲区, 合并前得让独立的一双眼睛看一遍.
怎么对 AI 说
请审 —— 给它提交范围和"本应做什么":
用 code-review 审一下刚写的优惠券核销: 派 code-reviewer 子代理, 对照计划(docs/plans/coupon.md)
检查 BASE..HEAD 这段提交, 重点看并发核销和金额边界, 按 Critical / Important / Minor 给问题.
你自己收到审查意见时也有讲究:
| ❌ 差的回应 | ✅ 好的回应 |
|---|---|
| You're absolutely right! 这就改 | (先验证它说得对不对)确实没加锁, 已改: 加了乐观锁 |
| (五条意见)先改我看懂的 | 有一条"幂等"没看懂, 先问清再一起改 |
| 审查说这段删了, 删 | 先 grep 确认这分支真没人走, 再决定删不删 |
反驳要带证据(贴代码 / 测试 / 并发压测结果), 不是嘴硬; 发现自己错了一句话认, 别长篇道歉.
它会怎么跟你走
请审时它取 BASE/HEAD 提交范围, 派一个独立 code-reviewer 子代理(只拿到 SHA 区间和需求, 不被你俩刚才的聊天带偏), 输出"优点 / 问题(分级)/ 总评" —— 比如揪出"核销没做幂等, 并发能重复核销"(Critical). 收审时你按 通读 -> 对照代码验证 -> 技术性回应 -> 一条条改各自测 来走; 改对了只说"Fixed. 加了券号唯一约束", 不说感谢套话.
一句话记住
code-review = 独立子代理评审 + 你理性收审. 像优惠券核销这种有并发/金额隐患的功能, 合并前必须让独立子代理看一眼; 收意见时先验证再改, 别无脑认错也别嘴硬.