用故事讲懂「请求代码审查」requesting-code-review：一个超能力助手的秘密想象一下，你正在搭建一个巨大

想象一下，你正在搭建一个巨大的乐高城堡。你搭完一层，正准备往上搭第二层——这时候，最好的朋友小明过来说：“等一下！你第一层有个柱子歪了，要是继续往上搭，整座城堡会塌的！”

你低头一看，果然！赶紧拆掉重来，花了 5 分钟就修好了。如果等到城堡搭到 10 层高才发现，那就要拆好几个小时——甚至整个项目报废。

代码审查（Code Review） 就是那个“提前发现歪柱子”的过程。而 requesting-code-review 这个 Skill，是一个能自动帮你请来“资深建筑师”的工具，它不打扰你现在的思路，快速检查你刚刚写的代码，指出哪里危险、哪里可以更好。

1. 实现原理：为什么它这么聪明？

1.1 核心思想：独立、聚焦、无历史包袱

我们看 SKILL.md 里这句话：

The reviewer gets precisely crafted context for evaluation — never your session's history.

翻译成人话：审查员（subagent）只看你的“代码成品”和“计划要求”，完全不看你写代码时“想了什么、尝试了什么、失败了什么”。

这样做的好处：

公正：不因为你是新手就降低标准，也不因为你知道内部坑就放过漏洞。
高效：审查员不需要加载你几万字的聊天记录，只需要看你给的 git diff 和需求文档。
安全：你的思考过程（可能包含敏感信息）不会泄露给审查员。

1.2 技术实现三步走

获取两个 git 提交的 SHA 值
BASE_SHA 是“开始改代码之前的版本”（比如上一次任务完成后的 commit），
HEAD_SHA 是“你刚刚写完代码后的最新版本”。
这两个 SHA 之间的 git diff 就是你要审查的所有改动。
用 Task 工具召唤 subagent
主 AI（你正在对话的那个）调用一个叫 superpowers:code-reviewer 的子代理。调用时，会把下面这些内容填进 code-reviewer.md 模板里：
- {WHAT_WAS_IMPLEMENTED} – 你实现了什么功能（一句话概括）
- {PLAN_OR_REQUIREMENTS} – 需求文档或计划片段
- {BASE_SHA} 和 {HEAD_SHA}
- {DESCRIPTION} – 稍微详细的描述
subagent 执行检查并返回结构化报告
审查员会运行 git diff --stat 和 git diff 拿到所有改动，然后按照 Checklist 里的代码质量、架构、测试、需求满足度、生产就绪度逐项打分，最后输出一份带 Critical / Important / Minor 等级的清单，以及一个明确的结论： “Ready to merge” 、 “With fixes” 还是 “No” 。

2. 最佳用法：什么时候用、怎么用、用完后怎么办

2.1 什么时候必须用？（来自 `SKILL.md` 的“Mandatory”）

每完成一个子任务（比如你用 subagent 做了 Task 1、Task 2、Task 3）→ 做完一个就 review 一次。
完成一个大的功能特性后。
准备合并到主分支（main）之前。

为什么这么频繁？因为越早发现“歪柱子”，修复成本越低。Task 1 歪了，马上改；Task 2 就会在正确的基底上搭建，不会浪费半天时间。

2.2 怎么用？（实操步骤）

假设你刚刚完成了“添加用户登录验证”这个任务，现在想审查一下。

第一步：获取 SHAs

BASE_SHA=$(git rev-parse HEAD~1)   # 上一个 commit 的 SHA
HEAD_SHA=$(git rev-parse HEAD)      # 当前最新的 commit SHA

第二步：调用 Task 工具
（在 AI 对话中，你不需要手动写 JSON，只需要说出类似下面的话，AI 会自动帮你调用）

“请使用 requesting-code-review Skill 审查我刚刚完成的登录验证功能。
需求见 docs/auth-spec.md，
BASE_SHA 是 a1b2c3d，
HEAD_SHA 是 e4f5g6h，
简短描述：增加了 JWT 登录和注册接口。”

实际上，系统会生成类似这样的调用：

Task(
  subagent_type="superpowers:code-reviewer",
  prompt="按照 code-reviewer.md 模板审查... 
         WHAT_WAS_IMPLEMENTED=用户登录验证
         PLAN_OR_REQUIREMENTS=docs/auth-spec.md
         BASE_SHA=a1b2c3d
         HEAD_SHA=e4f5g6h
         DESCRIPTION=增加 JWT 登录和注册接口"
)

第三步：拿到报告，马上行动
审查员会返回一个格式工整的报告，包含：

Strengths（好的地方，表扬）
Issues（分三个严重等级）
Recommendations（改进建议）
Assessment（最终结论）

你作为开发者：

Critical 问题 → 必须立刻修复，否则不能继续。
Important 问题 → 强烈建议修复后再推进。
Minor 问题 → 可以记下来，以后有空再优化。

2.3 典型工作流：结合“子代理驱动开发”

SKILL.md 里提到一个黄金模式：

Subagent-Driven Development: Review after EACH task. Catch issues before they compound.

意思是：
你拆解一个大功能为 3 个 Task。

做 Task 1 → 立刻 review → 如果有 Critical，修掉 → 再 review 直到通过。
做 Task 2（基于 Task 1 的正确代码）→ 立刻 review → …
做 Task 3 → review → 全部通过后合并。

这样做，永远不会出现“最后发现 Task 1 的歪柱子导致 Task 2、3 全部要重写”的惨剧。

3. 时序图：一次完整的代码审查调用过程

下面用 Mermaid 画一个时序图，展示你（用户）、主 AI、subagent、git 之间的交互：

一次完整的代码审查调用过程.png

注意：这个时序图中，用户只跟主 AI 对话一次，主 AI 会自动去调用 subagent，用户不需要手动跑 git 命令（当然你也可以手动跑，但主 AI 会代劳）。

4. 常见错误和正确姿势

❌ 错误做法

跳过审查：“这个改动很小，不用 review 了。” → 结果：小 bug 变成生产事故。
把所有问题都标为 Critical：让 reviewer 失去判断力，最后什么都不敢合并。
看到 Important 问题也不修：继续往下写，最后技术债越滚越大。
跟 reviewer 吵架：reviewer 说“缺少错误处理”，你说“我觉得不需要”。 → 正确做法：用技术理由讨论，或者直接加代码证明。

✅ 正确做法

每次完成任务，不管多小，都请求一次 review（习惯养成）。
认真对待每个等级的问题：Critical 立即停；Important 在本轮修复；Minor 记在 TODO 里。
如果 reviewer 错了，礼貌地指出：“这里其实有 try-catch，在第 42 行，你可能看漏了。” → reviewer 会更新判断。
审查通过后，立刻合并或继续下一个任务，保持节奏。

5. 一个小彩蛋：为什么叫“superpowers”？

因为这套工具给你带来的能力远超普通开发者：

提前预知风险（像蜘蛛感应）
自动召唤专家（像蝙蝠侠呼叫阿尔弗雷德）
不被历史干扰（像黑衣人记忆消除器，只看结果）

而 requesting-code-review 就是其中最常用的“呼唤盟友”技能。用好它，你写的代码会越来越稳，同事也会觉得你特别靠谱 —— 其实只是因为你每次搭乐高之前，都让“建筑师精灵”帮你检查了柱子。

最终总结一句话：

完成一个任务 → 立刻请求代码审查 → 根据 Critical/Important 修复 → 继续下一个任务。
就像吃一口饭，嚼碎了再咽，永远不会噎着。

现在，去试试对你的下一个 commit 调用这个 Skill 吧。 🚀

用故事讲懂「请求代码审查」requesting-code-review：一个超能力助手的秘密