用途：在收到 code review 反馈后、把建议落地之前使用，尤其当反馈含义不清晰或技术上可疑时，要求技术严谨与验证，避免表演式同意或盲目实现。核心原则是先验证再实现、不确定先问、技术正确性高于社交舒适度。
主要流程：READ 完整读完，不立刻反应；UNDERSTAND 用自己的话复述需求或提问澄清；VERIFY 对照代码库现实验证；EVALUATE 判断建议对该代码库是否技术上成立；RESPOND 做技术性确认或有理有据地反驳；IMPLEMENT 一次只改一项并逐项测试。
应避免的回应：不写“你说得完全对”“好建议”这类表演式同意，也不要在未验证时宣布“现在就改”。正确反馈用行动与代码体现，例如直接说明“已修复：<改了什么>”。
处理不清晰反馈：只要有一条不清晰就停下，先澄清全部条目再动手，因为多条反馈可能相互关联，半懂就实现容易做错。
区分来源：来自伙伴的反馈可信度高，理解后实现，范围不清仍要问；来自外部 reviewer 的反馈，落地前需检查对该代码库是否技术正确、是否破坏现有功能、当前实现为何如此、是否跨平台版本成立、reviewer 是否掌握完整上下文。无法验证时说明限制并询问先调查/提问/推进哪一项；与伙伴既有决策冲突时先停下与伙伴讨论。
YAGNI 检查：若建议做“更专业的实现”，先在代码库中检索实际调用；无人使用则询问是否按 YAGNI 删除，有人使用再完善。
实现顺序：先澄清全部不清晰项，再按 Blocking（崩溃/安全）、Simple fixes（typo、import）、Complex fixes（重构、逻辑）推进，每修一项跑测试并确认无回归。
何时反驳：建议会破坏现有功能、reviewer 缺少关键上下文、违反 YAGNI、对当前技术栈不成立、存在 legacy/兼容原因、与伙伴架构决策冲突时，用技术理由、具体问题、可运行测试或代码反驳；涉及架构则拉伙伴一起定。
GitHub 回复：回复 inline review comment 时应在该 comment thread 内回复，使用 gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies，不要发成 PR 顶层评论。
限制：资料未提供安装方式、具体平台支持范围与授权收费信息，暂未提供。