我写过怎么 提示最新一代 Claude 5 模型，以及如何与它们迭代，弄清你到底想做什么。
但发给 Claude 的那条消息，只是它拿到的上下文里很小一块。大量上下文来自系统提示词、Skills、CLAUDE.md、memory 等。我们把这叫 上下文工程；无论用 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 Code——系统提示词、CLAUDE.md 和 Skills 都是如此。
例如，读内部使用 Claude Code 的 transcript 时，同一次请求里常见互相冲突的说法：「酌情保留文档」或「不要加注释」——系统提示词、Skills 和用户请求彼此打架。
一般 Claude 能读懂用户意图并走到正确答案，但必须先更仔细地权衡这些重叠、冲突的信息，再决定做什么。
这些约束曾经是为了避开最坏情况；后来发现很多可以删掉，让模型靠周边上下文和判断力自行处理。
另外，Claude Code 现在工具更多了。以前 CLAUDE.md 几乎是记忆、信息和指引的唯一来源；现在有 memory、artifacts 和 Skills，Claude 可以用新方式跨会话加载与共享上下文。
从前与现在
不少旧的上下文工程「最佳实践」已经成了神话，包括：
从前：给 Claude 定规则
现在：让 Claude 用判断力
Claude Code 刚推出时，必须确保 Claude 避开删文件这类最坏情况。于是我们会给出特别强硬、并不总成立的指引。例如系统提示词里曾经写：
写代码时：默认不加注释。绝不写多段 docstring 或多行注释块——最多一行短注释。除非用户要求，否则不要创建规划、决策或分析文档——从对话上下文工作，不要用中间文件。
但对一部分提示词，这条指引是错的。文档方面用户可能有自己的偏好；极复杂代码的某些部分也可能需要多行注释。
没有这些护栏时，旧模型写的注释很多情况下是错的，我们只能接受这个权衡。新模型判断力更好，没有明文规则也能处理好这些决定。
新系统提示词里我们写：写出来的代码要读起来像周围代码：匹配它的注释密度、命名和惯用法。
从前：给 Claude 示例
现在：设计接口
工具使用的头号规则曾是：给 Claude 示例教它怎么用。对最新模型，我们发现给示例反而会把它锁在某一探索空间里。
与其堆示例，不如多想工具、脚本和文件的设计——Claude 有哪些参数、怎样更有表达力？
例如在 Todo 工具里，把 status 列成 pending、in_progress、completed 的枚举，本身就在暗示怎么用。再加一条「同一时间只有一项 in_progress」，就把我们要的行为定下来了。
从前：全部前置
现在：用渐进披露
因为 Claude Code 聚焦编码，系统提示词里曾塞了代码审查与验证的详细说明。这些并不总需要，但一旦需要就很关键。
此后 Claude Code 已经很擅长渐进披露——在对的时机加载对的上下文。例如，我们把验证和代码审查挪进各自的 Skill，由 Claude Code 选择性调用。
渐进披露不只用于 Skill，也用于工具。有些工具是 deferred loading：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 可能要移植的函数。
评分标准（rubrics）是另一种引用。Rubrics 让 Claude 用 动态工作流 拉起带这些标准的 verifier Agent，去试着核验你在某一领域的品味（例如好的 API 设计长什么样）。
落到你的上下文上
合在一起，组装上下文时是什么样？
系统提示词
系统提示词与产品上下文紧绑：告诉 Claude 它在哪个产品里、在做什么。对 Claude Code，你多半不会改它；若你在 自建 Agent harness，这里值得下大功夫。
CLAUDE.md
让 CLAUDE.md 保持轻量：简要说明仓库做什么，把大部分 token 花在代码库里的坑上。例如你把类型都放在一个单体文件、别处没有。避免写那些 Claude 看文件系统或仓库就该知道的「显而易见」之事。
大量用渐进披露：若有多套独特的验证说明，做成 verification Skill，再从 CLAUDE.md 引用。
Skills
把 Skills 想成轻量指引，让 Claude 需要时去找信息。除非极关键的领域，否则避免过度约束。
长 Skill 尽量渐进披露——拆成多个文件、分开存放。
最好的 Skill 编码的是你、你的团队或产品特有的观点、知识或最佳实践。
引用
可以用 @ mention 文件当作引用。引用让 Claude 对照当前计划的深度信息。
可能是规格、mockup，甚至整份代码库。一般更偏向代码形式的文件：它给 Claude 的是清晰、高保真、用它极熟的语言写的指令。例如，设计的 HTML mockup 通常比文字描述或截图效果更好。
试着简化
在系统提示词、Skills 和 CLAUDE.md 上，你可能也需要像我们一样简化。我们上线了 claude doctor，可自动帮你做这件事。针对更强模型的提示细节，见 Fable field guide。
本文作者 Thariq Shihipar，Anthropic Member of Technical Staff。