两周前，Anthropic 发布 Claude Opus 5 时扔出了一个反直觉的数据：Claude Code 的系统提示词被砍掉了超过 80%，内部编程评测没有明显下滑。
乍听像是产品优化小新闻。但事情没那么简单。
Boris Cherny（Claude Code 之父）在 Y Combinator 的最新访谈里，把这句话背后的完整故事抖了出来。同时，Claude Code 团队成员 Thariq Shihipar 和第三方工程师的追踪数据显示，这不只是一个数字游戏——它暴露了 AI 产品开发方法论的一次根本性翻转。
我们今天来拆这件事。因为它关乎每一个在 Agent 上做产品的人——不管你用 Claude、GPT 还是开源模型。
一、删掉的 80%，到底是些什么？
不是乱删的。
Anthropic 团队翻 Claude Code 内部使用记录时，发现同一个请求里经常出现互相冲突的要求——系统提示词说「不要加注释」，Skills 说「适当补充文档」，用户又临时要求「把复杂逻辑解释清楚」。
Claude 能看出用户要什么，但它得先处理矛盾的指令。浪费 Tokens，还浪费时间。
删掉的内容沿 六个方向 展开：
1. 让模型自己判断
过去写得死死的：默认不写注释，禁止多段文档字符串，用户没要求就别建规划文档。新版只留一句话：匹配周围代码的风格。要求少了，判断反而多了。
2. 设计接口，而不是给事例
给模型塞工具调用范例曾经是铁律。Anthropic 发现模型容易把示例当成全部答案。于是少写事例，多设计接口——Todo 工具只要把状态规定成 pending / in_progress / completed，Claude 已能自己推断用法。
3. 需要时再加载，不要一股脑全塞
大量审查、验证和工具说明常驻系统提示词。用户只改一句文案，也得先陪它跑完长长上下文。现在拆成 Skill，工具定义通过 ToolSearch 按需加载。
4. 同一件事只交代一次
旧模型容易忘，同一条规则要在提示词、工具描述和示例里反复出现。新模型对长上下文理解更深，重复反而制造冲突——同一件事只交给一个地方。
5. 让模型自动记忆
过去项目说明、用户偏好全往 CLAUDE.md 里堆。现在交给自动记忆，CLAUDE.md 只保留代码库简介和真正反常识的坑。
6. 只给简单规格
新模型不需要人类把所有要求翻译成「适合 AI 阅读」的简化说明。HTML 原型、测试用例、现有代码、评分标准，都可以直接作为参考。
一句话概括：Anthropic 删掉的不是上下文本身，而是人类替旧模型预先做好的判断。
二、那为什么 Opus 5 又比 Opus 4.8 长了 72%？
这里出现了一个反高潮。
Qoder 工程师陈成抓取了 Claude Code 实际发出的请求后发现：Opus 4.7 的系统提示词约 15225 个字符，4.8 降到 4467，但 Opus 5 又增至 7694 个——比 4.8 多出 72%。
不是打脸。原因比打脸有意思得多。
旧模型的能力瓶颈是「能不能完成任务」，所以删。但模型升级后，新问题出现了。
增加的 70% 管的是两件事：
Delivering work — Opus 5 自主性太强了。用户让它修复一个报错，它可能顺手重构周围代码、补充测试、更新文档。听着不错？但用户只想要一个 bug fix。所以新规定了：不要因为自己发现了更好的方案就悄悄改变任务范围。困难的部分推不动，先把能做的做完，再明确说缺了什么。
Corrections — Opus 5 还喜欢解释纠错过程。「我刚才说错了，其实是这样的……」在长任务中，很多更正根本不影响最终结果，只增加了输出长度。新规定：只有真正影响代码、结论或决策的错误才需要解释。无关结果的小失误直接改掉。不要反复批评自己。
一段防止 Claude 做得太多，一段防止它说得太多。
这是一个更值得注意的信号：问题的性质随着模型能力的提升在变化。 你过去精心设计的规则，在新的能力层级上，不但多余，甚至有害。
三、「消融实验」——一个被严重低估的方法论
Boris 在访谈中提到了一个概念，我认为是整篇谈话最有价值的部分：
消融（Ablation）。
做法极其简单：每当新模型发布，删掉整个系统提示词，逐行重新加入，观察每一行到底产生了什么影响。
不是猜模型需要什么——是先让它跑，看它哪里不行，再加对应的指令。
Boris 的原话是：
不要一开始就去猜模型需要哪些指令，因为很多时候你的判断可能是错的。真正有效的方法是，直接开始使用模型，观察它在哪些任务上出色，哪些地方失败。只有当你发现模型反复在同一个地方出问题时，才考虑把相关指令加回来。
他甚至提供了一个可以直接用的实验方法：
# 删除 Claude Code 的所有系统提示词
CLAUDE_CODE_SIMPLE=1 claude「有趣的是，模型在没有这些提示词的情况下，实际上会稍微更聪明一些。」
这和我们绝大多数人做 Agent 开发的习惯完全相反。大多数团队的做法是：模型犯一次错，就加一条规则。几个月后，系统提示词膨胀到几万字。
而 Anthropic 的做法是：每个模型版本迭代，先无差别清零，再按需重建。
Boris 还把这个原则推到了更广的范围：
对于那些不是构建 Agent 产品、而是在使用 Claude Code 的人来说，每隔六个月，你也应该删除你的 quantum D，删除你的 skills，删除你的 hooks。看看模型会有什么变化。
六个月的「消融节拍」——这不是技术建议，这是方法论层面的范式切换。
四、「产品过剩空间」和「解除束缚」
Boris 还提出了两个极有洞察力的概念。
产品过剩空间（Product Surplus）： 当前模型已经具备的能力，但你还没有一个产品让这些能力真正发挥出来。Claude Code 的诞生就是最典型的例子：Sonnet 3.5 已经能一次生成完整函数甚至完整文件，但当时的产品只做「单行代码补全」和「读代码不写代码」。Claude Code 只是去掉了多余的脚手架，给了模型一个尽可能简单的 Harness——然后这个世界级的编程 Agent 就诞生了。
束缚（Fettering）： 反面同样存在——产品不但没有释放模型能力，反而阻碍了它。你以为你在「设计产品」，实际上你在给模型戴镣铐。Boris 建议的方法：给模型安排一些稍微超出你预期能力范围的任务。 把任务描述在更高的层级——告诉模型你想完成什么、限制条件是什么、什么算完成——然后放手。
这句话值得每个做 Agent 产品的人反复读：
理解模型的方式，应该更像在理解一个有生命的东西，或者说一个更加有机的系统。每一代模型的表现都会有所不同，它会展现出不一样的行为方式，甚至有一点像拥有不同的「个性」。你必须花时间去了解它，然后根据它的特点调整 Harness。
不是设计架构，是驯养生物。
五、苦涩的教训，在系统提示词上的完美再现
2019 年，强化学习先驱 Richard Sutton 写了《The Bitter Lesson》。
核心论点：七十年的 AI 发展史反复证明——人类总忍不住把自己的经验和解法直接写进机器。 下棋就写定式，语音就写音素结构，图像就让专家指定特征。短期看这些规则立竿见影，甚至让人很有成就感。但当算力一上来，它们迅速失效，反而是利用规模计算的方法遥遥领先。
这个教训之所以苦涩，是因为被淘汰的从不愚蠢——恰恰是研究者最得意、投入最多的部分。
Claude Code 删掉的那些提示词，就是一个缩小版。
那些提示词让 Claude Code 成为神一样的 Agent。但随着模型继续进化，它们开始反过来拖产品的后腿。 因为每一条规则都是向过去模型的缺陷低头的产物。模型修复了缺陷，规则就成了累赘。
这是所有 Agent 产品都要面对的挑战：你今天的核心竞争力，可能正是明天的技术债务。
解决方案也不是不写规则——而是把规则看作临时性实验产物，带着随时可能删除的心态来写。你的系统提示词、工具定义、Skills——它们的生命周期可能只有一代模型的窗口期。
六、落到行动：给所有 Agent 开发者的四条建议
1. 建立消融节奏
每发布一个新模型（大约 3-6 个月），对你的系统提示词进行一次全量消融实验。删掉所有，逐行加回，观察每一行的影响。工具、Skills、hooks 也一样。
2. 单点负责，拒绝重复
同一条规则只写一次。如果需要在多个地方重复才能生效——那不是模型，是你在强行驯服旧模型。趁消融的时候一并清理。
3. 区分「历史包袱」和「当前问题」
系统提示词里那些「防止模型做 X」的规则，多半是针对早已不存在的旧模型行为。先搞清楚这条规则是为哪个版本写的，那个版本还在吗？
4. 超越提示词工程
Boris 反复强调：真正重要的不是「正确的提示词」，而是给模型布置有挑战性的任务 + 给模型验证结果的方法 + 观察它在哪里失败 + 然后只解决那个失败点。
所有人在找的那个「一招制胜的技巧」，不存在。
这件事真正的启示，不是一个产品更新，而是一面镜子。
模型能力在以指数级增长。你为上个版本付出的所有「聪明设计」，都可能在下一个版本到来时变得多余。
真正能扛过模型换代的，不是一套精心设计的系统提示词，而是一套能持续清零重建的工程习惯。
删掉你过去辛辛苦苦写的规则。这是苦涩的教训，也是唯一的解法。