一个团队删掉了自家 agent 框架 61% 的内容，同一时间 Anthropic 删掉了 Claude Code 系统提示词的 80%。两边独立收敛到同一个结论——这篇讲的是那个结论。
harness 里的每一个组件，都编码了一个关于「模型自己做不到什么」的假设——而这些假设会随着模型变强而过期。
把这句话反过来读，问题就清晰了：你 harness 里的每一条，都在赌一件模型做不到的事。问题只是这个赌注什么时候到期。
所以真正的工作不是「精简」，而是识别哪些赌注已经到期、哪些永远不会到期。这个区分一旦建立，后面所有的具体建议——删什么、怎么写、留什么——都能自己推出来。
而区分的判别式只有两条，简单到可以背下来：
「这些东西以后会不会被模型内化掉」——这个问题没有统一答案，一概而论地回答「会」或「不会」都不对。得分层看。
很多团队自建 harness，重写自己的执行循环、设计自己的 workflow 引擎。而 L1 恰恰是最会被平台原生吸收、最不保值的一层——Claude Code、Codex 每个版本都在往里吸收这些能力。
那是投入最大、贬值最快的地方。
L2 不会被模型内化，但会从指令层沉降到工具层——变成 linter 规则、测试用例、CI 门禁。
一条容易记的分工：指令层的强度取决于模型当下怎么读它；工具层不取决于。所以能表达成工具的，就别留在指令里。
有个很干净的检验方法：把「换一个团队，这条会不会不一样」套上去。L2 和 L3 的答案全是「会」，L0 和 L1 的答案全是「不会」——所以 L0 与 L1 注定由模型和平台提供。
如果只把这轮变化理解成「精简一点更好」，就错过了最重要的部分。
在弱模型时代，多写一句话最坏的结果是浪费 token；今天，多写一句话可能覆盖掉模型自己更好的判断。这是性质的变化，不是程度的变化。
过度规定流程会引入噪音、缩小模型的搜索空间，或者导致机械化的回答。
OpenAI · GPT-5.5 prompt guidance
「缩小搜索空间」是这轮变化的技术内核：你写下的每一条路径规定，都在从模型可选的方案里剪掉一部分。当模型比你更清楚哪条路好走时，这个剪枝就是净损失。
这三条最值得抄下来贴在显示器上，因为它们都是很多人正在写、而且自以为无害的写法。
在人类之间这是个程度副词；在指令遵循能力足够强的模型那里，是一条会被严格执行的规则。你以为在调节风格，实际在削减召回。
官方给的正确做法：让它全报，然后另开一轮过滤。
CRITICAL: You MUST use this tool when…过去为了让模型可靠调用工具，大家习惯这么写。现在官方建议降级成普通的 Use this tool when…——新模型对系统提示词更敏感，激烈措辞会导致过度触发。
同理，If in doubt, use [tool] 这类兜底句现在是过度触发的主要来源。
这类规则官方要求直接删掉——它反而会增加内部标签泄漏到可见输出里的概率。而且「点名负面项」比「笼统表述」效果更差。
正面替代：与其写一堆「不要怎样」，不如给一个你想要的样子的正面例子。
注意官方的处置建议是「删除」，不是「改写」。Anthropic 的文档里甚至直接点名了 legacy harness scaffolding（遗留的 harness 脚手架）——那是在明确告诉你：你 harness 里那些旧脚手架该拆了。
上面几条都还停留在「建议」层面。prefill 不是建议，是既成事实。
prefill（预填充助手回复的开头来强制输出格式，比如先塞一个 {"result": 逼模型接着输出 JSON）是个存在多年的标准技巧。从 Claude 4.6 开始，这个能力从 API 层面直接移除，带 prefill 的请求返回 400。
官方理由只有一句：模型智能和指令遵循已经进步到大多数 prefill 场景不再需要它。
这是「脚手架消失」最干净的一个样本，也点破了这轮变化的性质——脚手架不是被优化掉的，是它防御的那个问题不存在了。
大家精简 prompt 时想的通常是省上下文预算，但真正的代价在别处：
你加了一个文件，agent 读了它，然后又去读真实代码确认一遍，现在它得调和两个事实来源。
Addy Osmani · Stop Using /init for AGENTS.md
代码会变，你写的那份描述不会跟着变。当两者不一致时，agent 要么信了过期的那份，要么花额外的推理去判断该信谁。过期的文档比没有文档更危险。
配套的删除判据非常好用——这条信息，agent 读你的代码库能不能找到？能找到就删。按这条：目录结构、架构概览、技术栈描述全该删；而「用 uv 管理依赖」「跑测试必须加 --no-cache，否则会有假通过」这类要留，因为读代码找不到。
作者团队还有一条可以逐行机械执行的判据，比抽象提醒好用得多：一个没有本次会话记忆的 agent 读到这一行，行为会怎么变？答不出来就删。用它扫一遍，三类东西必然出局——元评论（「这里以前出过 bug」）、自我辩护（「这就是本 skill 存在的理由」）、防御性否定（「这不是指某某」，为了澄清反而把被否定的概念引入了上下文）。
前面一直在讲「少写、别规定路径」，很容易被理解成另一个极端：那就什么都别写，全交给模型。这是放羊，不是放权。
关于绝对措辞，OpenAI 给了一条很实用的分界线：把 MUST / NEVER 留给真正的不变量；判断题——何时搜索、何时追问、何时用工具、何时继续迭代——一律改写成决策规则。
按这条线，作者团队 harness 里保留绝对措辞的地方只剩一类：不可逆动作。commit、push、MR 合入、deploy、workspace 之外的删除。这些是真正的不变量，写死没有代价。其余全部改成了判据。
官方要求：在写大量文档之前，先建评测。五步是——不带 skill 跑一遍记录具体失败（不是「效果不太好」，是「它在第三步漏掉了 X」）→ 针对 gap 建三个评测场景 → 建立 baseline → 写刚好够填补 gap 的最少内容 → 迭代对照。
注意「最少内容」的定义方式：不是靠写的人自己把握分寸，而是由评测反推——能让评测从不通过变成通过的那些内容就是必要的，多出来的都是待辩护的。这也是为什么 Anthropic 敢一次删掉 80%：删了会不会坏，不是靠判断，是靠跑出来的。
但这套流程真正的价值在它的副产品：每条规则天然绑定了它防御的那个具体失败。这一点直接决定了你能不能在未来删掉它。
把删掉的和留下的并排放，harness 里的内容其实分成了两种资产：一种每次模型升级都要减记一次，另一种越积越厚而且没人能替你积。
L0 + L1 · 过去一年真实到期的脚手架
CRITICAL 类强调语L2 + L3 · 删剩的 6,400 字符只有这四类
价值排序、私有 context（三年前那个模块为什么要那样设计）、主观 oracle（什么样算好看）——这些信息物理上不在模型能到达的地方。
不在公开语料里，否则每个组织都会是一样的答案；也不在你的 repo 里，否则 grep 就能拿到。这不是智力问题，是信息可达性问题。
第一条理由有个漏洞：信息不可达，理论上可以靠「把信息补齐」来缩小。第二条堵住了它。
只有人能继承后果。你可以让 agent 在 policy 内安全地做选择、路由、合并、升级，但它无法继承后果。这不是能力问题也不是信息问题，是社会结构问题——出了事，被问责的是人。连理论上都无法被技术进步消解。
这一节回答了一个很普遍的现象。根因不是懒——是这些规则当初就没写清防的是什么，所以谁也不敢删，因为谁也判断不了它是否还有用。文件于是变成一堆没人说得清是否还起作用的历史包袱。
说不清防什么的规则，从写下来的那一刻起，就已经无法被淘汰了。
所以「面向未来设计」唯一可执行的形态不是「留个接口、留点余地」（那是猜测，而且猜错代价很高），而是——你预测不了模型什么时候会内化某条规则，但你可以让「已经被内化」这件事变得可检测。做法就是给每条规则绑定它防御的具体失败模式。
Addy Osmani 把这叫「棘轮法」：只在观察到真实失败之后才加约束，规则必须能追溯到真实发生过的错误，而不是猜测。
除了 L3，还有一类容易被漏掉——因为它不是能力缺口。
模型自评时会自信地夸奖自己的作品，即便在人看来质量明显平庸。这不是「模型不够聪明」，而是评价者与被评价者是同一个造成的结构性问题。用 Addy 更直白的说法：写代码的那个模型给自己的作业打分，实在是太宽容了。
结论：独立 reviewer 和跨模型校验的价值，不随模型变强而衰减。需要补充一个精确的观察——Anthropic 的实测是 evaluator 的价值边界只是外移了：以前需要 QA 复核的任务现在模型能自行完成，但复杂应用仍然从独立评审中获益。是边界移动，不是价值消失。
你能交给一个循环的自主度，上限就是你能廉价且可靠地验证的那么多——一寸都不能多。
Addy Osmani · back pressure
顺着这条线还有一个更大的背景：验证，而不是生成，才是真正的瓶颈。启动一个 agent 只要一句话，但收口一个 agent 一点也不便宜。当生成速度超过你能有意义地验证的速度，积累的就是认知债。
这种债最麻烦的地方在于它不像技术债那样通过摩擦暴露自己——它滋生的是虚假的信心。
这条上界还有一个直接推论落在 gate 的设计上：gate 的数量上限，等于人能真正判断的数量上限。人在 gate 面前会退化成快速点头，所以对策不是减少 gate，而是让每个 gate 便宜到能真判——把需要裁决的事项、证据和推荐前置，全文和 diff 作为可选读的附录。一个人判不动的 gate 等于没有 gate，而且更糟：它制造了「已经审过」的假象。
pending / in_progress / completed——枚举本身就在引导正确用法。对足够强的模型，示例反而会成为约束，因为它比你给的例子更有想象力。commit / push / deploy / 删除 是真正的不变量，写死没有代价。另外提醒一句：原文里有十几处关键内容是图片——四层归属图、到期清单表、删除类型归纳、注释规则的 before/after 对照。本文里的四层模型和到期判别式是从图片周围的文字反推出来的，逻辑成立，但如果你要引用具体分类项，最好回原文对着图看一遍。
如果只挑一篇一手原文读，选 Anthropic 的 The new rules of context engineering for Claude 5 generation models——删掉 80% 的来龙去脉、六个转变、以及规则→判据的 before/after 对照都在里面。