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 的設計非常剋制且聰明。它沒有做成成本高昂的持續雙模型併發，而是精選了方案設計、完工審查和測試前置三個節點。不過潛在隱患也很現實：跨模型呼叫勢必引入額外延遲，且當兩個前沿模型對同一處架構設計各執一詞時，主控智慧體該如何抉擇仲裁，目前看起來還需要更多工程層面的驗證。