对于更先进的模型，我们移除了 Claude Code 系统提示词中超过 80% 的内容。以下是如何将这些经验教训应用到您自己的上下文工程中，无论是用于 Claude Code 还是构建您自己的智能体。
- 分类Claude Code智能体
- 产品Claude CodeClaude EnterpriseClaude 平台
- 日期2026 年 7 月 24 日
- 阅读时间5分钟
- https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models
我之前写过如何为最新一代的 Claude 5 模型编写最佳提示词，以及如何与它们进行迭代协作，以发现您想要构建的内容。
但是，当您向 Claude 发送消息时，提示词只是其获取的上下文中的一小部分。您的上下文大部分是由系统提示词、技能、CLAUDE.md 文件、记忆和其他来源组合而成的。我们称之为上下文工程，它对您在使用 Claude Code 或构建自己的智能体时生成的结果有着重大影响。
与提示词不同，上下文通常跨多个请求通用，因此不能过于具体。您如何为 Claude 构建这些通用提示和指导，尤其是在您不知道用户提示词可能是什么的情况下？
随着 Claude 自身能力的演进，这可能会变得异常困难。最近，我们注意到在提示最新一代 Claude 模型的方式上有了巨大的飞跃。对于像 Claude Opus 5 和 Claude Fable 5 这样的模型，我们移除了 Claude Code 系统提示词中超过 80% 的内容，而在我们的编码评估中并未发现可衡量的性能损失。
以下是我们从提示这类新型模型中学到的经验，以及您如何利用这些经验来更新您的上下文工程。我们将这些最佳实践整合到了 `claude doctor` 中；在 Claude Code 中使用 /doctor 命令来调整您的技能和 CLAUDE.md 文件的大小。
为 Claude 松绑
总体而言，我们发现我们通过系统提示词以及 CLAUDE.md 文件和技能，对 Claude Code 施加了过多的约束。
例如，当我们阅读自己内部使用 Claude Code 的转录记录时，我们看到在单个请求中存在多条相互矛盾的指令，比如“酌情添加文档”或“不要添加注释”，这是因为我们的系统提示词、技能和用户请求之间相互冲突。
通常，Claude 能够理解用户的意图以得出正确答案，但在决定如何行动之前，Claude 必须更仔细地思考这些相互重叠且存在冲突的信息。
虽然这些约束曾经是避免最坏情况所必需的，但我们后来发现，可以删除其中许多约束，让模型转而利用周围的上下文和自己的判断力。
此外，Claude Code 现在拥有了更多工具。Claude 过去依赖 CLAUDE.md 作为记忆、信息和指导的来源。现在我们有了记忆、工件和技能，Claude 可以利用它们创建在会话之间加载和共享上下文的新方式。
过去与现在
过去有许多关于上下文工程的最佳实践，如今已变成了迷思。其中包括：
过去：给 Claude 制定规则
现在：让 Claude 运用判断力
当我们首次推出 Claude Code 时，我们需要确保 Claude 避免最坏情况，例如删除文件。这意味着我们会给出一些可能并非总是正确的、非常强硬的指导。例如，在系统提示词中，我们过去会这样说：
在代码中：默认不写注释。永远不要写多段落的文档字符串或多行注释块——最多一行短注释。除非用户要求，否则不要创建规划、决策或分析文档——从对话上下文中工作，而不是依赖中间文件。
但对于某些特定的提示词，这种指导是错误的。在编写文档的情况下，用户可能有自己的偏好，或者非常复杂代码的特定部分可能需要多行注释块。
尽管如此，如果没有这些针对旧模型的防护栏，Claude 编写的注释在很多情况下都会出错，我们不得不接受这种权衡。但较新的模型拥有更好的判断力，能够在没有明确规则的情况下妥善处理这些决策。
在新的系统提示词中，我们这样说：编写与周围代码风格一致的代码：匹配其注释密度、命名习惯和惯用写法。
过去：给 Claude 提供示例
现在：设计接口
工具使用的首要规则是给 Claude 提供如何使用工具的示例。通过我们最新的模型，我们发现提供示例实际上会将它们限制在特定的探索空间内。
与其使用示例，不如多思考一下你的工具、脚本和文件的设计——Claude 有哪些参数，以及如何让这些参数更具表现力？
例如，在 Todo 工具示例中，仅仅将状态列举为待处理、进行中和已完成这三个枚举值，就能向 Claude 提示如何使用它。而关于始终保持一个项目处于“进行中”状态的指令，则有助于明确我们所期望的行为。
过去：把所有内容都放在最前面
现在：采用渐进式披露
由于 Claude Code 专注于编码，我们的系统提示词包含了关于如何进行代码审查和验证的详细信息。这些信息并非总是需要，但在需要时，它们又是至关重要的信息。
自那以后，Claude Code 已经非常擅长使用渐进式披露——在正确的时间加载正确的上下文。例如，我们将验证和代码审查移到了它们各自的技能中，这样 Claude Code 就可以有选择地调用它们。
但渐进式披露不仅适用于技能，我们也将其用于工具。我们的一些工具是“延迟加载”的，这意味着智能体必须先使用 ToolSearch 搜索到它们的完整定义，然后才能使用它们。这使我们能够拥有更多工具（例如我们的任务工具），这些工具在需要之前不会占用上下文。
同样的原则也可以应用于你自己的 CLAUDE.md 和 Skill.md 文件。一个常见的误解是，你应该把这些文件当作一个中心仓库，存放你可能遇到的所有已知实践，因为否则 Claude 就找不到它们。相反，不妨考虑建立一个可以在适当时间加载的文件树。
过去：重复指令
现在：简洁的工具描述
早期的 Claude 模型有时可能需要重复的指令，或者更倾向于听从其上下文窗口末尾的指令，而不是开头的指令。这意味着我们的系统提示词有时会在主系统提示词中引用工具，同时在工具描述中也包含指令。
我们发现可以删除这些重复的示例，并将如何使用工具的指令放在工具描述中，而不是系统提示词里。
过去：将记忆存储在 CLAUDE.md 文件中
现在：自动记忆
我们过去鼓励用户使用 # 快捷键自动写入 CLAUDE.md 文件，将内容保存到 Claude 的记忆中。而现在，Claude 会自动保存与工作和你相关的记忆。
过去：简单的规格说明
现在：丰富的参考资料
在规划模式下，Claude Code 严重依赖包含计划的 Markdown 文件。将这些文件作为计划存储，有助于 Claude 在需要时进行参考。另一个类似的最佳实践是将规格说明存储在代码库中，以便 Claude 在跨较长项目工作时参考。
但我们发现，Claude 能够处理越来越复杂的参考资料。除了简单的 Markdown 文件，Claude 还可以引用我们新的人工智能体功能创建的 HTML 产物。
你也可以以代码形式向 Claude 提供参考资料。一份规格说明也可以是一套详细的测试套件，或者是 Claude 可能移植的另一个代码库中的某个函数。
评分标准是另一种参考资料形式。评分标准允许 Claude 通过使用动态工作流并启动带有这些评分标准的验证智能体，来尝试验证你在特定领域的品味（例如，一个好的 API 设计应该是什么样的）。
将其应用于你的上下文
综合来看，当你组装自己的上下文时，这会是怎样的情形？
系统提示词
系统提示词与产品上下文紧密相关。它告诉 Claude 它在哪个产品中运行以及它在做什么。对于 Claude Code，你很可能永远不会修改它，但如果你在构建自己的智能体框架，这正是你应该投入大量时间的地方。
CLAUDE.md
保持你的 CLAUDE.md 文件轻量，简要描述你的仓库用途，但将大部分模型 token 用于说明代码库中的陷阱。例如，你可能将代码组织为所有类型都放在一个单一文件中，而不放在其他地方。避免陈述那些 Claude 通过查看你的文件系统或仓库就应该知道的“显而易见”的事情。
大量使用渐进式披露，例如，如果你有若干关于如何验证工作的独特指令，可以创建一个验证技能，并从你的 CLAUDE.md 文件中引用它。
技能
将技能视为轻量级指南，让 Claude 在需要时查找信息。除非在非常重要的领域，否则避免对它们施加过多限制。
对于较长的技能，请尽可能采用渐进式披露——将其拆分为多个文件并分别展开。
当技能编码了属于你、你的团队或产品特有的特定观点、知识或最佳实践时，效果最佳。
参考资料
你可以使用 @ 提及文件，将其作为参考资料包含进来。参考资料能让 Claude 查阅与当前计划相关的深度信息。
这些信息可能存在于规格文件、设计稿甚至整个代码库中。通常，你应优先选择代码中的文件，因为它们能以 Claude 非常熟悉的语言，向其提供清晰、高保真的指令。例如，一个设计的 HTML 原型通常比该设计的文字描述或截图能产生更好的效果。
尝试简化
在你的系统提示词、技能和 CLAUDE.md 文件中，你可能需要像我们一样进行简化。我们推出了一条名为 `claude doctor` 的新命令，它也能帮助你自动完成此操作。如需了解针对更高级模型编写提示词的更多细节，请查阅我们的 Fable 现场指南。
本文由 Anthropic 技术团队成员 Thariq Shihipar 撰写。