本文根据 Anthropic 技术人员 Thariq Shihipar 的文章编译整理，非逐字翻译；文中观点均属于原作者。

原文：The new rules of context engineering for Claude 5 generation models

Anthropic 在适配 Claude Opus 5 和 Claude Fable 5 等新一代模型时，从 Claude Code 的系统提示词中删除了超过 80% 的内容，而代码评测没有出现可测量的退步。

这项调整反映了一个更普遍的变化：随着模型能力增强，过去为了防止最坏情况而不断累积的规则、示例和重复说明，可能开始限制模型的判断。上下文工程的重点不再是把所有要求一次性写满，而是让正确的信息在正确的时间，以更清晰的结构出现。

提示词只是上下文的一部分

用户发送的提示词并不是 Claude 获取的全部信息。系统提示词、CLAUDE.md、Skills、记忆以及工具定义都会共同组成模型实际处理的上下文。

提示词通常针对当前任务，可以非常具体；上下文则会跨越许多不同请求，无法预先知道用户下一步要做什么。因此，上下文工程需要解决的不是“怎样写出最长、最完整的总提示词”，而是怎样提供足够通用、彼此一致且能够按需加载的指导。

随着 Claude 能力提升，一些曾经必要的约束逐渐变成负担。系统提示词、项目说明和 Skills 可能同时对同一件事给出不同要求，模型虽然通常能够理解用户意图，却必须先消解这些冲突，增加了不必要的判断成本。

从增加规则转向释放判断力

早期模型更容易出现危险或低质量行为，因此开发者往往用强硬、绝对的规则提前封住各种可能性。例如统一限制注释长度、禁止生成某类文档，能够减少一部分常见错误，但也会在真正需要详细说明的复杂代码中产生错误约束。

新一代模型更适合遵循周围代码和当前任务的实际语境。相比规定所有场景都必须怎样做，更有效的要求是让模型匹配现有项目的命名、惯例和注释密度，并结合用户当前目标作出判断。

这并不意味着删除所有规则。涉及安全、不可逆操作或团队明确边界的约束仍然重要。需要减少的是那些为了旧模型的弱点而添加、如今又与真实任务频繁冲突的绝对化说明。

具体的上下文工程方向

用接口表达能力，而不是堆叠调用示例

过去，为工具提供多个调用示例可以帮助模型理解使用方式。但对于能力更强的模型，示例也可能把探索范围限制在少数已展示的路径里。

更好的做法是设计清晰、表达力足够的工具接口。参数名称、数据类型、枚举值和状态约束本身就能传递使用意图。例如，一个任务工具明确区分 pending、in_progress 和 completed，并说明同时只能有一个任务处于进行中，就已经定义了核心行为，不必再重复大量固定示例。

按需加载，而不是把所有内容放在最前面

代码审查、验证流程或特定领域规则非常重要，但并不是每次请求都需要。如果这些内容始终占据系统上下文，就会稀释当前任务真正相关的信息。

渐进式披露让模型在需要时再加载详细说明。Claude Code 可以把验证和代码审查拆成独立 Skills，也可以先只暴露工具名称与用途，等模型决定使用时再取得完整定义。

同样的原则适用于 CLAUDE.md 和项目文档：入口文件负责说明仓库用途、关键边界和信息位置，具体流程则拆到能够按需读取的文件中。上下文由此形成一棵可导航的树，而不是不断膨胀的单一文档。

消除重复，把说明交给真正的所有者

早期模型有时需要在上下文不同位置反复看到同一条要求，因此系统提示词和工具描述可能保留重复内容。

新模型更能稳定理解局部说明。与工具有关的规则应尽量放进工具定义，与仓库有关的特殊约束应留在项目上下文中。减少重复不仅节省 token，也降低两份说明逐渐不一致的风险。

用自动记忆承接长期信息

过去，Claude Code 鼓励用户把长期信息不断写入 CLAUDE.md。现在，自动记忆可以保存与用户和工作相关的内容，项目文件不必同时承担所有会话记忆。

CLAUDE.md 因而可以重新聚焦于仓库本身：它应说明代码中不容易直接看出的特殊约定，而不是记录所有历史事实或显而易见的目录信息。

从简单规格转向丰富参考资料

模型对复杂参考资料的处理能力也在提升。规范不必只存在于简短的 Markdown 计划里，还可以是测试套件、另一个代码库中的参考实现、HTML 原型或其他高保真材料。

代码通常是很有价值的参考，因为它能精确表达接口、约束和预期行为。评价标准同样可以作为参考资料，用来帮助模型理解团队对 API、设计或代码质量的具体偏好，并支持后续验证。

让 Skills 保持轻量和有选择性

Skills 更适合充当按需查找信息的入口，而不是新的巨型系统提示词。除非涉及非常重要的边界，否则不应把每个步骤都限制死。

较长的 Skill 可以继续拆分，把详细资料放到多个文件中，再由入口说明何时读取。真正值得保留的内容，是个人、团队或产品特有的知识、判断与最佳实践，而不是模型从代码和通用知识中已经能够得出的结论。

不同上下文组件应该负责什么

系统提示词

系统提示词与产品形态紧密相关，用于说明模型所在的环境、可用能力和总体职责。Claude Code 用户通常不会直接修改它；如果在开发自己的 Agent 框架，这一层才需要投入更多设计工作。

CLAUDE.md

CLAUDE.md 应保持轻量，简要说明仓库用途，把主要篇幅留给代码中难以发现的特殊约束和常见陷阱。显而易见的目录结构或模型可以自行读取的事实，没有必要重复写入。

如果一个验证流程包含很多细节，可以把它做成独立 Skill，并在 CLAUDE.md 中提供入口，而不是展开全部步骤。

Skills

Skills 用于在特定任务出现时提供额外指导。它们应明确触发条件，保留有价值的领域判断，并借助渐进式披露控制上下文体积。

References

参考资料承担深度信息，可以包含规格文件、设计稿、原型、测试或完整代码库。相比对实现进行模糊描述，直接提供结构清晰的代码或 HTML 原型通常能传递更准确的要求。

从简化现有上下文开始

迁移到能力更强的模型，并不意味着必须立即建立一套更复杂的上下文系统。更实际的起点是检查现有系统提示词、Skills 和 CLAUDE.md：

  1. 删除已经过时、相互冲突或仅为旧模型弱点服务的规则。
  2. 把工具规则放回工具描述，把仓库规则放回项目上下文。
  3. 将低频但重要的详细流程改为按需加载。
  4. 用清晰接口和高质量参考资料替代重复示例。
  5. 保留安全边界、不可逆操作约束和真正属于团队的经验。

Claude Code 新增的 /doctor 可以帮助检查 Skills 和 CLAUDE.md 的体积与组织方式。最终目标不是让上下文越短越好，而是减少无效约束，让模型在获得必要信息的同时，仍有空间根据当前任务作出判断。