Anthropic 删了 80% 提示词，但你不能照做

TL;DR

Anthropic 砍掉了 Claude Code 系统提示词的 80% 以上，编码评测没有可测量的损失。

但这句话真正证明的，是那 80% 本来就没在传递信息——它是给弱模型打的补丁，不是知识。

一个团队能删掉多少提示词，度量的不是模型有多强，是他们之前写了多少废话。

模型学到的是世界的公共部分。你的规则里装的是私有部分——“我们周五不发版”、“这个库禁用”、“这个仓库的类型全在一个文件里”。这些从没进过任何语料库，模型再强也补不上。

该薄的是公共部分，该厚的是私有部分。而按 token 数砍，砍掉的往往正好是后者。

一、一份被当成指引的实验报告

Anthropic 最近发了一篇文章——The new rules of context engineering for Claude 5 generation models，讲他们如何为新一代模型重做上下文工程。核心事实只有一句：他们把 Claude Code 的系统提示词删掉了 80% 以上，在自己的编码评测集上没有观察到可测量的损失。

文章顺势列了六条“已经过时的最佳实践”：

给模型定死规则，改成让模型自己判断；给工具用法示例，改成把语义设计进接口；把信息全部前置塞满，改成按需分批加载；重要的话说三遍，改成说一次并放进工具描述；记忆写进 CLAUDE.md，改成让模型自动存取；用简单的 markdown 写规格，改成给它测试套件、代码、评分标准这类更丰富的引用。

这六条单独看都不难接受。真正值得停下来的地方，是他们删掉的具体是什么。

文章自己举了旧提示词的原文：“写代码时默认不加注释。绝不要写多段式文档字符串或多行注释块——最多一行。不要创建计划、决策或分析文档，除非用户明确要求。”

新版本把这一整段换成了一句：“写出和周围代码读起来一致的代码：注释密度、命名、惯用法都对齐。”

而这里有个绕不过去的问题：没有人拿得到那 80% 的清单。 HN 上有人直接问了——删掉 80% 是个很大的数字，能不能列出到底改了什么？我们需要知道哪些是模型训练里本来就会的、哪些是我们不该过度指定的。“让模型用判断力”这种说法，对真正在实现 agent 的人来说太含糊了。

这个追问没有得到回答。所以这篇文章的可操作性天然是低的：它给了一个结论和一个数字，但没给出得到这个数字的过程。你只能拿着“80%”这个锚点，去猜自己该删什么。

二、删掉的是补丁，不是知识

先把那句“绝不要写多行注释”拆开看：它到底在传递什么信息？

答案是——什么都没传递。

模型知道什么是注释，知道注释该怎么写，知道什么时候该多写、什么时候该少写。这些在训练语料里到处都是。那句禁令没有告诉模型任何它不知道的事，它只做了一件事：压制一种不稳定的行为。

老一代模型在注释这件事上的表现方差很大，有时会生成大段无意义的文档字符串。于是加一条强硬的禁令，用“一刀切的错”去换“随机的错”。文章自己也承认了这个取舍：没有这些护栏，模型写的注释在很多情况下是不对的，当时只能接受这个代价。

这类东西不是知识，是补丁。补丁的寿命和模型能力直接挂钩——能力上来了，方差收窄了，补丁自然就冗余了。删掉它不掉分，一点也不意外。

现在把这个观察翻个面。

“删了 80%，评测没掉分”——同一组数据，可以讲成两个故事：

一个是：我们的模型已经强到不需要那么多指导了。

另一个是：我们之前写的东西里，有 80% 本来就没在传递信息。

这两句话在数据上完全一致，含义却相反。第一个是能力叙事，暗示这是通用规律，别人也该跟着删。第二个是自查叙事，说的是他们自己那份提示词的冗余度。

而关键在于：第二个才是这次实验能支撑的结论，而且它不可推广。 他们的补丁比例高，不代表你的高。一个团队能删掉多少提示词，衡量的是这个团队之前往里塞了多少废话，跟模型强弱的关系比想象中小得多。

三、模型学的是世界的公共部分

上一节留了个问题：什么样的内容不是补丁？

判据不在“这条规则有多重要”，也不在“它写得有多长”，而在一个更朴素的地方——这份知识是从哪来的。

模型学到的是世界的公共部分。训练语料里有的，是被写下来、被公开、被反复讨论过的东西：语言、算法、框架用法、常见的坑、社区里吵过几百遍的最佳实践。模型在这些东西上确实越来越强，而且会继续强下去。

但下面这些，从来没进过任何语料库：

• 我们周五不发版
• 这个库我们内部禁用，用另一个替代
• 这个仓库的类型定义全部集中在一个文件里，别的地方没有
• 改这块要先过某个人
• 我们说“简洁”的时候，指的是不要用专业黑话，不是指少写字

这不是模型能力不足的问题。是它物理上不可能知道。 这些信息只存在于你的团队内部、你的代码库里、你自己的脑子里，从未被写成公开文本，也就从未有机会进入任何一次训练。

所以“把规则删掉、期待模型自己补上”这个期望之所以不切实际，不是因为模型不够强——是再强也没用。 变强发生在公共知识这条线上，私有知识根本不在这条线上。你可以等模型继续变强，但等到天荒地老，它也猜不出你们周五不发版。

这也顺带解释了一个之前想不通的现象：为什么 Anthropic 能删 80%，而你照着删就出事？

不是因为你的模型弱。是因为你的规则里私有含量更高。

他们删的是 Claude Code 这个产品级系统提示词。那份东西面向的是所有用户、所有代码库、所有场景——它按定义就只能写公共内容，写不了任何一家公司的特殊约定。所以它里面补丁比例极高，删起来当然安全。

而用户的 CLAUDE.md 和 skill 里装的是什么？恰恰相反，几乎全是私有的：这个项目的坑、这个团队的约定、这个人的偏好。两者从来不是同一种东西。 把前者的实验结论包装成“上下文工程的新规则”推给后者，这一步就是越界发生的地方。

四、代价都是迟到的

假设你还是照着删了。会发生什么？

答案是：当场什么也不会发生。 这正是最麻烦的地方。

删掉几条私有规则，模型照样能跑，任务照样能完成，输出看起来也没什么不对。你会很自然地得出结论——看，果然是冗余的。

代价在两个地方，而且都是迟到的。

第一处，是你换模型那天。

写在文件里的知识可以带走。你把 CLAUDE.md 复制到另一个 harness、另一个模型下面，它还在工作。但如果这份知识没被写下来，而是靠模型“自己判断”补上的，那它就长在权重里——换个模型，它就不存在了。

HN 上已经有人在换了。有人说自己彻底转向自建 harness 加开放权重模型；有人说新一代模型的行为让他难以接受，回去用别家。这些人搬家的时候，能带走的只有他们写下来的那部分。

厂商锁定这件事，机制其实比“阴谋”平淡得多。没有人锁你的文件。只是当你的 harness 越来越薄，你迁移时能带走的东西就越来越少——不是因为它被锁住了，而是因为它从来没被写下来过。

第二处，是半年后有人问“这段为什么这么写”。

这个问题会以各种形式出现：code review 时对方问你、事故复盘会上有人问、新同事接手时问，或者只是三个月后的你自己翻到这段代码，完全想不起来当时为什么这么写。

如果答案是“我让它按周围代码风格来，它自己判断的”——这个回答在任何一个场合都是空的。

有人在讨论里说得很直白：推理过程被隐藏之后，你甚至不确定它是用了某段记忆，还是自己独立联想出来的。你能看到的只有结果，看不到理由。

规则的价值有一半从来不是提升产出质量，是留下决策的痕迹。 git blame、commit message、架构决策记录、代码注释——这个行业发明了这么多东西，解决的都是同一件事：系统的寿命比人的记忆长。而“让模型自己判断”恰恰是在制造不可追溯——判断发生在权重里，不留痕迹。

还有一层更隐蔽的：模型变强，改变的不是错误的数量，是错误的形态。

HN 上有条实测说得最准。这位用户其实是早期就认同“少写命令式指令、多声明意图”的那批人——上一代模型的突破让他很早就把 CLAUDE.md 写得很轻。但新一代模型让他遇到了新麻烦：一旦跑偏，更难纠正了。因为它整体是错的，却用听起来合理的论据把痕迹盖住了，你很难指出问题具体出在哪。

从明显的低级错误，变成隐蔽的、有说服力的错误。这个变化对“该写多少规则”的影响，比“模型变强了所以少写点”要复杂得多。

五、控制没有减少，只是换了位置

顺着上一节往下推：事前写的规则，只能接住明显的错误。

你能预料到的失败模式，才能写成规则去防。而隐蔽错误的定义就是你预料不到——你不知道它会在哪个地方开始自我合理化，自然也就写不出对应的禁令。

能接住这类错误的只有一样东西：事后验证。

测试、评分标准、独立的验证流程。它们不试图预测模型会怎么错，只检查结果对不对。

有意思的是，Anthropic 的文章其实说到了这一半，只是没说透。它提到规格不一定是 markdown 文件，也可以是一套详细的测试；提到评分标准可以让模型去验证你在某个领域的品味，比如什么样的 API 设计算好设计。

但这不是“放弃控制”。这是把控制从入口挪到了出口。

这两件事不是替代关系。事前规则依然有用，它擅长拦住你已经知道会出问题的地方；事后验证补的是另一块——你事先根本想不到的那部分。真正变的是重心：模型越强，能被事前预料的错误越少，重量就越往出口那头压。

而且事后验证一点也不“新”，测试比提示词老得多。变的从来不是手段，是它在整套工作流里的位置。

而且出口这道关更难绕过。测试要么过要么不过，二值的，不需要模型配合；“请遵循 X”这种话则完全可以被软性忽略——模型一边应着“好的”，一边照旧。

所以总控制量并没有减少。文章标题喊的是做减法，实际发生的是位移。只讲了前半句、没讲后半句，读者就容易理解成“什么都不用管了”。

六、该薄的和该厚的

把前面几节收成一张可操作的表。判据只有一个：这份知识，模型能不能自己重新发现。

最后一类是唯一越写越值钱的。因为它是你和模型之间的信息差，不是模型的能力缺口——模型再强，也不会变强出你的品味。

而这里有个陷阱：Anthropic 的文章一边说“skill 最好是编码你、你的团队、你的产品特有的意见和知识”，一边说“避免让 skill 过度约束”。这两句话是拧着的。取舍类知识在形式上本来就是约束——你要求“术语换白话”就是在约束它。冗余的约束和承载信息的约束，是两种东西，不能用同一句话处理。

所以“skill 可以变薄，但不能变少”这个说法，需要再拧紧一步：

该薄的是公共部分，该厚的是私有部分。

薄是压缩表达，同一份知识从三段话变成一句话，信息量不变。少是删除条目，赌模型能自己推出来。这两件事被“删了 80%”这个数字合并在了一起，但它们完全不同。

而且要小心：薄到极致，和少，在后果上是等价的。

“不要过度润色”这五个字，对熟悉上下文的人有效，是因为下面垫着几十轮对话。换个模型、换个人，没有这些垫底，这五个字几乎是空的——它只是一个指针，指向一份没被写下来的共识。压缩没有让知识消失，只是把它挪进了更不可靠的地方。

最后两句：

按 token 数砍，砍掉的是最长的；按信息量砍，砍掉的是最冗余的。这两者经常正好相反。 私有知识往往写得又长又啰嗦，因为它本来就需要长——它要解释一件模型完全不知道的事。

没有验证的减法不是减法，是赌博。 Anthropic 敢删 80%，是因为他们有评测集，删完跑一遍，分不掉就是真冗余。而大多数人删 skill 是没有评测的，删完只能靠感觉“好像还行”。

而感觉不到问题，和没有问题，是两件事。代价都是迟到的。