{"content_id":"yihyxok0ch","slug":"claude-5-context-engineering-rules","locale":"zh-hant","schema_type":"TechArticle","category":"ai_data","category_name":"AI 資料","title":"Claude 5 模型的上下文工程規則","summary":"對判斷能力有所提升的 Claude 模型而言，比起大量細節規則，明確的目的、設計完善的工具，以及符合任務需求的參考資料更為重要。本文說明如何減少重複指示、適時提供必要資訊的上下文設計原則與應用流程。","author":{"name":"injoys","url":"https://injoys.com/ko/about"},"key_points":["上下文工程不僅涉及提示，還包括整合設計系統指示、工具、記憶、檔案、對話記錄與執行結果。","安全、法律、權限與資料完整性規則應嚴格維持，但會因情況而異的風格指示，最好改為依據上下文的原則。","與其一開始就放入所有資訊，不如透過搜尋、讀取檔案、Skills 與子代理，在需要時才提供。","與其反覆列舉工具使用範例，不如設計具備明確名稱、輸入結構描述、狀態定義與錯誤結構的介面。","CLAUDE.md、自動記憶、程式碼、測試與規格應分別承擔不同角色，不應在多個位置複製相同指示。"],"content_markdown":"若要有效運用判斷能力有所提升的 Claude 模型，僅僅琢磨一句提示詞並不足夠。必須將模型在單次推理中會看到的系統指示、專案檔案、工具、記憶、對話紀錄與執行結果，設計成一個完整的資訊環境。\n\n核心原則很簡單。\n\n\u003e 與其事先規定所有行為，不如提供明確的目的、安全邊界、具表達力的介面與可靠的參考資料，並將細節判斷交給模型。\n\n本文中的 `Claude 5`，是指所提供資料所稱的下一代高效能 Claude 模型環境。本文不討論具體的產品規格或發布狀態，而是聚焦於可套用至判斷能力有所提升之模型的上下文設計原則。\n\n## 提示詞工程與上下文工程\n\n### 提示詞工程\n\n提示詞工程是設計如何表達目前請求的工作。通常會處理以下項目。\n\n- 工作目標\n- 執行範圍\n- 限制條件\n- 輸出格式\n- 成功標準\n- 必要範例\n\n例如：\n\n```text\n在 Next.js API Route 中實作取消付款功能。\n重複使用現有服務層並新增測試。\n不要變更公開 API 契約，並說明變更理由。\n```\n\n### 上下文工程\n\n上下文工程是篩選並維護進入模型推理之完整資訊集合的工作。在 Claude Code 這類程式設計代理中，上下文大致由以下要素構成。\n\n```text\n使用者目前的請求\n+ 系統指示\n+ CLAUDE.md 與專案指示\n+ Skills\n+ 自動記憶\n+ 程式碼、規格、測試、文件\n+ 工具定義與 MCP 資源\n+ 對話紀錄\n+ 工具執行結果與錯誤日誌\n```\n\n因此，即使是良好的提示詞，若與過時的記憶、重複的專案規則或龐大的日誌一併提供，效果也可能減弱。反之，即使請求簡短，只要同時提供相關程式碼、測試與明確的工具，也能夠相當精準地執行。\n\n| 分類 | 提示詞工程 | 上下文工程 |\n|---|---|---|\n| 設計對象 | 目前請求的表達方式 | 進入推理的完整資訊環境 |\n| 主要問題 | 要請求什麼，以及如何請求 | 要讓模型在何時看到什麼 |\n| 代表要素 | 目標、格式、限制、範例 | 系統指示、檔案、工具、記憶、紀錄 |\n| 主要失敗 | 請求模糊、成功標準不明確 | 衝突、重複、過時資訊、過量日誌 |\n| 改善方法 | 具體化請求並提出驗證標準 | 篩選高訊號資訊、適時搜尋、生命週期管理 |\n\n## 為何上下文並非越多越好\n\n即使 LLM 的上下文視窗擴大，可用於工作的注意力也不是無限的。相關性低的 token 增加時，可能產生以下問題。\n\n1. 重要需求被埋沒在冗長說明中。\n2. 不同位置的相似指示發生細微衝突。\n3. 過時的決策或失敗嘗試影響目前工作。\n4. 範例如同標準答案般發揮作用，限制其他解決路徑。\n5. 日誌與工具輸出占用程式碼、規格及測試所需的空間。\n6. 模型將推理用於解讀指示的優先順序，而非實際工作。\n\nAnthropic 說明了長上下文中資訊運用效率下降的現象，並建議將代理設計為能適時搜尋所需資訊，且壓縮過時紀錄。重要的不是填滿 token 數量上限，而是提高會影響結果之高訊號 token 的比例。\n\n## 縮減系統提示詞的案例有何意義\n\n所提供的 Anthropic 案例說明，在檢視 Claude Code 的內部指示後，將系統提示詞縮減了至少 80%。這個數字並不是要求所有應用程式都按相同比例縮減提示詞的規則。應將其理解為針對特定系統，整理重複且過於細節化之行為指示的案例。\n\n例如，以下指示可能同時出現在一個請求中。\n\n```text\n系統指示：視情況留下適當的文件。\nSkill 指示：不要新增註解。\n使用者請求：讓它像現有版本一樣運作。\n```\n\n每個句子單獨來看都可能合理，但放在一起時會產生多種解讀問題。\n\n- 文件與程式碼註解屬於同一類別嗎？\n- 禁止註解是毫無例外的規則嗎？\n- 現有版本的行為也包含註解或文件結構嗎？\n- 目前請求與可重複使用的 Skill，哪一方優先？\n\n此時失敗的原因不只是模型的程式設計能力。人為建構的資訊環境包含不必要的矛盾，也是原因之一。\n\n## 六項新的上下文設計規則\n\n| 過去做法 | 建議做法 |\n|---|---|\n| 以禁止清單規定細節行為 | 提出目標與判斷標準，並善用上下文 |\n| 提供大量工具呼叫範例 | 將結構描述本身設計成可說明用法 |\n| 在工作開始時注入所有資訊 | 在需要的時機逐步揭露 |\n| 在多個位置重複相同指示 | 為每項指示指定一個權威儲存位置 |\n| 連暫時記憶也儲存在 CLAUDE.md | 區分永久政策與自動記憶的角色 |\n| 依賴冗長的 Markdown 說明 | 提供程式碼、測試、HTML、評分表等可執行資料 |\n\n### 1. 將細節禁止清單改為以脈絡為基礎的原則\n\n為了防止過去模型反覆犯錯，有時會冗長地列出下列規則。\n\n- 不撰寫註解。\n- 不建立包含多個段落的 docstring。\n- 不建立未經請求的計畫文件。\n- 不儲存中間分析檔案。\n\n這類規則雖能防止特定失敗，卻不是適用於所有情況的絕對原則。複雜的安全驗證或並行程式碼可能需要說明，而一目了然的 CRUD 程式碼中，註解反而可能造成雜訊。\n\n較好的方式是提供如下判斷標準。\n\n```text\n撰寫方式與周邊程式碼一致、易於閱讀的程式碼。\n遵循現有檔案的命名規則、慣用表達與註解密度。\n僅在缺少說明便無法釐清安全性或意圖的邏輯中，新增必要文件。\n```\n\n但不應將所有規則都弱化。以下項目應繼續維持明確限制，或以工具層級進行管控。\n\n- 正式環境部署與資料刪除核准\n- 個人資料與機密資訊的處理限制\n- 身分驗證與授權驗證\n- 金錢交易的冪等性與稽核紀錄\n- 資料庫遷移政策\n- 法律、授權條款與法規遵循\n- 不得變更的公開 API 契約\n\n| 規則類型 | 適當的處理方式 |\n|---|---|\n| 安全、法律、權限 | 維持明確且強制的限制 |\n| 可能造成資料遺失的工作 | 透過核准流程與工具權限管控 |\n| 公開契約、相容性 | 透過測試與結構描述驗證 |\n| 程式碼風格、註解 | 使用依據周邊程式碼判斷的原則 |\n| 暫時性工作順序 | 在目前計畫或工作清單中管理 |\n\n### 2. 與其提供大量範例，不如設計具表達力的工具\n\n若持續在工具說明中新增正常與異常的呼叫案例，上下文會持續增大，模型也可能模仿範例的表面形式。更好的做法，是讓工具名稱、輸入欄位與狀態轉換本身就能呈現使用方式。\n\n```text\nTodoWrite\n目的：建立及更新目前工作階段的工作清單\n\nstatus:\n- pending\n- in_progress\n- completed\n\n限制：\n- 同時只能有一項工作處於 in_progress\n```\n\n良好的代理工具具備以下特性。\n\n- 僅從名稱即可看出行為與對象。\n- 必填欄位與選填欄位有所區分。\n- 以列舉限制允許的值。\n- 區分讀取與寫入、預覽與執行。\n- 錯誤以結構化形式回傳原因與復原方式。\n- 危險工作要求確認 token 或核准步驟。\n- 結果過長時提供摘要與分頁瀏覽功能。\n\n範例最好只在說明難以透過介面表達的例外或模糊輸入時加入。\n\n### 3. 不要一開始就放入所有資訊，而應逐步揭露\n\n不應只因代理可能需要某些資訊，就從一開始注入整個儲存庫、所有政策與冗長日誌。先提供探索所需的最少資訊，待工作具體化時，再讓模型讀取相關資料。\n\n建議流程如下。\n\n1. 提供目標、成功標準與安全邊界。\n2. 透過儲存庫結構或搜尋工具找出相關位置。\n3. 僅讀取必要的檔案與規格。\n4. 實作後執行相關測試與靜態分析。\n5. 若失敗，僅額外取得該錯誤與周邊程式碼。\n6. 完成後壓縮或移除過時日誌與中間推理。\n\n逐步揭露並不是隱藏資訊，而是提供搜尋路徑與明確的檔案結構，讓模型能夠發現所需資訊。\n\n### 4. 移除重複指示並指定權威位置\n\n若將同一規則複製到系統提示詞、CLAUDE.md、Skill 與工具說明中，隨著時間推移，內容措辭可能出現差異。應依指示類型指定一個權威儲存位置。\n\n| 資訊 | 建議位置 |\n|---|---|\n| 整個組織的安全政策 | 系統指示或權限層級 |\n| 儲存庫的建置與測試命令 | 專案 CLAUDE.md |\n| 特定工作流程 | 對應的 Skill |\n| 工具輸入與限制 | 工具結構描述與說明 |\n| 公開 API 行為 | 程式碼結構描述、規格與契約測試 |\n| 目前工作階段的進度 | 工作清單或工作階段狀態 |\n\n若無法避免重複，與其複製內容，不如指向權威位置或採用自動產生的方式，會更加安全。\n\n### 5. 區分 CLAUDE.md 與自動記憶的角色\n\nCLAUDE.md 適合存放可供專案成員檢閱並納入版本控制的持續性指示。\n\n- 標準建置與測試命令\n- 儲存庫結構的核心說明\n- 團隊協議的禁止變更區域\n- 專案特有的驗證流程\n- 難以透過一般工具推理得出的規則\n\n相較之下，以下資訊更適合放在自動記憶或工作階段狀態中。\n\n- 從重複工作中發現的個人化偏好\n- 最近工作中有用的探索路徑\n- 暫時性的開發環境特性\n- 目前工作階段的進度\n\n不應假設自動記憶永遠正確或永久有效。必須能夠修改或移除過時項目，也不應將其作為安全政策與公開契約的唯一儲存庫。\n\n### 6. 優先使用可執行的參考資料，而非說明文件\n\n自然語言規格有助於說明意圖，但可能無法完整表達實際行為。在可能的情況下，一併提供以下資料。\n\n- 與目前程式碼相似的現有實作\n- 單元測試與整合測試\n- API 結構描述與型別定義\n- 實際 HTML 或設計產出\n- 資料庫遷移檔案\n- 輸入與輸出範例資料\n- 評分表與自動評分標準\n\n參考資料之間也可能發生衝突，因此應明確指定優先順序。例如，可將契約測試指定為公開 API 的權威標準，而 README 則作為說明資料。\n\n## 實務用上下文組成範本\n\n以下結構是精簡整理程式設計工作所需資訊的範例。\n\n```text\n目標\n- 新增取消付款 API。\n\n成功標準\n- 重複使用現有付款服務層。\n- 即使有重複請求，也只取消一次。\n- 相關契約測試通過。\n\n強制限制\n- 不變更公開回應結構描述。\n- 不存取正式環境資料。\n\n參考資料\n- src/payments/capture.ts\n- tests/contracts/payment-cancel.test.ts\n- openapi/payments.yaml\n\n判斷原則\n- 遵循周邊付款程式碼的錯誤處理與命名規則。\n- 若存在不安全的假設，在實作前先提問。\n\n驗證\n- 目標單元測試\n- 契約測試\n- 型別檢查\n```\n\n這種格式不會事先列出所有情況，而是將目標、成功條件、不變邊界、權威資料與驗證方法分開。\n\n## 整理現有上下文的流程\n\n### 第 1 步：列出所有指示的來源\n\n一併確認系統提示詞、CLAUDE.md、Skills、自動記憶、工具說明與 CI 設定。若只檢視一份文件，很難發現實際衝突。\n\n### 第 2 步：為每項指示加上分類標籤\n\n- 安全或法律上的必要事項\n- 產品契約上的必要事項\n- 團隊的持續性慣例\n- 僅特定工具所需的說明\n- 為防止過去模型犯錯而制定的暫時規則\n- 目前依據不明確的規則\n\n### 第 3 步：尋找重複與衝突\n\n將以不同方式表達相同行為的句子歸為一組。尤其應優先檢視 `一律`、`絕對`、`必須`、`不要` 等表達方式。\n\n### 第 4 步：將規則轉移至測試或權限\n\n相較於自然語言警告，適合以自動驗證確保落實的項目，應移至以下層級。\n\n- 測試與 linter\n- 型別系統與結構描述\n- 最小權限工具\n- 核准流程\n- 沙箱\n- CI 政策\n\n### 第 5 步：以實際工作進行評估\n\n不能只衡量提示詞長度。應在代表性工作集合中比較以下指標。\n\n- 成功率與測試通過率\n- 不必要的檔案變更數量\n- 使用者修改次數\n- 工具呼叫失敗率\n- 完成所需的時間與 token\n- 是否違反安全政策\n\n### 第 6 步：只針對失敗原因進行最低限度補強\n\n發生失敗時，不要立刻新增禁止規則。應先區分原因究竟是目標模糊、參考資料不足，還是工具結構描述錯誤。\n\n## 不應刪除的指示\n\n精簡並不代表無條件刪除。若以下任一問題的答案為 `是`，就應保留該指示，或將其轉移至更強力的管控機制。\n\n- 違反時是否會造成資料遺失或金錢損失？\n- 是否涉及法律、個人資料或授權義務？\n- 是否為模型僅查看程式碼時無法得知的組織政策？\n- 是否決定公開 API 或資料格式的相容性？\n- 是否需要在執行工作前取得人工核准？\n- 是否難以僅透過自動測試完整偵測違規？\n\n## 常見失敗模式\n\n### 每次失敗後都新增規則\n\n若將一次錯誤泛化成永久規則，例外與衝突就會持續累積。應先新增評估案例，確認是否為重複發生的失敗。\n\n### 將冗長範例實際當成範本使用\n\n若範例過於具體，模型可能會優先遵循範例，而不是目前的程式碼庫。範例應限制為足以說明原則的最小規模。\n\n### 原封不動地保留完整日誌\n\n工具輸出與建置日誌會迅速占滿上下文。最好只以結構化方式保留失敗原因、相關堆疊與變更後的狀態。\n\n### 將自動記憶作為政策儲存庫\n\n自動記憶雖然方便，但其檢閱、部署與稽核機制可能較弱。組織的強制政策應保存在納入版本控制的指示或權限層級中。\n\n### 只以節省 token 評估上下文縮減\n\n較短的上下文不一定更好。若移除必要測試、安全規則或規格，結果反而會惡化。目標不是 token 最少，而是最低限度的高訊號 token。\n\n## 最終檢查表\n\n- 目前請求的目標與成功標準是否分開？\n- 安全規則與風格偏好是否有所區分？\n- 相同指示是否未在多個位置重複？\n- 工具結構描述是否無須冗長範例也能說明用法？\n- 是否能在需要時搜尋相關檔案？\n- 是否有方法移除過時記憶與執行日誌？\n- 是否能以測試或權限強制執行自然語言規則？\n- 參考資料之間的優先順序是否明確？\n- 是否有可比較指示變更前後結果的評估工作？\n\n## 結論\n\n針對高效能 Claude 模型的上下文工程，並不是無條件縮減指示的技術。它是一種資訊設計：清楚呈現模型判斷目前工作所需的目的、安全邊界與依據，並移除無關資訊及相互衝突的規則。\n\n最實用的原則可概括如下。\n\n\u003e 強制落實安全與契約，將風格交由脈絡判斷，在需要的時機提供資訊，並以可執行的測試驗證結果。","content_html":"\u003cp\u003e若要有效運用判斷能力有所提升的 Claude 模型，僅僅琢磨一句提示詞並不足夠。必須將模型在單次推理中會看到的系統指示、專案檔案、工具、記憶、對話紀錄與執行結果，設計成一個完整的資訊環境。\u003c/p\u003e\n\u003cp\u003e核心原則很簡單。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e與其事先規定所有行為，不如提供明確的目的、安全邊界、具表達力的介面與可靠的參考資料，並將細節判斷交給模型。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e本文中的 \u003ccode\u003eClaude 5\u003c/code\u003e，是指所提供資料所稱的下一代高效能 Claude 模型環境。本文不討論具體的產品規格或發布狀態，而是聚焦於可套用至判斷能力有所提升之模型的上下文設計原則。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E6%8F%90%E7%A4%BA%E8%A9%9E%E5%B7%A5%E7%A8%8B%E8%88%87%E4%B8%8A%E4%B8%8B%E6%96%87%E5%B7%A5%E7%A8%8B\" class=\"anchor\" id=\"提示詞工程與上下文工程\"\u003e\u003c/a\u003e提示詞工程與上下文工程\u003c/h2\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E6%8F%90%E7%A4%BA%E8%A9%9E%E5%B7%A5%E7%A8%8B\" class=\"anchor\" id=\"提示詞工程\"\u003e\u003c/a\u003e提示詞工程\u003c/h3\u003e\n\u003cp\u003e提示詞工程是設計如何表達目前請求的工作。通常會處理以下項目。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e工作目標\u003c/li\u003e\n\u003cli\u003e執行範圍\u003c/li\u003e\n\u003cli\u003e限制條件\u003c/li\u003e\n\u003cli\u003e輸出格式\u003c/li\u003e\n\u003cli\u003e成功標準\u003c/li\u003e\n\u003cli\u003e必要範例\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e例如：\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e在 Next.js API Route 中實作取消付款功能。\n\u003c/span\u003e\u003cspan\u003e重複使用現有服務層並新增測試。\n\u003c/span\u003e\u003cspan\u003e不要變更公開 API 契約，並說明變更理由。\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E4%B8%8A%E4%B8%8B%E6%96%87%E5%B7%A5%E7%A8%8B\" class=\"anchor\" id=\"上下文工程\"\u003e\u003c/a\u003e上下文工程\u003c/h3\u003e\n\u003cp\u003e上下文工程是篩選並維護進入模型推理之完整資訊集合的工作。在 Claude Code 這類程式設計代理中，上下文大致由以下要素構成。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e使用者目前的請求\n\u003c/span\u003e\u003cspan\u003e+ 系統指示\n\u003c/span\u003e\u003cspan\u003e+ CLAUDE.md 與專案指示\n\u003c/span\u003e\u003cspan\u003e+ Skills\n\u003c/span\u003e\u003cspan\u003e+ 自動記憶\n\u003c/span\u003e\u003cspan\u003e+ 程式碼、規格、測試、文件\n\u003c/span\u003e\u003cspan\u003e+ 工具定義與 MCP 資源\n\u003c/span\u003e\u003cspan\u003e+ 對話紀錄\n\u003c/span\u003e\u003cspan\u003e+ 工具執行結果與錯誤日誌\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e因此，即使是良好的提示詞，若與過時的記憶、重複的專案規則或龐大的日誌一併提供，效果也可能減弱。反之，即使請求簡短，只要同時提供相關程式碼、測試與明確的工具，也能夠相當精準地執行。\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e分類\u003c/th\u003e\n\u003cth\u003e提示詞工程\u003c/th\u003e\n\u003cth\u003e上下文工程\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"分類\"\u003e設計對象\u003c/td\u003e\n\u003ctd data-label=\"提示詞工程\"\u003e目前請求的表達方式\u003c/td\u003e\n\u003ctd data-label=\"上下文工程\"\u003e進入推理的完整資訊環境\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"分類\"\u003e主要問題\u003c/td\u003e\n\u003ctd data-label=\"提示詞工程\"\u003e要請求什麼，以及如何請求\u003c/td\u003e\n\u003ctd data-label=\"上下文工程\"\u003e要讓模型在何時看到什麼\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"分類\"\u003e代表要素\u003c/td\u003e\n\u003ctd data-label=\"提示詞工程\"\u003e目標、格式、限制、範例\u003c/td\u003e\n\u003ctd data-label=\"上下文工程\"\u003e系統指示、檔案、工具、記憶、紀錄\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"分類\"\u003e主要失敗\u003c/td\u003e\n\u003ctd data-label=\"提示詞工程\"\u003e請求模糊、成功標準不明確\u003c/td\u003e\n\u003ctd data-label=\"上下文工程\"\u003e衝突、重複、過時資訊、過量日誌\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"分類\"\u003e改善方法\u003c/td\u003e\n\u003ctd data-label=\"提示詞工程\"\u003e具體化請求並提出驗證標準\u003c/td\u003e\n\u003ctd data-label=\"上下文工程\"\u003e篩選高訊號資訊、適時搜尋、生命週期管理\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E7%82%BA%E4%BD%95%E4%B8%8A%E4%B8%8B%E6%96%87%E4%B8%A6%E9%9D%9E%E8%B6%8A%E5%A4%9A%E8%B6%8A%E5%A5%BD\" class=\"anchor\" id=\"為何上下文並非越多越好\"\u003e\u003c/a\u003e為何上下文並非越多越好\u003c/h2\u003e\n\u003cp\u003e即使 LLM 的上下文視窗擴大，可用於工作的注意力也不是無限的。相關性低的 token 增加時，可能產生以下問題。\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e重要需求被埋沒在冗長說明中。\u003c/li\u003e\n\u003cli\u003e不同位置的相似指示發生細微衝突。\u003c/li\u003e\n\u003cli\u003e過時的決策或失敗嘗試影響目前工作。\u003c/li\u003e\n\u003cli\u003e範例如同標準答案般發揮作用，限制其他解決路徑。\u003c/li\u003e\n\u003cli\u003e日誌與工具輸出占用程式碼、規格及測試所需的空間。\u003c/li\u003e\n\u003cli\u003e模型將推理用於解讀指示的優先順序，而非實際工作。\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eAnthropic 說明了長上下文中資訊運用效率下降的現象，並建議將代理設計為能適時搜尋所需資訊，且壓縮過時紀錄。重要的不是填滿 token 數量上限，而是提高會影響結果之高訊號 token 的比例。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E7%B8%AE%E6%B8%9B%E7%B3%BB%E7%B5%B1%E6%8F%90%E7%A4%BA%E8%A9%9E%E7%9A%84%E6%A1%88%E4%BE%8B%E6%9C%89%E4%BD%95%E6%84%8F%E7%BE%A9\" class=\"anchor\" id=\"縮減系統提示詞的案例有何意義\"\u003e\u003c/a\u003e縮減系統提示詞的案例有何意義\u003c/h2\u003e\n\u003cp\u003e所提供的 Anthropic 案例說明，在檢視 Claude Code 的內部指示後，將系統提示詞縮減了至少 80%。這個數字並不是要求所有應用程式都按相同比例縮減提示詞的規則。應將其理解為針對特定系統，整理重複且過於細節化之行為指示的案例。\u003c/p\u003e\n\u003cp\u003e例如，以下指示可能同時出現在一個請求中。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e系統指示：視情況留下適當的文件。\n\u003c/span\u003e\u003cspan\u003eSkill 指示：不要新增註解。\n\u003c/span\u003e\u003cspan\u003e使用者請求：讓它像現有版本一樣運作。\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e每個句子單獨來看都可能合理，但放在一起時會產生多種解讀問題。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e文件與程式碼註解屬於同一類別嗎？\u003c/li\u003e\n\u003cli\u003e禁止註解是毫無例外的規則嗎？\u003c/li\u003e\n\u003cli\u003e現有版本的行為也包含註解或文件結構嗎？\u003c/li\u003e\n\u003cli\u003e目前請求與可重複使用的 Skill，哪一方優先？\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e此時失敗的原因不只是模型的程式設計能力。人為建構的資訊環境包含不必要的矛盾，也是原因之一。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E5%85%AD%E9%A0%85%E6%96%B0%E7%9A%84%E4%B8%8A%E4%B8%8B%E6%96%87%E8%A8%AD%E8%A8%88%E8%A6%8F%E5%89%87\" class=\"anchor\" id=\"六項新的上下文設計規則\"\u003e\u003c/a\u003e六項新的上下文設計規則\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e過去做法\u003c/th\u003e\n\u003cth\u003e建議做法\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"過去做法\"\u003e以禁止清單規定細節行為\u003c/td\u003e\n\u003ctd data-label=\"建議做法\"\u003e提出目標與判斷標準，並善用上下文\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"過去做法\"\u003e提供大量工具呼叫範例\u003c/td\u003e\n\u003ctd data-label=\"建議做法\"\u003e將結構描述本身設計成可說明用法\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"過去做法\"\u003e在工作開始時注入所有資訊\u003c/td\u003e\n\u003ctd data-label=\"建議做法\"\u003e在需要的時機逐步揭露\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"過去做法\"\u003e在多個位置重複相同指示\u003c/td\u003e\n\u003ctd data-label=\"建議做法\"\u003e為每項指示指定一個權威儲存位置\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"過去做法\"\u003e連暫時記憶也儲存在 CLAUDE.md\u003c/td\u003e\n\u003ctd data-label=\"建議做法\"\u003e區分永久政策與自動記憶的角色\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"過去做法\"\u003e依賴冗長的 Markdown 說明\u003c/td\u003e\n\u003ctd data-label=\"建議做法\"\u003e提供程式碼、測試、HTML、評分表等可執行資料\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\n\u003ca href=\"#1-%E5%B0%87%E7%B4%B0%E7%AF%80%E7%A6%81%E6%AD%A2%E6%B8%85%E5%96%AE%E6%94%B9%E7%82%BA%E4%BB%A5%E8%84%88%E7%B5%A1%E7%82%BA%E5%9F%BA%E7%A4%8E%E7%9A%84%E5%8E%9F%E5%89%87\" class=\"anchor\" id=\"1-將細節禁止清單改為以脈絡為基礎的原則\"\u003e\u003c/a\u003e1. 將細節禁止清單改為以脈絡為基礎的原則\u003c/h3\u003e\n\u003cp\u003e為了防止過去模型反覆犯錯，有時會冗長地列出下列規則。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e不撰寫註解。\u003c/li\u003e\n\u003cli\u003e不建立包含多個段落的 docstring。\u003c/li\u003e\n\u003cli\u003e不建立未經請求的計畫文件。\u003c/li\u003e\n\u003cli\u003e不儲存中間分析檔案。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e這類規則雖能防止特定失敗，卻不是適用於所有情況的絕對原則。複雜的安全驗證或並行程式碼可能需要說明，而一目了然的 CRUD 程式碼中，註解反而可能造成雜訊。\u003c/p\u003e\n\u003cp\u003e較好的方式是提供如下判斷標準。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e撰寫方式與周邊程式碼一致、易於閱讀的程式碼。\n\u003c/span\u003e\u003cspan\u003e遵循現有檔案的命名規則、慣用表達與註解密度。\n\u003c/span\u003e\u003cspan\u003e僅在缺少說明便無法釐清安全性或意圖的邏輯中，新增必要文件。\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e但不應將所有規則都弱化。以下項目應繼續維持明確限制，或以工具層級進行管控。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e正式環境部署與資料刪除核准\u003c/li\u003e\n\u003cli\u003e個人資料與機密資訊的處理限制\u003c/li\u003e\n\u003cli\u003e身分驗證與授權驗證\u003c/li\u003e\n\u003cli\u003e金錢交易的冪等性與稽核紀錄\u003c/li\u003e\n\u003cli\u003e資料庫遷移政策\u003c/li\u003e\n\u003cli\u003e法律、授權條款與法規遵循\u003c/li\u003e\n\u003cli\u003e不得變更的公開 API 契約\u003c/li\u003e\n\u003c/ul\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e規則類型\u003c/th\u003e\n\u003cth\u003e適當的處理方式\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"規則類型\"\u003e安全、法律、權限\u003c/td\u003e\n\u003ctd data-label=\"適當的處理方式\"\u003e維持明確且強制的限制\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"規則類型\"\u003e可能造成資料遺失的工作\u003c/td\u003e\n\u003ctd data-label=\"適當的處理方式\"\u003e透過核准流程與工具權限管控\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"規則類型\"\u003e公開契約、相容性\u003c/td\u003e\n\u003ctd data-label=\"適當的處理方式\"\u003e透過測試與結構描述驗證\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"規則類型\"\u003e程式碼風格、註解\u003c/td\u003e\n\u003ctd data-label=\"適當的處理方式\"\u003e使用依據周邊程式碼判斷的原則\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"規則類型\"\u003e暫時性工作順序\u003c/td\u003e\n\u003ctd data-label=\"適當的處理方式\"\u003e在目前計畫或工作清單中管理\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\n\u003ca href=\"#2-%E8%88%87%E5%85%B6%E6%8F%90%E4%BE%9B%E5%A4%A7%E9%87%8F%E7%AF%84%E4%BE%8B%E4%B8%8D%E5%A6%82%E8%A8%AD%E8%A8%88%E5%85%B7%E8%A1%A8%E9%81%94%E5%8A%9B%E7%9A%84%E5%B7%A5%E5%85%B7\" class=\"anchor\" id=\"2-與其提供大量範例不如設計具表達力的工具\"\u003e\u003c/a\u003e2. 與其提供大量範例，不如設計具表達力的工具\u003c/h3\u003e\n\u003cp\u003e若持續在工具說明中新增正常與異常的呼叫案例，上下文會持續增大，模型也可能模仿範例的表面形式。更好的做法，是讓工具名稱、輸入欄位與狀態轉換本身就能呈現使用方式。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eTodoWrite\n\u003c/span\u003e\u003cspan\u003e目的：建立及更新目前工作階段的工作清單\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003estatus:\n\u003c/span\u003e\u003cspan\u003e- pending\n\u003c/span\u003e\u003cspan\u003e- in_progress\n\u003c/span\u003e\u003cspan\u003e- completed\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e限制：\n\u003c/span\u003e\u003cspan\u003e- 同時只能有一項工作處於 in_progress\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e良好的代理工具具備以下特性。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e僅從名稱即可看出行為與對象。\u003c/li\u003e\n\u003cli\u003e必填欄位與選填欄位有所區分。\u003c/li\u003e\n\u003cli\u003e以列舉限制允許的值。\u003c/li\u003e\n\u003cli\u003e區分讀取與寫入、預覽與執行。\u003c/li\u003e\n\u003cli\u003e錯誤以結構化形式回傳原因與復原方式。\u003c/li\u003e\n\u003cli\u003e危險工作要求確認 token 或核准步驟。\u003c/li\u003e\n\u003cli\u003e結果過長時提供摘要與分頁瀏覽功能。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e範例最好只在說明難以透過介面表達的例外或模糊輸入時加入。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#3-%E4%B8%8D%E8%A6%81%E4%B8%80%E9%96%8B%E5%A7%8B%E5%B0%B1%E6%94%BE%E5%85%A5%E6%89%80%E6%9C%89%E8%B3%87%E8%A8%8A%E8%80%8C%E6%87%89%E9%80%90%E6%AD%A5%E6%8F%AD%E9%9C%B2\" class=\"anchor\" id=\"3-不要一開始就放入所有資訊而應逐步揭露\"\u003e\u003c/a\u003e3. 不要一開始就放入所有資訊，而應逐步揭露\u003c/h3\u003e\n\u003cp\u003e不應只因代理可能需要某些資訊，就從一開始注入整個儲存庫、所有政策與冗長日誌。先提供探索所需的最少資訊，待工作具體化時，再讓模型讀取相關資料。\u003c/p\u003e\n\u003cp\u003e建議流程如下。\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e提供目標、成功標準與安全邊界。\u003c/li\u003e\n\u003cli\u003e透過儲存庫結構或搜尋工具找出相關位置。\u003c/li\u003e\n\u003cli\u003e僅讀取必要的檔案與規格。\u003c/li\u003e\n\u003cli\u003e實作後執行相關測試與靜態分析。\u003c/li\u003e\n\u003cli\u003e若失敗，僅額外取得該錯誤與周邊程式碼。\u003c/li\u003e\n\u003cli\u003e完成後壓縮或移除過時日誌與中間推理。\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e逐步揭露並不是隱藏資訊，而是提供搜尋路徑與明確的檔案結構，讓模型能夠發現所需資訊。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#4-%E7%A7%BB%E9%99%A4%E9%87%8D%E8%A4%87%E6%8C%87%E7%A4%BA%E4%B8%A6%E6%8C%87%E5%AE%9A%E6%AC%8A%E5%A8%81%E4%BD%8D%E7%BD%AE\" class=\"anchor\" id=\"4-移除重複指示並指定權威位置\"\u003e\u003c/a\u003e4. 移除重複指示並指定權威位置\u003c/h3\u003e\n\u003cp\u003e若將同一規則複製到系統提示詞、CLAUDE.md、Skill 與工具說明中，隨著時間推移，內容措辭可能出現差異。應依指示類型指定一個權威儲存位置。\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e資訊\u003c/th\u003e\n\u003cth\u003e建議位置\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"資訊\"\u003e整個組織的安全政策\u003c/td\u003e\n\u003ctd data-label=\"建議位置\"\u003e系統指示或權限層級\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"資訊\"\u003e儲存庫的建置與測試命令\u003c/td\u003e\n\u003ctd data-label=\"建議位置\"\u003e專案 CLAUDE.md\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"資訊\"\u003e特定工作流程\u003c/td\u003e\n\u003ctd data-label=\"建議位置\"\u003e對應的 Skill\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"資訊\"\u003e工具輸入與限制\u003c/td\u003e\n\u003ctd data-label=\"建議位置\"\u003e工具結構描述與說明\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"資訊\"\u003e公開 API 行為\u003c/td\u003e\n\u003ctd data-label=\"建議位置\"\u003e程式碼結構描述、規格與契約測試\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"資訊\"\u003e目前工作階段的進度\u003c/td\u003e\n\u003ctd data-label=\"建議位置\"\u003e工作清單或工作階段狀態\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e若無法避免重複，與其複製內容，不如指向權威位置或採用自動產生的方式，會更加安全。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#5-%E5%8D%80%E5%88%86-claudemd-%E8%88%87%E8%87%AA%E5%8B%95%E8%A8%98%E6%86%B6%E7%9A%84%E8%A7%92%E8%89%B2\" class=\"anchor\" id=\"5-區分-claudemd-與自動記憶的角色\"\u003e\u003c/a\u003e5. 區分 CLAUDE.md 與自動記憶的角色\u003c/h3\u003e\n\u003cp\u003eCLAUDE.md 適合存放可供專案成員檢閱並納入版本控制的持續性指示。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e標準建置與測試命令\u003c/li\u003e\n\u003cli\u003e儲存庫結構的核心說明\u003c/li\u003e\n\u003cli\u003e團隊協議的禁止變更區域\u003c/li\u003e\n\u003cli\u003e專案特有的驗證流程\u003c/li\u003e\n\u003cli\u003e難以透過一般工具推理得出的規則\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e相較之下，以下資訊更適合放在自動記憶或工作階段狀態中。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e從重複工作中發現的個人化偏好\u003c/li\u003e\n\u003cli\u003e最近工作中有用的探索路徑\u003c/li\u003e\n\u003cli\u003e暫時性的開發環境特性\u003c/li\u003e\n\u003cli\u003e目前工作階段的進度\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e不應假設自動記憶永遠正確或永久有效。必須能夠修改或移除過時項目，也不應將其作為安全政策與公開契約的唯一儲存庫。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#6-%E5%84%AA%E5%85%88%E4%BD%BF%E7%94%A8%E5%8F%AF%E5%9F%B7%E8%A1%8C%E7%9A%84%E5%8F%83%E8%80%83%E8%B3%87%E6%96%99%E8%80%8C%E9%9D%9E%E8%AA%AA%E6%98%8E%E6%96%87%E4%BB%B6\" class=\"anchor\" id=\"6-優先使用可執行的參考資料而非說明文件\"\u003e\u003c/a\u003e6. 優先使用可執行的參考資料，而非說明文件\u003c/h3\u003e\n\u003cp\u003e自然語言規格有助於說明意圖，但可能無法完整表達實際行為。在可能的情況下，一併提供以下資料。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e與目前程式碼相似的現有實作\u003c/li\u003e\n\u003cli\u003e單元測試與整合測試\u003c/li\u003e\n\u003cli\u003eAPI 結構描述與型別定義\u003c/li\u003e\n\u003cli\u003e實際 HTML 或設計產出\u003c/li\u003e\n\u003cli\u003e資料庫遷移檔案\u003c/li\u003e\n\u003cli\u003e輸入與輸出範例資料\u003c/li\u003e\n\u003cli\u003e評分表與自動評分標準\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e參考資料之間也可能發生衝突，因此應明確指定優先順序。例如，可將契約測試指定為公開 API 的權威標準，而 README 則作為說明資料。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E5%AF%A6%E5%8B%99%E7%94%A8%E4%B8%8A%E4%B8%8B%E6%96%87%E7%B5%84%E6%88%90%E7%AF%84%E6%9C%AC\" class=\"anchor\" id=\"實務用上下文組成範本\"\u003e\u003c/a\u003e實務用上下文組成範本\u003c/h2\u003e\n\u003cp\u003e以下結構是精簡整理程式設計工作所需資訊的範例。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e目標\n\u003c/span\u003e\u003cspan\u003e- 新增取消付款 API。\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e成功標準\n\u003c/span\u003e\u003cspan\u003e- 重複使用現有付款服務層。\n\u003c/span\u003e\u003cspan\u003e- 即使有重複請求，也只取消一次。\n\u003c/span\u003e\u003cspan\u003e- 相關契約測試通過。\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e強制限制\n\u003c/span\u003e\u003cspan\u003e- 不變更公開回應結構描述。\n\u003c/span\u003e\u003cspan\u003e- 不存取正式環境資料。\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e參考資料\n\u003c/span\u003e\u003cspan\u003e- src/payments/capture.ts\n\u003c/span\u003e\u003cspan\u003e- tests/contracts/payment-cancel.test.ts\n\u003c/span\u003e\u003cspan\u003e- openapi/payments.yaml\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e判斷原則\n\u003c/span\u003e\u003cspan\u003e- 遵循周邊付款程式碼的錯誤處理與命名規則。\n\u003c/span\u003e\u003cspan\u003e- 若存在不安全的假設，在實作前先提問。\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e驗證\n\u003c/span\u003e\u003cspan\u003e- 目標單元測試\n\u003c/span\u003e\u003cspan\u003e- 契約測試\n\u003c/span\u003e\u003cspan\u003e- 型別檢查\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e這種格式不會事先列出所有情況，而是將目標、成功條件、不變邊界、權威資料與驗證方法分開。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E6%95%B4%E7%90%86%E7%8F%BE%E6%9C%89%E4%B8%8A%E4%B8%8B%E6%96%87%E7%9A%84%E6%B5%81%E7%A8%8B\" class=\"anchor\" id=\"整理現有上下文的流程\"\u003e\u003c/a\u003e整理現有上下文的流程\u003c/h2\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E7%AC%AC-1-%E6%AD%A5%E5%88%97%E5%87%BA%E6%89%80%E6%9C%89%E6%8C%87%E7%A4%BA%E7%9A%84%E4%BE%86%E6%BA%90\" class=\"anchor\" id=\"第-1-步列出所有指示的來源\"\u003e\u003c/a\u003e第 1 步：列出所有指示的來源\u003c/h3\u003e\n\u003cp\u003e一併確認系統提示詞、CLAUDE.md、Skills、自動記憶、工具說明與 CI 設定。若只檢視一份文件，很難發現實際衝突。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E7%AC%AC-2-%E6%AD%A5%E7%82%BA%E6%AF%8F%E9%A0%85%E6%8C%87%E7%A4%BA%E5%8A%A0%E4%B8%8A%E5%88%86%E9%A1%9E%E6%A8%99%E7%B1%A4\" class=\"anchor\" id=\"第-2-步為每項指示加上分類標籤\"\u003e\u003c/a\u003e第 2 步：為每項指示加上分類標籤\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e安全或法律上的必要事項\u003c/li\u003e\n\u003cli\u003e產品契約上的必要事項\u003c/li\u003e\n\u003cli\u003e團隊的持續性慣例\u003c/li\u003e\n\u003cli\u003e僅特定工具所需的說明\u003c/li\u003e\n\u003cli\u003e為防止過去模型犯錯而制定的暫時規則\u003c/li\u003e\n\u003cli\u003e目前依據不明確的規則\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E7%AC%AC-3-%E6%AD%A5%E5%B0%8B%E6%89%BE%E9%87%8D%E8%A4%87%E8%88%87%E8%A1%9D%E7%AA%81\" class=\"anchor\" id=\"第-3-步尋找重複與衝突\"\u003e\u003c/a\u003e第 3 步：尋找重複與衝突\u003c/h3\u003e\n\u003cp\u003e將以不同方式表達相同行為的句子歸為一組。尤其應優先檢視 \u003ccode\u003e一律\u003c/code\u003e、\u003ccode\u003e絕對\u003c/code\u003e、\u003ccode\u003e必須\u003c/code\u003e、\u003ccode\u003e不要\u003c/code\u003e 等表達方式。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E7%AC%AC-4-%E6%AD%A5%E5%B0%87%E8%A6%8F%E5%89%87%E8%BD%89%E7%A7%BB%E8%87%B3%E6%B8%AC%E8%A9%A6%E6%88%96%E6%AC%8A%E9%99%90\" class=\"anchor\" id=\"第-4-步將規則轉移至測試或權限\"\u003e\u003c/a\u003e第 4 步：將規則轉移至測試或權限\u003c/h3\u003e\n\u003cp\u003e相較於自然語言警告，適合以自動驗證確保落實的項目，應移至以下層級。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e測試與 linter\u003c/li\u003e\n\u003cli\u003e型別系統與結構描述\u003c/li\u003e\n\u003cli\u003e最小權限工具\u003c/li\u003e\n\u003cli\u003e核准流程\u003c/li\u003e\n\u003cli\u003e沙箱\u003c/li\u003e\n\u003cli\u003eCI 政策\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E7%AC%AC-5-%E6%AD%A5%E4%BB%A5%E5%AF%A6%E9%9A%9B%E5%B7%A5%E4%BD%9C%E9%80%B2%E8%A1%8C%E8%A9%95%E4%BC%B0\" class=\"anchor\" id=\"第-5-步以實際工作進行評估\"\u003e\u003c/a\u003e第 5 步：以實際工作進行評估\u003c/h3\u003e\n\u003cp\u003e不能只衡量提示詞長度。應在代表性工作集合中比較以下指標。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e成功率與測試通過率\u003c/li\u003e\n\u003cli\u003e不必要的檔案變更數量\u003c/li\u003e\n\u003cli\u003e使用者修改次數\u003c/li\u003e\n\u003cli\u003e工具呼叫失敗率\u003c/li\u003e\n\u003cli\u003e完成所需的時間與 token\u003c/li\u003e\n\u003cli\u003e是否違反安全政策\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E7%AC%AC-6-%E6%AD%A5%E5%8F%AA%E9%87%9D%E5%B0%8D%E5%A4%B1%E6%95%97%E5%8E%9F%E5%9B%A0%E9%80%B2%E8%A1%8C%E6%9C%80%E4%BD%8E%E9%99%90%E5%BA%A6%E8%A3%9C%E5%BC%B7\" class=\"anchor\" id=\"第-6-步只針對失敗原因進行最低限度補強\"\u003e\u003c/a\u003e第 6 步：只針對失敗原因進行最低限度補強\u003c/h3\u003e\n\u003cp\u003e發生失敗時，不要立刻新增禁止規則。應先區分原因究竟是目標模糊、參考資料不足，還是工具結構描述錯誤。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E4%B8%8D%E6%87%89%E5%88%AA%E9%99%A4%E7%9A%84%E6%8C%87%E7%A4%BA\" class=\"anchor\" id=\"不應刪除的指示\"\u003e\u003c/a\u003e不應刪除的指示\u003c/h2\u003e\n\u003cp\u003e精簡並不代表無條件刪除。若以下任一問題的答案為 \u003ccode\u003e是\u003c/code\u003e，就應保留該指示，或將其轉移至更強力的管控機制。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e違反時是否會造成資料遺失或金錢損失？\u003c/li\u003e\n\u003cli\u003e是否涉及法律、個人資料或授權義務？\u003c/li\u003e\n\u003cli\u003e是否為模型僅查看程式碼時無法得知的組織政策？\u003c/li\u003e\n\u003cli\u003e是否決定公開 API 或資料格式的相容性？\u003c/li\u003e\n\u003cli\u003e是否需要在執行工作前取得人工核准？\u003c/li\u003e\n\u003cli\u003e是否難以僅透過自動測試完整偵測違規？\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E5%B8%B8%E8%A6%8B%E5%A4%B1%E6%95%97%E6%A8%A1%E5%BC%8F\" class=\"anchor\" id=\"常見失敗模式\"\u003e\u003c/a\u003e常見失敗模式\u003c/h2\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E6%AF%8F%E6%AC%A1%E5%A4%B1%E6%95%97%E5%BE%8C%E9%83%BD%E6%96%B0%E5%A2%9E%E8%A6%8F%E5%89%87\" class=\"anchor\" id=\"每次失敗後都新增規則\"\u003e\u003c/a\u003e每次失敗後都新增規則\u003c/h3\u003e\n\u003cp\u003e若將一次錯誤泛化成永久規則，例外與衝突就會持續累積。應先新增評估案例，確認是否為重複發生的失敗。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E5%B0%87%E5%86%97%E9%95%B7%E7%AF%84%E4%BE%8B%E5%AF%A6%E9%9A%9B%E7%95%B6%E6%88%90%E7%AF%84%E6%9C%AC%E4%BD%BF%E7%94%A8\" class=\"anchor\" id=\"將冗長範例實際當成範本使用\"\u003e\u003c/a\u003e將冗長範例實際當成範本使用\u003c/h3\u003e\n\u003cp\u003e若範例過於具體，模型可能會優先遵循範例，而不是目前的程式碼庫。範例應限制為足以說明原則的最小規模。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E5%8E%9F%E5%B0%81%E4%B8%8D%E5%8B%95%E5%9C%B0%E4%BF%9D%E7%95%99%E5%AE%8C%E6%95%B4%E6%97%A5%E8%AA%8C\" class=\"anchor\" id=\"原封不動地保留完整日誌\"\u003e\u003c/a\u003e原封不動地保留完整日誌\u003c/h3\u003e\n\u003cp\u003e工具輸出與建置日誌會迅速占滿上下文。最好只以結構化方式保留失敗原因、相關堆疊與變更後的狀態。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E5%B0%87%E8%87%AA%E5%8B%95%E8%A8%98%E6%86%B6%E4%BD%9C%E7%82%BA%E6%94%BF%E7%AD%96%E5%84%B2%E5%AD%98%E5%BA%AB\" class=\"anchor\" id=\"將自動記憶作為政策儲存庫\"\u003e\u003c/a\u003e將自動記憶作為政策儲存庫\u003c/h3\u003e\n\u003cp\u003e自動記憶雖然方便，但其檢閱、部署與稽核機制可能較弱。組織的強制政策應保存在納入版本控制的指示或權限層級中。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E5%8F%AA%E4%BB%A5%E7%AF%80%E7%9C%81-token-%E8%A9%95%E4%BC%B0%E4%B8%8A%E4%B8%8B%E6%96%87%E7%B8%AE%E6%B8%9B\" class=\"anchor\" id=\"只以節省-token-評估上下文縮減\"\u003e\u003c/a\u003e只以節省 token 評估上下文縮減\u003c/h3\u003e\n\u003cp\u003e較短的上下文不一定更好。若移除必要測試、安全規則或規格，結果反而會惡化。目標不是 token 最少，而是最低限度的高訊號 token。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E6%9C%80%E7%B5%82%E6%AA%A2%E6%9F%A5%E8%A1%A8\" class=\"anchor\" id=\"最終檢查表\"\u003e\u003c/a\u003e最終檢查表\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e目前請求的目標與成功標準是否分開？\u003c/li\u003e\n\u003cli\u003e安全規則與風格偏好是否有所區分？\u003c/li\u003e\n\u003cli\u003e相同指示是否未在多個位置重複？\u003c/li\u003e\n\u003cli\u003e工具結構描述是否無須冗長範例也能說明用法？\u003c/li\u003e\n\u003cli\u003e是否能在需要時搜尋相關檔案？\u003c/li\u003e\n\u003cli\u003e是否有方法移除過時記憶與執行日誌？\u003c/li\u003e\n\u003cli\u003e是否能以測試或權限強制執行自然語言規則？\u003c/li\u003e\n\u003cli\u003e參考資料之間的優先順序是否明確？\u003c/li\u003e\n\u003cli\u003e是否有可比較指示變更前後結果的評估工作？\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E7%B5%90%E8%AB%96\" class=\"anchor\" id=\"結論\"\u003e\u003c/a\u003e結論\u003c/h2\u003e\n\u003cp\u003e針對高效能 Claude 模型的上下文工程，並不是無條件縮減指示的技術。它是一種資訊設計：清楚呈現模型判斷目前工作所需的目的、安全邊界與依據，並移除無關資訊及相互衝突的規則。\u003c/p\u003e\n\u003cp\u003e最實用的原則可概括如下。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e強制落實安全與契約，將風格交由脈絡判斷，在需要的時機提供資訊，並以可執行的測試驗證結果。\u003c/p\u003e\n\u003c/blockquote\u003e\n","tags":["提示詞工程","上下文工程","AI 代理人","Claude Code","Claude"],"faqs":[{"question":"提示詞工程與上下文工程有何不同？","answer":"提示詞工程處理如何表達目前請求的目標、格式與限制。上下文工程則設計何時要向模型顯示哪些內容，包括該提示詞，以及系統指示、檔案、工具、記憶、對話紀錄與執行結果。"},{"question":"上下文越長，模型的效能就一定越好嗎？","answer":"並非如此。較長的上下文中可能混雜不相關的資訊、過時的紀錄與相互衝突的指示。重要的不是整體 token 數量，而是能直接幫助目前工作的高訊號資訊比例。"},{"question":"需要為 Claude 5 刪除所有現有規則嗎？","answer":"不需要。像程式碼風格或註解這類會依情況而異的細微規則，可以改為判斷原則，但與安全、個人資料、權限、金錢交易、資料刪除及公開 API 契約有關的限制，則應予以保留，或透過工具與測試進行更嚴格的控管。"},{"question":"CLAUDE.md 中適合放入哪些內容？","answer":"適合放入持續有效且可供審查的指示，例如專案的建置與測試命令、儲存庫結構、禁止變更的區域，以及團隊達成共識的驗證程序。若將暫時性的進度或個人化的發現全都儲存下來，文件可能很快就會過時。"},{"question":"自動記憶可以取代 CLAUDE.md 嗎？","answer":"無法完全取代。自動記憶有助於保留在重複工作中發現的偏好或探索資訊，但像安全政策與公開契約這類需要稽核與版本管理的指示，則應放在 CLAUDE.md 或獨立的政策層中。"},{"question":"良好的代理工具介面具備哪些特徵？","answer":"應僅從工具名稱與輸入結構描述就能看出用途，且必填值與允許的狀態都必須明確。危險的寫入操作應要求預覽或核准，而錯誤最好能以結構化方式回傳原因與復原方法。"},{"question":"漸進式揭露是指對模型隱藏資訊嗎？","answer":"不是。一開始先提供目標與探索路徑，並讓模型隨著工作逐步具體化，搜尋所需的檔案、規格與日誌。其目的在於維持資訊的可存取性，同時減少不必要的預先注入。"},{"question":"縮減上下文後，要如何評估效果？","answer":"應在一組具代表性的工作上，比較變更前後的測試通過率、使用者修改次數、不必要的變更、工具錯誤、token 使用量，以及是否違反安全政策。不應僅憑提示詞長度減少就判定成功。"},{"question":"可以完全不提供工具使用範例嗎？","answer":"範例並非總是不必要。當存在僅靠結構描述難以表達的邊界案例或模糊輸入時，最少量的範例會很有幫助。但比起重複列出一般呼叫方式，應優先讓介面本身清楚明確。"}],"sources":[{"url":"https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents","title":"AI 代理的有效情境工程","type":"source"},{"url":"https://www.anthropic.com/engineering/building-effective-agents","title":"建立有效的代理","type":"source"},{"url":"https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview","title":"提示詞工程概述","type":"source"},{"url":"https://docs.anthropic.com/en/docs/claude-code/memory","title":"Claude Code 記憶文件","type":"source"}],"images":[{"id":303,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzMzMywicHVyIjoiYmxvYl9pZCJ9fQ==--b6a9225f1d5837dd6ca93532a1e1a3388a1cc4fc/ai-e5c0c894.webp","is_representative":true,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"문서와 데이터 아이콘이 깔때기를 거쳐 중앙 AI 네트워크로 모이는 일러스트","caption":"다양한 컨텍스트가 선별·구조화되어 AI 모델에 연결되는 과정을 표현한다.","description":null},"en":{"alt":"Documents and data icons flowing through a funnel into a central AI network","caption":"The illustration shows varied context being filtered and structured for an AI model.","description":null},"ja":{"alt":"文書やデータのアイコンが漏斗を通って中央のAIネットワークに集まる図","caption":"多様なコンテキストを選別・構造化してAIモデルにつなぐ流れを表している。","description":null},"es":{"alt":"Iconos de documentos y datos pasan por un embudo hacia una red de IA central","caption":"La ilustración representa cómo se filtra y estructura el contexto para un modelo de IA.","description":null},"id":{"alt":"Ikon dokumen dan data mengalir melalui corong menuju jaringan AI pusat","caption":"Ilustrasi ini menunjukkan konteks yang disaring dan disusun untuk model AI.","description":null},"pt":{"alt":"Ícones de documentos e dados passam por um funil até uma rede central de IA","caption":"A ilustração mostra diferentes contextos sendo filtrados e estruturados para um modelo de IA.","description":null},"zh-hant":{"alt":"文件與資料圖示經漏斗匯入中央AI網路","caption":"插圖呈現多種脈絡經篩選與結構化後連接至AI模型的流程。","description":null}}},{"id":304,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzMzOSwicHVyIjoiYmxvYl9pZCJ9fQ==--c5e1421a425951ca760407e2d7b6c78654f545e5/ai-8b2296c2.webp","is_representative":false,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"로봇이 검색, 파일, 도구, 코드, 검증, 보고서 단계를 거쳐 목표로 향하는 AI 워크플로","caption":"보안 경계 안에서 컨텍스트와 도구를 단계별로 처리하는 AI 워크플로를 보여준다.","description":null},"en":{"alt":"AI workflow with a robot moving through search, files, tools, code, validation, and reporting toward a target","caption":"The diagram shows an AI processing context and tools step by step within a secure boundary.","description":null},"ja":{"alt":"ロボットが検索、ファイル、ツール、コード、検証、レポートを経て目標へ進むAIワークフロー","caption":"安全な境界内でコンテキストとツールを段階的に処理するAIワークフローを示している。","description":null},"es":{"alt":"Flujo de IA con un robot que pasa por búsqueda, archivos, herramientas, código, validación e informes","caption":"El diagrama muestra una IA que procesa contexto y herramientas por etapas dentro de un entorno seguro.","description":null},"id":{"alt":"Alur kerja AI dengan robot melalui pencarian, berkas, alat, kode, validasi, dan laporan menuju sasaran","caption":"Diagram ini menunjukkan AI yang memproses konteks dan alat secara bertahap dalam batas aman.","description":null},"pt":{"alt":"Fluxo de IA com robô passando por busca, arquivos, ferramentas, código, validação e relatório até o alvo","caption":"O diagrama mostra uma IA processando contexto e ferramentas em etapas dentro de um limite seguro.","description":null},"zh-hant":{"alt":"機器人依序經過搜尋、檔案、工具、程式碼、驗證與報告並朝目標前進的 AI 工作流程","caption":"圖中呈現 AI 在安全邊界內分階段處理情境資訊與工具的工作流程。","description":null}}}],"published_at":"2026-07-27T05:12:07+09:00","updated_at":"2026-07-27T05:12:07+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant"],"url":"https://injoys.com/en/articles/claude-5-context-engineering-rules"}