我们为更先进的模型删除了 Claude Code 系统提示中超过 80% 的内容。本文分享我们从中学到的经验，以及如何将其应用到你在 Claude Code 与自建 Agent 中的上下文工程实践中。
我之前写过如何为最新一代 Claude 5 模型编写提示词，以及如何与之迭代协作、逐步明确你想要构建的东西。
但当你向 Claude 发送一条消息时，提示词只是它所获得上下文的一小部分。你的大部分上下文由系统提示、Skills、CLAUDE.md 文件、记忆以及其他来源共同拼装而成。我们称之为上下文工程，它对你使用 Claude Code 或构建自有 Agent 时所生成的结果影响巨大。
与提示词不同，上下文通常会在多次请求中被反复使用，因此它无法做到那么具体。你该如何为 Claude 构建这些通用的提示与指引——尤其是在你并不知道用户的提示可能是什么的时候？
这件事出奇地难，因为 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 和用户请求彼此矛盾——既出现「按需保留文档说明」，又出现「不要添加注释」。
通常，Claude 能够理解用户意图并给出正确的答案，但面对这些相互重叠、彼此冲突的信息，Claude 必须在决定如何行动之前更仔细地思考。
这些约束曾经是必要的，用来避免最坏的情况发生。但后来我们发现可以删掉其中的许多条，让模型借助上下文和自身判断来做决定。
此外，Claude Code 现在拥有更多的工具。过去 Claude 依赖 CLAUDE.md 作为记忆、信息的来源和指引。而现在我们有了记忆、artifacts 和 skills，Claude 可以用它们来创造在多次会话中加载和共享上下文的新方式。
过去与现在
一些过去的上下文工程最佳实践其实早已成为误区。比如：
过去：给 Claude 立规矩
现在：让 Claude 自己判断
当我们第一次推出 Claude Code 时，我们需要确保 Claude 能避开最坏的情况——例如误删文件。这意味着我们会给出一些格外强硬、但并不总是正确的指引。例如，在系统提示中我们曾经这样写：
在代码中：默认不写注释。绝不写多段 docstring 或多行注释块——最多写一行。除非用户明确要求，否则不要创建计划、决策或分析类文档——直接从对话上下文中工作，不要依赖中间文件。
但对于一部分提示来说，这种指引反而是错的。在涉及文档的场景中，用户可能有自己特定的偏好；对于某些极其复杂的代码，可能确实需要多行注释块。
即便如此，如果没有这些护栏，老模型的注释在很多场景下都会出错，我们只能接受这种权衡。但更新的模型具备更好的判断力，可以在没有显式规则的情况下妥善处理这些决策。
在新的系统提示中我们是这样写的：写与周围代码风格一致的代码：注释密度、命名和习惯用法都要对齐。
过去：给 Claude 提供示例
现在：设计接口
工具使用的第一准则曾是给 Claude 展示如何使用工具的示例。然而在我们最新的模型上，我们发现提供示例反而会把它约束在某一个固定的探索空间内。
比起提供示例，不如多花心思在你的工具、脚本和文件的设计上——Claude 可以使用哪些参数，这些参数又该如何更具表达力？
例如，在 Todo 工具的示例中，只要把 status 列成 pending、in_progress 和 completed 三种取值，就已经在向 Claude 暗示该怎么用了。再加上一条「同一时刻只保留一项为 in_progress」的约束，就能把期望行为刻画清楚。
过去：把所有信息一股脑放到最前面
现在：按需渐进加载（progressive disclosure）
因为 Claude Code 最初聚焦于编程场景，我们的系统提示里写入了关于如何进行代码审查和验证的详细信息。这些信息并不总是需要，但一旦需要，便是关键信息。
此后，Claude Code 已经能够非常熟练地使用渐进加载——在恰当的时机加载恰当的上下文。例如，我们把验证和代码审查移到各自的 skill 中，由 Claude Code 按需调用。
不过渐进加载不止适用于 skills，对工具同样适用。我们的一些工具采用了「延迟加载」机制：Agent 必须先通过 ToolSearch 检索到完整的工具定义，然后才能调用它们。这让我们能够拥有更多工具（比如 Task 系列工具），而它们在真正被用到之前都不会占用上下文。
同样的方法也可以用在你自己的 CLAUDE.md 和 Skill.md 文件上。一种常见误区是：把这些文件做成一份「什么最佳实践都可能用到」的中央知识库，因为你担心 Claude 找不到。而正确做法恰恰相反——考虑构建一个按需加载的文件树。
过去：反复重复同一件事
现在：工具描述要简洁
更早的 Claude 模型有时需要重复指令，或者更容易听进上下文末尾的指令、忽略开头的指令。这导致我们的系统提示中常常会在主提示里引用某个工具，同时又把使用说明写在工具描述里。
后来我们发现可以删掉这些重复，把工具的使用说明直接放在工具描述里，而不是塞在系统提示中。
过去：把记忆写进 CLAUDE.md
现在：自动记忆
我们曾经鼓励用户通过 # 快捷键把信息存进 CLAUDE.md，从而保存到 Claude 的记忆中。而现在，Claude 会自动保存与当前工作以及与你个人相关度高的记忆。
过去：使用简单的规格说明
现在：使用更丰富的参考资料
在 plan 模式下，Claude Code 长期依赖以 Markdown 文件形式存储的 plan。把 plan 存成文件，便于 Claude 在需要时回查。类似的最佳实践还有：把规格说明放在代码库里，让 Claude 在更长的项目中随时查阅。
但我们发现 Claude 能处理的参考资料形式正在变得越来越复杂。Claude 不再局限于简单的 Markdown 文件，而是可以引用由新 artifacts 功能生成的 HTML artifacts。
你也可以以代码形式给 Claude 提供参考资料。一份规格说明可以是一套详尽的测试用例，也可以是另一个代码库中、Claude 可能移植过去的某个函数。
评分量表（Rubrics）是另一种形式的参考资料。借助动态工作流，评分量表能让 Claude 围绕某一领域（例如「一个好的 API 设计长什么样」）调用校验 Agent 来验证你的品味。
把这些原则应用到你的上下文
把这些原则放到一起，当你拼装上下文时，具体应该怎么做？
系统提示
系统提示与产品上下文强绑定。它告诉 Claude 自己处于什么产品中、正在做什么。对于 Claude Code，你基本不需要修改它；但如果你正在自建 Agent 框架，这是你最该花时间的地方。
CLAUDE.md
把 CLAUDE.md 写得轻量一些，简短说明你这个仓库是做什么的，把大部分 token 留给代码库内部的「踩坑点」。例如，你可能把代码组织成「所有类型集中在一个大文件里、别处不再出现」这种结构。要避免把那些 Claude 通过浏览文件系统或仓库结构就能知道的「显而易见」的事写进去。
大量使用渐进加载：例如，如果你有几条关于如何验证工作的特殊指令，可以建一个 verification skill，然后在 CLAUDE.md 中引用它。
Skills
把 skills 看作让 Claude 在需要时能找到信息的轻量指南。除非是极为关键的领域，否则不要把它们写得过度约束。
对于较长的 skill，尽可能使用渐进加载——拆成多个文件分散组织。
最好的 skill 是那些编码了特定立场、知识或最佳实践的内容——专属于你、你的团队或你的产品。
参考资料
你可以使用 @ 提及文件来将它们作为参考资料。参考资料让 Claude 能够查阅与当前 plan 相关的深度信息。
这些可以是规格文件、UI mockup，甚至整个代码库。通常你应该优先使用代码形式的文件，因为它们能以 Claude 非常熟悉的语言提供清晰、高保真的指令。例如，一张设计的 HTML mockup 通常会比一段设计描述或一张截图产生更好的结果。
尝试做减法
在你的系统提示、skills 和 CLAUDE.md 文件中，你可能也需要像我们一样做减法。我们上线了一条新命令 claude doctor;，它可以帮你自动完成这件事。想了解关于如何针对更先进模型编写提示词的更多细节，请阅读我们的 Fable 实战手册。
本文作者：Thariq Shihipar，Anthropic 技术团队成员。