昨天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读文件能不能自己推断出来？能，就别写。
这是判断框架还是别做什么的禁令？能写成「你相信什么」，就尽量别写成「你不许什么」。
A社究竟干了些啥
三个事实：
第一，删减幅度是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,504 | 9,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替代老板、替代同事，你终于到了可以去解雇老板的时刻。现在得补半句：你解雇了老板，自己就坐上了那个位置。那你是个什么样的老板？
本文由作者【花叔】，微信公众号：【花叔】，原创或授权 发布于平台，未经许可，禁止转载。