如果你在用 Claude Code 做开发，superpowers-skills 是 superpowers 插件的社区技能库，其中有两个"AI 代码评审"技能特别值得掌握：requesting-code-review（请求评审）与 receiving-code-review（接收反馈）。前者让 AI 主动派发评审子代理把关代码，后者教 AI 如何技术化地回应评审意见——不谄媚、不盲从，必要时优雅回怼。本文带你把这一整套流程跑通。🎯

一、AI 代码评审的完整闭环：两个技能各司其职

superpowers-skills 把"评审"拆成了攻守两端：

两个技能搭配使用：第一个负责"把评审请进来"，第二个负责"把反馈接住、接稳"。

二、第一件：如何向 AI 请求代码评审

何时必须请求评审？

根据 requesting-code-review 技能，评审分"强制"与"可选"两档：

强制场景（Mandatory）：

• 子代理驱动开发（subagent-driven development）中，每个任务完成后
• 完成一个主要功能后
• 合并进主分支之前

可选但高性价比的场景：

• 卡住了（换个新视角）
• 重构之前（建立基线检查）
• 修复复杂 bug 之后

请求评审的三步操作

整个流程并不复杂，核心步骤在 SKILL.md 中有完整定义：

第 1 步：拿到两个 commit SHA

BASE_SHA=$(git rev-parse HEAD~1) # 起始提交（或 origin/main） HEAD_SHA=$(git rev-parse HEAD) # 结束提交

第 2 步：派发 code-reviewer 子代理

使用 Task 工具加载评审模板 code-reviewer.md，填入 5 个占位符：

• {WHAT_WAS_IMPLEMENTED}— 你刚实现了什么
• {PLAN_OR_REQUIREMENTS}— 它本应做什么
• {BASE_SHA}/{HEAD_SHA}— 评审的提交区间
• {DESCRIPTION}— 一段简要总结

第 3 步：按严重程度分级处理反馈

• Critical（严重）→ 立即修复
• Important（重要）→ 继续推进之前必须修复
• Minor（次要）→ 记录下来，日后再说
• 评审员错了→ 带着技术推理去反驳（push back）

评审子代理会交付什么？

模板文件 code-reviewer.md 规定了严格的输出格式，确保评审结果可执行：

1. Strengths（亮点）：具体到文件行号，不空夸
2. Issues（问题）：按 Critical / Important / Minor 三级分类，每条都要给出文件:行号、问题原因、修复建议
3. Recommendations（建议）：质量、架构、流程层面的改进
4. Assessment（结论）：明确回答 "Ready to merge? Yes / No / With fixes"

模板还立下规矩：不许没检查就喊 "looks good"，不许把吹毛求疵标成 Critical，不许含糊其辞（比如"改进一下错误处理"这种空话）。

三、第二件：收到反馈后，如何优雅地"回怼"

很多 AI 助手接到评审意见会立刻说 "You're absolutely right!" 然后闷头照做——这正是 receiving-code-review 技能 最想纠正的毛病：代码评审需要的是技术评估，而不是情绪表演。

六步响应模式：READ → IMPLEMENT

技能中给出的标准响应流程（SKILL.md）：

1. READ— 完整读完反馈，先别反应
2. UNDERSTAND— 用自己的话复述要求（不清楚就问）
3. VERIFY— 对照代码库实际情况核实
4. EVALUATE— 这条建议对当前代码库技术上是否成立
5. RESPOND— 技术性确认，或带理由地反驳
6. IMPLEMENT— 一次只改一条，每改一条都测试

禁用回复清单：别让 AI 当"应声虫"

技能明确列出了绝不可用的回复（SKILL.md）：

技能的原话很直接：当你发现自己正要写 "Thanks" 时——删掉它，直接陈述修复内容。

何时该回怼？怎么怼？

该回怼的六种情况（SKILL.md）：

• 建议会破坏现有功能
• 评审者缺乏完整上下文
• 违反YAGNI原则（给没人用的功能加戏）
• 对当前技术栈技术上不成立
• 存在遗留代码/兼容性约束
• 与你（人类）已做的架构决策冲突

回怼的正确姿势：用技术推理，而不是防御性情绪；提出具体问题；引用能证明现状正确的测试和代码；涉及架构争议时拉上人类拍板。

💡 技能里还埋了一个彩蛋：如果 AI 觉得回怼起来"不太自在"，它可以发一句暗号 "Strange things are afoot at the Circle K" 来示意——这个细节让整套机制多了一分人味。

反馈看不明白？先停下来问

一个高频陷阱是"半懂不懂就先做一半"。技能的规定是（SKILL.md）：

只要有任何一条不清楚：STOP，什么都先别改，先就模糊条目请求澄清。因为各条目之间可能相关，部分理解 = 错误实现。

正确示范："我理解第 1、2、3、6 条，第 4 和 5 条在动手前需要澄清。"

YAGNI 检查：评审员要求"实现完整功能"时

如果评审员建议把某个端点"实现得专业一点"（加数据库、日期过滤、CSV 导出……），正确动作是先grep代码库确认实际使用情况：

• 没人调用→ 反问："这个端点没有任何调用方，直接删掉（YAGNI）吗？"
• 有人调用→ 再谈完善

背后的规则是：你和评审员都向用户汇报——不需要的功能就不要加。

改错了自己先前的回怼？体面地认错

如果你反驳了评审者、后来验证发现自己错了，技能给出的标准模板是：

"You were right — I checked X and it does Y. Implementing now."

只陈述事实、立刻纠正、不写长篇道歉、不辩解当初为什么反驳。

四、实战对比：同一句反馈的两种回应

技能文档中的真实示例（SKILL.md）最直观：

评审员说："把遗留代码删掉"

❌ 表演式认同：

"You're absolutely right! Let me remove that..."

✅ 技术验证式回应：

"查了一下……构建目标是 10.15+，而这个 API 需要 13+。要兼容 13 以下版本就必须保留遗留路径。不过当前实现里 bundle ID 写错了——是修掉它，还是干脆放弃 13 以下的支持？"

同一个问题，后者既核实了代码事实，又给出了可执行的选项——这就是"优雅回怼"的含金量。

五、把两件套放进你的工作流

这两个技能不是孤立存在的，它们与协作类技能形成了完整链条（见 skills/collaboration/）：

• 每个任务之间：subagent-driven-development 规定"新子代理执行任务 + 任务间代码评审"，评审问题在下一任务开始前就被拦下
• 合并之前：requesting-code-review 的强制场景覆盖 "before merge to main"
• 收尾阶段：finishing-a-development-branch 会先验证测试全绿，再给出合并 / PR / 清理选项
• 找不到技能时：用 find-skills 脚本按关键词过滤，快速定位

六、小结：三条带得走的规则

1. 评审要早、要勤：任务完成后、大功能完成后、合并前，主动派发 code-reviewer，按 Critical / Important / Minor 分级处理
2. 先验证，再实现：收到反馈先 READ → VERIFY → EVALUATE，不理解的条目先问清楚再动手
3. 技术正确 > 社交舒适：拒绝谄媚式认同；评审错了就用代码和测试回怼，自己错了就一行话体面认错

掌握这套"AI 代码评审两件套"，你的 Claude Code 工作流就同时拥有了质量闸门和理性防线——代码评审不再是一场客套表演，而是扎实的技术对话。🚀