我先前写过关于如何最好地提示新一代 Claude 5 模型并与它们迭代式协作，以发现你想要构建的内容。
但当你向 Claude 发送消息时，提示只是它获得的上下文中的一小部分。你的大部分上下文是由系统提示、技能、CLAUDE.md 文件、记忆以及其他来源组合而成的。我们称之为上下文工程，它对你使用 Claude Code 或构建自己的 Agent 时所产生的结果有着重大影响。
与提示不同，上下文通常跨多个请求通用，因此无法做到那么具体。那么，如何为 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 作为记忆、信息和指导的来源。现在，我们有了记忆、工件和技能，Claude 可以使用这些来创建新的方式，跨会话加载和共享上下文。
过去与现在
过去有许多上下文工程的最佳实践，现在已变成了神话。其中包括：
**
过去：给 Claude 规则
现在：让 Claude 运用判断力
**当我们最初推出 Claude Code 时，我们需要确保 Claude 避免最坏情况，比如删除文件。这意味着我们会给出特别强硬的指导，而这些指导并不总是适用。例如，在系统提示中，我们曾经说过：
在代码中：默认不写注释。永远不要写多段落的文档字符串或多行注释块——最多一行。除非用户要求，否则不要创建计划、决策或分析文档——从对话上下文中工作，而不是中间文件。
但对于某些特定的提示，这条指导可能是错误的。在文档方面，用户可能有自己的偏好，或者非常复杂代码的特定部分可能需要多行注释块。
尽管如此，对于旧模型来说，没有这些防护栏，Claude 写的注释在很多情况下都会是错误的，我们不得不接受这个权衡。但新模型有更好的判断力，能够很好地处理这些决策，无需明确的规则。
在新的系统提示中，我们这样说：写代码时要让它读起来像周围的代码：匹配其注释密度、命名习惯和风格。
**过去：给 Claude 例子
现在：设计接口**
**对于工具使用，首要规则是给 Claude 提供如何使用它们的例子。对于我们的最新模型，我们发现提供例子实际上会将它们限制在某个探索空间内。
与其使用例子，不如更多地考虑你的工具、脚本和文件的设计——Claude 有哪些参数，它们如何能更具表现力？
例如，在 Todo 工具示例中，仅仅将状态列举为 pending、in_progress 和 completed 这几个枚举值，就向 Claude 暗示了如何使用它。而保持一个项目处于 in_progress 状态的指令则帮助定义了我们所期望的行为。
**过去：把所有内容放在前面
现在：使用渐进式披露**
**因为 Claude Code 专注于编码，我们的系统提示包含了关于如何进行代码审查和验证的详细信息。这些信息并不总是需要的，但当需要时，它们至关重要。
自那以后，Claude Code 已经非常擅长使用渐进式披露——在正确的时间加载正确的上下文。例如，我们将验证和代码审查移到了各自的技能中，Claude Code 可以有选择地调用。
但渐进式披露不仅适用于技能，我们也将其用于工具。我们的一些工具是“延迟加载”的，这意味着 Agent 在使用它们之前必须使用 ToolSearch 搜索它们的完整定义。这使我们能够拥有更多工具（例如我们的 Task 工具），这些工具在需要之前不会占用上下文。
同样的事情也可以应用到你的 CLAUDE.md 和 Skill.md 文件中。一个常见的误解是你希望把这些文件做成一个中央仓库，存放所有你可能遇到的已知实践，因为否则 Claude 就找不到它们。实际上，考虑建立一个可以在适当时候加载的文件树。
**过去：重复自己
现在：简单的工具描述**
**早期的 Claude 模型有时可能需要重复的指令，或者更倾向于听从上下文窗口末尾的指令而不是开头的指令。这意味着我们的系统提示有时会在主系统提示中引用工具，同时在工具描述中也有指令。
我们发现我们可以删除这些重复的例子，并将如何使用工具的指令放在工具描述中，而不是系统提示中。
**过去：将记忆放在 CLAUDE.md 文件中
现在：自动记忆**
**我们过去鼓励用户通过使用 # 快捷键自动写入 CLAUDE.md 来保存东西到 Claude 的记忆中。而现在，Claude 会自动保存与工作和你相关的记忆。
**过去：简单的规格说明
现在：丰富的引用**
**在计划模式下，Claude Code 严重依赖包含计划的 Markdown 文件。将这些文件存储为计划有助于 Claude 在需要时引用它们。另一个类似的最佳实践是将规格说明保存在代码库中，以便 Claude 在长期项目中工作时参考。
但我们发现 Claude 能够处理越来越复杂的引用。除了简单的 Markdown 文件，Claude 还可以引用由我们新的工件功能创建的 HTML 工件。
你也可以以代码的形式给 Claude 提供引用。一个规格说明也可能是一个详细的测试套件，或者另一个代码库中 Claude 可能移植的函数。
评分标准是另一种引用形式。评分标准允许 Claude 通过使用动态工作流并启动带有这些评分标准的验证器 Agent，来尝试验证你在特定领域的偏好（例如，好的 API 设计是什么样的）。
将其应用到你的上下文中
综合所有内容，当你组装上下文时，这看起来是什么样的？
**系统提示
**系统提示与产品上下文紧密相关。它告诉 Claude 它在什么产品中运行以及它在做什么。对于 Claude Code 来说，你可能永远不需要修改它，但如果你正在构建自己的 Agent 框架，那么这是你应该花大量时间的地方。
**CLAUDE.md
**保持你的 CLAUDE.md 轻量级，简要描述你的仓库是做什么的，但将大部分标记用在代码库中的注意事项上。例如，你可能将代码组织成将所有类型放在一个单一文件中，而不放在其他地方。避免陈述那些 Claude 通过查看你的文件系统或仓库就应该知道“显而易见”的事情。
对于更多细节，使用渐进式披露，例如，如果你有关于如何验证工作的几条独特指令，就创建一个验证技能，并在你的 CLAUDE.md 中引用它。
**技能
**将技能视为轻量级指南，让 Claude 在需要时找到信息。避免让它们过度约束，除非在非常重要的领域。
对于较长的技能，尽量使用渐进式披露——将其分成多个文件并拆分出来。
最好让技能编码那些属于你、你的团队或产品特有的特定观点、知识或最佳实践。
**引用
**你可以通过 @ 提及文件来将它们作为引用包含进来。引用允许 Claude 参考当前计划的深入信息。
这些信息可能来自规格说明文件、模型，甚至整个代码库。通常，你应该优先选择代码形式的文件，因为它们能以 Claude 非常熟悉的语言提供清晰、高保真的指令。例如，一个设计的 HTML 模型通常比设计的描述或截图产生更好的结果。
尝试简化
在你的系统提示、技能和 CLAUDE.md 文件中，你可能需要像我们一样进行简化。我们推出了一条名为 claude doctor 的新命令，它可以帮助你自动完成此操作。有关更具体地提示更高级模型的更多详细信息，请查看我们的 Fable 实地指南。
