用途：处理收到的代码评审反馈（PR 评论、实现建议、问题清单），以技术严谨性逐条核实后再行动，而非直接照做。
主要能力与规则：
- 实现前先验证：读完所有反馈项，逐条对照代码库核实，不默认评审者正确。例如评审称第 42 行未处理 null，应先检查该输入是否已在 API 边界校验。
- 有依据地反驳：当建议错误、属于 YAGNI 或违反项目约束时，用证据说明，不为避免冲突而实现。
- 禁止表演式附和：不得使用“好观点！”“完全正确！”“感谢指出！”等措辞，改为读→验证→实现或反驳。
- 模糊反馈先澄清：如“可以更高效”需先问清指时间复杂度还是内存占用，再动手。
- 批量澄清：先读完所有反馈，集中一次提问，而非逐条边做边问。
决策路径：反馈清晰且可验证正确→核实后实现并运行验证；不清晰→加入澄清批次；可证伪→附文件与行号反驳；YAGNI 或超范围→说明理由不实现；仅风格偏好且不符项目规范→标记为主观。全部处理完后运行完整验证再宣布完成。
反驳格式：陈述主张→给出证据→结论，例如“第 42 行不存在 null 风险：输入在 middleware/validate.ts:18 已校验”。
边界情况：评审者可能掌握更多上下文，若反驳基于不完整信息应先询问；多位评审者意见冲突时明确标出冲突而非默默选边；安全、数据丢失等严重问题应立即处理，不等批量澄清；评审者坚持时，若有新证据或上下文则实现，若无新理由则维持立场。
不适用：给出评审意见（用 code-review）、决策前在选项间取舍（用 brainstorming）。
限制：资料未提供安装命令、平台支持、收费方式及具体运行环境信息。