AI Coding 如何減少 Token？10 個實戰技巧，降低消耗又不犧牲程式碼品質

使用 Claude Code、Cursor、GitHub Copilot 或其他 AI Coding Agent 開發專案，最容易忽略的一件事，就是 Token 可能不是花在寫程式，而是花在理解專案、讀取無關檔案、重複分析，以及反覆修正。

例如，你只是想新增一支 IQC API，AI 卻開始探索整個 Repository、讀取大量 Model、分析不相關的前端元件，最後還產生一份很長的分析報告。

程式還沒寫，Token 已經消耗不少。

這時候，與其一味更換更強的模型，不如先思考：

能不能讓 AI 只讀取必要的資訊、執行必要的工作，並減少重複推理？

以下整理 10 個可以直接應用在 AI Coding 工作流程中的技巧。

一、限制 AI 的搜尋範圍，不要一開始就掃描整個專案

這是我認為最值得優先處理的問題。

當你要求 AI：

幫我分析整個專案，新增 IQC API。

AI 可能需要自行探索目錄、尋找相關 Model、追蹤資料庫關係，再判斷應該修改哪些檔案。

如果任務範圍不明確，探索成本就可能不斷增加。

更有效的方式，是直接指定起始範圍與調查方向：

請先檢查 backend 中與 IQC、GRN 相關的實作。

確認現有 Model、Router、Service、Schema、
權限檢查及測試慣例。

只有在必要依賴無法確認時，才擴大搜尋範圍。
不要掃描無關的 Frontend 模組。

這種做法的重點不是禁止 AI 查看其他檔案，而是採用「由近到遠」的調查策略。

先找直接相關的程式碼，再沿著實際依賴追查。

適用情境： 新增 API、修正 Bug、調整既有功能、處理單一模組的重構。

二、明確告訴 AI 哪些檔案不要讀

大型專案經常包含大量不需要進入一般開發上下文的檔案，例如：

node_modules/
dist/
build/
coverage/
__pycache__/
.pytest_cache/
*.log

依專案情況，也可以排除產生的文件、暫存資料及不相關的建置產物。

但要注意，不同工具使用不同的忽略機制。

例如：

• Claude Code 可以使用 CLAUDE.md、設定檔及相關的忽略或權限機制管理工作範圍。

• Cursor 可以透過 .cursor/rules/ 定義規則，也可以設定檔案排除。

• GitHub Copilot 可以使用 .github/copilot-instructions.md 提供專案指令。

這些設定的效果並不完全相同。

Git 的 .gitignore 也不代表 AI 一定不會讀取被忽略的檔案。

另外，排除規則應該依工具的實際行為設定，不能假設所有 AI Coding Agent 都支援相同的 .claudeignore 檔案。

還有一個實用原則：不要排除可能用於除錯的關鍵日誌、測試資料或設定檔。目標是減少無關資訊，不是讓 AI 失去必要的證據。

三、建立精簡的專案指令檔，避免每次重複輸入規則

如果你每次開發都要重複告訴 AI：

• 使用 FastAPI 與 Pydantic v2。

• 遵循現有 SQLAlchemy 寫法。

• Router 不要塞入大量業務邏輯。

• 修改前確認實際資料表結構。

• 不要任意新增 Service、DTO 或抽象層。

• 修改後執行相關測試。

那麼就可以把穩定且經常使用的規則放進專案指令檔。

例如：

smtms/
├── AGENTS.md
├── .github/
│   └── copilot-instructions.md
├── backend/
└── frontend/

AGENTS.md 可以放置適用於整個專案的開發原則；Copilot 的指令檔則用於對應的工具。

如果需要，也可以進一步設定模組專屬規則，避免所有任務都載入大量不相關的說明。

不過，這裡有一個容易忽略的細節：

指令檔不是越長越好。

如果一份規範包含數百行說明、重複的程式碼範例，以及大量與當前任務無關的規則，本身也可能增加上下文消耗。

建議優先保留：

1. 不可違反的業務規則。

2. 專案特有的程式碼慣例。

3. 必要的修改與驗證要求。

4. 常用文件的位置。

其餘內容再依任務需要載入。

四、把專案背景與業務規則分開，採用按需讀取

假設你的專案是 FastAPI + React 的品保管理系統 SMTMS。

AI 在新增 IQC API 時，不一定需要理解整個前端，也不一定需要重新閱讀所有驗收文件。

可以把長期有效的資訊整理成幾份精簡文件：

.ai/
├── architecture.md
├── business_rules.md
└── project_state.md

例如 business_rules.md：

# Business Rules

- IQC 檢驗紀錄必須符合既有收料流程
- GRN 必須關聯對應的供應商批次
- 實際用料必須能追溯至供應商批次

實際規則仍須以專案已確認的規格與實作為準，不能因為這個範例就直接假設所有資料表都採用相同設計。

執行任務時，要求 AI 先查看必要的背景與業務規則，再檢查相關程式碼即可。

例如：

先參考 .ai/business_rules.md。

接著檢查 IQC 與 GRN 的實際實作，
確認資料模型與 API 慣例後再修改。

若文件與程式碼不一致，先確認差異，
不要直接假設其中一方正確。

這種方式的好處，是不必每次重新解釋整個系統。

但不要為了管理 Context，刻意建立多份內容重複的文件。現有的 README、架構文件及驗收規格如果已經完整，就應該優先重用。

五、不要把所有原始碼貼進 Prompt，改用精準的檔案引用

另一種常見的 Token 浪費方式，是將大量程式碼直接複製到對話中。

例如，只需要修改一個 Router，卻把整個 Service、所有 Model、資料庫結構及前端頁面全部貼進去。

這不但增加輸入量，也可能讓重要資訊被大量次要內容淹沒。

比較好的方式是提供：

• 需求描述。

• 相關檔案路徑。

• 必要的程式碼片段。

• 已確認的業務規則。

• 驗收條件。

例如：

任務：修正 IQC API 的資料驗證。

優先檢查：
- IQC Router
- IQC Schema
- IQC Service
- 對應 Model
- 相關測試

先確認資料驗證在哪一層執行，
沿用既有模式，以最小差異修正。

不要為了這次修改重新分析整個專案。

如果工具能透過檔案引用、符號搜尋或程式碼索引取得內容，就善用這些能力。

但要注意，檔案引用語法並非所有工具通用。例如 @檔案路徑 的支援方式取決於使用的工具與介面。

六、控制 Session 長度，避免把所有工作塞進同一段對話

長時間使用同一個對話處理不同任務，也可能造成上下文膨脹。

例如：

1. 修正 JWT 認證。

2. 調整 RBAC 權限。

3. 修改供應商資料模型。

4. 開發 IQC。

5. 回頭處理前端表格。

這些工作可能有部分關聯，但也包含許多已經不再需要的歷史資訊。

建議依任務的關聯性管理 Session。

適合延續原 Session 的情況：

• 同一個 Bug 的調查與修正。

• 同一個功能的實作與測試。

• 需要延續前面已確認的技術決策。

適合開新 Session 的情況：

• 上一個任務已經完成。

• 開始完全不同的模組。

• 舊對話累積大量無關的工具輸出。

• AI 開始反覆引用已經過時的假設。

如果任務尚未完成，可以先整理目前狀態，再使用工具的上下文整理功能，或在新 Session 中提供必要摘要。

以 Claude Code 為例，可以使用 /clear 開始新的對話工作階段，或使用 /compact 整理目前上下文。

但要記得：新 Session 不會自動知道舊對話中所有重要資訊，因此應保留已確認的事實、修改檔案、測試結果及未解決問題。

七、建立簡短的 Project State，避免每次重新理解進度

對於持續開發的專案，可以維護一份 project_state.md：

# Project State

## Completed
- JWT Authentication
- RBAC
- Supplier Management

## In Progress
- IQC Module

## Next
- Complete IQC API
- Verify permissions
- Run related tests

## Known Constraints
- Follow existing SQLAlchemy patterns
- Verify actual schema before changing models

每次開始新任務時，先查看目前進度，就能減少重複說明背景的工作。

但這份文件應該短小，並且在重要變更後更新。

它不能取代程式碼、資料庫結構及測試結果。如果文件中的進度與實際實作不同，仍然需要核對現況。

最重要的是，不要把每一次聊天的所有內容都寫進去。

只保留會影響下一步工程決策的資訊。

八、限制 AI 的修改範圍，減少反覆修正的 Token

Token 不只會花在閱讀，也可能大量消耗在錯誤的修改循環。

例如，AI 為了修正一個 API 問題，順便重構多個 Service、調整資料模型、修改前端元件，最後引入更多錯誤。

接著又開始修正這些新問題。

這就是典型的無效迴圈。

可以在任務中加入以下要求：

1. 先確認根因與必要修改範圍。
2. 優先沿用現有實作模式。
3. 只修改完成需求所必要的檔案。
4. 不新增不必要的抽象層或重複邏輯。
5. 修改後執行與變更直接相關的測試。
6. 若測試失敗，先分析原因，不要盲目擴大修改。
7. 最後回報修改檔案、驗證結果及未解決問題。

這類限制能減少不必要的程式碼產生、工具呼叫及後續除錯。

但不要把「最小差異」理解成「只能修改一個檔案」。如果正確修正確實需要同步調整 Schema、Service、Router 與測試，就應該完整修改。

目標是避免無關變更，而不是限制必要的工程工作。

九、減少冗長的工具輸出與分析報告

在 AI Coding 工作流程中，工具輸出也是值得管理的成本來源。

例如執行測試時，如果整份測試日誌有數千行，但真正的問題只有一個 AssertionError，就不一定需要把全部輸出都交給模型分析。

可以先使用適當的篩選方式，保留：

• 失敗的測試名稱。

• 例外訊息。

• 必要的呼叫堆疊。

• 與錯誤相關的程式碼。

• 測試總結。

對於大型搜尋結果，也可以先查看檔案清單與相關片段，再決定是否需要讀取完整內容。

另外，任務回報也可以依複雜度調整。

小型修正只需要回報修改內容與測試結果；跨模組重構則需要說明設計取捨、相容性及風險。

不需要每次修改一行程式碼，都產生一份完整的架構分析報告。

不過，過度壓縮日誌也可能漏掉重要錯誤，因此應保留能夠支持判斷的必要證據。

十、量測實際 Token 用量，不要只靠感覺

以上技巧可能改善效率，但不能直接推論每個專案都能減少固定比例的 Token。

實際成效會受到模型、工具、任務複雜度、快取機制及上下文管理方式影響。

如果想確認哪些方法真的有效，可以挑選幾個相似任務，記錄導入前後的結果：

指標	觀察目的
輸入 Token	是否減少無關上下文
輸出 Token	是否減少不必要的報告與程式碼
快取 Token	是否有效利用產品提供的快取
工具呼叫次數	是否減少重複搜尋與讀取
修改檔案數	是否減少無關變更
測試結果	是否維持正確性
人工修正次數	是否降低返工成本
完成時間與實際費用	是否真正提升開發效率

不同平台的用量統計方式可能不同，應使用各平台實際提供的資料，並在相同模型、相近任務與一致驗收標準下比較。

不要只看 Token 數字下降，卻忽略測試失敗、人工修正增加或開發時間變長。

真正有價值的是：用更少的無效消耗，完成品質相同甚至更好的工程任務。

最後：我會優先採用哪幾個技巧？

如果現在要開始改善 AI Coding 的 Token 使用效率，我會按照以下順序執行：

1. 縮小搜尋範圍：讓 AI 從相關模組開始調查。

2. 控制上下文：只提供任務真正需要的文件與程式碼。

3. 建立精簡規範：避免每次重複輸入相同要求。

4. 管理 Session：任務結束後，適時整理或重新開始對話。

5. 控制修改範圍：減少不必要的重構與返工。

6. 精簡工具輸出：只保留有助於判斷的必要資訊。

7. 持續量測：確認 Token、成本、時間與品質是否一起改善。

這些方法不需要一次導入所有工具，也不需要先把專案改造成複雜的 AI 架構。

從下一次新增 API 或修正 Bug 開始，先明確指定調查範圍、必要規則及驗收條件，就能逐步建立更有效率的 AI Coding 工作流程。

降低 Token 的關鍵，不是讓 AI 少做必要的工作，而是不要讓 AI 把資源花在不必要的工作上。

延伸工具：OmniRoute 與 AI 原生 Repo

除了 Context Engineering，也可以關注 OmniRoute 這類 AI Gateway。它的定位是統一模型 API 入口，協助管理不同模型供應商、路由與故障轉移；實際支援能力仍需依工具及模型相容性確認。

但要注意，模型路由不等於 Token 優化。

真正減少不必要消耗的關鍵，仍然是讓 AI 只讀取任務需要的資訊，而不是每次都把整個專案塞進上下文。

我會優先做好：

• AGENTS.md：定義 AI Agent 的專案工作規則

• .ai/：整理架構、業務規則與專案狀態，按需載入

• Cursor Rules / TRAE Rules：依各工具的機制設定規則入口

當這些基礎建立好，再搭配 OmniRoute 管理多模型，才更有機會兼顧開發效率、成本與可靠性。

AI Coding 的重點，不只是選對模型，而是讓模型在正確的上下文中完成正確的任務。