學習筆記

TL;DR

隨著大型語言模型（LLM）能力顯著提升，上下文工程的規則已從過去對模型施加嚴格約束，轉變為應減少限制，給予模型更多自由判斷的空間，以發揮其最大潛力。

快速結論

Claude 5 時代，Nropic 大幅削減了 Claude Code 超過 80% 的系統提示詞，但編碼評測結果顯示效果並未下降。這項改變的核心在於，當前大型語言模型（LLM）的判斷力已足夠強大，能自行理解複雜且甚至可能衝突的指令並推斷用戶意圖，因此過去為避免模型「闖禍」而設計的強硬約束，如今反而成為其理解與執行任務的負擔。

這一切的指導原則是「按好布林，給模型鬆綁」（unleash the model），意味著我們應該讓模型更多地依賴上下文和自身的判斷來做決定。上下文工程的思維模式因此徹底轉變，從「預設所有情況並給予死板規則」變成「提供彈性上下文，並讓模型在需要時自行判斷或調用資訊」。例如，過去詳細描述如何使用工具的示例應被簡化，轉而透過工具本身的設計來清晰表達用途。

在實際應用上，System Prompt、Code MD 和 Skills 等都應保持輕量化、模組化。應避免將所有規則都寫在一個大文件中，而是將細節拆分成獨立的 Skills 或 Refinements，讓模型在需要時才載入。此外，模型對程式碼語言最為熟悉，因此在引用文件或提供資訊時，應優先考慮使用程式碼形式（如 HTML 設計稿或程式碼片段），這將比純文字描述更有效率和精準。

這支影片在說什麼

這支影片分享了 Claude 團隊 Sherrick 提出的「上下文工程新規則」，其背景是 Nropic 在 Claude 5 時代將 Claude Code 的系統提示詞大幅削減超過 80%，而效果卻沒有下降。影片旨在闡釋為何新一代大型語言模型能力增強後，過去的上下文工程方法已不再適用，並透過六組新舊思維轉換的對比，提供如何設計 System Prompt、Skills、Code MD 和 Refinements 的實際應用建議。本影片適合所有想提升 AI 模型提示工程與上下文管理效率的開發者或使用者。

最重要的 3-5 個重點

1. 模型能力提升，提示詞應「鬆綁」而非「綑綁」： Claude 5 模型判斷力顯著提升，能自行推斷意圖。過去為避免模型出錯而設置的強硬規則，現在反而成為模型理解的負擔，應刪除，給予模型更多自由判斷的空間，讓它靠上下文和自己的判斷來做決定。
2. 上下文工程思維從「預設」轉向「彈性」： 過去傾向於將所有可能的規則和細節預先寫入系統提示詞；新規則則提倡將這些內容拆分為更小的模組（如獨立 Skills 或 Refinements），讓模型在需要時動態調用，避免不必要的上下文佔用，並減少重複。
3. 工具使用教學應轉為「設計本身說清楚」： 過去會透過示例（投套體率）教導模型如何使用工具；現在則強調透過工具本身的設計（如參數命名、枚舉值定義）讓模型自然理解用法，避免示例反而將模型框死在特定範圍內。
4. 資訊組織應模組化，利用漸進式披露： 不常用但關鍵的細節（如程式碼審查、限制）不應預設在 System Prompt 中，而是應拆成獨立的 Skills 或 Refinements，採「漸進式披露」（Just-in-Time disclosure）策略，讓模型在需要時自行調用，減少平時上下文佔用。
5. 程式碼形式的引用更精準高效： 在 Refinements 中，盡量使用程式碼形式（例如引用一個 HTML 設計稿或程式碼片段）來傳達資訊，因為程式碼是模型最熟悉的語言，一個設計稿通常比一段文字描述或截圖更能讓模型理解。

知識架構

I. 上下文工程的定義與範式轉變 A. 上下文與 Prompt 的區別 1. Prompt 針對單次具體任務。 2. 上下文（System Prompt, Skills, Code MD, 記憶）是模型看到的完整背景，面對多種未知請求。 B. 模型能力提升導致的轉變 1. 舊模型能力有限，需嚴格規則避免錯誤。 2. 新模型判斷力強，能理解衝突指

令並推斷意圖。 3. 核心原則：Sherrick 的「按好布林，給模型鬆綁」——從「約束」轉向「自由判斷」。

II. 上下文工程的六組新規則（過去 vs. 現在） A. 規則的強度： 1. 過去：擔心模型「闖禍」，給予強硬死規矩（如「絕不寫多行註釋」）。 2. 現在：換成彈性規則，讓模型根據周圍上下文判斷（如「註釋密度、風格跟周圍上下文一致」）。 B. 工具使用指導： 1. 過去：透過提供示例（投套體率）教模型調用工具。 2. 現在：別對示例，改由工具本身設計（參數命名、枚舉值）讓結果自明用法。 C. 細節與流程： 1. 過去：將不常用但關鍵的細節預設嵌入 System Prompt。 2. 現在：換成「漸進式披露」，裁成獨立 Skills 或工具，需要時再加載。 D. 資訊重複： 11. 過去：為確保模型記住，在 System Prompt 和工具描述中重複提及。 2. 現在：刪除重複，直接寫進工具描述，System Prompt 不再說第二遍。 E. 記憶與存儲： 1. 過去：需要手動將要記住的東西寫入 Code MD。 2. 現在：模型會自動將與當前工作相關的東西存入記憶，無需手動。 F. 應用類型： 1. 過去：程式碼模型高度依賴 code_md 寫的計畫。 2. 現在：模型能處理更複雜的應用，如 Relyfacts 生成的 HTML、程式碼、詳細測試、函式、Rubric 評分標準等。

III. 日常實踐中的應用建議 A. System Prompt： 1. 與產品綁定，告訴模型在哪個產品、做什麼。 2. Claude 無需太多改動，若自建 Agent 需下功夫。 B. Code MD： 1. 保持輕量化，簡單說明程式碼庫功用。 2. 偏複雜的技術細節（如類型定義）放在程式碼庫內的單一文件。 3. 避免模型看文件結構即知的「廢話」。 C. Skills： 1. 過去：輕量嚮導，避免寫太死。 2. 現在：拆成多個文件，適合裝載屬於團隊、產品的經驗和判斷。 3. 除非特別關鍵，否則避免給予太硬的規定。 D. Refinements： 1. 用 @ 符號引用文件。 2. 盡量用程式碼形式引用（HTML 設計稿、程式碼片段），因為程式碼是模型最熟悉的語言。

IV. 實際案例驗證 A. 「Boring Video Studio」Skills 拆解： 1. 原問題：Block_form_Video 的 Skill MD 過於龐大（300+ 行），包含所有細節。 2. 改進：主文件只保留「何時使用、大致功用」，細節（如格式配置表、目錄結構）傳到 Refinements 透過 at 引用。 B. 關鍵規定的保留： 1. 某些「會出事」的硬性規定仍需保留，如「數字必須核對官方元件」、「封面設計中黃暴保存路徑」。 2. 一般層面的硬化規則，可交由模型判斷。

關鍵概念

• 上下文工程 (Context Engineering)： 設計通用指令（System Prompt, Skills, Code MD, 記憶等）的過程，這些指令組合成模型看到的完整上下文，以應對多種未來可能出現的請求。
• Prompt： 針對一次具體任務的指令，與上下文工程不同，上下文樣板面對的是多個情境。
• System Prompt： 系統提示詞，與產品綁定，用於告訴模型它在哪個產品中，正在執行什麼任務。

Skills： 模型可調用的工具或功能模組，過去被當成輕量嚮導。在新規則下，應拆分成多個文件，用於裝載屬於個人、團隊、產品的經驗和判斷。

• Code MD： 用於存儲與當前工作相關的資訊，應保持輕量化，並將技術細節（如類型定義）放在程式碼庫內的特定文件。
• Refinements： 透過 @ 符號引用外部文件的機制，建議以程式碼形式引用，因為程式碼是模型最熟悉的語言。
• 按好布林 (Unleash the model)： 核心指導原則，意指給模型鬆綁，讓模型更多地依靠上下文和自身的判斷來做決定，而不是被過多、過死的硬性規則限制。
• 漸進式披露 (Just-in-Time disclosure)： 將不常用但關鍵的資訊拆分成獨立模組，在模型需要時才調用，避免預設佔用上下文。

重要例子與細節

• 削減 System Prompt 的實際效果： Nropic 將 Claude Code 的系統提示詞砍掉 80% 以上，但根據編碼評測結果，效果並沒有任何下降。
• 過去的指令衝突問題： 舊模型常面臨 System Prompt 說「寫文章就寫文章」、Skills 又說「絕對不要加註釋」、再加上用戶要求等互相打架的指令，模型需要耗費精力理解並推斷意圖。
• 「擔心闖禍」規則的轉變：
  • 過去做法： 給予強硬規則，如「絕不寫多行註釋」，擔心模型寫出錯誤的程式碼。
  • 現在做法： 換成「寫出的程式碼，其註釋密度、風格都跟周圍上下文一致」，將判斷交給模型。
• 工具使用指導的轉變案例：
  • 過去做法： 提供示例（投套體率）教模型怎麼調用工具。
  • 現在做法： 透過工具本身的設計，如參數取名、枚舉值定義（status 有 pending, in progress, completed），再加上「同時只保留一個 in progress」的說明，讓模型自然理解用法。
• 程式碼審查與限制細節的處理： 過去將程式碼審查、限制等細節寫在 System Prompt 中，現在則裁成獨立的 Skills，模型需要時自己調用。
• Code MD 和 Skills 的拆分原則： 不再將所有可能用的規矩都寫在一個大文件裡，而是拆成多個文件，該加在哪塊就加在哪塊。
• 重複資訊的移除： 過去 System Prompt 可能會重複提及某個工具的使用方式，工具描述裡又寫一遍；現在這些重複都刪了，使用方式直接寫進工具描述，System Prompt 不再重複。
• 模型記憶能力的進步： 過去需要手動將要記得東西寫進 Code MD；現在模型會自己把跟當前工作相關的東西存進記憶。
• 程式碼模型應用範圍擴大： 不再僅依賴 code_md 寫的計畫，還能處理 Relyfacts 生成的 HTML、程式碼、詳細測試、另一個程式碼庫裡的函式、甚至 Rubric 評分標準。
• 小貓桃的「Boring Video Studio」Skills 拆解實例：
  • 舊問題： Block_form_Video 的 Skill MD 有 300 多行，涵蓋主題選定、專案格式、目錄結構、選軟、封面、講解畫重建等所有細節。
  • 新做法： 主文件只保留「什麼時候用它、大致功用」，像格式配置表、專案目錄結構、增量重建這些細節，傳到 Refinements 用 at 引用載入。
  • 例外規定： 裁徑影片中「數字必須核對官方元件」、封面設計中「科帶X會黃暴保存路徑」等屬於任務執行中的 BKN 指南，刪了會出事，這類硬性規定仍需保留。

可學習的洞察

1. 動態調整是常態： 隨著 AI 技術（特別是大型語言模型）的快速發展，過去的最佳實踐可能很快就會過時。我們必須保持敏銳，定期回顧和調整我們的提示工程與上下文管理策略，而不是固守舊有規則。
2. 信任模型的判斷力： 模型能力越強，我們越應信任其理解和自主判斷的能力。過多的、衝突的或僵化的規則會阻

礙模型的潛力發揮，甚至增加其理解負擔；給予模型更多自由和彈性，它反而能做得更好。 3. 精簡與模組化是高效的關鍵： 避免將所有資訊和規則堆積在一個大文件中。將上下文資訊拆分成更小、更專注的模組（如 Skills、Refinements），並採取「漸進式披露」的策略，能有效減少模型處理的上下文量，提高效率和準確性。 4. 「設計」本身就是一種「溝通」： 無論是工具的參數命名、程式碼的結構，還是資料的呈現方式，都應努力讓其意義不言自明。清晰、自洽的設計能有效傳達資訊，減少對額外解釋和範例的依賴，這不僅適用於模型，也適用於人類協作。 5. 用模型的「母語」溝通： 在與大型語言模型互動時，特別是傳遞結構化或技術性資訊，使用程式碼形式（如 HTML、程式碼片段）通常比自然語言描述更為精準和有效。了解模型底層的訓練偏好，能幫助我們更有效地與其溝通。

可行動的整理

1. 審視現有 System Prompt 與 Skills： 檢查當前使用的 System Prompt、Code MD 和 Skills 中是否存在過多重複、衝突或不必要的硬性約束，考慮進行 80% 以上的簡化或刪減。
2. 推動 Context 資訊模組化： 將龐大的 System Prompt 或 Skills 拆分成更小的、專注於特定功能的模組，並練習利用 Refinements 的 @ 引用機制，在模型需要時才動態載入。
3. 最佳化工具設計的「自說明性」： 如果你在設計供 LLM 調用的工具，確保其參數命名、枚舉值定義等設計本身就能清晰表達用途，減少對額外使用範例的依賴。
4. 優先使用程式碼形式引用資訊： 在與 LLM 共享設計稿、技術規範或其他結構化資訊時，盡量以程式碼形式（如 HTML 設計稿、程式碼片段）來引用，以提高溝通的精準度。
5. 研究 Claude.com 資源： 影片中提到 Claude.com 和 搶鞋杆.com（[資訊不足]待確認網址拼寫），這些平台能幫助自動為 Skills 和 Code MD 生成提示詞。可將其作為學習新的上下文工程實踐的起點。
6. 明確界定「硬性規則」與「彈性判斷」： 仔細區分那些一旦刪除「會出事」的關鍵性硬性規定，與那些可以交由模型自行判斷的一般性規則。只保留前者，後者則賦予模型自由。

複習問題

1. 為何 Claude 5 時代的上下文工程規則需要從過去的「嚴格約束」轉變為「給予模型更多自由」？
2. 影片中提到「按好布林」的原則是什麼意思？它如何影響上下文工程的策略？
3. 過去在指導模型使用工具時，常透過提供示例（投套體率），現在則強調透過「工具設計本身說清楚」。這兩種方法的核心差異與優缺點為何？
4. 在日常實踐中，應如何調整 System Prompt、Code MD 和 Skills 的設計，以符合新的上下文工程規則？請至少說明三點。
5. 在 Refinements 中，為何建議盡量使用程式碼形式（如 HTML 設計稿或程式碼片段）來引用資訊，而非純文字描述？

待確認資訊

• 影片中提到的 搶鞋杆.com 網址拼寫是否正確？（可能是口誤或音譯，原文為此拼寫，但感覺可能需要回看影片或查證）