我们为最新模型去掉了约 80% 的 Claude Code 系统提示，以下是我们学到的关于为它们编写系统提示、技能和 CLAUDE.md 的经验。https://t.co/6DZwSrZjE9

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

我之前写过关于如何为最新一代 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 作为记忆、信息和指导的来源。现在我们有了记忆、构件和技能，Claude 可以使用它们创建跨会话加载和共享上下文的新方式。

过去与现在

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

** 过去：给 Claude 规则 现在：让 Claude 使用判断力 **当我们首次推出 Claude Code 时，我们需要确保 Claude 避免最坏情况，比如删除文件。这意味着我们会给出特别严格的指导，而这些指导可能并不总是正确的。例如，在系统提示中，我们过去常说：

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

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

尽管如此，如果没有针对旧模型的这些防护措施，Claude 编写的注释在许多情况下会是错误的，我们不得不接受这种权衡。但新模型具有更好的判断力，可以在没有明确规则的情况下很好地处理这些决策。

在新的系统提示中，我们说：编写与周围代码风格一致的代码：匹配其注释密度、命名和习惯用法。

**过去：给 Claude 示例 现在：设计接口 **工具使用的第一条规则是给 Claude 使用示例。对于我们的最新模型，我们发现提供示例反而会将它们限制在某个探索空间内。

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

例如，在 Todo 工具示例中，只需将状态列为待办、进行中和已完成，就能暗示 Claude 如何使用它。指示保持一个项目处于进行中的状态有助于定义我们所要求的行为。

过去：全部放在前面 现在：使用渐进式披露

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

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

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

同样的方法也可以应用于你自己的 CLAUDE.md 和 Skill.md 文件。一个常见的迷思是你希望将它们作为可能遇到的所有已知实践的中心仓库，因为否则 Claude 不会找到它们。相反，考虑建立一棵文件树，可以在适当的时候加载。

过去：重复自己 现在：简单的工具描述

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

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

过去：在 CLAUDE.md 文件中存储记忆 现在：自动记忆

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

过去：简单的规范 现在：丰富的参考

在计划模式下，Claude Code 严重依赖包含计划的 markdown 文件。将这些文件存储为计划有助于 Claude 在需要时引用它们。另一个类似的最佳实践是将规范存储在代码库中，供 Claude 在较长项目期间参考。

但我们发现 Claude 可以处理越来越复杂的参考。除了简单的 markdown 文件，Claude 还可以引用由我们新的构件功能创建的 HTML 构件。

你也可以以代码的形式给 Claude 提供参考。一个规范也可以是一个详细的测试套件，或者 Claude 可能移植的不同代码库中的一个函数。

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

将这一点应用到你的上下文中

综合所有这些，当你组装上下文时，会是什么样子？

系统提示 系统提示与产品上下文紧密相关。它告诉 Claude 它在什么产品中运作以及它在做什么。对于 Claude Code，你可能永远不需要修改它，但如果你正在构建自己的代理框架，你应该在这里投入大量时间。

CLAUDE.md 保持你的 CLAUDE.md 轻量级，简要描述你的仓库是做什么的，但将大部分标记用于代码库中的陷阱。例如，你可能将类型组织在一个单一的文件中，而不在其他地方出现。避免陈述 Claude 通过查看你的文件系统或仓库应该已经知道的“显而易见”的事项。

对于更多细节，使用渐进式披露，例如，如果你有几条关于如何验证工作的独特指令，可以创建一个验证技能，并在 CLAUDE.md 中引用它。

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

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

最好让技能编码特定的观点、知识或最佳实践，这些最好是你、你的团队或产品特有的。

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

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

尝试简化

在你的系统提示、技能和 CLAUDE.md 文件中，你可能需要像我们一样进行简化。我们推出了一条名为 claude doctor 的新命令，它将帮助你自动完成这一过程。有关更高级模型的具体提示细节，请查看我们的 Fable 现场指南。