Claude 5 模型的 context engineering 新规则
Thariq (@trq212)
2026-07-25
D
原文
---
title: "Claude 5 模型的 context engineering 新规则"
author: "Thariq (@trq212)"
source_url: "https://x.com/trq212/status/2080710971228918066"
published_at: "2026-07-24T17:45:27.000Z"
fetched_at: "2026-07-25T00:10:03Z"
updated_at: "2026-07-25T00:13:04Z"
language: "zh"
review_status: "draft"
---
# Claude 5 模型的 context engineering 新规则
我之前写过一篇文章，介绍怎样才能更好地[为最新一代 Claude 5 模型写 prompt](https://x.com/trq212/status/2073100352921215386)，以及如何通过反复与模型协作，逐渐弄清自己想构建什么。
但当你向 Claude 发送消息时，prompt 只是它所获得 context 的一小部分。更多 context 来自系统 prompt、Skills、CLAUDE.md 文件、记忆以及其他来源。我们把这称为 [context engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)。无论是使用 Claude Code，还是构建自己的 agent，context engineering 都会显著影响最终结果。
单次 prompt 可以写得很具体，context 却要供许多请求共用，因此不能同样具体。那么，尤其是在不知道用户会输入什么 prompt 的情况下，该怎样为 Claude 编写这些通用提示和指导？
随着 Claude 自身能力不断进步，这件事可能比想象中更难。最近，我们发现，为最新一代 Claude 模型写 prompt 的方式发生了很大变化。针对 Claude Opus 5、Claude Fable 5 等模型，我们删掉了 Claude Code 系统 prompt 中超过 80% 的内容，而编程评估并未显示模型表现有所下降。
下面是我们在为这类新模型写 prompt 时总结出的经验，以及如何据此更新你的 context engineering。我们已经把这些最佳实践放进了 \`claude doctor\`；在 Claude Code 中使用 /doctor 命令，就能把 Skills 和 CLAUDE.md 文件调整到合适的规模。
## 给 Claude 松绑
总体来看，我们发现，无论是系统 prompt，还是 CLAUDE.md 文件和 Skills，都给 Claude Code 加了太多限制。
例如，我们查看内部使用 Claude Code 的对话记录时，会发现同一个请求里同时出现几条互相冲突的信息，比如“在适当的地方补充文档”和“不要添加注释”。这是因为系统 prompt、Skills 和用户请求彼此冲突。
一般来说，Claude 能读懂用户的意图并把事情做对。但面对这些重叠甚至冲突的信息，它必须更仔细地权衡，才能决定该怎么做。
这些限制过去确实有必要，可以避免最坏情况。不过后来我们发现，其中很多都可以删掉，让模型结合周围的 context 自行判断。
此外，Claude Code 如今拥有的工具也多得多。过去，Claude 主要依赖 CLAUDE.md 获取记忆、信息和指导。现在有了记忆、产物和 Skills，Claude 可以用新的方式加载 context，并在不同会话之间共享 context。
## 过去与现在
过去的一些 context engineering 最佳实践，如今已经成了误区。比如：
**过去：给 Claude 规则**
**现在：让 Claude 自己判断**
Claude Code 刚推出时，我们必须确保 Claude 不会做出删除文件之类的最坏行为。因此，我们会给出非常强硬、但并非总是适用的指导。例如，系统 prompt 过去会这样写：
*写代码时，默认不添加注释。绝不要写多段 docstring 或多行注释块——最多一行简短注释。除非用户要求，否则不要创建规划、决策或分析文档；应根据对话 context 工作，而不是依赖中间文件。*
但面对某些 prompt，这种指导并不合适。以文档为例，用户可能有自己的偏好；非常复杂的代码中，某些部分也确实需要多行注释。
即便如此，旧模型如果没有这些护栏，写出的注释往往会出错，所以我们不得不接受这种取舍。但新模型的判断力更强，即使没有明确规则，也能妥善作出这些决定。
新的系统 prompt 里，我们只说：*代码风格要与周围代码一致，包括注释密度、命名方式和惯用写法。*
**过去：给 Claude 示例**
**现在：把接口设计好**
以前，使用工具的第一原则，是用示例告诉 Claude 应该怎样操作。但在最新模型上，我们发现，示例反而会把模型限制在特定的探索范围内。
与其提供示例，不如多花些心思设计工具、脚本和文件：Claude 能使用哪些参数？怎样让这些参数表达更多意图？
以 Todo 工具为例，只要把状态列为 pending、in_progress 和 completed 这几个枚举值，就已经在暗示 Claude 应该如何使用它。再说明只能有一个事项处于 in_progress 状态，就能界定我们想要的行为。
**过去：把所有内容都放在最前面**
**现在：渐进式披露**
Claude Code 主要用于编程，因此我们的系统 prompt 过去包含如何做代码审查和验证的详细说明。这些内容并非总能用到，但需要时又至关重要。
此后，Claude Code 越来越擅长渐进式披露（progressive disclosure），也就是在合适的时机加载合适的 context。例如，我们把验证和代码审查分别移进独立的 Skills，让 Claude Code 按需调用。
渐进式披露不只适用于 Skills，也适用于工具。我们有些工具采用“延迟加载”：agent 必须先用 ToolSearch 找到完整定义，才能使用它们。这样一来，我们就能提供更多工具（比如 Task 工具），同时又不让它们在用到之前占用 context。
同样的做法也适用于你自己的 CLAUDE.md 和 Skill.md 文件。一种常见误区是，应该把所有将来*可能*遇到的实践都集中存放在这些文件里，否则 Claude 就找不到。更好的做法是，[建立一棵能在合适时机按需加载的文件树](https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code)。
**过去：重复说明**
**现在：简洁的工具描述**
早期 Claude 模型有时需要反复提醒，而且相比 context 窗口开头的指令，它们可能更容易听从末尾的指令。因此，我们有时不仅会在工具描述里写使用说明，还会在主系统 prompt 中再次提到这些工具。
后来我们发现，这些重复示例可以删掉。如何使用工具，写在工具描述里即可，不必再放进系统 prompt。
**过去：把记忆放进 CLAUDE.md 文件**
**现在：自动记忆**
过去，我们鼓励用户把内容存进 Claude 的记忆里：按下 # 快捷键，就能自动写入用户的 [CLAUDE.md](http://claude.md/)。现在，Claude 会自动保存与当前工作和用户本人相关的记忆。
**过去：简单的规格说明**
**现在：丰富的参考资料**
在 plan mode 中，Claude Code 一直非常依赖记录计划的 Markdown 文件。把计划存成文件，能让 Claude 在需要时回来查阅。另一个类似的最佳实践，是把规格说明存进代码库，供 Claude 在长期项目中持续参考。
但我们发现，Claude 已经能处理越来越复杂的参考资料。除了简单的 Markdown 文件，它还可以读取新 artifacts 功能生成的 HTML 产物。
你也可以把代码本身作为参考资料交给 Claude。一套详细的测试可能就是规格说明；另一个代码库中的函数，也可能成为 Claude 移植功能时的参考。
评分标准也是一种参考资料。有了评分标准，Claude 就能借助[动态工作流](https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code)启动验证 agent，边尝试边检验结果是否符合你在某个领域的品味，比如怎样才算好的 API 设计。
## 把这些原则用到你的 context 中
把这些经验合在一起，实际组装 context 时应该怎么做？
**系统 prompt**
系统 prompt 与具体产品紧密相关。它会告诉 Claude 自己正在什么产品中运行、要做什么。使用 Claude Code 时，你大概永远不会修改它；但如果你在构建自己的 agent harness，这部分就值得投入大量时间。
**CLAUDE.md**
让 CLAUDE.md 保持轻量，简要说明代码库的用途，把大部分篇幅留给代码库里那些容易踩的坑。例如，你的代码组织方式可能要求所有类型都放在一个大文件中，其他地方一律不放。那些 Claude 只要查看文件系统或代码库就能知道的“显而易见之事”，不要再写进去。
更多细节用渐进式披露来提供。例如，如果你对如何验证工作结果有几条特殊要求，可以创建一个验证 Skill，再从 CLAUDE.md 中引用它。
**Skills**
把 Skills 看成轻量指南，帮助 Claude 在需要时找到信息。除非涉及非常重要的领域，否则不要设置过多限制。
Skills 很长时，应尽量使用渐进式披露：把内容拆开，分别放进多个文件。
Skills 最适合承载你个人、团队或产品特有的观点、知识和最佳实践。
**参考资料**
你可以用 @ 提及文件，把它们加入参考资料。参考资料让 Claude 能查阅当前计划所需的详细信息。
它可以是规格文件、设计稿，甚至整个代码库。一般来说，应优先提供代码形式的资料，因为代码能用 Claude 非常熟悉的语言，给出清晰而高保真的指导。例如，一份 HTML 设计原型通常会比设计描述或截图带来更好的结果。
## 试着做减法
你的系统 prompt、Skills 和 CLAUDE.md 文件可能也需要像我们一样做减法。我们推出了一个名为 \`claude doctor,\` 的新命令，也能自动帮助你完成这件事。如果想进一步了解如何专门为更先进的模型写 prompt，可以阅读我们的 [Fable 实战指南](https://claude.com/blog/a-field-guide-to-claude-fable-finding-your-unknowns)。