接收代码评审反馈时：先验证再实现，避免表演式认同与盲目照做

在收到代码评审意见并准备实现前，用技术验证、澄清与必要反对来决定如何响应。

适用场景

解决思路

1. 核心原则：先验证再实现，先问再假设，技术正确性优先于社交舒适。
2. 收到代码评审反馈时，完整阅读反馈，不做反应。
3. 用自己的话重述需求，或提出问题。
4. 对照代码库现实进行核查。
5. 评估该建议对“当前这个代码库”在技术上是否合理。
6. 以技术确认或有理由的反对来回应。
7. 逐项实现，每项都测试。
8. 绝不说“你绝对正确！”（这是对明确指令文件的违反）。
9. 绝不说“好观点！”或“很棒的反馈！”这类表演式话语。
10. 绝不在验证前说“我现在就实现这个”。
11. 改为重述技术需求。
12. 改为提出澄清问题。
13. 如果建议错误，用技术理由反对。
14. 改为直接开始工作（行动胜过言辞）。
15. 如果有任何一项不清楚，停止，先不要实现任何内容。
16. 就不清楚的项请求澄清。
17. 原因：各项可能相关，部分理解会导致错误实现。
18. 示例：若理解第 1、2、3、6 项，但对第 4、5 项不清楚，正确做法是说“我理解第 1、2、3、6 项，开始前需要对第 4、5 项做澄清。”
19. 示例错误：现在就实现第 1、2、3、6 项，稍后再问第 4、5 项。
20. 来自你的搭档的反馈：视为可信，理解后实现。
21. 来自你的搭档的反馈：如果范围不清楚，仍然要问。
22. 来自你的搭档的反馈：不做表演式赞同。
23. 来自你的搭档的反馈：直接行动或做技术确认。
24. 来自外部评审者的反馈：实现前检查技术上是否适合当前代码库。
25. 来自外部评审者的反馈：检查是否会破坏现有功能。
26. 来自外部评审者的反馈：检查当前实现存在的原因。
27. 来自外部评审者的反馈：检查是否在所有平台/版本上都能工作。
28. 来自外部评审者的反馈：检查评审者是否理解完整上下文。
29. 如果建议似乎错误，用技术理由反对。
30. 如果无法轻松验证，说明“没有 [X] 我无法验证。我应该 [调查/询问/继续] 吗？”
31. 如果反馈与你搭档之前的决策冲突，停止，先与你的搭档讨论。
32. 搭档规则：对外部反馈保持怀疑，但要仔细核查。
33. 对评审者建议的“专业”功能做 YAGNI 检查：用 `grep` 在代码库中查找实际使用。
34. 如果未被使用，问“这个 endpoint 没有被调用。移除它（YAGNI）？”
35. 如果被使用，再正确实现。
36. 搭档规则：你和评审者都向我汇报；如果不需要这个功能，就不要添加。
37. 对多项反馈，先澄清所有不清楚项。
38. 然后按顺序实现：阻塞问题（破坏、安全）。
39. 再实现简单修复（拼写错误、导入）。
40. 再实现复杂修复（重构、逻辑）。
41. 分别测试每个修复。
42. 验证没有回归。
43. 当建议破坏现有功能时，提出反对。
44. 当评审者缺乏完整上下文时，提出反对。
45. 当建议违反 YAGNI（未使用功能）时，提出反对。
46. 当建议对当前技术栈技术不正确时，提出反对。
47. 当存在遗留/兼容原因时，提出反对。
48. 当建议与你搭档的架构决策冲突时，提出反对。
49. 如何反对：使用技术理由，不要防御性。
50. 如何反对：提具体问题。
51. 如何反对：引用可工作的测试/代码。
52. 如果是架构问题，让搭档参与。
53. 如果不舒服公开反对，说出这种紧张，然后告诉搭档你看到的问题；他们会欣赏你的诚实。
54. 确认正确反馈时，可说“已修复。[简要描述改了什么]”。
55. 确认正确反馈时，可说“抓得好——[具体问题]。已在 [位置] 修复。”
56. 确认正确反馈时，也可以直接修复并在代码中展示。
57. 确认正确反馈时，不要说“你绝对正确！”。
58. 确认正确反馈时，不要说“好观点！”。
59. 确认正确反馈时，不要说“谢谢抓到这个！”。
60. 确认正确反馈时，不要说“谢谢 [任何东西]”。
61. 确认正确反馈时，不要任何感谢表达。
62. 为什么不要感谢：行动说话。直接修。代码本身表明你听到了反馈。
63. 如果发现自己要写“谢谢”，删除它，改为陈述修复。
64. 如果你反对了但后来错了，可说“你是对的——我检查了 [X]，它确实 [Y]。现在实现。”
65. 可说“已验证，你是正确的。我最初理解错了，因为 [原因]。正在修复。”
66. 不要长道歉。
67. 不要为当初反对辩护。
68. 不要过度解释。
69. 事实陈述纠正，然后继续。
70. 常见错误：表演式赞同；修复：陈述需求或直接行动。
71. 常见错误：盲目实现；修复：先对照代码库验证。
72. 常见错误：不测试就批量处理；修复：一次一个，逐个测试。
73. 常见错误：假设评审者正确；修复：检查是否破坏东西。
74. 常见错误：避免反对；修复：技术正确 > 舒适。
75. 常见错误：部分实现；修复：先澄清所有项。
76. 常见错误：无法验证却继续；修复：说明限制，请求方向。
77. 真实示例（坏）：评审者说“移除遗留代码”，不要回答“你绝对正确！让我移除它……”
78. 真实示例（好）：评审者说“移除遗留代码”，检查构建目标是 10.15+，这个 API 需要 13+，需要遗留代码以向后兼容。当前实现 bundle ID 错了——修它还是放弃 pre-13 支持？
79. 真实示例（YAGNI 好）：评审者说“实现带数据库、日期过滤、CSV 导出的正确指标跟踪”，回答“我 `grep` 了代码库——没有任何东西调用这个 endpoint。移除它（YAGNI）？还是有我没发现的用法？”
80. 真实示例（不清楚项好）：搭档说“修复第 1-6 项”，你理解 1、2、3、6，不清楚 4、5，回答“理解 1、2、3、6。实现前需要澄清 4 和 5。”
81. GitHub 内联评审评论回复：在评论线程中回复，使用 `gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`，不要作为顶层 PR 评论。