# 接收反馈准则（借 receiving-code-review）

> 处理收到的评审/反馈意见时，反对两种反模式：**表演式同意**（为显得配合而附和）
> 与**盲目实现**（没理解、没验证就改）。本文给出可执行的禁用语、停手规则与范围纪律。

---

## 1. 禁用「表演式同意」措辞

下面这些是为了关闭对话、显得配合而说的空话。**一律禁用**，除非后面紧跟已验证的技术理由：

| 禁用措辞 | 为什么禁 | 改成 |
|---|---|---|
| 「你说得太对了！」 | 情绪附和，没有技术判断 | 「我核了 X，确认这条成立，因为……」 |
| 「马上改！」（话音未落就改） | 没经过核验阶段 | 「我先确认这是不是改进，再动手」 |
| 「好的好的，我改」 | 缺乏对意见正确性的独立判断 | 「这条我同意/存疑，理由是……」 |
| 「完全同意，没问题」 | 笼统，掩盖了未理解的部分 | 「前两点同意；第三点我不确定含义，需澄清」 |
| 「抱歉抱歉，这就修」 | 过度道歉替代了实质分析 | 直接给出问题分析与修复方案 |

核心：**同意必须带证据，反驳也必须带证据**。空附和与空反驳都不许。

## 2. 收到意见的标准流程（暂停 → 核验 → 判定 → 行动）

1. **暂停**：收到意见先别立刻改。立刻改往往是表演式同意。
2. **核验技术正确性**：这条建议真的是改进吗？用代码/测试/事实验证，别凭感觉。
3. **判定清晰度**：意见是否明确？指到了具体元素吗？
4. **对可疑/不清处提质疑或要澄清**：分析性怀疑，不是情绪对抗。
5. **只在「理解 + 验证」之后才动手**。

## 3. 不清楚就全停（stop-all-if-unclear）

- 只要对意见的**含义、范围、目标**有任何不确定，**停下来要澄清**，不要用猜测继续往下做。
- 用猜测继续 = 在错误方向上累积工作量，返工成本远高于一次提问。
- 提问要具体：「你指的是 A 还是 B？」优于「我不太懂」。
- 在拿到澄清前，不对该意见相关的部分做不可逆改动。

## 4. 反驳要带证据，不空驳

- 反驳时给：可复现的代码片段、失败/通过的测试、明确的技术理由或权威来源。
- 禁止：「我觉得没必要」「一直都这么写」这类无证据反驳。
- 姿态是分析性怀疑（这建议在技术上成立吗），不是为反对而反对。

## 5. 范围纪律 + YAGNI

- **只改被指出的问题**。不要借评审之机顺手重构无关代码——范围蔓延会引入新风险、掩盖根因、让 diff 难评审。
- **YAGNI（You Aren't Gonna Need It）**：不要为「将来可能用到」添加抽象、配置项、防御代码或额外功能。只实现当前明确需要的。
- 多出来的灵活性 = 多出来的维护面和 bug 面。需求没写就不做。
- 修复不夹带重构；重构单独成步、单独验证（联动 systematic-debugging Phase 4）。

## 6. 问题分级（与 code-review 一致）

| 级别 | 处理时机 |
|---|---|
| Critical | 立即修，阻塞交付 |
| Important | 进下一任务前修 |
| Minor | 记录待办，可延后 |

把致命问题排在格式小问题前面，别陷入「只挑表述/格式」的表面陷阱。

---

## 一句话总则
**先理解，再验证，后动手；同意带证据，反驳带证据，不清楚就停。** 范围只覆盖被要求的，YAGNI 是默认。
