我之前写过一篇文章，介绍怎样才能更好地为最新一代 Claude 5 模型写 prompt，以及如何通过反复与模型协作，逐渐弄清自己想构建什么。
但当你向 Claude 发送消息时，prompt 只是它所获得 context 的一小部分。更多 context 来自系统 prompt、Skills、CLAUDE.md 文件、记忆以及其他来源。我们把这称为 context engineering。无论是使用 Claude Code，还是构建自己的 agent，context engineering 都会显著影响最终结果。
单次 prompt 可以写得很具体，context 却要供许多请求共用，因此不能同样具体。那么，尤其是在不知道用户会输入什么 prompt 的情况下，该怎样为 Claude 编写这些通用提示和指导？
随着 Claude 自身能力不断进步，这件事可能比想象中更难。最近，我们发现，为最新一代 Claude 模型写 prompt 的方式发生了很大变化。针对 Claude Opus 5、Claude Fable 5 等模型，我们删掉了 Claude Code 系统 prompt 中超过 80% 的内容，而编程评估并未显示模型表现有所下降。
下面是我们在为这类新模型写 prompt 时总结出的经验，以及如何据此更新你的 context engineering。我们已经把这些最佳实践放进了 `claude doctor`；在 Claude Code 中使用 /doctor 命令，就能把 Skills 和 CLAUDE.md 文件调整到合适的规模。
给 Claude 松绑
总体来看，我们发现，无论是系统 prompt，还是 CLAUDE.md 文件和 Skills，都给 Claude Code 加了太多限制。
例如，我们查看内部使用 Claude Code 的对话记录时，会发现同一个请求里同时出现几条互相冲突的信息，比如“在适当的地方补充文档”和“不要添加注释”。这是因为系统 prompt、Skills 和用户请求彼此冲突。
一般来说，Claude 能读懂用户的意图并把事情做对。但面对这些重叠甚至冲突的信息，它必须更仔细地权衡，才能决定该怎么做。
这些限制过去确实有必要，可以避免最坏情况。不过后来我们发现，其中很多都可以删掉，让模型结合周围的 context 自行判断。
此外，Claude Code 如今拥有的工具也多得多。过去，Claude 主要依赖 CLAUDE.md 获取记忆、信息和指导。现在有了记忆、产物和 Skills，Claude 可以用新的方式加载 context，并在不同会话之间共享 context。
过去与现在
过去的一些 context engineering 最佳实践，如今已经成了误区。比如：
过去：给 Claude 规则
现在：让 Claude 自己判断
Claude Code 刚推出时，我们必须确保 Claude 不会做出删除文件之类的最坏行为。因此，我们会给出非常强硬、但并非总是适用的指导。例如，系统 prompt 过去会这样写：
写代码时，默认不添加注释。绝不要写多段 docstring 或多行注释块——最多一行简短注释。除非用户要求，否则不要创建规划、决策或分析文档；应根据对话 context 工作，而不是依赖中间文件。
但面对某些 prompt，这种指导并不合适。以文档为例，用户可能有自己的偏好；非常复杂的代码中，某些部分也确实需要多行注释。
即便如此，旧模型如果没有这些护栏，写出的注释往往会出错，所以我们不得不接受这种取舍。但新模型的判断力更强，即使没有明确规则，也能妥善作出这些决定。
新的系统 prompt 里，我们只说：代码风格要与周围代码一致，包括注释密度、命名方式和惯用写法。
过去：给 Claude 示例
现在：把接口设计好
以前，使用工具的第一原则，是用示例告诉 Claude 应该怎样操作。但在最新模型上，我们发现，示例反而会把模型限制在特定的探索范围内。
与其提供示例，不如多花些心思设计工具、脚本和文件：Claude 能使用哪些参数？怎样让这些参数表达更多意图？
以 Todo 工具为例，只要把状态列为 pending、in_progress 和 completed 这几个枚举值，就已经在暗示 Claude 应该如何使用它。再说明只能有一个事项处于 in_progress 状态，就能界定我们想要的行为。
过去：把所有内容都放在最前面
现在：渐进式披露
Claude Code 主要用于编程，因此我们的系统 prompt 过去包含如何做代码审查和验证的详细说明。这些内容并非总能用到，但需要时又至关重要。
此后，Claude Code 越来越擅长渐进式披露（progressive disclosure），也就是在合适的时机加载合适的 context。例如，我们把验证和代码审查分别移进独立的 Skills，让 Claude Code 按需调用。
渐进式披露不只适用于 Skills，也适用于工具。我们有些工具采用“延迟加载”：agent 必须先用 ToolSearch 找到完整定义，才能使用它们。这样一来，我们就能提供更多工具（比如 Task 工具），同时又不让它们在用到之前占用 context。
同样的做法也适用于你自己的 CLAUDE.md 和 Skill.md 文件。一种常见误区是，应该把所有将来可能遇到的实践都集中存放在这些文件里，否则 Claude 就找不到。更好的做法是，建立一棵能在合适时机按需加载的文件树。
过去：重复说明
现在：简洁的工具描述
早期 Claude 模型有时需要反复提醒，而且相比 context 窗口开头的指令，它们可能更容易听从末尾的指令。因此，我们有时不仅会在工具描述里写使用说明，还会在主系统 prompt 中再次提到这些工具。
后来我们发现，这些重复示例可以删掉。如何使用工具，写在工具描述里即可，不必再放进系统 prompt。
过去：把记忆放进 CLAUDE.md 文件
现在：自动记忆
过去，我们鼓励用户把内容存进 Claude 的记忆里：按下 # 快捷键，就能自动写入用户的 CLAUDE.md。现在，Claude 会自动保存与当前工作和用户本人相关的记忆。
过去：简单的规格说明
现在：丰富的参考资料
在 plan mode 中，Claude Code 一直非常依赖记录计划的 Markdown 文件。把计划存成文件，能让 Claude 在需要时回来查阅。另一个类似的最佳实践，是把规格说明存进代码库，供 Claude 在长期项目中持续参考。
但我们发现，Claude 已经能处理越来越复杂的参考资料。除了简单的 Markdown 文件，它还可以读取新 artifacts 功能生成的 HTML 产物。
你也可以把代码本身作为参考资料交给 Claude。一套详细的测试可能就是规格说明；另一个代码库中的函数，也可能成为 Claude 移植功能时的参考。
评分标准也是一种参考资料。有了评分标准，Claude 就能借助动态工作流启动验证 agent，边尝试边检验结果是否符合你在某个领域的品味，比如怎样才算好的 API 设计。
把这些原则用到你的 context 中
把这些经验合在一起，实际组装 context 时应该怎么做？
系统 prompt
系统 prompt 与具体产品紧密相关。它会告诉 Claude 自己正在什么产品中运行、要做什么。使用 Claude Code 时，你大概永远不会修改它；但如果你在构建自己的 agent harness，这部分就值得投入大量时间。
CLAUDE.md
让 CLAUDE.md 保持轻量，简要说明代码库的用途，把大部分篇幅留给代码库里那些容易踩的坑。例如，你的代码组织方式可能要求所有类型都放在一个大文件中，其他地方一律不放。那些 Claude 只要查看文件系统或代码库就能知道的“显而易见之事”，不要再写进去。
更多细节用渐进式披露来提供。例如，如果你对如何验证工作结果有几条特殊要求，可以创建一个验证 Skill，再从 CLAUDE.md 中引用它。
Skills
把 Skills 看成轻量指南，帮助 Claude 在需要时找到信息。除非涉及非常重要的领域，否则不要设置过多限制。
Skills 很长时，应尽量使用渐进式披露：把内容拆开，分别放进多个文件。
Skills 最适合承载你个人、团队或产品特有的观点、知识和最佳实践。
参考资料
你可以用 @ 提及文件，把它们加入参考资料。参考资料让 Claude 能查阅当前计划所需的详细信息。
它可以是规格文件、设计稿，甚至整个代码库。一般来说，应优先提供代码形式的资料，因为代码能用 Claude 非常熟悉的语言，给出清晰而高保真的指导。例如，一份 HTML 设计原型通常会比设计描述或截图带来更好的结果。
试着做减法
你的系统 prompt、Skills 和 CLAUDE.md 文件可能也需要像我们一样做减法。我们推出了一个名为 `claude doctor,` 的新命令，也能自动帮助你完成这件事。如果想进一步了解如何专门为更先进的模型写 prompt，可以阅读我们的 Fable 实战指南。