指令预算：模型只能有效遵循几百条指令
上周做了一次系统提示词考古。
起因是我们一个内部 Agent 越来越「轴」：明明任务很简单，它非要按部就班地列计划、复述需求、逐条确认。翻开系统提示词一看，好家伙，两千多行。里面能看到清晰的地层结构：最底下是一年前的「let’s think step by step」时代沉积物，中间是各种「你必须」「绝对不要」「在任何情况下」，最上面是最近几个月针对各种 bad case 打的补丁——每次出问题加一条，只进不出。
我做了个粗暴的实验：把规则按「最后一次证明有用是什么时候」分类，凡是说不清的全删，两千行砍到八百。跑了一周，不仅没出问题，之前那个「轴」的毛病还消失了大半。
删东西删出性能提升，这个体验促使我认真研究了一下背后的机制。
服从容量
HumanLayer 的 Kyle 提过一个概念我觉得抓到了本质：前沿模型大约只能有效遵循几百条指令，超过就进入「傻瓜区」——开始遗漏关键指令，甚至幻觉出你没写过的规则。
注意这和上下文窗口是两回事。窗口是「装得下多少」，现在动辄一百万 token，装下一本书没问题；服从容量是「能同时听进去多少条要求」，这个数字小得多，而且不随窗口变大而变大。
几百条听着不少，实际一算根本不够分。一个典型 Agent 会话的指令来源：系统提示词几十到几百条，项目配置文件（CLAUDE.md 之类）几十条，工具定义——这个最容易被忽略，每个工具的使用说明都是指令，挂二十个 MCP 工具轻松吃掉上百条——再加上用户消息本身的要求。四路汇合，超载是常态。
这解释了很多被归为「玄学」的现象。规则写了模型不遵守，多数时候不是它「没理解」，是那条规则排在第四百位，注意力分不过去。每加一条新指令，都在稀释所有旧指令的权重。这是我考古时删掉的那一千二百行的真正罪状——它们不是没用，是在给有用的规则捣乱。
拐杖会变成绊脚石
考古时另一个发现：很多规则在写下的当时是对的，只是模型换代后变成了负担。这个规律值得单独说。
「take a deep breath」「step by step」是 GPT-3.5 时代的必备咒语；到了 o 系列，官方明确提醒不要再写——推理模型自带这个能力，你再写就是干扰。GPT-5 时代有人在提示词里强调「充分分析上下文」，结果导致模型过度搜索；后来官方的建议变成「写更短、更结果导向的 prompt」。Claude 这边也一样，老版本推荐的 XML 标签加绝对化措辞，在新版本上会造成过度触发。
规律很一致：老模型需要拐杖，新模型自带能力之后，拐杖变绊脚石。而且贬值方向很坑人——你当年写得越用力（「必须！」「绝对！」「一步一步！」），现在坏得越厉害。
所以我现在把提示词维护当成一件有明确节奏的事：每次主力模型升级，主动跑一轮删减实验。不是等出问题再改，是默认旧提示词里有一批拐杖到期了。
预算不够怎么办：让它自取
删归删，有些知识确实需要。预算不够的正解不是硬塞，是渐进式披露——只告诉 Agent「有什么可以用」，需要时它自己去取。
三个我们实际在用的场景：
CLI 工具的用法，不贴文档，写一句「Python 包用 uv 管，先跑 uv --help」。一行顶五十行，而且永不过期——工具升级了它跑 help 看到的永远是新的。
技能包（skills），启动时只加载名称和一句话描述，模型判断相关才读全文。
MCP 工具懒加载，会话开始只注入工具名索引，按需拉取完整定义。这项我们实测省掉了 85% 以上的工具定义占用——挂了三十几个工具的会话，以前光工具 schema 就两万多 token。
字节 TRAE 团队把这个思路说得更系统，叫「渐进式索引」：入口文件是一级索引，模块文档是二级索引，代码是叶子。Agent 像走 B+ 树一样下钻，而不是把整棵树背进窗口。我觉得这个比喻会流行起来，因为它把上下文管理从「艺术」变成了数据库工程师都熟悉的东西。
把预算做成可以看的数字
考古是一次性动作，要防止沉积层再长出来，得有日常度量。我们现在给主要的 Agent 配了一个很土但有效的统计脚本，每周跑一次，输出三个数：
指令总量估算。把系统提示词、项目配置、当前挂载的工具描述拼起来，按「祈使句 + 禁令 + 条件规则」粗略数条数（让模型自己数，误差可接受）。这个数超过 300 就亮黄灯，超过 500 亮红灯——阈值是我们自己校准的，仅供参考，但有阈值本身比阈值准不准重要。
构成比例。指令来自哪里：系统提示词占多少、项目配置占多少、工具描述占多少。我们第一次跑这个统计时发现工具描述占了 55%——三十几个工具是历史上陆续挂的，一半早没人用了。砍工具比砍提示词容易得多，收益还大，这个低垂果实建议先摘。
周环比。指令数这周比上周多了几条、是谁加的。增长要有出处，就像代码要有 commit。听起来官僚，实际执行就是周会上花一分钟看一眼——但「有人在看」这件事本身，就把随手加规则的冲动摁下去了大半。
这三个数没有任何技术含量，价值全在「让不可见的东西可见」。预算管理的第一步从来不是省钱，是记账。
我现在怎么写 prompt
考古事件之后，我给自己定的写法可以概括成一句：prompt 是工作契约，不是话术。只写四样东西——目标、约束、验收证据、停止条件。语气助词、鼓励、威胁（「这对我的职业生涯非常重要」之类的老梗）全部不写。
另外一条硬性判断：一条规则如果能变成 lint、hook 或 CI 检查，就坚决不进提示词。写进 markdown 的是建议，模型概率性遵守；写进 CI 的是规则，百分之百拦截。指令预算应该留给那些真正无法机械化的判断——比如「这类改动要谨慎」背后的品味。
最后留个自查题，就是我考古时用的那个问题，对你的系统提示词逐条问：这条指令最后一次被证明有用，是什么时候？答不上来的，大概率是地层沉积物。放心删，模型比你想象的强，而且强得比你的提示词更新得快。