Claude 5 代模型上下文工程新规则：Claude Code 系统提示词精简超 80%

我们为更先进的模型移除了 Claude Code 系统提示词中超过 80% 的内容。以下是如何将我们学到的经验应用到你在 Claude Code 中以及使用你自己的智能体时的上下文工程中。

我之前写过如何最好地为最新一代 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 Code 施加了过多的约束，无论是通过系统提示词，还是在 CLAUDE.md 文件和技能中。

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

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

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

此外，Claude Code 现在拥有了多得多的工具。Claude 过去依赖 CLAUDE.md 作为记忆、信息和指导的来源。现在我们有了记忆、artifacts 和技能，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 不再局限于简单的 markdown 文件，而是可以引用由我们全新的 artifacts 功能创建的 HTML artifacts。

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

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

将此应用到你的上下文中

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

系统提示词

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

CLAUDE.md

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

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

技能

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

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

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

引用

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

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

尝试简化

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