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

我之前写过一篇文章，介绍如何更好地向最新一代 Claude 5 模型编写提示词，以及如何与它们迭代协作，去发掘你真正想要构建的东西。

但当你向 Claude 发送一条消息时，提示词只是它所获得的上下文（Context）中的一小部分。你的大部分上下文是由系统提示词（System Prompt）、技能（Skills）、CLAUDE.md 文件、记忆（Memory）以及其他来源组装而成的。我们称之为上下文工程（Context Engineering），它对你使用 Claude Code 或构建自己的智能体（Agent）时所产出的结果有着重大影响。

与提示词不同，上下文会跨许多请求被通用化地使用，因此它无法做到那么具体。那么，如何为 Claude 构建这些通用性的提示与指引——尤其是在你并不知道用户的提示词会是什么的情况下？

随着 Claude 自身能力的演进，这件事出人意料地困难。最近，我们注意到在针对最新一代 Claude 模型的提示方式上出现了一次巨大的飞跃：面向 Claude Opus 5 和 Claude Fable 5 这样的模型，我们删除了 Claude Code 系统提示词中超过 80% 的内容，而在我们的编程评测中没有出现任何可测量的损失。

以下是我们关于如何提示这类新模型的心得，以及你可以如何运用它们来更新自己的上下文工程。我们已经把这些最佳实践放进了 claude doctor；在 Claude Code 中使用 /doctor 命令，即可精简调整你的技能和 CLAUDE.md 文件。

解除束缚 (Unhobbling 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 工具的示例中，仅仅把状态列为 pending、in_progress 和 completed 之间的枚举，就向 Claude 暗示了它的用法。而关于保持只有一个条目处于 in_progress 状态的说明，则帮助定义了我们所期望的行为。

过去：把所有内容前置堆叠

现在：渐进式披露 (Progressive Disclosure)

由于 Claude Code 专注于编程，我们的系统提示词中曾包含如何进行代码审查（Code Review）和验证（Verification）的详细信息。这些信息并不总是用得上，但一旦需要，就是关键信息。

从那时起，Claude Code 已经非常擅长渐进式披露——在正确的时间加载正确的上下文。例如，我们把验证和代码审查移入了各自的技能中，Claude Code 可以选择性地调用它们。

但渐进式披露不仅仅适用于技能，我们也把它用于工具。我们的一些工具采用"延迟加载 (deferred loading)"，这意味着智能体必须先用 ToolSearch 搜索到它们的完整定义，然后才能使用。这让我们可以拥有更多的工具（比如我们的 Task 工具），它们在需要之前不会占用上下文。

同样的思路也适用于你自己的 CLAUDE.md 和 SKILL.md 文件。一种常见的迷思是：你想把这些文件打造成一个中央仓库，收纳你可能会遇到的所有已知实践，因为否则 Claude 就找不到它们。其实，不妨构建一棵文件树，让内容在恰当的时机被加载。

过去：重复强调

现在：简洁的工具描述

早期的 Claude 模型有时需要反复指令，或者说，它们更倾向于听从上下文窗口末尾的指令而非开头的。这意味着我们的系统提示词有时会在主体部分提及工具，同时又在工具描述中再写一遍指令。

我们发现，这些重复的内容可以删掉，把工具使用说明放在工具描述里即可，不必再放进系统提示词。

过去：用 CLAUDE.md 文件做记忆

现在：自动记忆 (Auto-memory)

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

过去：简单的规格说明 (Specs)

现在：丰富的参考资料 (Rich References)

在规划模式（Plan Mode）下，Claude Code 重度依赖写有计划的 Markdown 文件。把这些文件存为计划，有助于 Claude 在需要时查阅。另一个类似的最佳实践是：在代码库中存放规格说明，供 Claude 在跨长周期项目工作时参考。

但我们发现，Claude 能处理的参考资料越来越复杂。除了简单的 Markdown 文件，Claude 还可以参考由我们新的 Artifacts 功能创建的 HTML 工件。

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

评分细则（Rubrics）是另一种形式的参考。通过动态工作流，Claude 可以基于这些评分细则启动验证者智能体（Verifier Agents），从而尝试验证你在某个特定领域的品味（例如：好的 API 设计长什么样）。

应用到你的上下文中

把这一切汇总起来，当你组装自己的上下文时，它应该是什么样子？

系统提示词 (System Prompt)

系统提示词与产品上下文紧密绑定。它告诉 Claude 自己在哪个产品中运行、在做什么。对于 Claude Code，你大概率永远不会去修改它；但如果你正在构建自己的智能体框架（Agent Harness），这里才是你应该投入大量时间的地方。

CLAUDE.md

让你的 CLAUDE.md 保持轻量，简要描述你的代码仓库是做什么的即可，把大部分 token 花在代码库里的"坑"（gotchas）上。例如，你可能约定把类型集中放在一个大文件里、除此之外不放别处。避免陈述那些"显而易见"的事情——Claude 通过查看你的文件系统或仓库就应该知道的事。

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

技能 (Skills)

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

对于篇幅较长的技能，尽可能使用渐进式披露——将其拆分为多个文件。

最好的技能，是那些凝结了特定于你、你的团队或你的产品的观点、知识或最佳实践的技能。

参考资料 (References)

你可以用 @ 提及文件，将其作为参考资料纳入。参考资料让 Claude 能够查阅与当前计划相关的深度信息。

它可以是规格文件、设计稿，甚至是整个代码库。一般来说，你应当优先选择代码形式的文件，因为它以 Claude 最熟悉的语言提供了清晰、高保真的指令。例如，一个设计的 HTML 设计稿，通常会比对设计的文字描述或截图产生更好的效果。

尝试做减法

在你的系统提示词、技能和 CLAUDE.md 文件中，你可能需要像我们一样做减法。我们推出了一个名为 claude doctor 的新命令，它也能帮你自动完成这件事。有关如何专门针对更先进的模型编写提示词的更多细节，请查阅我们的 Fable 实战指南。

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