| 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 模式 |
| 沉默接受所有建议 | 放弃独立判断 |
实施顺序
- 澄清不清楚项 FIRST — 不理解的先问，不猜
- 阻塞性问题 — Critical 级别
- 简单修复 — 快速处理的 Nit
- 复杂修复 — 需要设计或重构的项
常见说辞
| 说辞 | 现实 | 后果 |
|---|
| "reviewer 总是对的" | 盲目信任和盲目拒绝一样危险。 | 盲目接受 ~20% 不适用反馈，引入新问题 |
| "不能反驳 reviewer" | 有证据的反驳是贡献。 | 压制异议 → 审查退化为人情盖章 |
| "先全部改完再说" | 批量接受 = 放弃判断。 | 无法定位哪条引入新 bug，回退范围 = 全部 |
| "反馈太多了，挑着改" | 每条都读都评估，不能不读。 | 未读反馈可能含 Critical 问题 |
| "reviewer 比我懂" | reviewer 看的是 snapshot，你活在代码库里。 | 盲目执行 snapshot 判断覆盖 lived experience |
违反字面规则就是违反精神。 没有灰色地带。
验证失败处理
| 失败场景 | 处理方式 |
|---|
| 实施后测试失败 | 回退该条修改，重新评估，不继续下一条 |
| 反驳后发现不成立 | 直接承认错误，切换实施模式 |
| 外部反馈事实不成立 | 记录证据，提供技术性反驳 |
| 反馈意图不明确 | 标记"待澄清"，不猜测意图 |
| 批量修改后无法定位 | 回退全部，改为逐条实施 |
红旗
以下任何一个出现，立即停止：
- 未读完全部反馈就开始改代码
- 对所有反馈说"好的"（yes-machine）
- 反驳时没有技术证据（纯主观偏好）
- 混淆"我不同意"和"你是错的"
- 一条失败后继续改下一条（不回退）
- 跳过测试直接处理下一条
- 把"感谢"当作技术回应
- 不提问就猜测反馈意图
验证清单
输出模板
## Review Feedback 响应
### 反馈来源
- 来源: human partner / 外部 reviewer
- 反馈条数: N 条
- 处理状态: 全部评估 / 部分待澄清
### 逐条响应
| # | 反馈摘要 | 评估结论 | 理由 | 实施状态 |
|---|---------|---------|------|---------|
| 1 | [摘要] | 采纳/反驳/部分 | [技术依据] | 已修复/已反驳 |
### 待澄清项
| # | 反馈摘要 | 不明确之处 | 状态 |
|---|---------|----------|------|
| 7 | [摘要] | [描述] | 待 reviewer 补充 |
### 实施验证
- 全部修改后测试: PASS
- 无回归: 确认
