不是規則都能刪

Anthropic 公開了一個很容易讓人誤讀的數字：針對 Claude Opus 5、Claude Fable 5 等較新模型，Claude Code 的 system prompt 被移除超過 80%，而官方 coding evaluations 沒有出現可量測的表現損失。

看到這裡，最直覺的結論可能是：「原來 prompt 寫越短越好。」

但這正是最危險的誤解。

Anthropic 並不是說規則不再重要，也不是證明每個團隊都能把安全、權限、資料邊界與專案慣例刪掉八成。它真正揭露的是另一個問題：當 system prompt、專案規則、Skills、記憶、工具說明與使用者要求全部擠進同一份上下文，更多文字不一定帶來更多控制，反而可能製造重複、衝突與注意力成本。

為什麼規則越多，AI 反而可能越難做事

想像同一個 coding agent 同時收到這些指令：

• 系統提示詞要求「視情況補充文件」。
• 專案規則要求「不要新增文件」。
• Skill 規定任何修改都要執行完整驗證。
• 使用者只要求修正一個錯字。
• 工具說明已寫過使用方法，但 system prompt 又放了另一版範例。

每一句單獨看都可能合理，放在一起卻需要模型先判斷誰優先、哪些只適用特定情境、哪些已經過時。

這就是 context engineering 的核心：問題不只在「寫了什麼」，也在「放在哪裡、何時載入、是否重複，以及是否跟其他指令衝突」。

80% 的數字到底證明了什麼

官方說法有兩個重要限定。

第一，精簡的是 Claude Code 對較新 Claude 5 世代模型使用的 system prompt。這不是所有產品、所有模型與所有團隊的通用比例。

第二，官方觀察的是 coding evaluations 沒有可量測的損失。這不等於所有任務都完全一樣，更不代表刪除任何規則都沒有風險。

所以正確 takeaway 不是「照著刪 80%」，而是先盤點哪些文字只是舊模型時代留下的支架，哪些才是模型無法從環境自行推得的真實邊界。

從常駐規則改成按需載入

Anthropic 提到的關鍵方向之一是 progressive disclosure，也就是讓模型在真正需要時才載入專門資訊。

例如 code review、verification、deployment check 都非常重要，但不是每個任務都需要三套流程同時常駐。把它們拆成獨立 Skills，可以讓 coding agent 在需要審查時載入 review 規則，需要驗證時載入 verification 規則，而不是每次改一行文字都先背完整手冊。

這種做法不是減少治理，而是讓治理更精確。

哪些內容應該留在常駐上下文

常駐規則適合放模型無法自行猜到、而且跨任務長期有效的資訊：

1. 權限與資料邊界：哪些環境不能寫、哪些資料不能外流、哪些動作需要核准。
2. 專案慣例：命名、錯誤處理、檔案配置與團隊已做出的架構決策。
3. 真實 gotchas：每位新工程師都會踩到、但從檔案樹看不出來的陷阱。
4. 完成條件：什麼狀態才算交付，哪些證據不能省略。

相反地，完整 API 文件、歷史紀錄、可以直接從 source 看出的資訊，以及團隊實際上不遵守的願望式規則，都很容易成為上下文噪音。

工具設計比大量範例更重要

過去常用很多 few-shot examples 教模型怎麼呼叫工具。對能力更強的模型，過多範例可能把探索空間鎖死。

如果工具的參數名稱清楚、enum 有明確語意、錯誤訊息能指出修正方向、輸出契約穩定，模型往往不需要先閱讀十個範例。

換句話說，當 agent 老是用錯工具時，問題不一定是 prompt 不夠長，也可能是工具介面本身太含糊。

一份實用的上下文清理順序

不要先算要刪幾成，先做以下四步：

1. 找重複

搜尋同一條規則是否同時出現在 system prompt、專案規則、Skill 與工具說明。保留最接近責任邊界的單一真源。

2. 找衝突

把「總是」「絕不」「每次都要」這類強制句抓出來，確認它們是否會跟其他情境規則互相打架。

3. 重新分層

跨任務長期有效的留在常駐上下文；特定工作才需要的移到按需 Skill；工具操作細節回到工具描述；事實資料放在可查詢的 reference。

4. 用自己的評測驗證

Anthropic 的 80% 不是你的安全比例。清理前後應使用相同任務、相同模型與相同完成標準比較，確認品質、成本與失敗型態是否真的改善。

不能刪掉的東西

Context engineering 的「做減法」絕不等於移除安全邊界。

權限限制、production 寫入規則、個資與機密資料處理、法務要求、使用者明確指定、不可逆操作核准，以及可驗證的完成標準，都不是模型可以靠常識自動補齊的內容。

真正該刪的是重複、過時、互相衝突與放錯層的指令，而不是責任。

結語

提示詞工程沒有消失，只是從一句 prompt 的文字遊戲，走向整套上下文架構。

下一代 AI agent 的差距，未必來自誰寫了最長的 system prompt，而是誰能讓模型在正確時間取得正確資訊，同時看見清楚的權限、工具與驗收邊界。

當 AI 表現不穩時，與其再加一條規則，不妨先問：這條規則應該一直存在，還是只在某個工作階段出現？

查證摘要

• Anthropic 於 2026-07-24 表示，Claude Code 針對 Claude Opus 5、Claude Fable 5 等較新模型移除超過 80% system prompt，在其 coding evaluations 上沒有可量測損失。
• 官方把指令衝突、重複規則與過度限制列為問題，並提出 judgement、interface design、progressive disclosure、simple tool descriptions、auto-memory 與 rich references 等方向。
• 官方 Opus 5 prompting 文件同時保留 scope、權限與任務邊界的重要性，因此本篇不把「80%」延伸成全面刪除規則的建議。
• 主要真源：Anthropic｜The new rules of context engineering for Claude 5 generation models、Claude Platform｜Prompting Claude Opus 5、Claude Help Center｜Give Claude context: CLAUDE.md and better prompts。