指导开发者以技术严谨性处理代码审查反馈,强调验证而非盲从、行动胜过言辞的工作方法论,避免表演式认同,确保代码质量优先。
基本信息
- 技能名称?Receiving Code Review
- 中文名称?技术验证优先,拒绝表演式认同
- 作者?chenleiyanquan
- 分类?专业技能
- 版本?0.1.0
- 标签?code-review, technical-rigor, yagni, communication, best-practices, developer-hygiene, skepticism, agile, clean-code, team-collaboration
使用方法
使用说明
核心用法
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 完全依赖用户记忆,长期可能流于形式
过度推回 :新手可能误用"技术推回"机制,将合理建议当作错误拒绝
协作张力 :外部审查者可能因缺少正向反馈感到被冷落,需额外沟通成本
💬 评论 (0)
📭 还没有评论,快来抢沙发吧!