Context Engineering · 中文译文
Claude 5 Context Engineering 教程:为什么 Prompt 已经不够用了?
The new rules of context engineering for Claude 5 generation models
本文译自 Claude by Anthropic 官方博客,版权归原作者及 Anthropic 所有。若译文与原文存在差异,请以英文原文为准。文中产品与功能以原文所述产品为准。
过去:给 Claude 制定规则
现在:让 Claude 自行判断
最初推出 Claude Code 时,我们需要确保 Claude 避免最糟糕的情况,例如删除文件。这意味着我们会给出非常强硬、但未必始终正确的指导。例如,我们过去会在系统 Prompt 中这样写:
编写代码时:默认不写注释。绝不要编写包含多个段落的文档字符串或多行注释块——最多只能写一行简短注释。除非用户提出要求,否则不要创建规划、决策或分析文档——应根据对话 Context 开展工作,而不是依赖中间文件。
但对于某些 Prompt,这些指导并不正确。以文档为例,用户可能有自己的偏好,或者非常复杂的代码中某些特定部分可能确实需要多行注释块。
尽管如此,如果旧模型缺少这些护栏,Claude 写出的注释在许多情况下都会不正确,因此我们不得不接受这种权衡。但新模型的判断力更强,即使没有明确规则,也能妥善处理这些决策。
在新的系统 Prompt 中,我们这样写:编写与周围代码风格一致的代码:匹配其注释密度、命名方式和惯用写法。
过去:给 Claude 提供示例
现在:设计接口
工具使用的首要规则曾经是向 Claude 提供使用示例。对于最新的模型,我们发现,提供示例实际上会将模型限制在某个特定的探索空间内。

与其使用示例,不如更多地思考工具、脚本和文件的设计——Claude 可以使用哪些参数?怎样才能让这些参数具有更强的表达能力?
例如,在 Todo 工具的示例中,仅仅把状态列为 pending、in_progress 和 completed 之间的枚举,就能向 Claude 暗示该如何使用它。要求保持一个项目处于 in_progress 状态的指令,则有助于定义我们所期望的行为。
过去:把所有内容都预先放进去
现在:使用渐进式披露
由于 Claude Code 专注于编码,我们的系统 Prompt 中包含了关于如何进行代码审查和验证的详细信息。虽然并非总会用到这些信息,但一旦需要,它们就至关重要。
此后,Claude Code 已经非常擅长使用渐进式披露——在恰当的时机加载恰当的 Context。例如,我们把验证和代码审查分别移入了独立的 Skills,让 Claude Code 可以选择性地调用它们。
但渐进式披露不仅适用于 Skills,我们也将它用于工具。我们的部分工具采用“延迟加载”,这意味着 Agent 在使用它们之前,必须先通过 ToolSearch 搜索其完整定义。这样一来,我们便可以提供更多工具(例如 Task 工具),而它们只有在需要时才会占用 Context。
同样的方法也可以应用于你自己的 CLAUDE.md 和 Skill.md 文件。一个常见的误区是,你应该把这些文件建成一个中央知识库,收录你可能遇到的每一种已知实践,因为否则 Claude 就找不到它们。更好的做法是,考虑构建一棵可在恰当时机加载的文件树。
过去:反复重申
现在:简洁的工具描述
早期的 Claude 模型有时需要重复指令,或者相较于 Context 窗口开头的指令,更容易听从末尾的指令。这意味着,我们有时不仅会在工具描述中提供说明,还会在主系统 Prompt 中引用工具。
我们发现,可以删除这些重复的示例,并把工具使用说明放在工具描述中,而不是放在系统 Prompt 里。
过去:在 CLAUDE.md 文件中保存记忆
现在:自动记忆
我们过去鼓励用户把内容保存到 Claude 的记忆中,方法是使用 # 快捷键自动写入其 CLAUDE.md。现在,Claude 会自动保存与你和当前工作相关的记忆。
过去:简单的规格说明
现在:丰富的参考资料
在计划模式中,Claude Code 一直高度依赖包含计划的 Markdown 文件。将这些文件保存为计划,有助于 Claude 在需要时参考它们。另一个类似的最佳实践,是把规格说明存储在代码库中,供 Claude 在处理周期较长的项目时参考。
但我们发现,Claude 已经能够处理越来越复杂的参考资料。除了简单的 Markdown 文件外,Claude 还可以参考由新的 artifacts 功能创建的 HTML artifact。
你也可以用代码的形式向 Claude 提供参考资料。规格说明也可以是一套详细的测试,或者是另一个代码库中可供 Claude 移植的函数。
评分标准是另一种参考资料。通过使用动态工作流,并基于这些评分标准启动验证 Agent,评分标准可以让 Claude 尝试理解并验证你在特定领域的品味(例如,优秀的 API 设计应该是什么样)。
将这些原则应用于你的 Context
把以上内容整合起来后,在组装 Context 时应该是什么样子?

系统 Prompt
系统 Prompt 与产品 Context 高度相关。它会告诉 Claude,自己正在哪个产品中运行,以及正在做什么。对于 Claude Code,你很可能永远不需要修改它;但如果你正在构建自己的 Agent 框架,就应该在这方面投入大量时间。
CLAUDE.md
让 CLAUDE.md 保持轻量,并简要说明代码仓库的用途,但应把大部分 Token 用于记录代码库中的易踩坑之处。例如,你可能会规定将所有类型集中放在一个单体文件中,其他任何地方都不能定义类型。不要陈述那些 Claude 通过查看文件系统或代码仓库就应该知道的“显而易见”的事情。
大量使用渐进式披露。例如,如果你有多条关于如何验证工作的独特指令,可以创建一个验证 Skill,并在 CLAUDE.md 中引用它。
Skills
可以把 Skills 看作轻量级指南,帮助 Claude 在需要时找到信息。除非涉及极其重要的领域,否则应避免给 Skills 加上过多约束。
对于较长的 Skills,应尽可能采用渐进式披露——把内容拆分到多个文件中。
如果 Skills 编码了你、你的团队或产品所特有的观点、知识或最佳实践,效果会最好。
参考资料
你可以通过 @ 提及文件,将其作为参考资料纳入 Context。参考资料让 Claude 能够查阅有关当前计划的深入信息。
这些参考资料可能是规格说明文件、模型稿,甚至整个代码库。通常应该优先选择以代码形式呈现的文件,因为代码能用 Claude 非常熟悉的语言,为其提供清晰且高保真的指令。例如,相较于设计说明或截图,一份设计的 HTML 模型稿通常能带来更好的结果。
尝试做减法
你的系统 Prompt、Skills 和 CLAUDE.md 文件可能都需要像我们一样进行简化。我们推出了一个名为 claude doctor, 的新命令,它也能帮助你自动完成这项工作。要进一步了解如何专门为更先进的模型编写 Prompt,请参阅我们的 Fable 实战指南。
本文由 Anthropic 技术团队成员 Thariq Shihipar 撰写。