我此前写过，如何最好地提示新一代 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 Code 现在拥有更多工具。过去，Claude 依赖 CLAUDE.md 作为记忆、信息和指导的来源；现在则有记忆、artifacts 与 Skills，可以借此创造在会话之间加载和共享上下文的新方式。
过去与现在
过去有不少上下文工程的最佳实践，如今已经成了迷思，包括：
过去：给 Claude 规则
现在：让 Claude 运用判断
Claude Code 刚推出时，我们需要确保 Claude 避开删除文件等最坏情况。因此会给出特别强的指导，但这些指导未必在所有时候都正确。例如，我们过去会在系统提示词中写：
在代码中：默认不写注释。绝不要编写多段 docstring 或多行注释块——最多一行简短文字。除非用户提出要求，不要创建规划、决策或分析文档——应从对话上下文工作，而不是依赖中间文件。
但对于一部分提示，这样的指导反而是错误的。以文档为例，用户可能有自己的偏好；而某些极其复杂的代码也可能确实需要多行注释块。
不过，旧模型若没有这些护栏，很多情况下写出的注释会不正确，我们不得不接受这种取舍。新模型则有了更好的判断力，即使没有明确规则，也能妥善处理这类决策。
在新的系统提示词中，我们写道：让代码读起来与周边代码一致：匹配其注释密度、命名方式和惯用风格。
过去：给 Claude 示例
现在：设计接口
过去，工具使用的头号原则是向 Claude 提供如何使用工具的示例。我们发现，对于最新模型，这些示例实际上会把它们限制在特定的探索空间中。
与其提供示例，不如更多思考工具、脚本和文件的设计：Claude 可使用哪些参数？怎样让这些参数更具表达力？
例如，在 Todo 工具中，仅仅把 status 列为 pending、in_progress 和 completed 的枚举值，就已暗示 Claude 应如何使用它；“始终只保留一项处于 in_progress”的说明，则进一步定义了我们想要的行为。
过去：把所有内容都放在前面
现在：使用渐进式披露
由于 Claude Code 最初聚焦于编码，我们的系统提示词包含了如何进行代码审查和验证的详细说明。这些信息并非总是需要，但一旦需要就至关重要。
此后，Claude Code 已非常擅长渐进式披露——在恰当的时机加载恰当的上下文。举例来说，我们把验证和代码审查移入各自的 Skills，让 Claude Code 按需调用。
渐进式披露不只适用于 Skills，也适用于工具。我们的一些工具采用“延迟加载”：agent 必须先通过 ToolSearch 搜索其完整定义后才能使用。这样一来，我们可以拥有更多工具（例如 Task 工具），而它们不会在需要前就占用上下文。
同样的做法也能用于自己的 CLAUDE.md 和 Skill.md 文件。一个常见迷思是，应把它们做成收录所有可能遇到的已知实践的中央仓库，仿佛不这样 Claude 就找不到信息。相反，可以考虑建立一棵能在合适时机加载的文件树。
过去：重复自己
现在：简洁的工具描述
早期 Claude 模型有时需要重复指令，或更容易听从上下文窗口末尾、而非开头的指令。因此，我们的系统提示词有时会在主体中提及工具，同时又在工具描述中重复使用示例。
我们发现，可以删除这些重复示例，把工具的使用说明放进工具描述，而不是系统提示词。
过去：把记忆放进 CLAUDE.md 文件
现在：自动记忆
过去，我们鼓励用户使用 # 热键，将内容自动写入自己的 CLAUDE.md 以保存 Claude 的记忆。如今，Claude 会自动保存与工作和用户相关的记忆。
过去：简单规格
现在：丰富参考资料
在 plan mode 中，Claude Code 曾高度依赖存放计划的 Markdown 文件。将这些文件存为计划，可帮助 Claude 在需要时再次引用。另一项类似的最佳实践，是把规格存进代码库，以便在更长周期的项目工作中查阅。
但我们发现，Claude 已能处理日益复杂的参考资料。与简单的 Markdown 文件相比，它可以引用由新 artifacts 功能创建的 HTML artifacts。
你也可以用代码形式提供参考资料。规格可以是一套详细的测试，也可以是另一个代码库中 Claude 可能要移植的函数。
评判量表也是一种参考资料。它能让 Claude 通过动态工作流和启动验证 agent，尝试并检验你在特定领域的品味，例如什么才是优秀的 API 设计。
将这些应用到你的上下文中
把上述内容汇总起来，当你拼装自己的上下文时，具体应该怎么做？
系统提示词
系统提示词与产品上下文紧密相关。它告诉 Claude 正在什么产品中运行，以及自己在做什么。对 Claude Code 而言，你大概率永远不会修改它；但如果你在构建自己的 agent harness，这正是最值得投入大量时间的地方。
CLAUDE.md
让 CLAUDE.md 保持轻量：简短说明仓库用途，再把大部分 token 留给代码库内部的陷阱。举例来说，你可能会把类型统一放在一个庞大的文件中，而不放在其他地方。避免陈述那些 Claude 只要查看文件系统或仓库就能知道的“显而易见”之事。
更细节的内容可以采用渐进式披露。例如，如果你有多项独特的工作验证指令，可以创建一个验证 Skill，再从 CLAUDE.md 引用它。
Skills
把 Skills 视作轻量指南，让 Claude 在需要时找到信息。除非是极其重要的领域，否则避免施加过多约束。
对于较长的 Skill，应尽可能使用渐进式披露：将其拆分为多个文件。
当 Skills 编码的是你、团队或产品所特有的观点、知识或最佳实践时，效果最好。
参考资料
你可以用 @ 提及文件，将其作为参考资料纳入。参考资料让 Claude 能查阅当前计划的深度信息。
它们可以是规格文件、mockup，甚至整个代码库。通常应优先选择代码中的文件，因为它能以 Claude 非常熟悉的语言，提供清晰且高保真的指令。例如，设计的 HTML mockup 通常会比设计描述或截图产出更好的结果。
尝试简化
也许你的系统提示词、Skills 和 CLAUDE.md 文件，都需要像我们一样做一次简化。我们还推出了一个名为 claude doctor 的新命令，可自动帮你完成这件事。若想进一步了解如何专门提示更先进的模型，请参阅我们的 Fable 实战指南。