receiving-code-review

name	receiving-code-review
description	在接收代码评审意见并准备落地前使用，尤其适用于评审意见不清晰或技术上可疑时。要求先验证再实现，避免表演式认同和盲从执行。

接收代码评审

核心原则

技术正确性优先于情绪表达：先验证，再实现；先澄清，再行动。

标准流程

1. 完整阅读评审意见，不抢答。
2. 用自己的话复述理解；不清楚就提问。
3. 对照代码库事实验证。
4. 评估该建议是否适用于“当前代码库上下文”。
5. 给出技术确认或有理有据的反驳。
6. 分项实现并逐项验证。

禁止行为

• 表演式附和（如“你完全正确”）。
• 未验证先承诺立刻改。
• 对不清晰项先做部分实现。

不清晰意见处理

• 任一条目不清晰，先停下并澄清。
• 多条目任务中，不允许“先做懂的、后问不懂的”。

来源差异处理

• 来自用户：默认高优先级，但范围不清仍需确认。
• 来自外部审查者：先验证正确性、兼容性、上下文完整性。
• 与既有架构决策冲突：先与用户对齐再执行。

何时应反驳

• 建议会破坏现有行为。
• 建议忽略了上下文或兼容约束。
• 明显违反 YAGNI（无调用路径的“完善性需求”）。

实施顺序建议

1. 阻断性问题（安全/崩溃/错误行为）
2. 低成本修复（拼写/导入/配置）
3. 复杂修复（逻辑/结构）

每一项修后立即验证，避免批量堆叠。

底线

外部评审是“待评估建议”，不是“无需判断的指令”。