事實

術語 · LLM 工程 · AI 代理 · 語言模型 · 效能評測 · AI 人工智慧 · 說明這個名詞與這門功夫，2023 年 1 月至 2026 年 9 月

• 878天：從目前找到最早的用法（2023 年 1 月）到 Tobi Lütke 的貼文（2025 年 6 月）
• 6天：從「全部的脈絡」到 Andrej Karpathy 警告脈絡太多也有害
• 18個模型經 Chroma 測試；每一個都是輸入愈長愈不可靠
• 1,000名情境工程師：Cognizant 於 2025 年 8 月宣布一年內部署的人數

不到三年內的四個定義 並排來看，它們對這份工作是「加脈絡」還是「減脈絡」並沒有共識。

• Riley Goodside · 2023 年 1 月 23 日

  「挑選並準備相關脈絡」

  是提示工程的一半，而不是它的接班人。

  • 原文：「我認為提示工程可以分成『情境工程』，也就是為任務挑選並準備相關脈絡，以及『提示編程』，也就是寫出清楚的指示。」
  • 這是 Hacker News 上的一則留言，Simon Willison 當天就加以引用。它是目前找到最早的用法——並不證明沒有人更早寫過。

• Tobi Lütke · 2025 年 6 月 19 日

  「提供全部的脈絡」

  最先被別人引用的貼文：一道「夠不夠」的考題。

  • 原文：「把全部的脈絡提供給大型語言模型，讓任務有可能被它解出來的功夫。」
  • 他開頭寫的是「我真的很喜歡這個詞」——是在支持一個已經有人在用的說法。一週前，Cognition 的 Walden Yan 已稱情境工程「實際上是打造 AI 代理的工程師的頭號工作」。

• Andrej Karpathy · 2025 年 6 月 25 日

  「為下一步準備剛剛好的資訊」

  六天後，引用 Lütke 的貼文——並點出兩種失敗。

  • 「太少或形式不對，模型就沒有達到最佳表現所需的脈絡。太多或太不相關，成本可能上升，表現可能下降。」
  • 從「任務」變成「下一步」：挑選脈絡是每一輪都要做的事，而不是一件工作做一次。
  • 他也替這個詞劃了界線：情境工程「只是正在成形的一整層不簡單的軟體裡的一小塊」。

• Anthropic · 2025 年 9 月 29 日

  「訊號最強、數量最少的 token 集合」

  正式定義，以「少」為指導原則。

  • 正式寫法：「在大型語言模型推論期間，篩選並維持最佳 token（資訊）集合的一套策略，包括提示以外可能落進脈絡的其他所有資訊。」
  • 提示工程如今被放進它裡面：情境工程是提示工程的「自然延伸」，而且「每次決定要把什麼交給模型，都會經過一次篩選」。
  • 這是廠商的定義，由其應用 AI 團隊為在自家平台上開發而寫。

各部分站得多穩 依可信程度排序。有日期的文件、量測結果和廠商自報的數字，是不同種類的事實。

時序

從一則留言到一個職稱 每個日期都是一次發表。人們何時改變做事方式，沒有一份來源量測過。

1. 2023 年 1 月 23 日提示工程的一半。Riley Goodside 在 Hacker News 上把提示工程分成「情境工程」——挑選並準備相關脈絡——和「提示編程」。這是目前找到最早的用法。
2. 2024 年 12 月 19 日有這份工作，還沒有這個流行詞。Anthropic 把「加上檢索、工具與記憶等擴充能力的大型語言模型」稱為代理系統的基本構件。
3. 2025 年 4 月 7 日「一切都是情境工程。」Dex Horthy 發表在 GitHub 上的〈12-Factor Agents〉指南，依其提交日期。
4. 2025 年 6 月 12 日頭號工作。Cognition 的 Walden Yan 稱情境工程是提示工程的「下一個層次」，要「在動態系統中自動完成」。
5. 2025 年 6 月 18 日問題有了名字。一位 Hacker News 留言者提出「脈絡腐化」：脈絡愈長，「輸出品質下滑得很快」。
6. 2025 年 6 月 19 日全部的脈絡。Tobi Lütke 表示比起提示工程，他更喜歡這個詞：提供全部的脈絡，讓任務有可能被解出來。十一天內，Simon Willison、Harrison Chase 與 Philipp Schmid 都引用了它。
7. 2025 年 6 月 22 日三天後，反方論點。Drew Breunig：「更長的脈絡不會產生更好的回應」，並列出脈絡失敗的四種方式——中毒、分心、混淆、衝突。
8. 2025 年 6 月 23 日框架廠商的定義。LangChain 的 Harrison Chase：以動態系統、用正確的格式提供正確的資訊與工具；提示工程是它的「子集」。
9. 2025 年 6 月 25 日六天後，兩面都講。Andrej Karpathy 引用 Lütke 的貼文並重新定義：為下一步準備剛剛好的資訊——太少有害，太多也有害。
10. 2025 年 6 月 27 日站得住。Simon Willison：這個詞「可能會流傳下去」，因為「大家推斷出來的定義才會留下來」，而這個詞讓人推斷出的意思，很可能更接近原意。
11. 2025 年 7 月 14 日有人量測了。Chroma 的《Context Rot》報告：十八個模型，沒有一個處理長輸入能像處理短輸入一樣可靠。報告標題用的名字，26 天前才在 Hacker News 上首次出現。
12. 2025 年 7 月 17 日紙上的一門學科。Lingrui Mei 等人發表綜述，把它定位為「一門正式的學科」，所依據的研究論文超過 1,400 篇。
13. 2025 年 8 月 29 日一個職稱。Cognizant 宣布一年內部署 1,000 名情境工程師，並把脈絡定義為一家公司的「知識總和」。
14. 2025 年 9 月 29 日數量最少的集合。Anthropic 的正式定義把「少」定為指導原則，距「全部的脈絡」102 天。同一天，它推出脈絡編輯與記憶工具。
15. 2026 年 2 月又兩項量測。Damon McMillan 發現模型本身的能力遠比脈絡的格式重要；LOCA-bench 發現代理的表現隨脈絡增長而下滑，而脈絡管理有幫助。
16. 2026 年 7 月 30 日廠商問買家。Redis 的調查：受訪的 IT 與 AI 基礎設施主管幾乎都說，脈絡決定 AI 能否奏效；但很少人說自己已建好供應脈絡的系統。
17. 2026 年 9 月仍是一節，不是一個條目。維基百科沒有情境工程的專頁；它是〈Prompt engineering〉條目裡的一節，該條目最近一次修訂在 9 月 21 日。

論點

不是反轉，而是選擇 兩種考題第一週就都擺上桌了。正式定義選了其中一種。

補充

實務上怎麼做 Anthropic 的指南是最詳細的說明；接下來的表格補上其他人發表的內容。

1. 1寫在恰當的高度介於寫死而脆弱的邏輯，與假設彼此已有共識的模糊指引之間。目標是能完整規範行為的最少內容——最少不等於最短。
2. 2工具組要小自成一體、能承受錯誤、彼此重疊最少。如果人類工程師都說不出某個情況該用哪個工具，就不能指望模型做得更好。
3. 3晚點抓，不要早抓保留輕量的識別資訊——檔案路徑、儲存的查詢、連結——在執行時才載入資料。後設資料本身就是訊號：放在 tests 裡的 test_utils.py，和放在 src/core_logic/ 裡的同名檔案，意思不同。
4. 4長任務要懂得丟東西壓縮（把滿了的視窗做成摘要，再從摘要重新開始）、結構化筆記（筆記存在視窗外，需要時再讀回來），以及子代理（用數萬個 token 探索，只回傳一兩千個）。

單一廠商指南之外 其他打造代理的人發表了什麼、又量測了什麼。最後一欄說明每項屬於哪一種證據。

結論

帶走什麼 三件事，最後一件是：這個詞從哪裡來，能說的其實很少。