Claude 5 代模型上下文工程新规则
原文：The new rules of context engineering for Claude 5 generation models 作者：Thariq Shihipar 日期：2026-07-24
我们删除了 Claude Code 为更先进模型编写的超过 80% 的系统提示词。以下是我们总结的经验，以及如何将这些经验应用到你的上下文工程中。
我之前写过关于如何最好地为最新一代 Claude 5 模型编写提示词，以及如何与它们迭代协作来发现你想构建的东西。
但当你向 Claude 发送一条消息时，提示词只是它接收到的上下文中的一小部分。你的大部分上下文是由系统提示词、技能、CLAUDE.md 文件、记忆以及其他来源组装而成的。我们称之为上下文工程（context engineering），它对你使用 Claude Code 或构建自己的智能体时产生的结果有巨大影响。
与提示词不同，上下文通常跨多个请求通用，因此它不能过于具体。那么，如何为 Claude 构建这些通用的提示词和指导，尤其是当你不知道用户的提示词会是什么时？
随着 Claude 自身能力的进化，这个问题变得出人意料地困难。最近，我们注意到为最新一代 Claude 模型编写提示词的方式发生了重大跃迁。对于 Claude Opus 5 和 Claude Fable 5 等模型，我们删除了 Claude Code 超过 80% 的系统提示词，而编码评测结果没有任何可衡量的下降。
以下是我们学到关于为这类新模型编写提示词的经验，以及你如何利用这些经验来更新你的上下文工程。我们已将这些最佳实践放入了 claude doctor 中；在 Claude Code 中使用 /doctor 命令来自动优化你的技能和 CLAUDE.md 文件。
给 Claude “解绑”
总体而言，我们发现我们过度约束了 Claude Code——无论是通过系统提示词，还是 CLAUDE.md 文件和技能。
例如，当我们阅读内部使用 Claude Code 的对话记录时，能看到单次请求中包含多条互相冲突的指令，比如”视情况留下文档注释”，或者”不要添加注释”——系统提示词、技能和用户请求相互冲突。
通常，Claude 可以理解用户意图并得出正确答案，但 Claude 必须在判断如何处理这些重叠和冲突的消息之前仔细思考。
虽然这些约束曾经是为了避免最坏情况所必需的，但我们发现可以删除其中许多约束，让模型使用周围的上下文和自身判断力来代替。
此外，Claude Code 现在拥有更多工具。Claude 过去依赖 CLAUDE.md 作为记忆、信息和指导的来源。现在我们有了记忆、制品和技能等机制，Claude 可以利用它们创建跨会话加载和共享上下文的新方式。
过去与现在
以往有许多上下文工程最佳实践，现在已变成了迷思。包括：
过去：给 Claude 规则 → 现在：让 Claude 自行判断
当我们最初推出 Claude Code 时，需要确保 Claude 避免最坏情况，比如删除文件。这意味着我们会给出特别强力的指导，即使这些指导并不总是正确的。例如，系统提示词中曾这样写：
在代码中：默认不写注释。绝不写多段落文档字符串或多行注释块——最多一行短注释。除非用户要求，不要创建规划、决策或分析文档——从对话上下文中工作，而不是中间文件。
但对于某些提示词子集，这些指导是错的。就文档而言，用户可能有自己的偏好，或者特别复杂的代码的某些部分可能需要多行注释块。
但对于旧模型来说，没有这些护栏，Claude 写的注释在很多情况下都是错误的，我们不得不接受这种权衡。但新模型有更好的判断力，可以在没有显式规则的情况下妥善处理这些决策。
在新系统提示词中，我们说：写出与周围代码风格一致的代码：匹配其注释密度、命名风格和惯用写法。
过去：给 Claude 示例 → 现在：设计接口
工具使用的头号规则一直是给 Claude 提供使用示例。但在我们最新的模型中，我们发现提供示例实际上会将它们限制在某个探索空间内。
与其使用示例，不如更多思考工具、脚本和文件的设计——Claude 有哪些参数，它们如何能更具表达力？
例如，在 Todo 工具中，仅将状态列举为 pending、in_progress 和 completed，就暗示了 Claude 如何使用它。保持一个项目为 in_progress 的指令，则帮助定义了我们期望的行为。
过去：一次性全部前置 → 现在：渐进式披露
由于 Claude Code 专注于编码，我们的系统提示词包含了关于如何做代码审查和验证的详细信息。这些并不总是必需的，但当需要时，是至关重要的信息。
自那以后，Claude Code 在渐进式披露方面变得非常擅长——在正确的时间加载正确的上下文。例如，我们将验证和代码审查移入了各自的技能中，Claude Code 可以选择性地调用它们。
但渐进式披露不仅适用于技能，我们也将其用于工具。我们的一些工具是”延迟加载”的，这意味着智能体必须使用 ToolSearch 搜索它们的完整定义才能使用。这使我们能拥有更多工具（如我们的 Task 工具），在需要之前不占用上下文。
同样的原则可以应用于你自己的 CLAUDE.md 和 Skill.md 文件。一个常见的迷思是，你想把它们做成一个中心仓库，包含你可能遇到的每一种已知实践，因为否则 Claude 就找不到。相反，考虑构建一个文件树，在需要时加载正确的文件。
过去：重复自己 → 现在：简洁的工具描述
早期的 Claude 模型有时需要重复的指令，或者更倾向于听取上下文末尾而非开头的内容。这意味着我们的系统提示词有时会在主系统提示词中引用工具，同时在工具描述中也给出指令。
我们发现可以删除这些重复示例，将工具使用说明放在工具描述中而非系统提示词中。
过去：CLAUDE.md 中的记忆 → 现在：自动记忆
我们过去鼓励用户将内容保存到 Claude 的记忆中，使用 # 快捷键自动写入 CLAUDE.md。而现在，Claude 会自动保存与工作和用户相关的记忆。
过去：简单规格文档 → 现在：丰富的参考资料
在计划模式下，Claude Code 严重依赖 Markdown 格式的计划文件。将这些文件存储为计划有助于 Claude 在需要时参考它们。另一个类似的最佳实践是将规格文档存储在代码库中，供 Claude 在跨长项目工作时参考。
但我们发现 Claude 可以处理越来越复杂的参考资料。除了简单的 Markdown 文件，Claude 还可以参考由我们新的制品功能创建的 HTML 制品。
你也可以以代码形式给 Claude 参考资料。一个规格文档也可以是一个详细的测试套件，或者是另一个代码库中 Claude 可能需要移植的函数。
评分标准是另一种形式的参考资料。评分标准允许 Claude 通过使用动态工作流并启动带有这些评分标准的验证智能体，来尝试和验证你在特定领域的品味（例如，好的 API 设计是什么样的）。
将这些应用到你的上下文中
综合来看，当你组装上下文时，应该是什么样子？
系统提示词
系统提示词与产品上下文紧密相关。它告诉 Claude 它运行在什么产品中以及它在做什么。对于 Claude Code，你大概率不会修改它；但如果你在构建自己的智能体编排框架，这是你应该投入大量时间的地方。
CLAUDE.md
保持你的 CLAUDE.md 轻量，简要描述你的仓库用途，但将大部分 Token 花在代码库内部的陷阱上。例如，你可能将类型组织在一个单一文件中而不是分散在各处。避免陈述那些 Claude 通过查看文件系统或仓库就能知道的”显而易见”的东西。
大量使用渐进式披露：例如，如果你有几条关于如何验证工作的独特指令，创建一个验证技能并从你的 CLAUDE.md 中引用它。
技能（Skills）
将技能视为轻量级指南，让 Claude 在需要时找到信息。避免使其过度受限，除非在高度重要的领域。
对于较长的技能，尽可能使用渐进式披露——将其拆分为多个文件并分散开来。
最好的技能是编码了你、你的团队或产品特有的特定观点、知识或最佳实践。
参考资料（References）
你可以 @ 提及文件将其作为参考资料包含。参考资料允许 Claude 引用关于当前计划的深入信息。
这可以是规格文件、原型甚至整个代码库。通常应优先选择代码形式的文件，因为它以 Claude 非常熟悉的语言提供了清晰、高保真的指令。例如，一个 HTML 设计原型通常比一段设计描述或截图产生更好的结果。
试着简化
在你的系统提示词、技能和 CLAUDE.md 文件中，你可能需要像我们一样进行简化。我们推出了一个新命令叫 claude doctor，它可以帮你自动完成这个优化过程。关于为更先进模型编写提示词的更多细节，请查看我们的 Fable 实操指南。
译者注：这篇文章对正在构建或使用 AI 智能体编码工具的开发者非常有价值。核心观点可以提炼为：模型越强，越需要信任其判断力而非用规则束缚它。过去我们为「防患未然」而塞入大量显式约束，但随着 Claude 5 代模型的理解和推理能力大幅提升，这些约束反而成为负担。关键转变在于——从「告诉 AI 怎么做」转向「设计好的接口让 AI 自行决策」，从「提前加载所有信息」转向「按需渐进式披露」。这实际上和软件工程中从 monolithic 到 microservices 的演进逻辑异曲同工。