事實
術語 · LLM 工程 · 語言模型 · 效能評測 · AI 人工智慧 · 名詞解析Tratopedia · 2026 年 8 月 15 日
五篇之二 · 包住提示的那一層
「全部的脈絡」只撐了六天
2025 年 6 月 19 日，Shopify 執行長說：情境工程是把全部的脈絡提供給模型，讓任務有可能被解出來。六天後，Andrej Karpathy 表態支持這個詞，同時悄悄改了它的意思：把剛剛好的資訊填進脈絡視窗，供下一步使用。再過三週，Chroma 量測了十八個模型，發現輸入愈長，表現就愈不可靠。到了九月底，Anthropic 的定義已經和最初那句話相反 —— 找出訊號最強、數量最少的 token 集合。大約一百天之內，這個詞從「你給模型的夠不夠」，變成了「你給模型的是不是太多」。
十五週內的四個定義 把它們並排，說的並不是同一件事。差別就是本文的重點。
- 6從這個詞被支持，到它的意思被收窄，相隔的天數
- 102從「全部的脈絡」到「數量最少的集合」，相隔的天數
- 18Chroma 測試的模型數；沒有一個是均勻使用其脈絡的
- 0擷取時，這個詞的維基百科條目數 —— 它只是另一個條目裡的一段
Tobi Lütke · 2025 年 6 月 19 日
「提供全部的脈絡」
- 全文：把全部的脈絡提供給 LLM，讓這項任務有可能被解出來的技藝。
- 注意「這項任務」—— 單數，而且做一次就好。
- 他自己的說法是「我很喜歡這個詞」，讀起來像是認可，而不是發明。但本站查到的資料也沒有指出更早的使用者。
Andrej Karpathy · 2025 年 6 月 25 日
「供下一步使用的剛好資訊」
- 「我支持用情境工程取代提示工程。人們把提示聯想成簡短的任務描述……但在每一個工業級的 LLM 應用裡，情境工程是把脈絡視窗填滿的精細技藝與科學……」
- 從「這項任務」變成「下一步」：從每件工作做一次，變成每一輪都要做一次。
- 本站取回的內容在句子中間就斷了。結尾「供下一步使用的剛好資訊」是 Anthropic 引用的，且該文連結到這則貼文。屬於旁證，不是讀到全文。
Chroma · 2025 年 7 月 14 日
不是定義，是限制
- 他們檢驗的假設是：模型「處理第 10,000 個 token 應該和處理第 100 個一樣可靠」。他們的發現是：並非如此。
- 模型「並非均勻使用其脈絡；其表現隨輸入長度增加而愈來愈不可靠」—— 涵蓋 GPT-4.1、Claude 4、Gemini 2.5 與 Qwen3。
- 它落在造詞與正式定義之間。這很值得玩味，但本頁不把它當成已證實的因果。
Anthropic · 2025 年 9 月 29 日
「訊號最強、數量最少的 token 集合」
- 正式定義：在 LLM 推論期間，策畫並維持最佳 token 集合的一整套策略，包含所有落在提示之外的其他資訊。
- 它也把節奏講明了：「策畫這個階段，每一次我們決定要傳什麼給模型時都會發生。」
- 這是廠商給的定義，也是此處唯一的正式定義。本次連線遭拒連 anthropic.com —— 全文由 djTratoh 提供。
每一部分站得多穩 幾乎全部都讀了原始出處。有兩項不是，還有一項是算出來的。
| 確信程度 | 內容 | 依據 |
|---|---|---|
| 已讀原始出處 | Lütke 的原話：「把全部的脈絡提供給 LLM，讓這項任務有可能被解出來的技藝」 | 他在 X 上的貼文，2026 年 8 月 15 日擷取 |
| 已讀原始出處 | Karpathy 的原話，到「把脈絡視窗填滿」為止 | 他在 X 上的貼文，2026 年 8 月 15 日擷取。取回的文字在該處被截斷 |
| 已讀原始出處 | Chroma 測試了 18 個 LLM；模型「並非均勻使用其脈絡」；表現「隨輸入長度增加而愈來愈不可靠」 | 《Context Rot》，Chroma 技術報告，2025 年 7 月 14 日，已讀原始出處。僅讀了開頭 —— 本頁未引用其中任何單一實驗結果 |
| 已讀原始出處 | 情境工程沒有維基百科條目；它只是〈Prompt engineering〉裡的一段 | 2026 年 8 月 15 日擷取時回傳 404。缺席也是一種發現：百科全書仍把它視為子題 |
| 推算而得 | 兩則貼文相隔六天 —— 2025 年 6 月 19 日 03:01 UTC 與 6 月 25 日 15:54 UTC | 由貼文本身的 ID 推算，該 ID 內含毫秒級時間戳。這是推算而非閱讀 —— 可重複驗證，但和在頁面上看到日期不同 |
| 他人提供，來源遭封鎖 | Anthropic 的正式定義、注意力預算、n² 注意力論證，以及三項長時程技術 | 《Effective context engineering for AI agents》，2025 年 9 月 29 日。本次連線的所有工具對 anthropic.com 均得到 403；全文由 djTratoh 提供 |
| 本站推論 | 這個詞反轉了：從「夠不夠」的判準變成「太多了沒」的判準 | 由上述四個定義綜合而成。沒有任何來源提及這一點 |
| 本站推論 | Chroma 的量測是收窄的可能原因 | 它落在造詞與正式定義之間，且 Anthropic 有引用它 —— 但沒有任何資料說定義是因它而改變 |
時序
一百零二天 五個名詞中時間最密的一段 —— 四份文件，以及夾在中間的一次量測。
- 2024 年 12 月工作已在，名字未到。Anthropic 把「增強型 LLM」—— 模型加上檢索、工具與記憶 —— 描述為一切代理式系統的基本組件。這些全都是情境工程，但當時還沒有這個名字。
- 2025 年 6 月 19 日全部的脈絡。Tobi Lütke 貼文表示，他偏好用「情境工程」而非「提示工程」，因為它更能描述核心技能：提供全部的脈絡，讓任務有可能被解出來。
- 2025 年 6 月 25 日六天後，變成剛剛好的脈絡。Karpathy 表態支持 —— 同時把它重新定義為：把剛好的資訊填進視窗，供下一步使用。「全部」這個詞沒有撐過那一週。
- 2025 年 7 月 14 日有人把它量出來了。Chroma 發表《Context Rot》：十八個模型，沒有一個處理第 10,000 個 token 時，能和處理第 100 個時一樣可靠。輸入愈長，表現愈不可靠。
- 2025 年 9 月 18 日迴圈也有了定義。Simon Willison 定調為「LLM 代理在迴圈中使用工具以達成目標」。正是那個迴圈，不斷產出如今需要有人去策畫取捨的 token。
- 2025 年 9 月 29 日數量最少的集合。Anthropic 給了這個詞第一個正式定義 —— 在推論期間策畫並維持最佳的 token 集合 —— 並把目標明訂為訊號最強、數量最少的集合。距離「全部」那句話，一百零二天。
論點
為什麼一個定義會在一百天內反轉 因為第一個是願望，第二個已經被量過了。
Lütke 的定義是一個「夠不夠」的判準。你有沒有把模型需要的東西都給它？如果沒有，任務就不可能被解出來，而那是你的問題，不是模型的問題。這是個慷慨而務實的想法，也確實指向一種真實的失敗 —— 看不到檔案的代理，就用不了那個檔案。Anthropic 的定義則是「太多了沒」的判準，指向相反的失敗。脈絡是有限的，模型有注意力預算，而每一個 token 都會花掉一些。架構解釋了原因：Transformer 讓每個 token 都能注意到其他每個 token，於是 n 個 token 產生 n² 組兩兩關係，視窗愈滿，注意力就被攤得愈薄。結果是一道斜坡而不是一道懸崖 —— 模型在長脈絡下仍有能力，但精準度會下降。兩者之間發生的事，是有人把它量了出來。Chroma 用十八個模型檢驗「第 10,000 個 token 和第 100 個一樣可靠」這個假設，結果報告說並非如此 —— 不是某一個模型，是全部。一旦這件事被記錄下來，「把全部的脈絡都給它」就不再是慷慨，而是一種讓自己系統退化的做法。本頁沒有主張是 Chroma 造成了這個改變。該報告落在造詞與正式定義之間，而且 Anthropic 有引用它；這值得玩味，但也就僅止於此。能夠證明的只有用字：6 月 19 日的「全部的脈絡」、6 月 25 日的「剛剛好」、9 月 29 日的「數量最少的集合」。
- all → least同一個詞，相隔一百零二天
- 18據 Chroma，有 18 個模型並非均勻使用其脈絡
- n²n 個 token 產生的兩兩關係數 —— 視窗愈滿、注意力愈薄的原因
補充
實際上該怎麼做 Anthropic 自己的做法，是目前最具體的一份說明。
- 1寫在對的高度介於寫死而脆弱的 if-else 邏輯，與假定彼此心照不宣的空泛指引之間。目標是能完整界定行為的最小集合 —— 而且要注意，最小不等於最短。
- 2把工具集保持精簡工具應該自成一體、能容錯、彼此重疊愈少愈好。判準很直白：如果連工程師都說不出某個情境該用哪個工具，就不能指望模型做得更好。
- 3晚一點再取，而不是先囤好只保留輕量的識別資訊 —— 檔案路徑、查詢、連結 —— 到執行時才載入資料。詮釋資料本身就是訊號：
tests/裡叫test_utils.py的檔案，和src/core_logic/裡同名的檔案，意義並不相同。 - 4長工作就得丟東西三種技術：壓縮（把整個視窗摘要後，從摘要重新開始）、結構化筆記（把筆記寫在視窗外，之後再讀回來）、子代理（用上數萬 token 探索，只回傳一到兩千）。
三種長時程技術的比較 Anthropic 自己對「哪一種適合哪種情況」的建議。
| 技術 | 做什麼 | 適合 |
|---|---|---|
| 壓縮 | 把接近上限的視窗摘要後重新初始化。Claude Code 保留架構決策、未解決的 bug 與實作細節，丟掉重複的工具輸出，並帶著最近存取的五個檔案繼續 | 需要大量來回往復的工作 |
| 結構化筆記 | 代理把筆記寫到脈絡視窗之外的記憶體，之後再取回。可以是一份待辦清單，或一個 NOTES.md | 有明確里程碑的迭代開發 |
| 子代理 | 專職代理在乾淨的視窗中工作，只回傳濃縮摘要 —— 探索了數萬 token，通常只回傳 1,000–2,000 | 平行探索有回報的研究與分析 |
有一點值得從廠商的框架裡抽出來看，因為它最可能隨時間失效。Anthropic 的建議以「做最簡單而有效的事」作結，並預期更聰明的模型將需要更少的策畫 —— 代理式設計會「朝著讓聰明的模型聰明行事、人為策畫逐步減少的方向發展」。那是一個預測，由一個「希望它成真」的一方提出，也應該當成預測來讀。不是預測的，是 Chroma 的量測：由另一個組織執行，涵蓋十八個模型，包含三家廠商的旗艦。如果這些模型已經能均勻處理長脈絡，那份報告會這麼說。它說的是相反的事，而且是對全部模型這麼說。兩者可以同時成立：策畫也許會變輕鬆，但仍然必要。只是其中只有一件事被量過。
- 1本文中唯一的獨立量測。其餘都是定義或做法
- 1–2k子代理從數萬 token 的探索中回傳的 token 數
- 403anthropic.com 對本次連線回傳的狀態碼。該文是他人提供，不是本站抓取
結論
該帶走什麼 三件事，第一件是引用這個詞時的提醒。
先問對方指的是哪一個定義
「把全部的脈絡都提供給它」和「找出數量最少的 token 集合」是兩個相反的指令，而兩者都在一百零二天之內、以同一個名詞發表。2026 年有人說「情境工程」時，可能是指其中任何一個。這個詞本身無法區分。
唯一的獨立量測，是最值得相信的部分
此處四個定義中有三個，來自有東西要賣或有立場要推進的人。Chroma 的報告完全沒有定義這個詞 —— 它檢驗的是模型是否均勻使用長脈絡，涵蓋十八個模型，結論是並非如此。那是最吃重的事實，而它來自唯一沒有在定義任何東西的一方。
沒有任何查到的資料自稱造了這個詞
Lütke 寫的是「我很喜歡這個詞」—— 那是認可某個東西，不是替它命名。Karpathy 寫的是「+1」。兩者讀起來都不像起源，而本站查到的資料中也沒有出現更早的使用者。這個詞常被歸功於他們；就現有證據而言，他們是讓它流行起來的人。