Claude Code把自己的提示词删掉80%，我照着砍了自己的60%

昨天Anthropic发了篇文章说，他们把Claude Code系统提示词删掉了80%以上，编码评测表现没有明显下降。然后写了篇文章，把这次删减背后的判断做了波阐述，标题叫《The new rules of context engineering for Claude 5 generation models》，作者是Claude Code团队的Thariq。

https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models
我看到的时候有点想笑。其实系统提示词，或者说提示词到底该长还是短，该写到什么程度，一直在被反复讨论，模型能力升级了这么多次，但这部分讨论还是在继续。

2024年2月我在即刻发过一条，说很多人感觉GPT-4变笨变懒，各种分析都有，我当时觉得最靠谱的原因是系统提示词变得太长了，超过1700token，每次对话你的prompt都要被这么多无关内容污染。我还照这个判断做了个「更勤奋更聪明的GPT-4」，逻辑简单到不好意思说（其实就是把插件全禁了加几句简单提示词，它后来在Education分类做到全球第11）。

两年零五个月之后，Anthropic把这件事做了一遍，规模大得多，当然因为面临的任务环境和模型能力不同，理由也讲得比我当年清楚得多。我看了觉得也很有启发。

这篇主要做一件事：把那篇文章讲透。它直接影响你手上的CLAUDE.md、你写的每个skill、你给agent定义的每个工具。最后我会补上自己照着重构的结果和完整清单。

你也考虑不读我这篇文章，直接复制全文给你的Claude Code、Codex、Kimi code等任何你在用的agent。虽然A社说这套删减逻辑主要在他们最新的Opus 5、Fable 5模型上有效，但是相信我...GPT-5.6和Kimi K3也都完全没问题的。

其实简单来说呢，判断某些提示词写不写，怎么写的，最最最核心的就是这两个标准：

这条Claude读文件能不能自己推断出来？能，就别写。 这是判断框架还是别做什么的禁令？能写成「你相信什么」，就尽量别写成「你不许什么」。

三个事实：

第一，删减幅度是80%以上，适用于Claude Opus 5和Claude Fable 5这一代。评测口径是编码评测没有可测量的下降。

第二，也是最容易被忽略的：他们现在每个模型配一套不同的系统提示词。在那场对谈里Cat说得很明白，只有最前沿的那几个模型享受这次80%的削减，旧模型用的还是完整版。

第三，Thariq把这个演化描述成短—长—短。早期模型需要短prompt加大量示例和限制，模型理解力上来之后prompt越写越长，现在又短回去了。我们正好站在第二个拐点上。

六条变化的策略

文章的主体是一张对照表，六条过去这么做、现在该这么做。

过去（原文划掉的）

现在

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一、给规则 → 让它判断

他们删掉的那一句是这样的：

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

默认不写注释，永远不写多段落docstring或多行注释块，最多一行短的。同一批删掉的还有一条，大意是除非用户要求否则不创建规划、决策或分析文档，从对话上下文工作，不要产出中间文件。

换上去的是这句：

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

写代码要匹配周围代码的风格，注释密度、命名、习语都跟着来。

前一句是规则清单，规定注释写几行；后一句是判断依据，告诉模型拿什么当参照。规则消失了，约束其实更准了。你想，在一个注释本来就很密的老代码库里，默认不写注释这条硬规则本身就是错的，而模型会认真执行一条错的指令。

文章给的理由是：新一代模型有更好的判断力，注释密度这种细粒度决定，它不需要显式规则也能处理好。

二、给示例 → 设计接口

这条算是挺反常识。过去几年所有prompt教程的第一条建议都是给它几个例子。

Thariq在对谈里的说法是，早期Opus 4那一代确实需要大量示例，但移除示例「极其有帮助」，因为模型自己想出来的东西比他们给的示例更有创造力。

机制不难理解：模型看到示例会认为你要的就是这一类，探索空间被锁死了。你给三个例子，等于画了个圈说别出去。

那不给示例怎么让它知道该怎么用？文章的答案是把接口设计得会说话。

他们举的例子是Todo工具的status参数，枚举值是pending、in_progress、completed。这三个值本身就在暗示这个工具该怎么用，不需要再配一段示例说明。参数命名和枚举定义到位，示例就是多余的。

这特么差不多是在说，之前prompt engineering上最最常用的技巧之一：few-shot（少示例提示）就特么尽量别用了。

三、全部前置 → 渐进披露

过去是把所有可能用到的信息一次性塞进上下文，现在是用到才加载。

具体来说的话，会涉及到三个地方的变化。长的skill拆成多个文件，主文件只放路由和判断，细节放references，需要时才读。工具本身也可以延迟加载，agent一开始只知道工具名字，必须先通过ToolSearch搜到完整定义才能调用，这样几百个工具的定义不会全部压在上下文里。CLAUDE.md同理，文章建议如果你有好几套验证说明，把它们做成独立的skill从CLAUDE.md引用过去，而不是全塞进主文件。

这一条是整件事的枢纽，也是最容易被抄错的地方：删掉不等于扔掉，是把它挪到用到的时候才读的位置。后面我讲自己怎么删的时候会回到这里。

四、反复强调 → 单一位置

过去有种做法是重要的话说三遍，系统提示词写一次、skill里再写一次、CLAUDE.md里又写一次，图个保险。文章说旧模型有时确实需要重复指导，或者更关注上下文窗口末尾的指令，但新模型已经不需要了。

不但不需要，而且有害。文章举了个很具体的翻车场景：同一个请求里，「酌情保留文档」和「不要添加注释」这两条同时出现，分别来自系统提示词、skill和用户请求。模型收到的是一组互相打架的指令，它只能猜你到底想要哪个。

配套建议是把工具的使用指导放进工具描述里，不要放在系统提示词里。过去他们两个地方都写，现在只在一处写。

五、CLAUDE.md存记忆 → 自动记忆

过去的做法是鼓励用户用#快捷键把要记的东西存进CLAUDE.md，现在Claude会自动保存跟工作和用户相关的记忆，不需要你手工往配置文件里塞。

区别不只是省事。CLAUDE.md是每次会话都全量加载的，你往里面塞的每一条记忆，之后每一次对话都要为它付费；自动记忆是索引加按需读取，用不上的那些不占位置。这本质上还是渐进披露。

六、简单规格 → 富引用

这条讲的是你怎么告诉AI我要的是什么样。

过去是写一个markdown的计划文件，用文字描述需求。现在文章建议直接引用真东西：HTML工件、代码里的具体函数、测试套件。

用测试套件当规格比用文字描述准得多，因为它不会有歧义，也不需要模型去猜。想让它照着某个页面的样子做，给它那个HTML，比写三段话形容那个页面有效。

四类文件分别该怎么写

文章最后按类型给了建议，我觉得这部分比对照表更实用。
系统提示词。它现在只负责一件事：告诉Claude它在哪个产品里运行、在干什么。文章的原话是系统提示词高度绑定产品上下文。如果你在做自己的agent，重点该花在这里。

CLAUDE.md。保持轻量，简要说明这个仓库是干什么的。重点写代码库的特殊情况，文章给的例子特别好懂：类型统一存在一个文件里，别处没有。这种事你不说，Claude得自己摸半天。

然后是关键的一条：避免陈述Claude通过查看文件系统就能理解的内容。目录结构、有哪些文件、用了什么框架，它自己看得到。

从根本来说就是：对每行CLAUDE.md问一句Claude读代码能不能自己推断出来，能，就删。

Skills。文章说要把它当成轻量的指南，帮Claude按需找到信息，而不是当规章制度。避免过度约束，除非涉及关键领域。长skill用渐进披露拆成多文件。

最该编码进skill的是什么？原文的说法是团队或产品特定的观点、知识、最佳实践，也就是模型不可能自己知道的那部分。你们团队为什么放弃了某个方案、哪个接口有历史包袱、什么情况下必须找谁确认，这些才值得写进去。

References。用基于代码的规格和测试套件，HTML文件比文字描述管用。

两条方法论

文章和对谈里还有两条不在对照表上、但含金量很高的东西。

第一条，软化绝对表述。他们把「必须验证所有前端更改」改成了「较大的UX变更时运行本地应用」。

Thariq的解释是要让prompt做到100%准确。always verify听起来很负责，但它并不总是对的，存在大量不需要验证的边缘情况。而模型会认真执行一条并不总是对的指令，于是你得到一堆无谓的动作。

第二条是Cat给的启发式，我觉得是全文最实用的一句：给模型写prompt的时候，想一想一个善意的人会怎么误解这句话。

不是恶意曲解，是善意误读。你写保持文档简洁，一个想把事做好的人可能理解成能不写就不写，也可能理解成写但别啰嗦。模型也一样。这条拿来审自己的CLAUDE.md，一审一个准。

顺带提一句工具设计。他们的原则是每个工具功能互不重叠，让Claude一眼能分清什么时候调哪个。据此砍掉了grep和glob两个专用工具改用原生bash，因为功能重复了；但保留了专门的文件编辑工具，理由是UI展示需要。Thariq说工具设计这件事是生物学不是物理学，很难用eval完全量化。

至于「不要做X」这类指令，Thariq说它可能会让Claude非常困惑，尤其当它和后面的用户指令冲突的时候，策略换成更多上下文、更少指令。

现在，立刻，马上去做这三件事

文章讲到这儿就结束了。把它的方法落到手上，是下面这三步，半小时之内做得完：

一、测量一遍你的启动token成本。把每次会话自动加载的文件（全局CLAUDE.md、项目CLAUDE.md、记忆文件）字符数加起来除以2.2，基本就是你还没开口就废掉的token数。

二、用两个标准过一遍。对每一行问：Claude读文件能不能推断出来？这是判断框架还是禁令？前者删，后者改写。

三、把禁用词清单和坏例子挪出主上下文。挪到只有审校环节才读的文件里。这一步收益最大、风险最低，因为它不删任何规则，只换位置。

我照着做了一遍

看完之后我花了半天，让我自己的claude code结合我的系统环境和A社文章里的判断，帮我做了梳理和精简。

其实查一遍我才发现自己特么又不断积存了那么多存货，最后精简的情况大概是：

before

after

全局CLAUDE.md

1,289

673

-48%

写作总纲CLAUDE.md

4,160

1,355

-67%

公众号写作CLAUDE.md

1,624

1,625

一个字没改

自动记忆索引

7,786

5,606

-28%

手工记忆两份

8,645

0

整体下线

合计23,5049,259-60%

作为参照，Anthropic精简后的整个Claude Code系统提示词大约13k。

我一开始的反应是我比官方还多，不过似乎也没必要这么比：他们那份管的是通用编码场景，我这份管的是模型根本猜不到的个人偏好和踩坑，大一点完全可能是对的。真正的问题不是它大，是里面有一多半是坏的。

坏在哪。同一份记忆文件里，第80行说某个API key没配置会上传失败，第170行说已配置且实测6张图全成，两句都在，每次一起进上下文。模型版本表停在Opus 4.6。记忆索引234行超出200行上限，每次会话都是被截断加载的。14个记忆文件根本没进索引，等于不存在，其中两条是前两天刚写的踩坑记录。还有一个被引用了6次的规则文件，它压根不存在，每次照着它走都是一次空手而归。

这些跟模型聪不聪明没关系，也跟提示词长短没关系。它们就是坏的。

最后：你已经是老板了

Anthropic这次删减，表面是工程决策，本质是一次管理动作。

管理学里有个挺老的框架叫情境领导，Hersey和Blanchard提的。它把领导风格分四档：下属能力低的时候用指导型，你得计划、示范、告知、监督、高频反馈；下属能力高的时候用授权型，你给资源、给信任、给挑战，然后走开。核心命题是没有最好的领导风格，只有匹配下属成熟度的风格。

现在再回头看每个模型配一套不同系统提示词这个设计，它就是情境领导的工程实现。前沿模型是能力高的下属给授权，旧模型是能力低的下属给指导，同一件事两套管法。

而人做不到，是因为从管理自己到管理他人这一关卡的不是技能是价值观，你得从自己把活干好变成通过别人把活干好。prompt越写越长，就是这个卡点的症状。你在替它想每一步，因为你还没把自己当成管理者。

我4月在即刻写过一句，说很多人担心老板拿AI替代自己，但少有人意识到你也可以拿AI替代老板、替代同事，你终于到了可以去解雇老板的时刻。现在得补半句：你解雇了老板，自己就坐上了那个位置。那你是个什么样的老板？