用途
本技能用于规范 AI 编程助手在收到代码审查反馈时的行为方式。它强调代码审查需要的是技术评估，而不是情绪表演。核心原则是：先验证再实现，先询问再假设，技术正确性优先于社交舒适。
主要能力
该技能定义了一套完整的响应模式与处理规则：
- 响应流程：收到反馈后依次执行——完整阅读反馈且不立即反应、用自己的话复述需求（或提问）、对照代码库实际情况验证、评估该建议是否适用于当前代码库、给出技术性确认或有理有据的反驳、逐项实现并逐项测试。
- 禁止的回应：明确禁止“你说得完全对！”“好建议！”“优秀反馈！”等表演式回应，也禁止在验证之前就说“我现在就实现”。替代做法是复述技术需求、提出澄清问题、用技术理由反驳错误建议，或直接开始工作（行动胜于言辞）。
- 处理不明确的反馈：只要有任何一项不明确，就应停止，先澄清再实现。因为各项反馈可能相互关联，部分理解会导致错误实现。例如对方说“修复 1-6 项”，你只理解 1、2、3、6，正确做法是先说明理解范围并请求澄清 4、5，而不是先做已理解的部分。
- 区分反馈来源：来自人类搭档的反馈视为可信，理解后即可实现，但范围不清时仍需询问，且不做表演式认同；来自外部审查者的反馈则需在实现前核查：是否对当前代码库技术正确、是否破坏现有功能、当前实现的原因是什么、是否在所有平台/版本上可用、审查者是否了解完整上下文。若建议看似错误，用技术理由反驳；若无法轻易验证，应说明“没有 X 我无法验证，是否应调查/询问/继续”；若与人类搭档此前的决策冲突，应先停下与搭档讨论。
- YAGNI 检查：当审查者建议“正确实现”某功能时，先在代码库中搜索实际使用情况。若未被使用，可提出“该端点无人调用，是否按 YAGNI 移除”；若确有使用，再正确实现。
- 实现顺序：多项反馈时，先澄清所有不明确项，然后按顺序实现——阻塞性问题（破坏、安全）、简单修复（拼写、导入）、复杂修复（重构、逻辑），每项单独测试，并验证无回归。
- 何时反驳：当建议破坏现有功能、审查者缺乏完整上下文、违反 YAGNI、对当前技术栈技术不正确、存在遗留/兼容性原因、或与人类搭档的架构决策冲突时，应进行反驳。反驳方式是用技术推理而非防御性态度、提出具体问题、引用可用的测试/代码，涉及架构时让人类搭档介入。
- 确认正确反馈：当反馈正确时，用“已修复。[简述改动]”“好发现——[具体问题]，已在[位置]修复”或直接修复并在代码中体现。禁止任何感谢表达，因为行动本身已表明你听到了反馈。
- 优雅地纠正自己的反驳：若反驳后发现自己错了，应事实性地说明“你是对的——我检查了 X，它确实 Y，现在实现”，避免冗长道歉、为反驳辩护或过度解释。
- GitHub 线程回复：回复 GitHub 内联审查评论时，应在评论线程中回复（
gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies），而不是作为顶层 PR 评论。
使用方式
该技能以提示词/规则文档形式提供，供 AI 编程助手在接收到代码审查反馈的场景中加载并遵循。文档中包含常见错误对照表（如表演式认同、盲目实现、未测试就批量修改、假设审查者一定正确、回避反驳、部分实现、无法验证仍继续等）及对应的修正方式，并附有真实示例说明正确与错误做法。
适用场景
适用于 AI 编程助手参与代码审查流程、收到来自人类搭档或外部审查者的反馈并准备修改代码的任何时刻，尤其当反馈不清晰或技术上存疑时。
限制
资料未提供该技能的具体安装方式、依赖环境、支持的平台或版本信息，暂未提供。