強模型規劃與本地小模型執行的分工架構

該使用者在 Reddit 討論區分享其使用 Ornith 1.5-9B（8-bit 量化版本）作為本地編碼代理的經驗。他發現這個小型模型能夠完成工程任務，但前提是計畫必須針對小模型的能力進行撰寫。

為了讓強模型（如 Claude Code）能生成適合執行的計畫，使用者將學習心得整理成一份公開指引文件。該文件的設計目的是交給較強的規劃模型使用，由強模型負責撰寫規格說明與拆解為小型任務卡片，並在合併前驗證結果。

本地的小型模型則負責執行中間漫長且機械性的工作，包括執行命令、建置專案、輪詢作業狀態以及處理 Git 操作。這些步驟通常是 Token 消耗的主要來源，透過將這些工作轉移到本地硬體執行，使用者得以減少對雲端服務 Claude 的 Token 依賴。

針對小模型能力的具體指引與限制

指引文件詳細列出了小型模型的能力邊界與預期行為。文中指出，小模型的實際工作表現比其自我報告更為可靠，但它不會主動探索未知領域，也無法自行判斷任務何時完成，且在處理長上下文時速度會變慢。

為了有效指揮小模型，指引建議提供精確的檔案名稱與行號範圍、絕對路徑、僅限 1 至 3 行的編輯指令、確切的函式簽名，並將所有規則明確寫下。每個步驟都應以一個命令結束，並附上該命令預期的確切輸出結果，同時必須設定明確的停止規則。

在執行策略上，建議每個任務都在全新的工作階段中進行，保持上下文範圍小巧，並將計畫檔案作為記憶來源。在任何變更合併之前，必須透過 Git 記錄與系統日誌來驗證模型的宣稱，而不是依賴模型提供的摘要報告。

實際測試結果與效能限制

根據使用者分享的結果，這套方法成功由本地 9B 模型完成了一次涉及兩個倉庫、共 75 個提交的合併操作，且所有回歸測試均通過。過程中，模型關於其執行內容的筆記多次出現錯誤，但計畫中設定的檢查機制與最終驗證步驟捕捉到了所有這些錯誤。

然而，這種方法存在明顯的效能限制。使用者指出，完成該階段的任務花費了接近一天的時間，相比之下，單獨使用 Claude 處理相同階段僅需約一小時。此外，這套流程需要具備足夠硬體資源來運行表現尚可的本地模型。

使用者強調，雖然這些規則設計上是與特定工具框架無關（harness-agnostic），但它們是基於單一模型學習而來的經驗法則。他歡迎社群分享這些規則在其他模型上的適用性與效果，目前尚未有其他模型的驗證數據。