--- title: "Claude 5 模型的上下文工程規則" locale: zh-hant category: ai_data category_name: "AI 資料" translation_status: reviewed license: cc_by author: "injoys" source_url: https://injoys.com/en/articles/claude-5-context-engineering-rules published_at: 2026-07-27T05:12:07+09:00 --- # Claude 5 模型的上下文工程規則 > 對判斷能力有所提升的 Claude 模型而言，比起大量細節規則，明確的目的、設計完善的工具，以及符合任務需求的參考資料更為重要。本文說明如何減少重複指示、適時提供必要資訊的上下文設計原則與應用流程。 ## Key Points - 上下文工程不僅涉及提示，還包括整合設計系統指示、工具、記憶、檔案、對話記錄與執行結果。 - 安全、法律、權限與資料完整性規則應嚴格維持，但會因情況而異的風格指示，最好改為依據上下文的原則。 - 與其一開始就放入所有資訊，不如透過搜尋、讀取檔案、Skills 與子代理，在需要時才提供。 - 與其反覆列舉工具使用範例，不如設計具備明確名稱、輸入結構描述、狀態定義與錯誤結構的介面。 - CLAUDE.md、自動記憶、程式碼、測試與規格應分別承擔不同角色，不應在多個位置複製相同指示。 若要有效運用判斷能力有所提升的 Claude 模型，僅僅琢磨一句提示詞並不足夠。必須將模型在單次推理中會看到的系統指示、專案檔案、工具、記憶、對話紀錄與執行結果，設計成一個完整的資訊環境。 核心原則很簡單。 > 與其事先規定所有行為，不如提供明確的目的、安全邊界、具表達力的介面與可靠的參考資料，並將細節判斷交給模型。 本文中的 `Claude 5`，是指所提供資料所稱的下一代高效能 Claude 模型環境。本文不討論具體的產品規格或發布狀態，而是聚焦於可套用至判斷能力有所提升之模型的上下文設計原則。 ## 提示詞工程與上下文工程 ### 提示詞工程 提示詞工程是設計如何表達目前請求的工作。通常會處理以下項目。 - 工作目標 - 執行範圍 - 限制條件 - 輸出格式 - 成功標準 - 必要範例 例如： ```text 在 Next.js API Route 中實作取消付款功能。 重複使用現有服務層並新增測試。 不要變更公開 API 契約，並說明變更理由。 ``` ### 上下文工程 上下文工程是篩選並維護進入模型推理之完整資訊集合的工作。在 Claude Code 這類程式設計代理中，上下文大致由以下要素構成。 ```text 使用者目前的請求 + 系統指示 + CLAUDE.md 與專案指示 + Skills + 自動記憶 + 程式碼、規格、測試、文件 + 工具定義與 MCP 資源 + 對話紀錄 + 工具執行結果與錯誤日誌 ``` 因此，即使是良好的提示詞，若與過時的記憶、重複的專案規則或龐大的日誌一併提供，效果也可能減弱。反之，即使請求簡短，只要同時提供相關程式碼、測試與明確的工具，也能夠相當精準地執行。 | 分類 | 提示詞工程 | 上下文工程 | |---|---|---| | 設計對象 | 目前請求的表達方式 | 進入推理的完整資訊環境 | | 主要問題 | 要請求什麼，以及如何請求 | 要讓模型在何時看到什麼 | | 代表要素 | 目標、格式、限制、範例 | 系統指示、檔案、工具、記憶、紀錄 | | 主要失敗 | 請求模糊、成功標準不明確 | 衝突、重複、過時資訊、過量日誌 | | 改善方法 | 具體化請求並提出驗證標準 | 篩選高訊號資訊、適時搜尋、生命週期管理 | ## 為何上下文並非越多越好 即使 LLM 的上下文視窗擴大，可用於工作的注意力也不是無限的。相關性低的 token 增加時，可能產生以下問題。 1. 重要需求被埋沒在冗長說明中。 2. 不同位置的相似指示發生細微衝突。 3. 過時的決策或失敗嘗試影響目前工作。 4. 範例如同標準答案般發揮作用，限制其他解決路徑。 5. 日誌與工具輸出占用程式碼、規格及測試所需的空間。 6. 模型將推理用於解讀指示的優先順序，而非實際工作。 Anthropic 說明了長上下文中資訊運用效率下降的現象，並建議將代理設計為能適時搜尋所需資訊，且壓縮過時紀錄。重要的不是填滿 token 數量上限，而是提高會影響結果之高訊號 token 的比例。 ## 縮減系統提示詞的案例有何意義 所提供的 Anthropic 案例說明，在檢視 Claude Code 的內部指示後，將系統提示詞縮減了至少 80%。這個數字並不是要求所有應用程式都按相同比例縮減提示詞的規則。應將其理解為針對特定系統，整理重複且過於細節化之行為指示的案例。 例如，以下指示可能同時出現在一個請求中。 ```text 系統指示：視情況留下適當的文件。 Skill 指示：不要新增註解。 使用者請求：讓它像現有版本一樣運作。 ``` 每個句子單獨來看都可能合理，但放在一起時會產生多種解讀問題。 - 文件與程式碼註解屬於同一類別嗎？ - 禁止註解是毫無例外的規則嗎？ - 現有版本的行為也包含註解或文件結構嗎？ - 目前請求與可重複使用的 Skill，哪一方優先？ 此時失敗的原因不只是模型的程式設計能力。人為建構的資訊環境包含不必要的矛盾，也是原因之一。 ## 六項新的上下文設計規則 | 過去做法 | 建議做法 | |---|---| | 以禁止清單規定細節行為 | 提出目標與判斷標準，並善用上下文 | | 提供大量工具呼叫範例 | 將結構描述本身設計成可說明用法 | | 在工作開始時注入所有資訊 | 在需要的時機逐步揭露 | | 在多個位置重複相同指示 | 為每項指示指定一個權威儲存位置 | | 連暫時記憶也儲存在 CLAUDE.md | 區分永久政策與自動記憶的角色 | | 依賴冗長的 Markdown 說明 | 提供程式碼、測試、HTML、評分表等可執行資料 | ### 1. 將細節禁止清單改為以脈絡為基礎的原則 為了防止過去模型反覆犯錯，有時會冗長地列出下列規則。 - 不撰寫註解。 - 不建立包含多個段落的 docstring。 - 不建立未經請求的計畫文件。 - 不儲存中間分析檔案。 這類規則雖能防止特定失敗，卻不是適用於所有情況的絕對原則。複雜的安全驗證或並行程式碼可能需要說明，而一目了然的 CRUD 程式碼中，註解反而可能造成雜訊。 較好的方式是提供如下判斷標準。 ```text 撰寫方式與周邊程式碼一致、易於閱讀的程式碼。 遵循現有檔案的命名規則、慣用表達與註解密度。 僅在缺少說明便無法釐清安全性或意圖的邏輯中，新增必要文件。 ``` 但不應將所有規則都弱化。以下項目應繼續維持明確限制，或以工具層級進行管控。 - 正式環境部署與資料刪除核准 - 個人資料與機密資訊的處理限制 - 身分驗證與授權驗證 - 金錢交易的冪等性與稽核紀錄 - 資料庫遷移政策 - 法律、授權條款與法規遵循 - 不得變更的公開 API 契約 | 規則類型 | 適當的處理方式 | |---|---| | 安全、法律、權限 | 維持明確且強制的限制 | | 可能造成資料遺失的工作 | 透過核准流程與工具權限管控 | | 公開契約、相容性 | 透過測試與結構描述驗證 | | 程式碼風格、註解 | 使用依據周邊程式碼判斷的原則 | | 暫時性工作順序 | 在目前計畫或工作清單中管理 | ### 2. 與其提供大量範例，不如設計具表達力的工具 若持續在工具說明中新增正常與異常的呼叫案例，上下文會持續增大，模型也可能模仿範例的表面形式。更好的做法，是讓工具名稱、輸入欄位與狀態轉換本身就能呈現使用方式。 ```text TodoWrite 目的：建立及更新目前工作階段的工作清單 status: - pending - in_progress - completed 限制： - 同時只能有一項工作處於 in_progress ``` 良好的代理工具具備以下特性。 - 僅從名稱即可看出行為與對象。 - 必填欄位與選填欄位有所區分。 - 以列舉限制允許的值。 - 區分讀取與寫入、預覽與執行。 - 錯誤以結構化形式回傳原因與復原方式。 - 危險工作要求確認 token 或核准步驟。 - 結果過長時提供摘要與分頁瀏覽功能。 範例最好只在說明難以透過介面表達的例外或模糊輸入時加入。 ### 3. 不要一開始就放入所有資訊，而應逐步揭露 不應只因代理可能需要某些資訊，就從一開始注入整個儲存庫、所有政策與冗長日誌。先提供探索所需的最少資訊，待工作具體化時，再讓模型讀取相關資料。 建議流程如下。 1. 提供目標、成功標準與安全邊界。 2. 透過儲存庫結構或搜尋工具找出相關位置。 3. 僅讀取必要的檔案與規格。 4. 實作後執行相關測試與靜態分析。 5. 若失敗，僅額外取得該錯誤與周邊程式碼。 6. 完成後壓縮或移除過時日誌與中間推理。 逐步揭露並不是隱藏資訊，而是提供搜尋路徑與明確的檔案結構，讓模型能夠發現所需資訊。 ### 4. 移除重複指示並指定權威位置 若將同一規則複製到系統提示詞、CLAUDE.md、Skill 與工具說明中，隨著時間推移，內容措辭可能出現差異。應依指示類型指定一個權威儲存位置。 | 資訊 | 建議位置 | |---|---| | 整個組織的安全政策 | 系統指示或權限層級 | | 儲存庫的建置與測試命令 | 專案 CLAUDE.md | | 特定工作流程 | 對應的 Skill | | 工具輸入與限制 | 工具結構描述與說明 | | 公開 API 行為 | 程式碼結構描述、規格與契約測試 | | 目前工作階段的進度 | 工作清單或工作階段狀態 | 若無法避免重複，與其複製內容，不如指向權威位置或採用自動產生的方式，會更加安全。 ### 5. 區分 CLAUDE.md 與自動記憶的角色 CLAUDE.md 適合存放可供專案成員檢閱並納入版本控制的持續性指示。 - 標準建置與測試命令 - 儲存庫結構的核心說明 - 團隊協議的禁止變更區域 - 專案特有的驗證流程 - 難以透過一般工具推理得出的規則 相較之下，以下資訊更適合放在自動記憶或工作階段狀態中。 - 從重複工作中發現的個人化偏好 - 最近工作中有用的探索路徑 - 暫時性的開發環境特性 - 目前工作階段的進度 不應假設自動記憶永遠正確或永久有效。必須能夠修改或移除過時項目，也不應將其作為安全政策與公開契約的唯一儲存庫。 ### 6. 優先使用可執行的參考資料，而非說明文件 自然語言規格有助於說明意圖，但可能無法完整表達實際行為。在可能的情況下，一併提供以下資料。 - 與目前程式碼相似的現有實作 - 單元測試與整合測試 - API 結構描述與型別定義 - 實際 HTML 或設計產出 - 資料庫遷移檔案 - 輸入與輸出範例資料 - 評分表與自動評分標準 參考資料之間也可能發生衝突，因此應明確指定優先順序。例如，可將契約測試指定為公開 API 的權威標準，而 README 則作為說明資料。 ## 實務用上下文組成範本 以下結構是精簡整理程式設計工作所需資訊的範例。 ```text 目標 - 新增取消付款 API。 成功標準 - 重複使用現有付款服務層。 - 即使有重複請求，也只取消一次。 - 相關契約測試通過。 強制限制 - 不變更公開回應結構描述。 - 不存取正式環境資料。 參考資料 - src/payments/capture.ts - tests/contracts/payment-cancel.test.ts - openapi/payments.yaml 判斷原則 - 遵循周邊付款程式碼的錯誤處理與命名規則。 - 若存在不安全的假設，在實作前先提問。 驗證 - 目標單元測試 - 契約測試 - 型別檢查 ``` 這種格式不會事先列出所有情況，而是將目標、成功條件、不變邊界、權威資料與驗證方法分開。 ## 整理現有上下文的流程 ### 第 1 步：列出所有指示的來源 一併確認系統提示詞、CLAUDE.md、Skills、自動記憶、工具說明與 CI 設定。若只檢視一份文件，很難發現實際衝突。 ### 第 2 步：為每項指示加上分類標籤 - 安全或法律上的必要事項 - 產品契約上的必要事項 - 團隊的持續性慣例 - 僅特定工具所需的說明 - 為防止過去模型犯錯而制定的暫時規則 - 目前依據不明確的規則 ### 第 3 步：尋找重複與衝突 將以不同方式表達相同行為的句子歸為一組。尤其應優先檢視 `一律`、`絕對`、`必須`、`不要` 等表達方式。 ### 第 4 步：將規則轉移至測試或權限 相較於自然語言警告，適合以自動驗證確保落實的項目，應移至以下層級。 - 測試與 linter - 型別系統與結構描述 - 最小權限工具 - 核准流程 - 沙箱 - CI 政策 ### 第 5 步：以實際工作進行評估 不能只衡量提示詞長度。應在代表性工作集合中比較以下指標。 - 成功率與測試通過率 - 不必要的檔案變更數量 - 使用者修改次數 - 工具呼叫失敗率 - 完成所需的時間與 token - 是否違反安全政策 ### 第 6 步：只針對失敗原因進行最低限度補強 發生失敗時，不要立刻新增禁止規則。應先區分原因究竟是目標模糊、參考資料不足，還是工具結構描述錯誤。 ## 不應刪除的指示 精簡並不代表無條件刪除。若以下任一問題的答案為 `是`，就應保留該指示，或將其轉移至更強力的管控機制。 - 違反時是否會造成資料遺失或金錢損失？ - 是否涉及法律、個人資料或授權義務？ - 是否為模型僅查看程式碼時無法得知的組織政策？ - 是否決定公開 API 或資料格式的相容性？ - 是否需要在執行工作前取得人工核准？ - 是否難以僅透過自動測試完整偵測違規？ ## 常見失敗模式 ### 每次失敗後都新增規則 若將一次錯誤泛化成永久規則，例外與衝突就會持續累積。應先新增評估案例，確認是否為重複發生的失敗。 ### 將冗長範例實際當成範本使用 若範例過於具體，模型可能會優先遵循範例，而不是目前的程式碼庫。範例應限制為足以說明原則的最小規模。 ### 原封不動地保留完整日誌 工具輸出與建置日誌會迅速占滿上下文。最好只以結構化方式保留失敗原因、相關堆疊與變更後的狀態。 ### 將自動記憶作為政策儲存庫 自動記憶雖然方便，但其檢閱、部署與稽核機制可能較弱。組織的強制政策應保存在納入版本控制的指示或權限層級中。 ### 只以節省 token 評估上下文縮減 較短的上下文不一定更好。若移除必要測試、安全規則或規格，結果反而會惡化。目標不是 token 最少，而是最低限度的高訊號 token。 ## 最終檢查表 - 目前請求的目標與成功標準是否分開？ - 安全規則與風格偏好是否有所區分？ - 相同指示是否未在多個位置重複？ - 工具結構描述是否無須冗長範例也能說明用法？ - 是否能在需要時搜尋相關檔案？ - 是否有方法移除過時記憶與執行日誌？ - 是否能以測試或權限強制執行自然語言規則？ - 參考資料之間的優先順序是否明確？ - 是否有可比較指示變更前後結果的評估工作？ ## 結論 針對高效能 Claude 模型的上下文工程，並不是無條件縮減指示的技術。它是一種資訊設計：清楚呈現模型判斷目前工作所需的目的、安全邊界與依據，並移除無關資訊及相互衝突的規則。 最實用的原則可概括如下。 > 強制落實安全與契約，將風格交由脈絡判斷，在需要的時機提供資訊，並以可執行的測試驗證結果。 ## FAQ ### 提示詞工程與上下文工程有何不同？ 提示詞工程處理如何表達目前請求的目標、格式與限制。上下文工程則設計何時要向模型顯示哪些內容，包括該提示詞，以及系統指示、檔案、工具、記憶、對話紀錄與執行結果。 ### 上下文越長，模型的效能就一定越好嗎？ 並非如此。較長的上下文中可能混雜不相關的資訊、過時的紀錄與相互衝突的指示。重要的不是整體 token 數量，而是能直接幫助目前工作的高訊號資訊比例。 ### 需要為 Claude 5 刪除所有現有規則嗎？ 不需要。像程式碼風格或註解這類會依情況而異的細微規則，可以改為判斷原則，但與安全、個人資料、權限、金錢交易、資料刪除及公開 API 契約有關的限制，則應予以保留，或透過工具與測試進行更嚴格的控管。 ### CLAUDE.md 中適合放入哪些內容？ 適合放入持續有效且可供審查的指示，例如專案的建置與測試命令、儲存庫結構、禁止變更的區域，以及團隊達成共識的驗證程序。若將暫時性的進度或個人化的發現全都儲存下來，文件可能很快就會過時。 ### 自動記憶可以取代 CLAUDE.md 嗎？ 無法完全取代。自動記憶有助於保留在重複工作中發現的偏好或探索資訊，但像安全政策與公開契約這類需要稽核與版本管理的指示，則應放在 CLAUDE.md 或獨立的政策層中。 ### 良好的代理工具介面具備哪些特徵？ 應僅從工具名稱與輸入結構描述就能看出用途，且必填值與允許的狀態都必須明確。危險的寫入操作應要求預覽或核准，而錯誤最好能以結構化方式回傳原因與復原方法。 ### 漸進式揭露是指對模型隱藏資訊嗎？ 不是。一開始先提供目標與探索路徑，並讓模型隨著工作逐步具體化，搜尋所需的檔案、規格與日誌。其目的在於維持資訊的可存取性，同時減少不必要的預先注入。 ### 縮減上下文後，要如何評估效果？ 應在一組具代表性的工作上，比較變更前後的測試通過率、使用者修改次數、不必要的變更、工具錯誤、token 使用量，以及是否違反安全政策。不應僅憑提示詞長度減少就判定成功。 ### 可以完全不提供工具使用範例嗎？ 範例並非總是不必要。當存在僅靠結構描述難以表達的邊界案例或模糊輸入時，最少量的範例會很有幫助。但比起重複列出一般呼叫方式，應優先讓介面本身清楚明確。 ## Sources - [AI 代理的有效情境工程](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) - [建立有效的代理](https://www.anthropic.com/engineering/building-effective-agents) - [提示詞工程概述](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview) - [Claude Code 記憶文件](https://docs.anthropic.com/en/docs/claude-code/memory) ## Images ![文件與資料圖示經漏斗匯入中央AI網路](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzMzMywicHVyIjoiYmxvYl9pZCJ9fQ==--b6a9225f1d5837dd6ca93532a1e1a3388a1cc4fc/ai-e5c0c894.webp) ![機器人依序經過搜尋、檔案、工具、程式碼、驗證與報告並朝目標前進的 AI 工作流程](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzMzOSwicHVyIjoiYmxvYl9pZCJ9fQ==--c5e1421a425951ca760407e2d7b6c78654f545e5/ai-8b2296c2.webp)