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就能得到写进去只会占窗口。更值钱的内容通常长这样一句话职责这个仓库解决什么问题不解决什么问题反向约定和常规开源习惯不一致的地方例如「类型必须集中在某文件」「禁止某类自动重构」高风险动作哪些命令默认不要跑、哪些路径改前必须先读测试索引而不是正文验证看哪个 Skill长流程看哪份文档细节不要贴进常驻文件Anthropic 的原话大意是轻量描述仓库用途把 token 花在 gotchas验证类长说明做成 Skill从短文件引用。 progressive disclosure渐进披露才是主策略——需要时再展开而不是预防性塞满。一个很实用的自检删掉这段后Agent 会不会在真实任务上明显变笨如果不会它多半是安慰剂文字。另一个自检更狠这条规则是否会与用户当次请求冲突如果会尽量改成「跟随周围代码 / 跟随用户明确要求」这类带判断的表述而不是绝对禁令。Claude Code 的/doctor本质上是把「权利尺寸」自动化帮你发现过约束的 Skill 和过长的仓库说明。自己搭 Agent 时也可以做等价检查——不是有没有规则而是规则有没有在互相打架。四、JIT Skill把流程从「常驻」改成「召唤」JITJust-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 天拆出 12 个 JIT Skill优先拆「验证」和「评审」。常驻文件只留一行入口。Skill 里写清命令与完成判据。第 3 天给「宣称完成」接独立校验本地脚本或 CI 均可。原则是测试/lint 红任务状态就不能是 done。第 45 天用真实任务回归选 3 个最近常做的改动类型跑一遍。记录两类信号误伤不该拦的被拦了 → 放宽规则或改成判断型表述漏拦该失败的没失败 → 补确定性闸而不是加形容词第 67 天看窗口与返工如果常驻 token 明显下降而返工次数没有上升说明精简有效。若返工上升先检查是不是把「硬约束」误删成了「口头约束」而不是急着把说明书糊回去。七、几个值得留下的判断第一模型一代一代变强Context 的最优形态会跟着变。今天正确的长规则可能是明天的过约束。要把规则当可老化资产而不是碑文。第二精简不是管理变松是责任上移人更少靠叮嘱更多靠结构设计——文件树、工具接口、测试、权限、门禁。第三若你只能做一件事先做这件事让「完成」依赖退出码而不是依赖模型语气。有了这道底砍系统提示才安全没有这道底砍提示只是关掉警报器。Anthropic 用八成提示换来的不是放任而是承认新一代模型更吃判断力也更怕被互相矛盾的规矩绑住。该交给判断的别写成死规则该交给机器的别再写进提示词。