该技能面向 AI 编程助手与开发者，用于处理“收到代码审查反馈之后、开始修改代码之前”这一环节。它把代码审查视为技术评估而非情绪表演，核心原则是先验证再实现、先询问再假设，技术正确性优先于社交舒适。
用途与定位：帮助接收方在落实审查建议前，判断建议是否适用于当前代码库，避免盲目照做或表演式认同。
主要能力与流程：文档给出固定响应模式——完整阅读反馈、用自己的话复述需求（或提问）、对照代码库实际验证、评估建议对当前代码库是否技术合理、给出技术性确认或有理据的反驳、逐项实现并逐项测试。明确禁止“你说得完全对！”“好建议！”等表演式回应，以及未验证就宣称“我现在就实现”。对于表述不清的反馈，要求先停止实现、澄清所有不明确条目，因为条目之间可能相关，部分理解会导致错误实现。
来源区分处理：来自人类伙伴的反馈被视为可信，理解后即可实现，但范围不清仍需询问；来自外部审查者的建议，需先检查其是否适用于当前代码库、是否破坏既有功能、现有实现的理由、平台与版本兼容性，以及审查者是否掌握完整上下文。若建议看起来有误，应以技术理由反驳；若难以验证，应说明限制并询问是调查、求证还是继续；若与人类伙伴既有决策冲突，应先与人类伙伴讨论。
YAGNI 检查：当审查者建议“规范实现”某个功能时，先在代码库中搜索实际调用；若未被使用，可提出移除；若确有使用，再规范实现。
实现顺序：先澄清所有不明确项，再按阻塞性问题（崩溃、安全）、简单修复（拼写、导入）、复杂修复（重构、逻辑）的顺序处理，逐项测试并验证无回归。
反驳与纠错：当建议破坏既有功能、审查者缺乏上下文、违反 YAGNI、对当前技术栈不正确、存在遗留或兼容性原因、或与人类伙伴架构决策冲突时，应基于技术理由反驳，提出具体问题，引用可运行的测试或代码，架构层面的分歧需引入人类伙伴。若反驳后被证明有误，应事实性说明并继续，而非冗长道歉或辩解。
GitHub 场景：回复行内审查评论时，应在对应评论线程中回复，而不是发布为 PR 顶层评论。
适用场景：代码评审后的沟通、建议评估与分批落实；外部贡献者反馈处理；多人协作中的技术分歧处理。
限制：该内容为行为准则类指南，不提供自动化工具、代码生成或平台集成能力；具体项目规则与团队约定需以实际环境为准。