Agent 方法论框架 superpowers：请评审与接评审是两套技能
本文基于 superpowers 仓库 commit 44c9b2d（2026-07-27）梳理，该项目仍在持续迭代，具体行为以仓库 https://github.com/obra/superpowers 最新代码与文档为准。
在 Agent 驱动的开发里，评审真正卡人的地方不是”让谁来评”，而是收到一条你觉得不对的意见之后的那半分钟。 你要么条件反射地照做，把一个本来正确的实现改坏；要么条件反射地辩解，把一个真问题挡在门外。superpowers 这个开源项目（MIT 许可证，仓库在 https://github.com/obra/superpowers ）把这件事拆成了两份互不重叠的技能文件：一份管怎么请，一份管怎么接。后者用了整整一节篇幅写”意见看起来不对时的处理路径”，这在同类方法论里并不常见。
站内已经有两篇讲通用方法论的文章：AI 代码评审工具怎么用 谈工具选型和接入方式，AI 评审与人工评审的分工 谈责任边界。本篇不重复那两层，只看 superpowers 这一个具体项目把这套东西落到了哪些文件、哪些强制约束上，你可以自己打开仓库逐行核对。
一、这两份文件各自负责什么
skills/requesting-code-review/SKILL.md 的开头一句话就定了调：派一个评审 subagent 去在问题级联之前抓住它，评审方拿到的是精心构造的上下文，而不是你这一轮会话的历史。核心原则写作 Review early, review often。
它把触发时机分成两档。强制的三条：subagent-driven development 里每个任务之后、完成一个大功能之后、合并到主干之前。可选但有价值的三条：卡住的时候（换个视角）、重构之前（拿基线）、修完一个复杂 bug 之后。
文件靠后有一张 Common Rationalizations 表，专门堵两种自我说服。第一条是”我自己看一下 diff 就行了，不用派人”，给出的回应是：你是协调者的角色，内联读 diff 会烧掉你还要继续驱动工作的上下文窗口；派一个评审 subagent，diff 和评估过程都留在它的上下文里，回到你这里的只有结论。第二条是”评审方需要我完整的会话历史才能看懂改动”，回应是把精心构造的上下文交给它，永远不要给会话历史，这样评审方盯的是工作产物，不是你的思考过程。
这两条说的其实是同一件事的两面——上下文隔离。如果你还不熟悉这种把重活推给独立会话的写法，可以先看 Claude Code 的 subagent 机制。
skills/receiving-code-review/SKILL.md 管的是另一端。它的核心原则是：先验证再实施，先问再假设，技术正确性优先于社交舒适度。开篇第一句更直白——代码评审要的是技术评估，不是情绪表演。
二、请评审这个动作，拆开看有几步
只有三步，但每一步都有约束。
第一步取两个 SHA，文件里给的就是这么两行：
BASE_SHA=$(git rev-parse HEAD~1) # or origin/main
HEAD_SHA=$(git rev-parse HEAD)
第二步派一个 general-purpose subagent，用 code-reviewer.md 里的模板填四个占位符：{DESCRIPTION}（你建了什么）、{PLAN_OR_REQUIREMENTS}（它应该做到什么）、{BASE_SHA}、{HEAD_SHA}。
第三步是处理反馈，分四级：Critical 立刻修，Important 在往下走之前修，Minor 记下来以后再说，评审方说错了就带着技术理由推回去。
模板本身值得单独读。它里面有一节 Read-Only Review，明确要求评审是只读的：不许改动工作树、索引、HEAD 或分支状态，用 git show、git diff、git log 看历史；如果确实需要另一个版本的工作副本，用 git worktree add 检出到独立的临时目录，绝不在当前 checkout 上移动 HEAD。这条约束在 Agent 场景里是刚需——一个跑偏的评审方切一次分支，你正在推进的工作就废了。
检查面分了五组：计划一致性、代码质量、架构、测试、生产就绪度。测试那组问得很具体，比如测试验证的是真实行为还是 mock。
还有一节叫 Calibration，讲评审方自己的校准：按真实严重度分类，不是什么都是 Critical；在列问题之前先承认做得好的地方，理由写得很清楚——准确的肯定能让实现方相信后面那些意见。另外，如果发现的是计划本身的问题而不是实现的问题，也要直说。
输出格式是固定的：Strengths、Issues（Critical / Important / Minor 三档）、Recommendations、Assessment。每条问题要给文件行号、错在哪、为什么要紧、怎么修。最后的 Assessment 只有三个取值：Yes、No、With fixes。DON’T 清单里有一条挺狠的——不许对你没真读过的代码给意见。
| 组成部分 | 它负责什么 | 对应仓库位置 | 你什么时候会碰到它 |
|---|---|---|---|
| 请求评审技能 | 定义何时请、怎么取 SHA、怎么按四档处理反馈 | skills/requesting-code-review/SKILL.md | 完成一个功能、准备合并之前 |
| 评审提示词模板 | 评审方的角色、只读约束、五组检查面、固定输出格式 | skills/requesting-code-review/code-reviewer.md | 每次派评审 subagent 时填占位符 |
| 接受评审技能 | 六步响应模式、禁用话术、推回的判据与方式 | skills/receiving-code-review/SKILL.md | 评审结果回来、你打算动手改之前 |
| 任务级评审衔接 | 任务循环里的评审调度、修复波次、最终整分支评审 | skills/subagent-driven-development/SKILL.md | 按计划分任务推进时 |
| 任务级评审提示词 | 与合并就绪评审分开的、限定在单任务 diff 的评审提示 | skills/subagent-driven-development/task-reviewer-prompt.md | 单个任务完成后的那次评审 |
多说一句衔接关系：skills/subagent-driven-development/SKILL.md 在讲最终整分支评审时，明确说要用 requesting-code-review 的 code-reviewer.md；而单个任务的那次评审用的是自己目录下的提示词。这个区分是有意的——合并就绪级别的评审框架套在一个任务的 diff 上，会诱导评审方超出改动范围去挑毛病。
三、接评审：动手之前先停住
receiving-code-review 给的是一个六步序列：
1. READ: Complete feedback without reacting
2. UNDERSTAND: Restate requirement in own words (or ask)
3. VERIFY: Check against codebase reality
4. EVALUATE: Technically sound for THIS codebase?
5. RESPOND: Technical acknowledgment or reasoned pushback
6. IMPLEMENT: One item at a time, test each
注意实施排在第六位，前面五步一步都不能跳。
被明令禁止的回应有三类：You’re absolutely right 这种（文件里注明这是对指令文件的直接违反）、Great point 这种表演式的、以及还没验证就说”我这就去实现”。替代做法是复述技术需求、提澄清问题、有理有据地推回，或者干脆直接开干——行动比话有用。
还有一条容易被忽略：只要有任何一项没看懂，就全部停下，先问清楚，什么都别先做。理由是各项之间可能相关，理解了一半就动手等于实现错。文件里举的例子很具体：对方说”修 1 到 6”，你懂 1、2、3、6，不懂 4、5，错误做法是先把懂的四条改了、回头再问；正确做法是说明白哪几条清楚、哪两条需要澄清之后再动手。
多条意见的实施顺序也定死了：先澄清不清楚的，然后按阻塞性问题（会崩、有安全风险）、简单修复（拼写、import）、复杂修复（重构、逻辑）的顺序做，每条单独测，最后验证没有回归。
关于道谢，文件的态度很硬：不写”谢谢你发现这个”，任何感谢表达都不写；正确的确认方式是”已修复，改了什么”，或者”这里确实有问题，在某某位置修了”，或者干脆只把代码改好。理由是行动会说话，代码本身就证明你听进去了。如果你发现自己正要写谢谢，删掉，改成陈述修了什么。
这套写法背后是有取舍的：它牺牲了对话的社交润滑，换取信息密度。人和人之间这样说话未必合适，但对一个会因为迎合而偏移的模型来说，禁掉表演式认同是有意义的。
四、意见看起来不对时，具体怎么办
这是全篇最实用的一节。文件把外部评审来的建议单独列了一段处理流程，实施之前先过五个检查：
1. Check: Technically correct for THIS codebase?
2. Check: Breaks existing functionality?
3. Check: Reason for current implementation?
4. Check: Works on all platforms/versions?
5. Check: Does reviewer understand full context?
后面跟着三条分支：建议看起来不对，带技术理由推回；自己没法轻易验证，就直说”没有某某条件我验证不了，是该去查、去问，还是先按这个做”；如果建议和人类伙伴此前定下的决定冲突，先停下来讨论，不要自作主张。文件里把这套态度概括成一句话——对外部反馈要保持怀疑，但要认真核查。
该推回的情形列了六条：建议会破坏现有功能、评审方缺少完整上下文、违反 YAGNI（要加的是没人用的功能）、对当前技术栈技术上不成立、存在遗留或兼容性原因、与既有架构决策冲突。
推回的方式也写了：用技术论证而不是防御姿态，问具体问题，引用能跑通的测试或代码，属于架构层面的就把人拉进来。文件里给的对照例子很能说明区别——评审方说”把遗留代码删掉”，表演式的回答是”你说得太对了，我这就删”；技术性的回答是先去查构建目标支持的最低系统版本，发现它比这个 API 要求的版本还低，所以遗留分支为了向后兼容必须留着，同时指出当前实现里的 bundle ID 是错的，反问对方是修掉这个错误，还是干脆放弃对旧系统的支持。这个回答的结构值得拆开看：它先给出一个可核查的事实，再给出保留代码的理由，最后把一个自己无权单方面拍板的取舍抛回给提意见的人。三段缺一不可——只有事实没有取舍，对话就停在那里；只有取舍没有事实，就还是在凭感觉争。
YAGNI 那条给了可执行的动作：评审方要求”把这个实现得更正规一些”时，先 grep 一遍代码库看有没有真实调用。没人调用就问”这个端点没有任何调用方，按 YAGNI 删掉？“；有调用再认真实现。这背后是一条明写的原则：你和评审方都对同一个人负责，不需要的功能就别加。
推回错了怎么收场也有规定：核实之后说”你是对的，我查了某某，确实是某某，现在改”，然后往下走。不写长篇道歉，不解释自己当初为什么推回，不过度说明。
最后一条我觉得是这份文件里最见功力的：如果你不太敢当面推回，先把这份不适说出来，然后照样把你看到的问题告诉伙伴。它没有假装这种张力不存在，而是给了一条明路。这条对人和对 Agent 同样成立，也和 对手验证 那种刻意制造分歧的做法思路一致。
五、边界与代价
先说它明确不管的事。这两份文件不提供评审规则集，不定义任何静态检查或 lint 配置，不管 CI 怎么接，也不管评审结论怎么变成 PR 里的状态。它们管的只是调度和沟通：什么时候派、给什么上下文、拿到结论后按什么顺序处理。评审内容的专业性完全依赖被派出去的那个模型自己。
再说依赖。整套流程建立在 git 提交区间上，BASE_SHA 和 HEAD_SHA 是模板的必填项。如果你的工作流里提交历史脏乱、一个任务混着几件不相干的事，取出来的区间就没有评审价值。它同样依赖运行时能派出独立 subagent——skills/using-superpowers/references/gemini-tools.md 里有一张把评审派发映射到另一个宿主工具的对照表，说明适配是要另外做的，不是白来的。
代价必须讲清楚。第一，慢。每个任务后面挂一次评审，加上澄清和修复的往返，整体节奏会明显下降。第二，Agent 会变啰嗦：六步响应模式意味着它在动手前要复述、要核查、要给判断，输出的字数和 token 消耗都会涨，这部分开销你得自己算一笔账。第三，对小改动是过度设计——改一行文案、调一个常量也走完整流程，投入产出明显不划算。
这里有个张力要摆在明面上：requesting-code-review 的 Red Flags 一节写着，绝不要因为”这很简单”就跳过评审。项目的立场是宁可多评，因为人对”简单”的判断本身就不可靠。但这条规则套在一个几十行的脚本仓库上就是负担。这个边界项目没有替你划，你得自己划，划的时候至少要意识到自己正在对抗它的默认立场。
还有一点要认清：评审方产出的是自然语言判断，不是确定性检查结果。模板要求它核对测试是否验证真实行为、是否覆盖边界情况，但这套核对本身没有强制执行力。它是在类型检查、测试套件、安全扫描之上加的一层，不是替代品。
六、上手清单与常见坑
把整段会话历史贴给评审方。 会踩是因为省事——反正上下文都在手边。后果是评审方跟着你的思路走，你当初的错误假设它会一起继承，这就不是独立评审了。避法是老老实实填四个占位符，描述、需求、两个 SHA，其余一概不给。
BASE_SHA 取错。 会踩是因为顺手写 HEAD~1。如果这个任务实际上产生了五个提交，你只评审了最后一个，前面四个直接漏掉。文件的示例里是从 git log 里定位上一个任务的提交来取基线的，思路是按任务边界取，不是按提交条数取。
评审方在你的 checkout 上动了手。 会踩是因为它想看某个历史版本的完整文件，顺手切了分支。避法是把只读约束原样写进派发的提示词里，需要别的版本就用 git worktree add 检出到临时目录。
看懂四条就先改四条。 会踩是因为想先推进一点是一点。问题在于多条意见常常互相牵连，你按局部理解改完的部分，等剩下两条解释清楚以后可能要全部推倒。避法是全部澄清完再动第一行代码。
条件反射式认同。 会踩是因为迎合的成本最低，说一句”你说得对”就能把球踢回去。代价是把错误的建议原样实施进代码库，而且没人再复核。避法是把那三类禁用话术当硬性红线，回应只允许是复述需求、提问、推回，或者直接改。
给每一条 finding 都派一个修复者。 会踩是因为看起来更并行、更干净。skills/subagent-driven-development/SKILL.md 里写得很清楚：每个修复者都要重建上下文、重跑测试套件，最终评审的修复波次成本可能超过前面所有任务的总和。做法是派一个修复者带完整的问题清单，然后只做一轮限定范围的复评。
把评审结论当合并许可。 会踩是因为模板末尾就写着 Ready to merge。但那只是评审方的技术判断，是否合并、要不要带着已知问题上线，决定权在人这一侧。如果你想搭一条流水线自动放行，先想清楚谁为放行负责，这一层可以参考 Human in the loop 的设计。
收尾
把这套东西压成一句自检：派评审之前，问自己给出去的是精心构造的上下文还是会话历史；收到评审之后，问自己在动手之前有没有做过第三步的核查。这两个问题任何一个答不上来，这次评审的价值就已经漏掉一半了。
接下来该读哪个文件，取决于你卡在哪一端。想改进派发质量，读 skills/requesting-code-review/code-reviewer.md，重点是 Read-Only Review 和 Calibration 两节。想改进接收质量，读 skills/receiving-code-review/SKILL.md 的 Source-Specific Handling 和 When To Push Back。想看这两者怎么嵌进一条完整的多任务流程，再去读 skills/subagent-driven-development/SKILL.md 的评审循环部分。这是别人维护的项目，仓库还在动，读之前先确认你手上的版本。
本文属于 superpowers 方法论专题（共 30 篇，含三篇与其它开源 Agent 项目的对照）。想看把资产铺满的另一种取向，见 ECC 开源 Agent 套件专题。