用途：在收到代码评审反馈、准备按建议修改之前，提供一套技术化的处理流程，避免盲目照做或情绪化回应。核心原则是“先验证再实现、先询问再假设、技术正确性优先于社交舒适”。
主要能力与流程：收到反馈后按 READ→UNDERSTAND→VERIFY→EVALUATE→RESPOND→IMPLEMENT 执行：完整读完反馈不做反应；用自己的话复述需求或提问；对照代码库实际情况核验；判断该建议对当前代码库是否技术上成立；给出技术性确认或有理由的反驳；最后逐项实现并逐项测试。
禁止的回应：不得说“你说得完全对！”“好建议！”“优秀反馈！”等表演式附和，也不得在验证前就说“我马上去实现”。替代做法是复述技术要求、提问澄清、用技术理由反驳，或直接动手。
处理不清晰反馈：任何一项不清楚就停止，不要先做清楚的部分，因为各项可能彼此关联，部分理解会导致错误实现。例：对方说“修 1—6”，你只懂 1、2、3、6，应回复“我理解 1、2、3、6，需先澄清 4 和 5 再动手”。
来源区分：来自人类搭档的反馈可信任，理解后实现，范围不清仍要问；来自外部评审者的建议需先核查是否对当前代码库技术正确、是否破坏现有功能、当前实现原因、是否跨平台版本可用、评审者是否了解完整上下文，无法轻易验证就说明需要何种信息再决定。若与人类搭档既有架构决策冲突，先停下与其讨论。
YAGNI 检查：评审者建议“规范实现”某功能时，先 grep 代码库确认真实调用；无人使用则可提出移除，确实被调用再规范实现。
实现顺序：先澄清所有不清项，再按阻塞问题（破坏、安全）、简单修复（错字、导入）、复杂修复（重构、逻辑）排序，逐项测试并确认无回归。
应当反驳的情形：建议破坏现有功能、评审者缺乏完整上下文、违反 YAGNI、对当前技术栈不正确、存在遗留与兼容原因、与人类搭档的架构决策冲突。反驳时用技术推理而非防御姿态，提出具体问题，引用可用的测试与代码。
确认正确反馈：直接说明修复内容与位置，或直接在代码中体现；不要表达感谢或任何感激之词。若反驳错了，事实性说明后继续推进，不做冗长道歉。GitHub 行内评论需在线程内回复而非顶层评论。总之，外部反馈是待评估的建议，不是必须执行的命令：先验证、先质疑，再实现。