Anthropic 工程師實現 8 倍產出提升：揭秘背後的 Context Engineering 系統

Anthropic 的工程師每天合併的程式碼數量是去年的 8 倍。模型沒有變，硬體沒有變，團隊規模也沒有變。改變的是 Claude 在開始工作前所看到的內容。

大多數開發者將時間花在撰寫更好的提示詞（prompts）上。Anthropic 的工程師則將時間花在建立更好的上下文（context）上。正是這一點轉變，造就了那 8 倍的差距。

Anthropic 自己的研究直接指出：一個 AI Agent 的品質，與其說是取決於模型，不如說是取決於你給予它的上下文。Claude 只能看到上下文視窗內的內容。視窗之外的一切都不存在。這意味著，一位專業 AI 工程師的全部工作並非撰寫巧妙的提示詞，而是確保 Claude 在採取任何行動之前，已經掌握了絕對正確的資訊。

這種紀律現在有了一個名稱：上下文工程（Context engineering）。它正在取代提示詞工程，就像兩年前提示詞工程取代手動腳本編寫一樣。

請收藏此文並追蹤我

我是 Noisy，一位擁有 4 年經驗的開發者。我構建 AI 系統、自動化流程，並尋找將技術轉化為實際收入的方法。

為什麼你的 AI Agent 會給出糟糕的回答

大多數人在 AI Agent 失敗時會責怪模型。例如編輯了錯誤的檔案、做出了錯誤的假設，或是犯下任何開發者一眼就能看出的明顯錯誤。

問題幾乎從來不在模型本身，而在於上下文缺失。

1大多數人給 Claude 的內容   |  提示詞
2Claude 真正需要的內容      |  知識、記憶、檔案、
3                           |  規則、範例、工具、
4                           |  狀態、過往行動

提示詞只是一句話。而上下文是 Claude 運作的整個資訊環境。一個能用的 Agent 和一個不能用的 Agent，其差別幾乎總是在於環境中包含了什麼，而不是正在執行哪個模型。

Anthropic 是這樣描述的：LLM 只能看到上下文視窗內的內容。上下文就是 AI 的作業系統。如果建構錯誤，無論模型能力多強，一切都無法運作。

上下文究竟是什麼

大多數人認為上下文就是他們在提問前貼上的那段文字。那只是其中一層。一個經過妥善設計的上下文，包含七個協同運作的組件。

1記憶 (Memory)            |  Agent 從過去對話中學到的內容
2指令 (Instructions)      |  規則、限制、程式設計風格
3範例 (Examples)          |  優質輸出實際的樣子
4檔案 (Files)             |  相關程式碼、文件、架構
5過往行動 (Previous actions) |  Agent 已經嘗試過的事項
6工具結果 (Tool results)  |  搜尋和函數回傳的內容
7狀態 (State)             |  任務目前的進度

每當 Claude 採取一個行動，上下文就會增加。工具結果回傳、讀取了新檔案、狀態更新。Claude 看到新的上下文並決定下一個行動。這個循環才是 Agent 的實際運作機制——不是提示詞，也不是模型，而是隨著每一步驟不斷演進的上下文。

1使用者請求
2↓
3從七個組件建立上下文
4↓
5Claude 決定行動
6↓
7工具執行
8↓
9結果加入上下文
10↓
11Claude 看到新上下文
12↓
13下一個行動
14↓
15重複直到完成

一個糟糕的 Agent 會在第二步中斷這個循環。由於上下文不完整，Claude 只能進行假設。假設錯誤，輸出自然也就錯誤。大多數開發者試圖透過重寫提示詞來解決，但真正的解決方案是正確地建構上下文。

三層上下文堆疊

Anthropic 建議將上下文分為三層來思考。每一層都有不同的用途，並在 Agent 工作的不同階段載入。

1全域上下文 (Global Context)   |  始終存在，適用於每次對話
2專案上下文 (Project Context)  |  在專案開始時載入
3任務上下文 (Task Context)     |  針對特定任務載入

全域上下文是永久層。包含身份、核心規則、程式設計風格，以及 Agent 絕對不該做的事。這在對話之間永遠不會改變，也不需要重複解釋。

1全域上下文包含：
2- Agent 的身份與角色
3- 程式設計標準與風格規則
4- 安全限制
5- 絕對不可觸碰或修改的內容
6- 如何處理不確定性

專案上下文是知識層。Claude 理解此特定程式碼庫所需的一切——架構、使用的模式、做出的決策及其原因、過去發生的錯誤。

1專案上下文包含：
2- README 與架構概覽
3- 包含專案特定規則的 AGENTS.md
4- 資料夾結構與命名慣例
5- 測試需求與模式
6- 關鍵依賴項及其選擇原因

任務上下文是執行層。包含正在處理的特定檔案、當前工單、即時目標，以及適用於此特定任務的限制。

1任務上下文包含：
2- 當前檔案與相關檔案
3- 本次對話的特定目標
4- 最近的變更及其結果
5- 當前測試結果
6- 此任務特有的限制

大多數開發者只給 Claude 任務上下文。Agent 每次開始對話時都沒有全域或專案上下文，必須猜測所有它不知道的事情。這些猜測正是錯誤的來源。

AGENTS.md —— 改變一切的檔案

https://docs.claude.com/en/docs/claude-code/memory

這是任何嚴謹的 Claude Code 設定中最重要的一個檔案。研究人員已將 AGENTS.md 認定為 AI 程式設計 Agent 上下文的新標準——它現在存在於數千個生產環境的儲存庫中，原因就是它確實有效。

AGENTS.md 是專案上下文永久存在的地方。Claude 會在每次對話開始時自動讀取它。之後，它就不再需要被重複告知這些資訊。

1# AGENTS.md
2
3## 架構
4採用 Next.js 前端與 Express 後端的 Monorepo。
5所有 API 路由位於 /api。絕對不要直接修改 /legacy。
6
7## 程式設計規則
8絕對不要使用 axios。一律使用 fetch。
9每個組件：TypeScript、Tailwind、Server Actions。
10除了頁面外，不要使用預設匯出（default exports）。
11
12## 測試
13使用 Vitest 進行單元測試。使用 Playwright 進行 E2E 測試。
14每次提交前執行 npm test。
15絕對不要停用失敗的測試——修復它或上報。
16
17## Git
18絕對不要直接提交到 main 分支。
19一律開啟 PR 並附上清晰的描述。
20將每個 PR 連結到 Linear 工單。
21
22## 禁止觸碰
23src/payments/ - 任何變更都需要人工審核
24src/auth/tokens/ - 需要安全審核
25.env 檔案 - 絕對不要讀取或修改

此檔案中的每一條規則，都是 Claude 以後不會再犯的一個錯誤。專案運行時間越長，AGENTS.md 就越具體且價值越高——它是 Agent 犯過的每一個錯誤以及團隊建立的每一項慣例所累積的知識。

驅動專業 Agent 的上下文堆疊

最優秀的 AI 工程師不會在開始任務時就寫提示詞。他們會建立一個上下文堆疊——這是一組結構化的資訊序列，會在 Claude 採取任何行動之前載入。

1步驟 1  |  載入全域上下文 - 身份、規則、風格
2步驟 2  |  載入專案上下文 - AGENTS.md、架構、文件
3步驟 3  |  搜尋記憶庫以獲取相關過往經驗
4步驟 4  |  載入此特定任務的相關檔案
5步驟 5  |  載入當前狀態 - 測試結果、最近變更
6步驟 6  |  定義具有明確成功標準的任務目標
7步驟 7  |  Claude 在資訊充足的情況下採取行動

比較一下經過良好上下文設計的 Agent 與預設 Agent 的差別：

1糟糕的 Agent：
2問題 → Claude → 回答
3Claude 猜測所有它不知道的事情
4
5優秀的 Agent：
6問題
7↓ 搜尋文件
8↓ 搜尋記憶庫
9↓ 讀取 AGENTS.md
10↓ 讀取相關檔案
11↓ 檢查當前狀態
12↓ Claude
13↓ 基於完整資訊建立的回答

第二個 Agent 並沒有變聰明，它只是資訊更充足。模型是一樣的，但上下文不同。

記憶 —— 在對話之間存續的上下文

Anthropic 對餵養上下文的記憶類型做了明確區分。大多數 Agent 只有一種——當前的對話。這就是為什麼它們每次開始對話時都從零開始。

1長期記憶 (Long-term memory)   |  從過去所有對話中學到的一切
2短期記憶 (Short-term memory)  |  在此對話中稍早發生的事
3工作記憶 (Working memory)     |  當前上下文視窗中的內容

長期記憶是讓 Agent 價值隨時間累積的關鍵。每一次對話都會增加記憶。每一個錯誤都會被記錄。每一個成功的模式都會被儲存。在一個程式碼庫上運行了六個月的 Agent，對該專案的了解是任何提示詞都無法複製的。

實際的實作方式是一個記憶檔案——一個對話之外的 Markdown 文件，Agent 在每次對話開始時讀取，並在結束時更新。

1# 專案記憶
2
3## 架構決策
4- 選擇 Supabase 而非 Firebase：即時性要求較低，需要 SQL 查詢
5- 從 REST 遷移至 tRPC：實現全端型別安全，2026 年 6 月
6
7## 有效的經驗
8- 重構前提高測試覆蓋率可防止回歸錯誤
9- 將大型 PR 拆分為功能旗標（feature flag）發布可減少審核時間
10
11## 無效的經驗
12- 自動生成遷移檔：Schema 偏移導致了生產環境事故
13- 多個 Agent 同時寫入同一個檔案：一律使用 worktrees
14
15## 重複出現的模式
16- 驗證問題幾乎總是追溯到中間件（middleware）順序

每次對話都會讀取此檔案，每次對話也都會更新它。Agent 永遠不會忘記。

MCP —— 來自各處的上下文

上下文不僅來自儲存庫中的檔案。一個生產環境的 Agent 需要來自團隊工作系統中各處的上下文——工單追蹤系統、錯誤監控、文件、資料庫、溝通工具。

模型上下文協定（Model Context Protocol, MCP）讓 Claude 能夠從外部系統提取上下文，而無需為每個系統編寫自定義整合。

1檔案系統 (Filesystem)  |  本地檔案、配置、程式碼庫
2GitHub                |  工單、PR、提交歷史、CI 結果
3Linear / Jira         |  工單、優先級、專案狀態
4Slack                 |  決策過程、討論中的上下文
5Postgres              |  即時資料、Schema、查詢結果
6Google Drive          |  文件、規格、會議記錄
7Sentry                |  即時錯誤、頻率、受影響使用者

配置了 MCP 的 Agent 不僅僅能看到程式碼。它能看到描述為什麼需要此功能的工單、決定架構的 Slack 對話、顯示使用者如何觸發 Bug 的 Sentry 錯誤，以及修復時必須遵守的資料庫 Schema。

這就是完整的上下文。Claude 無需猜測，即可做出正確決策所需的一切。

上下文工程的工作流程

這就是一個經過妥善上下文設計的任務從開始到結束的樣子。

與其這樣：

1建立匯出功能。

你給 Claude 這些：

1目標
2匯出功能是阻礙免費轉付費轉換的關鍵。
3參考訊號：/signals/export-too-hidden.md
4
5相關檔案
6src/features/export/ - 當前實作
7src/components/ui/Button.md - 應遵循的按鈕模式
8tests/features/export.test.ts - 現有測試覆蓋率
9
10架構限制
11閱讀 AGENTS.md 章節：匯出規則
12絕對不要直接修改帳單整合（billing integration）
13
14成功標準
15所有現有測試通過
16新測試涵蓋三種匯出格式
17開啟 PR 並連結 Linear 工單 EXP-47
18src/payments/ 無任何變更

同樣的任務，上下文完全不同。輸出結果不僅僅是稍微好一點，而是本質上的不同，因為 Claude 是在資訊充足的情況下做出決策，而不是靠聰明的猜測。

這個週末的實作設定

第一天 - 建立三層上下文堆疊。撰寫一個包含身份與核心規則的全域上下文檔案。建立包含專案架構、程式設計慣例與禁止觸碰清單的 AGENTS.md。設定一個在對話開始時載入、結束時更新的記憶檔案。

第二天 - 透過 MCP 連接外部上下文。安裝 GitHub 連接器，讓 Claude 能看到你的工單追蹤與 PR 歷史。安裝檔案系統連接器，使其能有效瀏覽程式碼庫。如果你的團隊使用 Slack 或 Linear 進行決策，也請一併加入。

第三天 - 測試差異。使用你舊有的「僅提示詞」方法與完整的上下文堆疊分別執行同一個任務。輸出的差距，就是那 8 倍生產力的來源。

已經發生的轉變

提示詞工程在於尋找正確的詞彙。上下文工程則在於建構正確的資訊環境。

Anthropic 最優秀的 AI 工程師不會花時間構思巧妙的提示詞。他們花時間確保 Claude 在採取任何行動之前，已經掌握了絕對正確的知識、記憶、檔案、規則與狀態。提示詞只是最後 1% 的工作，上下文才是那另外 99%。

一個提示詞完美但上下文貧乏的 Agent，會犯下「聰明」的錯誤。一個提示詞普通但上下文完整的 Agent，則會做出正確的決策。模型是一樣的，資訊環境卻不同。

上下文就是 AI 的作業系統。建構好它，那 8 倍的產出差距就不再只是發生在 Anthropic 的傳說，而是發生在你程式碼庫中的現實。

大多數開發者會繼續重寫他們的提示詞，並納悶為什麼結果沒有改善。而少數人會花一個週末建立一個正確的上下文堆疊，從此回不去舊方法。

你的人生由你自己打造 —— 所以選擇正確的路。

/ 如果這篇文章對你有幫助 —— 請追蹤我 /