重點一：Anthropic 為 Claude 5 世代刪除 Claude Code 逾 8 成系統提示詞，內部編碼評測成績沒有可測量的下滑。
重點二：針對 Claude 5 世代的上下文工程，Anthropic 建議減少過度約束與大量工具範例，改以清楚介面、漸進式揭露及模型判斷力為主。
重點三：
CLAUDE.md應保持精簡，集中放置需持續遵守的專案規則與模型不易自行發現的陷阱；Skills 則適合承載按需載入的流程、知識與團隊觀點。
如果你曾為了讓 Claude 更聽話，在設定檔裡寫滿規則、堆滿範例，Anthropic 有個壞消息：面對 Claude 5 世代的新模型，這些心血有一部分可能正在扯 AI 的後腿。
Anthropic 技術團隊成員 Thariq Shihipar 於 2026 年 7 月 24 日在官方部落格發文揭露，團隊為 Claude Opus 5、Claude Fable 5 等 Claude 5 世代模型，刪掉了 Claude Code（Anthropic 推出的 AI 程式開發工具）超過 8 成的系統提示詞，內部編碼評測的成績卻沒有任何可測量的下滑。
這件事的言外之意是：過去一兩年在社群流傳的一批提示詞守則，包括給 AI 範例、立下嚴格規矩、把注意事項寫好寫滿，正被規則的制定者親手重新檢討。
這裡先建立一個背景觀念。當你送出一則訊息給 Claude，AI 實際讀到的內容遠不只那句話，還包括系統提示詞（產品開發者預先寫好的角色與規則說明）、CLAUDE.md（使用者放在專案裡的說明檔）、Skills（技能檔，等於預先打包好的工作指南）等一整套背景資料。
而如何組裝這些背景資料，業界稱為「context engineering」（上下文工程），Shihipar 直言，它對你能拿到什麼品質的產出，影響很大。
為什麼規則越多，AI 反而變笨？
Shihipar 給的診斷很直接：問題不在規則寫得不好，而在「過度約束」（overconstraining）。
Anthropic 回頭翻閱內部員工使用 Claude Code 的紀錄，發現同一個請求裡經常塞著互相打架的指令：這頭寫著「留下適當的文件說明」，那頭寫著「不准加註解」，系統提示詞、Skills 與使用者的當下要求彼此衝突。模型通常猜得出使用者真正的意圖，但它必須耗費更多推理，去處理這些重疊或衝突的指令。
這些嚴格規矩其實是歷史包袱。早期模型判斷力不足，Anthropic 必須用強硬措辭防止 AI 闖禍，例如舊版系統提示詞有這麼一條：「預設不寫註解。絕不寫多段的說明區塊，最多一行短註解。」 但這條規則注定在某些情境是錯的：有些複雜程式碼就是需要大段註解，有些使用者就是偏好完整文件。
如果是舊模型只能接受這種取捨；但新一代模型的判斷力已經夠好，因此新版系統提示詞只剩一句：「寫出讀起來與周圍程式碼一致的程式碼：跟上它的註解密度、命名與慣用寫法。」
換句話說，Anthropic 對待 AI 的方式，正在從「防呆」轉向「授權」。
官方點名的舊迷思，收斂成 4 條新守則
Shihipar 在文中列出六組「以前這樣教、現在別再做」的對照，《數位時代》以下整併為 4 條可直接套用的新守則。
第 1 條：別立死規矩，留判斷空間
檢查你的
CLAUDE.md或常用提示詞，把「絕對不要」「一律禁止」這類措辭挑出來，問自己：這條規則有沒有例外？如果有，改成描述原則而非下命令。前述的註解規則就是官方示範，從「絕不寫多段註解」改成「跟隨周圍程式碼的風格」，把判斷權還給模型。
第 2 條：與其堆範例，先設計好介面
過去工具說明的第一鐵則是「附上使用範例」，Anthropic 卻發現，對 Claude 5 世代模型而言，大量範例反而會把它鎖在單一路徑，限制它探索更好的做法。
Anthropic 的新建議是把力氣優先花在「介面設計」：讓工具的參數名稱、選項本身就清楚、有表達力，足以說明用法。官方以自家的待辦清單工具為例，狀態欄位只開放「待處理、進行中、已完成」三個選項，再補一句「同時間只保留一項進行中」，不必額外舉例，模型就能抓到用法。
但這不等於範例從此無用：範例輸出、格式參照與特殊案例的示範仍有用途，Claude Code 的 Skills 官方文件也仍建議可在技能的輔助檔案中，放置示範預期格式的範例輸出。
第 3 條：別全塞在前面，讓 AI 需要時再讀
一個常見迷思是把
CLAUDE.md當成百科全書，所有可能用到的守則都寫進去，深怕 AI 找不到。官方的新做法叫「漸進式揭露」（progressive disclosure）：把資訊拆成一棵檔案樹，需要時才載入。Anthropic 自己就把程式碼審查、驗證流程從系統提示詞拆出來，變成獨立的 Skills，用到才呼叫；部分工具甚至採「延遲載入」，模型得先主動搜尋，才能取得完整定義。你的驗證步驟如果有好幾條，也可以拆成一個獨立技能檔，
CLAUDE.md只留一行指路。
第 4 條：規格不必只靠文字，可加入高保真參照物
過去的慣用做法，是把計畫與規格寫成簡單的 Markdown 文件；這種寫法仍然可行，但新模型已能消化複雜得多的參照材料，不必只依靠文字規格。一份規格可以是一套完整的測試碼、另一個專案裡現成的函式，甚至是一個 HTML 網頁原型。
官方的經驗是，一個 HTML 排版原型的效果，通常好過一段文字描述或一張截圖。你甚至可以把自己的品味寫成評分準則（rubric），例如「一份好的 API 設計長什麼樣」，讓模型拿著這份準則生出驗證代理，自我把關。白話說，與其用文字描述你要什麼，不如直接丟一個「長這樣」的實物給它看。
最後附上 Shihipar 原文六組對照的完整清單，方便你逐項檢視手上的設定：
| 構面 | 舊做法（Then） | 新做法（Now） |
|---|---|---|
| 行為約束 | 給 Claude 立規矩 | 讓模型用判斷力 |
| 工具示範 | 給 Claude 大量範例 | 設計清楚、有表達力的工具介面 |
| 資訊載入 | 把資訊全塞在最前面 | 漸進式揭露，需要時才載入 |
| 指令強調 | 重要指令重複講 | 指令只寫在工具描述，講一次就好 |
| 記憶維護 | 用 CLAUDE.md 手動存記憶 |
自動記憶分擔手動保存 |
| 規格描述 | 規格寫成簡單文字檔 | 提供高保真參照物：測試碼、HTML 原型、Rubric |
你的 CLAUDE.md 和 Skills，可以這樣改
回到多數使用者最關心的兩個檔案，這些建議可以整理成三個動作。
動作一：CLAUDE.md 大瘦身**
用一小段講清楚這個專案是做什麼的，把主要篇幅留給模型無法直接從專案看出的東西：特殊慣例、限制與常見陷阱。
因此，需要每個工作階段都遵守的持續性規則，像建置與測試指令、程式規範、專案架構、命名慣例與工作流程，依 Claude Code 記憶功能文件的定位，仍然屬於這裡；但凡是 AI 自己翻專案就能發現的事，一律刪掉。
官方文件也給出具體門檻：指令要具體、簡潔、彼此不矛盾，每份
CLAUDE.md以 200 行以內為目標。另外，你不必再把所有臨時偏好與工作心得手動塞進
CLAUDE.md：Claude Code 的自動記憶功能（2.1.59 版以上，預設開啟、可關閉）會讓 Claude 從除錯經驗、被糾正的偏好中自行累積筆記。兩者是互補而非取代，需要穩定約束模型行為的專案規則，仍應寫在CLAUDE.md。
動作二：Skills 寫觀點，不寫百科
官方對 Skills 的定位是「輕量的指南」，幫模型在需要時找到資訊；除了少數高度重要的領域，避免寫成綁死的操作規範。
最有價值的 Skills，是把你個人、團隊或產品獨有的觀點、知識與最佳實務編寫進去。太長的技能檔一樣適用漸進式揭露，拆成多個檔案、分層載入。
動作三：用 /doctor 自動體檢
如果不知道從哪裡下手，可以先在 Claude Code 輸入 /doctor 指令。依官方文件說明，它會檢查安裝健康度、設定檔是否有效、有沒有閒置的擴充，並找出
CLAUDE.md裡模型可自行從程式碼庫推導的內容，提出修剪建議，經你確認後才套。Shihipar 也在部落格中建議用它評估 Skills 與
CLAUDE.md是否需要「調整到合身」。它給的是診斷與建議，最終怎麼改，仍由你決定。
這些新守則，同樣有保鮮期
有兩點注意事項要先說：
第一，這套新守則的前提是「Claude 5 世代的新模型」。Shihipar 明講，舊模型少了這些護欄，寫出來的註解在很多情境會出錯；如果你或團隊還在用較舊的模型，貿然刪光規則，等於拆掉當初防止翻車的護欄。
第二，「讓模型自己判斷」不等於什麼都不用寫，官方自己也為「高度重要領域」保留了嚴格約束的空間；哪些領域重要到不能交給判斷力，仍然需要人來決定。
這篇文章更深一層的訊息或許是：**提示詞技巧的折舊速度，本身就是新常態。**過去一年的最佳實務，如今成了官方點名的迷思；這批新守則，也可能在下一代模型登場時失效。
而與模型能力一起演進的，不只是 AI 能做的事，還有人跟 AI 說話的方式：它越來越不像寫程式，更像帶一位能力很強的新同事。先講清楚目標，再交出判斷權；先給看得懂的實物，再談抽象規則；先把手冊瘦身，再讓他自己翻資料。
資料來源：Anthropic 官方部落格、Anthropic 工程團隊文章、Claude Code 記憶功能文件、Claude Code Skills 文件、Claude Code 組態診斷文件
本文初稿為AI編撰，整理．編輯/ 李先泰
