我不再事事都用 Opus 了。雖然仍在使用 Claude、Kimi 和 GPT，但 AI 成本一夜之間下降了 43%

1檢視你最近 30 個 Droid 任務。把它們分成兩組：
2
3需要前沿模型：涉及系統架構、身分驗證、金流、安全、跨服務相依性的任務，
4任何出錯會浪費時間除錯或需要還原的工作。超過 100 行商業邏輯的複雜重構。
5
6例行工作：文件更新、設定變更、為現有函式新增測試、
7有明確規格的小型錯誤修正、版權標頭、README 編輯、
8樣板生成、簡單遷移。
9
10分別計算兩組的數量。
11
12根據 Factory 的 session 層級資料：
13「重設密碼」類型任務：Opus $0.84 vs 分流後 $0.09，便宜 89%。
14「新增版權標頭」類型任務：Opus $0.62 vs 分流後 $0.12，便宜 81%。
15
16用例行任務數量乘以這個差距。
17這個數字就是你目前因模型選擇而多付的稅金。

1拉出你上個月的 Droid session 日誌。
2
3每個 session 需記錄：
4- 任務類型（根據規則 1 的分類）
5- 使用的模型
6- 成本
7
8計算：
9- 使用前沿模型的例行任務總支出
10- 這些任務改用高效模型後的成本（套用 80-90% 的降幅）
11- 透過分流可獲得的每月節省金額
12
13這是在啟用 Factory Router 之前的基準線。
14大多數團隊會發現 30-50% 的 session 是例行工作，卻跑在前沿模型上。

1任務的描述方式會向分流系統傳達它的複雜度。
2
3低複雜度訊號（導向高效模型）：
4- 「簡單的設定更新，不涉及商業邏輯：把 config.yaml 中的 timeout 從 30 改為 60」
5- 「為 /helpers 中的工具函式補上遺漏的 JSDoc 註解」
6- 「更新 README 以反映新的部署步驟」
7
8高複雜度訊號（導向前沿模型）：
9- 「重構身分驗證中介軟體，以支援跨越 3 個服務的新 SSO 整合」
10- 「除錯金流處理器中的競爭條件，該問題只在併發負載下出現」
11- 「重新設計頻率限制系統，以支援每個租戶的門檻」
12
13具體且富含脈絡的任務描述能提升分流準確度。
14模糊的描述會被保守地導向前沿模型。

1估算 Factory Router 節省金額的公式：
2
3每月 session 數：[N]
4未分流時平均每個 session 成本：[Opus 基準價格，以美元計]
5例行任務佔比：[根據規則 1 稽核得出的百分比]
6例行任務成本降幅：80-90%
7
8每月節省金額估算：
9N × 基準成本 × 例行佔比 × 0.85 = 每月回收金額
10
11年度：乘以 12。
12
13舉例：一個團隊每月執行 5,000 個 session，平均成本 $2.87，例行任務佔 40%：
145,000 × $2.87 × 0.40 × 0.85 = 每月 $4,879 = 每年 $58,548
15
16這是下限。Missions（長時間自主執行的工作）還會進一步放大節省效果。

1在啟用分流之前，先定義在你的程式碼庫中哪些工作必須留在前沿模型上。
2
3寫下這段內容，然後貼上作為你的分流指導基準：
4
5「以下工作永遠需要前沿模型：
6- 任何更動到 [身分驗證 / 金流 / 安全層] 的內容
7- 涉及超過 [N] 個檔案的跨服務重構
8- 對 CI/CD 管線設定的變更
9- 資料庫綱要遷移
10- 任何在我們的問題追蹤器中標記為 [P0 / 重大] 的項目
11
12其他所有工作都可分流到高效模型。」
13
14這份文件將成為你的分流政策文件。
15隨著你了解自己的程式碼庫中哪些需要前沿模型處理，再持續更新它。

1在 Factory CLI 或桌面應用程式中：
2
31. 開啟模型選擇器
42. 選擇「Factory Router」
53. 完成。
6
7不需要任何設定即可開始。Router 會立即使用預設分流邏輯。
8
9驗證它是否已啟用：
10執行一個簡單任務（例如「更新這個檔案中的註解」）。
11查看 session 日誌中的模型歸屬。
12你應該會看到高效的模型處理它，而不是 Opus。
13
14如果你在簡單任務上看到 Opus，請確認 Router 已被選取，而不是特定模型的覆蓋設定。

1分流指導是建議性質的。它能幫助 Router 為你的特定程式碼庫做出更好的決策，
2但不會強制指定模型。
3
4將以下內容貼上作為分流指導的起點，並根據你的技術堆疊進行編輯：
5
6「身分驗證、金流和安全相關變更：前沿模型。
7資料庫遷移和綱要變更：前沿模型。
8影響外部消費者的 API 合約變更：前沿模型。
9
10文件更新：高效模型。
11為現有函式新增測試：高效模型。
12設定和環境變數變更：高效模型。
13樣板生成和骨架建立：高效模型。
14程式碼註解和 JSDoc：高效模型。
15README 和更新日誌更新：高效模型。
16
17其他一切：Router 根據任務脈絡自行決定。」

1對於大規模執行 agent 的團隊，分流指導已成為治理文件。
2
3受監管行業（銀行、醫療、企業 SaaS）的標準範本：
4
5「高敏感度分流規則：
6- 任何涉及 [PII / 金融資料 / 身分驗證] 的內容 = 僅限前沿模型
7- 任何外部 API 變更 = 僅限前沿模型
8- 生產部署腳本 = 僅限前沿模型
9- 事故回應任務 = 僅限前沿模型
10
11標準分流：
12- 開發、測試和暫存環境 = Router 自行決定
13- 內部工具和自動化 = 偏好高效模型
14- 文件、報告和溝通 = 偏好高效模型
15
16覆蓋政策：
17任何開發者都可以為某個任務要求使用前沿模型。
18Router 會將其視為強制覆蓋，而非建議。
19所有前沿模型覆蓋紀錄都需記錄，供每月檢討。」
20
21將此內容儲存為專案根目錄下的 ROUTING_POLICY.md。
22在你的 CLAUDE.md 或對應的脈絡檔案中引用它。

1Missions 是 Factory 的長時間自主執行任務。
2可能需要數小時或數天，無需監督。
3
4啟用 Factory Router 後，Missions 也能享受相同的分流邏輯。
5Mission 中的每一步都會被適當地分流。
6複雜 Mission 中的簡單步驟會跑在高效模型上。
7只有當真正需要前沿模型的推理能力時，Mission 才會支付前沿模型的費率。
8
9設定方式：
10在啟動任何 Mission 之前先啟用 Factory Router。
11加入能反映該 Mission 複雜度輪廓的分流指導：
12
13「這個 Mission 包含 [高複雜度的核心工作] 和 [例行支援任務]。
14核心工作（架構決策、安全分析）：前沿模型。
15支援工作（文件、設定、樣板）：高效模型。
16對於任何不需要上述推理能力的步驟，
17請使用最有效率且可用的模型。」
18
19長時間的 Missions 能獲得比例上更大的節省，因為它們會累積更多例行步驟。

1Factory Router 會跨供應商分流以確保可靠性。
2如果某個供應商路徑效能下降，session 會透過健康的供應商繼續執行。
3
4對於有正常運作時間要求的企業團隊：
5
6「可靠性分流政策：
7- 每個模型的主要供應商：[列出你偏好的供應商]
8- 容錯轉移觸發條件：任何請求失敗或延遲超過 [N] 秒
9- 容錯轉移行為：同一模型，不同供應商（如果有的話）。
10  如果同一模型不可用，則升級到下一個前沿模型。
11- 專屬 TPM：請與 Factory 客戶團隊確認你的方案層級。
12- 目標：99.9% 以上的請求可靠性。
13
14記錄所有容錯轉移事件。每週檢視供應商健康狀況。」

1設定一個每週例行事項來追蹤 Router 的效能。
2
3在 Factory session 日誌中檢查：
41. 本週 session 總數
52. 模型分佈（各模型佔比）
63. 有分流 vs 基準線（全部用 Opus）的成本
74. 任何 Router 升級到前沿模型的 session（品質訊號）
8
9報告格式：
10> session 數：[N]
11> 高效模型使用率：[%]
12> 前沿模型使用率：[%]
13> 實際支出：$[金額]
14> 基準線（全部用 Opus）應為：$[計算值]
15> 本週節省金額：$[金額]
16> 升級到前沿模型的次數：[N]（檢討是否需要改善分流指導）
17
18如果升級率超過 10%，請檢討你的分流指導。
19太多升級表示例行任務被描述得過於複雜。

1在為整個團隊部署 Factory Router 之前，先執行 Factory 的 Agent Readiness 評估。
2
3它會評估 100 多個訊號，包括：
4- 程式碼庫健康度（測試覆蓋率、CI 可靠性、文件）
5- 工作流程成熟度（PR 流程、程式碼審查標準、部署管線）
6- 團隊準備度（對 agent 工具的熟悉程度、現有自動化）
7
8利用評估結果來決定哪些工作流程應優先分流。
9
10高準備度工作流程：立即部署 Router，啟用完整分流。
11中等準備度工作流程：部署 Router 時使用保守的指導，保留較多任務給前沿模型。
12低準備度工作流程：先建立準備度再進行分流。
13在準備不足的程式碼庫上使用 agent 工具，會花更多時間在前沿模型上修正錯誤。
14
15Router 的節省效果在高準備度的環境中最為顯著。

1Factory Router 從一個包含前沿和高效模型的池中選取模型。
2你設定的池會影響可用的分流選項。
3
4建議的起始模型池：
5
6前沿層級（複雜工作）：
7- Claude Opus（最新版本）
8- GPT-5.2（如果你的已核准供應商清單中有它）
9
10高效層級（例行工作）：
11- Kimi K2.6（程式碼任務的每 F1 分最佳價值）
12- MiniMax M2.7（簡單任務的最低成本）
13
14隨著你在自己的程式碼庫中驗證模型效能，再逐步加入更多模型。
15先從雙層結構開始。
16等到你有分流數據後，再擴展到三層（前沿 / 中階 / 高效）。
17
18記錄哪些模型已通過哪些法規要求的核准。
19如果你的企業限制特定的模型供應商，請相應地設定模型池。
20對於需要資料在地化要求的環境，可透過 Factory 使用美國託管的開源模型。

1Factory 可以在 CI 管線中運作。分流同樣適用於此。
2
3將 Factory Router 加入你的 GitHub Actions 工作流程：
4
5對於 Pull Request 審查：
6「根據檔案變更範圍分流 PR 審查任務。
7- 安全和身分驗證檔案變更：前沿模型
8- 測試檔案：高效模型
9- 文件變更：高效模型
10- 混合型 PR：如果可能，逐節分流，否則整個審查用前沿模型」
11
12對於自動化 QA：
13「根據測試複雜度分流 QA 任務。
14- 關鍵路徑端對端測試：前沿模型
15- 單元測試生成：高效模型
16- 回歸測試套件：高效模型」
17
18CI 分流能讓節省效果複利成長，因為它每次提交都會執行。
19每天 100 次提交中，用 Opus 和 Kimi K2.6 進行測試生成的成本差異是顯著的。

1分流指導應該隨著你的程式碼庫和團隊成長而演進。
2
3每月檢討議程（30 分鐘）：
4
51. 成本報告：實際 vs 基準線，節省趨勢
62. 升級分析：哪些任務升級了，為什麼
73. 分流指導更新：目前的指導是否仍然反映程式碼庫的複雜度？
84. 新模型評估：模型池中是否有值得加入的新模型？
95. 團隊回饋：開發者是否經常覆蓋 Router 的決定？為什麼？
10
11以下問題表示你的分流指導需要更新：
12- 升級率超過 15%：指導過於傾向高效模型
13- 升級率低於 2%：指導可能過於保守，放過了節省機會
14- 開發者覆蓋率超過 20%：Router 沒有達到開發者的期望
15
16每次檢討後更新 ROUTING_POLICY.md。