（2357期）receiving-code-review – 技术优先的代码审查响应指南

技术优先的代码审查响应指南 来自个人开发者的代码审查反馈处理指南，强调技术验证优先于社交表演，帮助开发者建立严谨的代码审查响应流程。 使用说明 核心用法 该 Skill 是一套处理代码审查反馈的行为规范指南，核心目标是消除"表演式同意"，建立技术优先的审查响应流程。使用时遵循"READ-UNDERSTAND-VERIFY-EVALUATE-RESPOND-IMPLEMENT"六步模式：先完整阅读反馈、用自己的话重述需求、对照代码库验证、评估技术合理性、给出技术回应或合理反驳、最后逐项实施并测试。 显著优点 反表演设计：明确禁止"You're absolutely right!"等社交辞令，强制用技术事实替代情绪劳动 防御性思维：针对外部审查者设置五重验证清单（技术正确性、功能破坏性、原实现理由、跨平台兼容性、上下文完整性） YAGNI 检查机制：提供具体命令（grep 代码库）验证"专业级功能"是否真有调用，避免过度工程 分级处理策略：区分"人类伙伴"（高信任，可跳过验证）与"外部审查者"（需 skepticism）的不同响应方式 纠错礼仪：即使反驳错误也能体面承认，用"You were right - I checked [X]"替代冗长道歉 潜在缺点与局限性 文化冲突风险：在强调"心理安全"的团队中，直接反驳可能引发人际摩擦 上下文依赖："人类伙伴"的信任关系需要预先建立，新团队难以直接套用 无自动化能力：纯文档指南，不提供与 GitHub/GitLab API 的集成，无法自动拉取 PR 评论 特定技术栈假设：示例中的 grep、gh CLI 等命令暗示 Unix-like 环境，Windows 开发者需适配 暗号机制隐患："Strange things are afoot at the Circle K"作为求助信号，若团队未统一认知会失效 适合的目标群体 技术驱动型团队的资深开发者，尤其是担任代码审查主导角色的人员 开源项目维护者，需要处理大量外部 PR 反馈 远程协作团队，文字沟通占比高、需减少误解的场景 经历过"盲目实施错误建议导致生产事故"的技术负责人 使用风险 流程摩擦成本：严格执行六步模式可能延长简单修复的响应时间 团队规范冲突：若组织已有强制的"感谢文化"，该 Skill 的"禁止感谢"规则可能引发合规问题 过度自信陷阱："VERIFY"步骤依赖使用者自身的技术判断力，经验不足者可能误判正确建议 无版本控制：作为个人项目（T3 来源），内容更新不受企业 SLA 约束，关键规则变更无通知机制 原始说明 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