7 月 24 日，Claude 官方博客更新了一篇讲上下文工程的文章。里面有一句话，凡是给 AI 写过工作流的人，看到都该心里一紧：
面向 Claude Opus 5 和 Claude Fable 5 这一代模型，他们把 Claude Code 的系统提示词删掉了 80% 以上，在自家的编程评测上没有测出可观察的损失。
不是重写，不是优化，是删。删掉八成，成绩单没动。
这句话的杀伤力在于，过去两年整个行业攒下来的那套手艺——把注意事项塞满、把反例列全、把每条规则重复三遍——被官方用自己的产品当场证伪了一大半。
先说清楚：被删的到底是哪部分
很多人把「提示词」和「上下文」混着用，但这篇要说的，不是你在对话框里敲的那句话。
你敲的那句只是最小的一块。真正送进模型的是一整包东西：系统提示词、Skills、CLAUDE.md、记忆、@ 进来的参考文件……全部拼在一起，才是模型这一轮真正读到的内容。官方管这叫上下文工程。
区别在哪？提示词是一次性的，可以写得非常具体；上下文则要跨几百次请求反复使用，你根本不知道下一句用户会问什么，所以只能往「通用」上写。
而「通用」这件事，恰恰最容易写歪——因为你会忍不住把所有可能的情况都提前堵上。
官方原话：我们把 Claude 管得太死了
文章里用了一个词叫 unhobbling，直译是「解开脚镣」。团队复盘自己内部用 Claude Code 的对话记录，发现同一次请求里经常出现互相打架的指令：
系统提示词说「文档该留就留」，某个 skill 说「不要写注释」，用户又说「你就照旧的那个改」。
三句话来自三个地方，谁都没错，但拼在一个上下文里就变成了一道阅读理解题。模型当然能猜出你真正想要什么，代价是它得先花一轮心思去调和这些矛盾，然后才能开始干活。
这里藏着一个容易被忽略的因果：这些约束当初不是白加的。老一代模型判断力不够，不写死就真会写出一屏胡说八道的注释、真会满仓库拉平文档，所以团队宁可接受「有时候管错」，也要先把最坏情况堵住。
变的是模型，不是道理。新一代模型自己能看情况办事之后，同一条规则的性质就从「保险」变成了「成本」。
六条老经验，被官方逐条划掉
文章里最狠的，是这张对照表——六条曾经的最佳实践，现在全被划成了过时说法。
第一条：从「给规则」到「给判断」。
老版系统提示词里原话是这样的：代码里默认不写注释，绝不写多段式 docstring 或多行注释块，最多一行；除非用户要求，不要生成规划、决策、分析文档。
新版换成了一句话：写出读起来像周围代码的代码——注释密度、命名、习惯，都跟着上下文走。
前者是一条死线，后者是一个判断标准。前者在 90% 的场景里对，在剩下 10% 里错得很难看（比如某段复杂逻辑真就需要一大段说明）。后者把这 10% 交还给了模型。
第二条：从「给例子」到「设计接口」。
这条最反直觉。过去讲工具调用，第一铁律就是给示例。现在官方说，示例反而会把模型框死在你举的那几种用法里。
替代方案是去设计工具本身——参数取什么名、有哪几个取值、字段之间什么关系。
他们举了自家 Todo 工具的例子：状态字段就写成 pending / in_progress / completed 三个枚举值，模型自己就明白该怎么流转；再补一句「同一时间只留一项处于进行中」，行为约束就定死了。
不需要例子。接口本身就是最好的说明书。
第三条：从「全塞在前面」到「渐进披露」。
Claude Code 早期什么都往系统提示词里塞，包括怎么做代码审查、怎么做验证——这些内容不是每次都用得上，但用得上的时候至关重要。
现在这些统统被拆成独立的 skill，需要时才加载。工具也一样：一部分工具改成了「延迟加载」，模型得先用 ToolSearch 去搜，才能拿到完整定义。好处是工具可以做得很多，不用的时候一个 token 都不占。
顺便，官方专门点名了一个流传很广的误区：很多人觉得 CLAUDE.md 和 skill 文件必须写成大而全的中央仓库，否则模型「找不到」。正确做法是拆成一棵可以按需加载的文件树。
第四条：从「重要的说三遍」到「工具描述里说一遍」。
老模型有个毛病，同一条指令放在上下文末尾比放开头更容易被听见，所以团队习惯在系统提示词和工具描述里各写一遍。现在这些重复可以直接删掉，指令归位到工具描述里就够了。
第五条：从「手动记进 CLAUDE.md」到「自动记忆」。
过去要用 # 快捷键手动往 CLAUDE.md 里写东西，现在模型会自己判断哪些东西值得记下来。
第六条：从「简单规格书」到「富参考」。
以前写 plan、写 spec，习惯落成一个 markdown 文件。现在官方说模型能吃下复杂得多的参考物：一份详尽的测试套件可以当规格书，另一个仓库里的某个函数可以当规格书，一个 HTML 原型可以当设计稿。
甚至评分标准也是一种参考——把「什么算好的 API 设计」写成 rubric，让模型开一个验证 agent 去照着打分。
那到底该怎么写
文章末尾给了四个位置各自的定位，这部分其实比前面六条更实用。
系统提示词：它绑的是产品语境——告诉模型你在哪个产品里、在干什么。用 Claude Code 的人基本不用碰它；但如果你在自己搭 agent，这里值得花最多时间。
CLAUDE.md：保持轻。简单说清这个仓库是干什么的，然后把大部分篇幅花在坑上——比如「所有类型定义只在这一个文件里，别去别处找」。凡是模型翻一眼文件结构就能知道的事，一个字都别写。
Skills：把它当成「需要时能查到的轻量指南」，而不是必须遵守的军规。除非是特别要紧的领域，否则别把 skill 写得太死。写长了就拆文件。skill 最大的价值是承载你自己、你团队、你产品特有的那点见识——通用知识模型本来就有。
参考文件：@ 进来的东西优先给代码。官方原话是，一个 HTML 版的设计稿，效果通常好过一段文字描述，也好过一张截图。
官方还顺手上了个工具：在 Claude Code 里敲 /doctor，它会帮你把现有的 skill 和 CLAUDE.md 做一次「瘦身体检」。
一个做工作流的人的实感
我自己维护着一套几十个 skill 的内容生产流水线，读到这篇的第一反应不是「学到了」，而是有点尴尬。
因为我那套东西里，被点名的每一种写法都能找到——生怕模型跑偏，每条规则后面都跟着「绝不许」「必须」「否则视为未完成」；生怕它找不到，一个 skill 塞了几百行；生怕它忘了，同一句话在三个文件里各写一遍。
这些不是懒，恰恰是过去两年被模型教出来的条件反射。每一条背后都对应着一次真实的翻车。
问题是，条件反射的更新速度赶不上模型。当年那些约束是为了兜住能力的窟窿，窟窿补上之后，约束不会自动消失——它会留在文件里，继续和模型现在的判断力对抗。上下文这东西又是加法结构，只进不出，一年下来就成了一层层压死的沉积岩。
所以这篇文章真正在说的，不是「少写点」这种懒人福音。它说的是你的规则文件需要一个定期删除的机制——每次模型换代，都该回去问一遍：这条当初是为了补哪个短板？那个短板还在吗？
还有一句话值得单独拎出来：约束的作用是防最坏情况，不是提升平均表现。防最坏情况是有代价的，代价就是你顺手把最好的情况也一起摁死了。以前这笔账划算，现在不一定了。
至于删多少合适——官方自己删了 80%，你不必照抄这个数字。但如果你从来没删过，那大概率不是 0。
数据来源
- Claude 官方博客：《The new rules of context engineering for Claude 5 generation models》（2026 年 7 月 24 日，作者 Thariq Shihipar）
- Claude 官方博客：《A field guide to Claude Fable: finding your unknowns》
- Claude Code 官方文档（code.claude.com/docs）
你手里的 CLAUDE.md 或者规则文档，现在有多少行了？上一次删东西是什么时候？