2026 年 7 月，Anthropic 发了一篇很刺眼的笔记：面向 Claude Opus 5、Claude Fable 5 这一代，他们把 Claude Code 的系统提示砍掉了八成以上，编码评测几乎没有掉分。同期还有 /doctor，专门帮你给 CLAUDE.md 和 Skill「瘦身」。

很多人读完只记住半句：「模型强了，规则可以少写。」若停在这里，仓库很容易走向另一种失控——常驻文件变短了，但测试可以不跑、危险命令没人拦、完成标准只剩模型口头保证。

真正要学的是迁移：哪些约束该退出窗口，哪些约束必须进入环境。

Context、JIT Skill 与确定性校验三层分工

一、为什么旧式「规则堆叠」会失效

早期 Coding Agent 不稳，团队习惯用三层唠叨兜底：系统提示写死行为，CLAUDE.md 写满规范，Skill 再复述一遍。意图是防最坏情况，比如乱删文件、灌水式注释、跳过验证。

问题出在叠加。Anthropic 自己复盘内部 transcript 时发现，同一轮请求里经常同时出现「少写文档」和「该补说明就补」这类冲突指令。模型不是完全听不懂，而是先要在互相打架的规矩里做取舍，注意力被消耗在「听谁的」上，而不是「把任务做对」。

对旧模型，这是划算的坏交易：宁可过约束，也不要最坏情况。对 Claude 5 代，这笔交易变贵了——判断力够用时，过约束会压探索空间，还会把窗口塞满低价值指令。

他们改了几类典型写法，很值得对照：

过去常见写法	现在更合理的写法
「默认绝不写注释」	「注释密度、命名、习惯跟周围代码一致」
系统提示里常驻详细 code review / verification	拆成按需 Skill，用到再加载
用长示例教工具怎么用	把工具接口设计清楚，少用示例锁死探索路径
同一规则在系统提示和工具描述各写一遍	工具用法放进工具描述，系统提示只保留身份与边界
把 CLAUDE.md 当总记忆库	轻量 gotchas + 自动记忆 / artifacts / Skill 分工

重点不在「删字」，在「换承载层」。 删掉的是常驻冲突；留下的是判断空间和可执行边界。

二、先分清 Context 和 Harness

讨论精简时，很多人把「给模型看的字」和「卡住模型的闸」混在一起。这两层目标不同。

Context（上下文工程）回答：这一步它该看见什么。 包括仓库说明、任务描述、相关文件、记忆、Skill 索引、工具名。优化目标是：相关、及时、可负担。窗口是工作内存，不是档案室。

Harness（运行约束）回答：它做完以后，环境凭什么相信。 包括类型检查、测试、lint、沙箱权限、危险命令拦截、人工审批点、失败回流。优化目标是：可重复、难绕开、不依赖模型自觉。

Claude 5 代把大量口头规则撤出 Context，并不证明 Harness 可以变薄。口头约束越少，确定性校验越要硬。否则你会得到一种很糟的状态：对话更干净，事故更安静。

可以记一句分工：

• 能靠「看代码 / 看接口」判断的，尽量别写进常驻 Context
• 能靠退出码判定的，尽量别只写进提示词
• 只有产品身份、工作边界、仓库特有坑，才值得常驻

三、短 AGENTS.md：写「扫描器看不见」的东西

AGENTS.md / CLAUDE.md 最常见的失败形态，是第二份 README：目录树、安装步骤、常见命令、框架介绍。这些模型列目录、读 package.json / pyproject.toml 就能得到，写进去只会占窗口。

更值钱的内容通常长这样：

1. 一句话职责：这个仓库解决什么问题，不解决什么问题
2. 反向约定：和常规开源习惯不一致的地方（例如「类型必须集中在某文件」「禁止某类自动重构」）
3. 高风险动作：哪些命令默认不要跑、哪些路径改前必须先读测试
4. 索引，而不是正文：验证看哪个 Skill，长流程看哪份文档，细节不要贴进常驻文件

Anthropic 的原话大意是：轻量描述仓库用途，把 token 花在 gotchas；验证类长说明做成 Skill，从短文件引用。 progressive disclosure（渐进披露）才是主策略——需要时再展开，而不是预防性塞满。

一个很实用的自检：

删掉这段后，Agent 会不会在真实任务上明显变笨？

如果不会，它多半是安慰剂文字。

另一个自检更狠：

这条规则是否会与用户当次请求冲突？

如果会，尽量改成「跟随周围代码 / 跟随用户明确要求」这类带判断的表述，而不是绝对禁令。

Claude Code 的 /doctor，本质上是把「权利尺寸」自动化：帮你发现过约束的 Skill 和过长的仓库说明。自己搭 Agent 时，也可以做等价检查——不是有没有规则，而是规则有没有在互相打架。

四、JIT Skill：把流程从「常驻」改成「召唤」

JIT（Just-in-Time）不是时髦词，它直接对应 progressive disclosure。验证、评审、发布检查、迁移注意事项，对大多数回合都是噪音；只有进入对应阶段才是刚需。

一个好 Skill 通常具备四个特征：

• 触发面窄：什么情况下该加载，写清楚
• 步骤可执行：不是原则口号，而是命令、顺序、完成判据
• 编码特有知识：团队口味、仓库坑、产品约束；别复述「要写清晰代码」
• 允许判断：除了真正不能碰的红线，少用全大写的绝对句

坏 Skill 的症状也很固定：打开就是五十条 MUST，和系统提示抢权；或者把三个不相关流程塞进一个文件，导致每次加载都污染窗口。

工具侧同理。旧最佳实践强调「给示例」。新一代模型上，示例反而可能把探索空间锁死。更有效的做法是把工具参数设计得可表达：枚举值本身就暗示状态机，一条「同时只允许一个 in_progress」比三段示例故事更稳。

若你在做自己的 Agent 产品（而不只是用 Claude Code），系统提示反而仍值得精写——它定义「你是谁、在什么产品语境里工作」。但仓库级常驻文件应当变短：长流程进 Skill，硬约束进钩子和 CI。

五、确定性校验：完成定义不能交给自我鉴定

口头规则撤退后，最容易空窗的是「什么叫做完」。如果做完等于模型说「已完成」，你会重新养出一套更难调试的幻觉闭环。

最低限度，建议把完成拆成三道独立闸：

1. 静态闸 格式、类型、lint。失败即停，错误信息要可行动（指出文件、规则、怎么改）。

2. 行为闸 与改动相关的测试必须绿。不必迷信全量套件，但「相关路径零验证」不能算完成。

3. 权限闸 删数据、改密钥、强推远程、修改锁文件策略等，默认禁止或必须人批。这类事不适合靠「请小心」解决。

Agent 互审仍然有用，尤其适合设计取舍、可读性、边界情况。可它回答的是「值不值得合并」里偏品味的一半；另一半——「机器是否接受这份变更」——应听确定性退出码。

这里有个容易忽略的工程细节：校验必须站在模型外面。 同一 Agent 既写补丁又宣布审核通过，激励结构是歪的。即便你用第二个 Agent 做 review，最终仍建议留一道非 LLM 的门禁。否则你只是把单点幻觉升级成双点幻觉。

六、一套可落地的改造顺序（带验收）

不必推倒重来。按一周节奏做，反而更容易看出哪条规则真有用。

第 1 天：审计常驻文件 打开 AGENTS.md / CLAUDE.md，用两色标记：绿=扫仓库得不到的坑；灰=说明书。灰的删除或外移。

第 2 天：拆出 1～2 个 JIT Skill 优先拆「验证」和「评审」。常驻文件只留一行入口。Skill 里写清命令与完成判据。

第 3 天：给「宣称完成」接独立校验 本地脚本或 CI 均可。原则是：测试/lint 红，任务状态就不能是 done。

第 4～5 天：用真实任务回归 选 3 个最近常做的改动类型跑一遍。记录两类信号：

• 误伤：不该拦的被拦了 → 放宽规则或改成判断型表述
• 漏拦：该失败的没失败 → 补确定性闸，而不是加形容词

第 6～7 天：看窗口与返工 如果常驻 token 明显下降，而返工次数没有上升，说明精简有效。若返工上升，先检查是不是把「硬约束」误删成了「口头约束」，而不是急着把说明书糊回去。

七、几个值得留下的判断

第一，模型一代一代变强，Context 的最优形态会跟着变。今天正确的长规则，可能是明天的过约束。要把规则当可老化资产，而不是碑文。

第二，精简不是管理变松，是责任上移：人更少靠叮嘱，更多靠结构设计——文件树、工具接口、测试、权限、门禁。

第三，若你只能做一件事，先做这件事：让「完成」依赖退出码，而不是依赖模型语气。 有了这道底，砍系统提示才安全；没有这道底，砍提示只是关掉警报器。

Anthropic 用八成提示换来的，不是放任，而是承认：新一代模型更吃判断力，也更怕被互相矛盾的规矩绑住。

该交给判断的，别写成死规则；该交给机器的，别再写进提示词。