# Verify Workflow Receiving Review

> 接收审查反馈。当收到代码审查反馈需要评估和实施，或提到"审查反馈""PR comment""修改意见"

- Skill: `zeroz-lab/verify-workflow-receiving-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add zeroz-lab/verify-workflow-receiving-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zeroz-lab/verify-workflow-receiving-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: zeroz-lab (https://skillmd.com/u/zeroz-lab)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zeroz-lab/verify-workflow-receiving-review

---


# Receiving Review — 接收审查反馈


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

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

## Iron Law

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

## 流程

### 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，因为[理由]。"

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

## 禁止行为（红旗区）

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

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

## 实施顺序

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

## 常见说辞

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

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

## 验证失败处理

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

## 红旗

<HARD-GATE>
以下任何一个出现，立即停止：

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

## 验证清单

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

## 输出模板

```markdown
## Review Feedback 响应

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

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

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

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