砍掉 80%，同時長到兩萬字：
Anthropic 把 system prompt 往兩個相反方向調

摘要

Claude Code：砍掉 80%

一手來源是 2026 年 7 月 21 日公開的一份逐字稿。Simon Willison 在 AI Engineer World's Fair 主持了一場爐邊對談，對象是 Anthropic Claude Code 團隊的 Cat Wu 與 Thariq Shihipar。這個數字是在對談中由兩位團隊成員親口確認的，不是二手推測。

這裡有個容易被漏掉的前提：這個縮減並非全面套用。Cat Wu 在同一場對談中補充，只有最前沿的模型享有這個減量，較舊的模型仍然跑完整版的 system prompt。換句話說，「system prompt 應該要短」不是一條普世規則，而是綁定模型能力的工程決策。

被砍掉的到底是什麼

一、範例

這是最反直覺的一項。「給模型範例」幾乎是所有 prompt engineering 教學的第一課，Simon 當場也說這打破了他的心智模型——他一直是這條建議的推廣者。

機制其實很單純：範例同時是示範，也是天花板。當你給模型三個範例，你等於在說「我要的東西長這樣」，於是模型的輸出會向這三個樣本收斂。對能力不足的模型，這個收斂是救命的；對能力已經超過你範例的模型，這個收斂是損失。

二、「不要做 X」

第二項被砍的是負面指令。Thariq 指出，硬約束對 Claude 而言是「非常強的衝動」，而問題出在衝突：system prompt 裡的禁令會跟後面使用者自己的指令打架。

對照一下你自己的 CLAUDE.md 或專案規則檔，這一條大概是最容易立刻套用的：如果裡面有一長串「不要用 X」「絕對不能 Y」，而你又常常在對話裡要求例外，那你正在製造 Thariq 描述的那種衝突。

三、順帶一提，OpenAI 也給了同方向的建議

這不是 Anthropic 一家的觀察。Simon 在同一篇文章中引用了 OpenAI 針對 GPT-5.6 的 prompting 最佳實踐，內容方向一致：移除重複的指令與範例、簡化工具描述，可同時改善任務表現與 token 效率。OpenAI 給出的內部評測數字是評分提升約 10–15%、總 token 減少 41–66%、成本下降 33–67%。

claude.ai：完全相反的方向

如果「越新的模型越不需要指令」是普世趨勢，那 Anthropic 自家消費端產品的 system prompt 應該也在變短。實際上並沒有。

Anthropic 在官方 release notes 長期公開 claude.ai 網頁介面與 iOS／Android App 的核心 system prompt。這裡有個關鍵的制度變化讓比較變得乾淨：從 Claude 4.6 世代起，每個 model ID 對應單一固定快照，不再有「同一個模型多個日期版本」。於是 4.6 之後的六個模型，每個剛好就是一份、可以直接比長度。

結論很清楚：半年間、跨越四個世代，claude.ai 的 system prompt 在兩萬字元上下盤整，沒有出現任何接近 80% 的縮減。最長的一份出現在 Opus 4.7（2026-04），之後小幅回落，如此而已。

拉長來看更明顯。Claude 3 世代的 Haiku 3 系統提示只有 736 字元、Opus 3 是 2,142 字元。也就是說，這份 prompt 在兩年多間長了大約三十倍。

而且不只是長，是硬

更關鍵的是內容風格。Claude Code 拿掉的正是「不要做 X」，但 claude.ai 這份裡，這種寫法是骨幹。以下摘自 Claude Opus 5 的官方快照（2026-07-24）：

摘自 Claude Opus 5 system prompt，2026-07-24 官方快照。原文為英文，此處為節錄。

整份文件裡，這類負面約束（does not、avoids、should not、doesn't 等）出現數十次，涵蓋武器、惡意程式、心理健康、政治立場、未成年人保護等。這正是 Claude Code 那邊被判定為「會造成混亂」而移除的寫法。

為什麼這兩件事不矛盾

把兩邊並排，差異不在模型，而在使用者是誰、以及猜錯的代價由誰承擔。

Claude Code 的減法之所以成立，是因為它有一個 claude.ai 沒有的東西：一個知道自己要什麼、而且看得到結果的人坐在前面。那個人本身就是最好的約束機制，所以 system prompt 可以退位、把判斷權交還給模型。

claude.ai 沒有這個條件。它的 system prompt 必須同時當說明書、當安全網、當危機處理流程——而且是對一個你完全不認識的人。這種情況下，「更少指令、更多脈絡」不是選項。

可以帶走的判準：90% 正確的指令 × 100% 的場次

整場對談裡最實用的一段，是 Cat Wu 講他們重新審視 Claude Code system prompt 時用的檢查方式。這條判準跟模型世代無關，套在任何 prompt 上都成立：

他們舉的實例是「驗證」。原本的指令是：做了前端修改就一定要驗證。聽起來完全正確——誰不希望模型驗證自己的工作？但 Cat 指出反例：如果只是把一個字串改成另一個字串，而使用者說「快速修一下、順便更新測試」，那可能就不需要跑起來驗證。

於是措辭從「永遠驗證、驗證、驗證」改成接近這樣：多數情況下做前端工作時，光打後端 endpoint 無法真正理解使用者體驗，所以當你對使用者體驗做出較大改動時，請在本地把應用跑起來。

而 Cat 自己接著說，這條大概也還不夠好——什麼叫「較大改動」？也許小改動也該測。這個自我拆解本身就是示範：一條指令的品質，取決於它在多少比例的場次裡真的成立。

套用到你自己的 CLAUDE.md

把上面幾條合起來，對一般使用者最直接的意義是這四件事：

1. 先問你在哪一邊

如果你寫的是專案規則檔（CLAUDE.md、AGENTS.md、cursor rules 之類），你的處境跟 Claude Code 團隊一樣——使用者是你自己，任務明確，出錯你看得到。那就適用減法：少寫禁令，多寫脈絡。

如果你在做一個面對不特定使用者的產品，你的處境接近 claude.ai。那份又長又硬的 prompt 才是你的參考範本，不是 Claude Code。

2. 把「不要做 X」改寫成「這件事的情況是 Y」

這是 Thariq 那條建議的可執行版本。與其寫「不要用 any」，不如寫「這個 codebase 的型別檢查設定為 strict，任何 any 都會讓 CI 失敗」。後者是脈絡，模型可以據此推理出例外情況；前者是禁令，遇到你自己要求的例外時就會打架。

3. 檢查每一條規則的例外率

逐條套 Cat 的問題：這條在多少比例的情況下成立？如果答案是「大部分」而不是「全部」，就把它放軟，或補上適用範圍。

4. 別直接照抄 80%

這是最容易犯的錯。80% 是 Anthropic 針對自家 Claude Code、自家評測、自家最前沿模型測出來的結果。他們自己都沒有把它套用到舊模型上（舊模型仍跑完整版）。你的 prompt 該砍多少，只有你自己跑 A／B 才知道。

那個「800 → 164 tokens」是假的

這則消息在中文與英文圈流傳時，通常會附上一組很具體的數字：從約 800 tokens 砍到 164 tokens，釋出約 636 tokens 的空間。數字越具體越可信，但這組數字查不到出處。

更值得注意的是，二手報導在追逐那組假數字的同時，漏掉了三件真正影響判讀的事：

• 不只是 Fable 5。Thariq 明確說 Opus 4.8 也適用，未來模型也會。報導普遍寫成「因為 Fable 5」。
• 只有前沿模型享有。Cat 明確說舊模型仍跑完整版。報導普遍寫成全面套用，讀者容易推論成「system prompt 都該砍短」。
• 被砍的是範例與硬約束。這是唯一能拿來改善自己 prompt 的資訊，而它在多數報導裡被壓縮成一句「刪掉了冗餘指令」。

這是一個乾淨的案例：當一則 AI 新聞給你一個很具體的數字時，先確認那個數字出現在哪一手。百分比通常來自受訪者，絕對數字則常常是轉述者為了讓報導更有畫面感而自行補上的。

常見問題

結論

「新模型需要更少指令」這句話正在被大量轉述，但它有一個幾乎總是被省略的前提：更少指令的前提是有人在旁邊看著。

Claude Code 敢把 system prompt 砍掉 80%，是因為每一次執行都有一個知道自己要什麼的工程師坐在前面驗收。claude.ai 不能這樣做，因為它面對的是不特定的陌生人，而且沒有人會在旁邊確認結果對不對。同一家公司、同一世代模型，兩個產品因此往相反方向走——這不是策略搖擺，是條件不同。

所以下次看到「prompt 應該更短」這類建議時，先問一句：短的那個版本，是誰在承擔猜錯的成本？如果是你自己，那就放心砍；如果是別人，那份又長又硬的 claude.ai system prompt，才是你該研究的範本。