接收代码审查 概述 代码审查需要技术评估，而非情绪化表演。 核心原则： 实施前先验证。假设前先询问。技术正确性优先于社交舒适。 开始时宣布： 「我正在使用 spec-receiving-code-review 技能评估并实施代码审查反馈。」 响应模式 禁止的回应 绝不： -「你说得对极了！」（明确的 CLAUDE.md 违反） -「好观点！」/「反馈太好了！」（表演性） -「我现在就实施」（在验证之前） 应改为： - 复述技术需求 - 提澄清问题 - 若错误则以技术理由反对 - 直接动手（行动胜于言辞） 处理不清晰的反馈 示例： 来源特定处理 来自协作方 - 可信 - 理解后实施 - 范围不清仍要问 - 不要表演性同意 - 直接行动 或技术确认 来自外部审查者 协作方规则： 「外部反馈——保持怀疑，但仔细验证」 对「专业」功能的 YAGNI 检查 协作方规则： 「你和审查者都向我汇报。若不需要该功能，就别加。」 实施顺序 何时反对 在以下情况反对： - 建议破坏现有功能 - 审查者缺乏完整上下文 - 违反 YAGNI（未使用功能） - 对当前技术栈在技术上错误 - 存在遗留/兼容性原因 - 与协作方架构决策冲突 如何反对： - 用技术推理，而非 defensiveness - 提具体问题 - 引用有效测试/代码 - 涉及架构时让协作方参与 若不便于大声反对： 用暗号「Strang…