Claude 5 代模型的上下文工程新规则

# 面向 Claude 5 代模型的上下文工程新规则 来源：https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models ## 过去与现在 过去有很多被奉为圭臬的上下文工程最佳实践，如今已沦为神话。其中包括： ### 过去：为 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 找不到。相反，应该考虑建立一个文件树，在合适的时机加载（https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code）。 ### 过去：重复说教 ### 现在：简洁的工具描述 早期的 Claude 模型有时需要重复指令，或者更倾向于听取上下文窗口末尾的指令而非开头的指令。这意味着我们的系统提示有时既要包含对工具的主要说明，又要在工具描述中重复指令。 我们发现可以删除这些重复示例，将工具的使用说明放在工具描述中，而不是系统提示里。 ### 过去：将记忆存入 CLAUDE.md 文件 ### 现在：自动记忆 过去我们鼓励用户通过 `#` 热键将内容自动写入 CLAUDE.md（http://claude.md/）来保存记忆。而现在，Claude 会自动保存与工作和用户相关的记忆。 ### 过去：简单的规格说明 ### 现在：丰富的引用 在计划模式下，Claude Code 严重依赖包含计划的 markdown 文件。将这些文件存储为计划有助于 Claude 在需要时引用它们。另一个类似的最佳实践是在代码库中存储规格说明，让 Claude 在跨较长项目工作时可以引用。 但我们发现 Claude 能够处理越来越复杂的引用。除了简单的 markdown 文件，Claude 还可以引用我们新 artifact 功能创建的 HTML 产物。 你也可以以代码的形式给 Claude 提供引用。规格说明可以是一套详细的测试套件，也可以是另一个代码库中 Claude 可能移植的函数。 评分标准是另一种引用形式。评分标准允许 Claude 通过动态工作流（https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code）和启动带有这些评分标准的验证代理，来尝试验证你在某个领域的偏好（例如，一个好的 API 设计应该是什么样的）。 ## 如何应用到你的上下文中 综合以上内容，当你组装上下文时应该怎么做？ ### 系统提示 系统提示与产品上下文紧密相关。它告诉 Claude 它在什么产品中运行以及它在做什么。对于 Claude Code，你很可能永远不需要修改它；但如果你在构建自己的代理框架，那么这应该是你花大量时间的地方。 ### CLAUDE.md 保持你的 CLAUDE.md 轻量，简要描述你的仓库用途，但把大部分标记字符用在代码库中的“注意事项”上。例如，你可能将代码组织成将所有类型放在一个单体文件中，其他地方不存。避免写那些 Claude 通过查看文件系统或仓库就能知道的“显而易见”的东西。 大量使用渐进式披露：例如，如果你有多个独特的验证工作方法，可以创建一个验证技能模块，并在 CLAUDE.md 中引用它。 ### 技能模块 将技能模块视为轻量指南，让 Claude 在需要时找到信息。除非在非常重要的领域，否则不要过度约束它们。 对于较长的技能模块，尽量使用渐进式披露——将其分成多个文件并拆分。 最好的技能模块是那些编码了只适用于你、你的团队或产品的特定意见、知识或最佳实践。 ### 引用 你可以通过 `@` 提及文件来将它们作为引用包含进来。引用允许 Claude 参考有关当前计划的深度信息。 这可以是规格说明文件、原型图，甚至是整个代码库。通常你应优先选择代码形式提供引用，因为它能用 Claude 非常熟悉的语言提供清晰、高保真的指令。例如，设计稿的 HTML 原型通常比设计描述或截图效果更好。 ## 尝试简化 在所有系统提示、技能模块和 CLAUDE.md 文件中，你可能也需要像我们一样进行简化。我们推出了一条新命令 `claude doctor`，它可以自动帮你完成简化。关于如何为更高级模型进行提示的更多细节，请查阅我们的 Fable 现场指南（https://claude.com/blog/a-field-guide-to-claude-fable-finding-your-unknowns）。 *本文由 Anthropic 技术团队成员 Thariq Shihipar 撰写。*