前言

使用 AI 寫程式之後，開發速度確實快了不少，但實際使用時，還是可能遇到對話越來越長、需求反覆說明，以及 AI 修改超出預期等問題。

有時候只是想修正一支 API，卻需要來回溝通好幾次；有時候 AI 修改了很多程式碼，最後卻發現真正需要調整的只有一小部分。

這些情況都會增加開發成本。因此，除了讓 AI 寫出程式，也可以進一步思考如何減少不必要的資訊、降低反覆修改的次數，並把有效的開發習慣保存下來。

Token 是什麼？為什麼需要管理？

使用 AI 時，經常會聽到 Token 這個詞，可以先把它理解成模型處理文字與程式碼時使用的基本單位。實際的切分方式取決於模型使用的分詞規則，因此一個中文字或英文單字不一定只對應一個 Token。

當我們請 AI 修改程式時，模型可能需要參考目前的對話、相關程式碼、專案指令，以及執行工具後得到的結果。這些資訊可能占用模型的 Context Window，也就是模型一次能夠處理的上下文容量。

可以把 Context 想成 AI 完成任務時需要參考的資料，而 Token 則是處理這些資訊時使用的單位。兩者有關，但並不是同一件事。實際的 Token 使用量與費用，也會受到模型、輸入輸出內容及服務計費方式等因素影響。

當對話越來越長，裡面可能累積許多已經解決的問題、先前的錯誤訊息，以及與當前任務無關的內容。這些資訊不一定能幫助 AI 完成下一個任務，因此有必要適時整理。

管理 Token 並不是把每段提示詞都寫得越短越好，而是讓 AI 取得足夠且相關的資訊，減少不必要的輸入、輸出與反覆修改。

從日常習慣開始管理 Context

先把任務說清楚

假設現在要修改筆記系統的單筆查詢 API，如果只告訴 AI「幫我改善筆記 API」，它可能會自行決定要調整哪些地方，甚至順便重構其他程式碼。當修改超出原本的需求，就需要花更多時間檢查與修正。

相較之下，如果先說明這次要解決的問題、允許修改的範圍，以及完成後需要確認的條件，AI 就比較容易掌握任務方向。

例如，可以先處理筆記查詢，再確認使用者是否有權限讀取該筆筆記，最後檢查相關錯誤情境與測試。如果幾個步驟彼此相關，可以一起完成；當任務包含太多不同的目標時，再拆成幾個容易確認的小階段即可。

任務越明確，就越容易判斷 AI 是否完成了真正需要的工作，也能降低因為誤解需求而反覆修改的機會。

只提供完成任務需要的資訊

當 AI 需要理解專案架構時，提供必要的背景很重要，但不代表每次修改都要重新貼上整個專案的程式碼。

例如，這次要修改 GET /api/notes/:id，可以先讓 AI 查看對應的 Route、Service，以及相關的權限驗證與測試程式碼。如果問題涉及資料庫查詢，再繼續查看相關的 Entity 或資料表結構。

如果使用的是能讀取專案檔案的 Coding Agent，例如 Codex，也可以直接要求它檢查相關檔案，不需要手動把每個檔案的完整內容複製到對話裡。

不過，精簡資訊不代表限制 AI 不能查看其他檔案。如果問題可能來自其他模組，就應該繼續追查相關程式碼。真正需要減少的是與任務無關的內容，而不是解決問題所需的線索。

讓 AI 的回覆符合當下的需求

除了輸入的資訊，AI 的回覆內容也可以依照任務調整。

如果正在學習新的技術，可以請 AI 解釋程式碼的寫法與原因；如果只是要修改已經熟悉的 API，則可以請它簡單整理修改了哪些檔案、執行了哪些測試，以及還有哪些問題尚未解決。

不需要每次都要求 AI 詳細解釋所有程式碼，也不用為了節省 Token 而禁止它提供必要的說明。當問題比較複雜時，適當的分析仍然很重要，重點是避免產生與任務無關的大量內容。

什麼時候該整理對話？

使用 AI 一段時間後，對話裡可能同時包含需求討論、程式碼修改、測試錯誤，以及已經解決的問題。如果接下來準備處理另一個功能，就可以考慮先整理目前的進度，再決定是否需要開啟新的對話。

那要怎麼知道 Context 是否已經累積太多？

如果使用的工具有提供 Context 使用量指示器，就可以查看目前的使用情況。有些工具也會提供上下文壓縮的提示，表示系統正在整理先前的對話內容。不同工具與版本的介面可能不同，因此不一定每個工具都會顯示相同的資訊。

如果沒有明確的用量提示，也可以在任務結束或準備切換工作時，主動檢查目前的對話是否還有保留的必要。例如，AI 開始反覆詢問已經說明過的事情，或修改方向逐漸偏離需求時，就值得重新確認目前的需求與相關背景是否清楚。

不過，這些現象不一定代表 Context 已經用滿，也可能是需求不夠明確，或 AI 還沒取得必要的程式碼。因此，不必因為對話比較長就立刻重開視窗，可以依照任務進度與實際需要判斷。

如果準備整理，可以請 AI 摘要目前的工作：

請整理目前任務的進度，包含：
1. 已完成的修改與相關檔案
2. 重要的技術決策
3. 已執行的測試與實際結果
4. 尚未解決的問題與下一步

請保留繼續完成任務所需的資訊，
不需要重貼完整程式碼。

整理完之後，就能保留真正重要的內容。如果要開啟新對話，可以將這份摘要與接下來的需求一起提供給 AI。

需要注意的是，新對話不一定會自動保留舊對話的完整脈絡，因此仍然需要提供必要背景。重新開啟對話也不一定能降低總 Token 用量，因為重新提供資訊同樣會產生使用量。真正重要的是，避免反覆帶入已經不再需要的內容。

減少無效修改，讓每次嘗試都有依據

即使已經清楚交代需求，AI 寫出來的程式仍然可能有問題。這時就需要透過測試與實際結果，確認修改是否有效。

假設筆記 API 的測試發現，使用者可以讀取其他人的筆記，就應該先確認權限檢查出了什麼問題，再請 AI 針對原因修正，而不是直接要求它重寫整支 API。

當 AI 完成修改後，可以執行相關測試。如果測試失敗，就根據錯誤訊息分析原因，針對問題進行修正，再重新執行測試。這個反覆進行「修改、觀察、修正、再次確認」的過程，就是常說的 Feedback Loop。

透過這種方式，每一次修正都有實際結果可以參考，也比較容易控制修改範圍。相反地，如果每次測試失敗都要求 AI 全面重寫程式，就可能讓原本沒有問題的部分也跟著變動，增加新的錯誤與檢查成本。

最後，還是要檢查 Git Diff，確認實際變更是否符合需求，並確認測試是否真的執行、結果是否通過。AI 回報「已經修正完成」只能作為參考，仍然需要根據實際結果判斷。

把常用的規則保存下來

當我們使用 AI 開發一段時間後，可能會發現有些要求幾乎每次都要交代，例如遵循原本的專案架構、修改後執行測試，以及最後檢查 Git Diff。

如果每次都重新輸入這些要求，不只麻煩，也可能因為疏忽而漏掉。這時就可以把共通的開發規則保存成文件，讓 AI 在後續任務中參考。

用 AGENTS.md 保存專案規則

以 Codex 為例，可以在專案根目錄建立一個名為 AGENTS.md 的檔案，記錄這個專案的開發原則與必要檢查。Codex 在處理專案任務時，可以依照適用的指令了解需要遵循的規則。

例如：

# Development Rules

- Follow the existing project architecture.
- Keep changes scoped to the requested task.
- Avoid unrelated refactoring.

# Verification

- Run relevant tests after changing behavior.
- Review the Git diff before finishing.
- Report actual test results.
- Mention tests that were not executed.

這份文件保存的是專案共通的規則。之後新增 API、修正錯誤或調整資料庫查詢時，AI 就能參考這些指引，不必每次都從頭交代相同的原則。

不過，AGENTS.md 並不是越長越好。如果把所有操作細節、技術背景與例外情況都塞進去，反而可能增加 AI 需要處理的資訊。只要保留多數任務都需要遵守的原則即可，並隨著專案實際需求逐步調整。

另外，文件中的文字只是提供 AI 遵循的指引，並不保證每個步驟都會確實執行。因此，重要的檢查仍然應該搭配測試工具。例如，可以在 package.json 中定義測試指令，再讓 AI 實際執行，根據測試結果確認程式是否符合預期。

這樣就把專案規則與實際驗證連接起來，也能減少每次開發都要重複交代的內容。

從固定流程理解 Harness

當 AI 開始依照專案指令讀取程式碼、使用工具、執行測試，並根據結果持續修正時，就能進一步理解 AI Coding 中的 Harness 概念。

可以先把 Harness 理解成支援 AI 執行任務的整體環境與控制機制，可能包含模型能參考的資訊、可以使用的工具、執行時遵循的規則，以及檢查工作結果的方式。

前面提到的 AGENTS.md、測試工具與開發流程，都可以成為這個環境的一部分，但它們並不等於完整的 Harness。Feedback Loop 著重在根據執行結果反覆修正，Harness 的範圍則更廣，還包含支援整個執行過程的環境與控制方式。

對初學者而言，不需要一開始就打造複雜的自動化系統。先把任務說清楚、保存必要的專案規則，並透過測試確認修改結果，就已經能改善開發過程。等到某些工作經常重複，而且確實值得自動化時，再逐步建立更完整的流程即可。

結語

使用 AI Coding 之後，寫程式的速度變快了，但開發效率仍然取決於我們如何管理資訊、交代任務，以及確認修改結果。

節省 Token，可以從減少無關資訊、適時整理對話，以及讓 AI 的回覆符合需求開始；減少無效修改，則需要清楚的任務目標、合理的修改範圍，以及實際的測試與檢查。

當這些方法逐漸變成習慣，也可以把共通規則保存起來，讓後續開發更有一致性。

走到這裡，30 天的後端學習也即將告一段落。最後一天，想回頭整理這段學習歷程，重新串起從後端基礎、資料庫與登入驗證，到測試、部署和 AI Coding 的完整脈絡，看看這些技術如何組合成一個真正能運作的系統。