笔者在日常工作中使用 Claude Code，每当向 CLAUDE.md（按项目设置的指示文件）追加指示时，总会犹豫：这些指示到底应该写到多细？2026年7月24日，Anthropic 在官方博客发布了正面回答这一问题的文章 “The new rules of context engineering for Claude 5 generation models”。作者是该公司技术人员 Thariq Shihipar，次日（日本时间7月25日）他也在自己的 X 账号（@trq212）上发布了全文。本文对其内容加以梳理和介绍。下文所载图示均引自该帖子（@trq212）（制图：Anthropic）。

结论 — 六条最佳实践已成过时的通说

文章的核心报告是下面这句话。

We removed over 80% of Claude Code’s system prompt for models like Claude Opus 5 and Claude Fable 5 with no measurable loss on our coding evaluations.

（面向 Claude Opus 5、Claude Fable 5 等模型，我们删除了 Claude Code 系统提示词的80%以上，而在编码评测中未测得任何性能下降）

在此基础上，文章将旧世代模型中行之有效、如今已沦为通说（myth）的六条最佳实践，与新的指导原则一一对照列出。

旧规则与新规则的对照表。Give Claude Rules→Give Claude Judgement、Give Claude Examples→Design Interfaces、Put it all upfront→Use Progressive Disclosure、Repeat Yourself→Simple Tool Descriptions、Memory in Claude.MDs→Auto-memory、Simple Specs→Rich References

图1：旧世代模型的六条最佳实践（左侧，带删除线）与 Claude 5 世代的新指导原则（右侧）

旧（Then）新（Now）
给出规则交给判断
给出示例设计接口
全部前置写明使用渐进式披露（progressive disclosure）
反复叮嘱工具说明简洁并集中于一处
在 CLAUDE.md 中记录记忆交给自动记忆（auto-memory）
简单的规格文档丰富的参照物（rich references）

下面从其背后的问题意识依次说起。

前提 — 提示词与上下文并非一回事

文章首先区分了用户输入的「提示词（prompt）」与模型实际接收的「上下文（context）」。向 Claude 发送消息时，提示词只是整个上下文中很小的一部分，其大部分由系统提示词、技能（skills）、CLAUDE.md、记忆等来源组装而成。设计这一组装过程，就是所谓的上下文工程。

它与提示词的本质区别在于通用性。提示词可以针对眼前的任务专门撰写，而上下文要跨越大量请求复用，必须在不知道用户会提出什么请求的前提下书写。「通用性指示应当如何书写」这一问题的最优解，随着模型世代更替发生了巨大变化——这正是文章的主题。

解除束缚（Unhobbling） — 过度约束滋生矛盾

Anthropic 回顾自家内部使用 Claude Code 的记录时发现，系统提示词、技能与用户请求相互冲突，同一请求中并存着相互矛盾的指示。文章举的例子是「视情况保留文档」与「不要添加注释（DO NOT add comments）」同时存在。

组装后的上下文示意图。系统提示词中有「leave documentation as appropriate」，技能中有「do not add comments」，用户请求中有「just make it work like the old one」——可能相互冲突的指示并存，Claude 必须通读全部内容并加以调和

图2：同一上下文中并存可能相互冲突的指示的例子。Claude 必须读完全部内容、调和一致后再决定行动（图中文字为说明用示例）

Claude 通常能够领会用户意图并得出正确答案，但一旦存在重复、矛盾的指示，它就要花费额外的思考去调和。这类强约束在过去是必要的，用以避免误删文件等最坏情形；而在当前世代，文章表示其中许多都可以删除，交由周围的上下文和模型自身的判断来处理。

文章还指出，约束之所以能够减少，另一个背景是工具体系的变化。过去的 Claude Code 依赖 CLAUDE.md 作为记忆、信息与指导的存放处；如今已具备记忆、artifacts、技能等机制，跨会话加载与共享上下文的途径大为增加。

六个转变

1. 给出规则 → 交给判断

Claude Code 刚推出时，为了确保避开最坏情形，团队有意写下了并非总是正确的强指示。文章展示的旧系统提示词实例如下。

In code: default to writing no comments. Never write multi-paragraph docstrings or multi-line comment blocks — one short line max.

（在代码中，默认不写注释。绝不书写多段的 docstring 或多行注释块——最多一行简短注释）

出处：同一文章（引自 Claude Code 的旧系统提示词）

对于某些提示词而言，这条指示显然是错的。关于文档，用户可能有自己的偏好；极其复杂的代码的特定部分，有时确实需要多行注释块。即便如此，在旧世代模型上，没有这道护栏时写出的注释多数并不恰当，因此只能接受这种取舍——文章如此解释。在新的系统提示词中，同一处已被替换为一句话。

Write code that reads like the surrounding code: match its comment density, naming, and idiom.

（写出读起来与周围代码浑然一体的代码：在注释密度、命名和惯用写法上与之保持一致）

出处：同一文章（引自 Claude Code 的新系统提示词）

可以看到，禁止事项的罗列变成了判断标准的提示。

2. 给出示例 → 设计接口

通过示例教会工具的用法——这曾是工具使用的头号规则。但在最新世代上，团队发现给出示例反而会把模型束缚在特定的探索空间内（constrains them to a certain exploration space）。

取而代之的建议是重新审视工具、脚本、文件本身的设计：Claude 手中有哪些参数，能否让它们更具表达力？文章以任务管理工具（TodoWrite）为例说明：仅仅把 status 参数定义为 pending、in_progress、completed 的枚举类型，就足以提示其用法；而「in_progress 同时只能有一项」这一句话，则定义了所期望的行为。

TodoWrite 工具说明的修订前后对比。旧版带有使用场景清单和完整示例，约9,100字符；新版仅由「为当前会话创建并更新任务列表」这句简短说明、status 三个取值的枚举，以及「同时只能有一项 in_progress」的约束构成

图3：TodoWrite 工具说明修订前后。约9,100字符的用例集被枚举类型与简短约束的设计所取代

3. 全部前置写明 → 使用渐进式披露

旧的系统提示词中始终包含代码评审与验证的详细步骤——并非时时需要，但需要时至关重要。如今的 Claude Code 已非常擅长渐进式披露（progressive disclosure），即在恰当的时机加载恰当的上下文：验证与代码评审的步骤被移入独立的技能，由其按需选择性调用。

渐进式披露不仅限于技能，也用于工具。部分工具采用「延迟加载（deferred loading）」：代理必须先通过名为 ToolSearch 的工具检索其完整定义后方可使用。这样便能拥有大量在被用到之前不占用上下文的工具。

同样的思路也适用于你自己的 CLAUDE.md 和技能文件。「Claude 自己找不到，所以应当把可能遇到的所有实践都集中写进一个文件」是一种通说；文章建议改为构建一棵可以在恰当时机加载的文件树。

4. 反复叮嘱 → 工具说明简洁并集中于一处

旧世代模型有时需要重复指示，或者更容易听从上下文窗口末尾而非开头的指示。因此，同一工具的说明有时会同时出现在系统提示词正文和工具说明中。在当前世代，团队发现这类重复可以删除，工具的用法可以只写在工具说明一处。

5. 在 CLAUDE.md 中记录记忆 → 交给自动记忆

过去官方鼓励用户使用 # 快捷键把备忘自动写入 CLAUDE.md 作为 Claude 的记忆。如今这已被自动记忆（auto-memory）机制取代：Claude 会自动保存与当前工作和用户相关的记忆。

6. 简单的规格文档 → 丰富的参照物

在计划模式（plan mode）下，Claude Code 长期高度依赖把计划保存为 markdown 文件、需要时再行参照的方式。在较长的项目中，把规格文档放进代码库也曾是同类的定番做法。但当前世代已能处理愈发复杂的参照物，文章列举了以下选项：

  • 不再使用简单的 markdown 文件，而是参照用新的 artifacts 功能创建的 HTML
  • 以「代码」的形式给出规格——详尽的测试套件，或另一代码库中待移植的函数，同样可以充当规格
  • 把评分细则（rubric）作为参照物——例如「好的 API 设计是什么样的」这类偏好标准，可让 Claude 启动携带该细则的验证代理来加以确认

如何应用到你自己的上下文

文章后半部分将上述内容按上下文的层次重新整理为指南。

上下文层次结构图。自上而下依次为 Your prompt、References（@提及的文件、规格、原型图、代码库、artifacts）、System prompt、Claude.MDs、Skills、Memory

图4：组装而成的上下文的层次。提示词之下依次叠放着参照物、系统提示词、CLAUDE.md、技能与记忆

  • 系统提示词：与产品语境紧密绑定的层，告诉 Claude 它运行在什么产品中、在做什么。Claude Code 的用户几乎不会去改动它；但如果你在构建自己的代理框架，这里是最值得投入时间的地方
  • CLAUDE.md：保持轻量，简要说明仓库的用途即可，把大部分篇幅（token）花在代码库内部的「坑」上（例如「类型定义集中在单一文件中，别处一概不放」这类仓库特有的约定）。不要写那些看一眼文件系统或仓库就能明白的自明之事。验证步骤之类的细节应拆分为独立技能，CLAUDE.md 中只留引用
  • 技能：把它们视为让 Claude 在需要时找到信息的轻量指南。除极其重要的领域外，避免过度约束。较长的技能应拆分为多个文件、尽量采用渐进式披露；技能最能发挥作用的场合，是承载你个人、团队或产品所特有的观点、知识与最佳实践
  • 参照物（References）：通过 @ 提及文件，向 Claude 提供与当前计划相关的深入信息。可以是规格文件、原型图，甚至整个代码库；但一般而言以代码形式存在的文件更佳，因为那是用 Claude 极为熟悉的语言写成的清晰而高保真的指示。例如文章指出，设计的 HTML 原型通常比对设计的文字描述或截图产生更好的结果

文章最后建议读者像团队自身所做的那样，简化自己的系统提示词、技能与 CLAUDE.md，并介绍了自动辅助这一过程的命令 claude doctor（在 Claude Code 中为 /doctor）。

小结

  • 面向 Claude 5 世代（Opus 5、Fable 5 等），Claude Code 的系统提示词被删除了80%以上，据报告在编码评测中未测得任何性能下降
  • 其背后是过度约束的问题：当系统提示词、技能与用户请求之间的指示相互重复、矛盾时，模型要花费额外的思考去调和
  • 旧世代行之有效的六条最佳实践（罗列规则、提供用例、信息全部前置、重复指示、在 CLAUDE.md 中记录记忆、markdown 规格文档）已成过时的通说，分别被交给判断、接口设计、渐进式披露、工具说明集中一处、自动记忆、丰富的参照物所取代
  • 对用户而言，实践要点可归纳为：CLAUDE.md 保持轻量、聚焦于「坑」；细节拆分为技能以实现渐进式披露；规格以测试套件、HTML 原型等代码形式提供
  • 官方提供了辅助简化既有配置的命令 claude doctor（/doctor）

参考资料