核心思想
用户提示只是上下文的一小块；真正决定产出质量的是系统提示词、Skills、CLAUDE.md、记忆等跨请求复用的上下文工程。面对 Claude Opus 5 / Fable 5 这类新模型，Claude Code 删掉了超过 80% 的系统提示词，编码评测却无明显损失——旧时代的护栏（硬规则、堆示例、全量前置、反复强调）已变成迷思。新范式是：让模型用判断力、用接口表达力代替示例、用渐进式披露按需加载，并用
claude doctor//doctor精简你自己的 Skills 与 CLAUDE.md。
我之前写过如何更好地提示新一代 Claude 5 模型，以及如何与它们迭代协作，逐步摸清你真正想构建的东西。
但当你向 Claude 发送一条消息时，提示词只是它拿到的上下文里很小的一块。大量上下文其实拼装自系统提示词、Skills、CLAUDE.md、记忆（memory）以及其他来源。我们称之为上下文工程（context engineering）；无论你是在用 Claude Code，还是在搭建自己的智能体，它都会大幅影响最终产出。
与单次用户提示不同，上下文往往会跨许多请求复用，因此不能写得太具体。问题在于：在并不知道用户会问什么的前提下，你该如何为 Claude 构建这些通用的提示与指引？
随着 Claude 自身能力演进，这件事会出奇地难。最近我们注意到，面向最新一代 Claude 模型的提示方式出现了一次大幅跃迁。对 Claude Opus 5、Claude Fable 5 这类模型，我们删掉了 Claude Code 系统提示词里超过 80% 的内容，编码评测上却没有可测量的损失。
下面是我们在提示这类新一代模型时学到的东西，以及你如何据此更新自己的上下文工程。这些最佳实践已经写进 claude doctor：在 Claude Code 中运行 /doctor，即可合理精简（rightsize）你的 skills 与 CLAUDE.md。
给 Claude 解绑
总体来看，我们发现自己过度约束了 Claude Code——系统提示词如此，CLAUDE.md 与 skills 亦然。
举例来说，阅读内部使用 Claude Code 的对话记录时，我们常在同一次请求里看到互相打架的信息：有的说「文档酌情保留」，系统提示词却写着「不要添加注释」——skills 与用户请求彼此冲突。
通常 Claude 仍能读懂用户意图并走到正确结论；但在决定怎么做之前，它必须更仔细地权衡这些重叠且矛盾的信息。
这些约束曾经必要，用来兜住最坏情况；但我们后来发现，其中许多都可以删掉，改让模型依靠周围上下文与判断力。
与此同时，Claude Code 可用的工具也多得多了。过去 Claude 主要靠 CLAUDE.md 充当记忆、信息与指引的来源；现在有了 memory、artifacts 和 skills，Claude 能以新的方式在会话之间加载与共享上下文。
从前与现在
不少曾经的上下文工程「最佳实践」，如今已变成迷思，其中包括：
从前：给 Claude 定规则 → 现在：让 Claude 运用判断力
Claude Code 刚上线时，我们必须确保 Claude 避开最坏情况——比如误删文件。于是我们会给出特别强硬、却未必总成立的指引。例如系统提示词里曾写：
写代码时：默认不要写注释。绝不写多段 docstring 或多行注释块——最多一行短注释。除非用户明确要求，否则不要创建规划、决策或分析类文档——依托对话上下文推进，而不是依赖中间文件。
但对一部分提示来说，这类指引是错的。文档方面，用户可能自有偏好；极复杂代码的某些局部，也可能确实需要多行注释。
即便如此，对旧模型若拿掉这些护栏，Claude 写出的注释在很多场景仍会不对，我们只能接受这种取舍。新模型判断力更强，不必靠一条条显式规则也能处理好这些决策。
新系统提示词改成了：
写出读起来像周围代码的代码：匹配其注释密度、命名与惯用风格（idiom）。
从前：给 Claude 示例 → 现在：设计接口
工具使用的头号法则曾是：示范 Claude 该怎么用。面对最新模型，我们发现：给示例反而会把它们锁进某个探索范围。
与其堆示例，不如多想工具、脚本与文件的设计——Claude 能用哪些参数？怎样让这些参数更有表达力？
以 Todo 工具为例：只需把 status 定义为 pending、in_progress、completed 这一组枚举，就足以暗示用法；而「同一时间只让一项处于 in_progress」这类指令，则用来界定我们期望的行为。
从前：一股脑全部前置 → 现在：渐进式披露
因为 Claude Code 聚焦编码，系统提示词里曾塞进代码评审与验证的详细说明。它们并非每次都需要，但一旦需要，又至关重要。
此后，Claude Code 在**渐进式披露（progressive disclosure）**上已经相当成熟——在对的时机加载对的上下文。例如，我们把验证与代码评审拆成独立 skills，由 Claude Code 选择性地调用。
渐进式披露不只用于 skills，也用于工具。部分工具采用延迟加载（deferred loading）：智能体必须先通过 ToolSearch 检索完整定义，才能使用。这样我们可以保留更多工具（例如 Task 相关工具），却不会在用到之前占用上下文。
同一思路也适用于你自己的 CLAUDE.md 与 Skill.md。常见迷思是：把所有可能碰上的实践都塞进一个包罗万象的中央库，否则 Claude 就找不到。更好的做法是，用一棵能在恰当时机加载的文件树。
从前：反复强调 → 现在：简洁的工具描述
更早的 Claude 有时需要重复指令，也更倾向于听从上下文窗口末尾、而非开头的指示。于是主系统提示词里会引用工具，工具描述里又再写一遍用法。
我们发现这些重复可以删掉：把「如何使用工具」写进工具描述即可，不必再堆进系统提示词。
从前：记忆写在 CLAUDE.md → 现在：自动记忆（auto-memory）
我们曾鼓励用户把内容存进 Claude 的记忆——用 # 快捷键自动写入 CLAUDE.md。现在不同了：Claude 会自动保存与当前工作、以及与你相关的记忆。
从前：简单规格 → 现在：丰富引用
在 plan 模式里，Claude Code 长期依赖带有计划内容的 markdown 文件。把计划落成文件，方便 Claude 需要时回看。类似做法还有：在代码库中存放规格（specs），供 Claude 在更长项目中参照。
但我们发现 Claude 已能处理越来越复杂的引用。除了简单 markdown，它还可以引用新 artifacts 功能生成的 HTML 产物。
你也可以用代码作为引用。一份规格可以是详尽的测试套件，也可以是另一个代码库里 Claude 可能要移植的函数。
评分标准 / 量规（rubrics） 是又一种引用。Rubrics 让 Claude 能尝试对齐你在某一领域的品味（例如「好的 API 设计长什么样」）——借助动态工作流，并拉起携带这些量规的验证智能体（verifier agents）。
应用到你的上下文
把以上合在一起，组装上下文时大致是这样：
系统提示词（System Prompt）
系统提示词与产品语境深度绑定：它告诉 Claude 自己处在什么产品里、正在做什么。使用 Claude Code 时，你多半永远不会改它；但若你在构建自己的智能体 harness（编排层），这里才是最该投入时间的地方。
CLAUDE.md
保持轻量：用几句话说明仓库用途，把大部分 token 花在代码库内部的暗坑（gotchas）上。例如，你们可能把类型全部集中在一个单体文件、别处都不放。别写那些 Claude 扫一眼文件系统或仓库就该明白的「显而易见」之事。
细节走渐进式披露：若你有多套独特的验证说明，做成 verification skill，再从 CLAUDE.md 引用它。
Skills
把 skills 想成轻量导览，让 Claude 在需要时能找到信息。除了少数高度关键的领域，尽量避免过度约束。
长 skills 尽量渐进式披露——拆成多个文件并分开存放。
Skills 的最佳形态，是沉淀专属于你、你的团队或产品的观点、知识与最佳实践。
引用（References）
你可以用 @ 提及文件，把它们纳入引用。引用让 Claude 能回看与当前计划相关的深度信息。
对象可以是规格、设计稿，甚至整个代码库。一般应优先代码形式的材料——它用 Claude 极为熟悉的语言，提供清晰、高保真的指令。例如，一份设计的 HTML mockup，通常比纯文字描述或截图效果更好。
试着简化
无论是系统提示词、skills 还是 CLAUDE.md，你或许都需要像我们一样做简化。我们上线了新命令 claude doctor，可以自动帮你完成这件事。若要更深入了解如何提示更先进的模型，请参阅 Fable field guide。