当我们给 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 中，不同来源的信息会同时影响模型判断。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/f5067fe5d610c1682d7873a99b1e0941.png)

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

- 适当补充文档
    
- 不要添加代码注释
    
- 不要创建额外的规划、决策或分析文件
    

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

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

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

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

## 上下文工程的六个变化

![](https://developer.qcloudimg.com/http-save/yehe-12464096/cab10fc2b47b4db8ba292de37d841850.png)

### 从规则堆叠到模型判断

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

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

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

### 从工具示例到接口设计

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

![](https://developer.qcloudimg.com/http-save/yehe-12464096/ab645ec5a83318b32c6ceefd6a7b5992.png)

相比不断地补充使用示例，我们应该更关注下工具本身的接口设计。以一个 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` 和工具定义。与其把所有经验都塞进一个文件，不如建立一棵信息树：

```Plain
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 设计是否合理，一个实现是否符合现有的团队习惯。

## 分层设计上下文

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

![](https://developer.qcloudimg.com/http-save/yehe-12464096/5985af6c4120b87496122dbbd5d169f4.png)

### 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 系统来说，好的上下文工程很少来自持续添加的内容。更多时候，我们要做的是删除那些不必要的信息，让真正重要的部分更容易被模型找到。

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

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

Anthropic提出“上下文工程”（Context Engineering）新范式：Claude Opus 5/Fable 5删减超80%系统提示词，性能未降。核心转向“瘦提示-厚工件-瘦技能”，强调模型自主判断、渐进披露与高保真参考，告别冗余规则堆砌。

人工智能

编程语言

开发工具

Claude模型升级后，上下文工程从规则堆叠转向模型自主判断。Anthropic删除了80%提示词，通过分层设计优化上下文结构：SystemPrompt定义环境，CLAUDE.md记录特殊事项，Skills扩展能力，References提供详细参考。新模型能自动保存记忆、理解复杂材料，减少人工干预，实现更智能的上下文管理。

上下文工程

代码解释

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Claude模型升级后，上下文工程从规则堆叠转向模型自主判断。Anthropic删除了80%提示词，通过分层设计优化上下文结构：SystemPrompt定义环境，CLAUDE.md记录特殊事项，Skills扩展能力，References提供详细参考。新模型能自动保存记忆、理解复杂材料，减少人工干预，实现更智能的上下文管...

Claude 新模型的上下文工程：从堆规则到设计上下文-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐