提示词删改背后，价值千金的Claude Code版“苦涩教训”

作者｜董道力
微信 ｜ddl941110

这几天，围绕Claude Code系统提示词究竟是否删减，还是其实偷偷增加，产生了不少讨论。

先是Claude Code 团队成员 Thariq Shihipar 发了一篇文章，说他们把 Claude 的系统提示词砍掉了超过 80%，内部编程评测没有明显下滑。

这属实有点打破常识，通常大家设计 Agent 的时候，恨不得写几十页的 Prompts，每当模型犯一次错，就又在后面再补一条规则。

但两天后，Qoder 工程师陈成抓取了 Claude Code 实际发出的请求。他发现，大幅精简发生在 Opus 4.8，并非 Opus 5。Opus 4.7 的系统提示词约有 15225 个字符，4.8 降到 4467 个，Opus 5 又增至 7694 个，比 4.8 长了 72%。

两组数据互相打脸，眼看又是一场风波。人们很是好奇，这 Anthropic 是放烟雾弹了还是又要开始炒作啥了？

不过这次还真不是。

1

删掉的 80%，是旧模型时代的六条最佳实践

我们先来看看它删掉的是什么。

Anthropic 团队翻 Claude Code 的内部使用记录时，发现同一个请求里经常出现互相冲突的要求，比如系统提示词说「不要加注释」，Skills 说「适当补充文档」，用户又临时要求「把复杂逻辑解释清楚」。

Claude 其实能明白出用户到底要什么，但它得先处理这些矛盾的指令，之后才干活。这么做不但浪费时间，还浪费 Tokens。

这些提示词不是没用，旧模型缺判断力，规则不写死，最坏情况真会乱删文件。可新模型已经能结合用户要求和上下文自己判断。旧规则不适配新模型的能力。

所以这次删除的内容，主要沿着六个方向，把「为旧模型准备的东西」进行销毁。

• 让模型自己判断

早期 Claude Code 规定得很死，默认不写注释，禁止多段文档字符串，用户没要求就别建规划和分析文档。这能管住旧模型的表达欲，也会误伤真正需要详细解释的复杂代码。

新版只留下一句话：匹配周围代码的注释密度、命名和习惯。要求看着少了，Claude 需要做的判断反而更多，它需要根据任务，再决定怎么写。

• 设计接口而不是给事例

给模型塞工具调用范例，曾经是 Agent 开发的铁律。Anthropic 却发现，新模型很容易把示例中的方法当成全部答案。

于是团队开始少写事例，多设计接口。比如，Todo 工具只要把状态规定成 pending、in_progress 和 completed，再限制同时只能有一个任务进行，Claude 已经能自己推断用法。

• 需要时再加载，不要一下子全加载

过去大量审查、验证和工具说明常驻系统提示词。用户只改一句文案，也得先陪 Claude 运行长长的上下文。

现在这些流程被拆成独立 Skills，工具定义也通过 ToolSearch 按需加载。Claude 只需要知道东西放在哪，真需要时再取。

• 说一次就好

旧模型容易忘指令，同一条规则往往要在系统提示词、工具描述和示例里反复出现。而新模型对长上下文的理解更深，重复提醒反而容易制造冲突。同一件事，只交给一个地方负责。

• 交给模型自动记忆

过去项目说明、用户偏好和工作经验全往 CLAUDE.md 里堆。现在长期状态交给自动记忆，CLAUDE.md 只保留代码库简介和真正反常识的坑。“写出高质量代码”不必提醒，“所有类型必须放在同一个文件里”才值得写。

• 只给简单规格。

新模型已经不需要人类把所有要求翻译成一份“适合 AI 阅读”的简化说明。HTML 原型、测试用例、现有代码和评分标准，都可以直接成为参考。一张真实原型图告诉 Claude 的东西，远比“页面要高级、简洁、有呼吸感”更多。

可以说，Anthropic 删掉的不是上下文本身，而是人类替旧模型预先做好的判断。

模型能力没增长的时候，规则是在填坑，模型能力增长以后，不肯删掉的规则，本身就成了坑。

1

增加的 70%，是管理新模型的坏脾气

前面删掉的六类内容，解决的都是旧模型的问题。但旧规则失效，不代表系统提示词会一直变短。模型升级以后，一些过去不明显的行为开始影响 Claude Code 的使用体验，Anthropic 又要增加新的限制。

这也是 Opus 5 比 4.8 多出 72% 的原因。

根据 Qoder 工程师陈成的推文，Opus 5 主要增加了两段 Delivering work 和 Corrections。我们结合 Piebald-AI Claude Code 提示词库，来看一下两段内容究竟是什么。

• 
  

  Delivering work

这段要求 Claude 按照用户原本要求的范围交付工作。普通的模糊问题由模型自己判断，只有不同理解会明显改变结果时，才需要停下来询问用户。

它还规定，Claude 不能因为自己发现了更好的方案，就悄悄缩小、扩大或改变任务，不能只完成容易的部分，再把结果说成已经完成，如果某一部分确实无法推进，也要先做好剩余部分，再明确说明缺了什么、为什么没做。

这些规定针对的是 Opus 5 容易扩大任务范围的问题。

Opus 5 的自主性更强，它会加入用户没要求的步骤，也会根据自己的判断，修改用户原本要解决的问题。

例如，用户只让它修复一个报错，它可能顺手重构周围代码、补充测试、更新文档，甚至检查同类模块。

• Corrections

Anthropic 在 Opus 5 指南里提到，这个模型比以前更喜欢向用户解释自己的纠错过程。它会指出前面哪句话说错了，详细分析错误原因，再说明现在准备怎么调整。

这种行为会让用户感觉模型一直在反复，尤其在长任务中，很多更正根本不会改变最终结果，只增加了输出长度。

所以 Corrections 要求 Claude 只解释真正影响代码、结论或决策的错误。无关结果的小失误，直接改掉继续做。不要加入道歉和开场说明，不要反复批评自己，也不要逐条统计前面犯过的错误。

用户提出追问，不等于 Claude 之前一定说错了。其他 Agent 指出问题时，Claude 也要先判断对方是否正确，不能直接推翻自己的结论。

一段防止 Claude 做得太多，一段防止 Claude 说得太多。

旧模型首先要解决的是能不能完成任务，而 Opus 5 已经能够完成更复杂、更长的任务，产品团队才开始处理任务范围和过程沟通的问题。

1

苦涩的教训：人类最舍不得删掉自己的聪明

2019 年，强化学习先驱 Richard Sutton 写了一篇文章，叫《The Bitter Lesson》。他翻了七十年的 AI 发展史，发现人类总忍不住把自己的经验和解法，直接写进机器。

下国际象棋，就告诉机器人类棋手总结的套路；做语音，就把音素结构写死；做图像，就让专家指定哪些视觉特征最重要。短期看，这些规矩往往立竿见影，也最让研究者有成就感。

但当算力一上来，这些精心设计的规则很快就会失效。最后，反而是利用堆算力的通用方法是最有效的，而且是遥遥领先的有效。

这教训之所以苦涩，是因为被淘汰的通常不是什么愚蠢设计，恰恰是研究者最得意、投入最多的部分。

人类的智慧，在（算）力大砖飞面前，不值一提。

Claude Code 删掉的那些提示词，就是一个缩小版的「苦涩的教训」。正是这些提示词，让 Claude Code 成为神一样的 Agent。但随着模型继续进化，这些提示词开始反过来拖产品的后腿。

作为在Agent与模型协同进化这事上最领先的产品，这一次的删减风波，直接难得地把Claude Code在设计系统提示词时如何应对模型变化带来的挑战背后的核心思想展示了出来。

想想上次Claude Code源代码的泄露给后面各类Agent产品爆发带来的关键作用，就知道这次看似提示词删减背后，这一整套“苦涩教训”也是价值千金。

今天所有关注上下文工程的人们该记住的是，别把自己干活的每一步都写进提示词，让模型永远踩着旧经验的脚印走。

更能扛过模型换代的，是一套能持续扩展的环境：具体走哪条路，应该最终交给模型自己。

点个“爱心”，再走 吧