小村軟體有限公司
日本語 English 한국어 繁體中文 简体中文 العربية
聯絡我們
選單

Fable 不能用了，但還沒到放棄的時候 ── 靠 OpenRouter Fusion＋中國 LLM＋審查層硬撐

· · AI, LLM, OpenRouter, Claude, ChatGPT, DeepSeek, 提示工程, 開發效率化, 工具介紹

1. Fable 死了。這下麻煩了

老實說吧。這遠遠比不上 Fable。

在寫這篇文章的時候，Anthropic 提供的 AI 程式撰寫代理「Fable」已經停止服務。那樣的精準度、那樣的速度、那樣的整合感。目前還沒有能超越它的替代方案。

話雖如此，也不能就這樣袖手旁觀。找替代品的話，選項大致是這些面孔：

  • Claude Code / Claude Sonnet：聰明。但單獨使用時精準度不及 Fable，費用也不便宜
  • GPT-5 / GPT-5.5：出乎意料地不太行。處理長程式碼庫時很快就喘不過氣。而且貴
  • Cursor / Windsurf：體驗不錯，但要看背後用的是哪個模型。無法自由配置
  • 本地 LLM（Ollama 等）：速度是有，但一旦交給實際的程式庫，精準度就會明顯下滑

於是，反覆嘗試之後找到的答案，就是用 OpenRouter 的 Fusion 功能＋中國 LLM 來生成程式碼，最後再過一層 gpt-5.5-pro 審查 或 Codex 的 PR 審查。這套組合完全比不上 Fable，但比純 gpt-5.5 好上不少。算是還能用。

不過，畢竟是中國 LLM，把工作用的程式碼餵給它還是有點怕。前提終究是只在興趣專案或個人開發的範圍內使用。

2. 什麼是 OpenRouter Fusion

OpenRouter 是一個能用統一介面呼叫多個 LLM 供應商的 API 閘道。Claude、GPT、Gemini、DeepSeek 全都能用同一套介面呼叫。

這個 OpenRouter 有一個叫做「Fusion」的功能。

簡單來說，這是一套把同一個提示丟給多個模型，分析它們的回答之後，由一個模型整理出最終輸出的機制。可以說是「模型們的合議制」。

具體流程如下：

  1. 使用者輸入提示
  2. 在 analysis_models 中指定的多個模型會同時針對同一個提示生成回答
  3. 由 model 指定的模型比較、分析這些回答，把共識點、矛盾點、缺漏、盲點等整理成結構化內容（＝擔任 judge 的角色）
  4. 接著，同一個模型會根據這份分析寫出最終回答

重點在於，無法為各個分析模型設定不同的角色或提示。所有模型收到的都是同一個提示，各自獨立回答，再由 judge 評估其中的差異——就是這麼簡單的機制。

名為 opencode 的 CLI 程式撰寫代理，原生支援把 Fusion 當作外掛使用。只要在 opencode.json 寫好設定，就能得到一個由多個模型協作生成、審查程式碼的代理。

3. 實際的設定

以下是我目前在用的 opencode.json 核心部分。

{
  "model": "openrouter/openrouter/fusion",
  "provider": {
    "openrouter": {
      "models": {
        "openrouter/fusion": {
          "name": "OpenRouter Fusion (Custom DeepSeek V4 Pro)",
          "options": {
            "plugins": [
              {
                "id": "fusion",
                "analysis_models": [
                  "xiaomi/mimo-v2.5-pro",
                  "z-ai/glm-5.1",
                  "deepseek/deepseek-v4-pro",
                  "moonshotai/kimi-k2.7-code",
                  "minimax/minimax-m3"
                ],
                "model": "deepseek/deepseek-v4-pro",
                "max_tool_calls": 8
              }
            ]
          }
        }
      }
    }
  }
}

由5 個分析模型和1 個執行模型組成。

分析模型（全部看著同一個提示、同時回答）

模型 開發商 特點
xiaomi/mimo-v2.5-pro Xiaomi（小米） 中國最大級手機廠商出品。性價比非常高
z-ai/glm-5.1 智譜AI（Zhipu AI） 清華大學出身。在中文圈的基準測試中長期名列前茅。擅長邏輯推理
deepseek/deepseek-v4-pro DeepSeek（深度求索） 不用多說，來自中國的破壞性 LLM。程式撰寫能力尤其突出
moonshotai/kimi-k2.7-code Moonshot AI（月之暗面） 程式碼生成專用模型。在長文脈處理上頗有名聲
minimax/minimax-m3 MiniMax（稀宇科技） 在多模態、長文處理方面評價快速上升的新秀

執行模型（根據分析結果寫出最終回答）

  • deepseek/deepseek-v4-pro：根據分析模型們的回答，負責實際的程式碼生成與檔案編輯。

為什麼是中國 LLM

單純是因為性價比極高。

截至 2026 年，中國出品的 LLM 的 API 價格是 Anthropic 或 OpenAI 的五分之一到二十分之一，效能卻不相上下甚至更好。尤其 DeepSeek V4 Pro 的程式撰寫能力，在實務層級上不少場合感覺可以與 Claude Sonnet 或 GPT-5.5 打成平手甚至更強。

4. 運作方式 ── 光靠 Fusion 還不夠

Fusion 單獨運作時的流程是這樣的。

  1. 使用者輸入提示
  2. 5 個分析模型各自獨立生成回答
  3. 執行模型（DeepSeek V4 Pro）比較、分析這些回答，產生一份提取出共識點、矛盾點、缺漏的結構化分析
  4. 根據這份分析，同一個執行模型（DeepSeek V4 Pro）生成最終的程式碼

這很接近人類團隊開發的模式。5 位工程師看著同一份規格各自提出審查意見，再由 1 個人（DeepSeek V4 Pro）分析整理之後動手實作——大概是這樣的畫面。

關於上下文視窗的限制： Fusion 的上下文視窗是 128K tokens。乍看之下不多，但因為對話歷程還要加上 5 個模型各自的回答全部塞進去，其實很快就會被填滿。不過不用太緊張。就算超過 128K 導致 Fusion 的合成步驟失敗，各個分析模型也早已各自（以 DeepSeek V4 Pro 的 100 萬 tokens、Kimi K2.7 的約 26 萬 tokens 等，各自足夠大的上下文視窗）完成了提示的處理。opencode 本身也保留了整個 session 的對話歷程，所以模型的「記憶」並不會因此消失。實際體感是不會造成太大的實務障礙。

但光靠這樣，完全比不上 Fable。畢竟 Fable 是單一模型，卻能輕鬆超越多模型合議制的精準度。這是 Anthropic 的底力。

因此，要在 Fusion 的輸出上再套一層審查層。選項有兩個。

選項 A：由 gpt-5.5-pro 進行程式碼審查

  1. 用 Fusion 架構生成程式碼
  2. 把生成的程式碼丟給 gpt-5.5-pro，要求它「審查並提出修正建議」
  3. 讓原本的執行模型套用這份修正建議

gpt-5.5-pro 單獨生成程式碼時表現不太行，但審查既有程式碼卻出乎意料地擅長。

選項 B：GitHub Codex 的 PR 審查

  1. 用 Fusion 架構生成程式碼
  2. 提出 PR，交給 GitHub Codex 的 PR 審查
  3. Codex 會指出潛在的錯誤或設計上的隱憂，把這些反映進去

Codex 的審查會考量 GitHub 的脈絡（Issue、過往的 PR、專案結構），因此會從和通用 LLM 審查不同的角度切入。

只要選一個就夠了。Fusion（5 模型合議）→ 審查（gpt-5.5-pro 或 Codex）的兩段式架構。正因為單靠一次 Fable 遠遠不夠，才用流程來補足，這是這套方法的核心想法。

純 gpt-5.5 常犯的函式庫版本錯誤、使用不存在的 API 等問題，用這套架構已經明顯減少。

5. 速度與實用性

速度本身和單一模型相比沒有太大差異。因為 5 個模型是並行運作，實際回應時間仍在可接受範圍。

問題在於精準度。換作 Fable 一次就能過關的地方，這套架構會出現幾次返工。結果就是整體開發時間明顯比 Fable 慢。錯得越多就越慢。

不過，比純 gpt-5.5 好上不少。用 Fusion＋審查生成的程式碼，一開始就相當接近正確答案，肯定比 gpt-5.5 單獨陷入生成→修正→修正→修正的無限迴圈要快得多。

體感上大概是「速度不差。精準度遠不及 Fable，但比純 gpt-5.5 好上好幾個檔次」的這種平衡。

6. 附加內容：審查層與其他 opencode 設定

審查層：gpt-5.5-pro 或 Codex PR 審查

光靠 Fusion 架構還是有點不放心，所以會選其中一個當作審查層來用。

gpt-5.5-pro：透過 opencode 的 task 功能指定為子代理，指示它「審查生成的程式碼並提出修正建議」。從零開始寫程式碼的表現微妙，但挑別人寫的程式碼的毛病卻異常擅長。

GitHub Codex：在提出 PR 的時候，讓 Codex 的 PR 審查 跑一遍。它能考量整個專案脈絡進行審查，這一點和通用 LLM 審查的味道不太一樣。

要用哪一個，全看當下的心情。兩個都用實在太超過，也太慢了。

其他設定

opencode.json 裡除了 Fusion 之外，還放了幾個實用的設定。

{
  "permission": {
    "read": "allow",
    "glob": "allow",
    "grep": "allow",
    "task": "allow",
    "webfetch": "allow",
    "websearch": "allow",
    "lsp": "allow",
    "edit": "allow",
    "bash": {
      "*": "allow",
      "Remove-Item *": "deny",
      "del *": "deny",
      "rm *": "deny",
      "rmdir *": "deny",
      "rd *": "deny",
      "erase *": "deny",
      "git clean *": "deny"
    }
  },
  "experimental": {
    "primary_tools": ["task"]
  }
}

重點有兩個。

1. 封鎖刪除類指令

明確拒絕了 Remove-Item、del、rm、rmdir、rd、erase、git clean。因為把檔案刪除交給 AI 代理去做實在讓人不放心。真的需要刪除時，就自己動手。

2. primary_tools: ["task"]

讓子代理（task）的平行探索優先執行。在大型程式庫中同時讀取或搜尋多個檔案時，透過 task 的方式明顯快得多。

7. 結語

Fable 的停止服務很痛。真的很痛。目前還沒有能超越它的東西。

但也不能就這樣袖手旁觀，所以目前是靠 OpenRouter Fusion＋中國 LLM 生成程式碼，再用 gpt-5.5-pro 或 Codex PR 審查收尾的架構在硬撐。

這套架構的要點：

  • 用 OpenRouter Fusion 靠 5 個模型的「合議制」生成程式碼
  • 分析模型：Xiaomi Mimo / GLM / DeepSeek / Kimi / MiniMax
  • 執行模型：DeepSeek V4 Pro
  • 收尾用的審查層：gpt-5.5-pro 或 Codex PR 審查（兩者選一）
  • 速度和單一模型相當。但因為精準度不及 Fable，返工會拖慢速度
  • 比純 gpt-5.5 好上不少。雖然遠不及 Fable，但足以應付實用需求
  • 因為是中國 LLM，不太適合用在工作程式碼上。僅限興趣、個人開發

如果你是「失去 Fable 很痛苦」、「覺得純 gpt-5.5 太不中用」的 AI 程式撰寫代理使用者，這套方案作為過渡期的替代品，值得一試。

只要有 OpenRouter 帳號，今天就能開始使用。

參考連結

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

常見問題

整理諮詢這個主題時常見的問題。

OpenRouter 的 Fusion 是什麼樣的功能？
這是把同一個提示同時丟給多個模型，讓其中一個模型（擔任 judge 角色）比較、分析各自的回答，整理出共識點、矛盾點與缺漏，再由同一個模型根據這份分析寫出最終回答的機制。可以說是模型們的合議制。無法為每個分析模型設定不同的角色或提示，所有模型收到的都是同一個提示。CLI 程式撰寫代理 opencode 原生支援 Fusion 外掛，只要在 opencode.json 寫好設定就能使用。
為什麼要用中國的 LLM？
單純是因為性價比極高。截至 2026 年，中國出品的 LLM 的 API 價格是 Anthropic 或 OpenAI 的五分之一到二十分之一，效能卻不相上下甚至更好。尤其 DeepSeek V4 Pro 的程式撰寫能力，在實務層級上不少場合感覺可以與 Claude Sonnet 或 GPT-5.5 打成平手甚至更強。不過把工作用的程式碼交給中國 LLM 存在風險，因此前提是只在興趣專案或個人開發的範圍內使用。
為什麼光靠 Fusion 還不夠？
因為即使是 5 個模型的合議制，精準度也仍達不到 Fable 的水準。所以要在 Fusion 的輸出上再加一層審查。選項有兩個：一是讓 gpt-5.5-pro 審查生成的程式碼並套用修正建議，二是提出 PR 讓 GitHub Codex 的 PR 審查把關，兩者選一個就足夠。gpt-5.5-pro 單獨生成程式碼時表現較弱，但很擅長審查既有程式碼；Codex 則能根據整個專案的脈絡提出意見。
這套架構的實用程度如何？
由於 5 個模型是並行運作，速度和單一模型相比差不了多少。但精準度遠不及 Fable，因為會產生返工，整體開發時間明顯變慢。即便如此，仍確實比純 gpt-5.5 單獨陷入生成與修正的無限迴圈要快，函式庫版本錯誤或使用不存在 API 的情況也明顯減少。只要有 OpenRouter 帳號，馬上就能試用。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。

聯絡我們
回到部落格一覽