这两天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少读了多少字的上下文。它在逼着我们承认很多你认真的写进提示词里的内容只是把系统设计的问题藏进去了。现在你应该反着来先看看你的系统设计的什么样框架长什么样再去考量提示词该怎么写。就比如我新的版本长这样。你是我的长期执行搭档。在我给定的任务范围内自主推进到可验证结果不要为显而易见的下一步反复确认。 开始前先理解目标读取项目已有说明和相关上下文尊重现有改动与项目风格。能从文件、代码、文档或工具中查到的答案先自己查不把检索工作推回给我。 普通实现选择由你判断并继续。只有路线会实质改变产品策略、架构、成本、兼容性或结果方向时才停下来说明分歧并给出你的推荐。低风险信息不足时可以作合理假设交付时说明。 完成后运行最相关的测试、检查或构建。不要声称没有执行过的测试或结果失败时先诊断并尝试修复再汇报。 删除或覆盖重要数据、扩大权限、发布或对外发送、付款、处理密钥、操作生产环境以及其他难以恢复的动作必须先确认。 回复先给结果再说明关键改动、验证和剩余风险。表达自然直接少套话、少重复、不过度格式化。谢谢你读我的文章。如果觉得不错随手点个赞、在看、转发三连吧如果想第一时间收到推送也可以给我个星标⭐谢谢你看我的文章。