代码审查不是走过场。Superpowers的Requesting Code Review技能定义了审查的正确方式：对照计划的独立验证。
为什么需要AI参与代码审查
人会疲劳、遗漏、偏向。AI可以：
- 保持一致性：每次审查标准相同
- 对照计划：不是泛泛的"代码好不好"
- 独立验证：不信任实现者的报告
但AI的审查需要正确的方法。不是"检查一下"，是两阶段的独立验证。
两阶段审查
Superpowers定义两个阶段：
- Spec Compliance：对照实现计划，确认做了要求的事
- Code Quality：检查代码质量、清晰度、风险
顺序重要：先确认内容，再确认质量。因为如果内容错了，质量检查没有意义。
Spec Compliance审查
审查者（独立子代理）收到：
- 任务描述：从计划中提取
- 文件路径：涉及哪些文件
- Spec要求：这个任务应该做什么
审查者不收到：
- 实现者的报告（防止信任）
- 其他审查者的结论（独立判断）
审查者独立阅读代码，对照任务要求：
Task spec: Implement addTodo in todoStore.js
Requirements:
- Function signature: addTodo(text)
- Returns: new task object with { id, text, completed: false }
- Generates unique ID
Reviewer findings:
- Function signature: addTodo(text) ✓
- Returns: { id, text, completed } ✓
- ID generation: uses incrementing counter ✓
- Extra feature found: logs "Task added" (not in spec)
Issue severity: Low (logging is benign but not requested)
审查者发现问题：添加了未请求的日志功能。这不是严重问题，但报告为"低严重性"。
严重性分级：
- Critical：阻止合并，必须修复
- High：应该修复，可能阻止合并
- Medium：建议修复，不阻止合并
- Low：可选修复，信息性
Code Quality审查
Spec compliance通过后，进入code quality检查：
Code quality findings:
- Code clear and minimal ✓
- Naming: addTodo, text parameter - clear ✓
- Error handling: what if text is empty? Not handled.
- Test coverage: test for addTodo exists ✓
Issue: Empty text not handled (Medium severity)
审查者发现：空文本没有处理。虽然spec没有明确要求，但这是明显的边界情况。
审查循环
如果发现问题，进入修复循环：
Implementation agent:
Received review feedback:
- Low: Remove "Task added" log (not in spec)
- Medium: Add empty text validation
Fixing:
1. Removed log statement
2. Added validation: if (!text) throw Error("text required")
3. Added test for validation
Self-review: Fixes complete.
审查者再次检查：
Re-review:
- Log removed ✓
- Validation added ✓
- Test added ✓
All issues resolved. Approved.
审查者的独立性
关键是审查者独立验证，不信任实现者的报告。
如果实现者说"I added validation"，审查者不直接相信，而是读代码确认：
function addTodo(text) {
if (!text) throw new Error("text required"); // Confirmed: validation exists
...
}
只有看到代码中确实有验证，审查者才确认通过。
这是防止AI自我合理化的机制。实现者可能说"我做了X"，但实际可能做得不完全。审查者独立验证确保合规。
Receiving Code Review技能
当你收到审查反馈时，Superpowers有另一个技能：Receiving Code Review。
这个技能告诉你如何应对：
- 不是表演式同意："好的，我来修复"
- 是技术验证：理解问题，验证问题确实存在，考虑修复方案
应对流程：
- 理解反馈：问题是什么？为什么是问题？
- 验证问题：读代码确认问题确实存在
- 评估严重性：Critical/High必须修复，Medium/Low可选
- 修复：如果决定修复，遵循TDD
- 回应：如果不同意，技术性解释（不是情绪性反驳）
如果审查反馈看起来不清楚或技术上可疑，你可以技术性讨论。
审查在流程中的位置
在Subagent-driven Development中，审查发生在每个任务完成后：
Task 1 complete → Review Task 1 → Issues → Fix → Re-review → Approved
Task 2 start → ... → Task 2 complete → Review Task 2 → ...
不是所有任务完成后一次性审查。是每个任务独立审查。
好处：
- 问题发现早：不累积到最后
- Context新鲜：审查者刚看到代码，记忆清晰
- 修复容易：任务小，修复范围明确
结论
Superpowers的代码审查：
- 两阶段：Spec Compliance → Code Quality
- 审查者独立：不信任实现者报告
- 严重性分级：Critical/High必须，Medium/Low可选
- 审查循环：问题→修复→重新审查
- 每个任务审查：不累积到最后
这不是泛泛的"代码好不好"，是对照计划的独立验证。审查者有明确的任务描述，检查合规性。
AI参与审查不是替代人类，是辅助：保持一致性，独立验证，详细报告。最终决策是人类。
下一步
下一篇《Git Worktree：为什么隔离工作空间很重要》将展示：
- Worktree如何创建隔离环境
- 为什么干净的起点是必要的
- 完成后如何处理worktree
