Claude 新模型的上下文工程：从堆规则到设计上下文

当我们给 Agent 发消息时，当前这一次输入的 Prompt，只占模型实际读到的上下文中的很小一部分。系统提示词、Skills、CLAUDE.md 文件、记忆机制，以及运行时加载的各种信息，共同构成了模型做判断时的依据。而围绕这部分内容的设计工作，Anthropic 将其称为 Context Engineering。

上下文工程和写 Prompt 有一个结构性差异，那就是 Prompt 面向单次任务，而上下文会被大量请求反复使用。要复用就意味着上下文不能写得太具体，不然在下一个任务中它会变成噪音甚至干扰。于是，问题变成了——在不知道用户接下来会提什么需求的前提下，这些通用的指导性信息应该怎么写？

Anthropic 上周给出了他们的答案。在 Claude 的新一代模型 Claude Opus 5、Claude Fable 5 中，Anthropic 删除了 Claude Code 中 80% 以上的提示词，而在代码评测上并没有观察到明显的性能下降。

这说明，过去需要通过大量提示词规则约束模型的部分工作，现在可以更多交给模型结合上下文来判断了。

约束的代价

过去 Claude Code 的上下文分散在系统提示词、CLAUDE.md 和各个 Skill 中，不同来源的信息会同时影响模型判断。

一个任务中，模型可能要同时处理多条来自不同位置的约束：

• 适当补充文档

• 不要添加代码注释

• 不要创建额外的规划、决策或分析文件

单看每一条规则，它们都有存在的合理性。但约束规则的来源和层级不同，组合在一起后就容易产生冲突，这时候就需要模型在这些冲突中选择执行哪些规则。

这些规则在旧模型阶段确实有用。它们能很好地避免模型随意修改文件、删除内容，严格的约束能够降低错误率。这种牺牲一部分灵活性的取舍，在当时是合理的。但随着模型判断能力的提升，同样的约束开始产生负收益。现在的模型已经能够从代码环境、用户目标和项目已有习惯中判断应该如何处理任务，过于硬性的规则反而限制了它做出更恰当选择的空间。

举个例子，过去约束条件可能是“默认不要写注释，不要创建多段文档，不要生成规划文件”。现在，更合适的写法是：“编写符合当前代码风格的代码，包括注释密度、命名方式和已有的代码习惯”。

前者规定了具体行为，后者提供了目标和判断依据。两者的区别不在措辞，而在于决策方式发生了变化。

上下文工程的六个变化

从规则堆叠到模型判断

早期使用 Claude Code 时，我们需要告诉模型大量“不要做什么”：不要随便删文件，不要生成多余文档，不要加太多注释。这些规则的作用是兜底，防止模型在不确定要做什么的时候乱行动。

但这些规则并不总是正确。复杂代码中的长注释可能是必要的，某些项目也有自己的文档习惯，一刀切的限制反而容易与真实项目需求产生冲突。新模型具备更强的情境判断能力，因此可以减少固定约束，让模型结合项目环境和具体任务自行判断。

现在，比较优雅的做法是给出目标和上下文，而不是列举一份禁止清单。

从工具示例到接口设计

过去我们要给 Claude 接入工具，一般要在提示词中提供大量调用示例，去告诉它“这个工具应该如何使用”。多示例确实能帮模型快速理解工具，但在新模型上，过多的示例反而可能会限制它的探索空间。模型会沿着示例中的固定模式执行任务，而忽略当前任务是否存在更合适的调用方式。

相比不断地补充使用示例，我们应该更关注下工具本身的接口设计。以一个 Todo 工具为例，如果状态字段定义为 pending、in_progress、completed，新模型几乎不用额外说明就能理解这些状态的含义。我们只用再补充一条约束，“同一时刻只能有一个任务处于 in_progress”就够了。

这样一来，就定义清楚了整个行为边界。重点也从“告诉 Claude 如何使用工具”，变成“设计一个 Claude 能够直接理解的工具”。

从全量加载到渐进式披露

过去的 Claude Code 在系统提示词中塞入了大量信息，比如如何进行代码 Review、如何验证修改结果、如何执行测试。这些并不是每次任务都需要的内容，始终占据着上下文窗口，也稀释了真正相关的信息。

现在的 Claude Code 会更多依赖 Progressive Disclosure（渐进式披露）。只在任务需要时，Claude 才会加载对应的信息。Claude 将代码验证和 Review 拆成独立的 Skill，Agent 判断需要时再主动调用 Skill。

这样的思路适用于 CLAUDE.md、Skill.md 和工具定义。与其把所有经验都塞进一个文件，不如建立一棵信息树：

CLAUDE.md
 ├── 基础项目说明
 ├── 验证 Skill
 ├── 部署 Skill
 └── 特殊规则文件

这样一来，根节点就能保持精简，只负责指路，让 Claude 在需要的时候能找到对应内容就够了。

从重复提醒到工具自描述

过去，模型有时候需要反复强调同一条规则。系统提示词里说明了工具怎么用，又在工具描述中再说一遍。这种冗余在当时能提升遵循率，但现在其实可以直接删掉。

比较优雅的方式是把使用方式写进工具描述本身，让工具自己携带说明。将信息和它作用的对象放在一起，也会降低维护成本。

从手动记录到自动 Memory

过去 Claude Code 靠人工维护长期记忆，鼓励用户通过 # 快捷键把信息保存进 CLAUDE.md。现在的 Claude 可以自动保存与当前工作、用户习惯相关的 Memory，不需要用户再手动记录所有内容。

这也说明 CLAUDE.md 的定位在变化：它适合记录相对不变的项目事实，高频变动的工作状态可以交给 Memory。

从 md 规划到复合参考资料

过去 Plan 模式大量依赖 Markdown 文件，项目计划、技术规范、开发说明都以文字形式存在 md 文件中，以便 Claude 在长周期任务中保持正确的方向。

现在的新模型能够理解复杂得多的参考材料，包括不限于 HTML Artifact、测试代码、其他项目中的实现。一份 API 设计规范，与其用文字描述，不如直接给模型测试用例和已有实现，这样模型读到的是可执行的事实，而不是对事实的转述。

Rubric 也是一种新的参考形式。有了它，Claude 能够按照标准做自我验证，比如判断一个 API 设计是否合理，一个实现是否符合现有的团队习惯。

分层设计上下文

把上面的变化落到具体实现上，每一层的职责要重新划分：

System Prompt

在整个上下文体系中，System Prompt 和具体产品的关系是最紧密的。它主要负责定义 Claude 所处的运行环境，以及它要完成的任务类型。对于普通 Claude Code 用户来说，一般不用修改这一层。但如果你正在构建自己的 Agent 系统，这里就是你最需要投入设计的部分。

CLAUDE.md

CLAUDE.md 应该保持轻量，只要说清楚项目是什么、目标是什么、有哪些特殊注意事项就够了。CLAUDE.md 的重点是在代码库中不符合常规预期的那部分内容，比如，要集中管理哪些类型文件，哪些目录有特殊约定，以及哪些测试流程和主流做法不同。

通过查看项目结构就能获得的信息，就不用重复写进 Claude。如果遇到像是“如何验证代码修改”这样的复杂流程，推荐做法是单独创建一个 Verification Skill，再在 CLAUDE.md 中引用它。

Skills

上下文体系中，Skills 是 Claude 的能力扩展模块。它负责帮 Claude 找到需要的信息，而不是限制它的行为。团队经验、特定领域知识、项目最佳实践都适合放在这里。比较大的 Skill 文件应该拆分成若干个子文件，同样还是保持按需加载。

References

引用文件可以为 Claude 提供更加详细的上下文参考。技术规范、产品设计稿、Mockup，甚至完整代码库，都能成为参考来源。

实际使用中，代码形式的参考一般能带来更好的效果。相比文字描述，一个 HTML 页面能够提供更高保真的设计信息，让模型更准确地理解目标效果。

上下文设计的减法

把两代实践放在一起对比下：

• 过去的做法：给更多规则、提供更多示例、把所有信息提前加载、不断重复提醒；

• 现在的做法：让模型使用判断、设计更好的接口、按需加载信息、提供高质量参考。

对于 Claude Code 或任何 Agent 系统来说，好的上下文工程很少来自持续添加的内容。更多时候，我们要做的是删除那些不必要的信息，让真正重要的部分更容易被模型找到。