上下文工程
Context Engineering
同樣的 GPT-4，在某個產品裡看起來聰明，在另一個產品裡看起來笨—— 同樣的權重，同樣的 API，同一個月。真正改變的是產品給了模型什麼可以運作的素材。 那段距離——模型能力的上限與你實際能觸及的高度之間——幾乎永遠是上下文的問題， 而不是能力問題。
這篇文章就是在談那段距離。它從兩個尺度處理上下文工程： 專案尺度（你的團隊在規格、計畫、決策、程式碼中累積的東西）與 推論尺度（單次呼叫的 token window 裡有什麼）。兩者是同一門技藝在不同高度的體現—— 當你能看見兩者如何相連，大部分的價值才會浮現。
在公開場合被命名
「上下文工程」這個名字，是在 2025 年 6 月於 X（推特）上被公開命名的。 它之所以流行起來，是因為它捕捉到實務工作者早已感受到的轉變—— 從撰寫巧妙的單次提示，轉向設計模型所處的整個資訊環境。
「我真的很喜歡『上下文工程』這個說法，勝過『提示工程』。它更精確地描述了核心技能：為了讓 LLM 有合理可能解決任務，提供一切所需上下文的藝術。」
「+1 給『上下文工程』勝過『提示工程』……這是一門細緻的藝術與科學——用下一步所需的恰當資訊來填滿 context window。」
Cognition 在一週之前（6 月 12 日）的 Don't Build Multi-Agents 就已經用這個短語作為章節標題—— 所以工程社群內部早已在用這個詞，Lütke 的推文只是讓它被更廣大的讀者看見。 Anthropic 在 9 月發表了機構層級的文章；Linear 則在 2026 年 3 月把產品開發的框架正式化。
上下文住在哪裡
你大部分的上下文其實不在模型的 window 裡。它們散落在團隊已經寫下來的東西—— 分布在 Slack、Notion、Linear、GitHub，以及團隊的集體記憶中。 以 Linear 的產品開發框架來看，那些累積的記憶可以分成七種素材：
- 計畫
- 討論
- 規格
- 技術設計
- 決策
- 摘要
- 程式碼
這些都是你的團隊早已在產出的東西——浮現意圖的計畫與討論、把想法釘在介面上的規格與技術設計、 把曖昧凝結成結論的決策、把會議壓縮下來的摘要，以及程式碼本身。每一種素材都有不同的半衰期、 面對不同的讀者。它們合起來，就是模型要做任何超越通用泛泛回答的事所需要的 累積記憶。
在這個尺度上，兩種失敗模式最常見：
- 上下文存在，但無法被取用。決策留在 agent 看不到的會議記錄裡。於是它幻想出一個決定，而你花一週時間撤銷它。
- 上下文過時。上一季的計畫還掛在 onboarding 文件裡。agent（和新進員工）乖乖地照著它走進錯誤的森林。
專案尺度的上下文工程，是讓團隊記憶既可取用又新鮮的紀律。 每個用 AI 開發產品的團隊，最後都會走到這裡。 Linear：What's Next ↗
為什麼規格重要
「AI 無法取代思考。它只能放大你已經做過的思考，或你還沒做的思考。」
規格是被壓縮過的上下文。當團隊寫下一份清楚的規格， 他們等於把原本只存在某人腦中的決策、限制與意圖攤出來——讓那些思考變得可取用， 無論是審查程式碼的人類，還是生成程式碼的 agent。
這正是「知識缺口」視角開始有用的地方。如果你的規格漏掉了 「我們上季因為 Y 的理由否決了方案 X」，模型就會興高采烈地重新提議 X。 你會在螢幕前抓狂。模型沒有失敗——是你的上下文失敗了。缺的那份規格就是 bug。
從 Dex Horthy 關於 coding agents 的實務經驗擷取幾個重點：
- 一份糟糕的計畫等於 100 行糟糕的程式碼。一次糟糕的研究可能把整件事引向完全錯誤的方向。在上游抓錯誤，是槓桿最高的一步。
- 帶有檔名與行數的計畫，遠勝過籠統的文字。世界上最笨的模型也能照著清楚的計畫走；沒有一個模型能執行模糊的計畫。
- 按需壓縮的上下文，勝過靜態的 onboarding 文件。文件會腐壞；要研究時就從程式碼這個「真實來源」重新產生當下這塊需要的上下文。
你真正擁有的窗口
鏡頭拉近。單次對模型的呼叫發生在一個固定大小的窗口裡——目前典型是 128K 或 200K tokens， 旗艦級模型可到 1M 甚至 2M。業界的直覺通常是：上下文越多，答案越好。 這個直覺其實是錯的。
Chroma 在 2025 年 7 月的研究（Context Rot）測試了 18 個模型——包括 GPT-4.1、 Claude 4、Gemini 2.5——發現表現會隨輸入變長非線性地衰退。 不同任務的拐點不同，但規律一致：超過某個門檻，模型用更多上下文推理的結果反而更差，不會更好。
輸入變長時，模型表現會非線性地衰退（Chroma Research，2025）。Dex Horthy 實務上把拐點定在 40% 左右。
軌跡也很重要。如果對話歷史是 「模型嘗試 → 人類糾正 → 模型再嘗試 → 人類再糾正」， 下一個最可能出現的 token 是模型再嘗試錯誤，人類再糾正。 模型是對整個軌跡做 pattern-match，不是只對事實。 一旦對話偏掉，重新開一個新視窗幾乎永遠比硬推下去便宜。
實務上的含意：上下文不是免費的，而且多不見得好。 你放進窗口的每個 token，都同時消耗延遲與注意力。 好的上下文工程把窗口當作預算，而不是桶子。 Chroma：Context Rot ↗
站得住腳的技巧
實務工作者的寫作中，有五個技巧反覆出現。它們是同一個動作的不同形狀： 先整理，再累積。
- 有意識的壓縮。 在視窗開始衰退之前，停下來，要求 agent 把目前的工作上下文壓縮成一個 markdown 檔案。 審視它，標記它。然後用壓縮後的版本作為全新的起點。 主動地壓縮，而不是等到 Claude 告訴你它開始迷糊。 Dex Horthy 演講 ↗
- 子代理用來隔離上下文，不是扮演角色。 不要為了模仿職銜而建立「QA 子代理」、「前端子代理」。 子代理的正確用法是——在你想把一個有邊界的研究工作交出去時， 讓子代理在自己的窗口裡讀完那堆資料，回報一段精簡的摘要給還待在聰明區的父代理。
- 研究 → 計畫 → 實作。 三個階段，每個階段的上下文都更小，輸出都更清楚。 研究壓縮的是真相；計畫壓縮的是意圖；實作則依照壓縮後的意圖執行。 每個階段的產物，都是下一階段的上下文。
- 按需壓縮的上下文勝過靜態文件。 與其手寫一份會老化的 onboarding 文件，不如讓一次研究從當前程式碼中重建上下文。 任何靜態文件的「偏離真相程度」圖表，縱軸的標籤都寫著「謊言」。
- 保持軌跡乾淨。 一個被糾正了六次的模型，會預期第七次也會被糾正。 與其跟它吵到對，不如用同一個目標、更乾淨的開場，另起一個新對話。
在這五項之上還有一個後設技巧：不要把思考外包出去。 計畫在被執行前還是得是對的。一個工具吐出一整面 markdown 讓你覺得「做了事」， 並不是上下文工程的勝利——思考還是留在你的盤子上，只是被漂亮的捲軸蓋住了。 模型放大的是你的用心，它無法替代你的用心。
駕馭工程作為一種視角
上下文工程中有一個特別有用的子集合—— 駕馭工程 所命名的那個分割：模型（使用時你改不了的那部分） 與馬具（人類在它周圍打造的一切——提示、工具、schema、護欄、記憶）。 這個分割偏教學性，不是技術定義上的嚴格界線，但它很銳利。 它回答了每個 AI 團隊都會問的問題：我們到底能修的是什麼？
如果某個行為落在模型那邊，你的選項是：換一個模型、等下一代更強的、或 fine-tune（昂貴，常常是壞主意）。 如果它落在馬具那邊，那是你的。上下文工程的技藝，就是辨認出在你手上這個問題裡，哪一邊才是重點。
重點摘要
- 能力是上限。上下文決定你能多接近那個上限。
- 規格不是官僚主義——它是被壓縮過的上下文。好的規格讓你團隊的思考對人類與 agent 同時可取用。
- 更多的上下文不等於更好。把窗口當成預算來管理。壓縮、隔離、在軌跡偏掉時重新來過。
