Copilot CLI 上线「橡皮鸭」：跨模型互审，Sonnet 追赶 Opus 74.7% 差距

程序员改不动代码时喜欢找桌上的小黄鸭念叨两句，很多时候说着说着自己就想通了。但要是让写代码的 AI 自己给自己挑错，往往是自己骗自己，同一个模型的盲区和偏见换几轮对话依然还在。

GitHub 在 Copilot CLI 里正式上线了实验性功能 Rubber Duck。有趣的是，这次 GitHub 没有让同一个模型反复做自我反思，而是拉来了对家模型当审稿人：只要你主控选了 Claude，背后挑刺的小黄鸭就换成了 GPT-5.4。

让 GPT 来挑 Claude 的刺

现在的代码智能体一般都按套路走：评估任务、出方案、写代码、跑测试，不行再重试。这个流程最大的隐患在于早期的规划偏差，一旦最底层的假设错了，后面写得越多，返工成本就越高。

模型自我反思虽然有用，但被同一套训练数据和偏置绑死。GitHub 拿出的解法很直接，把 Claude 和 GPT-5.4 凑成搭子，让不同家族的模型提供第二种视角。

在真实复杂项目测试集 SWE-Bench Pro 上，Claude Sonnet 4.6 搭配 GPT-5.4 扮演的 Rubber Duck，成功抹平了 Sonnet 与更高级的 Opus 之间 74.7% 的性能差距。

数据还显示，这只小黄鸭在跨 3 个以上文件、执行步骤超过 70 步的难缠任务里提升最明显。这类任务上它的解决率比 Sonnet 基线高出 3.8%，在多次测试认定的最难问题上更是高出 4.8%。

GitHub 给出了几个抓包现场：在 OpenLibrary 项目里，它发现原方案里的异步调度器不仅启动就会秒退、一个任务都跑不起来，其中一个任务本身还是死循环；在另一个 Solr 搜索模块中，代码在循环里静默覆盖同一个字典键，导致四分之三的分类参数无声丢失；在 NodeBB 邮箱验证逻辑里，新代码停写了一个 Redis 键，导致另外三个读取该键的文件在上线后会静默崩掉。

什么时候叫这只鸭子出来

如果每走一步都去调一遍大模型，响应速度和成本肯定扛不住。GitHub 的做法是把 Rubber Duck 接入既有的子智能体框架，只在回报率最高的高价值节点自动介入。

第一个关键节点是方案出炉后。这是避免错误假设滚雪球的最佳时机，早发现结构性缺陷能省去后面大半无效编码。

第二个节点是完成复杂实现后，由第二双眼睛来筛查边缘情况。

第三个节点是写完测试用例、但在正式执行之前。很多时候智能体会写出有逻辑缺陷的断言，最后全绿通过全凭侥幸，多一道把关能防止自我欺骗。

除了主动介入，当主智能体陷入循环或卡壳时也会求助小黄鸭；开发者在 Copilot CLI 里也可以随时打命令要求它对当前工作做复盘，并直接查看对比差异。

目前这个功能支持 Claude 全家桶（Opus、Sonnet、Haiku）作为主控，默认搭配 GPT-5.4，后续 GitHub 还打算探索让 GPT-5.4 当主控、其他模型当审稿人。想尝鲜的用户在 CLI 里输入 /experimental 就能开启。

为什么重要

对开发者来说，这套机制最大的价值是用更低的成本换取了越级能力。过去你可能必须为复杂架构任务掏钱上顶配的 Opus，现在跑着价格更亲民的 Sonnet，只要在关键节点请出 GPT-5.4 掌眼，就能达到逼近顶级模型的效果。特别是涉及多文件依赖和线上重构的任务，这种静默逻辑破坏往往最难排查，多一个视角查漏补缺非常划算。

对行业而言，它撕开了 AI 辅助编程单模型竞争的传统思路。大家过去都在死磕单个模型在某个 Benchmark 上的极限刷分，但不同团队的模型因为训练数据和对齐策略的差异，擅长点和盲区天然互补。GitHub 这一步证明了跨模型家族混合组队在实际工程场景里的巨大潜力，很可能会倒逼 Cursor 等竞品工具迅速跟进多模型流水线。

我们认为 GitHub 的设计非常克制且聪明。它没有做成成本高昂的持续双模型并发，而是精选了方案设计、完工审查和测试前置三个节点。不过潜在隐患也很现实：跨模型调用势必引入额外延迟，且当两个前沿模型对同一处架构设计各执一词时，主控智能体该如何抉择仲裁，目前看起来还需要更多工程层面的验证。