Receiving Code Review

核心用法

receiving-code-review 是一个行为准则型 Skill，用于规范 AI 助手接收代码审查反馈时的响应模式。它不提供自动化工具，而是通过结构化决策流程指导开发者：

1. 阅读 → 理解 → 验证 → 评估 → 回应 → 实施 的六步响应模式
2. 强制禁止表演式语言（"You're absolutely right!" / "Great point!" / "Thanks!"）
3. 对每项建议进行技术验证：是否适配当前代码库、是否破坏现有功能、是否符合 YAGNI 原则
4. 区分反馈来源：人类合伙人（可信但需确认范围）vs 外部审查者（需 skepticism）
5. 处理不明确反馈时的强制停止机制——必须先澄清全部项目再实施

显著优点

• 根治行业通病：针对开发者常见的"收到反馈就改"的盲从行为，建立技术验证防火墙
• YAGNI 检查机制：通过 grep codebase 验证功能真实使用情况，防止过度工程化
• 冲突升级路径：明确区分技术分歧与架构决策冲突，后者必须上升给人类合伙人
• 心理安全设计：提供 "Strange things are afoot at the Circle K" 暗号，允许在不直接说"不"的情况下表达不适
• 可逆性保障：要求逐项实施、逐项测试，避免批量修改导致的回归问题

潜在缺点与局限性

• 摩擦成本：严格的验证流程在紧急迭代中可能拖慢节奏，需团队共识支撑
• 暗语依赖："Circle K" 暗号的文化特异性（美国电影《比尔和泰德的奇异冒险》典故）可能造成理解障碍
• 外部关系风险：持续的 skepticism 可能损害与外部贡献者的协作关系，需配合礼貌的技术表达
• 无自动化：纯文档型 Skill，依赖开发者自律执行，无强制校验机制
• 上下文局限：未覆盖异步审查（如 GitHub PR 已合并后的评论）的特殊处理

适合人群

• 技术团队负责人，希望统一代码审查响应规范
• 频繁与外部开源贡献者交互的维护者
• 在快速迭代中常因"改错方向"浪费工时的开发者
• 使用 Claude Code 等 AI 编程助手、希望减少 AI 讨好行为的团队

常规风险

• 执行衰减：文档型 Skill 的 compliance 完全依赖用户记忆，长期可能流于形式
• 过度推回：新手可能误用"技术推回"机制，将合理建议当作错误拒绝
• 协作张力：外部审查者可能因缺少正向反馈感到被冷落，需额外沟通成本

核心用法

receiving-code-review 是一套代码审查反馈处理工作流，核心目标是将代码审查从"社交互动"还原为"技术验证"。其使用场景明确限定为：收到代码审查反馈后、实施修改前，尤其适用于反馈内容模糊或存在技术疑点时。

使用流程遵循六步响应模式：
1. READ - 完整阅读反馈不做反应
2. UNDERSTAND - 用自己的话重述需求或提问
3. VERIFY - 对照代码库实际状态验证
4. EVALUATE - 判断技术方案是否适应当前代码库
5. RESPOND - 技术确认或有理有据地反驳
6. IMPLEMENT - 逐项实施，每项单独测试

显著优点

彻底杜绝表演性沟通是该 Skill 最鲜明的特质。它明确禁止"You're absolutely right!"、"Great point!"、"Thanks for..."等社交化表达，代之以技术事实陈述或直接行动。这种设计直击开发者常见痛点：过度追求"评审者满意度"而牺牲技术正确性。

来源分级处理机制极具实践智慧。对人类合作伙伴（your human partner）的信任度高于外部评审者，但仍要求技术验证；对外部反馈则强制进行五维度检查（技术正确性、功能破坏性、原有实现理由、跨平台兼容性、评审者上下文完整性），并保留有理有据的反驳权。

YAGNI（You Aren't Gonna Need It）检查是另一亮点。当评审者建议"proper implementation"时，强制要求先在代码库中 grep 实际调用情况，避免为未使用的端点过度工程化。

安全与隐私表现优异。纯 Markdown 文档型 Skill，零可执行代码、零外部依赖、零网络调用，CLS-Certify 扫描获得 S+ 评级（100分），所有合规项（GDPR、CCPA、权限审查、敏感数据保护等）均通过。

潜在局限性

文化适应性挑战。该 Skill 的"零感谢"原则与多数技术团队的沟通习惯存在张力。完全剔除正向反馈可能被视为冷漠或对抗性，尤其在需要维护长期协作关系的场景中。

反驳门槛未量化。

"有理有据地反驳"的标准依赖使用者主观判断，新手开发者可能因经验不足而过度服从或过度抵触。

多层级反馈处理复杂度。同时处理人类合作伙伴与外部评审者的冲突建议时，要求"先与 human partner 讨论"，这在异步协作环境中可能阻塞进度。

适合人群

• 技术决策者需要保护代码库免受"评审驱动设计"侵蚀
• 团队存在"评审者话语权过大"导致过度工程化的痛点
• 开发者希望减少代码审查中的情绪劳动，聚焦技术实质
• 项目采用 YAGNI 原则，需要抵御不必要的功能扩张

常规风险

主要风险在于使用过度。若机械执行"零感谢"原则，可能在需要社交润滑的跨团队场景中制造摩擦。建议将核心原则（验证优先）与表达形式（零感谢）区分对待——前者应严格执行，后者可根据团队文化适度调整。

T3 来源可信度（个人开发者账号）虽因纯文档性质风险可控，但后续若引入可执行代码或外部依赖，需重新评估。

---

安全认证报告摘要：CLS-Certify v2.1.0 全扫描，0 项安全发现，S+ 评级，T3 来源，纯 Markdown 零依赖