Superpowers 系列（七）：审查反力
Review 在 Agent 协作里有两个相反风险：没有独立审查时，实现者会自证正确；盲从 reviewer 时，系统会把不适合当前代码库的建议变成新问题。
Superpowers 用 requesting-code-review 和 receiving-code-review 控制这两个方向。前者要求主动引入独立反力，后者要求对反馈做技术验证。requesting-code-review/SKILL.md 明确 reviewer 拿精确上下文而不是完整会话历史；receiving-code-review/SKILL.md 则要求先理解和验证反馈，再决定是否实现。
请求审查解决的是自证问题
实现者天然有盲区。它知道自己想实现什么，所以会在代码里读出自己期待的意图。尤其是 Agent，它还擅长把实现过程解释得很合理。
requesting-code-review 要求在任务完成、主要功能完成、合并前等节点请求审查。审查者拿到的是精确上下文：做了什么、应该满足什么、base/head 提交范围是什么。审查者不应该继承完整会话历史。
这个设计有两个好处。
第一，审查聚焦于工作产物，而不是实现者的叙事。第二，主 Agent 不必把大量 diff 放进自己的上下文里自审，避免协调上下文被细节淹没。
接收审查解决的是盲从问题
reviewer 不是流程里的神谕。它可能不知道完整上下文，可能提出超出当前需求的“专业功能”，也可能用通用最佳实践破坏本项目约束。
receiving-code-review 要求反馈处理遵循六步：读完、理解、验证、评估、回应、实现。它尤其反对表演式同意。Agent 不应该用“你完全正确”“好建议”这种话替代技术判断。
这个 Skill 的重点是：审查反馈需要被验证，而不是被感恩。
审查反馈的可信度分层
Superpowers 对反馈来源做了区分。
来自用户的反馈优先级高，但范围不清仍要澄清。来自外部 reviewer 的反馈要检查是否适合当前代码库：会不会破坏已有功能，是否和历史决策冲突，是否引入未使用能力，是否忽略平台版本或兼容性。
这种分层让审查保持技术性。Reviewer 的发现有价值，但不能自动变成实现动作。Agent 需要先确认反馈是否适合当前代码库，再决定修复、反驳或请求澄清。
YAGNI 检查是审查治理里的亮点
receiving-code-review 里有一个很有意思的规则：当 reviewer 建议“把功能实现得更完整”时，先搜索代码库是否真的有使用者。如果没有使用者，应该考虑删除或不做，而不是为了“专业”添加复杂能力。
这个规则防的是审查驱动的范围膨胀。
Review 常常会把“理论上更完整”推向“现在必须实现”。Superpowers 用 YAGNI 把问题拉回当前需求：这个能力有没有调用方？当前目标是否需要？不需要就不要用 review 的名义扩范围。
审查是反力，不是终点
一个健康的审查闭环应该是：
实现者提交工作产物 -> 独立 reviewer 检查 -> 主 Agent 验证反馈 -> 修复或技术反驳 -> 重新验证如果省略独立 reviewer，系统缺少反力。如果省略反馈验证，reviewer 变成新的单点权威。这两者都会损害协作质量。
审查反力的边界
审查不是终点。它提供反力，让实现者的叙事接受外部检查；它也需要被验证，避免 reviewer 的建议变成新的未经审查假设。
Superpowers 里的审查链路因此有两段：先请求独立审查，再技术化接收反馈。只要少了其中一段，系统都会偏：没有独立审查会自证正确；没有反馈验证会盲从权威。
这一点让 review 不再是“多看一眼”，而是一个可进可退的质量调节器。
参考资料：
系列导航：