AI 時代的 Token 數位時薪管理術 從 BPE 原理與 Prompt 精煉實踐 ROT 投資法

你輸入 20 個字，GitHub Copilot 實際消耗的可能超過 2,000 tokens。這不是誇張 — Copilot 會自動載入你看不見的 context：repo 結構、相鄰檔案、import 圖譜，每次互動都在靜默燒錢。

Token 不只是費用問題。它決定速率限制、context window 殘餘空間、以及首 token 回應速度。用得精，AI 才能給你真正有價值的輸出。

本文將從《把時間買回來》中的「人生時薪」出發，帶你建立「高信噪比 Prompt」的系統思維，把 Token 視為你的時間貨幣。

Token 帳本與 BPE 匯率損耗

Token 不是字、也不是字元，而是 subword（子詞）。

現代 LLM 使用 BPE（Byte Pair Encoding）演算法建立詞彙表：

1. 從原始 byte 開始（256 個初始值）
2. 找出訓練資料中最常見的 byte 對
3. 將這些 byte 對合併成新的 token
4. 重複，直到詞彙表約達 100K 個 token

如果用「時薪思考」來看，Token 就是你的時間貨幣。不同的語言與詞彙在 BPE 的解讀下，有著全然不同的「匯率」：

在 Claude 3 的 tokenizer 中，前 10,000 個常用英文單字裡有 8,311 個是單一 token。

最後一行說明了一個關鍵問題：「Sure, I’d be happy to help you with that!」消耗 10 個 token，卻帶來零資訊量。這些客套話是純粹的「資產折舊」。

Token 影響的 4 個面向：你的個人營運成本

理解為什麼要省 token，先看它如何扣減你的「個人營運成本」：

1. 費用（Cost）

API 與 UBB 計費都按 token 計算。重點：輸出費率通常是輸入的 5 倍，冗長的模型回應比你的 prompt 更燒錢。

2. 速率限制（Rate Limit）

每次請求消耗越少 token，每分鐘就能送出更多請求。這等於在同樣的時間內，你擁有更高的「產能」。

3. Context Window

輸入與輸出共用有限空間。輸入越省，留給輸出的空間越多，模型才能給出完整的答案。

4. 首 Token 回應速度（TTFT）

更少的輸入 token = 更快的首 token 回應時間（Time to First Token）。這會直接影響你的工作心流體驗。

你的 Prompt 背後，有多少看不見的 Token？

在 GitHub Copilot 中，你輸入的內容飾演著冰山一角：

你輸入 20 字 → 實際消耗 2,000+ tokens。

Copilot 會自動加入你看不見 of context — 這是設計，不是 bug。但你可以控制它的邊界。

不浪費 Token 的三大外包原則

原則一：只輸入 Relevant Context（拒絕無效會議）

在 Prompt 裡明確指定你需要的檔案，避免讓模型把整個 repo 當 context。

❌ 避免：

1

幫我檢查我的 repo 有沒有用到快取。

✅ 建議：

1
2
3
4
5

Context:
- src/api/user.ts
- src/lib/utils.ts

幫我檢查 src/api/user.ts 有沒有用到 src/lib/utils.ts 裡的 cacheData 函式。

明確指定檔案後，Copilot 只載入必要 context，節省幾百甚至上千個 token。

原則二：用摘要取代完整檔案（聘請專業經理人）

如果不需要看原始碼，用函式摘要即可。善用 function call 工具：

1
2
3

function get_file_summary(file_path: string)
function list_functions(file_path: string)
function analyze_imports(file_path: string)

這三個工具可以在不載入完整檔案的情況下，提取程式碼結構，大幅降低 context 消耗。

原則三：善用對話歷史，避免重複 Context（沿用合作默契）

第一次問問題時提供足夠 context，後續問題用對話歷史即可。

✅ 好的流程：

第一次：

1
2
3
4
5

Context:
- src/api/user.ts
- src/lib/utils.ts

幫我檢查 src/api/user.ts 有沒有用到 src/lib/utils.ts 裡的 cacheData 函式。

第二次（5 分鐘後）：

1

它被用在哪幾次？

不需要再提供相同檔案 — 對話歷史已經包含那份 context。

捨棄語言骨架：高信噪比的 Prompt 精煉

客套語言消耗大量 token，但對模型理解沒有幫助。這也是「省下不必要交易手續費」的第一步。

Before（~40 tokens）：

1
2
3

Hey, could you please help me refactor this function? I think it might have
some issues with how it handles the authentication, and I'd really like it
to be more efficient. Thanks!

After（~10 tokens）：

1

Refactor function. Fix auth handling. Make efficient.

結果：減少 75% token，模型理解程度相同。

應該捨棄

• 冠詞：a / an / the（在 prompt 中通常可省略）
• 填充詞：just、really、basically、actually、simply
• 客套話：「Sure, I’d be happy to help!」
• 模糊語氣：I think maybe / probably / you might want to…

應該保留

• 所有技術術語 — 精確照寫
• 程式碼 — 原樣保留
• 具體細節 — 越精確越好，而非越少越好
• 句型模板：[對象] [動作] [原因]. [下一步].

5 條實戰建議

根據我在多個專案中的實際測試，整理出以下五條高效能原則：

1. 始終用英文寫 prompt 與指令 — 比任何其他語言效率高 1.5–3 倍
2. 不要把 prompt 翻譯成 CJK 語言來省 token — 你只會花更多
3. 雙語使用者注意：母語可能寫得更精簡，但 token 成本仍較高
4. 程式碼輸出無論 prompt 語言都是英文 — 變數、註解、文件皆然
5. 非拉丁字母可音譯：俄文→拉丁節省約 21%、希伯來文→拉丁節省約 44%

copilot-instructions.md 的精實分層設計

.github/instructions/ 下的指令檔每次互動都會載入，是最容易被忽視的 token 黑洞。

建議的分層策略，專款專用，不繳冤枉稅：

React 元件問題不需要資料庫 migration 規範。如果全部放在全域常駐指令裡，每次都在為這份「稅」付費。

1
2
3
4
5
6
7

---
applyTo: "src/api/**/*.ts"
---
API conventions:
- Routes in src/api/routes/. Handlers thin, logic in services/.
- Validate with zod. Errors via Result<T,E>, never throw.
- All endpoints return { data, error } envelope.

控制輸出格式：從源頭減少輸出 Token

模型預設會解釋、會囉嗦。你可以在 copilot-instructions.md 或當下的 prompt 加入：

1

Code only, no explanation.

或在當下的 prompt 中：

1

Add input validation to processOrder(). Code only.

輸出格式控制的實際效果：

什麼時候不要用 “Code only”：學習或除錯時你需要解釋。只有在你清楚知道自己在做什麼、只是要實作的時候才使用。

拆解大任務：降低專案壞帳風險

一個大 prompt 的失敗成本很高；5 個小 prompt 每步可審查。

與其一次問：「幫我重構函式、加錯誤處理、寫測試、更新文件、檢查安全性」，不如拆成：

1
2
3
4
5

1. Refactor function.
2. Add error handling.
3. Write tests.
4. Update docs.
5. Check security.

這樣做的好處：

• 每步驟品質專注，輸出更精確
• 每步可審查再繼續，避免累積錯誤
• 失敗時只需重做該步，不浪費整段對話的 context，形同分散投資風險

延伸閱讀

這篇文章的思維框架可以延伸到更廣的 AI 工作流設計。如果你想深入了解 AI 輔助開發的系統性實踐，可以參考：

• AI Agent Skill 開發實踐指南 — 從 Prompt 到可複用工作流
• AI Agent Migration — 從 Gemini 到 AGY 的實戰紀錄
• 《把時間買回來》DRIP 矩陣與韁繩工程 — 如何把低價值工作自動化

FAQ

Q1：用中文寫 prompt 真的會花更多 token 嗎？

是的，顯著更多。 CJK 字元（中文、日文、韓文）在 BPE tokenizer 中通常一個字對應 1–2 個 token，而英文一個常見單字只需 1 個 token。加上中文往往需要更多字才能表達相同語意，整體效率明顯偏低。對於技術 prompt，英文是最節省 token 的選擇。

Q2：省 token 會不會降低輸出品質？

不一定。 省掉的是「填充詞」和「語言骨架」，而不是資訊本身。精確、簡潔的 prompt 往往讓模型更能聚焦，輸出品質反而更高。真正影響品質的是具體細節的精確度，而不是語句的冗長程度。

Q3：copilot-instructions.md 應該放多長？

越短越好，但不能犧牲關鍵規則。 建議常駐指令控制在 50–100 行以內，把特定情境的規範拆到 applyTo 條件式指令。這樣每次互動只載入真正需要的 context，避免為用不到的規則付費。

Q4：什麼是「token 黑洞」？怎麼找到它？

Token 黑洞是指每次互動都會載入、但大多數時候都用不到的 context。 最常見的來源是過於龐大的 copilot-instructions.md、過多的 #file 引用，以及包含大量 conversation history 的長對話。找到它的方法是觀察「你輸入多少字」vs「實際消耗多少 token」的落差。

本文根據在實際 AI 輔助開發工作流中的實測整理，數據來源包含 Anthropic tokenizer 研究與 GitHub Copilot 使用經驗。

• ← 上一篇