用途
本技能用于在收到代码审查反馈之后、实施建议之前，指导开发者如何以技术严谨的方式处理反馈。它适用于反馈不明确或技术上有疑问的场景，目标是避免敷衍附和、盲目执行，确保每一项改动都经过验证。
核心原则
先验证再实施，先提问再假设，技术正确性优先于社交舒适度。外部反馈被视为待评估的建议，而不是必须执行的命令。
响应模式
收到代码审查反馈时，按以下步骤进行：
- 阅读：完整阅读反馈，不急于反应。
- 理解：用自己的话复述需求，或提出提问。
- 验证：对照代码库的实际情况检查。
- 评估：判断对这个代码库来说技术上是否合理。
- 回应：给出技术性确认或有理有据的反驳。
- 实施：一次一项，逐个测试。
禁止的回应
绝不要说“你说得太对了！”“好观点！”“反馈很棒！”“让我立刻实施”等敷衍或未经验证就行动的表述。应该复述技术需求、提出澄清性问题、在审查意见有误时用技术理由反驳，或直接动手做。
处理不明确的反馈
如果有任何一项不明确，应停下来，先不要实施任何内容，就不明确的项目提出澄清。因为各项之间可能有关联，部分理解可能导致错误实施。例如搭档要求“修复第 1-6 项”，你理解 1、2、3、6，对 4、5 不确定，正确做法是说明已理解的部分，并请求澄清 4、5 后再动手。
按来源区别处理
来自搭档的反馈：可信赖，理解后直接实施；范围不明确时仍然要问；不要敷衍附和；直接行动或给出技术性确认。
来自外部审查者的反馈：实施之前需检查技术上是否正确、是否会破坏现有功能、当前实现是否有原因、是否在所有平台/版本上适用、审查者是否了解完整上下文。如果建议似乎有误，用技术理由反驳；如果无法轻易验证，说明限制并请求指导；如果与搭档之前的决策冲突，先停下来和搭档讨论。
YAGNI 检查
针对“专业化”功能建议，在代码库中 grep 实际使用情况。如果没人用，可以提出删除（YAGNI）；如果有人用，则正规实现。
实施顺序
对于包含多项的反馈：先澄清所有不明确的项；然后按阻塞性问题（崩溃、安全）、简单修复（拼写、导入）、复杂修复（重构、逻辑）的顺序实施；逐个测试每项修复；验证没有回归。
何时反驳
在建议会破坏现有功能、审查者缺少完整上下文、违反 YAGNI、对当前技术栈技术上不正确、存在遗留/兼容性原因、与搭档的架构决策冲突等情况下应反驳。反驳时用技术理由，不带防御情绪，提出具体问题，引用可正常工作的测试/代码，涉及架构问题时让搭档参与。
确认正确的反馈
当反馈确实正确时，直接说明修复内容，例如“已修复。[简要说明改了什么]”或“发现得好——[具体问题]。已在 [位置] 修复。”避免任何感谢表达，因为行动说明一切。
优雅地纠正自己的反驳
如果反驳后发现自己错了，如实陈述纠正，例如“你是对的——我检查了 [X]，确实 [Y]。正在实施。”避免长篇道歉、为自己的反驳辩护或过度解释。
常见错误与修正
敷衍附和应改为复述需求或直接行动；盲目实施应先对照代码库验证；批量实施不测试应改为一次一项逐个测试；假设审查者一定对应检查是否会破坏现有功能；回避反驳应记住技术正确性优先于社交舒适度；部分理解就开始实施应先澄清所有项；无法验证却继续推进应说明限制并请求指导。
GitHub 评论回复
在 GitHub 上回复行内审查评论时，应在评论线程中回复（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies），不要发顶层 PR 评论。
限制
本技能为方法论指南，不包含具体代码实现或自动化工具。其效果取决于使用者对代码库的了解和判断能力。