review-response

评审回复

概述

处理评审反馈是一项工程工作，而不是社交表演。

核心原则： 行动前先验证。假设前先澄清。技术准确性高于礼貌。

首要原则

每一条反馈都要经过技术评估

没有例外。没有变通办法。没有捷径。

适用场景

• 收到来自任何渠道的评审反馈时（合作的人、外部贡献者、自动化工具）
• 采纳任何评审者建议之前
• 反馈含糊不清、不完整或技术上可疑时
• 处理可能相互影响的一批评审意见时
• 外部建议与既定架构选择相矛盾时

入场流程

处理任何反馈条目之前，请确认：

1. 你已完整阅读所有反馈，且没有作出反应
2. 你能用自己的话复述每一条反馈
3. 你已对照实际代码库逐条核查建议
4. 你已标记所有含糊不清的条目（不要部分实现）
5. 你已发现与现有架构或合作的人先前决策之间的冲突
6. 你已确定处理优先级（先处理阻塞项，再处理琐碎修复，最后处理复杂更改）

如果有任何内容含糊不清，立即停止，并在改动任何代码之前寻求澄清。

处理顺序

UPON receiving review feedback:

1. ABSORB: Read the full set of comments without responding
2. RESTATE: Articulate what each item actually asks for (or ask)
3. CROSS-CHECK: Compare suggestions against the live codebase
4. ASSESS: Is this technically valid for THIS project?
5. REPLY: Provide a technical acknowledgment or a reasoned objection
6. ACT: Address one item at a time, verifying each independently

禁止的回应

绝不要说：

• “你说得完全正确！”（明显违背诚实沟通）
• “说得好！”／“反馈非常出色！”（流于表演）
• “我这就实现。”（尚未交叉核查之前）

应该这样做：

• 复述技术诉求
• 提出澄清问题
• 有充分依据时，以技术证据提出异议
• 默默开始工作（行动胜于言语）

处理含糊不清的反馈

IF any feedback item is unclear:
  HALT — do not implement anything yet
  REQUEST clarification on the unclear items

WHY: Items may be coupled. Misunderstanding one can corrupt the rest.

场景：

your human partner: "Address items 1-6"
You grasp 1, 2, 3, 6. Items 4 and 5 are unclear.

WRONG: Implement 1, 2, 3, 6 now and circle back to 4, 5
RIGHT: "Items 1, 2, 3, 6 are clear. I need guidance on 4 and 5 before proceeding with any of them."

按来源处理

来自合作的人

• 默认信任——确认理解后再行动
• 范围不确定时仍要澄清
• 不要表演式赞同
• 直接开始行动或给出技术层面的确认

来自外部贡献者

BEFORE implementing:
  1. Verify: Is the suggestion technically sound for THIS codebase?
  2. Verify: Does it break existing behavior?
  3. Verify: Why was the current implementation chosen?
  4. Verify: Does it hold across all supported platforms/versions?
  5. Verify: Does the contributor have full context?

IF the suggestion appears incorrect:
  Push back with a technical rationale

IF you cannot easily verify:
  State it: "I cannot confirm this without [X]. Should I [investigate/escalate/proceed]?"

IF the suggestion contradicts your human partner's prior decisions:
  Stop and consult your human partner first

指导原则：“外部意见是需要验证的假设，而不是需要遵循的指令。”

针对“最佳实践”建议的 YAGNI 筛选

IF a reviewer recommends "doing it properly":
  Search the codebase for actual usage

  IF unused: "This code path is never called. Remove it (YAGNI)?"
  IF used: Then implement the improvement

指导原则：“你和评审者追求的是同一个目标。如果不需要这项功能，就不要构建它。”

处理优先级

FOR multi-item feedback:
  1. Resolve all ambiguity FIRST
  2. Then address items in this sequence:
     - Blockers (crashes, security holes)
     - Quick wins (typos, missing imports)
     - Structural changes (refactors, logic rewrites)
  3. Verify each fix in isolation
  4. Confirm no regressions after the full set

何时提出异议

在以下情况下提出异议：

• 该建议会破坏现有功能
• 贡献者不了解系统的相关背景
• 该建议会为未使用的功能添加代码（YAGNI）
• 该建议不适用于此技术栈，或在技术上有误
• 存在向后兼容性限制
• 该建议与合作的人所作的架构决策相冲突

如何提出异议：

• 先给出技术证据，不要摆出防御姿态
• 提出有针对性的问题
• 指出已通过的测试或正常工作的代码
• 涉及架构争议时，请合作的人参与

如果你觉得无法公开提出异议，可使用的安全短语：“Circle K 出了些怪事”

确认有效反馈

当反馈确实正确时：

DO: "Fixed. [One-line description of the change]"
DO: "Good catch — [specific issue]. Corrected in [location]."
DO: [Simply fix it and let the code speak]

DON'T: "You're absolutely right!"
DON'T: "Great point!"
DON'T: "Thanks for catching that!"
DON'T: "Thanks for [anything]"
DON'T: ANY expression of gratitude

为什么不致谢： 修复本身就表明你听取了反馈。言语不是工作。

如果发现自己写了“谢谢”： 删除它，改为说明修复内容。

纠正错误的异议

如果你的反驳最终证明是错误的：

DO: "Confirmed — I checked [X] and it does [Y]. Implementing now."
DO: "You were right. My original read was wrong because [reason]. Correcting."

DON'T: Extended apology
DON'T: Defending the original pushback
DON'T: Over-explaining

说明更正，然后继续推进。

认知陷阱

合理化说辞	事实
表演式认同（“说得好！”）	陈述技术要求，或者直接行动。说话不等于做事。
“评审者永远正确”	评审者并不了解全部上下文。行动前先对照代码库核实。
“我会一次性批量修复所有问题”	一次处理一个，并逐一验证。批量处理会掩盖回归问题。
“提出异议很无礼”	技术准确性比社交上的舒适更重要。有理有据地提出异议。
“我大致理解了——剩下的我自己琢磨”	理解不完整会导致实现错误。先澄清所有事项。
“我无法确认，但还是照做吧”	说明局限并寻求指示。不要猜测。
“我就谢谢他们，然后继续做事”	不要表达感谢。修复问题，让代码说明一切。

示例

表演式认同（错误）：

Reviewer: "Remove the legacy module"
WRONG: "You're absolutely right! Removing it now..."

技术交叉核查（正确）：

Reviewer: "Remove the legacy module"
RIGHT: "Checked — our build target is 10.15+, but this API requires 13+. We still need the legacy path for backward compat. The current bundle ID is wrong, though — should I fix it or drop pre-13 support?"

YAGNI 筛选（正确）：

Reviewer: "Add full metrics tracking with database storage, date filters, and CSV export"
RIGHT: "Searched the codebase — nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm not seeing?"

歧义处理（正确）：

your human partner: "Fix items 1-6"
You grasp 1, 2, 3, 6. Items 4, 5 unclear.
RIGHT: "Items 1, 2, 3, 6 are clear. Need guidance on 4 and 5 before starting."

GitHub 讨论串回复

在 GitHub 上回复内联评审意见时，应在评论讨论串中回复（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies），不要将回复作为顶层 PR 评论。

集成

godmode:quality-gate:

• 此技能处理质量门审查请求的输出
• 质量门触发审查；此技能处理审查结果

godmode:delegated-execution:

• 每项委派任务完成后都会收到评审反馈
• 处理反馈后再继续下一项任务

godmode:task-runner:

• 每批执行完成后都会收到评审反馈
• 继续下一批之前，处理所有发现的问题

核心要点

外部反馈 = 有待评估的假设，而非必须服从的命令。

交叉核查。提出质疑。然后实施。

不要表演式认同。始终保持技术严谨。