当模型变强之后，我们该做的是删掉那些规则
Anthropic在2026年7月发了一篇博客——他们在最新的Claude 5代模型上，把Claude Code的系统提示词砍掉了80%。再跑同样的coding评测，效果没降。
80%不是一个修修补补的数字。是整段整段删掉。那些曾经被认为不可或缺的规则，在新模型面前变成了可有可无的东西。
但这个数据让我想的不只是“原来很多规则是多余的”。我想的是另一个问题：那20%没被删的规则，凭什么留下来了？
这个问题比看起来难回答。因为它追问的不是“哪些规则现在还有用”，而是“当初写下它们的时候，你知不知道它们最终属于那80%还是那20%”。如果不知道——那现在留下的那20%，跟已经被删掉的那80%，在当初写下的时候有什么区别？
两种规则
给AI搭的架子里面，其实有两类完全不同的东西。
第一类：模型的能力确实还做不到，所以需要规则兜底。 比如早期模型在长对话里会提前宣布任务完成——它把“做完了80%“当作”做完了“。Anthropic把这种现象叫作agentic laziness。于是需要加一条规则：“必须在所有子任务完成后才能声明完成。“这是补丁。补丁的目的不是改变模型的行为模式，是防止行为模式里一个已知缺陷造成后果。
第二类：模型的工作方式从结构上就不适合做这件事，跟能力强弱无关。 比如LLM每一次API调用都是无状态的。它不知道“上一次对话结束时的结论是什么”，除非你每次把完整历史重新塞进上下文。所以需要外部系统来维持跨session的连续状态。这不是补丁，是分工。分工的目的不是修补，是接管——把一件模型结构上做不好的事彻底拿过来自己做。
同一个80%的数据里，这两类同时存在。
被删掉的那80%，大部分是第一类。它们编码的假设是“模型还做不到X”。当模型在5代上做到了X，规则就成了噪音。噪音不是中性的——它占着上下文预算，挤占token空间，让真正有用的信息被稀释。
留下来的那20%，大部分是第二类。权限边界、compact机制、hook系统——它们不但没被删，反而变厚了。 因为模型越强，它能做的操作越多，操作后果越严重，外部约束反而需要越精密。
这里有一个容易被忽略的细节：同一条规则，在不同模型代际之间，可以从第二类变成第一类。
“默认不写注释，永远不要写多段文档字符串”——这条规则在早期模型上属于第二类。不是因为模型“有时候会写错注释”，而是因为那个阶段模型确实缺乏对注释质量的判断力。它分不清什么时候该写、什么时候不该写，所以要一刀切地禁止。到了Claude 5代，模型的判断力可以自己做这个区分了。规则从分工变成了补丁，从补丁变成了噪音。
一条规则的分类不是它本身的属性，是它和模型当前能力之间的关系属性。 这个关系一直在变。
为什么默认是不拆
如果规则会过期，那自然的问题是：为什么过期的规则没有被及时清理？
在传统软件工程里，死代码有很高的可见性。编译器会警告unused variables，linter会标出dead imports，code review会拦截废弃的逻辑分支。但在AI的架子工程里，死规则几乎没有可见性。它们不会在运行时崩溃，不会在编译时报错。它们唯一的症状是——模型的表现开始缓慢下滑。慢到你可能以为是模型那次发挥不好，而不是架子本身在腐烂。
更麻烦的是反馈回路。加规则有正反馈，拆规则没有。 加上一条规则之后Agent犯错的次数确实减少了——你看得见改善。拆掉一条规则之后，如果不用A/B测试做对比，你根本不知道拆对了还是拆错了——你看不见变化。一个是确定性的正反馈，一个是不确定性的零反馈。任何系统在这种不对称信息下，都会向单方向膨胀。
然后还有一个更深的原因。一条规则被写下的那个瞬间，它背后有一个具体的事件——某次session里Agent做了一件让人头疼的事，你为了防止它再犯，加了一条规则。这条规则跟那个事件的记忆绑定在一起。半年后，事件本身已经模糊了，但规则还在。你不敢删，因为你已经忘记了“当时没有这条规则会发生什么”。记忆的消退保护了规则。
这三种机制——可见性缺失、反馈不对称、记忆绑定——合在一起，构成了一个规则只增不减的系统惯性。
有没有办法提前知道
回到那个核心问题：在写下一条规则的时候，能不能判断它最终会属于那80%还是那20%？
严格来说不能。因为你需要预测未来的模型能力，没人能做到。
但有一条近似的判断标准。问自己一个问题：这条规则禁止的是模型的行为，还是模型的职责？
禁止行为——“不要用any类型”“不要写多段注释”“不要在没有确认的情况下提交代码”——这类规则的高度依赖模型当前的能力水平。行为是可以被模型学会的。今天需要禁止的行为，下一代模型可能已经不需要了。它们天然属于那80%。
划分职责——“权限判断不交给模型”“跨session的状态不依赖模型记忆”“对输出的独立验证不由同一个模型执行”——这类规则的高度依赖的是模型的工作方式本身。自回归、无状态、单向读取——这些东西不是能力问题，是结构问题。它们天然属于那20%。
行为规则会过期。职责规则会变形，但不会消失。
但这个二分并不总是干净的。有些规则同时踩在两边的线上。“不得在没有确认的情况下执行shell命令”——它表面上是禁止一个行为，但背后是对“后果不可逆的操作该由谁判断”这个职责问题的回答。这类规则最难归类，也恰恰是最常见的一类。面对它们，判断标准需要稍微往前推一步：这条规则禁止的究竟是模型还没有能力做好判断，还是这件事的判断权本就不该属于模型？ 答案指向前者，它就是会过期的行为禁令。答案指向后者，它就是不该消失的职责划分。
这个区分在写规则的那一刻就有用。行为规则应该写得尽可能具体，因为具体的东西在它过期的时候更容易被识别出来。“不要在未修改的代码里乱改注释”比“保持代码整洁”更容易在模型升级后被追问“这条规则还成立吗”——因为它清晰地描述了一个具体场景，你可以在这个场景里做A/B测试。职责规则应该写得尽可能抽象，因为抽象的东西不会被具体场景的变化所挑战。“权限边界不由模型自行判断”是一句永远不会因为模型变强而过期的陈述——因为它在陈述的不只是“现在不该怎么做”，而是“这件事的归属权不在这里”。
这里有一个更深的推论：一条规则的保质期，跟它编码的假设有多显性成正比。 “不要在长对话里提前结束任务”这条规则之所以会在Opus 4.5之后过时，是因为它的假设——“模型分不清80%和100%”——没有被显性写出来。它藏在了规则背面。如果当时写规则的时候把这个假设显性化——“当前模型会在完成80%进度时误判为完成，因此需要外部强制检查”——那当模型升级时，这个假设就变成了一个可以检验的命题。你可以设计一个测试：新模型在80%进度时会不会误判？会就留，不会就删。
大多数规则被写下的时候，假设是隐性的。隐性假设不会自我更新。它们以规则的形式被冻结在上下文里，直到有一天它们跟现实之间的偏移大到可以被察觉——通常是模型换了一代之后。
最后
给AI搭架子的能力可以分三个层次。
第一个层次是知道什么时候该加一条规则。这是最基本的。你在一次session里发现Agent反复犯同一类错，你知道这里需要一个约束。
第二个层次是知道这条规则应该写成什么形态——行为禁令还是职责划分，具体还是抽象，放在CLAUDE.md还是linter里。这需要经验。
第三个层次——也是最难的那个——是知道什么时候该拆。不是等到模型升级之后被动审核，而是在写下规则的时候就让它的假设暴露在可以检验的位置上。不是为了今天好用，是为了六个月后有人拿A/B测试跑一遍的时候，能准确知道它还有没有用。
大多数的架子死在第二层和第三层之间。它们有足够多、足够好的规则，但这些规则一旦过期就开始静默地吃掉系统的上下文预算，没人看得出来。
这件事的难点不在于技术，在于正反馈只在加规则的瞬间出现，而清退规则的收益要几个月后才体现在模型表现的总体均值里。一个只有短期反馈的系统，不会主动做长期清理。
所以一个领域成熟与否，也许可以用一个简单的比率来衡量：花在清退旧规则上的精力，是否开始接近花在制定新规则上的精力。