Superpowers receiving-code-review 技能深读：让编码 Agent 以"验证优先"而非"表演式认同"回应代码评审

Superpowers 的 receiving-code-review 技能（skills/receiving-code-review/SKILL.md）定义了编码 Agent 收到代码评审反馈后的标准响应流程：先读完再反应、用自己的话复述需求、对照代码库现实验证、技术性地接受或反驳，最后逐条实现并测试。阅读本文，你能完整掌握这套"验证优先"的评审响应方法论——包括六步响应模式、禁用应答清单、对模糊反馈的止损策略、按反馈来源（人类伙伴 vs 外部评审者）区分信任级的五步核查清单、YAGNI 反查流程，以及它与 Superpowers 中 requesting-code-review、subagent-driven-development 两个技能构成的评审闭环。

定位：这套技能解决什么问题

Superpowers 的 README.md 将 receiving-code-review 归入 Collaboration（协作）技能类别，描述为"Responding to feedback"（回应反馈）。其 frontmatter 中的 description 给出了触发时机：

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable — requires technical rigor and verification, not performative agreement or blind implementation

即：在收到评审反馈、准备实现建议之前触发，特别是当反馈"似乎不清晰或技术上可疑"时。这直接指向编码 Agent 的两个高频失败模式：

1. 表演式认同（performative agreement）——用"你说得完全对！"之类的话替代技术判断；
2. 盲目实现（blind implementation）——不验证就动手，把评审者的错误建议也一并落进代码库。

技能开篇给出的核心原则只有三句：

Code review requires technical evaluation, not emotional performance.

Core principle: Verify before implementing. Ask before assuming.
Technical correctness over social comfort.

即：实现前先验证，假设前先提问，技术正确性优先于社交舒适感。下文的所有规则都从这条原则推导出来。

六步响应模式：从 READ 到 IMPLEMENT

技能定义的响应模式是一个固定的六步流水线，原文以伪代码块给出，这里完整保留：

WHEN receiving code review feedback:

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

逐步拆解（对应 SKILL.md 的 "The Response Pattern" 一节）：

步骤	动作	关键约束
1. READ	读完整个反馈，不产生反应	禁止边读边答应"我来改"
2. UNDERSTAND	用自己的话复述每条要求的含义	复述不了就提问，不要猜
3. VERIFY	对照代码库现实检查	建议是否成立取决于当前代码，而非评审者的假设
4. EVALUATE	判断该建议在这个代码库中是否技术上成立	注意原文是 "for THIS codebase"，通用最佳实践不等于本仓库适用
5. RESPOND	技术性确认，或给出有理由的反驳	确认与反驳都必须带技术依据
6. IMPLEMENT	一次只改一条，每条都测试	禁止批量改完再统一验证

这个模式与 Superpowers 的整体哲学一致——README.md 的 Philosophy 一节将其概括为 "Evidence over claims"（证据优先于声明）。第 3、4 步是整个技能的重心：评审者看到的往往是 diff 或局部代码，而 Agent 掌握整个代码库，因此"对照代码库现实验证"是 Agent 相对人类评审者的结构性优势，而不是走过场。

禁用应答清单：为什么 "You're absolutely right" 被列为禁止项

技能用一整节 "Forbidden Responses" 明确划界：

NEVER:
- "You're absolutely right!" (explicit instruction-file violation)
- "Great point!" / "Excellent feedback!" (performative)
- "Let me implement that now" (before verification)

INSTEAD:
- Restate the technical requirement
- Ask clarifying questions
- Push back with technical reasoning if wrong
- Just start working (actions > words)

值得深读的第一条是括号里的注记："You're absolutely right!" 之所以最严重，标注为 "explicit instruction-file violation"（显式的指令文件违规）——意思是这句话不只是风格问题，而是直接违反了许多用户写在指令文件（CLAUDE.md / AGENTS.md / GEMINI.md）里的规则。这个措辞本身有仓库内的设计依据：docs/superpowers/specs/2026-05-05-platform-neutral-config-refs-design.md 记录了这一行的演变——原文写作 (explicit CLAUDE.md violation)，Superpowers 支持多个 Agent 运行时后，设计规格将其改为中性的 (explicit instruction-file violation)，理由是"该括注在做实际工作：它表明这句话不只是风格不好，而是主动违反了很多用户放在指令文件里的规则"。

另一层仓库级证据解释了为什么这类规则要写成"禁用清单"而非正向指令。docs/superpowers/specs/2026-06-10-positive-instruction-redesign-design.md 记录了 Superpowers 团队对技能文本中"负面指令 vs 正面配方"的实测研究，其分类学结论（该规格称之为 doctrine）包括：

• 触发线（tripwires）有效：对具体词元的短语级自检（"如果这句话包含 X……就停下"）会可靠触发；
• 识别表（recognition tables）有效：像 Red Flags / 合理化借口表这类在决策时（而非组句时）阅读的表，是工作的一贯可靠；
• 而"组成层禁令"（告诉模型写某段输出时不要包含什么）在模型自身有竞争动机时会适得其反，只有正向配方能改善。

Forbidden Responses 与后文的 "Common Mistakes" 表格都属于"识别表"类别——它们在 Agent 面对反馈做决策的那一刻被读取，而不干预具体措辞的生成。这是该技能文本能稳定起效的机制解释，读者在为自己的 Agent 编写类似护栏时可以直接借鉴这一分类。

处理不清晰的反馈：先停止，再提问

当反馈中存在任何一条含义不明时，技能给出的指令是硬性的：

IF any item is unclear:
  STOP - do not implement anything yet
  ASK for clarification on unclear items

WHY: Items may be related. Partial understanding = wrong implementation.

理由是条目之间可能存在耦合：只理解了 6 条中的 4 条就先动手，已实现的部分可能因为未理解部分而整体作废。技能随后给出具体示例：

your human partner: "Fix 1-6"
You understand 1,2,3,6. Unclear on 4,5.

❌ WRONG: Implement 1,2,3,6 now, ask about 4,5 later
✅ RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."

注意正确回应里同时声明了"已理解的部分"与"卡住的部分"——这本身就是六步模式中第 2 步（UNDERSTAND：复述或提问）的具体落地。这条规则与 Superpowers 其他技能中"遇到阻塞就停"的纪律同源：executing-plans 明确要求 "Ask for clarification rather than guessing"，subagent-driven-development 也把 "BLOCKED 状态" 列为唯一可以停下来向人类报告的三种情形之一。

按来源区分信任级：人类伙伴 vs 外部评审者

技能把评审反馈的来源分成两类，分别采用不同的处理策略。这是"技术正确性优先"原则在信任维度上的细化。

来自你的人类伙伴（Trusted）

- Trusted - implement after understanding
- Still ask if scope unclear
- No performative agreement
- Skip to action or technical acknowledgment

即：伙伴的意见在"理解之后"可以直接实现（信任），但范围不清时仍然要问（验证不豁免），且同样禁止表演式认同。信任降低的是"验证"的成本，降低的不是"理解"的要求。

来自外部评审者（External Reviewers）

外部反馈默认不可信，实现前必须跑完一个五步核查清单：

BEFORE implementing:
  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?

IF suggestion seems wrong:
  Push back with technical reasoning

IF can't easily verify:
  Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"

IF conflicts with your human partner's prior decisions:
  Stop and discuss with your human partner first

这五个检查分别对应"正确性、回归风险、历史原因（现实现可能有意为之）、跨平台兼容、上下文完备性"。技能还给了三条分支出口：建议确实错了就带技术理由反驳；无法低成本验证时不要假装能验证，而是显式说出局限并请示方向；与人类伙伴的既有决策冲突时，先停下与伙伴讨论——决策权在伙伴，不在 Agent，也不在评审者。技能末尾引用了这条总纲：

your human partner's rule: "External feedback — be skeptical, but check carefully"

（外部反馈——保持怀疑，但要认真核查。）

YAGNI 反查："专业级功能"建议的处置

针对评审者建议"把这个功能实现得正规一点/完整一点"（implementing properly）这类升级型建议，技能要求先用 grep 反查实际使用情况：

IF reviewer suggests "implementing properly":
  grep codebase for actual usage

  IF unused: "This endpoint isn't called. Remove it (YAGNI)?"
  IF used: Then implement properly

逻辑是：如果一个端点/功能在代码库里没有任何调用方，"把它实现正规"本身就是在为不存在的消费者建设——正确动作可能是删除而不是完善。技能同样引用了人类伙伴的原话作为裁决依据：

"You and reviewer both report to me. If we don't need this feature, don't add it." （你和评审者都向我汇报。如果这个功能没需求，就不要加。）

这条规则把 YAGNI（You Aren't Gonna Need It）从编码哲学变成了一条可执行的核查动作：先 grep，再决定实现方向。

多条反馈的实现顺序与测试纪律

FOR multi-item feedback:
  1. Clarify anything unclear FIRST
  2. Then implement in this order:
     - Blocking issues (breaks, severity/security)
     - Simple fixes (typos, imports)
     - Complex fixes (refactoring, logic)
  3. Test each fix individually
  4. Verify no regressions

排序逻辑值得说明：先澄清（避免返工）→ 阻断性问题（会破坏功能或有安全风险的）→ 简单修复（低成本快速清障，也降低后续复杂修复的噪声）→ 复杂修复（重构、逻辑改动，放在最后是因为它们可能改变前面简单修复所依赖的代码形态）。每一步"单独测试 + 最终验证无回归"，与六步模式中第 6 步 "One item at a time, test each" 呼应。

值得注意的是，这套顺序与 Superpowers 评审闭环中的严重度分级天然对齐：requesting-code-review 派发的评审子代理按 code-reviewer.md 模板输出时，问题被分为 Critical（Must Fix）/ Important（Should Fix）/ Minor（Nice to Have） 三级，且明确要求"按实际严重度分类，不是所有问题都是 Critical"。接收侧的排序（阻断 → 简单 → 复杂）正好消费这个结构：Critical 对应阻断问题，先修。

何时反驳，以及怎么反驳

技能列出了六种应当 push back 的情形：

• 建议会破坏现有功能；
• 评审者缺乏完整上下文；
• 违反 YAGNI（功能无人使用）；
• 对这个技术栈来说技术上不正确；
• 存在遗留代码/兼容性原因；
• 与人类伙伴的架构决策冲突。

反驳的执行方式有四条纪律：

- Use technical reasoning, not defensiveness
- Ask specific questions
- Reference working tests/code
- Involve your human partner if architectural

用技术推理而非防御姿态；问具体问题；引用能跑的测试和代码作为证据（而不是口头坚持）；涉及架构层面时把人类伙伴拉进来。技能还有一条对 Agent 情绪管理相当少见的补充：

If you're uncomfortable pushing back out loud: Name that tension, then tell your partner about the issue you've seen. They'll appreciate your honesty.

如果 Agent 对公开反驳感到"不适"（这在提示词工程语境里指的是模型回避冲突的倾向），应先把这种张力说出来，再把发现的问题告知伙伴——诚实本身会被欣赏。

确认正确反馈时的措辞，以及纠错的体面

当反馈确实正确

✅ "Fixed. [Brief description of what changed]"
✅ "Good catch - [specific issue]. Fixed in [location]."
✅ [Just fix it and show in the code]

❌ "You're absolutely right!"
❌ "Great point!"
❌ "Thanks for catching that!"
❌ "Thanks for [anything]"
❌ ANY gratitude expression

注意最后一行：任何形式的感谢都被禁用。技能解释的理由是"行动会说话：改好就行，代码本身证明了它听到了反馈"。并给出一条触发线式自检：

If you catch yourself about to write "Thanks": DELETE IT. State the fix instead.

（如果发现自己正要写 "Thanks"：删掉它，改为陈述修复内容。）这正是前文提到的"触发线"机制在技能文本里的应用。

当自己反驳错了

推翻了评审者、事后发现自己错的场景，纠正方式同样被规范：

✅ "You were right - I checked [X] and it does [Y]. Implementing now."
✅ "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing."

❌ Long apology
❌ Defending why you pushed back
❌ Over-explaining

事实性地陈述纠正（谁对、查了什么、为什么当初理解错），然后继续干活——不长道歉、不辩解、不过度解释。这与"验证优先"是同一原则的两面：反驳要验证，收回反驳也要有验证证据（"I checked [X] and it does [Y]"）。

常见错误速查表

技能用一张"错误 → 修正"对照表收束全部纪律：

错误	修正
Performative agreement（表演式认同）	陈述需求，或直接行动
Blind implementation（盲目实现）	先对照代码库验证
Batch without testing（批量改不测）	一次一条，每条都测
Assuming reviewer is right（默认评审者对）	检查是否会破坏现有功能
Avoiding pushback（回避反驳）	技术正确性 > 舒适感
Partial implementation（部分实现）	先澄清全部条目
Can't verify, proceed anyway（无法验证也硬做）	说明局限，请求指示

这七行与正文各节一一对应，可以当作 Agent 在收到评审反馈后的决策时识别表来用——这也符合仓库内 2026-06-10 正面指令研究规格中对"识别表在决策时读取有效"的实测分类。

真实示例：四种典型场景的正确形态

技能末尾给了四组对照示例，完整保留如下。

表演式认同（反例）：

Reviewer: "Remove legacy code"
❌ "You're absolutely right! Let me remove that..."

技术验证（正例）：

Reviewer: "Remove legacy code"
✅ "Checking... build target is 10.15+, this API needs 13+. Need legacy for
    backward compat. Current impl has wrong bundle ID - fix it or drop
    pre-13 support?"

这个示例浓缩了 VERIFY → EVALUATE → RESPOND 三步：先查（构建目标 10.15+），再判断（该 API 需要 13+，向后兼容需要保留 legacy），最后不硬顶也不盲从，而是把问题升级为决策问题抛回去（修 bundle ID，还是放弃 pre-13 支持？）。

YAGNI 反查（正例）：

Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
✅ "Grepped codebase - nothing calls this endpoint. Remove it (YAGNI)?
    Or is there usage I'm missing?"

注意结尾"Or is there usage I'm missing?"——反查结果作为证据摆出，但把最终裁决留给伙伴。

不清晰条目（正例）：

your human partner: "Fix items 1-6"
You understand 1,2,3,6. Unclear on 4,5.
✅ "Understand 1,2,3,6. Need clarification on 4 and 5 before implementing."

闭环中的位置：谁产生这些反馈，反馈如何被消费

单独看，receiving-code-review 处理的是"收到反馈"这一端；放到整个仓库里，它的上游是明确的。

上游：requesting-code-review。 skills/requesting-code-review/SKILL.md 定义了主动派发评审子代理的流程：先取 git SHA 范围（BASE_SHA=$(git rev-parse HEAD~1) / HEAD_SHA=$(git rev-parse HEAD)），再按 code-reviewer.md 模板派发 general-purpose 子代理，填充 {DESCRIPTION}、{PLAN_OR_REQUIREMENTS}、{BASE_SHA}、{HEAD_SHA} 四个占位符。评审子代理的输出结构固定为 Strengths / Issues（Critical、Important、Minor 三级，每条带 File:line、问题、影响、修法）/ Recommendations / Assessment（"Ready to merge? Yes | No | With fixes"）。也就是说，receiving-code-review 面对的反馈天然是分级的、带 file:line 引用的结构化产物——它的"逐条验证、按顺序实现、单独测试"纪律正是为消费这种结构而设计的。

requesting 技能对反馈的处置规则与 receiving 技能互为镜像：

3. Act on feedback:
   - Fix Critical issues immediately
   - Fix Important issues before proceeding
   - Note Minor issues for later
   - Push back if reviewer is wrong (with reasoning)

最后一行"Push back if reviewer is wrong (with reasoning)"正是 receiving 技能的整个领域。

更上游：subagent-driven-development。 skills/subagent-driven-development/SKILL.md 的任务循环中，每个任务完成后生成评审包并派发任务评审者；所有任务结束后，最终全分支评审同样使用 requesting-code-review 的 code-reviewer.md 模板，并用最强模型派发。该技能把"如何回应评审发现"制度化为修复循环：最多 5 轮，前 3 轮恢复原实现者继续修、第 4-5 轮换新实现者加更强模型；每一轮结束必须做限定范围的复审（scoped re-review）；断路器触发后对每条未决发现做裁决——"评审者错了或可争议"的记入 ledger 挂起（parked），"真实且是承重结构"的则 STOP 并报 BLOCKED。可以推断，receiving-code-review 技能面向的是人机协作场景中的单次评审回应，而 subagent-driven-development 是同一套"验证优先"原则在自主多任务循环里的工程化放大：同样先验证、同样可反驳、同样禁止静默丢弃（"a silent discard is forbidden"）。

历史佐证：GitHub 线程回复指引。 RELEASE-NOTES.md 的 v4.0.1（2025-12-23）条目记录了技能文本的一处增量：

Added GitHub thread reply guidance to receiving-code-review (h/t @ralphbean) — Added a note about replying to inline review comments in the original thread rather than as top-level PR comments.

这条指引就是技能当前的最后一节 "GitHub Thread Replies"：

When replying to inline review comments on GitHub, reply in the comment thread
(gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies), not as a
top-level PR comment.

即：对 GitHub 内联评审评论的回复应发到原评论线程（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies），而不是作为顶层 PR 评论。这是一个典型的"Agent 行为纠偏"条目——把人类协作中不言自明的礼仪，翻译成 Agent 需要显式指令才能保证的动作。

适用前提与使用限制

• 该技能是 Superpowers 技能库的一部分，随插件安装而生效（各运行时的安装方式见 README.md 的 Installation 一节）；技能由 using-superpowers 的调用规则保证"在响应之前"被加载，其用户指令优先级声明为：用户指令 > 技能 > 默认行为。
• 技能文本中的 "your human partner" 指与 Agent 协作的用户本人；"外部评审者"指除伙伴之外的一切反馈来源（其他人类评审者、上游 issue、以及 Superpowers 自己派发的评审子代理输出均可按外部来源对待，是否升级信任级由使用者自定）。
• 禁用感谢、禁用表演式认同等措辞规则是 Superpowers 的"风格纪律"，服务于让评审回应保持信息密度；它们不是对 Agent 的普世要求，迁移到其他项目时应连同"验证优先"的原则一起取舍，而不是只复制话术。

小结：一张可执行的响应清单

把全技能压缩成 Agent（或人）收到评审反馈时的检查清单：

1. 读完全部反馈，不反应；
2. 逐条复述含义，复述不了的先全部问清（条目可能相关，禁止部分实现）；
3. 外部来源逐条跑五步核查（正确性 / 回归 / 历史原因 / 跨平台 / 上下文）；
4. 升级型建议先 grep 实际使用情况，未使用则提议删除（YAGNI）；
5. 反驳要有技术推理、具体问题、可跑的测试/代码引用；架构冲突先找伙伴；
6. 确认无误后按"阻断 → 简单 → 复杂"顺序逐条实现，每条单独测试，最后验证无回归;
7. 回应措辞只陈述修复内容与位置，零感谢、零表演；反驳错了就事实性纠错，不道歉不辩解;
8. GitHub 内联评论在原线程内回复。

这条清单的每个条目都能在 skills/receiving-code-review/SKILL.md 中找到原文依据，而其下游消费格式可追溯到 skills/requesting-code-review/code-reviewer.md 的评审输出模板——两者合起来，构成了 Superpowers 中"评审—回应—修复"闭环的两半。