Claude 5 时代上下文工程的新规则¶

我们为更高级的模型删减了 Claude Code 80% 以上的系统提示词。如何将我们学到的经验应用到你在 Claude Code 中的上下文工程以及你自己构建的 Agent 中。

作者：Thariq Shihipar，Anthropic 技术人员

日期：2026 年 7 月 24 日 | 阅读时间：5 分钟

引言¶

当你发送消息给 Claude 时，prompt 只是上下文的一小部分——系统提示词、Skills、CLAUDE.md 文件、记忆等共同构成了完整的上下文。

我之前写过关于如何最好地提示 Claude 5 新一代模型以及如何通过迭代来发现你想构建什么的文章。

但当你发送消息给 Claude 时，prompt 只是它接收到的上下文的一小部分。你的上下文大部分是由系统提示词、Skills、CLAUDE.md 文件、记忆以及其他来源组装而成的。我们称之为「上下文工程」（context engineering），它对你使用 Claude Code 或构建自己的 Agent 时生成的结果有很大影响。

与 prompt 不同，上下文是跨多个请求通用的，因此它不能太具体。如何为 Claude 构建这些通用的提示词和指导——特别是当你不知道用户的 prompt 可能是什么的时候？

随着 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 和用户请求之间互相碰撞时出现的 "leave documentation as appropriate"（适当保留文档）和 "DO NOT add comments"（不要添加注释）。

通常，Claude 能够解读用户意图得出正确答案，但 Claude 必须更仔细地思考这些重叠且冲突的消息，然后才能决定怎么做。

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

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

过去与现在¶

许多之前的上下文工程最佳实践已经变成了过时的迷思。

以下是具体的变化：

过去：给 Claude 规则 → 现在：让 Claude 自行判断¶

新一代模型有更好的判断力，无需显式规则就能处理好这些决策。

当我们最初推出 Claude Code 时，我们需要确保 Claude 避免最坏情况，比如删除文件。这意味着我们会给出特别强硬的指导，即使并不总是正确的。例如，我们曾在系统提示词中说：

In code: default to writing no comments. Never write multi-paragraph docstrings 
or multi-line comment blocks — one short line max. Don't create planning, decision, 
or analysis documents unless the user asks for them — work from conversation context, 
not intermediate files.

但对于某些特定的 prompt，这个指导是错误的。在文档方面，用户可能有自己的偏好，或者非常复杂的代码的特定部分可能需要多行注释块。

然而，如果没有这些旧模型的防护措施，Claude 写的注释在很多情况下会是错误的，我们不得不接受这种权衡。但新模型有更好的判断力，无需显式规则就能很好地处理这些决策。

在新的系统提示词中我们这样说：

Write code that reads like the surrounding code: match its comment density, naming, and idiom.

过去：给 Claude 示例 → 现在：设计接口¶

与其给示例，不如更多地思考你的工具、脚本和文件的设计——让参数本身具有表达力。

工具使用的第一条规则曾经是给 Claude 示例来展示如何使用它们。对于最新的模型，我们发现给出示例实际上将它们约束在了某个探索空间内。

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

例如，在 Todo 工具的例子中，仅仅将 status 列为 pending、in_progress 和 completed 之间的枚举，就已经向 Claude 暗示了如何使用它。关于保持一项处于 in_progress 的指令则帮助定义了我们期望的行为。

过去：全部放在前面 → 现在：渐进式披露¶

Claude Code 现在非常擅长渐进式披露——在合适的时机加载合适的上下文。

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

从那以后，Claude Code 变得非常擅长使用渐进式披露——在合适的时机加载合适的上下文。例如，我们将验证和代码审查移到了它们自己的 skills 中，Claude Code 可以选择性地调用。

但渐进式披露不仅仅适用于 skills，我们也将它用于工具。我们的一些工具是「延迟加载」的，这意味着 agent 必须在使用之前通过 ToolSearch 搜索它们的完整定义。这使我们可以拥有更多工具（例如我们的 Task 工具），直到需要时才占用上下文。

同样的理念也可以应用于你自己的 CLAUDE.md 和 Skill.md 文件。一个常见的误区是你想把这些文件作为你可能遇到的所有已知实践的中央仓库，因为否则 Claude 就找不到它们。实际上，考虑使用文件树结构，让内容在合适的时机被加载。

过去：重复自己 → 现在：简洁的工具描述¶

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

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

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

过去：CLAUDE.md 中的记忆 → 现在：自动记忆¶

Claude 现在会自动保存与工作和你相关的记忆。

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

过去：简单的规格说明 → 现在：丰富的引用¶

Claude 可以处理越来越复杂的引用——HTML artifacts、代码、测试套件、评分标准等。

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

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

你也可以以代码的形式给 Claude 引用。规格说明也可以是一个详细的测试套件，或者是 Claude 可能会移植的不同代码库中的函数。

评分标准（Rubrics）是另一种引用形式。评分标准允许 Claude 通过使用动态工作流和启动带有这些评分标准的验证 agent 来尝试验证你在特定领域的品味（例如，好的 API 设计是什么样的）。

将这些应用到你的上下文中¶

把所有这些综合起来，当你组装上下文时应该是什么样子的？

System Prompt（系统提示词）¶

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

CLAUDE.md¶

保持你的 CLAUDE.md 轻量化，简要描述你的仓库用途，但把大部分 token 花在代码库中的「坑」上。例如，你可能将代码组织为把类型保存在一个整体文件中而不是其他地方。避免陈述 Claude 通过查看你的文件系统或仓库就应该知道的「显而易见」的事情。

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

Skills¶

将 skills 视为轻量级指南，让 Claude 在需要时找到信息。避免过度约束它们，除非是高度重要的领域。

对于长 skills，尽量使用渐进式披露——将其分成多个文件并拆分出去。

skills 最好是编码特定的观点、知识或最佳实践，这些是特属于你、你的团队或产品的。

References（引用）¶

你可以 @ 提及文件将它们作为引用包含进来。引用允许 Claude 参考关于当前计划的深入信息。

这可以是规格说明文件、模型或甚至整个代码库。通常你应该偏好代码形式的文件，因为它为 Claude 提供了清晰、高保真度的指令，使用的是它非常熟悉的语言。例如，设计的 HTML 模型通常比设计的描述或截图能产生更好的结果。

尝试精简¶

跨系统提示词、skills 和 CLAUDE.md 文件，你可能需要像我们一样进行精简。

我们推出了一个叫 claude doctor 的新命令，它会帮助你自动完成精简。关于如何专门为更高级的模型进行提示的更多细节，请查看我们的 Fable 使用指南。