Claude Code砍掉80%系統提示詞？實際是Opus 5又補回了72%
整理版優先睇
Claude Code 提示詞大砍80%後反彈72%？真相係動態平衡嘅上下文工程
呢篇文章係由開發者陳成透過抓包Claude Code CLI嘅真實請求，揭示Anthropic宣傳嘅「砍掉80%系統提示詞」背後更細膩嘅真相。原本大家以為Claude 5時代直接大刪規則，但實際係Opus 4.8大幅精簡到4,467字符，Opus 5上線後反而反彈到7,694字符，增幅約72%。作者想解決嘅問題係：點解會出現呢個反彈？呢個變化對AI開發者嘅上下文工程實踐有咩啟示？整體結論係：提示工程唔係越短越好，而係要追求最優信號密度，根據模型能力動態調整。
Opus 5嘅反彈係因為新模型有更高主動性同判斷力，但同時帶嚟新副作用，例如「過度解釋錯誤」。Anthropic用針對性規則（如#Delivering work同#Corrections）進行微調，而唔係一刀切。呢個案例證明模型能力唔係線性提升，提示工程係一個持續迭代嘅動態平衡過程。
對我哋普通開發者嚟講，呢個事件係一面鏡子：要定期審計自己嘅CLAUDE.md同Skills，勇敢刪除冗餘；針對Opus呢類強模型，傾向判斷導向規則而唔係硬性指令；用漸進披露嘅方式將詳細指導放喺Skills入面按需加載；同時留意新模型可能出現嘅新failure mode，及時加入Corrections。核心係將上下文工程視為「注意力預算管理」，持續迭代。
- 結論：Claude Code提示詞砍80%只係Opus 4.8嘅極致情況，Opus 5反彈72%，真正做法係動態調整。
- 方法：開發者陳成透過抓包CLI請求，拎到實際提示詞長度變化，揭露真相。
- 差異：Opus 5新增針對性規則（#Delivering work、#Corrections等），因為更聰明但出現新副作用。
- 啟發：提示工程唔係越短越好，而係追求最優信號密度，要動態平衡。
- 行動點：定期用/doctor審計，刪冗餘；對強模型用判斷導向規則；關注新failure mode。
/doctor 命令
Claude Code 內置命令，用嚟審視Skills同CLAUDE.md，幫你刪除冗餘或衝突嘅內容。
真實數據：砍在4.8，反彈在5
Anthropic工程師Thariq上週分享話Claude Code嘅系統提示詞砍咗80%以上，編碼成績無損失。但開發者陳成透過將CLI指向本地服務器捕獲真實流量，發現真相唔係咁簡單。
Opus 4.7：15,225字符
到Opus 4.8大幅精簡到4,467字符，主要刪除通用行為規則，例如# Doing tasks、# Executing actions with care等大段內容。
Opus 5：7,694字符
比4.8反彈約72%，但手寫策略正文部分精簡比例仍可達81%。另一個獨立驗證（Paweł Huryn）指出，宣傳嘅「80%」接近memory-off場景嘅極致值，實際整體精簡更接近70%。
點解會加返？動態平衡嘅智慧
提示工程係動態平衡
唔係越短越好，而係最優信號密度。過少會失控，過多則互相衝突、浪費token、增加決策負擔。
條件加載嘅智慧
好多規則而家係動態嘅（根據model id、capability、memory開關等），體現咗漸進式披露 progressive disclosure 嘅實踐。
對開發者嘅啟示：點樣更新自己嘅上下文工程
- 1 定期審計，勇敢刪除：用/doctor命令審視Skills同CLAUDE.md，刪掉冗餘、衝突或「顯而易見」嘅內容。優先保留項目特有gotchas。
- 2 匹配模型能力：針對Opus呢類強模型，傾向判斷導向而唔係規則導向。例如，將「絕不寫註釋」改為「匹配周圍代碼風格」。
- 3 漸進披露 + 動態規則：將詳細指導移到Skills，按需加載；用條件邏輯或子提示處理唔同模型/場景。
- 4 關注新問題：新模型可能出現新failure mode（如過度解釋），及時添加針對性Corrections，而唔係堆積通用規則。
- 5 測試為王：唔好只睇token數或主觀感受，要跑自己嘅編碼/任務評估集，量化影響。
核心要點：注意力預算管理
上下文工程唔係一次性優化
而係持續迭代嘅「注意力預算管理」。Anthropic內部都係邊飛邊修，呢個係前沿工程嘅常態。
從15k+到4.4k再到7.6k，呢個小反彈比單純嘅「大砍」故事更真實、更有營養。你準備好為Opus 5「瘦身」你嘅上下文未？
上星期分享過Anthropic工程師Thariq嘅一篇《Claude 5時代上下文工程新規則》，核心爆點係：佢哋為Opus 5、Fable 5等前沿模型砍咗Claude Code系統提示嘅80%以上，編碼評估成績卻毫無損失。呢個被解讀為「鬆綁Claude，讓模型用自有判斷力」。Claude 5時代：80%系統提示詞被砍咗，上下文工程嘅6大新規則+落地指南
然而，故事並冇結束。好快，開發者 陳成（@chenchengpro） 通過抓包Claude Code CLI嘅實際請求，揭開咗更細膩嘅真相：其實大砍主要發生喺 Opus 4.8，而Opus 5上線之後，提示詞長度反而反彈咗約 72%。
呢個唔係「推翻」，而係更真實嘅進化過程，值得AI開發者細味。
真實數據：砍喺4.8，反彈喺5
根據陳成嘅抓包實測（將CLI指向本地服務器捕獲真實流量）：
• Opus 4.7：15,225 字符 • Opus 4.8：4,467 字符（大幅精簡，主要刪除通用行為規則，例如# Doing tasks、# Executing actions with care等大段） • Opus 5：7,694 字符（較4.8反彈約72%）
精簡比例確實驚人（手寫策略正文部分可達81%），但並非「一砍到底」。Opus 5新增咗 # Delivering work（約2,019字符）同 # Corrections（約1,736字符）等專屬內容，主要係為咗應對新模型出現嘅特定問題，例如「反覆解釋錯誤」等行為。
另一個獨立驗證（Paweł Huryn嘅分析）都指出：宣傳嘅「80%」接近memory-off場景下嘅極致值，實際整體精簡更接近70%，而且係前沿模型專屬嘅精簡（Sonnet、Haiku等仍保留較多舊規則）。
點解會「加返嚟」？
呢個正係最有啓發嘅地方：
1. 模型能力唔係線性提升：更聰明嘅模型確實需要更少嘅通用規則（「unhobbling」），但新能力都可能帶嚟新副作用。Opus 5更主動、更具判斷力，同時都更容易喺某些場景下「過度解釋」或者重複糾錯。Anthropic用針對性規則進行微調，而唔係一刀切。 2. 提示工程係動態平衡：唔係越短越好，而係「最優信號密度」。過少會導致失控，過多則互相衝突、浪費token、增加模型決策負擔。 3. 條件加載嘅智慧：好多規則而家係動態嘅（根據model id、capability、memory開關等），而唔係靜態大塊。呢個體現咗漸進式披露progressive disclosure嘅實踐。
Anthropic官方觀點依然成立：越強嘅模型，需要嘅顯式指令越少。如果你發現自己嘅CLAUDE.md越來越長，可能說明你喺為「較弱模型」寫規則，而唔係充分利用當前前沿能力。
對我哋嘅啓示：如何更新自己嘅上下文工程？
呢次事件唔係「Anthropic打臉自己」，而係提供咗一面鏡子：
• 定期審計，勇敢刪除：用 /doctor命令（Claude Code內置）審視Skills同CLAUDE.md，刪掉冗餘、衝突或「顯而易見」嘅內容。優先保留項目特有gotchas（坑點）。• 匹配模型能力：針對Opus 5/Fable 5等強模型，傾向「判斷導向」而唔係「規則導向」。例如，將「絕不寫註釋」改為「匹配周圍代碼風格」。 • 漸進披露 + 動態規則：將詳細指導移到Skills，按需加載；用條件邏輯或子提示處理不同模型/場景。 • 關注新問題：新模型可能出現新failure mode（例如過度解釋），及時添加針對性Corrections，而唔係堆積通用規則。 • 測試為王：唔好淨係睇token數或主觀感受，要去跑自己嘅編碼/任務評估集，量化影響。
核心要點：上下文工程唔係一次性優化，而係持續迭代嘅「注意力預算管理」。Anthropic內部都喺邊飛邊修，呢個正係前沿工程嘅常態。
寫喺最後
從15k+到4.4k再到7.6k，呢個小反彈比單純嘅「大砍」故事更真實、更有營養。佢提醒我哋：模型喺進化，我哋嘅工程實踐都必須隨之進化。唔好迷信「越少越好」，而係要追求「恰到好處」，為當前模型提供最精煉、高信號嘅上下文。
保持好奇，持續迭代。你準備好為Opus 5「瘦身」你嘅上下文未？🚀
上週分享過 Anthropic 工程師 Thariq 的一篇《Claude 5 時代上下文工程新規則》，核心爆點是：他們為 Opus 5、Fable 5 等前沿模型砍掉了 Claude Code 系統提示的 80% 以上，編碼評估成績卻毫無損失。這被解讀為“鬆綁 Claude，讓模型用自有判斷力”。Claude 5時代：80%系統提示詞被砍掉，上下文工程的6大新規則+落地指南
然而，故事並沒有結束。很快，開發者 陳成（@chenchengpro） 通過抓包 Claude Code CLI 的實際請求，揭開了更細膩的真相：其實大砍主要發生在 Opus 4.8，而 Opus 5 上線後，提示詞長度反而反彈了約 72%。
這不是“推翻”，而是更真實的進化過程，值得 AI 開發者細品。
真實數據：砍在 4.8，反彈在 5
根據陳成的抓包實測（將 CLI 指向本地服務器捕獲真實流量）：
• Opus 4.7：15,225 字符 • Opus 4.8：4,467 字符（大幅精簡，主要刪除通用行為規則，如 # Doing tasks、# Executing actions with care 等大段） • Opus 5：7,694 字符（較 4.8 反彈約 72%）
精簡比例確實驚人（手寫策略正文部分可達 81%），但並非“一砍到底”。Opus 5 新增了 # Delivering work（約 2,019 字符）和 # Corrections（約 1,736 字符）等專屬內容，主要為了應對新模型出現的特定問題，例如“反覆解釋錯誤”等行為。
另一個獨立驗證（Paweł Huryn 的分析）也指出：宣傳的“80%”接近 memory-off 場景下的極致值，實際整體精簡更接近 70%，且是前沿模型專屬的精簡（Sonnet、Haiku 等仍保留較多舊規則）。
為什麼會“加回來”？
這正是最有啓發的地方：
1. 模型能力不是線性提升：更聰明的模型確實需要更少的通用規則（“unhobbling”），但新能力也可能帶來新副作用。Opus 5 更主動、更具判斷力，同時也更容易在某些場景下“過度解釋”或重複糾錯。Anthropic 用針對性規則進行微調，而不是一刀切。 2. 提示工程是動態平衡：不是越短越好，而是“最優信號密度”。過少會導致失控，過多則互相沖突、浪費 token、增加模型決策負擔。 3. 條件加載的智慧：許多規則現在是動態的（根據 model id、capability、memory 開關等），而非靜態大塊。這體現了漸進式披露 progressive disclosure 的實踐。
Anthropic 官方觀點依然成立：越強的模型，需要的顯式指令越少。如果你發現自己的 CLAUDE.md 越來越長，可能說明你在為“較弱模型”寫規則，而非充分利用當前前沿能力。
對我們的啓示：如何更新自己的上下文工程？
這次事件不是“Anthropic打臉自己”，而是提供了一面鏡子：
• 定期審計，勇敢刪除：用 /doctor命令（Claude Code 內置）審視 Skills 和 CLAUDE.md，刪掉冗餘、衝突或“顯而易見”的內容。優先保留項目特有 gotchas（坑點）。• 匹配模型能力：針對 Opus 5/Fable 5 等強模型，傾向“判斷導向”而非“規則導向”。例如，把“絕不寫註釋”改為“匹配周圍代碼風格”。 • 漸進披露 + 動態規則：把詳細指導移到 Skills，按需加載；用條件邏輯或子提示處理不同模型/場景。 • 關注新問題：新模型可能出現新 failure mode（如過度解釋），及時添加針對性 Corrections，而非堆積通用規則。 • 測試為王：不要只看 token 數或主觀感受，要去跑自己的編碼/任務評估集，量化影響。
核心要點：上下文工程不是一次性優化，而是持續迭代的“注意力預算管理”。Anthropic 內部也在邊飛邊修，這正是前沿工程的常態。
寫在最後
從 15k+ 到 4.4k 再到 7.6k，這個小反彈比單純的“大砍”故事更真實、更有營養。它提醒我們：模型在進化，我們的工程實踐也必須隨之進化。不要迷信“越少越好”，而是要追求“恰到好處”，為當前模型提供最精煉、高信號的上下文。
保持好奇，持續迭代。你準備好為 Opus 5 “瘦身”你的上下文了嗎？🚀