如何節省 Token？會議報告

這場討論整合了會前 63 則文字訊息，以及約 1 小時 52 分的語音會議。大家分享了省 Token 的工具、短 Prompt、免費模型與 Routing；雖然沒有正式表決或統一方案，一條主線反覆出現：真正燒錢的往往不是多打幾個字，而是讓模型反覆背著肥大的上下文工作，需求沒想清楚又推倒重來，或把每個任務都送進同一套昂貴流程。

01問題不只在帳單

26 分享自己的用量紀錄：在調整 Session 與模型分工前，一天最高可用到約 20 億 Token；調整後降到約 8.4 億，但快取讀取仍占很高比例。這是個人觀察，不是通用基準；會中對快取機制的解釋也明確保留了不確定性。可以確定的是，反覆攜帶大量前文會持續占用 Token，長期累積仍然可觀。

Benben 把代價分成四種：金錢、延遲、Context 上限，以及 Attention 被雜訊稀釋。上下文愈長，模型不只更慢，也更容易抓錯重點，甚至出現語言漂移或幻覺。換句話說，省 Token 不是單純省錢，而是在保護模型的注意力與工作品質。

文字討論串裡最直接的一句話是：

「上下文根本就是最毒的東西。」

它不是要大家每聊幾句就清空，而是提醒我們：歷史紀錄只有在仍與眼前任務有關時才有價值。

02最有效的方法，是重畫工作邊界

文字與語音裡反覆出現的做法，是把探索、執行與驗收拆開。規劃階段可以使用較完整的背景，先把需求、限制與驗收條件談清楚；接著由乾淨 Session 或 Subagent 執行單一任務；完成後再交給獨立角色驗收。Tiffany 在文字串分享的流程正是如此：先討論並產生 Plan，再開新 Session 執行，最後另開 Session 檢查有沒有跑偏。

這套方法要成立，交接文件不能只寫「做到一半」。它至少要留下目標、已完成內容、重要決策、限制、未完成項目與驗收方式。26 曾讓 Agent 自行交接，結果出現漏寫與亂寫，因此後來改成統一格式。Cyclone 也展示了用工作卡片記錄需求、負責 Agent、進度與交接內容的做法，目的在提升可見性並避免重工。會中用了一個很生活化的比喻：像公司裡不同部門協作，上一個部門做完就交給下一個，不要永遠累死第一個部門；但交接單必須讓接手的人看得懂。

03壓縮有用，但不能壓掉任務本身

Benben 展示了 Caveman 式 Prompt，把冗長請求縮成只保留意圖的短句；另一類方法則是在工具輸出進入模型前，先刪除空白、重複欄位與無關資訊。這些方法對目標明確的任務很有效，例如列目錄、看 Git 狀態、Review 結構。

不過，短不等於好。安全限制、輸出格式、不可變條件與驗收規則若被一起刪掉，模型做錯後重跑，總消耗反而更高。真正該刪的是禮貌性贅詞、重複說明和工具雜訊，不是讓任務成立的條件。

04模型 Routing：用剛好夠用的能力

Cyclone、Benben 與 Rycen 都提到依任務分配模型：規劃與重要決策交給能力較強的模型；查資料、簡單實作或 PR Review，可嘗試較便宜、免費或本地模型。Benben 的原則很務實：先找能力「剛好夠用」的模型，而不是每件事都叫最貴的模型上場。Rycen 則分享一對多的 Agent 分工，由主要 Agent 切任務，再交給其他工具執行與 Review。

會中也談到 MOA、MOE 等多模型概念，現場甚至一度混淆名稱。比縮寫更重要的是成本邏輯：同一問題若交給多個模型獨立回答再彙總，通常會花更多 Token，但可能換得更完整的答案與較少盲點；若 Router 能把任務準確送給適合的模型，才有機會同時省成本與時間。多模型互審是品質工具，不該包裝成免費的省 Token 魔法。

05最隱形的浪費：過度設計與反覆退件

Tiffany 分享自己的流程在第一步就被審核模型退件約八次；26 也遇過簡單功能被拉進罕見攻擊情境，跑了數十輪仍無法交付。這提醒大家，治理與安全不是愈多愈好。風險高的工作需要嚴格審核，但低風險功能若套用同一組重型關卡，會把 Token、時間與人的耐心一起耗光。26 提出的下一版做法，是先做出可上線版本，再把審核發現的問題列出來，由人決定哪些現在修、哪些延後；這仍是待驗證的設計方向。

06給剛開始用 Agent 的人

Kumi 提到，自己一度卡在「該選哪個模型、怎麼省 Token」，反而忘了先處理真正想解決的事情。後來她開始直接試用工具，才逐漸看見 AI 能協助查資料、交叉比對、準備導覽與練習口條。

會議後段因此多了一個比省 Token 更重要的結論：小工具不比大型系統低級。只要它真的解決生活中的問題，就是好的設計。社群的價值也不在展示誰的架構最大，而是把半成品、卡點與做法拿出來，讓別人能接著提出意見。

07會後可直接採用的做法

1. 先記錄 Token 花在哪裡，不要憑感覺優化。
2. 一個 Session 保持一個清楚目標；里程碑完成就交接、換新 Session。
3. 先寫 Plan 與驗收條件，再把執行交給乾淨 Session 或 Subagent。
4. 依任務難度選模型；多模型互審只用在值得付出額外成本的地方。
5. 壓縮 Prompt 與工具輸出，但保留限制、格式與驗收規則。
6. 用完成同一個可驗收成果所需的總 Token、總時間與返工次數來比較方案。

會中幾句值得留下的話，依逐字稿做了輕度整理：

「每一個 Subagent，就專心只做一件事。」

「省 Token 不是只有金錢上的部分。」

「你先試了，才比較知道下一步怎麼做。」

「只要真的解決你生活遇到的問題，就是好的設計。」

依逐字稿做了輕度整理

這場會議最後沒有選出一個萬用 Skill。它留下的是一套比較可靠的判斷順序：先減少重工，再隔離無關上下文；先把交接寫好，再談模型與工具 Routing；最後才處理每句 Prompt 能不能再短兩個字。