接收代码审查 (receiving-code-review)

接收代码审查（receiving-code-review）

概述

receiving-code-review 是与 requesting-code-review 配对的 Skill。它解决的问题是：

如何正确处理收到的审查反馈？

很多开发者的本能反应是：

“你说得对！”
“好建议，我这就改！”
“谢谢反馈！”

但这些反应的问题在于：

没有验证建议是否真的适用于这个代码库
没有检查是否会有副作用
表面认同不等于真正理解

receiving-code-review 的核心原则非常清晰：

验证后再实现。不明白就问。技术正确性 > 社会舒适度。

响应模式

收到代码审查反馈时：

1. 阅读：不要立刻反应，先完整阅读反馈
2. 理解：用自己话复述需求（或者直接问）
3. 验证：对照代码库现实检查
4. 评估：对这个代码库技术上是否合理？
5. 回应：技术确认或带理由的反驳
6. 实现：一次一个，测试每个

禁止的回应

永远不要：

“你说得完全对！“（明确违反）
“好观点！” / “绝佳反馈！“（表面表演）
“我这就去实现”（验证前不动手）

正确做法：

复述技术需求
提澄清问题
如果错了，用技术理由反驳
直接开始干活（行动 > 言语）

处理不清晰的反馈

如果任何项不清楚：
  停下来 - 还没实现任何东西
  先问清楚不清晰的项

原因：项之间可能有联系。_partial 理解 = 错误实现

示例：

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

❌ 错误：先实现 1,2,3,6，之后再问 4,5
✅ 正确："我理解 1,2,3,6。在继续之前需要澄清 4 和 5。"

来源特定处理

来自人类伙伴

可信 - 理解后实现
范围不清仍然要问
不要表面同意
直接到行动或技术确认

来自外部审查者

实现前检查：
  1. 检查：对这个代码库技术上正确吗？
  2. 检查：破坏现有功能吗？
  3. 检查：当前实现的原因是什么？
  4. 检查：所有平台/版本都工作吗？
  5. 检查：审查者是否理解完整上下文？

如果建议看起来错了：
  用技术理由反驳

如果不容易验证：
  说出来："没有 X 我无法验证。应该我[调查/询问/继续]？"

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

YAGNI 检查

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

  如果未使用："这个端点没有被调用。移除它 (YAGNI)？"
  如果使用了：那正确实现

实现顺序

多项反馈：
  1. 先澄清任何不清楚的
  2. 然后按这个顺序实现：
     - 阻塞问题（破坏、安全）
     - 简单修复（拼写、导入）
     - 复杂修复（重构、逻辑）
  3. 每个修复单独测试
  4. 验证无回归

何时反驳

可以反驳当：

建议破坏现有功能
审查者缺乏完整上下文
违反 YAGNI（未使用的功能）
对这个技术栈技术上不正确
存在遗留/兼容性原因
与人类伙伴的架构决定冲突

如何反驳：

用技术理由，不是防御性
提具体问题
参考能工作的测试/代码
如果是架构问题，找人类伙伴

承认正确反馈

当反馈确实正确时：

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

❌ "你说得完全对！"
❌ "好观点！"
❌ "谢谢！"
❌ 任何感谢表达

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

如果你发现自己要写”谢谢”：删掉它。说修复了什么。

速查卡片

何时使用

收到任何代码审查反馈时
反馈不清楚时
建议看起来有问题时
建议可能违反 YAGNI 时

关键要点

先读完整反馈再反应
验证建议是否适用于此代码库
不清楚就问
技术正确性 > 表面礼貌

禁止行为

“你说得对！”
“好建议！”
不验证就实现
批量实现不测试

正确做法

用自己话复述需求
先澄清不清楚的项
一次实现一个，测试每个
用技术理由反驳

关联 Skill

前置：requesting-code-review（发起审查）。
互补：verification-before-completion（修复后的验证）、subagent-driven-development（处理子代理反馈）。

查看源文件: GitHub原始文件