verify-workflow-receiving-review

name	verify-workflow-receiving-review
description	接收审查反馈。当收到代码审查反馈需要评估和实施，或提到"审查反馈""PR comment""修改意见"

Receiving Review — 接收审查反馈

入口/出口

• 入口: 审查反馈（来自 human partner 或外部 reviewer）
• 出口: 逐项处理后的反馈响应
• 指向: 处理完成后回到 /build 修复
• 前置加载: CANON.md
• 输出路径: docs/features/YYYYMMDD-<name>/04-review.md（反馈响应部分） → build-workflow-execute（修复实施）

何时不使用

• 还没有具体审查反馈，只是准备主动 review
• 反馈已经被验证并转化为明确 plan/build 任务
• 用户要求重新审查产物，而不是处理收到的反馈

Iron Law

收到反馈不等于同意反馈。每条反馈必须经过独立的技术评估——盲目同意和盲目拒绝一样危险。

流程

Step 1: READ — 完整阅读

完整阅读所有反馈，不做任何反应。不要边读边改。记录反馈条目数量。

Step 2: UNDERSTAND — 理解意图

用自己的话重述每条反馈的要求。复述不出来 = 没理解 → 提问澄清。每条不明确的反馈单独提问。

Step 3: VERIFY — 验证事实基础

对照代码库验证反馈：对应代码存在吗？描述的现象真实存在吗？引用的上下文完整吗？事实不成立 → 记录证据，准备技术性回应。

Step 4: EVALUATE — 评估合理性

对照代码库已有模式评估。考虑执行约束（性能、兼容性、迁移成本）和实施风险。给出判断：采纳 / 反驳 / 部分采纳。

Step 5: RESPOND — 技术性回应

采纳：说明理解和技术依据，不是空洞附和。反驳：事实 + 数据 + 替代方案。每条反馈一条回应。

Step 6: IMPLEMENT — 逐条实施

按实施顺序排列，一次处理一条，每条处理后跑测试。测试失败 → 回退该条修改，重新评估。

来源区分

trusted human partner： 理解后直接实施。仍需 Step 1-2。不理解的部分仍然要提问。

外部 reviewer： 需通过 5 点验证清单：事实准确？上下文完整？约束执行？YAGNI 检查？实施成本合理？

YAGNI 检查

reviewer 建议"properly implement"或"add abstraction"时，先 grep 确认真实使用场景：1 个 = 不抽象，2 个 = 看风格，3+ 个 = 抽象合理。没有第三个使用场景 = 不抽象。

反驳指南

何时反驳： 有技术证据、有量化影响、违反代码库已有模式且无充分理由。

如何反驳： 事实 + 数据 + 替代方案。例："这个改动增加 ~200ms 延迟（基准 X ms），替代方案是 Y，因为[理由]。"

如何纠正反驳： 直接说"我之前的反驳不成立，因为..."，不找借口，立即切换实施模式。

禁止行为（红旗区）

以下回应模式严格禁止——空洞同意不是技术回应：

禁止说辞	为什么禁止
"You're absolutely right!"	空洞同意，无技术分析
"Great point!"	无分析的附和
"Thanks for catching that!"	感谢不是技术回应
"I'll fix that right away"	没评估就承诺
对所有反馈说"好的"	yes-machine 模式
沉默接受所有建议	放弃独立判断

实施顺序

1. 澄清不清楚项 FIRST — 不理解的先问，不猜
2. 阻塞性问题 — Critical 级别
3. 简单修复 — 快速处理的 Nit
4. 复杂修复 — 需要设计或重构的项

常见说辞

说辞	现实	后果
"reviewer 总是对的"	盲目信任和盲目拒绝一样危险。	盲目接受 ~20% 不适用反馈，引入新问题
"不能反驳 reviewer"	有证据的反驳是贡献。	压制异议 → 审查退化为人情盖章
"先全部改完再说"	批量接受 = 放弃判断。	无法定位哪条引入新 bug，回退范围 = 全部
"反馈太多了，挑着改"	每条都读都评估，不能不读。	未读反馈可能含 Critical 问题
"reviewer 比我懂"	reviewer 看的是 snapshot，你活在代码库里。	盲目执行 snapshot 判断覆盖 lived experience

违反字面规则就是违反精神。 没有灰色地带。

验证失败处理

失败场景	处理方式
实施后测试失败	回退该条修改，重新评估，不继续下一条
反驳后发现不成立	直接承认错误，切换实施模式
外部反馈事实不成立	记录证据，提供技术性反驳
反馈意图不明确	标记"待澄清"，不猜测意图
批量修改后无法定位	回退全部，改为逐条实施

红旗

以下任何一个出现，立即停止：

• 未读完全部反馈就开始改代码
• 对所有反馈说"好的"（yes-machine）
• 反驳时没有技术证据（纯主观偏好）
• 混淆"我不同意"和"你是错的"
• 一条失败后继续改下一条（不回退）
• 跳过测试直接处理下一条
• 把"感谢"当作技术回应
• 不提问就猜测反馈意图

验证清单

• 每条反馈已读
• 不理解的已提问
• 外部反馈已通过 5 点验证清单
• 有技术证据支撑每个决定
• 实施顺序正确（澄清 → 阻塞 → 简单 → 复杂）
• 每条实施后测试通过
• 响应记录在 docs/features/<name>/04-review.md

输出模板

## Review Feedback 响应

### 反馈来源
- 来源: human partner / 外部 reviewer
- 反馈条数: N 条
- 处理状态: 全部评估 / 部分待澄清

### 逐条响应
| # | 反馈摘要 | 评估结论 | 理由 | 实施状态 |
|---|---------|---------|------|---------|
| 1 | [摘要] | 采纳/反驳/部分 | [技术依据] | 已修复/已反驳 |

### 待澄清项
| # | 反馈摘要 | 不明确之处 | 状态 |
|---|---------|----------|------|
| 7 | [摘要] | [描述] | 待 reviewer 补充 |

### 实施验证
- 全部修改后测试: PASS
- 无回归: 确认