receive-review

接收评审意见

将评审反馈视为需要评估的技术主张，而不是需要遵从的命令或需要回报的善意。正确比迎合更重要。

流程

1. 阅读每条意见，读完再回应。完成标准：你已掌握完整清单。
2. 理解——用自己的话复述每条意见。任何无法复述的意见都不清楚：立即停下，先询问所有不清楚的意见，再实现任何一项。意见之间会相互影响；理解不完整会导致自信满满地实现错误内容。完成标准：每条意见都已复述或提出疑问。
3. 核实每项主张，并对照实际代码库进行检查。评审者说某个函数忽略了错误？打开该函数。评审者说某条路径已失效？追踪调用方。完成标准：每项意见都已确认、驳回或标记为无法核实。
4. 评估——这项建议适合这个代码库吗？会破坏现有行为、平台支持或用户已经做出的决定吗？是否适用 YAGNI 原则：评审者说“把它正确实现”，先搜索实际用法——如果没有任何地方调用它，正确的修复方式就是移除，并提出这个方案。完成标准：每项意见都有明确立场：同意、反对或改为移除。
5. 回应时给出技术理由。同意时引用证据；反对时指出具体细节——代码、测试、约束——并提出有针对性的问题。如果无法核实某项主张，准确说明这一点，并询问如何继续。如果某项建议与用户先前的架构决策冲突，先告知用户，再采取行动。完成标准：每项意见都有明确立场。
6. 实现时一次处理一项，并按以下顺序进行：阻塞项（故障、安全问题）→ 简单修正（拼写错误、导入）→ 复杂改动（逻辑、重构）。每项修复都必须是生产代码——必需子技能：使用 tdd。完成标准：每项修复都有单独通过的测试运行，且没有回归问题。

禁止的回应

绝不要写：“你说得完全正确”“好建议”“发现得好，谢谢”，任何形式的“谢谢”，或其他表演式的赞同或感谢开场白。说明修复内容，而不是感受：“已修复——parseRange 现在会拒绝边界顺序颠倒的范围（parser.ts:88）。”差异本身就是认可。

信息来源的校准

• **用户：**可信——核实范围后采取行动。仍然不要使用表演式的赞同。
• **评审子 Agent：**没有先验可信度——其主张与其他主张一样，按相同的核实步骤处理。
• **外部评审者：**应更加审慎——他们缺乏完整背景。检查建议是否适用于当前技术栈、兼容性下限和架构。但不要未经检查就驳回：审慎意味着核实，而不是本能地说“不”。

反对后发现自己错了

直截了当地说明并修正：“已核实——你说得对，10.x 上的 API 确实要求使用较旧的签名。正在修复。”不要长篇道歉，也不要为最初的反对辩解。

自我开脱

想法	事实
“快速同意能让评审过程更融洽”	未经核实就同意，会以你的名义提交评审者的错误。
“我先修复理解的项目，之后再询问其余项目”	意见之间会相互影响；分批处理会导致实现错误理解的内容。先把所有问题澄清清楚。
“评审者资历高，肯定是对的”	资历不能代替阅读代码。先核实。
“实现建议比争论更容易”	“正确地”构建未使用的功能，是双重浪费。先搜索。
“快速说句‘谢谢，发现得好！’也没什么”	这会消耗你的可信度：带着赞美的回复会让人觉得你根本没检查。
“反对会显得很防御”	有证据支撑的反对，正是评审发挥作用的表现。沉默才是问题。

危险信号 — 停下并重新开始整个流程

• 你还没打开任何文件，就先输入了表示感谢或赞同的话。
• 第 5 项仍有歧义，你却已经在编辑第 2 项的代码。
• 你在“正确地实现”某项功能，却从未确认是否有调用方。
• 你没有在代码中核实，就驳回了外部审查者提出的问题。
• 你把所有修复都合并到一个提交中，最后才运行一次测试。