Claude Code 删了 80% 提示词，你的规则文件也是时候瘦身了

Anthropic 昨天把 Claude Code 的系统提示词删掉了超过八成，编码评测一分没掉。

这句话我建议每个正在维护 CLAUDE.md、给 agent 写规则文件、给工具写描述的人都读两遍。因为过去两年我们所有人干的事情是反的，一直在做加法。规则越写越细，CLAUDE.md 越堆越厚，工具描述里塞满示例，生怕模型少看一行就翻车。

现在官方自己跳出来说，这些大部分可以删了。

原文在这儿，The new rules of context engineering for Claude 5 generation models，作者是 Anthropic 的 Thariq Shihipar。八成篇幅在讲一件事，他们过去写给 Claude 的那些约束，在 Opus 5 和 Fable 5 这一代模型身上已经从护栏变成了枷锁。

好家伙，等于是把自己两年攒的家底当着所有人的面清了一遍库存。

我先说清楚一个词，免得后面卡住。上下文工程（context engineering），指的不是你在对话框里敲的那句话，是模型每次干活时被塞进去的全部材料，系统提示词、你仓库里的 CLAUDE.md、各种 skill 文件、记忆、工具描述，全算。你敲的那句 prompt 只占其中很小一块。Anthropic 之前专门写过一篇讲这个。跟 prompt 不一样的地方在于，上下文是跨很多次请求通用的，你没法针对某一次任务写得特别具体，你得在不知道用户会问什么的前提下先把料备好。

难就难在这儿。

他们是在自己的日志里发现问题的

最有意思的不是结论，是他们怎么发现的。

Anthropic 的人去翻自己内部用 Claude Code 的会话记录，然后看到同一次请求里，好几条指令在互相打架。系统提示词说「该写文档的地方写文档」，另一个地方说「不要加注释」，用户的要求又是第三个方向。

三条指令，三个来源，一起塞进去了。

模型当然还是能猜出你到底想要什么，但它得先花力气把这几条冲突的话理顺，才能决定手往哪儿落。这部分算力是纯浪费的。

我看到这段的时候是有点心虚的。我自己那些规则文件也是这么长起来的，某次模型干了件蠢事，加一条禁令；下次换个花样又蠢了，再加一条。加的时候每条都有充分理由，谁也不会回头去问，防的那个坑现在还在不在。

于是规则文件就变成了法条。只增不减，没有人负责废止。

六条老经验，现在全反过来了

原文列了六组「以前这样，现在那样」的对照。我按从温和到扎心的顺序捋一遍，最后那条跟我原来的认知完全掉了个个儿。

第一条最没争议，重复说三遍这件事可以停了。以前的模型有个毛病，同一条指令你在系统提示词里说一次、在工具描述里再说一次，它才听得进去，而且放在上下文末尾比放开头更管用。现在这些重复可以删掉，关于某个工具怎么用的话，只写在那个工具的描述里就行。

第二条，别再把所有东西一股脑塞在最前面。Claude Code 的系统提示词里原来有一大段讲怎么做 code review 和验证，大多数时候用不上，但真需要的时候是关键信息。现在这些被拆成了独立的 skill，模型自己判断什么时候去加载。工具也一样，有些工具做成了延迟加载，模型得先搜一下才拿得到完整定义，这样工具数量可以往上堆而不占上下文。

顺着这条往下，有个流传很广的说法该破了，就是「CLAUDE.md 得当成百科全书，把所有可能用到的规范都写进去，不然模型找不到」。官方的建议正好相反，做成一棵可以按需加载的文件树，别做成一本大部头。

第三条关于记忆。以前鼓励用户按 # 键把东西写进 CLAUDE.md，当成模型的长期记忆。现在 Claude 会自己判断哪些是跟工作和跟你相关的，自动存下来。手动维护记忆这个动作，官方不推荐了。

第四条，spec 可以写得比 markdown 更硬。以前的最佳实践是把计划和规范存成 md 文件放仓库里让模型随时翻。现在的说法是，模型能处理复杂得多的引用形式。一份详细的测试套件就是 spec，另一个仓库里的某个函数也是 spec，你想让它照着移植就直接指过去。评分标准（rubric）也算引用的一种，你可以写清楚什么叫好的 API 设计，然后让它开一堆验证 agent 拿这个标准去核对。

原文里有句话我觉得对做前端的朋友特别有用，一份 HTML mockup 比一段设计描述、比一张截图，都更能让模型做对事情。因为代码是它最熟的语言，信息保真度最高。

第五条开始有点扎人了，别再给它硬规则，让它自己判断。

原来的系统提示词里有这么一条，我把大意翻过来，代码里默认一条注释都不要写，绝对不许写多段的 docstring 或者多行注释块，最多一行；用户没要求就不要生成计划文档、决策文档、分析文档，从对话上下文里干活，不要造中间文件。

看着挺熟悉吧。很多人的 CLAUDE.md 里都有类似的句子，我也写过。

这条规则在当年是对的，因为老模型写出来的注释十有八九是废话，宁可一条不写。但它有一半场景是错的，用户可能就是想要文档，某段特别绕的代码可能就是需要多行注释说明。当年只能捏着鼻子接受这个代价。

新版本里，这一整段被换成了一句话，写出来的代码要读起来像它周围的代码，注释密度、命名、习惯用法都跟着周围走。

一条法条，换成一句关于品味的描述。

最后一条把我看笑了

第六条，别给例子了，去设计接口。

这条真的跟我原来的认知反着来。工具用不明白怎么办，加例子啊，这几乎是行业默认动作，我自己写工具描述的时候第一反应也是塞两个 example 进去。

官方现在的发现是，给例子反而把模型框死在一个很窄的探索空间里。它看到你给的那两个用法，就默认这个工具大概就这么用，本来能想出来的第三种用法它不去想了。

替代方案是，把心思花在工具本身的设计上。参数够不够有表达力，命名清不清楚，选项能不能自己说明自己。

原文举的例子是那个 Todo 工具。状态字段做成一个枚举，只有 pending、in_progress、completed 三个值，这个设计本身就在告诉模型该怎么用它，根本不需要额外写例子。再补一句「同一时间只保持一个 in_progress」，想要的行为就定义完了。

官方那张对比图里放了个数字，旧版 TodoWrite 的工具描述大约 9100 个字符，里面塞满了什么时候该用它、该怎么用的示例。取代它的新版本，一句话说清干什么，加一个三值枚举，加一句行为约定，完事。

这一手有点子牛逼。我盯着这段看了半天。这已经不是写作了，这是 API 设计。

提示词工程没死，它换了个岗位

把六条串起来看，我的判断是这样的，「写提示词」这件事的价值正在从一头转移到另一头。

约束模型的那部分在贬值。你写的 never、always、禁止、必须，绝大多数是针对某一代模型某个具体缺陷打的补丁。模型迭代一次，补丁就过期一批。而且没人给这些补丁做 code review，它们只会越堆越多。

升值的是另外两件事。

一件是接口设计。工具的参数怎么切分，枚举值怎么命名，返回结构长什么样，出错的时候给模型的信息够不够它自己恢复。这是实打实的工程活儿，跟写文案没关系。

另一件是信息路径设计。什么信息在什么时候出现在上下文里，哪些走系统提示词，哪些做成 skill 等着被调用，哪些做成延迟加载的工具。这是在设计一个检索和调度系统，不是在写文档。

坦率讲，这两件事都比写规则难多了。写规则你今晚就能加二十条，设计接口你得先想明白这个工具到底该长什么样。

官方没说的那几个坑

夸完了说点别的。这套东西直接照搬有风险，我列几条自己比较在意的。

第一，这篇文章的前提是你在用 Opus 5 和 Fable 5 这一代模型。原文说得很清楚，删掉那些约束是因为「更新的模型判断力更好」。可你的系统里跑的未必只有它们。

我平时的工作是给模型搭那层让它真能干活的脚手架，工具链、评测、调度、上下文管理都归这块管。干这个最容易形成的一个直觉是，一套 prompt 的实际下限，取决于你系统里最弱的那个模型，不是最强的那个。为了省钱把分类、摘要、路由这些环节挂在小模型上，是所有人都在做的事。你按 Opus 5 的标准把约束删干净，小模型那条链路当天就能给你表演一个花式翻车。

删之前先问一句，这份上下文最终会喂给谁。

第二，删约束和删信息是两码事，这个特别容易搞混。

该删的是法条式的禁令，是那些「不许写多段注释」。不该删的是你们代码库里的暗礁，比如所有类型定义只放在某一个巨型文件里、某个迁移脚本谁碰谁死、那个看起来能改其实上游还有三个服务在依赖的接口。

官方的原话是，CLAUDE.md 要轻，但 token 要花在 codebase 里的 gotchas 上，别去写那些模型自己看一眼文件系统就知道的废话。

所以正确的动作不是把 CLAUDE.md 砍短，是把里面「显而易见的部分」换成「只有你们团队才知道的部分」。字数可能不怎么变，含金量差很多。

第三，渐进披露不是免费的。

拆成一棵按需加载的树，听起来很美，实际多了一跳。模型得先意识到自己需要这个信息，然后去搜，然后加载。这里每一步都有失手的可能。skill 拆得太碎，很容易出现模型压根没意识到该去看它，最后拿着不完整的信息就动手了。

这种失败还特别难查，因为它不报错，它只是做得不太对。

第四，自动记忆意味着你不再完全知道上下文里有什么。

这条对写业务的人可能无所谓，对做评测的人是真问题。同一份 prompt 两次跑出来结果不一样，你得先排除是不是记忆在中间偷偷变了。可复现性这个东西，一旦有个你看不见的状态参与进来，调试成本立刻上一个台阶。

方便和可控之间，这次官方选了方便。我理解这个选择，但用的时候心里得有数。

第五，官方给了个 /doctor 命令，在 Claude Code 里敲一下，它会帮你审自己的 skill 和 CLAUDE.md，按这套新规则给你瘦身。这是好东西，我也建议大家跑一跑。

但它优化的是 Anthropic 认为的通用最佳实践，不是你们团队那些拿血换来的约束。跑完之后建议逐条看它删了什么，别直接 accept all。有些禁令看着像废话，其实背后是一次线上事故。

今天就能做的几件事

写到这儿给几个能落地的动作，都不难，一晚上够了。

打开你的 CLAUDE.md，逐行分三类。第一类是介绍这个仓库是干嘛的，留一两句就够。第二类是模型自己看目录结构就能知道的，删。第三类是暗礁，留下来而且写具体，写清楚为什么。做完之后你大概率会发现，第二类占了一半以上。

然后搜一遍所有规则文件里的 never、always、不要、禁止、必须。每一条问自己一个问题，这条当初是为了防哪个模型的哪种翻车。答得上来的留着，答不上来的删掉。答不上来说明那个坑可能早就不在了。

接着看你的工具描述。里面的 example 尝试拿掉，把省下来的力气花在参数上，能用枚举就别用自由文本，能在字段名里说清楚的就别在描述里解释。这条改起来最费劲，收益也最实在。

skill 文件超过两三百行的，拆。按「什么时候需要什么」来拆，不要按「这些内容看起来是一类」来拆。

最后这条最重要，删之前先留一份 baseline，跑一遍你自己的评测。

Anthropic 敢删八成，是因为他们后面有一整套编码评测顶着，删完能立刻看到掉没掉分。你没有这层保护就动手删，那不叫优化，那叫赌。哪怕你的评测只有二十条人工挑出来的典型任务，跑一遍前后对比，也比凭感觉强一百倍。

说实话我自己也还在摸索这套东西该怎么用，尤其是自动记忆那块，我到现在也没完全想清楚在需要严格复现的场景里该怎么跟它相处。有想法的朋友评论区聊聊。

压舱石

Anthropic 前几天还发过另一篇讲他们内部开发流程的文章，里面提到 Claude 已经承担了他们产品工程相当大比例的 PR。厉害了，自己吃自己做的饭，还敢把菜谱贴出来。把两篇放一起看，指向的是同一件事，这家公司在按「模型会继续变强」这个假设重构自己的工程实践，而不是按「现在这样挺好」来做加固。

所以那八成提示词被删掉，我看着不像一次优化，更像一次公开的技术债清算。

我们这两年给模型写的规则，很像出海时一路往船上捡的压舱石。风浪大的时候它们确实压得住船，可风向变了，船本身也换了，它们就只是拖着你跑不快的重量。麻烦的地方在于，压舱石从来不会自己滚下船，得有人在某个天气还不错的下午，走到甲板上，一块一块往下扔。

那份 CLAUDE.md 你多久没删过东西了。

真要开始扔，官方文档和那份 Fable 的实践指南可以一起翻着看。