AI Coding 詞典拆解（01）：模型、推論與 Harness 如何組成一次工作

「AI 幫我改好了」描述的是一段體驗，還不是技術上的解釋。一次程式修改可能經過模型生成、服務端推論、工具執行、檔案讀取和測試驗證。若把整段過程都叫作「模型在做」，故障時便很難知道該改提示、換模型、修工具，還是檢查服務狀態。

本文依照《Dictionary of AI Coding》第一單元的 16 個詞目，將它們放進同一條工作流程裡說明。本文是延伸教學，不是原詞條的逐句翻譯。課綱與詞典固定在原 repo 的 ed1ebed；供應商文件用來核對會變動的 API 行為。

「AI」是一個標籤，Model 才指向具體元件

AI 不是某一種固定的程式或硬體名稱。這個詞會隨著電腦新近能做到的事而移動，所以「AI 寫程式可靠嗎？」範圍太廣。回答前要先問，指的是哪個 Model、哪種 Agent、使用什麼 Harness，以及它能讀取哪些資料、執行哪些工具。今天常見的 AI coding 產品通常以大型語言模型為核心，但產品本身不等於模型。

Model 是根據輸入產生輸出的數學模型。它接收 Token 序列，經過訓練得到的數值運算，預測後續可能的 Token。單獨的模型沒有專案目錄、網路連線或終端機，也不會自行打開檔案。這些能力要由外部系統提供。

模型內部的大量數值稱為 Parameters，也常叫權重。它們不是可直接查詢的資料表；模型把訓練所得的統計規律編進這些數值，推論時再透過計算產生結果。這個區別解釋了為什麼模型能回答常見 API 問題，卻仍可能編出一個不存在的參數。模型並沒有在每次回答時搜尋一份權威 API 清單。

Training 是設定或調整參數的過程。預訓練讓模型從大量資料學習預測；後訓練再調整它遵循指令、使用工具或拒絕特定要求的方式。訓練和日常使用是不同階段。你在對話中指出錯誤，通常不會因此改變參數；若要讓模型在後續請求中繼續遵守，系統必須再次提供這條資訊，或透過外部記憶保存它。微調則是另一種訓練，會產生參數有所改變的模型版本，不等於在聊天中臨時教會模型某個 repo 的規則。

Inference 是拿已訓練模型處理新輸入並生成輸出的過程。你每次要求模型解釋錯誤、提議修改或產生程式碼，都在使用推論。訓練可能耗費大量時間和資源；推論則按請求反覆發生，費用、延遲及可用上限依模型與服務方案而變。

把模型參數和推論輸入分開看，能避免把不同解法混為一談。若模型不知道團隊的內部函式，先在請求中提供文件或型別定義，是改變 Context；微調則會調整 Parameters，必須準備資料、訓練流程和評估。前者通常適合單一專案的即時知識，後者適合反覆出現、需要模型行為一致的需求。兩者的資料風險和驗收方式也不同。不要把「它這次答對了」當成參數已經更新的證據。

Token 如何變成一段回答

模型讀寫文字時使用 Token。Token 可能對應常見片段、標點、空白或字的一部分，不是「一個字」的固定單位。不同語言、程式碼、罕見識別字、長數字和雜湊值會有不同切分方式。中文字數、檔案行數和 Token 數不能直接互換。圖片、音訊、檔案及請求格式也可能有自己的計量方式。

當你貼一段短錯誤訊息，再附上一張截圖、幾個檔案和工具定義時，帳單所計算的內容就不只是畫面上的文字。OpenAI 的 Token counting 文件指出，請求結構、工具 schema、圖片和檔案都會影響輸入計數。不同模型的處理細節也可能不同。需要準確計數時，使用該 Provider 對應的工具或實際 usage 欄位，不要用字元數除以某個常數當成正式數字。OpenAI Token counting 文件

Next-token prediction 描述生成文字時的一個核心步驟。模型根據目前收到的序列計算下一個 Token 的可能性，再依生成設定選出一個 Token，並把它接到序列尾端。接著模型再做一次計算，直到形成完整輸出或達到限制。它預測的是 Token 序列，不是把整段程式碼一次從資料庫取出來。

這種生成機制不等於「模型只能亂猜」。模型可以從訓練資料學到有效的語法和模式，也可以依目前輸入推導出有用的答案；但一段流暢輸出本身不能證明內容正確。要確認它是否改對程式，仍要看實際差異和驗證結果。

逐步生成也代表輸出時間和輸出長度相連。答案愈長，使用者通常等得愈久；實際速度會受模型、服務負載和產品設定影響。輸入和輸出的計價也可能不同，所以讓模型先輸出一大段分析，再要求它用兩句總結，不會把前面的生成成本消掉。應在任務開始時說明需要的交付物，例如「列出兩個風險，然後給最小補丁」，減少無用輸出。

Non-determinism 是相同或相近輸入有時會得到不同輸出的現象。抽樣設定可能直接引入隨機選擇；服務端版本、數值運算和模型路由等因素，也可能使重複請求不完全相同。調整溫度或使用偏確定性的設定，可能降低某些差異，卻不能保證跨版本、跨 Provider 或跨時間得到完全相同的結果。若任務需要穩定性，應用測試、型別檢查或明確驗收條件約束輸出，而不是依賴某一次生成剛好正確。

例如兩次請求都要新增欄位驗證，模型可能一次放在 API 邊界，另一次放在資料庫存取前。若需求沒有指定邊界，兩者都可能看起來合理。這時重試不會替你決定設計；先補上驗收條件，再用測試檢查每次生成。若需求和輸入完全沒變，但結果差異很大，才值得進一步記錄模型版本、effort、生成參數和 Provider 回應資訊，讓比較有依據。

Effort、Provider、Harness 的責任不同

Effort 是部分模型或產品提供的推理投入設定。它可能影響模型在回答前花多少運算或產生多少推理 Token，通常也會牽動速度、輸出預算或成本。它不是跨產品的統一標準：選項名稱、支援的模型、計量方式與實際效果都可能不同。提高 effort 不會自動補上缺失的程式碼或文件，也不保證結論正確。適合先在難度相近的任務上比較品質、延遲和 usage，再決定是否採用較高設定。

Model provider 是提供模型推論服務的一方。它接收 API 請求、選擇或執行模型、回傳結果，並定義計費、速率限制、資料處理和 API 欄位。模型開發者與服務 Provider 可以相同，也可以不同。標示相同家族名稱，不保證不同 Provider 的版本、上下文處理、工具格式、計價或生成結果一致。

Harness 是包在模型周圍、負責把模型接進實際工作的軟體。它可能讀取使用者訊息與專案指令，整理要交給模型的內容，宣告可用工具，檢查權限，執行工具，把結果放回下一個請求，並決定何時回覆使用者。檔案讀取、命令執行、對話保存和上下文管理，大多屬於 Harness 或其他服務，不是模型參數的內建能力。

常說的 Agent 可以理解為模型被 Harness 配上指令、工具與執行流程後，能持續處理任務的組合。這個詞在不同產品裡定義不一，不能只靠名稱判斷它有沒有自主權。判斷時要看它實際能呼叫什麼工具、是否需要逐次核准、可以連續執行多久，以及有哪些停止條件。

一次使用者要求可能包含多個 Provider request

Model provider request 是 Harness 和 Provider 之間的一次請求與回應。模型可以回傳文字，也可以回傳一個等待 Harness 執行的工具呼叫。假設你要求代理在新增 API 後執行測試，流程可能是：Harness 送出請求，模型要求讀取路由檔；Harness 回傳檔案內容後再送出請求；模型提出修改；Harness 寫入檔案並執行測試；測試輸出再送進後續請求，直到代理整理結果。這些來回合起來，才是你在介面看到的一次工作。

Input tokens 是某次請求送進模型的 Token，常包含系統或開發者指令、使用者訊息、相關歷史、工具定義、工具結果和多模態內容。不同 API 可能保留對話狀態或使用引用 ID，因此不應假設每個產品都由客戶端逐字重送完整歷史。但從帳單與模型實際可見內容來看，仍要查該次請求的 usage 和上下文組成。

Output tokens 是模型在該次請求產生的 Token，可能包括可見回答、工具呼叫內容，以及特定模型計量的推理 Token。使用者看不到的部分是否計費、如何回報，依 Provider 和模型而定。一次長工作可能有多次請求，每次請求又各自有輸入和輸出用量。因此，最後只寫了兩行程式碼，不能說明這次工作總共用了多少 Token。

排查成本時，先拆分輸入與輸出，再看請求次數和每次輸入大小。若輸入佔大宗，檢查工具 schema 是否過大、是否反覆放入不相關檔案、工具輸出是否冗長、歷史是否需要整理。若輸出偏高，檢查模型是否花很多 Token 推理、是否多次重試，或任務是否允許回答過長。先看用量紀錄，再改設定，通常比猜測「模型太貴」有效。

比較兩種模型或 Harness 時，要用同一項任務和相同的驗收標準，並記錄整個 Turn 的所有 Provider request。只比最終回答會漏掉失敗重試和工具呼叫；只比單次 request 又會漏掉一個工作所需的往返數。較有用的資料包括：各 request 的輸入、輸出和快取 Token，總延遲、工具執行結果，以及任務最後是否通過測試。這不是為了把每次開發都變成基準測試，而是當成本或品質出現爭議時，有辦法指出差異發生在哪裡。

Prefix cache 省的是重複處理，不是建立記憶

Prefix cache 是 Provider 對請求前綴重用運算的一種機制。如果連續請求的開頭部分一致，服務可能沿用先前已處理的前綴，減少重複計算。Cache tokens 則是用量回報中，Provider 標示為命中快取的輸入 Token。它仍是請求內容的一部分，不代表 Provider 已把對話永久記住，也不會代替 Session 或專案記憶。

快取通常依「前綴是否吻合」判斷，不是搜尋相似內容。假設多次請求都以相同的工具描述、指令和歷史開頭，後面只增加新工具結果，前面較穩定的部分可能重用。若 Harness 每次把時間戳插到最前面、重排工具定義，或改了早先訊息，匹配就可能縮短。實際快取區段、建立門檻、保留時間、讀寫價格和 API 欄位取決於 Provider、模型及版本。OpenAI 文件描述 cached_tokens 等欄位；Anthropic 文件則描述 cache_read_input_tokens、cache_creation_input_tokens 和不同 TTL。不要把一家的數字或規則套到另一家。OpenAI Prompt caching、Anthropic Prompt caching

若長對話成本突然升高，查看 usage 中的快取讀取量、快取建立量和一般輸入量，再比對請求的穩定前綴與間隔時間。若快取命中正常但費用仍高，問題可能是每次輸入太大，或輸出與請求數量高。快取能降低重複前綴的處理成本，不能消除上下文容量限制，也不能讓無關歷史變得有用。

快取也不等於把更多內容塞進提示的理由。加入長期不變但不相關的規則，雖然有機會形成較長的共用前綴，卻仍會增加首次寫入成本，並占用模型可用的上下文。先確保共用內容有助於任務，再觀察實際命中率與費用。除錯快取時，要確認請求內容、工具順序、模型設定和閒置時間都符合該 Provider 的條件；單看「字串一樣」未必足以證明請求前綴一致。

用分層方式定位故障

想像代理替付款流程加上重試。它產生不存在的設定欄位時，先確認實際模型版本和本次輸入有沒有型別定義及既有範例；這同時檢查 Model、Context 和 Harness 組出的內容。若回答正確但檔案沒有變，查看 Harness 是否提供寫檔工具、權限是否允許。若工具已跑完但代理沒有看懂錯誤，檢查工具結果是否送回後續請求，以及 Provider request 是否使用預期模型。若同一個要求兩次得到不同修改，先確認請求設定與模型版本，再讓測試和 diff 判斷哪個版本符合規格。

這種診斷方式把籠統的「AI 不好用」拆成可查證的問題：模型生成能力、送進去的 Token、Provider 的服務與計價、Harness 的工具流程，或最後的驗證不足。它們相互影響，但不是同一層。先找到出錯的層，才知道該補文件、改指令、調整工具、換模型或增加檢查。

本篇完整對應原 repo 課綱的 Section 1 — The Model。詞目來源見固定版本的 README 詞典。實際 Token 計數、effort 支援、快取條件與價格請以 OpenAI Token counting、OpenAI Prompt caching 和 Anthropic Prompt caching 的當前文件為準。