以前必须写死的规则，现在可以删掉

拿一条真规则看。Claude Code 早期的系统提示词里，关于注释是这么写的：

In code: default to writing no comments. Never write multi-paragraph docstrings or multi-line comment blocks — one short line max. Don't create planning, decision, or analysis documents unless the user asks for them — work from conversation context, not intermediate files.

这条规则当年是必要的。Claude Code 刚推出时，最要紧的是别让模型闯祸，比如别删文件。所以他们会给出特别强硬的指引，哪怕这条指引并不总是对的。注释这条就属于并不总是对的那类：有的用户自己有文档习惯，有的特别复杂的代码就该配多行注释块。可当时的模型不这么拦着，写出来的注释十有八九是错的。明知这条规则会误伤一部分人，也只能这么定。

新一代模型的判断力够了，就不用再这么误伤。同一件事，现在的系统提示词里只剩一句：

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

当年那些护栏是为了避开最坏情况才立的。最坏情况不再发生，护栏就该拆掉，让模型靠周围的语境和自己的判断来定。

三句互相冲突的话，同时出现在一次请求里

删规则还有个更实际的理由。他们读自己团队内部使用 Claude Code 的对话记录，发现一次请求里经常同时冒出好几句打架的话。

三句话拼在同一份上下文里送进去。这三句是 Anthropic 画的示意例，不是真实原话。图片来源：Thariq / X

Claude 一般能猜出你到底想要什么。但它得先把这几句互相矛盾的话调和掉，才能决定动手做什么。你以为往技能里多加一条约束是免费的，其实每加一条，都可能在别处跟另一条撞上，而调和是要花心思的。

这也解释了为什么删掉八成还不掉分：删掉的不只是占位置的字，还有它们制造的矛盾。

六条过时的老规矩，和替换它们的新做法

Thariq 把这些年口口相传、如今已经不成立的做法列了六条，一条一条给了替换：

第一条前面讲完了，还有三条各占一节，先把两条轻的说完。

重复强调 → 简单的工具描述

更早的 Claude 模型有时候需要把同一件事说好几遍才记得住，而且它们更容易听进上下文结尾的话、不容易听进开头的。所以以前系统提示词里会提一遍工具怎么用，工具描述里再写一遍。现在这些重复的说明删掉了，工具怎么用只写在工具描述里。

记忆写进 CLAUDE.md → 自动记忆

以前的用法是按 # 快捷键，把要记住的东西自动写进 CLAUDE.md。现在 Claude 自己会保存跟这次工作、跟你这个人相关的记忆，不用你手动往文件里塞。

别给示例了，把工具本身设计清楚

过去教模型用工具，第一条铁律是多给示例。现在他们发现，对最新这代模型，示例反而把它框死在一小片探索空间里：你举了几种用法，它就在这几种附近打转。

同一个 TodoWrite 工具的描述，左边改造前、右边改造后。右边那句话末尾是省略号，说明现在的描述还有后文，图上只展示了开头。图片来源：Thariq / X

替代示例的是接口设计：把工具、脚本、文件本身设计清楚。关键在参数，参数能取哪些值，本身就该把用法说明白。

TodoWrite 就是例子。它的 status 字段只有三个取值：pending、in_progress、completed。这个枚举摆在那儿，本身就在告诉模型该怎么用它：任务有这三种状态，不多不少。要求也不用举例说明，一句「同时只保持一个任务处于 in_progress」就说完了。

这个立场跟一年前不一样了。Anthropic 2025 年那篇讲上下文工程的文章里，对示例的说法是「提供示例，也就是少样本提示，是我们持续强烈推荐的一项公认最佳实践」，当时反对的只是往提示词里堆一长串边缘案例。隔了一代模型，示例本身从推荐项变成了约束项。

不必全部写在开头，用到才加载

Claude Code 早期专做编程，所以系统提示词里塞进了怎么做代码审查、怎么做验证的详细说明。这些内容大部分时候用不上，但真需要的时候是关键信息，于是就一直占着位置。

现在的解法是让它按需出现：代码审查和验证被搬进了各自独立的技能，Claude 需要时才去调。这套做法叫渐进披露（progressive disclosure）：需要哪一部分，才把哪一部分加载进来。

同一套办法也用在工具上。Claude Code 现在挂的工具比以前多得多，其中一些是延迟加载的：平时上下文里只有一个名字，模型得先用 ToolSearch 把完整定义搜出来才能调用。不搜的时候，这个工具占的就是一行名字的位置，那份动辄几千字的完整说明不进来，正因为不进来，才敢挂更多。

你自己的 CLAUDE.md 和技能文件也该这么组织。Thariq 点了一个常见误区：很多人把所有可能用到的做法都往一个文件里堆，理由是不写进去 Claude 就找不到。正确做法是拆成一棵能按需加载的文件树。

规格不一定是文档，也可以是一份代码或一套测试

先说清楚这里的「规格」指什么：你写给 Claude 的「我要的东西长什么样」。过去大家习惯把它写成一份 markdown 文档，在计划模式里，Claude Code 一直很依赖这种文件；把规格存进代码库供长期项目参考，也是同类做法。这些仍然管用，但可以更进一步：Claude 现在能处理复杂得多的参照物。

为什么代码类的参照物更管用，他在《Fable 田野指南》（同一个人写的另一篇，Anthropic 给 Fable 5 出的官方使用手册）里说得更直白：有些东西你描述不出来，可能是没有那套词汇，也可能是描述清楚要花太久；这时候最好的办法是给参照物，而所有参照物里最好的是源代码。回到这篇，他举的例子是：同一个设计，给一份 HTML 稿子通常比给一段文字描述或一张截图管用得多。

你可以用 @ 把文件带进来当参照物……一般来说优先选代码里的东西，因为它给 Claude 的是清晰、高保真的指令，而且是它非常熟悉的语言。 — Thariq Shihipar，《The new rules of context engineering for Claude 5 generation models》（省略号处为原文另一段落）

上下文由六层拼成，每层该放什么

把前面几条合起来，就是一份分层的摆放建议。先看这一次请求里，Claude 实际读到的东西是怎么拼起来的：

你敲的那句话在最上面一条，下面依次是参照物（@ 进来的文件、规格、设计稿、代码库、artifacts）、系统提示词、CLAUDE.md、技能、记忆。图片来源：Thariq / X

这六层里，最上面那句话是你当场敲的，最下面的记忆由 Claude 自己存，都不用你摆。真正要你动手安排的是中间四层：

想动手精简，先跑一个体检命令

Anthropic 把这套做法做进了一个命令，用来给你的技能和 CLAUDE.md 瘦身。原文对用法的说法是「我们把这些最佳实践放进了 claude doctor，在 Claude Code 里用 /doctor 命令」。

这两个入口不完全一样。本站在 Claude Code 2.1.220 上实测：命令行的 claude doctor，帮助文本写的是「检查你的 Claude Code 安装是否健康，读取当前目录的设置文件、不弹信任提示」，末尾还补了一句：要做能顺手修问题的完整体检，请在会话里运行 /doctor。所以想让它帮你精简技能和 CLAUDE.md，进会话跑斜杠命令那个。

这六条替换成立有个前提：「新一代模型的判断力更好了」，原文举的是 Opus 5 和 Fable 5。如果你的工作流跑在更老的模型上，或者跑在别家模型上，那些护栏当初挡的问题可能还在，照着删之前先小范围试。这一层原文没有展开。

Claude Code 刚出的时候，头等大事是别让它闯祸，所以规则写得特别硬，哪怕明知道有一部分人会被误伤。注释那条就是：有人自己有写文档的习惯，复杂代码本来也该配多行注释，可当年的模型不拦着就会写出一堆错注释，只能一刀切。

新的那句把参照物交给了周围的代码：注释密度、命名、写法跟着邻居走。参照物随项目变，这条规则就不用为每个项目重写一遍。

删规则还有个更实际的理由。他们翻自己团队用 Claude Code 的对话记录，发现一次请求里经常同时冒出几句打架的话。

Thariq 把这些年口口相传、现在已经不成立的做法列了六条，一条一条给了替换。

把前面几条合起来，就是一份摆放建议。六层里，最上面那句话你当场敲，最下面的记忆 Claude 自己存，真正要你安排的在中间。

想动手就先跑一次体检：在 Claude Code 会话里输入 /doctor，它会拿这套标准给你的技能和 CLAUDE.md 提精简建议。本站在 2.1.220 版上试过，命令行里的 claude doctor 只查安装是否正常，完整体检要在会话里跑。