Claude 5 代模型的上下文工程新规则

我之前写过如何最好地为最新一代 Claude 5 模型编写提示词，并与它们迭代协作，以发现你想构建的内容。

但当你向 Claude 发送消息时，提示词只是它获得的上下文的一小部分。你的大部分上下文来自系统提示词、Skills、CLAUDE.md 文件、记忆和其他来源。我们称之为上下文工程，它对你在使用 Claude Code 或构建自己的智能体时生成的结果有很大影响。

与提示词不同，上下文会普遍用于许多请求，因此无法那么具体。你如何为 Claude 构建这些通用的提示词和指导，尤其是在你不知道用户提示词可能是什么的情况下？

随着 Claude 自身能力的演进，这可能出乎意料地困难。最近，我们注意到在为最新一代 Claude 模型编写提示词的方式上出现了巨大飞跃。我们为 Claude Opus 5 和 Claude Fable 5 等模型删除了 Claude Code 系统提示词中超过 80% 的内容，而我们的编码评估没有出现可测量的损失。

以下是我们学到的关于为这类新模型编写提示词的经验，以及你如何利用它来更新你的上下文工程。我们已将这些最佳实践整理到 claude doctor 中；在 Claude Code 中使用命令 /doctor 来调整你的 skills 和 CLAUDE.md 文件的规模。

为 CLAUDE 松绑

总体而言，我们发现我们通过系统提示词以及 CLAUDE.md 文件和 skills 对 Claude Code 施加了过多约束。

例如，当我们阅读自己内部使用 Claude Code 的记录时，我们会在单个请求中看到几条相互冲突的信息，比如“酌情保留文档”，或“不要添加注释”，因为我们的系统提示词、skills 和用户请求彼此冲突。

一般来说，Claude 能够理解用户意图以得出正确答案，但在决定该怎么做之前，Claude 必须更仔细地思考这些重叠且冲突的信息。

虽然这些约束曾经是避免最坏情况所必需的，但此后我们发现可以删除其中许多约束，让模型转而利用周围的上下文和判断力。

此外，Claude Code 现在拥有多得多的工具。Claude 过去依赖 CLAUDE.md 作为记忆、信息和指导的来源。现在我们有了记忆、artifacts 和 skills，Claude 可以用它们来创造跨会话加载和共享上下文的新方式。

过去与现在

有许多以前的上下文工程最佳实践已经变成了迷思。包括：

过去：给 Claude 规则

现在：让 Claude 运用判断力

当我们最初推出 Claude Code 时，我们需要确保 Claude 避免最坏情况，例如删除文件。这意味着我们会给出可能并不总是成立的特别强烈的指导。例如，在系统提示词中我们过去常说：

在代码中：默认不写注释。永远不要写多段 docstring 或多行注释块——最多一行短注释。除非用户要求，否则不要创建规划、决策或分析文档——基于对话上下文工作，而不是中间文件。

但对于某一部分提示词，这条指导会是错误的。就文档而言，用户可能有自己的偏好，或者非常复杂代码的特定部分可能需要多行注释块。

不过，如果没有针对旧模型的这些护栏，Claude 写出的注释在很多情况下会不正确，我们不得不接受这一权衡。但较新的模型有更好的判断力，无需明确规则也能很好地处理这些决策。

在新的系统提示中，我们写道：编写读起来像周围代码的代码：匹配其注释密度、命名和惯用法。

然后是：给 Claude 示例

现在是：设计接口

工具使用的第一条规则是给 Claude 提供如何使用它们的示例。使用我们最新的模型，我们发现给出示例实际上会将它们限制在某个探索空间内。

与其使用示例，不如多思考你的工具、脚本和文件的设计——Claude 有哪些参数，它们如何能更具表现力？

例如，在 Todo 工具示例中，仅将 status 列为 pending、in_progress 和 completed 之间的枚举，就向 Claude 暗示了如何使用它。关于保持一个条目处于 in_progress 的说明有助于定义我们要求的行为。

然后是：把所有内容都放在前面

现在是：使用渐进式披露

因为 Claude Code 专注于编码，我们的系统提示包含了关于如何进行代码审查和验证的详细信息。这些并不总是需要，但当需要时，它们是至关重要的信息。

自那以后，Claude Code 在使用渐进式披露方面变得非常擅长——在正确的时间加载正确的上下文。例如，我们将验证和代码审查移到了它们自己的技能中，Claude Code 可以有选择地调用。

但渐进式披露不仅仅用于技能，我们也将其用于工具。我们的一些工具是“延迟加载”的，这意味着智能体在使用它们之前必须使用 ToolSearch 搜索它们的完整定义。这使我们能够拥有更多工具（例如我们的 Task 工具），这些工具在被需要之前不占用上下文。

同样的方法也可以应用于你自己的 CLAUDE.md 和 Skill.md 文件。一个常见的误区是，你想把这些文件做成一个中央仓库，存放你可能遇到的所有已知实践，因为否则 Claude 就找不到它。相反，考虑拥有一棵可以在正确时间加载的文件树。

然后是：重复自己

现在是：简单的工具描述

早期的 Claude 模型有时可能需要重复的指令，或者更倾向于听从其上下文窗口末尾的指令而非开头的指令。这意味着我们的系统提示有时会在主系统提示中引用工具，同时在工具描述中也有说明。

我们发现可以删除这些重复的示例，并将如何使用工具的说明放在工具描述中，而不是系统提示中。

然后是：CLAUDE.md 文件中的记忆

现在是：自动记忆

我们过去鼓励用户保存内容到 Claude 的记忆中，通过使用 # 热键自动写入他们的 CLAUDE.md。相反，Claude 现在会自动保存与工作和你相关的记忆。

然后是：简单的规格说明

现在是：丰富的引用

在计划模式中，Claude Code 严重依赖带有计划的 markdown 文件。将这些文件存储为计划有助于 Claude 在需要时参考它们。另一个类似的最佳实践是将规格说明存储在代码库中，以便 Claude 在跨较长项目工作时参考。

但我们发现 Claude 能够处理越来越复杂的引用。Claude 可以引用由我们新的 artifacts 功能创建的 HTML 工件，而不是简单的 markdown 文件。

你也可以用代码的形式向 Claude 提供参考资料。一份规范也可以是一个详细的测试套件，或者是另一个代码库中 Claude 可能会移植的函数。

评分标准（Rubrics）是另一种形式的参考资料。评分标准让 Claude 能够通过使用动态工作流并启动带有这些评分标准的验证代理，来尝试验证你在某一特定领域的品味（例如，什么样的 API 设计才算好）。

将此应用到你的场景中

把这一切综合起来，当你组装你的上下文时，它会是什么样子？

系统提示词

系统提示词与产品上下文紧密相关。它告诉 Claude 它正在什么产品中运行、正在做什么。对于 Claude Code，你很可能永远不会修改它，但如果你在构建自己的代理框架，这里就是你应该花大量时间的地方。

CLAUDE.md

让你的 CLAUDE.md 保持轻量，简要描述你的仓库是做什么的，但把大部分 token 花在代码库内部的坑点上。例如，你可能会把你的代码组织成将类型集中放在一个单一文件中，而不放在其他地方。避免陈述 Claude 通过查看你的文件系统或仓库就能知道的“显而易见”的事情。

大量使用渐进式披露，例如，如果你有几条关于如何验证你的工作的独特指令，就创建一个验证技能，并从你的 CLAUDE.md 中引用它。

技能（Skills）

把技能看作轻量级指南，让 Claude 在需要时找到信息。避免让它们过度受限，除非是在极其重要的领域。

对于较长的技能，尽量使用渐进式披露——把它分成许多文件并拆分出来。

当技能编码了特定于你、你的团队或你的产品的特定观点、知识或最佳实践时，效果最好。

参考资料

你可以用 @ 提及文件，将它们作为参考资料包含进来。参考资料让 Claude 能够查阅关于当前计划的深入信息。

这可能是规范文件、原型图，甚至整个代码库。一般来说，你应该优先选择代码形式的文件，因为它以 Claude 非常熟悉的语言为 Claude 提供清晰、高保真的指令。例如，一个设计的 HTML 原型通常比一段设计描述或一张截图产生更好的结果。

尝试简化

在你的系统提示词、技能和 CLAUDE.md 文件中，你可能需要像我们一样进行简化。我们推出了一个名为 claude doctor 的新命令，它也能帮助你自动完成这一工作。关于如何专门为更高级的模型编写提示词的更多细节，请查看我们的Fable 实战指南。

本文由 Anthropic 技术团队成员 Thariq Shihipar 撰写。