AI Coding 術語辭典
AI Coding 常常讓人覺得只有內行人才懂。一堆沒有解釋的術語。莫名其妙的失敗。帳單金額與實際工作量對不上。
其實沒那麼難。很多困惑都是人為製造的：有一整個靠風投支撐的生態圈，從讓這些東西難以理解中獲益。
AI Coding 的基本術語，一個下午就能學完。掌握了這些術語，整件事就不再像是猜謎遊戲。
為什麼脈絡（Context）會衰退？為什麼帳單這麼高？為什麼同一個提示詞，今天和昨天的行為不一樣？
每個問題都有清晰的答案，只要有人告訴你該用什麼詞。
這就是這本字典的用途。AI Coding 的詞彙，用清晰的語言翻譯給你。
想要的不只是詞彙？ 加入 62,000+ 位開發者，訂閱 aihero.dev/newsletter，獲取我最新的技能、AI 工程思考，以及讓你保持領先的資源。
目錄
Section 1 — 模型
Section 2 — 工作階段、上下文視窗與對話輪次
Section 3 — 工具與環境
Section 4 — 失敗模式
Section 5 — 交接
Section 6 — 記憶與引導
Section 7 — 工作模式
Section 1 — 模型
Model
即參數（Parameters）本身。無狀態（Stateless）——執行下一個詞元預測，僅此而已。「Claude Opus 4.7」和「GPT-5」都是模型。模型本身無法做任何代理人該做的事；它必須被駕馭化（Harnessed）。
情境例句：
「規劃步驟要不要把模型從 Sonnet 換成 Opus？」
"Should we switch the model from Sonnet to Opus for the planning step?"
「試試看吧——但這個任務大部分工作是駕馭在做。如果系統提示詞和工具設定不對，換模型也沒用。」
"Try it — but the harness is doing most of the lifting on this task. The model swap won't help if the system prompt and tools are wrong."
Parameters
模型內部的數字——通常有數十億個——在訓練過程中調整而成。模型「知道」的一切都存在於其中。訓練設定它們；推論時保持不變地使用它們。又稱權重（weights）。
情境例句：
「我們可以在我們的程式碼庫上對它進行微調嗎？」
"Can we fine-tune it on our codebase?"
「那會更新參數——之後就是一個不同的模型了。對單一專案而言，把程式碼庫作為脈絡載入幾乎永遠比重新訓練便宜。」
"That'd update the parameters — different model afterwards. For one project it's almost always cheaper to load the codebase as context than to retrain."
Training
設定模型參數（Parameters）的過程——將模型暴露於大量文字，並調整參數以改善下一個詞元預測的準確性。由模型供應商（Model Provider）執行的一次性、高成本過程。涵蓋預訓練（pre-training，主要的大規模執行）和後訓練（post-training，後續的精煉，如指令遵循和安全性校準）；在本詞彙表的層次，這個區別並不重要。
情境例句：
「我們能讓它學習我們的內部 API 嗎？」
"Can we get it to know our internal API?"
「不能透過訓練——那是模型供應商執行的、耗時數月的過程。改為把 API 文件載入脈絡，那才是你實際能用的槓桿。」
"Not via training — that's a months-long process by the model provider. Load the API docs into context instead, that's the lever you actually have."
Inference
執行已訓練好的模型以產生輸出——每次模型供應商請求（Model Provider Request）都在做這件事。參數（Parameters）維持不變；模型只是對給定的脈絡進行下一個詞元預測。相較於訓練成本低廉，但按詞元計費，是使用模型的主要費用來源。
情境例句：
「為什麼帳單會隨使用量計費，而不是固定授權費？」
"Why does the bill scale with usage instead of being a flat license?"
「你在為推論（Inference）付費——每次模型供應商請求都在供應商的硬體上執行模型。訓練早已完成，但推論費用按請求累計，而且一個對話輪次在呼叫工具時可能擴展成許多次請求。」
"You're paying for inference — every model provider request runs the model on the provider's hardware. Training already happened, but inference costs accrue per request, and a single turn can expand into many requests when tools are called."
Token
模型讀取和寫入的原子單位。大致上與一個單字差不多，但並不完全一致——常見詞彙通常是一個詞元，罕見或較長的詞彙則會拆分成多個。上下文視窗的大小、費用和延遲，全部以詞元（Token）為單位計算。
避免使用：「字詞」——詞元邊界與字詞邊界並不吻合，而每秒詞元數 / 每美元詞元數才是真正重要的計量單位。
情境例句：
「這個提示詞會有多大？」
"How big is this prompt going to be?"
「用 tokenizer 跑一下——Schema 本身很緊湊，但 JSON 的鍵名很怪，所以會拆分成比你預期更多的詞元。」
"Run it through the tokenizer — the schema's compact but the JSON keys are weird, so they'll split into more tokens than you think."
Next-token prediction
模型實際上做的事。給定一個脈絡，它抽樣出下一個詞元，將其附加上去，然後再執行一遍。所有輸出——一個句子、一個工具呼叫、一個上千行的檔案——都是逐個詞元建構起來的。模型沒有其他運作模式。
情境例句：
「代理人是怎麼『決定』要呼叫一個工具的？」
"How does the agent 'decide' to call a tool?"
「它不是『決定』——一路到底都是下一個詞元預測（Next-Token Prediction）。工具呼叫不過是駕馭從輸出串流中解析出來的一個結構化字串。」
"It doesn't — it's next-token prediction all the way down. The tool call is just a structured string the harness parses out of the output stream."
Non-determinism
同樣的輸入可能產生不同的輸出。用完全相同的脈絡跑同一個模型兩次，你可能會得到兩個不同答案——有時只差一個字，有時是完全不同的做法。你的程式碼不需要有任何改變，這件事也可能發生。
這是模型產生文字的方式，以及模型供應商如何處理請求的特性。沒有哪個設定可以一鍵把它消掉。
你應該預期代理在同一個任務上會產生一段結果分布。有些日子模型看起來很敏銳；有些日子它像是完全抓不到重點。同一個任務，不同次擲骰。
小心不要過度替這件事編故事。人類是會尋找模式的機器，一連串糟糕的執行結果，很容易讓人覺得「模型這週是不是變差了」。通常，那只是分布而已。
情境例句：
「Claude 今天爛透了。他們是不是發了一個更差的版本？」
"Claude has been awful today. Did they ship a worse version?"
「大概不是——模型輸出是非決定性的。同一個任務本來就會有好日子和壞日子。先明天再試一次，再開始找原因。」
"Probably not — model output is non-deterministic. You're going to have good days and bad days on the same task. Try again tomorrow before you go looking for a cause."
Model provider
為模型提供推論（Inference）服務的機構。通常是遠端服務（Anthropic、OpenAI、Google），但也可以是本地部署——在自己機器上執行的 Ollama、LM Studio、llama.cpp。駕馭自身不執行模型；它向供應商發出請求。
情境例句：
「我們能為這個隔離網路的客戶離線執行嗎？」
"Can we run this offline for the air-gapped client?"
「將模型供應商切換為本地供應商——在他們的機器上跑 Ollama 或 llama.cpp。駕馭不在乎，只是換了一個端點。」
"Swap the model provider to a local one — Ollama or llama.cpp on their box. The harness doesn't care, it just hits a different endpoint."
Harness
圍繞模型、將其轉化為代理人的一切：工具、系統提示詞、上下文視窗管理、權限設定、hooks。Claude.ai 和 Claude Code 執行的是同一個模型，行為卻大相徑庭，原因正是它們的駕馭不同。
情境例句：
「同樣的模型，為什麼 Claude Code 會修改檔案，而 Claude.ai 只是回答問題？」
"Same model, why is Claude Code editing files and Claude.ai just answering questions?"
「駕馭不同——Claude Code 有檔案系統工具、不同的系統提示詞和權限層。模型不是變數所在。」
"Different harnesses — Claude Code has filesystem tools, a different system prompt, and a permission layer. The model isn't the variable here."
Model provider request
從駕馭到模型供應商的一次往返。駕馭發送當前脈絡；供應商回傳一個回應（一個工具呼叫或最終答案）。如果代理人呼叫工具，一條使用者訊息可能觸發許多次模型供應商請求——每個工具結果都會觸發另一次請求。
情境例句：
「一個問題燒了四萬個詞元？」
"One question burned forty thousand tokens?"
「看看工具呼叫——十二次 grep、八次讀取、四次編輯。每個工具結果都會觸發另一次模型供應商請求，而整個工作階段的前綴每次都要重新發送。」
"Look at the tool calls — twelve grep, eight read, four edits. Each tool result spawns another model provider request, and the whole session prefix re-sends every time."
Input tokens
駕馭（Harness）在每次模型供應商請求時發送的詞元。計費費率低於輸出詞元（Output Tokens）。
情境例句：
「帳單很高，但代理人寫出的內容很少。」
"Bill's high but the agent's barely writing anything."
「是輸入詞元（Input Tokens）的問題——每個對話輪次都重新發送整個工作階段的歷史。沒有前綴快取（Prefix Cache）的話，每次請求都要重新為歷史記錄付費。」
"It's the input tokens — every turn re-sends the whole session. Without the prefix cache you re-pay for the history each request."
Output tokens
模型產生回傳的詞元。計費費率高於輸入詞元，因為產生輸出需要更多運算。
情境例句：
「這次重構工作階段燒信用額度燒得很兇，明明輸入很小。」
"The refactor session is burning through credit even though the inputs are small."
「代理人在整檔重寫，而不是局部修補。輸出詞元（Output Tokens）的費率大約是輸入費率的五倍——讓它只輸出差異（edits），帳單就會降下來。」
"Agent's rewriting whole files instead of patching. Output tokens cost roughly five times the input rate — get it emitting edits and the bill drops."
Prefix cache
供應商端的快取儲存區，讓連續的模型供應商請求能夠跳過重新處理共享前綴的步驟。當一個請求的開頭與近期某個請求的開頭吻合——相同的系統提示詞、相同的歷史記錄到某個時間點——供應商就重複使用先前的運算結果，並以快取詞元（Cache Tokens）的折扣費率計費。
任何改變前綴的操作（重新排列檔案順序、在工作階段中途改寫系統提示詞、在頂部注入時間戳記）都會從該點起使快取失效，之後的請求以全額輸入詞元費率計費。
情境例句：
「為什麼帳單在工作階段中途突然飆高？」
"Why did the bill spike halfway through the session?"
「駕馭開始在每個對話輪次把當前時間注入系統提示詞。前綴快取在第一個改變的詞元處就失效了，所以此後每次請求都以全額費率計費。」
"Harness started injecting the current time into the system prompt every turn. Prefix cache breaks at the first changed token, so every request after that billed at full rate."
Cache tokens
供應商（Model Provider）從先前的模型供應商請求（Model Provider Request）快取下來的輸入詞元（Input Tokens），不必重新處理。當連續的請求共享同一個前綴時，供應商透過其前綴快取（Prefix Cache）重複使用先前的運算結果，並以大幅折扣的費率計費快取部分。這是讓長工作階段在成本上可行的關鍵機制——沒有它，每個對話輪次都要重新支付整段歷史的費用。
情境例句：
「長工作階段的費用很驚人——一次重構花了八美元。」
"Cost on long sessions is brutal — eight bucks for a refactor."
「看看快取詞元（Cache Tokens）。如果駕馭在輪次之間重新排列系統提示詞或檔案，前綴就會失效，每次請求都要以全額輸入詞元費率重新計費。」
"Check the cache tokens. If the harness is reordering the system prompt or files between turns, the prefix breaks and you re-pay full input rate every request."
Section 2 — 工作階段、上下文視窗與對話輪次
Stateless
不攜帶任何資訊向前傳遞。模型在模型供應商請求（Model Provider Requests）之間是無狀態的——每次請求重新發送完整的上下文視窗，因為模型無法看到其他任何東西。代理人預設在工作階段之間是無狀態的：新工作階段從空白開始，沒有任何先前工作階段的痕跡。與有狀態（Stateful）相對。
情境例句：
「為什麼每次我清除之後它就忘記了那個慣例？」
"Why does it forget the convention every time I clear?"
「模型是無狀態的——新工作階段從空白開始。如果你想保留它，就把它寫入 AGENTS.md 或一個駕馭在工作階段開始時會載入的記憶檔案。」
"The model's stateless — the new session starts empty. If you want it carried, write it to AGENTS.md or a memory file the harness loads at session start."
Context
代理人目前可以存取的相關資訊。這是一個抽象名詞——不是模型看到的原始輸入（那是上下文視窗），也不是持續累積的對話歷史（那是工作階段），而是代理人當下對任務而言切實可用的知識。「將某樣東西載入脈絡」意味著把它納入這個集合；「脈絡工程」（Context Engineering）是策劃和管理這個集合的學問。
情境例句：
「它不斷捏造型別裡根本不存在的欄位。」
"It keeps inventing fields that aren't in the type."
「型別檔沒有進脈絡——它在讀呼叫端然後猜。先把定義讀進來。」
"The type file isn't in context — it's reading the call sites and guessing. Read the definition in first."
Context window
模型在每次模型供應商請求（Model Provider Request）中所能看到的全部內容。容量有限、因模型而異，且是模型感知任何事物的唯一介面。
避免使用：「記憶體」——上下文視窗是工作狀態，不會跨工作階段持久保存。記憶體（Memory）是一個獨立概念，架構在其上層。
情境例句：
「我可以把整個 monorepo 貼到提示詞裡嗎？」
"Can I just paste the whole monorepo into the prompt?"
「上下文視窗有 20 萬個詞元——大概只是整個代碼庫的五分之一。選取任務會觸及的檔案，把其餘的留在工具呼叫後面按需載入。」
"The context window's 200k tokens — that's maybe a fifth of the repo. Pick the files the task touches, leave the rest behind a tool call."
Stateful
攜帶資訊向前傳遞。一個工作階段在對話輪次之間是有狀態的——脈絡在工作階段執行期間持續累積，這正是為何長工作階段會漂入混沌區。代理人可以透過加入記憶系統（Memory System）跨工作階段保有狀態——將資訊持久化到環境，並在未來工作階段開始時重新載入。模型永遠不是有狀態的；任何表面上的連續性都是駕馭重新輸入脈絡的結果。與無狀態（Stateless）相對。
情境例句：
「它記得我昨天的偏好設定——這表示模型學到了嗎？」
"It remembered my preferences from yesterday — does that mean the model learned them?"
「沒有，代理人是有狀態的，因為駕馭把設定寫進了記憶檔案並在工作階段開始時重新載入。模型本身對昨天的事一無所知。」
"No, the agent's stateful because the harness wrote them to a memory file and reloaded them at session start. The model itself saw nothing of yesterday."
Agent
一個配備了工具（Tools）、系統提示詞（System Prompt）和上下文視窗（Context Window）的模型（Model），透過對話輪次與使用者互動。Claude Code 是代理人。Cursor 是代理人。Claude.ai 是代理人。 代理人是你實際與之對話的存在——是運作中的模型，針對特定目的進行配置。
避免使用：「AI」、「機器人」（too vague — 這些說法過於模糊，無法區分你指的是模型參數本身，還是經過駕馭化的整體系統）。
情境例句：
「你用哪個代理人來跑這次的遷移作業？」
"Which agent are you using for the migration?"
「本地用 Claude Code，UI 部分用 Cursor——底層是同一個模型，駕馭不同。」
"Claude Code locally, Cursor for the UI work — same model underneath, different harnesses."
System prompt
駕馭在每次模型供應商請求前都會加入的指令——代理人的常駐任務說明書：它是誰、如何行事、可以呼叫哪些工具、應遵循哪些慣例。通常在整個工作階段期間保持穩定。
情境例句：
「兩個駕馭、同一個模型，同樣的提示詞行為卻截然不同。」
"Two harnesses, same model, totally different behavior on the same prompt."
「系統提示詞不同。一個調整為精簡的程式碼編輯，另一個調整為解釋說明——差異就在那裡，在你的訊息到達之前就已決定了。」
"Different system prompts. One's tuned for terse code edits, the other for explaining — that's where the divergence lives, before your message even arrives."
Session
與代理人進行的單次有界互動。從空白開始，逐漸累積訊息、工具結果和讀取的檔案，並在清除、關閉或壓縮摘要成新工作階段時結束。工作階段是填充上下文視窗的東西：如果上下文視窗是個盒子，工作階段就是慢慢將它填滿的內容。超出單個上下文視窗容量的工作，必須拆分到多個工作階段中進行。
情境例句：
「一個工作階段能跑多久才不至於崩潰？」
"How long can one session run before it falls apart?"
「取決於工作的性質——一次專注的重構保持清晰的時間比開放式研究長得多。一旦工作階段過於龐大，就交接或壓縮摘要，不要硬撐。」
"Depends on the work — a focused refactor stays sharp longer than open-ended research. Once the session bloats, hand off or compact, don't push through."
Turn
一條使用者訊息，加上代理人在回應中所做的一切，直到它將控制權還給使用者為止。包含一次或多次模型供應商請求——如果代理人呼叫工具，則可能包含許多次。一個澄清問題結束這個輪次；你的回覆開始下一個。層級關係是工作階段 > 對話輪次（Turn）> 模型供應商請求。
情境例句：
「一個輪次花了兩分鐘？」
"One turn took two minutes?"
「它在那個輪次裡發出了十四次工具呼叫——每次都是一個獨立的模型供應商請求。延遲不斷疊加，直到代理人最終把控制權還給你。」
"It made fourteen tool calls inside that turn — each one is a separate model provider request. Latency stacks up before the agent finally yields back to you."
Section 3 — 工具與環境
Environment
代理人所作用的世界——駕馭之外任何代理人透過工具結果感知、透過工具呼叫改變的一切。駕馭執行代理人；環境是代理人工作的場所。像 AGENTS.md 這樣的檔案存在於環境中；駕馭負責將它載入上下文視窗。檔案系統（Filesystem）是最常見的環境類型，但並非唯一（資料庫、遠端 API、瀏覽器工作階段都可以是環境）。
避免使用：「環境」來指稱執行時期或駕馭本身——駕馭是外殼，環境是工作空間。
情境例句：
「代理人看不到 staging 資料庫的 Schema。」
"The agent can't see the staging DB schema."
「把它接入環境——給它一個只對 staging 具唯讀權限的
psql工具。駕馭沒問題，只是它沒有任何東西可以作用。」"Wire it into the environment — give it a
psqltool scoped to read-only on staging. The harness is fine, it just has nothing to act on."
Filesystem
代理人讀取、寫入、並在其中執行程式的檔案與目錄樹——coding agent 預設的環境類型。AGENTS.md、技能（Skills）、原始碼、建置腳本和工具配置，全都存放在檔案系統中。當一個駕馭「從你的專案啟動」時，它就是在將代理人指向一個檔案系統。
情境例句：
「它為什麼沒有讀到我的 AGENTS.md？」
"Why isn't it picking up my AGENTS.md?"
「它跑的是另一個檔案系統——沙盒掛載了上層目錄，而不是專案根目錄。重新指定駕馭的路徑。」
"It's running against a different filesystem — the sandbox mounted the parent dir, not the project root. Repoint the harness."
Tool
駕馭暴露給代理人可以呼叫的函式——Read（讀取）、Write（寫入）、Bash（執行指令）、Search（搜尋）。工具是代理人感知並作用於環境的方式：代理人除了透過工具結果之外無法感知環境，除了透過工具呼叫之外無法改變環境。每次工具呼叫都需要額外一次模型供應商請求，因為結果必須返回給模型，模型才能決定下一步。
情境例句：
「代理人可以直接查詢 staging 資料庫嗎？」
"Can the agent query staging directly?"
「在駕馭裡加一個
psql工具，限定只對 staging 具唯讀權限。沒有對應工具的話，代理人對檔案系統之外的一切都是盲的。」"Add a
psqltool to the harness, scoped read-only on staging. Without a tool for it, the agent's blind to anything outside the filesystem."
Tool call
模型輸出的、指定某個工具及其參數的內容——這不過是結構化文字。它本身不做任何事；駕馭必須讀取它並執行。由模型在一次模型供應商請求中產生。
情境例句：
「它說它跑了測試，但檔案的時間戳記沒有變。」
"It said it ran the tests but the file timestamps haven't changed."
「看一下對話紀錄——它是真的發出了工具呼叫，還是只是描述跑了測試？模型產生呼叫指令，但如果駕馭沒有執行它，什麼都沒發生。」
"Look at the transcript — did it actually emit a tool call, or just describe running them? The model produces the call, but if the harness didn't execute it, nothing happened."
Tool result
駕馭執行工具呼叫後回傳的內容——檔案內容、指令輸出、錯誤訊息。這是代理人感知環境的唯一窗口。在下一次模型供應商請求中傳回模型，模型才能決定如何處理它。工具呼叫和工具結果是同一次交換的兩端，都發生在同一個對話輪次之內。
情境例句：
「它在推論這個檔案的內容時，好像把它當成空的。」
"It's reasoning about the file like it's empty."
「工具結果回傳的是權限拒絕，不是檔案內容。模型只看到了錯誤字串——它沒有任何其他窗口可以看見這個檔案。」
"The tool result came back as a permission denial, not the contents. The model only saw the error string — it has no other window onto the file."
MCP
模型脈絡協定（Model Context Protocol）。 一種把外部工具伺服器接入駕馭的協定——讓代理人取得駕馭本身沒有內建的工具。代理人從來不會「呼叫 MCP」；它呼叫的是工具，只是駕馭剛好是從 MCP 伺服器取得那個工具。MCP 也會暴露資源（唯讀資料）與提示詞（可重用範本），但提供工具是主要用途。
情境例句：
「代理人需要從 Linear 讀取 ticket。」
"The agent needs to read tickets from Linear."
「設定駕馭使用 Linear MCP 伺服器——它會把 Linear API 暴露成代理人可呼叫的工具。這樣就不用自己寫工具包裝器。」
"Configure the harness to use the Linear MCP server — it exposes the Linear API as tools the agent can call. Saves you writing custom tool wrappers."
Permission request
駕馭在執行未預先核准的工具呼叫前，向使用者展示的提示。模型產生工具呼叫；駕馭不立即執行，而是暫停並詢問使用者。核准則執行；拒絕則駕馭將拒絕結果作為工具結果回報給模型。這是駕馭讓人類加入迴圈以監督風險或敏感操作的機制。
情境例句：
「它被一個權限請求卡住十分鐘了——我開會去了。」
"It's been blocked on a permission request for ten minutes — I was in a meeting."
「這就是人在迴圈的代價。預先核准安全的工具，讓請求只在真正有風險的操作上觸發。」
"That's the cost of human-in-the-loop. Pre-approve the safe tools so the request only fires on the actually-risky calls."
Permission mode
代理人模式（Agent Mode）中負責權限把關的切片——哪些工具呼叫會觸發權限請求（Permission Request），哪些會自動執行。這是模式系統的原始用途，後來駕馭才開始在其上捆綁行為指令。
情境例句：
「它每次 grep 都暫停——AFK 執行完全被卡死了。」
"It paused on every grep — totally killed the AFK run."
「放寬唯讀工具的權限模式，保留對寫入和 shell 操作的提示。研究型工作階段裡大多數的權限請求都是雜訊。」
"Loosen the permission mode for read-only tools, keep prompting on writes and shell. Most permission requests on a research session are noise."
Agent mode
一種在執行時期形塑代理人（Agent）運作方式的預設組合——將權限模式（Permission Mode）與注入系統提示詞（System Prompt）的行為指令捆綁在一起。常見範例：預設模式（針對風險操作請求確認）、計劃模式（plan mode，封鎖編輯並引導代理人進行研究）、自動接受編輯模式（accept-edits，自動核准編輯）、繞過權限模式（bypass permissions，俗稱 YOLO 模式，自動核准一切）。可在工作階段進行中切換。
廠商術語： Claude Code 將這些稱為「permission modes」（權限模式），Codex 稱為「approval modes」（核准模式）——兩者均早於行為捆綁概念的出現。
情境例句：
「它一直修改檔案，但我只想要一份計劃。」
"It keeps editing files when I just want a plan."
「切換到計劃模式——它會封鎖寫入，並保持在研究階段。」
"Switch to plan mode — it'll block writes and stay in research."
「那之後的 AFK 執行呢？」
"What about for the AFK run later?"
「繞過模式，但只在沙盒（Sandbox）裡用。」
"Bypass mode, but only inside the sandbox."
Sandbox
代理人在其中執行的隔離環境——一個容器、虛擬機、臨時檔案系統或受限權限的 shell。限制代理人操作的影響範圍：即使代理人執行了破壞性指令或下載了惡意內容，損害也被控制在沙盒之內。這是讓 AFK 工作模式在實務上可行的安全基礎。
情境例句：
「我想讓它在繞過權限模式下跑一夜，但又擔心風險。」
"I want to let it run bypass-permissions overnight but I'm not ready for that."
「把它放進沙盒（Sandbox）——全新容器、不掛載任何憑證、不開外網。最壞的情況是它毀掉自己的檔案系統，然後你丟棄那個容器就好了。」
"Put it in a sandbox — fresh container, no credentials mounted, no network out. Worst case it nukes its own filesystem and you discard the container."
Section 4 — 失敗模式
Sycophancy
充滿自信地附和你的模型輸出。成因來自訓練：模型被塑造成偏好人類喜歡的答案，而人類通常比起被告知自己錯了，更喜歡聽到對方同意自己。因此模型學會了「同意會得到獎勵」——即使這個同意是錯的。
常見表現：
- 被質疑就讓步——當你說「你確定嗎？」時，它會推翻原本正確的答案。
- 稱讚糟糕的輸入——還沒分析，就先同意你破綻百出的計畫很棒。
- 帶偏見的框架——當你暗示是你寫的，審查就偏正面；當你暗示是別人寫的，審查就偏負面。同一個成品，不同的判決。
- 模仿——把你的錯誤重複回給你，當作確認。
診斷測試：如果沒有你的引導，模型還會這樣說嗎？如果唯一改變的是你的語氣或框架，那就是諂媚，不是真的分析改變。
修復方式：隱藏你的偏好。用中性方式下提示詞——說「審查這段程式碼」，不要說「這段程式碼好嗎？」。
避免使用：把「諂媚」用在任何剛好討你喜歡的錯誤答案上。沒有診斷測試，這個詞就和「錯了」一樣沒有價值。
情境例句：
「它說我的重構計畫看起來很棒，然後我問『你確定嗎？』，它就把整個計畫收回去了。」
"It said my refactor plan looked great, then I asked 'are you sure?' and it walked the whole thing back."
「典型的諂媚——它一開始同意，是因為你聽起來很有把握；後來退縮，是因為你聽起來在懷疑。計畫品質沒有變，變的是你的語氣。清除後，用不暗示任何立場的方式重新提問。」
"Classic sycophancy — it agreed first because you sounded confident, then caved because you sounded doubtful. The plan's quality didn't change, your tone did. Clear and re-ask without signalling either way."
Hallucination
充滿自信卻又錯誤的模型輸出。分為兩種類型，各有不同的成因與修復方式：
- 事實性幻覺（Factuality Hallucination）——捏造或錯誤的世界知識（一個不存在的函式、錯誤的 API 簽名、虛假的引用來源）。成因是參數化知識的缺口，常發生在知識截止日期之後的內容。修復方式：載入正確的情境知識。
- 忠實性幻覺（Faithfulness Hallucination）——輸出偏離了已載入的情境知識、使用者的指令，或模型自身先前的推理。這是注意力衰退（Attention Degradation）的症狀，在混沌區會更嚴重。修復方式：清除或壓縮摘要。
避免使用：「幻覺」作為「錯誤」的代名詞——不指明是哪種類型，這個詞就沒有任何診斷價值。
情境例句：
「它幻覺出了 Schema 上一個
parseAsync方法。」"It hallucinated a
parseAsyncmethod on the schema."
「是事實性還是忠實性幻覺？」
"Factuality or faithfulness?"
「那個方法在我貼的文件裡有——它只是在第四十個對話輪次後停止讀那份文件了。」
"The method exists in the docs I pasted — it just stopped reading them after turn forty."
「那就是忠實性幻覺。壓縮摘要並重新載入，不用再加更多文件了。」
"Faithfulness then. Compact and reload, don't bother adding more docs."
Parametric knowledge
模型從訓練中「學到」的知識，儲存在其參數中。在訓練時凍結——模型既看不到自己的參數，也無法更新它們。資訊在壓縮時會流失：數十億個事實被塞進固定數量的參數，稀少的細節因此變得模糊。是流暢處理常見主題的來源，也是在不常見主題上產生捏造的根源。與情境知識（Contextual Knowledge）相對。
情境例句：
「它寫的 React 無懈可擊，但對我們內部 SDK 的方法卻亂說一通。」
"It writes flawless React but invents methods on our internal SDK."
「React 在參數化知識（Parametric Knowledge）裡密度很高——有數百萬個訓練範例。你們的 SDK 沒有，所以模型填入看起來合理的形狀。把 SDK 文件載入脈絡裡。」
"React is dense in the parametric knowledge — millions of training examples. Your SDK isn't, so the model fills in plausible-looking shapes. Load the SDK docs into context."
Knowledge cutoff
模型不具備參數化知識（Parametric Knowledge）的日期。截止日期之後的函式庫、API 和事件，除非以情境知識的形式載入文件，否則都是捏造的溫床。每次模型發布都有各自的截止日期。
情境例句：
「它一直寫 v3 SDK 的語法——我們用的是 v5。」
"It keeps writing the v3 SDK syntax — we're on v5."
「v5 是在知識截止日期之後才發布的。把 v5 的 changelog 作為情境知識載入，否則它會繼續根據舊的參數化版本捏造語法。」
"v5 shipped after the knowledge cutoff. Load the v5 changelog as contextual knowledge, otherwise it'll keep fabricating from the older parametric version."
Contextual knowledge
代理人可以直接從當前脈絡中讀取的事實——使用者的任務指令、代理人已讀入的檔案、工具結果（Tool Results）、在工作階段開始時載入的 AGENTS.md 內容。與參數化知識（Parametric Knowledge）相對：參數化知識是從參數中召喚出來的；情境知識是從視窗中直接讀取的。當代理人從情境知識出發時，幻覺（Hallucination）發生的機率大幅降低——答案就在眼前，無需從模糊的記憶中挖掘。
只有在與參數化知識對比時才使用此術語；其他情況直接說脈絡即可。
避免使用：「工作記憶體」——情境知識是當下在視窗裡的內容；記憶系統（Memory System）則是將跨工作階段的內容帶入其中的機制。兩者的尺度不同，不能混淆。
情境例句：
「為什麼我貼了 API 文件它就能對，不貼就亂說？」
"Why does it nail the API when I paste the docs and fabricate it when I don't?"
「貼了文件後，它讀的是情境知識——像在翻書查答案。沒貼的時候依賴的是參數化知識，那些少見的端點就會模糊。」
"With the docs in, it's contextual knowledge — reading off the page. Without, it's parametric and the rare endpoints blur."
Attention relationship
在預測每個詞元時，模型會將脈絡中所有其他詞元都納入考量——有些影響深遠，有些幾乎微不足道。兩個詞元之間的配對關係即為注意力關係（Attention Relationship），有意義的配對（例如「她」與「Sarah」，或一個 getUser() 呼叫與其 function getUser 定義）彼此的影響遠大於無關聯的配對。一個包含 N 個詞元的脈絡，大約有 N² 個注意力關係。
情境例句：
「它一直在 diff 裡搞混那兩個
user符號——聽起來像是進了混沌區。」"It keeps confusing the two
usersymbols across the diff — sounds like we're in the dumb zone."
「對，每個呼叫端與其宣告之間的注意力關係互相干擾——相同的詞元形狀，但綁定的對象不同。把其中一個改名，配對關係就會變得清晰。」
"Yeah, the attention relationship between each call site and its declaration is fighting the other one — same token shape, different bindings. Rename one and the pairings sharpen."
Attention budget
每個詞元（Token）能分配給其餘脈絡（Context）的影響力是有限的。對某個關係（Attention Relationship）施加大量影響，留給其他關係的就越少。這個預算是每個詞元固定的，不會隨脈絡擴大而增長，這正是為何工作階段越長，效果越稀薄。
情境例句：
「它為什麼一直忽略我貼在最上面的 Schema？」
"Why does it keep ignoring the schema I pasted at the top?"
「我們已深入混沌區了——每個詞元的注意力預算是固定的，但脈絡不斷增長。Schema 的訊號現在必須跟幾千個新詞元競爭。」
"We're well into the dumb zone — every token's attention budget is fixed, but the context kept growing. The signal on the schema is now competing with thousands of newer tokens."
Attention degradation
隨著工作階段不斷增長，每個詞元的注意力預算（Attention Budget）必須分配給更多的競爭者。任何一個有意義關係（Attention Relationship）上的訊號都會減弱；不相關的脈絡雜訊大量湧入。同樣的模型、同樣的參數——只是要從同一個盤子上餵食的嘴巴多了。這是清晰區與混沌區效應的根本成因。
情境例句：
「它深陷混沌區了——憑空捏造出型別檔裡根本不存在的泛型。」
"It's deep in the dumb zone — inventing generics that aren't in the type file."
「注意力衰退（Attention Degradation）。型別定義仍在脈絡中，但它的訊號被我們後來加入的所有內容淹沒了。清除並重新載入。」
"Attention degradation. The type definitions are still in context, but the signal on them is buried under everything we've added since. Clear and reload."
Smart zone
工作階段剛開始時，代理人處於「清晰區」（Smart Zone）——思維敏銳、專注、召回能力良好。隨著工作階段增長，它逐漸漂入「混沌區」（Dumb Zone）：更粗心、更健忘、更多錯誤——且更多忠實性幻覺。同樣的模型、同樣的駕馭——只是脈絡變多了。這是注意力衰退的直觀感受。在前沿模型上，混沌區通常約在 100,000 個詞元附近開始——雖然這點仍有爭議。工作階段膨脹時應清除或壓縮摘要，不要硬撐。
情境例句：
「前三個元件做得完美，第四個直接毀了。」
"It nailed the first three components and just butchered the fourth."
「你已出了清晰區——同樣的模型，只是深入混沌區了。壓縮摘要並重新載入計劃，下一個元件就會順利。」
"You're out of the smart zone — same model, just deep into the dumb zone now. Compact and reload the plan, the next component will land."
Section 5 — 交接
Clearing
結束當前工作階段並啟動一個全新的工作階段。下一則訊息從空白的工作階段和空白的上下文視窗重新開始。通常由使用者主動觸發。
情境例句：
「它陷入迴圈，一直在那個失敗的測試上打轉。」
"It's stuck looping on the failing test."
「直接清除——帶著計劃文件和測試檔案重開一個新工作階段。繼續跟既有的脈絡纏鬥毫無意義。」
"Just clear it — start a fresh session with the plan doc and the test file. No point fighting the existing context."
Handoff
將代理人的脈絡從一個工作階段轉移到另一個，且沒有返回路徑。傳遞方式各異——可以是書面的交接文件（Handoff Artifact）、記憶體內的摘要（壓縮摘要），或其他方式。與清除（Clearing）不同——清除不進行任何轉移。進行交接的原因多樣：切換角色（規劃者→實作者）、啟動 AFK 執行、分散到並行工作階段，或釋放上下文視窗空間。
情境例句：
「規劃工作階段越來越沉重——我應該繼續撐下去嗎？」
"Planning session is getting heavy — should I just keep going?"
「做一次交接。把決策寫進文件，清除工作階段，然後在新的工作階段中讀取那份文件來開始實作。」
"Do a handoff. Write the decisions to a doc, clear, start the implementation in a fresh session reading from it."
Handoff artifact
一份作為交接（Handoff）傳遞機制的文件——由一個工作階段撰寫，供另一個工作階段讀取。這是多種傳遞方式之一（另見壓縮摘要，Compaction）。
情境例句：
「如何在規劃代理人和實作代理人之間分工？」
"How do I split this between the planning agent and the implementing one?"
「讓規劃者寫一份交接文件——記錄檔案路徑、決策和約束條件。實作者的工作階段從指向該文件的指針開始，以它作為任務簡報。」
"Have the planner write a handoff artifact — file paths, decisions, constraints. The implementer's session opens with a pointer to the artifact and works from it as its brief."
Spec
一份描述跨多個工作階段工作的交接文件（Handoff Artifact）——記錄正在構建的是什麼，而非每個工作階段如何完成各自的份額。隨著工作進展而演進。由任務單（Tickets）組成。
情境例句：
「這些應該全放在一個工作階段裡嗎？」
"Should this all be one session?"
「不，把它整理成規格書——拆分成任務單，每張任務單用獨立的工作階段跑。試圖在單一脈絡裡完成整件事，還沒跑到一半就會碰到混沌區。」
"No, write it up as a spec — break it into tickets, run each one in its own session. Trying to do the whole thing in a single context will hit the dumb zone before you're halfway."
Ticket
一份劃定單一工作階段工作範圍的交接文件（Handoff Artifact）。可以獨立存在，也可以作為規格書（Spec）的子項之一。任務單可以阻塞或被同層任務單阻塞，因此工作順序從它們的相依關係圖中自然浮現，而非依賴線性計劃。
情境例句：
「這次遷移的規格書要從哪裡開始？」
"Where do I start on the migration spec?"
「看任務單圖——Schema 變更阻塞回填，回填阻塞 API 切換。挑一個沒有前置依賴的葉節點，然後跑一個工作階段處理它。」
"Look at the ticket graph — the schema change blocks the backfill, the backfill blocks the API switch. Pick a leaf and run a session on it."
Compaction
一種在記憶體中進行的交接（Handoff）：將前一個工作階段的歷史記錄摘要化，作為新工作階段的起點。有損耗——以細節換取空間餘裕。可由使用者手動觸發，也可自動觸發。
情境例句：
「脈絡越來越重，我還有測試要完成。」
"Context's getting heavy and I still have the test pass to do."
「先壓縮摘要再開始——把關鍵內容寫進摘要提示詞，讓新工作階段保留 Schema 決策、捨棄探索過程的雜訊。」
"Compact before you start — write what's load-bearing into the summary prompt so the new session keeps the schema decisions and drops the exploration."
Autocompact
由駕馭（Harness）在上下文視窗接近填滿時自動觸發的壓縮摘要（Compaction）。
情境例句：
「它似乎不記得我們早些時候對 Schema 做的決定了。」
"It doesn't seem to remember what we decided about the schema earlier."
「自動壓縮摘要（Autocompact）在對話輪次之間觸發了——早期的決定被摘要化，可能有些細節遺失了。重新載入計劃文件，或者下次手動壓縮，這樣你才能控制哪些內容被保留。」
"Autocompact fired between turns — the early decisions got summarised and we must have lost something. Reload the plan doc, or compact manually next time so you control what gets kept."
Section 6 — 記憶與引導
Memory system
一套試圖讓代理人能夠跨工作階段保有狀態（Stateful）的系統。在工作階段進行中將資訊持久化到環境，並在未來工作階段開始時重新載入上下文視窗，使代理人在使用者清除工作階段後仍能維持連續性。
情境例句：
「我每次都要重新告訴它我用的是 Postgres，不是 MySQL。」
"I keep having to re-tell it I'm on Postgres, not MySQL."
「接上記憶系統——在第一個對話輪次把它學到的內容寫入檔案系統，並在工作階段開始時重新載入。模型本身是無狀態的；記憶層模擬了持續性。」
"Wire up a memory system — write what it learns to the filesystem on the first turn, reload it at session start. The model itself is stateless; the memory layer fakes continuity."
AGENTS.md
一個位於環境（Environment）中、由駕馭（Harness）在工作階段（Session）開始時載入上下文視窗（Context Window）的檔案——這是專案給代理人的常駐任務說明書。各家駕馭通用的慣例。
避免使用： 將 AGENTS.md 用於應漸進式揭露（Progressive Disclosure）的內容——放在 AGENTS.md 裡的任何內容，每個對話輪次（Turn）都要付出詞元（Token）代價。
情境例句：
「為什麼每個工作階段一開始就已燒掉 4000 個詞元了？」
"Why is every session starting with 4k tokens already burned?"
「看看 AGENTS.md——有人把整份樣式指南直接貼在裡面，而不是把它放在技能（Skill）後面按需載入。」
"Check AGENTS.md — someone pasted the entire style guide in there instead of putting it behind a skill."
Progressive disclosure
只載入代理人當下需要的脈絡，其餘則用脈絡指標連向。借鑒自 UI 設計。
情境例句：
「我應該把整份樣式指南塞進 AGENTS.md 嗎？」
"Should I dump the entire style guide into AGENTS.md?"
「不——漸進式揭露（Progressive Disclosure）。把樣式指南作為一個技能（Skill）來引用，讓代理人在真正需要寫元件時才載入它。AGENTS.md 每個對話輪次都要付出詞元代價。」
"No — progressive disclosure. Reference the style guide as a skill the agent loads when it actually needs to write a component. AGENTS.md pays the token cost every turn."
Context pointer
文件中指向另一份文件的一個提及，讓代理人只在任務需要時，才把它拉進上下文視窗。這是構成漸進式揭露的基本單位。
避免使用：「參照」——太平淡，無法表達跟著它走就會把更多脈絡帶進來。「傳送門」——又太浮誇。
情境例句：
「AGENTS.md 越來越肥了。」
"AGENTS.md is getting huge."
「裡面大多數都應該改成脈絡指標，而不是直接塞內容。永遠要生效的規則就直接寫在裡面；部署操作手冊和樣式指南改做成技能，留下脈絡指標就好。」
"Most of it should be context pointers, not content. Keep the always-on rules inline; turn the deploy runbook and the style guide into skills and leave a context pointer behind."
Skill
一種可訓練的能力單元——針對某一項任務整理好的指令和資源，存放在環境中，直到脈絡指標在任務需要時把它拉進上下文視窗。這是駕馭中實現漸進式揭露的基本單位。
避免使用：「工具」——工具是代理人呼叫的東西；技能（Skill）是它讀取的指令。
情境例句：
「部署操作手冊要放哪裡？」
"Where should I put the deploy runbook?"
「作為一個技能——代理人只在任務涉及部署時才載入它。放在 AGENTS.md 裡，每個對話輪次就要為一個每週只用一次的東西消耗詞元。」
"As a skill — the agent loads it only when the task involves deploys. In AGENTS.md it'd burn tokens on every turn for something we use weekly."
Subagent
由另一個代理人透過工具呼叫（Tool Call）生成的代理人。在自己的工作階段中、帶著自己的上下文視窗運行，並回傳單一工具結果。與交接（Handoff）不同——父代理人明確期待一個返回結果；交接則沒有返回路徑。無法再生成子代理人——這個樹結構只有一層深。子代理人的存在是為了隔離脈絡，而非構建層級結構。
情境例句：
「grep 結果把我的脈絡撐爆了。」
"The grep results are blowing out my context."
「生成一個子代理人（Subagent）來做搜尋——它用自己的上下文視窗消耗那些雜訊，再把你真正需要的兩個檔案路徑回報給你。」
"Spawn a subagent to do the search — it'll burn its own context window on the noise and report back the two file paths you actually need."
Section 7 — 工作模式
Human-in-the-loop
一種工作模式，一或多位人類在工作階段進行中全程與代理人搭檔——即時審查、重新導向或協作。人類全程在場且主動參與，而不只是針對個別操作把關。
情境例句：
「要讓這個任務 AFK 跑一夜嗎？」
"Run this AFK overnight?"
「不，這是 Schema 遷移——保持人在迴圈（Human-in-the-loop）。我想看到每個步驟，如果它選錯了要回填的欄位，我要能即時介入調整。」
"No, schema migration — keep it human-in-the-loop. I want to see each step and steer if it picks the wrong column to backfill from."
AFK
離開鍵盤（Away from keyboard）。一種工作模式：使用者啟動一個工作階段後便離開，讓代理人在無人監督下持續執行。這是 AI Coding 的吞吐量倍增器——在你睡覺、吃飯或處理其他事情時，可以同時並行執行多個 AFK 工作階段。通常需要寬鬆的權限模式搭配沙盒機制才能安全運作。
避免使用：「背景代理人」——這個說法以機器為中心（「在背景執行」），而非以人的行為模式為中心（「使用者已離開」）。AFK 的關鍵事實是：使用者沒有在看。
情境例句：
「我要讓這個工作 AFK 執行——三個沙盒化的代理人負責重構，早上再來審查 PR。」
"I'm running this AFK — three sandboxed agents on the refactor, reviewing the PRs in the morning."
「要繞過權限嗎？」
「對，唯讀檔案系統，不連外網。」
"Yeah, read-only filesystem, no network."
Automated check
在環境中執行的確定性驗證——測試、型別檢查、靜態分析（lint）、建置、pre-commit hooks。結果只有通過或失敗，不涉及判斷。這是代理人可以自行修正、無需任何人介入的訊號。不穩定的測試是壞掉的自動化檢查，而非不算數的檢查；自動化檢查就是要設計成確定性的。
避免使用：「回饋迴路」、「反壓」——這兩個詞把自動化檢查和審查混為一談。避免使用：「測試」——測試是自動化檢查的一種，但並非所有自動化檢查都是測試。
情境例句：
「代理人在 AFK 執行時一直交出有問題的程式碼。」
"The agent keeps shipping broken code in the AFK runs."
「沙盒裡接了哪些自動化檢查？」
"What automated checks are wired into the sandbox?"
「只有單元測試。」
"Just the unit tests."
「加上型別檢查和靜態分析——它在 PR 送出之前就能自行從這些結果修正。」
"Add typecheck and lint — it'll self-correct from those before the PR ever lands."
Automated review
由一個代理人審查另一個代理人的工作，通常使用不同的模型或系統提示詞。非確定性的：它會形成判斷。可以在任何地方執行——合併前的 PR 審查、提交歷史的事後審查、作為子代理人在工作階段中途執行。CI 裡的 LLM-as-judge（語言模型作為裁判）是自動化審查，而非自動化檢查；判斷一件事屬於哪個類別，看的是斷言做了什麼，而非在哪裡執行。
避免使用：「AI 審查」、「代理人審查」——過於模糊，無法與執行工作的代理人本身區分。
情境例句：
「AFK 執行產出了太多劣質 PR。」
"We're getting too many bad PRs from the AFK runs."
「在合併前加一個自動化審查步驟——使用不同模型、獨立的系統提示詞，範圍鎖定在安全性和介面合約的變更。」
"Add an automated review step before merge — different model, separate system prompt, scoped to security and contract changes."
Human review
使用者親自閱讀代理人生成的程式碼並形成判斷。閱讀 diff 或修改後的檔案才算數；只閱讀代理人對其操作的描述並不算——敘述不等於產出物本身。
避免使用：單獨說「程式碼審查」——這個說法含糊，無法區分是人工審查還是自動化審查。
情境例句：
「我人工審查了 AFK 的輸出。」
"I human-reviewed the AFK output."
「你讀了 diff 還是只看摘要？」
"You read the diff or just the summary?"
「讀了 diff。摘要說它刪除了死碼——結果那個函式是從一個生成的檔案裡呼叫的。」
"Diff. The summary said it deleted dead code — turned out the function was called from a generated file."
Vibe coding
一種工作模式，使用者直接接受代理人的程式碼，不進行人工審查。程式碼差異被視為不透明的黑盒——重要的是程式是否正常運作，而非內部有什麼。自動化審查和自動化檢查可能仍會執行；氛圍程式設計（Vibe Coding）對這兩者都保持沉默。
避免使用：「氛圍程式設計」作為「低品質 AI Coding」的代名詞——這個術語描述的是審查立場，而非所產生的程式碼品質。
情境例句：
「你有讀它在認證流程裡改了什麼嗎？」
"Did you read what it changed in the auth flow?"
「氛圍程式設計（Vibe Coding）了——登入還能用，我就只確認這個。」
"Vibe coded it — login still works, that's all I checked."
「推送之前把 diff 讀一遍，在認證上氛圍程式設計是 secrets 洩漏進 log 的方式。」
"Read the diff before you push, vibing on auth is how secrets leak into logs."
Design concept
使用者與代理人之間對於正在構建的事物所共同持有的理解，存在於雙方之間，但獨立於任何具體產出物之外。Brooks 的術語（出自《The Design of Design》）：對話、交接文件（Handoff Artifacts）和程式碼，都是試圖捕捉或觸及設計概念的產出物，但它們都不等同於設計概念本身。設計概念的品質，可從建立它的對話品質中感受出來。
情境例句：
「它寫出了我要求的東西，但還是寫錯了。」
"It's writing exactly what I asked for and it's still wrong."
「你們還沒有建立共同的設計概念——它在用假設填補空白。在你讓它寫規格書之前，先持續對話，直到取消、退款和部分履行的邊界情況都在你們之間對齊為止。」
"You don't share a design concept yet — it's filling gaps with assumptions. Keep talking until cancellation, refunds, and partial fulfilment all line up between you before you let it write a spec."
Grilling
一種與代理人共同發展設計概念（Design Concept）的技術：由代理人以蘇格拉底式的方式訪談使用者，每次針對一個決策，並為每個決策提出一個建議答案。這個方式刻意放慢直奔最終計劃的衝動——在概念穩定之前，不撰寫任何交接文件（Handoff Artifact）。
情境例句：
「它直接去寫規格書，結果把取消邏輯搞錯了。」
"It went straight to writing the spec and got the cancellation logic wrong."
「先問答引導（Grilling）它——讓它在提交任何文字之前先問你關於部分取消、退款和時序的問題。在對話中釐清比在程式碼中修正要便宜得多。」
"Grill it first — make it ask you about partial cancels, refunds, and timing before it commits anything to the doc. Cheaper to resolve in conversation than in code."