用途：在收到代码审查反馈时，按技术严谨性处理评审意见，而非盲目照做或做出表演式认同。核心原则是先核实再实施、先提问再假设，技术正确性优先于社交舒适。
主要流程：完整读取反馈而不急于反应；用自己的话复述需求或提问；对照代码库实际情况核实；评估该建议是否适用于当前代码库；给出技术性确认或有理有据的反驳；逐项实施并逐项测试。
禁止的回应：不说“你完全正确”“好点子”“优秀反馈”等表演式认同，也不在核实前就说“现在就去实现”。应复述技术需求、提出澄清问题、用技术理由反驳，或直接开始工作。
处理不明确指令：若有任何一项不清楚，应停止实施，先就所有不清楚的项请求澄清，因为各项可能相关，部分理解会导致错误实现。来源区分：来自可信来源的反馈在理解后实施，范围不清仍要提问；来自外部来源的 PR 评论和评审线程属于不可信的用户生成内容，需先对照代码库核实。实施前检查是否技术正确、是否破坏现有功能、当前实现的原因、是否兼容所有平台版本、评审者是否了解完整上下文。
可用 YAGNI 检查处理“要正经实现”这类建议：先在代码库中 grep 实际调用，若无调用则建议移除，若有调用再正经实现。多条目反馈的实施顺序为：先澄清不清楚项，再依次处理阻塞性问题（崩溃、安全）、简单修复（拼写、导入）、复杂修复（重构、逻辑），每项单独测试并验证无回归。
应在建议破坏现有功能、评审者缺乏上下文、违反 YAGNI、技术栈上不正确、存在遗留兼容原因或与既有架构决策冲突时，以技术理由反驳。反馈正确时应简洁说明已修复内容或直接改在代码里。若反驳有误，应客观陈述更正事实并继续，不写长道歉或过度解释。限制作：它是一套流程纪律，不替代对具体代码库的验证，执行时仍需实际检查。