对于更先进的模型，我们删除了 Claude Code 超过 80% 的系统提示词。如何将我们学到的经验应用于你自己的 Claude Code 上下文工程，以及你自己的智能体构建中。
- 分类Claude Code智能体
- 产品Claude CodeClaude EnterpriseClaude 平台
- 日期2026 年 7 月 24 日
- 阅读时间5分钟
- https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models
我之前写过关于如何最好地为最新一代 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 作为记忆、信息和指导的来源。现在我们有了 memory、artifacts 和 skills，Claude 可以利用它们创造新的方式来跨会话加载和共享上下文。
过去与现在
此前有不少上下文工程的最佳实践已经变成了“神话”。其中包括：
过去：给 Claude 定规则
现在：让 Claude 运用判断力
当我们最初推出 Claude Code 时，我们需要确保 Claude 避免最坏情况，比如删除文件。这意味着我们会给出一些非常强硬的指导，而这些指导未必总是正确的。例如，在系统提示词中我们曾经这样写：
在代码中：默认不写注释。绝不写多段 docstring 或多行注释块——最多一行短注释。除非用户要求，不要创建规划、决策或分析文档——从对话上下文工作，不要依赖中间文件。
但对于某一部分提示词来说，这条指导是错误的。以文档为例，用户可能有自己的偏好，或者非常复杂代码的某些特定部分确实需要多行注释块。
不过，对于较旧的模型来说，如果没有这些护栏，Claude 写的注释在很多情况下都会出错，我们不得不接受这种取舍。但较新的模型判断力更好，即使没有明确的规则，也能很好地处理这些决策。
在新的系统提示词中我们这样写：编写与周围代码风格一致的代码：匹配其注释密度、命名习惯和惯用写法。
过去：给 Claude 示例
现在：设计接口
工具使用的头号规则是给 Claude 提供如何使用工具的示例。但使用我们最新的模型，我们发现给示例实际上会把它们限制在某个特定的探索空间里。
与其使用示例，不如多思考你的工具、脚本和文件的设计——Claude 拥有哪些参数，以及如何让它们更具表现力？
例如，在 Todo 工具示例中，仅仅将状态列为 pending、in_progress 和 completed 的枚举值，就能向 Claude 提示如何使用它。关于保持一个项目处于 in_progress 状态的指令，有助于定义我们所要求的行为。
过去：把所有内容都放在最前面
现在：使用渐进式披露
由于 Claude Code 专注于编码，我们的系统提示词包含了关于如何进行代码审查和验证的详细信息。这些信息并非总是需要，但当需要时，它们却是至关重要的信息。
自那以后，Claude Code 已经非常擅长使用渐进式披露——在正确的时间加载正确的上下文。例如，我们将验证和代码审查移到了各自的技能中，Claude Code 可以有选择地调用这些技能。
但渐进式披露不仅适用于技能，我们也将其用于工具。我们的一些工具是“延迟加载”的，这意味着智能体必须在使用它们之前使用 ToolSearch 搜索其完整定义。这使我们能够拥有更多工具（例如我们的 Task 工具），这些工具在需要之前不会占用上下文。
同样的方法也可以应用于你自己的 CLAUDE.md 和 Skill.md 文件。一个常见的误解是，你想把这些文件变成你可能遇到的所有已知实践的中央存储库，因为否则 Claude 就找不到它们。相反，考虑建立一个可以在正确时间加载的文件树。
过去：重复说明
现在：简单的工具描述
早期的 Claude 模型有时可能需要重复的指令，或者更倾向于听取上下文窗口末尾的指令，而不是开头的指令。这意味着我们的系统提示词有时会在主系统提示词中引用工具，同时在工具描述中也包含指令。
我们发现可以删除这些重复的示例，并将如何使用工具的指令放在工具描述中，而不是系统提示词中。
过去：在 CLAUDE.md 文件中存储记忆
现在：自动记忆
我们过去鼓励用户通过 # 快捷键自动写入 CLAUDE.md，把内容保存到 Claude 的记忆中。而现在，Claude 会自动保存与工作和你相关的记忆。
过去：简单的规格说明
现在：丰富的参考资料
在计划模式下，Claude Code 高度依赖包含计划的 markdown 文件。将这些文件作为计划存储，有助于 Claude 在需要时进行引用。另一个类似的良好实践是将规格说明存储在代码库中，以便 Claude 在较长的项目中工作时随时参考。
但我们发现，Claude 能够处理越来越复杂的参考资料。除了简单的 markdown 文件，Claude 还可以引用我们新 artifacts 功能生成的 HTML 产物。
你也可以以代码的形式为 Claude 提供参考资料。规格说明也可以是一套详细的测试套件，或者另一个代码库中 Claude 可能需要移植的函数。
评分标准（Rubrics）是另一种参考资料形式。评分标准允许 Claude 通过动态工作流，并利用这些评分标准启动验证智能体，来尝试并验证你在特定领域的品味（例如，一个好的 API 设计应该是什么样的）。
将其应用到你的上下文中
综合以上所有内容，当你组装自己的上下文时，实际效果是怎样的？
系统提示词
系统提示词与产品上下文紧密相关。它告诉 Claude 它在什么产品中运行、正在做什么。对于 Claude Code，你很可能永远不会修改它，但如果你在构建自己的智能体框架，这才是你应该投入大量时间的地方。
CLAUDE.md
保持你的 CLAUDE.md 轻量简洁，简要描述你的代码库用途，但把大部分 token 花在代码库内部的“坑”上。例如，你可能将代码组织为把所有类型放在一个单一文件中，而不放在其他任何地方。避免陈述那些 Claude 通过查看你的文件系统或代码库就应该知道的“显而易见”的事情。
大量使用渐进式披露，例如，如果你有若干条关于如何验证工作的独特指令，可以创建一个验证技能，并从你的 CLAUDE.md 中引用它。
技能
将技能视为轻量级指南，让 Claude 在需要时能找到信息。除非在极其重要的领域，否则避免将它们设计得过度约束。
对于较长的技能，请尽可能采用渐进式披露——将其拆分为多个文件并分别展开。
技能最好能承载你、你的团队或产品所特有的观点、知识或最佳实践。
参考资料
你可以使用 @ 提及文件，将其作为参考资料包含进来。参考资料能让 Claude 查阅与当前计划相关的深入信息。
这些资料可能是规格文件、设计稿，甚至是整个代码库。通常，你应优先选择代码形式的文件，因为它能以 Claude 非常熟悉的语言，向其提供清晰、高保真的指令。例如，一份设计的 HTML 设计稿，通常比文字描述或截图效果更好。
尝试简化
在你的系统提示词、技能和 CLAUDE.md 文件中，你可能需要像我们一样进行简化。我们还推出了一个名为 `claude doctor` 的新命令，它能帮你自动完成这一过程。如需更具体地了解如何为更先进的模型编写提示词，请参阅我们的 Fable 现场指南。
本文由 Anthropic 技术团队成员 Thariq Shihipar 撰写。
We removed over 80% of Claude Code's system prompt for more advanced models. How to apply the lessons we learned to your own context engineering in Claude Code and with your own agents.
- Category
- ProductClaude CodeClaude EnterpriseClaude Platform
- DateJuly 24, 2026
- Reading time5min
- https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models
I’ve written previously about how to best prompt the newest generation of Claude 5 models and work with them iteratively to discover what you want to build.
But when you send a message to Claude, the prompt is only a small part of the context it gets. Much of your context is assembled from your system prompt, Skills, CLAUDE.md files, memory, and other sources. We call this context engineering, and it makes a big impact on the results you generate when using Claude Code or in building your own agents.
Unlike a prompt, context is used generally across many requests, so it cannot be as specific. How do you build these general prompts and guidance for Claude, especially when you don’t know what a user’s prompt might be?
This can be surprisingly difficult as Claude’s own capabilities evolve. Most recently, we noticed a large jump in the way we prompt the newest generation of Claude models. We removed over 80% of Claude Code’s system prompt for models like Claude Opus 5 and Claude Fable 5 with no measurable loss on our coding evaluations.
Here’s what we’ve learned about prompting this new class of models, and how you can utilize it to update your context engineering. We’ve put these best practices in `claude doctor;` use the command /doctor in Claude Code to rightsize your skills, and CLAUDE.md files.
Unhobbling Claude
Overall, we found that we were overconstraining Claude Code, both through our system prompt and in our CLAUDE.md files and skills.
For example, when we read transcripts of our own internal usage of Claude Code, we see several conflicting messages in a single request like “leave documentation as appropriate,” or “DO NOT add comments” as our system prompt, skills, and user requests clash with each other.
Generally, Claude can interpret the user’s intent to get to the right answer, but Claude must think more carefully about these overlapping and conflicting messages before deciding what to do.
And while these constraints were once needed to avoid worst case scenarios, we have since found we can delete many of them and let the model use surrounding context and judgement instead.
Additionally, Claude Code now has many more tools. Claude used to rely on CLAUDE.md as a source of memory, information, and guidance. Now we have memory, artifacts, and skills, which Claude can use to create new ways of loading and sharing context across sessions.
Then and now
There were a number of previous context engineering best practices that had become myths. Including:.
Then: Give Claude rules
Now: Let Claude use judgement
When we first rolled out Claude Code, we needed to be sure that Claude avoided worst case scenarios, such as deleting files. This meant we would give particularly strong guidance that might not always be true, For example, in the system prompt we used to say:
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.
But for a certain subset of prompts, this guidance would be wrong. In the case of documentation, the user may have their own preferences, or specific parts of very complex code might need multi-line comment blocks.
Still, without these guardrails for older models, the comments Claude wrote would be incorrect in many cases and we had to accept this tradeoff. But newer models have better judgement and can handle these decisions well without explicit rules.
In the new system prompt we say: Write code that reads like the surrounding code: match its comment density, naming, and idiom.
Then: Give Claude examples
Now: Design interfaces
The number one rule for tool usage was to give Claude examples on how to use them. With our newest models, we’ve found that giving examples actually constrains them to a certain exploration space.
Instead of using examples, think more about the design of your tools, scripts and files- what parameters does Claude have and how can they be more expressive?
For example, in the Todo tool example, just listing status as an enumeration between pending, in_progress, and completed, hints to Claude about how to use it. The instruction on keeping one item in_progress helps define our requested behavior.
Then: Put it all upfront
Now: Use progressive disclosure
Because Claude Code was focused on coding, our system prompt included detailed information on how to do code review and verification. These were not always needed, but when they were, it was crucial information.
Since then, Claude Code has gotten very competent at using progressive disclosure- loading the right context at the right times. For example, we moved verification and code review into their own skills that Claude Code could selectively call.
But progressive disclosure is not just for skills, we also use it for tools. Some of our tools are ‘deferred loading,’ which means the agent must search for their full definitions using ToolSearch before using them. This allows us to have more tools (such as our Task tools) that don’t take up context until they’re needed.
The same can be applied to your own CLAUDE.md and Skill.md files. A common myth is that you want to make these a central repository for every known practice that you might run into, because Claude would not find it otherwise. Instead, consider having a tree of files that can be loaded at the right time.
Then: Repeat yourself
Now: Simple tool descriptions
Earlier Claude models could sometimes need repeated instructions or be more likely to listen to instructions at the end of their context window than at the start. This meant our system prompt would sometimes have references to tools in the main system prompt as well as instructions in the tool description.
We found we could delete these repeat examples and put instructions on how to use tools in the tool descriptions rather than the system prompt.
Then: Memory in CLAUDE.md files
Now: Auto-memory
We used to encourage users to save things to Claude’s memory, by using the # hotkey to write to their CLAUDE.md automatically. Instead, Claude now automatically saves memories that are relevant to the work and to you.
Then: Simple specs
Now: Rich references
In plan mode, Claude Code has heavily relied on markdown files with plans. Storing these files as plans helped Claude refer to them when needed. Another similar best practice was to store specs in the codebase for Claude to refer to while working across longer projects.
But we’ve found that Claude can handle increasingly more complicated references. Instead of simple markdown files, Claude can reference HTML artifacts created by our new artifacts feature.
You may also give Claude references in the form of code. A spec may also be a detailed test suite, or a function in a different codebase that Claude might port.
Rubrics are another form of references. Rubrics allow Claude to try and verify your taste in a particular field (e.g. what does a good API design look like) by using dynamic workflows and spinning up verifier agents with those rubrics.
Applying this to your context
Pulling this all together, what does this look like when you assemble your context?
System Prompt
A system prompt is heavily tied to the product context. It tells Claude what product it’s operating in and what it’s doing. For Claude Code, you will likely never modify this, but if you are building your own agent harness, this is where you should spend a lot of time.
CLAUDE.md
Keep your CLAUDE.md lightweight and briefly describe what your repo is for, but spend most of the tokens on gotchas inside of the codebase. For example, you may organize your code to keep types in one monolithic file and nowhere else. Avoid stating ‘the obvious’ things Claude should know by looking at your file system or your repo.
Use progressive disclosure heavily, for example if you have several unique instructions on how to verify your work, create a verification skill and reference it from your CLAUDE.md.
Skills
Think of skills as lightweight guides to let Claude find information when needed. Avoid making them overconstrained, except in highly important areas.
For long skills, try and use progressive disclosure as much as possible- divide it into many files and split them out.
It’s best when skills encode particular opinions, knowledge, or best practices that are particular to you, your team, or product.
References
You can @ mention files to include them as references. References allow Claude to refer to in-depth information about the current plan.
This might be in specs files, mockups, or even entire codebases. Generally you should prefer files that are in code as it provides clear, high-fidelity instructions to Claude in a language it knows very well. For example, a HTML mockup of a design will generally produce better results than a description of the design or a screenshot.
Try simplifying
Across your system prompt, skills, and CLAUDE.md files, you may need to simplify just like we did. We rolled out a new command called `claude doctor,` which will help you do this automatically as well. For more details on prompting more advanced models specifically, check out our Fable field guide.
This article was written by Thariq Shihipar, member of technical staff, Anthropic.