（10588期）Receiving Code Review – 技术验证优先，拒绝表演式认同

技术验证优先，拒绝表演式认同 指导开发者以技术严谨性处理代码审查反馈，强调验证而非盲从、行动胜过言辞的工作方法论，避免表演式认同，确保代码质量优先。 使用说明 核心用法 receiving-code-review 是一个行为准则型 Skill，用于规范 AI 助手接收代码审查反馈时的响应模式。它不提供自动化工具，而是通过结构化决策流程指导开发者： 阅读 → 理解 → 验证 → 评估 → 回应 → 实施 的六步响应模式 强制禁止表演式语言（"You're absolutely right!" / "Great point!" / "Thanks!"） 对每项建议进行技术验证：是否适配当前代码库、是否破坏现有功能、是否符合 YAGNI 原则 区分反馈来源：人类合伙人（可信但需确认范围）vs 外部审查者（需 skepticism） 处理不明确反馈时的强制停止机制——必须先澄清全部项目再实施 显著优点 根治行业通病：针对开发者常见的"收到反馈就改"的盲从行为，建立技术验证防火墙 YAGNI 检查机制：通过 grep codebase 验证功能真实使用情况，防止过度工程化 冲突升级路径：明确区分技术分歧与架构决策冲突，后者必须上升给人类合伙人 心理安全设计：提供 "Strange things are afoot at the Circle K" 暗号，允许在不直接说"不"的情况下表达不适 可逆性保障：要求逐项实施、逐项测试，避免批量修改导致的回归问题 潜在缺点与局限性 摩擦成本：严格的验证流程在紧急迭代中可能拖慢节奏，需团队共识支撑 暗语依赖："Circle K" 暗号的文化特异性（美国电影《比尔和泰德的奇异冒险》典故）可能造成理解障碍 外部关系风险：持续的 skepticism 可能损害与外部贡献者的协作关系，需配合礼貌的技术表达 无自动化：纯文档型 Skill，依赖开发者自律执行，无强制校验机制 上下文局限：未覆盖异步审查（如 GitHub PR 已合并后的评论）的特殊处理 适合人群 技术团队负责人，希望统一代码审查响应规范 频繁与外部开源贡献者交互的维护者 在快速迭代中常因"改错方向"浪费工时的开发者 使用 Claude Code 等 AI 编程助手、希望减少 AI 讨好行为的团队 常规风险 执行衰减：文档型 Skill 的 compliance 完全依赖用户记忆，长期可能流于形式 过度推回：新手可能误用"技术推回"机制，将合理建议当作错误拒绝 协作张力：外部审查者可能因缺少正向反馈感到被冷落，需额外沟通成本 原始说明 Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation