用途：在收到代码审查反馈之后、动手实施之前使用，把反馈当成需要技术评估的输入，而不是情绪表演。核心原则是先验证再实施、先提问再假设，技术正确性优先于社交舒适度。
主要能力：给出响应流程——完整阅读、用自己的话复述需求或提问、对照代码库实际情况验证、评估技术上是否合理、技术性确认或有理有据地反驳、一次一项地实施并逐个测试。区分反馈来源：来自搭档的反馈可信赖，理解后可直接实施，但范围不明确仍要提问；来自外部审查者则先检查是否技术上正确、是否会破坏现有功能、当前实现是否有原因、是否跨平台版本适用、审查者是否掌握完整上下文。
必要用法：遇到任何不明确的条目，先停下来实施，就不明确处提出澄清，因为各项之间可能关联；示例中“第 1、2、3、6 项我理解了。第 4 和第 5 项需要澄清后再动手”。面对“正规实现某功能”的建议，先在代码库中 grep 实际调用情况，无人使用则提出删掉（YAGNI）。实施多项反馈时，先澄清全部不明项，再按阻塞性问题、简单修复、复杂修复的顺序推进并逐项测试、验证无回归。反驳需用技术理由、提出具体问题、引用可正常工作的测试或代码，涉及架构时让搭档参与。确认正确反馈时直接说明已修复内容和位置，不写“你说得太对了”“好观点”或任何感谢表达。事后发现自己反驳有误，如实纠正后继续。在 GitHub 回复行内审查评论时使用 gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies，不发顶层 PR 评论。
适用场景：代码审查反馈的接收与处理，尤其是反馈不明确、技术上存疑或与既有决策冲突时。
限制：偏向流程与沟通准则，不包含具体语言或框架的实现代码；价格、平台支持等信息暂未提供。