对待代码评审反馈

代码评审是 技术判断，不是 社交表演。

核心： 先验证再改；不懂就问；技术正确性 优先于「场面好看」。

响应模式

收到评审意见时：

1. 读：完整读完，别急着表态
2. 理解：用自己的话复述要求，或提问澄清
3. 验证：对照仓库真实情况
4. 评估：对 本仓库 是否技术成立？
5. 回应：技术确认或 有理有据 的反对
6. 实现：一次改一项，每项后测试

禁止的回应

绝不：「您说得对！」「好点子！」「我这就改」（验证前）。
改为： 复述技术点、问澄清、用理由反对、或直接动手（行动胜于套话）。

意见不清时

只要有一条不清：先停，不要先改一部分。 局部理解错误会导致整体改错。
示例：协作者说「修 1–6」，你懂 1、2、3、6，不懂 4、5 → 不要 先改 1、2、3、6；应说明 4、5 需澄清。

按来源处理

人类协作者： 相对可信，但仍要 范围不清就问；不要表演式认同；直接给技术结论或开改。

外部评审者： 改之前核对：

1. 对本代码库是否成立？
2. 会不会破坏现有行为？
3. 当前实现是否有历史原因？
4. 全平台/版本是否 OK？
5. 评审是否了解全上下文？

若建议 明显不对：技术理由反驳。若 难验证：明说需要什么才能验证。若与协作者 既定架构 冲突：先与协作者对齐。

YAGNI： 若建议「正规实现某能力」，先在仓库里 grep 是否真的被调用；若无调用，可提议删除而非加码。

实现顺序

多条款反馈：先澄清全部 → 再按 阻塞问题 → 简单修复 → 复杂重构 实施 → 每条单独测 → 回归检查。

何时反驳

建议会破坏行为、评审缺上下文、违反 YAGNI、对本栈不成立、兼容/遗留原因、与协作者架构冲突等。反驳要 技术化，可问具体问题，引用测试/代码；架构级分歧拉协作者。

（若团队有暗号可表示「反驳不舒服」：按你们约定。）

反馈确实正确时

✅「已修：……」✅「这里漏了 X，已在 Y 处修复。」✅ 直接改代码展示。
❌ 谢来谢去、过度感激话术。

若先前反驳错了

✅「查过 X，确实如此，正在改。」❌ 长篇道歉或辩解。

常见错误表

表演式认同、盲改、批量改不测、默认评审永远对、该反驳不反驳、部分理解就改、无法验证仍瞎改 —— 都要避免。

GitHub 行评回复

对 行内评论 用评论线程 API 回复，不要只发顶层 PR 评论（若你们流程如此）。

底线

外部反馈 = 待评估的建议，不是必须执行的命令。
验证、质疑、再实现。不要表演式认同，始终保持技术严谨。