Appearance
让 AI 在同一个会话里"自我审查"存在一个根本缺陷：审查者和被审查者共享完整的对话历史，包括所有的推理过程、设计取舍和已知妥协。真正有效的代码审查需要独立视角——requesting-code-review skill 通过派发独立子代理来实现这一点，子代理只获得你精心构建的上下文，不受当前 session 历史影响，审查结果更接近真实的外部视角。
requesting-code-review：让独立子代理审查你的代码
为什么"自我审查"不够用
假设你刚刚用 AI 完成了一个功能模块，现在想让它审查一下代码质量。你在同一个对话窗口里说："帮我 review 一下刚才写的代码。"
表面上这是一次代码审查，实际上审查者和被审查者是同一个实体，拥有完全相同的背景信息：写代码时做的每一个决策、妥协过的每一处细节、当时的注意力焦点。在这种情况下，"审查"很容易变成"合理化"——找理由解释为什么现有代码是对的，而不是找出它真正的问题。
真正有价值的代码审查来自独立视角。这个视角不了解你的实现思路，只看代码本身，只看它是否符合要求，只关注它的质量、架构和潜在问题。
requesting-code-review 这个 skill 就是为了创造这种独立性。
核心机制：隔离上下文的子代理
这个 skill 的核心设计是把 code reviewer 作为一个独立的子代理（subagent）派发出去，通过 Task 工具启动。
关键在于：子代理不继承当前 session 的对话历史。
它获得的上下文完全由你构建和控制，包括：
- 你实现了什么
- 实现的目标/需求是什么
- 要审查哪个 git 区间的代码（base SHA 到 head SHA）
- 简短的背景描述
就这些。子代理看不到你们之前讨论了什么、尝试了什么方案、放弃了哪些选项。它看到的是一个陌生的代码差异，需要从中评估代码质量。这和让一个真实的同事审查代码的情况更接近。
操作流程
第一步：获取 git SHA 范围
bash
BASE_SHA=$(git rev-parse HEAD~1) # 或者用 origin/main
HEAD_SHA=$(git rev-parse HEAD)如果要审查多个提交，BASE_SHA 取最早的那个提交的前一个：
bash
BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')第二步：派发 code-reviewer 子代理
使用 Task 工具，类型为 superpowers:code-reviewer，填入以下信息：
WHAT_WAS_IMPLEMENTED：你刚做了什么（一两句话）PLAN_OR_REQUIREMENTS：这个功能应该做什么（可以引用需求文档或 plan 文件）BASE_SHA：起始提交HEAD_SHA：结束提交DESCRIPTION：简短说明，帮助 reviewer 快速定向
子代理会执行 git diff --stat BASE_SHA..HEAD_SHA 和 git diff BASE_SHA..HEAD_SHA，基于实际代码差异进行审查。
第三步：处理审查结果
子代理会按严重程度分类返回问题：
| 级别 | 含义 | 处理方式 |
|---|---|---|
| Critical | 安全漏洞、数据丢失风险、功能严重错误 | 立即修复，不继续下一步 |
| Important | 架构问题、缺失功能、错误处理不完整 | 本次修复 |
| Minor | 代码风格、命名、文档 | 记录，后续处理 |
Critical 和 Important 问题处理完之后，可以继续推进；Minor 问题不必阻塞进度。
如果你认为 reviewer 的某个判断有误，用技术理由反驳，给出代码或测试作为证据。这是正常的工程讨论，不是要无条件接受所有反馈。
审查者看什么
子代理拿到代码后，会从以下维度检查：
代码质量
- 关注点分离是否清晰
- 错误处理是否完整
- 类型安全（如果适用）
- DRY 原则是否遵守
- 边界情况是否考虑
架构
- 设计决策是否合理
- 是否有可扩展性考量
- 性能影响
- 安全隐患
测试
- 测试是否在测真实逻辑而不是 mock
- 边界用例覆盖
- 所有测试是否通过
需求符合度
- 是否满足计划中的所有要求
- 实现是否符合规格
- 是否有范围蔓延
- 破坏性变更是否有文档
什么时候触发代码审查
必须触发
- 每个开发任务完成后（子代理驱动开发模式下）：在进入下一个任务之前审查，问题不会累积
- 重要功能完成后：功能较大时，早发现早修复
- 合并到主分支前：最后一道关口
推荐触发
- 卡住了需要新视角时：换一个不带背景包袱的视角看问题
- 重构之前：建立基线，了解现有代码的问题点
- 修复复杂 bug 之后：确认修复没有引入新问题
可以跳过
- 极其简单的单行修复（但不要以"简单"为由习惯性跳过）
为什么早审查比晚审查好
一个常见的做法是"全部做完再统一 review"。这种方式的问题是：如果第一个任务的架构有问题，后面所有建立在它之上的代码都会受影响，统一审查时需要改动的范围会大得多。
每完成一个任务就审查，问题在还小的时候就被发现，修复成本最低。这不是多了一个步骤，而是减少了后续返工的概率。
一个具体例子
假设刚完成了任务 2：为会话索引添加验证和修复函数。
bash
# 获取 SHA 范围
BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
HEAD_SHA=$(git rev-parse HEAD)
# 派发子代理，填入：
# WHAT_WAS_IMPLEMENTED: 会话索引的验证和修复函数
# PLAN_OR_REQUIREMENTS: docs/plans/deployment-plan.md 中的任务 2
# BASE_SHA: a7981ec
# HEAD_SHA: 3df7661
# DESCRIPTION: 添加了 verifyIndex() 和 repairIndex()，覆盖 4 种问题类型子代理返回：
Strengths:
- 架构清晰，verifyIndex 和 repairIndex 分离合理
- 真实的行为测试，没有过度 mock
Issues:
Important:
1. 缺少进度提示
- indexer.ts:130
- 长时间操作没有进度反馈，用户不知道在等什么
- 建议加 "X of Y" 计数器
Minor:
1. 魔法数字
- indexer.ts:89，硬编码的 100 作为报告间隔
- 建议提取为命名常量 REPORT_INTERVAL
Assessment: Ready to proceed with fixes修复进度提示问题后，继续任务 3。
FAQ
Q: 子代理真的不知道当前 session 的上下文吗？
A: 是的。通过 Task 工具启动的子代理从一个干净的状态开始，它获得的唯一信息是你在任务描述里提供的内容。当前 session 的对话历史对它不可见，这是隔离性的技术保证。
Q: 审查结果太严苛，每次都有一大堆 Important 问题，正常吗？
A: 要看具体问题。如果都是真实存在的架构或功能问题，说明代码确实需要改进。如果 reviewer 把 Minor 问题标成了 Important，用技术理由反驳，说明为什么这个问题在当前场景下没那么严重。代码审查是一个讨论过程，不是单方面接受判决。
Q: 每个任务都触发审查，会不会太慢？
A: 子代理并行运行，不阻塞当前 session 继续思考下一步。审查的时间成本通常远低于后期修复累积问题的成本。如果确实觉得某个任务太小不值得审查，可以把几个相关的小任务合并成一个审查批次。
Q: reviewer 说代码有问题，但我认为它是对的，怎么处理？
A: 把你的理由说清楚。如果有测试证明行为正确，给出测试。如果是设计取舍，解释为什么这个取舍是合理的。reviewer 的判断基于它看到的信息，你有额外的上下文，合理的反驳会让审查更有价值。但要区分"有技术依据的反驳"和"因为改起来麻烦所以不想改"。