Anthropic 最近发了一篇很有信号意义的文章：《The new rules of context engineering for Claude 5 generation models》。表面看，它讲的是 Claude Code 在 Claude Opus 5、Claude Fable 5 这类新模型上，删掉了超过 80% 的系统提示词，而在编码评测上没有可测损失。
但这篇文章真正重要的地方，不是“系统 prompt 可以少写一点”。
更准确地说，它宣告了一个转折：上下文工程正在从“给模型更多规则”，转向“给模型更好的环境”。
过去我们把 Agent 做不好，常常归因于 prompt 不够细，于是不断追加规则、反例、流程、禁令、示例。新一代模型能力上来后，这套方法开始反噬：上下文越厚，冲突越多；规则越密，模型越要先解法条，而不是解决问题。
这篇文章给出的答案是减法，但不是简单删字，而是把“规则”迁移成更可组合的系统结构：工具接口、Skills、记忆、引用文件、测试、rubric、动态 verifier，以及渐进式加载。
一、Context engineering 不是 prompt engineering 的升级版
Anthropic 在文章开头先重新定义了问题：当用户给 Claude 发一条消息时，模型看到的不只是这条 prompt。
它还会看到：
- 系统提示词；
- Skills；
CLAUDE.md；- memory；
- artifacts；
- 工具定义；
- 代码、规格、测试、设计稿等 reference。
这些东西组合起来，才是 Claude 真正工作的“上下文”。
这就是 context engineering：不是写一句更聪明的 prompt，而是设计模型每次工作时所处的信息环境。
prompt 是一次性的，通常服务于一个明确请求；context 是长期性的，会跨任务、跨会话、跨工具反复生效。正因为它更通用，也更危险：一条“永远不要写多行注释”的规则，在某些代码库里是好约束，在另一些代码库里就是坏约束；一个“不要创建规划文档”的禁令，在简单修 bug 时能减少噪音，在复杂迁移时可能直接砍掉模型最需要的外部工作记忆。
所以新问题不是“怎么把规则写得更全”，而是：哪些信息应该常驻？哪些信息应该按需加载？哪些约束应该写成自然语言？哪些约束应该下沉到工具、测试和接口里？
二、第一条新规则：从“给规则”到“让模型判断”
文章最核心的例子，是 Claude Code 旧系统提示词里曾经有类似约束：默认不要写注释，不要写多段 docstring，不要创建规划、决策或分析文档，除非用户明确要求。
这些规则在早期是必要的。模型判断力不够时，强规则能防止它过度发挥：乱写注释、制造文档垃圾、把简单任务搞复杂。
但 Anthropic 现在的判断是：对 Claude 5 这一代模型，很多这种规则已经变成“脚镣”。
因为真实任务里，正确答案往往取决于局部上下文：
- 周围代码本来就有丰富注释，那新代码也应该匹配这种风格；
- 复杂迁移需要设计文档，硬禁止文档会伤害任务完成；
- 用户要求“留下必要说明”，系统又说“不要写注释”，模型就要先处理上下文冲突。
所以新系统提示词变成更原则化的一句话：写出像周围代码一样的代码，匹配它的注释密度、命名和惯用法。
这是一种重要变化：从“显式规定行为”转向“要求模型读环境并做判断”。
对 Agent 工程来说，这意味着我们要区分两类约束：
- 安全、权限、不可逆操作这类硬边界，仍然要明确；
- 风格、组织、文档密度、实现细节这类软偏好，应该让模型从周围上下文中推断。
把软偏好写成铁律，会让强模型变笨。
三、第二条新规则：从“给示例”到“设计接口”
过去工具调用的常见最佳实践，是给模型大量示例：这个工具怎么用，参数怎么填，成功输出长什么样。
文章说，新模型上这件事也变了。示例会把模型限制在某个探索空间里。示例越多，模型越容易模仿旧路径，而不是根据任务设计新路径。
更好的方法，是把工具本身设计清楚：
- 参数名是否表达意图；
- 枚举值是否天然暗示状态机；
- 工具返回是否让下一步可判断；
- 错误信息是否足够可恢复；
- 关键行为是否由接口约束，而不是靠 prompt 叮嘱。
Anthropic 举了 Todo 工具的例子：如果 status 只有 pending、in_progress、completed，并且规定最多一个 in_progress，模型其实已经从接口里读到了工作流。
这句话对所有 Agent 产品都很关键：工具 schema 本身就是 prompt。
甚至更进一步：好的工具设计比长篇工具说明更重要。因为工具接口会在每次调用时参与决策，而自然语言说明很容易变成上下文噪音。
四、第三条新规则：从“全部 upfront”到“渐进式披露”
Claude Code 早期把代码审查、验证、流程细则都塞进系统提示词，因为它担心模型在关键时刻不知道该怎么做。
现在 Anthropic 把这些信息拆到 Skills 里，让 Claude 在需要时选择性加载。
这就是 progressive disclosure：不要把所有可能有用的信息都放在当前上下文里，而是让模型在正确时刻拿到正确信息。
这条规则看似简单，实际是 Agent OS 的分水岭。
一个成熟 Agent 系统不应该只有一个巨大的 CLAUDE.md 或 system prompt。它应该像文件系统一样组织知识：
常驻上下文：身份、产品边界、安全红线、当前任务目标
按需技能：代码审查、发布流程、调试手册、数据分析、写作风格
外部引用：规格、测试、设计稿、历史决策、运行日志
动态记忆：用户偏好、项目惯例、失败教训
如果所有东西都常驻，模型每次都要背着整个组织的知识库走路。上下文窗口再大，也会被“可能有用”的东西吃掉。
渐进式披露的本质，是把上下文从“仓库”变成“检索系统”。
五、第四条新规则：从“重复强调”到“简单工具描述”
早期模型有一个现象：指令写在上下文末尾，或者重复多次，更容易被遵守。于是系统提示词里经常出现重复提醒：主 prompt 说一遍，工具描述再说一遍，Skill 里再说一遍。
Anthropic 的新结论是：对更强模型，这种重复可以删除。工具怎么用，放在工具描述里；系统提示词只负责产品上下文和全局角色。
这背后其实是一个工程原则：同一条规则只能有一个权威来源。
如果系统 prompt、Skill、项目文档、工具 schema 都在描述同一件事，迟早会出现版本漂移。模型看到的不是“更强约束”，而是一堆互相打架的规则。
这也是很多团队 Agent 越用越混乱的原因：每次事故后都往 prompt 里加一条补丁，最后上下文变成事故博物馆。短期看更安全，长期看更脆弱。
六、第五条新规则：从 CLAUDE.md 记忆到自动记忆
文章还提到一个变化：过去 Claude Code 鼓励用户用 # 快捷键把经验写入 CLAUDE.md。现在 Claude 会自动保存与工作和用户相关的记忆。
这不是说项目文档不重要，而是说 CLAUDE.md 不应该承担所有记忆职责。
更合理的分工是：
CLAUDE.md：轻量描述 repo 是什么、最重要的 gotchas；- memory：保存长期偏好、历史教训、反复出现的决策；
- Skills：保存可复用流程；
- artifacts / specs / tests：保存任务级上下文和可验证目标。
CLAUDE.md 最应该写的，不是“你要认真测试”“代码要简洁”这种显而易见的话，而是模型从文件系统里看不出来的坑：
- 类型只能放在某个单体文件；
- 发布流程有双 workflow 抢占；
- 某个测试必须带特殊环境变量；
- 某个目录是生成物，不能手改；
- 某个供应商 API 文档过时，要看本地封装。
换句话说，CLAUDE.md 应该是 repo 的“地雷图”，不是团队价值观手册。
七、第六条新规则：从简单 spec 到 rich references
文章最后一个重要变化，是 references 变丰富了。
过去 plan mode 依赖 markdown 计划和规格文件。现在 Claude 可以参考 HTML artifacts、代码、测试套件、另一个代码库里的函数，甚至 rubric。
这很关键，因为不同 reference 的信息密度不同。
一段自然语言说“做一个像 Stripe 文档一样的侧边栏”，远不如一个 HTML mockup 清楚；一句“API 设计要优雅”，远不如一组好 API 和坏 API 的 rubric；一个产品需求文档，很多时候不如一套测试更精确。
所以未来上下文工程会越来越像“给模型准备工作台”：
- 设计任务给 HTML mockup；
- 编码任务给测试和目标函数；
- 风格任务给 rubrics 和反例；
- 迁移任务给源代码和目标接口；
- 长任务给阶段计划和检查点。
模型越强，越能消费高保真 reference。我们不必把一切翻译成自然语言 prompt。
八、这篇文章真正改变的是 Agent 架构
如果把 Anthropic 的六条变化合起来看，会得到一个很清晰的方向：
强模型不需要更厚的说明书，它需要更好的操作系统。
这个操作系统至少包括五层：
- 最小常驻上下文：身份、边界、任务目标、安全红线；
- 可检索技能层：把复杂流程拆成按需加载的 Skills；
- 清晰工具接口：让参数、状态和错误恢复天然表达 workflow；
- 高保真引用层：测试、代码、HTML、rubric、artifact；
- 自动记忆与经验沉淀：把长期偏好和事故教训放到正确位置。
这也解释了为什么 Anthropic 可以删掉 Claude Code 超过 80% 的系统提示词：被删掉的不是能力，而是被迁移到了更合适的位置。
有些东西进了工具描述，有些东西进了 Skills，有些东西交给模型判断，有些东西交给 memory，有些东西交给 reference。
删 prompt，不等于少上下文；它意味着上下文开始分层。
九、对我们自己的启发：别再把 prompt 当垃圾桶
这篇文章对任何做 Agent 的团队都有直接启发。
第一，定期清理 prompt debt。
系统提示词、项目文档、技能说明会像代码一样腐化。每次失败都加一条规则，最后一定变成冲突集合。应该定期问：这条规则还需要常驻吗？能不能放到 Skill？能不能由工具 schema 表达？能不能变成测试？
第二，把“判断型规则”和“安全型规则”分开。
安全型规则要硬，判断型规则要给模型空间。比如“删除生产数据前必须确认”是硬规则；“不要写注释”是风格偏好，应该交给周围代码。
第三，工具接口要当产品设计做。
Agent 能不能稳定工作，很大程度取决于工具是不是让正确路径更自然。一个好的 schema，比十个示例更值钱。
第四，Skills 要短、专、可加载。
长 Skill 不应该把所有细节塞在一个文件里，而应该拆成入口说明 + reference 文件。入口告诉模型什么时候用，细节等需要时再读。
第五，测试和 rubric 会成为最重要的上下文。
未来让 Agent 做复杂任务，不是靠“请你写得好一点”，而是给它可执行测试、审查标准、设计 rubric、真实 mockup 和可比较样例。
十、结论：上下文工程进入“减法 + 分层”时代
这篇文章最值得记住的不是“删掉 80% prompt”，而是：模型越强，越不应该用密集规则把它绑死。
Claude 5 一代开始显示出更强的局部判断、工具使用和 reference 消费能力。继续用旧模型时代的写法——大段禁令、重复提示、全部 upfront、CLAUDE.md 包办记忆——会让系统变慢、变脆、变难维护。
新的上下文工程，核心是四个字：少而分层。
少，是少写显而易见、过时、重复、互相冲突的规则。
分层，是把不同类型的信息放到正确位置：系统 prompt 管产品边界，CLAUDE.md 管 repo gotchas，Skills 管可复用流程，memory 管长期经验，references 管高保真目标，tools 管可执行接口。
这也是 Agent 工程从“调 prompt”走向“做系统”的标志。
未来优秀的 Agent 团队，不会比谁的系统提示词更长，而会比谁能把上下文组织得更清楚、更轻、更可恢复、更可验证。
原文：Anthropic Claude Blog《The new rules of context engineering for Claude 5 generation models》。