sendback

一份餐盘从餐厅退回厨房。真正能持续运转的厨房，是在重做菜品前先检查餐盘：有时是菜品做错了，有时是单据开错了，有时是顾客点错了。凭直觉重做会浪费食材；凭直觉争辩则会失去顾客。这项技能，就是将同样的检查机制应用于评审反馈：先验证，再实施或驳回，并始终以技术原因为依据。

核心原则：评审反馈是一组待验证的主张，既不是必须执行的指令，也不是需要取悦的观众。评审人的职级高低毫无影响；代码库才是唯一权威。

操作模式

对每一条反馈，严格按以下顺序处理：

1. 通读全部反馈，再开始回应任何一条。 各条目之间存在关联；第 4 条可能彻底改变第 1 条的含义。
2. 清晰性关卡（Clarity gate）。 若你无法对某条反馈作出具体、可复现的重述（例如，“加载器问题仍需处理”——具体是哪个问题？以何种方式处理？），则整批反馈暂停处理。须先就模糊条目向评审人提问，再实施明确条目；靠猜测得出的理解，实为无人做出的设计决策，而基于片面理解的“自信实现”，只会坚定地做出错误改动。唯一例外：若某条反馈可被明确证明与所有模糊条目完全无关，则可先行处理，并在回复中清晰说明此情况。
3. 逐条验证反馈主张是否符合代码库现状。 该建议是否会破坏现有行为或违反已文档化的契约？是否有测试用例刻意锚定了当前行为？当前代码为何如此实现？务必实际运行验证（如 grep 搜索、运行测试、编写五行复现代码），切勿仅凭记忆主观裁决。
4. YAGNI 关卡（针对“也应支持……”类建议）。 使用 grep 查找调用方。若提议的参数、协议或灵活性在代码树中没有任何调用者，则答案应为：“无调用方——跳过（YAGNI）”，而非盲目扩展 API 表面。评审人和你都服务于用户；用户不需要的功能，对双方均无价值。
5. 然后逐条行动，严格按序推进： 阻塞性问题 → 简单修复 → 复杂修复。每完成一项即运行测试，再进入下一项；评审修复如同其他任何变更，同样须经“尝味”验证（即实测确认）。
6. 回复须言之有物。 明确说明：哪些已落实（含具体位置），哪些已驳回（附技术依据），哪些尚待澄清。用证据说话，而非形容词堆砌。

驳回反馈

当建议会导致行为破坏、违背已文档化的契约或被固定测试所锚定的行为、引入未被使用的表面、误读调用栈，或与用户已明确做出的架构决策相冲突时，应予以驳回。须引用具体证据：失败的复现代码、grep 结果、契约原文行号等。若冲突源于用户自身架构设计，则相关讨论应上升至用户层面，而非在评审线程内解决。

若你曾驳回但后续确认判断错误，请用一句话说明（例如：“已验证——您是对的，X 确实执行 Y。正在修复。”），随即继续推进。无需冗长致歉，亦无需为原始驳回行为辩护。

禁止使用的回复方式

• “您完全正确！” / “好观点！” / “精彩发现！”——属于表演式认同，毫无实质信息，且当你后续不得不提出异议时，将严重损害可信度。
• 所有以“感谢您的反馈”或其他类似致谢语开头的回复。修复后的代码本身，就是最有力的认可。
• 尚未验证主张真实性，就承诺“我马上实现这个”。
• 为迎合评审人偏好而弱化或重写已被固定（pinned）的测试。测试即契约；修改测试属于用户决策范畴。

只需陈述需求、陈述发现，或直接展示修复结果。

常见错误

• 为模糊条目自行臆造具体含义并直接交付。例如，对所谓“加载器修复”进行未经确认的实现，却意外改变了读取路径行为——这实为披着评审外衣的静默式设计变更。
• 仅因评审人职级较高，便采纳缺乏任何调用方的推测性参数或协议支持。权威不等于使用率。
• 折中处理：在某条模糊反馈尚未澄清时，先行实现其余明确条目；待最终澄清后，又不得不推倒重来。
• 表演式认同后悄无声息地拒绝执行——兼具两种缺陷之最坏情形。
• 将机器人评审员（bot reviewers）奉为圭臬或视为噪音。对待方式应与人类评审一致：验证其主张。
• 仅凭对代码库的“记忆”驳回反馈，而非基于你刚刚运行过的实际检查结果。