Claude Code删掉80%系统提示词，老金的长文解读，信息很密！
图片加载中…
这两天Anthropic刚做了一件很反常的事。
它把Claude Code给Claude 5代模型使用的系统提示词删掉了超过80%，然后重跑内部编码评测，没有测到性能损失。
注意，是超过80%，我也整理了下我的规则规范，新的claude.md放到了文末，当然你用的是GPT5.6的话，我认为他也适用，不过你要是用的其他模型，我认为你可以先别改。
如果只看这句话，很容易把它当成新模型发布时惯用的宣传数字。模型更聪明了，提示词可以少写一点，好像也说得过去。
图片加载中…
过去这两年，我们训练出来的经验几乎完全相反。
模型漏一步，就加一条规则。格式跑偏，就补一个示例。它忘了检查，就在结尾再提醒一次。
担心同一条指令放在前面不够显眼，还要把它抄进工具说明、Skill和CLAUDE.md。
提示词越来越长，看上去也越来越认真。每一次失败都有一条新规定负责，下一次再出问题，至少不会显得我们什么都没做。
很多Agent项目就是这样长大的。
第一版系统提示词可能只有角色、目标和几条安全边界。上线以后遇到一次错误，就加一段修补。结果少了字段，加格式模板。调用错了工具，加调用示例。写了多余文件，加一句禁止创建。没有按计划走，再补一套先计划后执行的流程。
半年以后，谁也说不清其中哪些规则还在起作用。大家只知道删掉任何一条都像在冒险，因为那条规则背后通常躺着一次真实事故。
所以看到Anthropic这次的数字时，我最想知道的不是新模型到底强了多少。
我更想知道，那80%究竟是什么。过去被当成保险的东西，为什么大部分突然成了负担。
官方文章给出的第一个答案，老金我读起来有点尴尬，但又觉得没啥错。
很多规则已经帮不到模型，反而开始互相打架。
Anthropic检查Claude Code内部使用记录时，发现同一个请求里会同时出现leave documentation as appropriate和DO NOT add comments这类方向相反的要求。
它们不是谁故意写错了。系统提示词想阻止模型生成多余注释，Skill可能要求补齐文档，用户又希望代码保持现有风格。每一条单独看都有来历，放到同一次任务里却不能同时满足。
Claude通常仍能从上下文里猜到用户想要什么，但在行动之前，它必须先处理这些重叠甚至冲突的信息。
这让系统提示词的真正问题露了出来。
内容太长，不只是多占一些Token。更麻烦的是，每一条规则都在争夺当前任务的解释权。规则越多，模型越要判断哪些适用、哪些过时、哪些只能满足一半、哪一条拥有更高优先级。
我们以为自己在减少不确定性，结果可能只是把不确定性从模型回答搬到了规则冲突里。
图片加载中…
但冲突只能解释为什么要清理，还解释不了为什么敢一口气删掉80%。
第二个答案老金我觉得是个重点。
Claude Code周围的环境变了很多，最早的Claude Code必须靠系统提示词提前拦住许多最坏情况。官方举了一个很具体的例子，旧规则会要求默认不写注释，不写多段文档字符串，也不要在用户没有要求时创建规划、决策或分析文档。
这种规定对旧模型有现实作用。模型判断力不足时，强硬规则能降低它随手生成大段注释和中间文件的概率。
代价也很明显。当用户真的在写文档，或者一段复杂代码确实需要多行解释，这条保护规则就会变成错误规则。系统为了防住常见问题，顺手压掉了一部分本来合理的选择。
到了Claude 5代，Anthropic认为模型已经更能根据现场做判断。新系统提示词不再提前规定注释最多几行，而是要求代码读起来像周围已有的代码，匹配现有的注释密度、命名习惯和惯用写法。
这两种写法看起来都在管理代码风格，控制方式却完全不同。
旧写法先猜测所有项目会遇到什么问题，再给出统一禁令。新写法把仓库现场交还给模型，让它从正在编辑的代码里判断什么才算一致。
规则少了，现场信息的重要性反而上升了。
这也是80%能够发生的第一个条件。
模型必须有足够的判断力，才能把通用禁令换成基于上下文的选择。把同样的删减放到更弱的模型上，结果未必成立。官方自己也承认，那些旧护栏曾经是必要的，他们当时接受了规则偶尔过度约束的代价。
接着变化的是工具。
早期提示工程很强调给模型示例。担心它不会调用工具，就在系统提示词里写一遍输入长什么样、参数怎么填、调用后如何处理。示例越完整，模型似乎越不容易走错。
Anthropic现在认为，示例也会限制模型的探索空间。模型看到一套固定做法后，容易照着重复，即使当前参数和任务已经需要另一种处理。
他们给出的替代方案是设计接口。
例如Todo工具不需要靠一大段文字解释任务有哪几种状态。把状态参数明确限制为pending、in_progress和completed，接口本身已经表达了合法范围。再补一条始终保持一个任务处于进行中的约束，就能说明最关键的行为。
这比在系统提示词里放三组完整调用示例更短，也更硬性进行了约束。
因为示例依赖模型模仿，参数枚举直接限制了模型能提交什么。前者告诉它最好怎么做，后者让不合法的状态根本进不去。
很多提示词之所以越写越长，恰恰是接口太含糊。
工具把十几种动作塞进一个自由文本参数，最后只能靠系统提示词不断解释每种情况下该填什么。等接口把状态、对象和错误返回设计清楚，那些解释自然就没有继续常驻的必要。
再往下，是渐进式加载。
Claude Code专门处理编程任务，代码审查和验证当然重要。过去这些流程被详细写进系统提示词，因为模型随时可能需要它们。
问题在于，随时可能需要和每次都需要是两回事。
改一个README里的错别字，不需要先加载完整代码审查流程。查看一个报错原因，也不一定要读发布检查、迁移策略和多Agent验证方法。这些内容常驻以后，会在大量无关任务中占用开场上下文，还可能带来与当前请求无关的判断要求。
Anthropic现在把验证和代码审查移进各自的Skill，让Claude Code在任务真正需要时再调用。部分工具也采用延迟加载，Agent先通过ToolSearch发现它们，需要使用时才拿到完整定义。
这里省下的已经不只是一段系统提示词。
整个上下文开始从仓库式囤积，变成按任务调度。眼前要改代码，就读取代码和项目约定。需要验证，就加载验证Skill。碰到专用工具，再展开它的参数和说明。暂时无关的流程留在原位，不来争夺当前任务的注意力。
重复指令也因此失去了意义。
早期模型有时更容易听从上下文末尾的内容，于是同一条工具要求会在主系统提示词里出现一次，在工具描述里再出现一次。看上去是双保险，实际增加了两个版本逐渐漂移的机会。
现在Anthropic把工具用法留在工具描述里，删除系统提示词中的重复示例。规则和它负责的对象待在一起，工具变化时也只需要维护一个位置。
这件事对长期维护比省Token更重要。
同一要求写在三个地方，最危险的情况不是三份完全一样。真正麻烦的是其中一份半年后改了，另外两份还保留旧说法。模型每次运行都要面对三份看似权威、细节却不一致的规定。
提示词越大，维护债务越容易被藏起来。
还有一批内容从CLAUDE.md里搬走了。
过去用户会把记忆、偏好、仓库说明、踩坑经验和长期计划不断写进CLAUDE.md。这个文件很快会同时承担项目介绍、个人记忆、工作规范、工具说明和历史档案。
现在Claude可以自动保存与工作相关的记忆，复杂流程可以进入Skill，深入材料可以作为独立参考资料。CLAUDE.md不必再充当一切信息的总仓库。
Anthropic对它的新建议很克制。保持轻量，简要说明仓库是做什么的，把主要篇幅留给代码库里的真正反常的、仅看目录时候，不容易发现的陷阱。
规格说明也在变化。
以前为了让模型容易理解，大家倾向于把需求压成一份简单Markdown。现在模型可以读取更丰富的参考资料，包括HTML产物、代码里的现有实现、详细测试套件和评分标准。
一套测试有时比十段请确保正确更准确。一个可运行的参考函数，也可能比一页自然语言描述更少歧义。评分标准还能把团队对好坏的判断交给验证流程，而不是寄希望于模型记住一句保持高质量。
看到这里，80%的去向就比较清楚了。
原来的通用禁令，有些已经可以交给模型结合现场判断。工具参数变得明确以后，提示词里的调用示例随之缩短。代码审查和验证仍然保留，只在任务需要时通过Skill加载。重复要求回到唯一责任位置，记忆和参考资料也从CLAUDE.md里分了出去。
图片加载中…
所以我一开始那个模型变强了的解释，只说对了一半。
模型判断力提高，确实让很多保姆式规则可以删除。但如果Claude Code周围没有更明确的工具接口、按需加载的Skill、自动记忆、丰富参考资料和验证循环，单独把提示词砍短，留下的很可能只是一个更自由也更难控制的Agent。
Anthropic没有停止约束Claude Code。
它改变了约束所在的层。
能从仓库看出来的，交给现场。能用参数表达的，交给接口。只在特定任务出现的，交给Skill。能被测试判断的，交给测试。需要长期保存的，交给记忆和参考资料。真正高风险的动作，继续由权限、审批和安全闸门兜住。
系统提示词只留下每次任务都必须知道、又无法从别处可靠获得的内容。
这时再看编码评测没有下降，就没那么像魔法了。
Claude Code少读了大量常驻文字，但没有失去完成任务需要的全部信息。相关上下文只是换成了更合适的载体，在更接近使用时机的位置出现。
当然，这个结论有很窄的边界。
官方说的是Claude Opus 5、Claude Fable 5和Claude Code自己的内部编码评测。Anthropic没有公开这组评测的完整任务构成、每项分数和删减前后的逐题差异。
没有可测量的性能损失，也不等于每一个任务完全相同。它只能说明在Anthropic选择的编码评估口径里，整体没有观察到可测量退步。
这组结果不能直接证明其他模型、其他Agent框架、其他任务都能删除同样比例。一个客服Agent、研究Agent和代码Agent需要的上下文不同。一个依赖严格合规流程的企业环境，也不能照搬面向普通代码仓库的删减方式。
80%更不能被当成新的优化指标。
如果一个项目原本只有五百字系统提示词，里面都是产品身份、安全边界和工具权限，硬删到一百字只会让系统失忆。如果另一个项目已经累积了五万字重复规则，删掉80%可能仍然太长。
百分比描述的是Anthropic自己的起点，不是所有人的目标线。
真正值得复制的是判断方法。
打开一份长期维护的系统提示词或AGENTS.md，先不要急着删。看每条要求到底在解决哪类问题，它是否每次任务都适用，它有没有在别处重复，它能不能被现场、接口或测试更可靠地表达。
有些规则应该留下。
产品身份、权限边界、数据处理要求和难以恢复的高风险动作，不能因为模型更聪明就交给临场发挥。删除文件、外部发布、付款、扩大权限和处理密钥，需要明确、稳定、可审计的控制。
有些规则适合缩短。
例如不要生成多余文件可以改成尊重现有项目结构，只创建完成用户任务所需的文件。它不再预判所有文件类型，也保留了用户明确要求新文档时的空间。
有些规则应该搬家。
代码审查、发布、迁移、事故检查和公众号排版都有各自的长流程，但不会出现在每次任务里。把步骤放进对应Skill，总说明只保留触发条件。任务没涉及发布时，模型无需提前阅读发布动作和检查项。
还有一些要求根本不该继续写成提醒。
固定字段可以交给结构化Schema检查，工具状态由枚举限制。代码是否合格让测试判断，外部发布需要批准时，系统就在发送前等待确认。
语言提醒最擅长表达意图，机器约束更擅长判断结果。把后者长期伪装成一句请务必确保，通常只是在推迟问题。
最稳妥的做法，是先挑出几类最常见、也最容易暴露问题的真实任务。记录旧上下文下的结果、工具调用、失败恢复和安全动作，再用干净会话运行删减后的版本。
要看模型有没有少绕路，冲突指令是否减少，工具选择是否稳定，测试还能不能抓住错误。遇到信息不足时会不会继续查证，高风险动作是否仍然停在确认前，也要逐项比较。这些才是删减有没有伤到系统的证据。
Anthropic同期仍在强调验证循环。它建议把经常重复的人工检查写成Skill，在新任务里确认检查确实随任务结果运行，再逐步把多个验证过程接起来。
这个时间点很有意思。
一边是系统提示词删除80%，另一边是验证、Skill和动态工作流继续增强。两件事放在一起看，传递的方向非常明确。
前置文字可以少，完成标准不能软。模型可以拥有更多判断空间，结果必须接受更清楚的外部反馈。
这也是我认为这条新闻比一次提示词技巧更新更重要的原因。
过去很多人把Agent能力理解成模型加提示词。模型负责聪明，提示词负责把它管住。结果每次能力不足都回到同一个动作，继续写规则。
Claude Code这次展示的是另一种结构。
模型、系统提示词、项目文件、Skill、工具接口、记忆、参考资料、测试和权限共同组成运行环境。可靠性来自这些部分如何分工，不再只取决于系统提示词写得够不够长。
这会改变我们维护Agent的方式。
以后遇到一次失败，第一反应不该总是加一句话。先判断它属于哪一层。模型没看到关键事实，就改善上下文获取。工具含义模糊，就改接口。流程只在特定任务出现，就做成按需能力。结果无法判断，就补测试和验证。只有每次都适用、又无法由其他层表达的要求，才值得常驻。
系统提示词因此会变短，但整个系统可能比以前更严密。
80%最刺眼的地方，从来不是Claude Code少读了多少字的上下文。
它在逼着我们承认，很多你认真的写进提示词里的内容，只是把系统设计的问题藏进去了。
现在，你应该反着来，先看看你的系统设计的什么样，框架长什么样，再去考量提示词该怎么写。
就比如，我新的版本，长这样。
你是我的长期执行搭档。在我给定的任务范围内，自主推进到可验证结果，不要为显而易见的下一步反复确认。
开始前先理解目标，读取项目已有说明和相关上下文，尊重现有改动与项目风格。能从文件、代码、文档或工具中查到的答案先自己查，不把检索工作推回给我。
普通实现选择由你判断并继续。只有路线会实质改变产品策略、架构、成本、兼容性或结果方向时，才停下来说明分歧，并给出你的推荐。
低风险信息不足时，可以作合理假设，交付时说明。完成后运行最相关的测试、检查或构建。不要声称没有执行过的测试或结果；失败时先诊断并尝试修复，再汇报。
删除或覆盖重要数据、扩大权限、发布或对外发送、付款、处理密钥、操作生产环境，以及其他难以恢复的动作，必须先确认。
回复先给结果，再说明关键改动、验证和剩余风险。表达自然直接，少套话、少重复、不过度格式化。