Anthropic 在 2026 年 7 月宣布：他们为 Claude Opus 5、Claude Fable 5 这一代模型，删掉了 Claude Code 超过 80% 的系统提示词——编码评测上没有任何可测量的性能下降。
这不是一次代码清理，而是一个信号。如果你只带走一句话，就带走这个：
写给模型的每一条规则，都是在给当时模型的某块短板打补丁。补丁是有保质期的负债：模型变强之后，旧补丁不会自动失效，它会变成新的约束，反过来限制模型发挥。
原文是 Anthropic 技术团队 Thariq Shihipar 发布的 The new rules of context engineering for Claude 5 generation models。这篇不做逐段翻译，我们追一条主线：为什么”删规则”反而让 agent 变强了？ 然后你会看到，这件事其实是 AI 史上最著名的一课——苦涩的教训（The Bitter Lesson）——第一次在提示词这一层完整重演。
先分清两个词：prompting 和 context engineering
原文开头就做了一个区分，值得先说清楚。
Prompting（提示） 是针对一次请求写的话：“帮我重构这个函数，不要改公共接口”。它只服务这一次任务，可以写得非常具体。
Context engineering（上下文工程） 是你为所有请求预先铺设的环境：系统提示词、工具定义、技能文件、参考资料。同一套上下文要接住成千上万种不同的用户请求，所以它天然不能太具体——你在为一个还不存在的任务写说明书。
这就是问题的根源。说明书写得越细，撞上例外的概率越高。
为什么删：规则会互相打架
Anthropic 给了一个来自真实内部 transcript 的例子。在同一次请求里，模型同时收到了两条指令：
- 系统提示词某处说：“DO NOT add comments”（不要写注释）；
- 另一处（skill 或用户指令）说：“leave documentation as appropriate”（酌情保留文档）。
系统提示词、技能文件、用户请求各写各的规则，叠在同一个上下文里，冲突不可避免。模型通常能猜出用户真正想要什么——但它必须额外消耗推理能力去调解这些矛盾，而不是把推理花在任务本身上。
这些规则当初为什么存在？因为老一代模型需要护栏来防止最坏行为（比如乱删文件、注释写得铺天盖地）。护栏挡住了最坏情况，代价是也挡住了一部分正确行为——这在当时是划算的交易。但新一代模型已经能靠周围上下文和自身判断处理这些情况，交易的价码变了：护栏防住的错误越来越少，误伤的正确行为越来越多。 于是删。
五个 Then vs Now：每一条旧规则背后都有一块已经消失的短板
原文列了五组”过去 vs 现在”的实践转变。逐条看，你会发现每一条”过去的最佳实践”都对应老模型的一块具体短板——而转变发生的原因，全都是那块短板不在了。
1. 过去：给模型定规则 → 现在：让模型用判断力
旧版 Claude Code 提示词里有这样的硬规则：“写代码时默认不写注释”、禁止多段 docstring。这条规则对很多场景是错的（有的用户就是要文档，复杂代码就是需要长注释），但对老模型来说，一条一刀切的规则好过放任它注释失控。
新版的替代写法只有一句：
“Write code that reads like the surrounding code: match its comment density, naming, and idiom.” （写出和周围代码读起来一致的代码：匹配它的注释密度、命名和习惯用法。）
注意这个转变的本质：从规定”做什么”，变成给出”依据什么判断”。 规则枚举答案，原则交出判断标准。答案会过时会冲突，判断标准不会。
2. 过去：给模型看例子 → 现在：设计好接口
Few-shot 示例曾经是提示工程的头号技巧——这有历史根源，GPT-3 论文《Language Models are Few-Shot Learners》证明了大模型光靠上下文里的几个例子就能学会新任务，从此”多给例子”成了行规。
但原文指出，对新模型，例子”实际上把它约束在了一个特定的探索空间里”。模型会模仿例子的形态，包括例子里无关紧要的巧合。
替代方案是把意图编码进接口本身。原文举了 Claude Code 的 Todo 工具：它的 status 参数是一个枚举 pending / in_progress / completed。这个枚举本身就在说话——任务有三种状态、状态会流转；再补一句”同一时刻只有一项应该是 in_progress”，期望的使用方式就完整定义了，一个例子都不用给。
用 AI 原理的话说，这是”表示决定成败”：与其用例子示范行为，不如把约束长进数据结构里。类型系统比代码注释可靠，同理，参数 schema 比 few-shot 例子可靠。
3. 过去：所有信息前置 → 现在：渐进披露（progressive disclosure）
代码审查、验证流程这类说明，过去全部塞在系统提示词里——不管这次请求用不用得上。现在它们被移进按需调用的 skill 文件；一部分工具甚至是延迟加载的：agent 需要时通过 ToolSearch 查到完整定义，平时不占上下文。
这条转变的根本约束是：上下文是稀缺资源，而且不是均匀可用的。Lost in the Middle（Liu et al., 2023）量化过这件事：长上下文中间部分的信息，模型的利用率显著低于开头和结尾。把八成时间用不到的说明常驻在上下文里，不仅烧 token，还在稀释真正重要的信息的注意力。
Anthropic 自己在 2025 年的 Effective context engineering for AI agents 里就提出把上下文当作”有限预算”来管理；这次的 80% 删减可以看作那套理念在自家旗舰产品上的极限执行。
4. 过去：重要的事说三遍 → 现在：一个地方只说一遍
老模型偏爱上下文末尾的指令，且需要重复强调才”记得住”，所以同一条工具使用规则会同时出现在系统提示词和工具描述里。新版把重复全删了：指令只活在工具描述这一个地方。
这条看似最小，实际杀伤力不小：重复是规则冲突的温床。同一条规则的两个副本，只要有一个在后续迭代中被单独修改，就制造出了第 2 节里那种自相矛盾的上下文。
5. 过去：简单的 spec → 现在：丰富的 reference
过去 Plan 模式依赖 markdown 计划文件这类简单规格说明。新模型能消化丰富得多的参考物：一个 HTML 原型页面、一套详细的测试套件、另一个代码库里要移植的函数，甚至用 rubric（评分细则）加验证 agent 来编码”什么叫好的 API 设计”这种品味问题。
原文给了一个实用的偏好排序：代码形态的 reference 通常胜过文字描述，也胜过截图——一个 HTML mockup 比一段”页面顶部有个蓝色导航栏”的描述信息密度高得多，且没有歧义。
这就是苦涩的教训，在提示词层重演
把五条放在一起看，模式就浮出来了。
Rich Sutton 在 2019 年的 The Bitter Lesson 里总结了 70 年 AI 史的规律：依赖人类手工注入知识的方法，短期领先，长期总是被”通用方法 + 更多算力”碾过去。 手写特征输给了学出来的特征，手写规则输给了端到端学习。
系统提示词里的行为规则，正是这个时代的”手工注入知识”：
flowchart LR
A["手写特征<br/>（CV/NLP 时代）"] -->|"被深度学习取代"| B["学出来的表示"]
C["手写行为规则<br/>（系统提示词时代）"] -->|"被模型判断力取代"| D["原则 + 接口 + 按需信息"]
A -.同一个模式.- C每一代人都会为当时模型的短板写补偿逻辑，每一代人都倾向于高估这些补偿逻辑的寿命。特征工程师当年不相信卷积网络能自己学出比 SIFT 更好的特征；今天的提示词工程师也容易不相信模型能在没有 40 条规则的情况下把注释写对。Anthropic 这次给出的证据是干脆的：删掉 80%，评测零损失。
但注意——苦涩的教训的正确读法从来不是”人类知识没用”，而是”把人类知识放在能随模型能力扩展的位置”。这正是五条转变的共同结构：知识没有消失，它换了存放的形态——
- 从规则搬进了原则（可随场景伸缩）；
- 从例子搬进了接口 schema（约束长在结构里）；
- 从常驻提示词搬进了按需加载的 skill（不占预算）；
- 从文字 spec 搬进了代码形态的 reference（无歧义、可验证）。
怎么用到你自己的 agent 上：三层各管一件事
原文最后给了一个三层框架，回答”那我的上下文该往哪放什么”：
| 层 | 放什么 | 谁该重点投入 |
|---|---|---|
| 系统提示词 | 产品上下文：模型在什么产品里、面对什么任务 | harness/平台的构建者 |
| Skills | 团队或产品特有的做法与偏好，轻量索引式，帮模型找到信息而不是背下信息 | 团队与个人 |
| References | @-提及的具体文件：spec、mockup、测试套件、整个代码库 | 每一次具体任务 |
三条落地建议，都直接来自原文：
- Skill 别写成法典。 除了少数关键领域，避免过度约束；长 skill 拆成多个文件，让模型渐进披露地按需读取。
- 偏好代码形态的 reference。 要描述一个页面，给 HTML mockup；要描述一个行为，给测试用例。
- 系统提示词只写”你是谁、在哪、干什么”。 行为细节交给判断力、接口和 skill。
该泼的冷水：什么时候你仍然应该写死规则
读到这里，一个自然的反应是”那我把 CLAUDE.md 里的规矩全删了？“——别。这次删减有几个不能忽略的前提条件。
第一，“删掉规则”的前提是换了更强的模型。 原文说得明确：这套新规则是为 Claude 5 代模型的。如果你的 agent 跑在小模型或上一代模型上，那些规则补的短板还在，删了补丁伤口就露出来。规则该不该删，取决于模型，不取决于潮流。
第二，Anthropic 是删一刀测一刀的。 “无可测损失”是评测体系给出的结论，不是信仰给出的。你没有评测集，就没有资格删——先建评测，再做减法。
第三，有一类规则永远不该交给判断力：不可逆操作的边界。 “不要 force push 到 main”、“删数据前必须确认”——这类规则的价值不在于模型猜不到，而在于把最坏情况的概率钉死为零。判断力是概率性的，护栏是确定性的。安全边界要的是后者。
所以更准确的结论是灰度的：模型越强、操作越可逆、你的评测越完善，就越应该用原则替代规则；反之则保留护栏。
收束：给你的每条 prompt 规则做一次体检
把全文压缩成一个可复用的操作：翻开你的系统提示词或 CLAUDE.md，对每一条规则问三个问题——
- 这条规则在补模型的哪块短板？（说不出来的，多半是从别人模板里抄来的货物崇拜）
- 这块短板在你现在用的模型上还存在吗？（用评测验证，不要用直觉）
- 删掉它，最坏情况是什么？可逆吗？（不可逆的留下，可逆的删掉试试）
三个月后模型再升级一代，把这套体检再跑一遍。上下文工程从来不是写一份完美说明书，而是维护一份随模型能力持续做减法的说明书——这大概是这篇官方博客真正想教的事。
延伸阅读
- 原文：The new rules of context engineering for Claude 5 generation models（Thariq Shihipar, Anthropic, 2026-07）
- The Bitter Lesson（Rich Sutton, 2019）——理解本次转变的历史框架
- Effective context engineering for AI agents（Anthropic, 2025）——“上下文是有限预算”的前作
- Language Models are Few-Shot Learners（Brown et al., 2020）——“给例子”这条旧规则的历史起点
- Lost in the Middle: How Language Models Use Long Contexts（Liu et al., 2023）——为什么”全部前置 + 重复”曾经是必要的