用途：在接收代码审查反馈、准备实现建议之前使用，尤其当反馈看起来不清楚或技术上可疑时。核心原则是先验证再实现，先询问再假设，技术正确性优先于社交舒适感。
主要能力：给出响应流程——完整阅读反馈、用自己的话复述需求、对照代码库验证、评估是否技术上合理、给出技术性确认或有理有据的反驳、一次处理一项并逐项测试。明确禁止表演式认同（如“你说得完全对”“好点子”）。区分来自人类伙伴与外部审查者的反馈：外部反馈需保持怀疑但仔细核查，检查是否会破坏现有功能、当前实现是否有理由、是否适用于所有平台/版本。对“专业化实现”建议做 YAGNI 检查，用 grep 确认是否真的被使用。
使用方式：处理多项反馈时先澄清不清楚项，再按阻塞问题、简单修复、复杂修复的顺序实现，每项单独测试并验证无回归。反驳时使用技术推理，引用可工作的测试或代码。确认正确反馈时直接说明修复内容，不说感谢。在 GitHub 上回复内联审查评论应使用 gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies 在线程中回复，而不是顶层评论。
适用场景与限制：适用于代码审查反馈的接收与落地。如无法验证建议，应说明限制并请求方向；若与人类伙伴先前的决定冲突，先停下讨论。资料未提供具体平台、收费或价格信息。