Claude Code 團隊成員 Thariq Shihipar 撰文坦承，你辛苦練成的提示詞技巧，多數是舊世代模型才需要的強硬規矩。面對 Claude Opus 5 與 Claude Fable 5，官方把系統提示砍掉逾 8 成，內部編碼評測沒有出現可測量的下滑。
（前情提要：Anthropic 發布 Claude Opus 5！效能逼近 Fable 5 價格卻砍半，成最新預設模型）
（背景補充：Claude Code 新推 /goals 指令：分離執行與評估，避免 AI 代理偷懶說謊）
本文目錄
Toggle
過度約束是怎麼發生的
那些老招式，現在都成了迷思
四層分工才是新解法
Claude Code 團隊成員 Thariq Shihipar 於本週在官方部落格發文指出，他們大幅改寫了 Claude Code 的系統提示，對象是 Claude Opus 5 與 Claude Fable 5 這兩款新世代模型。他指出過去一條一條累積下來的提示詞經驗，很大一部分正在這群新模型面前已失效。
這次改動幅度不小：系統提示裡超過 8 成的內容被直接刪掉，而內部的編碼評測沒有出現可測量的下滑。這代表的是：寫得越多、管得越細，不代表 Claude 表現得越好；對新一代模型來說，經常是管得越少，反而跑得越順。
但同一道護欄擺到新模型面前，情況就變了。新版系統提示已經把那一長串規定換成一句判斷：「Write code that reads like the surrounding code」，白話說就是，註解密度、命名與慣用寫法全部跟著周圍的程式碼走。
那些老招式，現在都成了迷思
第一條最反直覺：過去團隊相信，教 Claude 用工具最好的方法是給範例，把使用情境一條條列出來。現在他們發現，範例反而把模型的探索空間鎖死在範例劃出的框框裡。更好的做法是把工具設計得更會說話：例如 Todo 工具只要把狀態列成 pending、in_progress、completed 這幾個列舉值，模型光看這組狀態就知道怎麼用，不必再靠舉例硬教。
References 這一層則優先用程式碼形式帶進來。一份 HTML 設計稿，通常比一段文字描述或一張截圖更能讓模型抓到你要的樣子。規格也可以更具體：一份詳細的測試套件，或另一個程式庫裡等著被移植的既有函式，都能直接當規格用；再進一步，還能寫成一份評分準則（rubrics），讓 Claude 動態拉出驗證用的子代理，逐項檢查成果是不是符合你要的那種品味。
官方也同步推出 claude doctor 指令，在 Claude Code 裡輸入 /doctor，就能檢查 skills 與 CLAUDE.md 是不是寫得太肥、太約束。開發者社群這陣子聊的正是同一種煩惱：裝了一堆 Skills、Plugins 與 MCP Server，又寫了一份長到看不完的 CLAUDE.md，工作都還沒開始，脈絡視窗就先被吃掉一半。
Anthropic 自曝過度約束：Claude 5 世代，管得越少越好用
Claude Code 團隊成員 Thariq Shihipar 撰文坦承，你辛苦練成的提示詞技巧，多數是舊世代模型才需要的強硬規矩。面對 Claude Opus 5 與 Claude Fable 5，官方把系統提示砍掉逾 8 成，內部編碼評測沒有出現可測量的下滑。
（前情提要：Anthropic 發布 Claude Opus 5！效能逼近 Fable 5 價格卻砍半，成最新預設模型）
（背景補充：Claude Code 新推 /goals 指令：分離執行與評估，避免 AI 代理偷懶說謊）
本文目錄
Toggle
Claude Code 團隊成員 Thariq Shihipar 於本週在官方部落格發文指出，他們大幅改寫了 Claude Code 的系統提示，對象是 Claude Opus 5 與 Claude Fable 5 這兩款新世代模型。他指出過去一條一條累積下來的提示詞經驗，很大一部分正在這群新模型面前已失效。
這次改動幅度不小：系統提示裡超過 8 成的內容被直接刪掉，而內部的編碼評測沒有出現可測量的下滑。這代表的是：寫得越多、管得越細，不代表 Claude 表現得越好；對新一代模型來說，經常是管得越少，反而跑得越順。
過度約束是怎麼發生的
Shihipar 在文章裡拆解了一個具體現場：同一次請求裡，系統提示、CLAUDE.md 與 Skills 三方的指令疊在一起，經常互相打架。例如一邊寫著「視情況保留必要的說明」，另一邊卻寫著「禁止寫程式碼註解」。Claude 得先耗力氣判斷哪一條才算數，才能真正動手。規則不是在幫模型省力，而是先製造了一層要拆解的矛盾。
這些規則不是憑空冒出來的。Claude Code 剛推出時，團隊怕的是最壞情況，例如模型誤刪檔案，所以系統提示裡塞滿強硬規定，等於替判斷力還不夠的舊模型架設護欄。舊版曾經明白寫著：預設不寫註解、禁止多段落的說明字串，除非用戶主動要求，否則不要另外生出規劃或分析用的檔案。
對當時的模型而言，這是必要的取捨。
但同一道護欄擺到新模型面前，情況就變了。新版系統提示已經把那一長串規定換成一句判斷：「Write code that reads like the surrounding code」，白話說就是，註解密度、命名與慣用寫法全部跟著周圍的程式碼走。
那些老招式，現在都成了迷思
第一條最反直覺：過去團隊相信，教 Claude 用工具最好的方法是給範例，把使用情境一條條列出來。現在他們發現，範例反而把模型的探索空間鎖死在範例劃出的框框裡。更好的做法是把工具設計得更會說話：例如 Todo 工具只要把狀態列成 pending、in_progress、completed 這幾個列舉值，模型光看這組狀態就知道怎麼用，不必再靠舉例硬教。
第二條是「全部前置」。過去系統提示習慣把程式碼審查、驗證流程的細節一次寫完，用不用得到都先塞進去，結果工作還沒開始，上下文視窗就先被占掉一大塊。現在驗證與程式碼審查被拆成可按需呼叫的 skill，部分工具說明也改成延遲載入：模型真正要用時，才透過 ToolSearch 把完整定義找出來。
這套漸進揭露的邏輯同樣適用於你自己的 CLAUDE.md：別想著把所有知識塞進一份大檔案，拆成一整棵按時機載入的檔案樹才是正解。
第三條最貼近日常操作：CLAUDE.md 的手動記憶正在被自動記憶取代。過去要靠用戶自己按下熱鍵，才把心得寫進 CLAUDE.md；現在 Claude 會自行判斷哪些內容值得留下並存成記憶。管得越細，不再等於記得越牢。
四層分工才是新解法
Shihipar 給的解法不是刪光所有規則，而是重新分配四層脈絡各自該管什麼。
System Prompt 綁的是產品邏輯，一般開發者幾乎碰不到，自己搭建代理框架的人才該把力氣花在這裡。
CLAUDE.md 保持輕量，篇幅留給程式庫裡真正的陷阱與眉角，不必寫「Claude 看一眼檔案結構就懂」的廢話
Skills 當成輕量指南，除非是極重要的領域，否則別寫得太約束，長的 skill 更要拆成多個檔案。
References 這一層則優先用程式碼形式帶進來。一份 HTML 設計稿，通常比一段文字描述或一張截圖更能讓模型抓到你要的樣子。規格也可以更具體：一份詳細的測試套件，或另一個程式庫裡等著被移植的既有函式，都能直接當規格用；再進一步，還能寫成一份評分準則（rubrics），讓 Claude 動態拉出驗證用的子代理，逐項檢查成果是不是符合你要的那種品味。
官方也同步推出 claude doctor 指令，在 Claude Code 裡輸入 /doctor，就能檢查 skills 與 CLAUDE.md 是不是寫得太肥、太約束。開發者社群這陣子聊的正是同一種煩惱：裝了一堆 Skills、Plugins 與 MCP Server，又寫了一份長到看不完的 CLAUDE.md，工作都還沒開始，脈絡視窗就先被吃掉一半。
你手上那套「規則寫越細，AI 才會越聽話」的舊經驗，擺在新一代模型面前不是加分，而是佔位置的死重。真正該問的問題，不是還能再加哪一條規則，而是哪一條規則，已經可以刪掉了。