Anthropic 把系统提示词删掉 80% 且性能无损，这背后是上下文工程（Context Engineering）取代提示词工程的范式转移。提示词工程管的是「怎么问」——单次指令的结构、示例、角色设定；上下文工程管的是「在推理时往上下文里放哪些 token」——系统指令、工具描述、MCP、外部数据、消息历史，所有会落进上下文窗口的东西。上下文是有限资源，Transformer 架构下 n 个 token 产生 n² 对注意力关系，上下文越长模型从中准确召回信息的能力越差，这叫 context rot。Claude Code 的做法正是通过按需加载、渐进式披露来对抗这种衰减。

Claude Code 删掉 80% 系统提示词的关键工程技术是渐进式披露（Progressive Disclosure）。传统做法是把所有规则、工具定义、例子一股脑塞进上下文，像 100 个顾问同时把资料箱倒在桌上。渐进式披露是三层架构：元数据层只给技能名称和一行描述（约 100 token），模型判断需要时再调用 read_skill 加载完整指令层（SKILL.md），最后按需访问资源层的示例和脚本。这种策略解决了「技能数量 × 完整指令体积」导致的上下文窗口溢出——100 个技能全量加载需约 50 万 token，远超限制。Claude Code 的工具延迟加载（defer_loading）也是同理，50+ 工具不全部内联发送，只在模型决定调用某工具时才加载其 schema。

文章说 CLAUDE.md 应轻量化、主要记录代码库里的坑而非常识。实战验证：超过 200 行的 CLAUDE.md 反而让 Claude 表现更差。原因在于每次会话都加载它，每行废话都在占用模型理解代码的「脑容量」——500 行的 CLAUDE.md 消耗 5000-8000 token，这些 token 本可用于更关键的任务上下文。正确写法是只记录项目独有信息：架构概述、常用命令、代码规范、已知坑点。比如「订单表的 create_time 字段用的是 UTC，前端展示需要转东八区」——这种常识之外的信息才是 Claude 真正需要的，技术栈、公司使命这些不必写。

Anthropic 发现给新模型举例子「反而把它们限死在某个探索空间里」，于是转向思考工具接口本身的设计——参数怎么命名、枚举值怎么定义、结构怎么暗示用法。比如 Todo 工具把 status 设成 pending / in_progress / completed 三个枚举值，模型自然理解工作流；不用再写「一次只能有一个进行中任务」。这条路径的下一步是：当模型能理解接口语义时，Agent 框架的「提示词」层会越来越薄，核心竞争力从「谁写得好 prompt」转向「谁设计得好工具接口和上下文编排」。Claude Code 的动态工作流（Dynamic Workflows）就是这种演化的产物——模型根据任务即时生成编排脚本，协调多个子 Agent 并行工作，不再依赖人工预设的静态流程。

Anthropic 发现 Opus 5 / Fable 5 这代模型判断力大幅提升，删掉 80% 系统提示词后编码评测无损失。这引出两个值得追问的方向：第一，模型能力是否存在一个「提示词阈值点」——过了这个点，详细指令的边际收益递减甚至为负（因为约束限制了模型自身判断力）？第二，如果最佳做法是「让模型自己判断」，那系统提示词最终会消失、只剩工具接口设计吗？还是说总有某些高风险领域（如删除文件、修改生产数据）需要绝对指令而非模型判断？这些问题的答案，决定了未来 Agent 系统架构的走向。