什么是Receiving Code Review
收到代码审查反馈后、实施建议前使用，尤其当反馈不明或存疑时——需严谨技术验证，切忌敷衍附和或盲从。该工具的核心原则是：在实现任何修改之前必须进行技术验证，而非情感上的认同或社交性回应。它强调‘先理解，再行动’的工作流程，要求开发者完整阅读反馈内容而不急于反应，随后用自己的话复述需求以确认理解无误，接着对照实际代码库检查其可行性，评估该技术建议是否真正适用于当前项目环境，最后才做出技术性回应或执行修改。整个过程摒弃了诸如‘你说得对！’‘感谢指出！’这类表演性赞同，倡导用实际行动代替口头感谢，让修复后的代码本身证明已正确接收并处理了反馈。
核心功能特点
- 严格遵循‘验证-理解-响应-实施’的技术闭环流程
- 禁止任何形式的表演性同意（如‘你说得对！’），提倡技术性回应
- 针对模糊不清的反馈项主动暂停实施并请求澄清
- 区分内部与外部评审意见的不同处理策略
- 实施前强制检查建议是否会破坏现有功能或违背YAGNI原则
- 支持分阶段、逐项测试的渐进式修复方式
适用场景
本工具最适合在收到来自外部评审者的代码审查反馈时使用，特别是在面对那些表述不够清晰、与团队既有决策相冲突、或看似合理但缺乏上下文支撑的建议时。例如，当评审者提出‘移除遗留代码’时，系统会引导你首先核查构建目标版本和API兼容性，判断是否需要保留旧接口以实现向后兼容；又如，若有人建议‘完善指标追踪功能’，则会促使你通过代码搜索确认该功能是否被实际调用过，避免为未使用的特性投入开发资源。此外，在团队协作环境中，当你对某条建议的真实意图存在疑问，或者担心直接实施可能导致意外副作用时，此工具提供的结构化应对框架能有效降低沟通风险，确保每次变更都建立在充分理解和准确评估的基础上。