AI 程式設計接下來真正重要的指標，可能不是“誰的模型最強”，而是誰能用更少的 token、更低的成本、更穩定的流程，完成更多可驗收的工作。
這就是 Token Efficiency 的價值。
很多人理解 Token Efficiency，只會想到模型便宜、上下文變長、快取命中更低價。但這些只是底層條件。真正能把它變成生產力的，是模型分工、任務編排、上下文預算和評估體系。
換句話說，Token Efficiency 不是省錢技巧，而是一套把 token 轉換成產出的工程方法。
DeepSeek V4 的定位：把大小模型分工產品化
這篇文章最應該先補上的背景，是 DeepSeek V4 的定位。
DeepSeek V4 不是單純釋出一個更強模型，而是把 Token Efficiency 需要的兩層能力直接拆成了 V4 Pro 和 V4 Flash：Pro 更適合做規劃、推理、架構判斷和關鍵審查，Flash 更適合做高頻執行、批次改寫、程式碼補全、資料整理和 agent 迴圈裡的普通節點。
這正好對應 AI 程式設計裡的兩個角色：
V4 Pro：當作 planner / consultant，用在需求拆解、技術方案、複雜 bug 根因、架構審查和最終驗收。V4 Flash：當作 executor，用在檔案掃描、簡單實現、測試補齊、文件整理、候選方案生成和重複性任務。
DeepSeek 官方 API 文件顯示，V4 Flash 和 V4 Pro 都支援 1M 上下文、JSON Output、Tool Calls、Chat Prefix Completion 和 FIM Completion；價格頁也把快取命中輸入單獨計價，並說明全模型 input cache hit 價格已降到釋出價的十分之一。這幾個點組合起來，才是它和 Token Efficiency 關係最密的地方。
1M 上下文解決的是複雜 agent 任務容易被壓縮的問題；低快取命中價格解決的是長系統 prompt、專案文件、程式碼片段和歷史狀態反覆進入上下文的成本問題；Flash / Pro 雙模型形態解決的是“每一步都用旗艦模型太貴、每一步都用小模型又不穩”的分工問題。
所以 DeepSeek V4 的優勢不應該只寫成“便宜”或“上下文長”，而應該理解成三件事：
- 執行層便宜：大量 agent 節點可以交給
V4 Flash，讓 token 消耗落在低成本模型上。 - 判斷層可用：關鍵步驟仍然可以呼叫
V4 Pro，避免為了省錢犧牲複雜推理質量。 - 長鏈路友好：
1M上下文和快取價格讓程式碼庫、文件、工具呼叫歷史更容易留在可用視窗裡。
這就是為什麼 DeepSeek V4 對 AI 程式設計的意義，不只是又多了一個模型選項，而是給“顧問模型 + 執行模型 + harness 編排”的模式提供了更現實的成本結構。
不要讓最強模型幹所有活
過去使用 AI，常見做法是找一個最聰明的模型，讓它從需求分析、程式碼實現、測試、總結一路幹到底。
這個方式簡單，但不一定高效。因為很多工並不需要最高階別的推理能力。真正貴的模型，應該更像顧問、架構師或規劃員：只在關鍵決策點介入。
更合理的結構是：
- 大模型負責拆問題、定方向、做關鍵判斷。
- 小模型負責執行、批次處理、重複修改。
- 工具和 harness 負責流程、狀態、上下文和驗證。
- 人負責定義產品、驗收結果和決定取捨。
這樣做的好處是，前沿推理能力不會被浪費在機械執行上。大部分 token 消耗可以落到便宜模型和快取輸入裡，貴模型只處理真正需要“腦力”的部分。
上下文不是越大越好
長上下文很重要，尤其是 coding agent。程式碼、文件、歷史對話、測試輸出、錯誤日誌都會吃掉上下文。上下文一旦接近上限，模型就容易觸發壓縮、遺忘或誤判。
但長上下文不等於可以無限塞資料。
Token Efficiency 的關鍵，是讓每個任務都能在一個清晰、可控的上下文視窗內完成。最理想的狀態不是“把整個倉庫塞進去”，而是：
- 當前任務只帶必要檔案。
- 背景文件只帶決策相關部分。
- 歷史資訊只保留當前階段需要的狀態。
- 每個節點有明確輸入和輸出。
- 完成後把結果壓縮成結構化摘要，交給下一個節點。
上下文越便宜，越要警惕浪費。便宜 token 會誘導人把無關資訊全塞進去，最後模型不是更聰明，而是更容易被噪聲拖慢。
Harness 比單個模型更重要
如果只是把 Claude Code、Codex 或其他 coding agent 接到便宜模型上，效果未必好。小模型容易在長鏈路任務裡跑偏，需要更強的流程控制。
真正讓小模型發揮價值的，是 harness。
這裡的 harness 可以理解為一套排程系統：它知道任務怎麼拆、節點怎麼跑、模型怎麼選、結果怎麼驗收、失敗怎麼重試、上下文怎麼傳遞。
一個可用的編排系統，至少要回答幾個問題：
- 哪些任務需要規劃？
- 哪些任務可以直接執行？
- 哪些節點可以並行？
- 哪些節點必須序列？
- 哪個節點用大模型，哪個節點用小模型？
- 每個節點最多允許多少上下文？
- 每個節點完成後輸出什麼結構？
- 誰來 review，誰來決定是否繼續？
沒有這層軟體，小模型只是便宜；有了這層軟體，小模型才可能變成槓桿。
用 DAG 拆任務
一個有效的思路，是把複雜任務拆成有向無環圖，也就是 DAG。
比如一個功能開發任務，可以拆成：
- 需求澄清
- 方案設計
- 任務拆分
- 編碼實現
- 測試補齊
- Code Review
- 修復問題
- 提交 PR
每個節點都可以是一個獨立 agent。它們執行在獨立環境裡，有自己的角色、prompt、工具許可權和輸出格式。節點之間不靠長篇聊天傳遞資訊，而是靠預先定義好的結構化結果。
這會帶來兩個直接收益。
第一，單個節點更短。任務越小，越容易被小模型完成，也越不容易撐爆上下文。
第二，流程更可測。你可以單獨觀察“編碼節點失敗率高”還是“review 節點漏問題多”，然後針對性最佳化。
任務可以跑多個副本
當 token 足夠便宜時，一個有趣的變化會出現：同一個任務不一定只跑一次。
你可以讓同一個任務用不同模型、不同 prompt、不同編排跑多個副本，再從結果裡選最好的，或者把多個結果合併。這個思路有點像“抽卡式任務解決”，但前提是必須有評估和驗收。
適合多副本的任務包括：
- 方案設計
- 文案生成
- 測試用例補全
- Bug 根因假設
- 重構方案比較
- Code Review
不適合盲目多副本的任務，是那些會直接修改共享狀態、會產生外部副作用、或者驗收標準不清楚的任務。
多跑幾次不是為了碰運氣，而是為了獲得可比較樣本。樣本越多，越能反過來最佳化編排、模型選擇和節點技能。
必須建立評估體系
Token Efficiency 不能只看價格。便宜但失敗率高，最後會吞掉人的時間，反而更貴。
所以每個團隊都應該逐步建立自己的評估體系。它不需要一開始就很複雜，但要能量化。
可以先記錄這些指標：
- 任務完成率
- 人工介入次數
- 工具呼叫失敗率
- 測試透過率
- Review 發現的問題數量
- 單任務 token 成本
- 單任務耗時
- 返工次數
- 不同模型組合的差異
有了這些資料，才能知道哪些任務適合小模型，哪些任務必須上大模型，哪些任務應該交給人判斷。
真正的最佳化不是“所有地方都換便宜模型”，而是把每類任務放到最合適的模型和流程裡。
業務流程要原子化
普通使用者不一定要自己寫完整 harness。未來這類工具會越來越多，也會越來越成熟。
但現在就可以做一件事：把自己的業務流程拆成原子節點。
比如內容生產可以拆成：
- 選題
- 資料收集
- 提綱
- 初稿
- 事實核查
- 風格改寫
- SEO 標題
- 多語言翻譯
- 釋出檢查
軟體開發可以拆成：
- 需求確認
- 技術方案
- 資料結構
- 介面變更
- 單元測試
- 實現
- 遷移指令碼
- 文件
- Review
每個節點都要儘量做到輸入明確、輸出明確、驗收明確、上下文可控。這樣等 harness 工具成熟時，你的業務流程可以直接接進去。
硬體不是第一優先順序
很多人聊 Token Efficiency，很快就會聊到本地部署和顯示卡。但對大多數人來說，第一選擇仍然應該是 API。
原因很簡單：在沒有跑通經濟模型之前，本地硬體只是成本前置。你還不知道 token 怎麼轉化成收入或生產力，就先買昂貴裝置，很容易變成玩具。
更穩的順序是：
- 先用 API 跑通業務流程。
- 建立任務評估和成本統計。
- 找到穩定高頻的執行節點。
- 再考慮哪些節點值得本地化。
- 最後再計算硬體、電費、維護和折舊。
如果只是個人提效，API 往往已經夠用。如果是創業團隊，要驗證模型邊界和推理框架，本地 CUDA 平臺才更有學習價值。如果已經有明確生產場景和經濟模型，多卡部署才有討論空間。
小結
Token Efficiency 的本質，不是“用便宜模型替代貴模型”，而是重新設計 AI 工作流。
大模型負責關鍵判斷，小模型負責批次執行，harness 負責排程和驗證，人負責定義目標和驗收結果。只有這四層配合起來，token 才能穩定變成生產力。
接下來真正有價值的能力，不只是會用最新模型，而是能把任務拆小、把上下文控住、把結果量化、把流程編排起來。
模型會繼續降價，上下文會繼續變長，小模型會繼續變強。越是這樣，越應該早點理解 Token Efficiency。因為未來的差距，很可能不在誰呼叫了最強模型，而在誰能用同樣的 token 撬動更多真實產出。