上下文工程到底是什么
先厘清术语。提示词是你刚敲下的那一行。上下文是那一行抵达模型时一并带过去的全部内容——由系统提示词、CLAUDE.md 文件、技能、记忆等来源汇聚而成，而你的提示词只是这一整包的最后一行。
原文说得很准：当你发送一条消息时，提示词只是模型所获上下文的一小部分。设计这一整包就是上下文工程，它对结果质量影响很大。
打个比方，提示词是今天交给新人的工作指令，上下文则是这位新人手里的整本手册。指令再清楚，手册一团糟，成果也会一团糟。
而这本手册是有保质期的，因为去年的模型和今天的模型并不相同。把新人手册塞给十年老手，非但没有帮助，反而是妨碍。这次公告的要点正在于此。
变了什么，变了多少
Anthropic 针对 Claude Opus 5、Claude Fable 5 这类最新一代模型，删除了 Claude Code 系统提示词的 80% 以上，且在其编码评测上没有可测量的性能损失。这就是原文开篇段落的说法。
他们给这件事起的名字是「Unhobbling Claude」——一种自我诊断：他们在系统提示词、CLAUDE.md 文件和技能这三处，对 Claude Code 施加了过度约束。
共有六组变化。原文以「过去」与「现在」并列的形式逐一列出。
| 过去 | 现在 |
|---|---|
| 给规则 | 交给判断 |
| 给示例 | 设计接口 |
| 全部预先塞入 | 使用渐进式披露 |
| 重复同一件事 | 只写在工具说明里 |
| 在 CLAUDE.md 里攒记忆 | 交给自动记忆 |
| 给简单规格 | 给丰富参考 |
规则一 — 别给规则，交给判断
旧的系统提示词里有这样一句：「代码中默认不写注释。绝不要写多段落文档字符串或多行注释块——最多一行短注释。」
问题在于这类规则并非总是对的。真正复杂的代码有时需要长注释，而「绝不」一旦写死，需要时也用不了。旧模型判断力不足，所以哪怕付出这种副作用也要用规则捆住。
如今留下的是一句话：「写出读起来像周围代码的代码：让注释密度、命名与惯用法与周边一致。」十行禁令变成了一行标准。
打开你自己的 CLAUDE.md 看看。里面一定有若干以「绝对不要」收尾的句子。几个月前那是推荐做法，如今其中相当一部分删掉反而更好。
规则二 — 用接口设计代替示例
过去做工具的正统做法是附上大量用法示例：这种情况这样用，那种情况那样用。
但在最新模型上，示例反而把模型圈住了。原文的说法是，给出示例实际上把模型约束到了某个特定的探索空间。本想当作参照的东西，变成了围栏。
所以新做法是少说话，让工具本身开口。原文举的例子是待办工具：把状态定义为 pending、in_progress、completed 三个枚举值，光这一点就已经暗示了该怎么用。再加一句「进行中只保留一项」，想要的行为也定义好了。
做得好的门把手，不用说明书也知道该推还是该拉。把写说明书的时间花在把把手做好上。
规则三 — 别全部前置，让它按需取用
这叫渐进式披露：在需要的时机加载需要的上下文。
Claude Code 自身就是这样改的。代码评审与验证方法这类并非总需要、但需要时至关重要的信息，被从系统提示词中移出，各自成为技能。工具也一样：部分工具采用延迟加载，智能体必须先通过 ToolSearch 找到完整定义才能使用。这样即便工具变多，平时也不占上下文。
CLAUDE.md 同理：把它当作服务台而不是仓库。简短写明这个仓库是做什么的，然后只做指路——验证看这个文件，部署看那个文件。细节拆分到单独文件或技能里，做那件事时才打开。
那么 CLAUDE.md 里该留什么？原文说把大部分 token 花在 gotcha 上，也就是坑。比如这个仓库把所有类型都放在唯一一个大文件里。反过来，光看文件结构就能知道的显而易见之事不要写——那些模型自己看得见。
规则四与五 — 不要重复，记忆交给自动
旧模型在对话变长后会忘掉前面，所以把重要指令写好几遍是正统，连 Anthropic 自己也把同一份工具用法写在系统提示词和工具说明两处。
最新模型说一次就懂。于是重复被清掉，工具用法只留在工具说明里。你的 CLAUDE.md 里几乎肯定有同一条规则出现两三次的地方，删掉能省 token 并提升表现。
记忆也更省手。过去要靠人保存：在聊天框输入以 # 开头的一行，就会直接写进 CLAUDE.md。现在与工作、与你相关的内容，模型会自己保存。
不过自动并不意味着显式就没意义。真正必须留存的东西，明确说一句请记住仍然更稳妥。
规则六 — 交出比 Markdown 更深的材料
一直以来，计划书、规格与设计文档默认用 Markdown 写，因为轻便简单。
但最新模型能处理复杂得多的参考材料，那就没有理由把要传达的信息刻意模糊化。原文建议优先使用以代码形式存在的文件，因为那是模型非常熟悉的语言，指令因此清晰。
具体来说：与其在 Markdown 里写「按钮是蓝色、圆角」，不如直接交出 HTML 原型。规格可以是一份详尽的测试套件——没有什么比「让这些测试通过」更明确的要求。让 Claude 把另一个代码库中的某个函数照搬过来，同样是规格。
评分表也是参考的一种形式。给出「什么才是好的 API 设计」这类标准表，模型就能启动验证代理，按该标准给自己的产出打分。与其用语言描述品味，不如把评分表交出去。
那我该怎么整理自己的文件
原文最后把这件事拆成四个位置，各司其职。
系统提示词与产品语境紧密绑定：它告诉模型自己正身处什么产品、在做什么。作为 Claude Code 的使用者，你基本不会去动它；如果你在做自己的智能体框架，那才是该花大量时间的地方。
CLAUDE.md 要保持轻量。简短写明仓库用途，把大部分 token 花在坑上。如果验证方式复杂，就单独做一个验证技能，CLAUDE.md 里只指向它。
把技能看作让模型在需要时找到信息的轻量指南。除极重要的领域外不要过度约束；技能一长就拆成多个文件。技能最有价值的时候，是承载你、你的团队、你的产品所独有的观点与经验。
参考资料用 @ 引入文件——规格文件、原型，甚至整个代码库。尽量优先用以代码形式存在的文件。
不必全部手工修改
读到这里，会想从自己的文件哪里下手。而 Anthropic 已经把这些最佳实践放进了工具里。
把 Claude Code 更新到最新版，然后输入 /doctor。它会按这些规则，把你的技能和 CLAUDE.md 文件调整到合适的规模——原文用的词是 rightsize。
归纳成六句：少给规则，交给判断；用接口代替示例；不要全部前置，让它按需取用；不要重复；记忆交给自动；用代码、HTML 与测试代替 Markdown。
贯穿始终的只有一句话：模型已经成了资深，而我们还在把新人手册塞给它。今天就能做的，是打开 CLAUDE.md 删掉那些「绝对不要」和重复的段落，然后运行 /doctor。