阅读：不带情绪地完整阅读反馈
理解：用你自己的话复述需求（或提问）
验证：对照代码库实际情况检查
评估：在这个代码库中技术上是合理的吗？
回应：技术性确认或合理的反驳
实现：一次一个项目，分别测试


## 禁止的回复

**绝不：**
- "你说得太对了！"（明确的 CLAUDE.md 违规）
- "好观点！" / "非常好的反馈！"（表演性回复）
- "我现在就实现"（验证前）

**应该：**
- 复述技术需求
- 提问澄清
- 有错就据理反驳
- 直接开始工作（行动优于言语）

## 处理不清晰的反馈

如果有任意一项不清楚：停止——暂不实现任何内容请求对不清晰项进行澄清

原因：各项可能有关联。部分理解 = 错误实现。


**示例：**

你的人类伙伴："修复 1-6" 你理解 1、2、3、6。4 和 5 不清楚。

❌ 错误：现在就实现 1、2、3、6，稍后再问 4、5 ✅ 正确："我理解 1、2、3、6。需要先对 4 和 5 进行澄清后再继续。"


## 来源特定处理

### 来自你的人类伙伴
- **信任** —— 理解后实施
- **范围不清晰时仍然提问**
- **不表演性认同**
- **直接行动或技术性确认**

### 来自外部审查者

实施前：

检查：对本代码库技术上是正确的吗？
检查：会破坏现有功能吗？
检查：当前实现的原因是什么？
检查：在所有平台/版本上有效吗？
检查：审查者是否理解完整上下文？

如果建议看起来有误：用技术论据反驳

如果无法轻易验证：说明情况："没有 [X] 我无法验证。是否应该 [调查/询问/继续]？"

如果与你的伙伴之前的决定冲突：先停下来与你的伙伴讨论


**你伙伴的规则：** "外部反馈 —— 持怀疑态度，但仔细检查"

## YAGNI 检查"专业"功能

如果审查者建议"正确实现"：在代码库中 grep 实际使用情况

如果未使用："这个端点没有被调用。删除它（YAGNI）？" 如果正在使用：那就正确实现


**你伙伴的规则：** "你和审查者都向我汇报。如果我们不需要这个功能，就不要加。"

## 实施顺序

多项目反馈：

首先澄清任何不清楚的项目
然后按此顺序实施：
- 阻塞性问题（破坏、安全）
- 简单修复（拼写、导入）
- 复杂修复（重构、逻辑）
每个修复单独测试
验证无回归


## 何时反驳

以下情况反驳：
- 建议破坏现有功能
- 审查者缺乏完整上下文
- 违反 YAGNI（未使用的功能）
- 技术上对本技术栈不正确
- 存在遗留/兼容性原因
- 与你伙伴的架构决策冲突

**如何反驳：**
- 用技术论据，而非防御性
- 提具体问题
- 引用已有的测试/代码
- 涉及架构问题时拉入你伙伴

**如果不好意思大声反驳：** "Circle K 有奇怪的事"

## 正确反馈的确认

当反馈确实是正确的：

✅ "已修复。[简要描述更改了什么]" ✅ "好发现 —— [具体问题]。已在 [位置] 修复。" ✅ [直接修复并在代码中展示]

❌ "你说得太对了！" ❌ "好观点！" ❌ "谢谢发现！" ❌ "感谢 [任何内容]" ❌ 任何感谢表达


**为什么不感谢：** 行动胜于言语。直接修复就行。代码本身就能说明你听到了反馈。

**如果发现自己要写"谢谢"：** 删除它。直接说明修复内容。

## 优雅地纠正你的反驳

如果你反驳后错了：

✅ "你说得对 —— 我检查了 [X]，它确实 [Y]。现在开始实施。" ✅ "验证后你是正确的。我最初的理解错了，因为 [原因]。正在修复。"

❌ 冗长的道歉 ❌ 为反驳辩护 ❌ 过度解释


实事求是地说明更正，然后继续。

## 常见错误

| 错误 | 修复 |
|---------|---------|
| 表演性认同 | 直接说明需求或直接行动 |
| 盲目实现 | 先对照代码库验证 |
| 批量测试无单独验证 | 一次一个，分别测试 |
| 认为审查者一定对 | 检查是否会破坏功能 |
| 回避反驳 | 技术正确性 > 舒适感 |
| 部分实现 | 先澄清所有项目 |
| 无法验证却继续 | 说明局限性，请求方向 |

## 真实示例

**表演性认同（坏）：**

审查者："删除遗留代码" ❌ "你说得太对了！让我删除它……"


**技术验证（好）：**

审查者："删除遗留代码" ✅ "检查中……构建目标是 10.15+，该 API 需要 13+。需要遗留支持以实现向后兼容。当前实现的 bundle ID 有误——修复它还是放弃 pre-13 支持？"


**YAGNI（好）：**

审查者："用数据库、日期过滤器和 CSV 导出实现正确的指标跟踪" ✅ "在代码库中 grep —— 没有调用此端点。删除它（YAGNI）？还是有我漏掉的使用场景？"


**不清晰项（好）：**

你的人类伙伴："修复项目 1-6" 你理解 1、2、3、6。4 和 5 不清楚。 ✅ "理解 1、2、3、6。需要先对 4 和 5 进行澄清后再实施。"


## GitHub 评论回复

在 GitHub 上回复行内审查评论时，在评论线程中回复（`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`），而非作为 PR 的顶层评论。

## 底线

**外部反馈 = 需要评估的建议，而非必须执行的命令。**

验证。质疑。然后实施。

不表演性认同。始终坚守技术严谨性。

receiving-code-review

接收代码审查

概述

响应模式