我把我的 AI 編碼帳單從每月 $4,200 美元砍到 $312 美元
沒有新工具。沒有減少交付。沒有「改用更便宜的替代方案」這種自我安慰
只是更聰明的路由、提示快取，以及我工作流程中 5 個悄悄燒掉我 50-70% token 的固定漏洞，在我發現之前
這篇文章就是我承諾過的完整解析。每個修復、每個配置、每塊省下的錢。讀完之後，你會得到一個完整的系統，而且你真的可以在這個週末就實作
讀完並實作這篇文章後，你將獲得：
- 每月 AI 編碼帳單降低 50-70%，而且不損失交付速度或品質
- 一個多模型路由器，能自動為每個任務挑選正確的模型
- 對 token 經濟學的實用理解，這是 95% 的 vibe coder 從不花時間學習的
- 一個 30 天的 rollout 計畫，每週都有具體行動
- 一個可直接複製貼上到 Cursor / Claude Code 的路由器配置
[ 讓我們開始拆解 ] ↓↓↓
1. 為什麼你的 AI 編碼帳單正在爆炸
2026 年 vibe coder 的成本圖表看起來像一根曲棍球棍
Claude Code、Cursor、Aider、Windsurf，每個工具都遵循同樣的經濟學：token 進、token 出，每百萬個 $X，無論方向。你用這些工具交付得越多，燒掉的 token 就越多，帳單就跟著漲
陷阱在於，大多數 vibe coder 是在 GPT-3.5 免費、Claude 每月 $20 美元固定的時候學會 AI 編碼的。沒有任何東西訓練你面對你的工具在一個星期二早上你正在煮咖啡時，開始執行 50,000 token 的 agentic 循環
三件事同時發生了：
- 模型變得更聰明也更貴（Opus 4.6 的輸入成本大約是兩年前 GPT-3.5 的 10 倍）
- 工具開始自動包含更多上下文（Cursor 的自動上下文、Claude Code 的 repo 感知、每個 IDE 都推出
@-everything）
- Agentic 工作流程成為預設（每個工具現在都執行多步驟循環，每一步都要支付完整的 token 成本）
結果：每天交付的普通 vibe coder 每月燒掉 $2,000-$5,000 美元，而且他們大多數人直到看到明細才意識到其中有多少是浪費
診斷結果不是「模型太貴」
診斷結果是「你在為懶惰付費」
你大部分的 token 帳單都是可修正的行為，而不是定價問題。這是好消息。這也是為什麼這份指南真的有效
核心洞察（你不是在為 token 付費，你是在為上下文付費）
網路上每一篇「降低 AI 帳單」的文章都叫你換模型
那是錯誤的修復
真正的修復在上游：停止發送你不需要發送的 token
一個典型的 vibe coder 工作階段是這樣的：
- 打開 Cursor
- 自動上下文載入 47,000 token 的 repo 檔案
- 要求 Claude「修復這個函式中的錯誤」
- Claude 為了找到那 30 行關鍵程式碼，推理了 47,000 token
- Claude 回傳一個 200 token 的修復
- 這個循環一天重複 50 次
成本：每次約 $0.70 美元 × 50 次 = 每天 $35 美元，在一個「小」工作日
實際信號：30 行關鍵程式碼
你不是付錢給 Claude 來修復錯誤。你是付錢給 Claude 來讀取整個 repo 50 次，這樣它才能找到 30 行
上下文紀律是槓桿。模型選擇是下游的
一旦你內化了這一點，下面的每個章節就都有意義了
Token 經濟學 101（大多數 Vibe Coder 實際上不知道的單位經濟學）
在我們開始節省 80% 帳單之前，你需要了解你實際上在為什麼付費
在每個現代 AI 帳單上，有 4 種 token 類別：
輸入 token — 你發送給模型的所有內容：你的提示、系統訊息、檔案內容、對話歷史。按每百萬個計價（$/M 輸入）
輸出 token — 模型回傳給你的所有內容：程式碼、解釋、推理。通常每個 token 比輸入貴 3-5 倍
快取 token — 在最近一次請求中發送過並被標記為快取的輸入 token。定價約為常規輸入成本的 10%。這是被低估的 90% 成本削減，大多數人沒有使用
推理 token — 模型在生成輸出之前使用的內部「思考」token。Claude Opus 會燒掉這些。即使你看不到它們，你也要為它們付費
截至 2026 年中期的近似定價（請在各供應商頁面上驗證——這些數字會變動）：
- Claude Opus 4.6：約 $15 / $75 每百萬（輸入 / 輸出）
- GPT-5：約 $10 / $40
- Claude Sonnet 4.6：約 $3 / $15
- Claude Haiku 4.5：約 $1 / $5
- Kimi 2.6（Moonshot）：約 $0.50 / $2
最貴選項與最便宜付費選項之間的差距，輸入端約 30 倍，輸出端約 35 倍
注意 Sonnet 4.6 和 Kimi 2.6 之間的具體差距：輸入端便宜 6 倍，輸出端便宜 7.5 倍。對於 95% 的嚴肅編碼工作，兩者交付的品質差距是看不見的。大多數以 Sonnet 價格付費的 vibe coder，是在為他們本可以從 Kimi 以相同品質水準獲得的輸出支付 6 倍的價格
（我們接下來會談到哪個任務該用哪個模型，並附上實際數字）
[ 現在讓我們診斷你的浪費 ] ↓↓↓
每個 Vibe Coder 都會掉進的 5 個 Token 陷阱
這 5 件事導致了我每月 $4,200 美元的帳單。修復每一個，你就能收回大部分的浪費
陷阱 1：每次回合都重新發送整個 Repo
發生的情況：
Cursor 或 Claude Code 的自動上下文功能在每次提示中都包含相同的 30-50 個檔案。那些檔案沒有改變。但你每次回合都要為它們付費
一個 50 檔案的上下文 = 約 80,000 輸入 token。以 Opus 定價計算，每次 $1.20 美元。每天 50 次 = 每天 $60 美元 = 每月 $1,800 美元，僅僅是為了重新發送未改變的上下文
修復方法：
- 對穩定的檔案關閉自動上下文。透過提示快取一次性包含它們
- 在詢問模型之前先使用 grep/ripgrep。只發送相關的函式或區塊
- 在 Cursor 中：對於例行工作停用
@codebase。使用特定的@file引用
- 在 Claude Code 中：依賴 agent 自己的 grep 工具，而不是預先載入檔案
僅此一個陷阱就能節省：穩定工作階段的輸入 token 減少 60-80%
陷阱 2：工具呼叫循環失控
發生的情況：
Agent 呼叫一個工具。取得資料。重新發送完整上下文。呼叫另一個工具。重新發送。呼叫第三個工具。重新發送
每次 agent 說「讓我去檢查一下」，你都在支付完整的輸入成本。等到 agent 得到答案時，你已經為同一個 50,000 token 的上下文付了 5 次錢
修復方法：
- 批次處理相關的工具呼叫。要求 agent 在執行之前先規劃好它的工具呼叫
- 積極地總結工具輸出。不要將原始輸出直接管道送回上下文
- 對於已知的工作流程，用確定性的 Python 輔助工具取代 agentic 工具循環
- 分析你的工具呼叫——記錄一週內每次呼叫的輸入/輸出 token 數量。找出失控的循環
節省：agentic 流程的成本降低 3-5 倍
陷阱 3：在廉價模型就能處理的任務上使用高階模型
發生的情況：
你要求 Opus「修正這個錯字」或「格式化這個 JSON」或「重新命名這個變數」。模型思考了 12 秒，燒掉了 8,000 token 的推理，回傳答案。成本：$0.60 美元，而 Haiku 本來可以用 $0.02 美元完美完成
或者更糟：你要求 Sonnet 重構一個 500 行的檔案。輸出成本 $0.12 美元，14 秒內交付。同樣的重構在 Kimi 2.6 上成本 $0.04 美元，16 秒內交付，而且程式碼在生產環境中無法區分
修復方法：
- 設定一個路由器（下一節）。對於瑣碎任務，預設使用 Haiku 或本地模型
- 對於實際的實作工作，預設使用 Kimi 2.6 而不是 Sonnet（在編碼任務上交付的品質相同，成本卻只有一小部分）
- 將 Opus / GPT-5 保留給那 10% 會產生複合效應的決策（架構、複雜重構）
一個來自我的工作流程的真實例子，讓我更清楚這一點：我的 agentic 重構循環以前全程使用 Opus。平均成本：每次 $18-24 美元。我只把 Opus 留給規劃步驟（一次呼叫），然後將 25-30 個迭代步驟路由到 Kimi 2.6。同樣的工作流程，同樣交付的程式碼，同樣通過的測試。新成本：每次 $1.40 美元
高階模型在迭代步驟上並沒有做高品質的工作。Kimi 2.6 逐行匹配了它。我只是在為循環不需要的能力付費
節省：在清理/格式化/lint 層級上節省 95%。在每個步驟都適度的長 agentic 循環上節省 10-15 倍
陷阱 4：在應該批次處理時使用串流（或反過來）
發生的情況：
串流回應可能會破壞某些工作流程的提示快取。而應該串流時卻批次處理會浪費使用者時間
修復方法：
- 對於穩定前綴的工作流程使用批次回應（快取提示在批次處理時效果更好）
- 對於互動式編碼，當你想要 UX 感覺時使用串流
- 對於不需要使用者回饋的背景 agent，總是使用批次處理
節省：正確批次處理時，快取前綴呼叫減少 30-50%
陷阱 5：來自「以防萬一」包含的上下文膨脹
發生的情況：
你不確定 Claude 是否需要 utils.ts，所以你包含了它。你不確定它是否需要測試檔案，所以你包含了它。你不確定它是否需要 schema，所以你包含了它。現在你的「修復這個錯誤」提示變成了 80,000 token
修復方法：
- 先 grep/ripgrep。如果 grep 沒有找到引用，模型就不需要那個檔案
- 要求 agent 請求它需要的檔案。不要主動提供
- 在長時間的工作階段中，定期總結舊的上下文並丟棄原始內容
- 使用 CLAUDE.md / 系統提示一次性編碼靜態上下文，然後快取它
節省：輸入 token 減少 70% 以上
[ 現在讓我們建立修復方案 ] ↓↓↓
路由器架構（停止對所有事情使用單一模型）
這是你所能做的最大的單一改變
根據任務類型將你的工作分散到多個模型上
大多數 vibe coder 對所有事情都使用一個模型。要嘛他們使用高階模型（每個任務都用 Opus，很貴），要嘛使用預算模型（每個任務都用 Haiku，在真正重要的工作上品質下降）。大多數人預設的中間地帶（所有事情都用 Sonnet）是兩者中最糟的：你支付了比必要多 6 倍的價格，而且在忙碌的日子裡仍然會遇到速率限制
聰明的做法是使用一個路由器，根據任務挑選正確的模型，讓 Kimi 2.6 負責大部分實際的編碼工作
路由決策樹：
- 這是規劃/架構任務嗎？→ 高階層級（Opus 4.6 或 GPT-5）。那 10% 會產生複合效應的決策。值得花這個錢
- 這是實作、程式碼審查、重構、除錯，或任何嚴肅的編碼工作嗎？→ Kimi 2.6。你的日常主力。在交付品質上與 Sonnet 相當，成本便宜 6 倍，沒有速率限制的頭痛問題
- 這是一個有很多迭代的長 agentic 循環嗎？→ 還是 Kimi 2.6。成本優勢在每次迭代中都會複合
- 這是 lint、格式化、單行編輯或瑣碎修復嗎？→ 實用層級（Haiku 4.5）。或者你的 IDE 的自動完成
- 這是樣板程式碼、自動完成或 stub 生成嗎？→ 本地層級（透過 Ollama 的 Qwen 3）。免費
大多數 vibe coder 從未設定這個，因為工具預設使用一個模型。但每個現代 AI 編碼工具現在都支援自訂模型——Cursor、Aider、Claude Code、Windsurf，全部都有
設定一個路由器需要 30 分鐘
在你做任何其他事情之前，它就能把你的帳單砍掉 50-70%！！！
模型層級（為每個任務挑選正確的模型）
知道要將每個任務發送給哪個模型是成功的一半。以下是每個主要模型如何實際融入一個智慧堆疊，不帶行銷話術
高階層級（用於會產生複合效應的決策）
Claude Opus 4.6：資深架構師。系列中最佳的判斷力，成本最高（約 $15/$75 每百萬）。用於系統設計、安全關鍵的審查、複雜的多檔案重構、除錯並發問題。大約 10% 的工作真正屬於這裡
GPT-5.5：在推理上與 Opus 接近的第二名，類似的定價層級（約 $10/$40）。在數學密集型任務和形式證明上常常領先。在長上下文連貫性和程式碼判斷上略遜一籌
主力層級（你的日常主力）
Kimi 2.6（Moonshot）：現代 AI 編碼堆疊中實際的主力（約 $0.50/$2）。這是大多數人搞錯的地方，所以我會直接說清楚：Kimi 2.6 在大多數編碼任務上匹配或超越 Sonnet 4.6，同時成本便宜 6 倍
我運行的基準測試（下面的完整表格）顯示 Kimi 2.6 在重構、除錯和程式碼生成上達到了 Sonnet 的品質，有時還稍微領先。2025 年那種「Kimi 是廉價選項」的框架已經過時了。在 2026 年，Kimi 2.6 是你應該預設使用的選項，而 Sonnet 則保留給那些它特定優勢真正重要的狹窄任務集
Kimi 2.6 明確勝出的地方：
- 長 agentic 循環（10 次以上迭代）。每次迭代都是一個小而範圍明確的步驟。執行一個 30 步驟的重構 agent：Opus 約 $25 美元，Sonnet 約 $5 美元，Kimi 約 $1 美元。同樣交付的程式碼。Kimi 在跨迭代的狀態處理上與 Sonnet 一樣好
- 中等到高複雜度的程式碼生成。CRUD 端點、脚手架、多檔案功能實作。Kimi 的程式碼品質 consistently 與 Sonnet 處於同一區間，價格只有 1/6
- 大規模重構任務。當你重寫 500 行的檔案時，Sonnet 的邊際品質並不會在交付的 diff 中顯現出來。Kimi 的輸出通過同樣的測試
- 持續運行的背景 agent。一個 24/7 的監控 agent 在 Sonnet 上每月運行 $200-400 美元。同樣的 agent 在 Kimi 上每月運行 $15-30 美元。Sonnet 版本划不來。Kimi 版本划得來
- 高吞吐量的批次任務。如果你的工作流程因為 Sonnet 的速率限制而被排隊 30 分鐘，那麼較便宜的模型在實務上也是較快的模型。Moonshot 的速率限制寬裕得多
- 長上下文工作。Kimi 2.6 的 256k 上下文視窗在高端範圍內匹配或超越 Sonnet 的連貫性。一年前「長上下文用 Sonnet」的規則已經不再成立
我仍然會改用其他模型的狹窄情況：
- 架構和系統設計決策 → Opus 或 GPT-5（高階層級，10% 的工作）
- 生產 PR 上的安全關鍵程式碼審查 → Opus
- 高度專業化的領域（形式驗證、利基編譯器）→ 高階層級
注意什麼不在那個清單上：嚴肅的實作工作、除錯、程式碼審查、重構、agentic 流程。那些現在都歸 Kimi 2.6 管
有效的框架：高階模型用於那 10% 會產生複合效應的決策，Kimi 2.6 用於 90% 的嚴肅交付工作，Haiku/本地用於那 10% 純粹的清理工作。Sonnet 最終落在一個薄薄的「我需要 Claude 模型來處理這個特定怪癖」用例的切片中，這沒問題，但不是預設
實用層級（清理和執行）
Claude Haiku 4.5：初級工程師。快速且便宜（約 $1/$5）。用於 lint、格式化、單行編輯、重新命名重構、簡單的 stub 生成。在多步驟工作上品質會下降，但對於不需要思考的任務來說很完美
GPT-5 mini / o4-mini：OpenAI 生態系統中相當於 Haiku 的模型。類似的定價層級和用例。選擇你的工具已經乾淨整合的那個
本地層級（零成本）
Qwen 3 / Llama 3（透過 Ollama）：在你的筆電上運行。每個 token $0 美元。最適合自動完成、打字、樣板程式碼、語法修復。不適合多步驟推理或任何需要細微差別的事情
誠實的評估
- 如果你只能有一個模型：2026 年 Kimi 2.6 是正確的選擇。以高品質涵蓋 90% 的用例，成本比一個 Sonnet 訂閱還低
- 如果你想要一個雙模型堆疊：Kimi 2.6 + Opus 用於高階決策。這是精簡、專家的設定。與全 Sonnet 基準相比，成本降低約 70%
- 如果你正在大規模交付：完整的路由器（Opus/Kimi/Haiku/本地）是唯一能讓帳單保持合理，同時在重要工作上保持品質的方法
大多數 vibe coder 犯的錯誤是預設使用 Sonnet，因為那是 2024-2025 年的行銷告訴他們的。2026 年的成本-品質數學不同了。Kimi 2.6 縮小了品質差距，而價格差距仍然很大。在 2026 年堅持以 Sonnet 作為預設，等於把 60-70% 的帳單留在桌上
[ 實用技巧 ] ↓↓↓
7 個在不損失品質的情況下降低成本的實用技巧
透過實作以下所有技巧，你可以達到我的結果，削減 80% 的 AI 編碼帳單成本
P.S. 如果你對如何將它們應用到你的工作空間有任何疑問，請在留言或我的私訊中提出
技巧 1：在可用的地方啟用提示快取
Anthropic、OpenAI、Moonshot——現在都支援提示快取。快取 token 的成本約為常規輸入的 10%
將你的穩定上下文（CLAUDE.md、系統指令、程式碼庫摘要）放在快取前綴中。以 5 分鐘為區塊組織你的工作（快取 TTL）
- 在 Claude Code 中：系統提示和 CLAUDE.md 會自動快取
- 在 Cursor 中：在設定 → 模型 →「使用提示快取」中啟用
- 在 Aider 中：傳遞
--cache-prompts
節省：穩定輸入 token 減少 60-90%
技巧 2：先 Grep 再擷取
與其「以防萬一」包含一個檔案，不如先 grep 那個符號或模式。只包含重要的部分
大多數「我需要整個檔案」的直覺是錯的。90% 的情況下，30 行就夠了
技巧 3：分析你的工具呼叫
記錄一週內每次工具呼叫的輸入/輸出 token 數量。你會發現失控的循環和重複擷取相同資料 10 次的工具
在 Claude Code 中快速記錄：啟用 --verbose-tools 並管道輸出到一個檔案。用 grep 分析。找出你最大的 token 黑洞
大多數 vibe coder 僅僅透過修復最糟的 3 個工具循環，就能削減 30-50%
技巧 4：使用漸進技能模式
一旦一個工作流程可行，就將其儲存為 SKILL.md 檔案。下一個 agent 載入該技能，完全跳過探索階段
例子：我的「部署到 staging」工作流程以前每次在 Opus 上花費 $4 美元，因為 agent 每次都要重新弄清楚環境。寫成一次 SKILL.md，將執行器切換到 Kimi 2.6。現在每次花費 $0.18 美元，交付相同的結果
這與 Browserbase 的 Autobrowse 用於瀏覽器 agent 的模式相同。一旦一個工作流程被捕捉為技能，後續的運行就會便宜一個數量級
這個原則也適用於編碼
技巧 5：使用本地模型處理樣板程式碼和自動完成
在 Ollama 上運行的 Qwen 3 / Llama 3 = 每個 token $0 美元，在你的筆電上運行
將它們用於：自動完成、打字、簡單補全、語法修復、stub 生成
不要將它們用於：複雜推理、任何多步驟的事情、任何品質重要的事情
設定只需 5 分鐘：
然後將你的 IDE 的自動完成指向 localhost:11434
節省：樣板程式碼層級 100%
技巧 6：在長時間工作階段中積極總結
每 10-15 次回合後，要求 agent 總結已經完成的事情以及下一步要做什麼。丟棄原始的對話上下文。從總結開始下一批
一個 200k token 的工作階段可以壓縮成一個 5k token 的總結。下一批從頭開始，成本只有繼續下去的 5%
大多數 vibe coder 從不這樣做，因為工具不會提示他們。設定一個 30 分鐘的計時器
技巧 7：批次處理你的「小」請求
與其一次問模型 10 個小問題（10 次獨立的 API 呼叫 = 10 次獨立的輸入前綴費用），不如將它們批次處理成一個提示：
「回答以下 10 件事，編號 1-10...」
節省：批次處理工作流程的輸入 token 減少 70-90%。搭配提示快取時尤其強大
[ 證明它有效的數字 ] ↓↓↓
每個實際任務的成本基準測試
我在主要模型上運行了相同的 4 個任務。這些是說明性的，你自己的基準測試會因任務類型和程式碼庫而異。但形狀才是重點
任務：重構 500 行檔案
Opus 4.6：$0.42 / 18s / 9.5
GPT-5：$0.32 / 16s / 9.4
Sonnet 4.6：$0.12 / 14s / 9.0
Kimi 2.6：$0.04 / 16s / 9.2
任務：建立 CRUD 端點
Opus 4.6：$0.18 / 22s / 9.0
GPT-5：$0.14 / 20s / 9.0
Sonnet 4.6：$0.06 / 18s / 9.0
Kimi 2.6：$0.02 / 17s / 9.0
任務：除錯堆疊追蹤
Opus 4.6：$0.08 / 11s / 9.5
GPT-5：$0.07 / 10s / 9.4
Sonnet 4.6：$0.03 / 9s / 9.0
Kimi 2.6：$0.01 / 10s / 9.1
任務：架構規劃
Opus 4.6：$0.65 / 28s / 9.8
GPT-5：$0.50 / 26s / 9.7
Sonnet 4.6：$0.22 / 24s / 8.5
Kimi 2.6：$0.08 / 25s / 9.2
有幾件事值得注意：
- Kimi 2.6 在所有 4 個任務上的品質匹配或超越 Sonnet 4.6，同時成本便宜 3-4 倍
- Kimi 2.6 以 1/10 的成本，落在 Opus / GPT-5 的 0.3-0.6 品質點內
- Haiku 很快，但在大多數任務上品質低於 ~7.0（只對瑣碎工作有價值）
- Opus / GPT-5 只有在架構決策上才有意義地領先，因為邊際品質很重要
對這個表格的合理解讀：將 10% 的架構工作路由到高階模型，90% 的例行和嚴肅工作路由到 Kimi 2.6，清理層級路由到 Haiku/本地。Sonnet 最終落在一個薄薄的邊緣案例切片中（長篇散文生成、某些 Claude 特定的模式），這沒問題，但不是預設。你在一週結束時交付的品質是可比較的。你在月底的帳單則不是
我的確切路由器配置（複製貼上）
這是我實際運行的配置。你的需要調整，但這是起點：
將此貼入你的 Claude Code 或 Cursor 配置（路徑因工具而異——請查閱它們的文件了解「自訂路由」或「模型選擇」）
- 在此配置之前：每月 $4,200 美元
- 之後：每月 $312 美元
- 比例：原始成本的 7.5%
- 關鍵任務的品質：不變
[ 你的 30 天 rollout 計畫 ] ↓↓↓
將帳單削減 80% 的 30 天計畫
如果你想要一個結構化的 rollout 而不是一次全部完成：
第 1 週：止血
- 在你使用的任何工具上啟用提示快取
- 對穩定的檔案關閉自動上下文
- 安裝 ripgrep，開始在詢問之前使用 grep
- 預期節省：30-40%
第 2 週：將預設切換到 Kimi 2.6
這是結構性的一週。之前的技巧是在削減浪費。切換你的預設模型才是真正改變單位經濟學的關鍵
- 設定你的工具的自訂模型配置
- 將你的預設主力路由到 Kimi 2.6。這是整個 30 天中最大的一步。大多數 vibe coder 習慣性地預設使用 Sonnet 4.6，為品質相當的交付程式碼支付了 6 倍的價格
- 將 lint/格式化路由到 Haiku
- 僅將 Opus / GPT-5 保留給規劃層級
- 預期額外節省：40-55%（你大部分的減少來自這一個切換）
第 3 週：分析並修復工具循環
- 啟用詳細工具記錄一週
- 找出你最貴的 3 個工具循環
- 用批次呼叫或確定性輔助工具取代它們
- 預期額外節省：10-20%
第 4 週：漸進技能 + 本地模型
- 找出你重複做的 3 個工作流程。將每個寫成 SKILL.md
- 設定 Ollama + Qwen 3 用於自動完成和樣板程式碼
- 將瑣碎任務路由到本地模型
- 預期額外節省：5-10%
累積：30 天內帳單減少 70-85%
而且不損失交付速度！！！
何時應該花更多錢（高階模型仍然勝出的 10%）
成本削減有其限制
有些任務確實需要高階模型。強迫一個廉價模型處理這些任務，會在重試和錯誤修復上花費比你節省更多的錢
始終使用 Opus / GPT-5 處理：
- 系統架構決策
- 安全關鍵的程式碼審查
- 具有橫切關注點的複雜多檔案重構
- 除錯並發/競爭條件
- 編譯器/形式驗證工作
規則：
如果錯誤答案的成本超過模型成本差異的 100 倍，就使用高階模型
一個規劃任務上 $0.50 美元的錯誤可能讓你損失一週
一個 $0.05 美元的修復出錯，30 秒內就能恢復
根據失敗的成本來為模型定價，而不是根據呼叫的成本
對於中間的所有事情（嚴肅的實作、重構、程式碼審查、非並發層級的除錯），Kimi 2.6 是正確的選擇。在你讀這篇文章之前，正是「為了安全起見使用高階模型」的本能燒掉了你的帳單
更大的圖景
你每省下的一塊錢 token 成本，都可以投入到更多的交付中
在 2027 年勝出的開發者，不會是那些擁有最好模型的人
他們會是那些擁有最佳上下文紀律和最聰明路由的人
12 個月後，每月花費 $200 美元和每月花費 $4,000 美元預算的開發者之間的差距，不會是技能
而是他們路由得好不好
希望你會選擇正確的道路，並且不懶惰地實作這篇文章中的所有技巧 ❤️
