Claude 5 时代的 context 工程新规则

原文是 Anthropic 官方博客 2026 年 7 月 24 日发布的工程文章，作者 Thariq Shihipar，Anthropic 技术团队成员（Member of Technical Staff）。文里的「我们」就是 Claude Code 团队自己——这不是外部观察者的推测，是亲手把自家 system prompt 砍掉 80% 的人在讲他们砍了什么、为什么敢砍。文章发布后，海外多家技术媒体做了二次解读。中文翻译、重排与 5 张配图本地化：Yaqin Hei（非原创，已保留原文出处）。

译者的话：为什么翻这篇

多数人的 CLAUDE.md 和 skill 只增不减。每踩一次坑就加一条，从来没删过——我自己也是。

这篇点破的是：那些规则里有很大一部分，是为旧模型的缺陷买的保险。模型换代了，保险还在扣费，而且是从 context 预算里扣。你以为自己在给 agent 上护栏，实际上是在拿今天的 token，付一年前那个模型的账。

我拿它当尺子量了自己这套配置。写作那个 skill 三万多字符，比整个仓库的 CLAUDE.md 还长将近一倍，里面塞满了「例子」和「不要做 X」。它改的不是我某一条规则，是我加规则这个动作本身：以前踩坑就加一条；现在踩坑先问一句——这是模型判断力不够，还是我这个仓库真的特殊？只有后者才配进 CLAUDE.md。前者只要换代就该删。

下周你可以先做一件事：把最长那个 skill 打开，数一下有多少条是「怕模型犯傻」，多少条是「只有我这个仓库才知道的坑」。两个数字摆在一起，该删哪些就不用问了。

以下是正文

面向更强的模型，我们把 Claude Code 的 system prompt 删掉了 80% 以上。这些经验，怎么用到你自己的 context 工程和你自己的 agent 上。

我之前写过怎么给新一代 Claude 5 模型写 prompt，以及怎么跟它反复迭代，把你想做的东西一点点问清楚。

但你给 Claude 发一条消息时，prompt 只是它拿到的 context 里很小的一块。你的 context 大部分是拼装出来的——system prompt、Skills、CLAUDE.md、memory，还有别的来源。我们把这件事叫 context 工程（context engineering），无论你是在用 Claude Code，还是在自己造 agent，它对结果的影响都很大。

prompt 是一次性的，context 不是——它要覆盖很多次不同的请求，所以没法写得那么具体。于是问题来了：你根本不知道用户下一句会问什么，怎么写这种通用的指令和指导？

这件事的难，还在于 Claude 自己的能力一直在变。最近我们就发现，给新一代 Claude 模型写 prompt 的方式出现了一次大跳变：对 Claude Opus 5、Claude Fable 5 这一档模型，我们把 Claude Code 的 system prompt 删掉了 80% 以上，coding 评测上测不出任何损失。

下面是我们对这一代模型摸出来的东西，以及你可以怎么拿它更新自己的 context 工程。这些实践我们已经做进了 claude doctor；在 Claude Code 里敲 /doctor，它会帮你把 skills 和 CLAUDE.md 调到合适的体量。

给 Claude 松绑

（原文小标题是 Unhobbling Claude。hobble 是给马绑上脚绊、让它跑不起来的那个动作——这一节讲的正是把脚绊一根根解掉。）

总的来说，我们发现自己一直在过度约束 Claude Code——system prompt 里在约束，CLAUDE.md 和 skills 里也在约束。

举个例子。我们翻自己内部使用 Claude Code 的对话记录，经常在同一个请求里看到几条互相打架的指令：一边是「文档该留就留」，一边是 system prompt 里的「不要写注释」——system prompt、skills、用户请求，三方各说各的。

同一份 context，Claude 全都要读，还得自己调和。图中引号内为示意文本，不是任何真实 prompt、skill 或用户请求的原话。

一般来说 Claude 能领会用户的真实意图、给出对的答案，但面对这些重叠又矛盾的说法，它得先多想一轮，才能决定做什么。

这些约束当年确实必要，用来兜住最坏的情况；但我们后来发现，其中很多都可以删掉，让模型自己看周围的 context、自己拿判断。

还有一点：Claude Code 现在的工具多多了。以前 Claude 主要靠 CLAUDE.md 当记忆、当信息源、当行为指南。现在我们有了 memory、artifacts 和 skills，Claude 可以用它们造出新的方式，把 context 在多次会话之间装载和共享。

昨天与今天

有一批过去的 context 工程最佳实践，如今已经变成了迷思。包括：

划掉的是昨天的规则，右边是今天的做法。

昨天：给 Claude 定规则 → 今天：让 Claude 用判断力

Claude Code 刚上线那会儿，我们必须确保它不会做出最坏的事，比如删文件。这意味着我们会给一些特别强硬的指令，哪怕它并不总是对的。比如 system prompt 里我们曾经这么写：

写代码时：默认不写注释。绝不写多段式 docstring 或多行注释块——最多一行短注释。除非用户要求，不要创建规划、决策或分析类文档——从对话 context 里干活，不要产出中间文件。

但对某一部分请求来说，这条指令是错的。就拿文档来说，用户可能有自己的偏好；某些特别复杂的代码，也确实需要多行注释块。

话说回来，对更老的模型，没有这些护栏，Claude 写出来的注释很多时候是错的，我们只能接受这个取舍。但新模型的判断力更好，不用明说规则，也能把这类决定处理得不错。

新的 system prompt 里我们是这么写的：写出来的代码要读着像它周围的代码，注释密度、命名、惯用法都对齐。

昨天：给 Claude 举例子 → 今天：设计接口

工具使用的第一条铁律，曾经是给 Claude 示范怎么用。到了我们最新的模型上，我们发现举例子反而会把它们框死在某一小片探索空间里。

与其教它怎么用，不如让接口本身把用法说清楚。

与其举例子，不如多想想你的工具、脚本和文件本身怎么设计——Claude 手里有哪些参数，这些参数能不能更会说话？

比如 Todo 工具那个例子，光是把 status 列成 pending、in_progress、completed 这么一个枚举，就已经在暗示 Claude 该怎么用了。而「同一时刻只保持一项 in_progress」这句指令，则把我们想要的行为定义清楚了。

昨天：全都放在最前面 → 今天：用渐进式披露

因为 Claude Code 是围绕写代码做的，我们的 system prompt 里塞了大量关于怎么做 code review、怎么做验证的细节。这些内容不是每次都用得上，但用得上的时候是关键信息。

后来 Claude Code 把渐进式披露（progressive disclosure）用得非常熟练——该加载的 context，在该加载的时候加载。比如我们把验证和 code review 各自挪成了独立的 skill，让 Claude Code 按需调用。

渐进式披露不只是 skills 能用，工具也能用。我们有一部分工具是「延迟加载」（deferred loading）的：agent 得先用 ToolSearch 把完整定义搜出来，才能调用。这样我们就能挂更多工具（比如 Task 那一系列），而它们在被用到之前不占 context。

同样的思路可以用在你自己的 CLAUDE.md 和 Skill.md 上。有个常见迷思是：这些文件得当成一个中央仓库，把你可能撞上的所有实践全写进去，否则 Claude 就找不到。恰恰相反——不如做成一棵文件树，需要哪块、什么时候加载哪块。

昨天：把话重复几遍 → 今天：简洁的工具描述

更早的 Claude 模型有时需要你把指令重复几遍，而且更容易听 context window 末尾的话，而不是开头的话。于是我们的 system prompt 里常常出现这种情况：主体部分提到某个工具，工具描述里又把怎么用写一遍。

我们发现这些重复的例子可以删掉，把「怎么用这个工具」放进工具描述里，而不是 system prompt 里。

昨天：把记忆写进 CLAUDE.md → 今天：自动记忆

我们过去鼓励用户用 # 快捷键把东西存进 Claude 的记忆里，它会自动写进 CLAUDE.md。现在不用了，Claude 会自动把跟这项工作、跟你这个人相关的记忆存下来。

昨天：简单的 spec → 今天：丰富的参考材料

在 plan 模式下，Claude Code 一直很依赖 markdown 格式的计划文件。把计划存成文件，Claude 需要时就能回去查。另一个类似的做法，是把 spec 存进代码库，方便 Claude 在跨度很长的项目里随时参考。

但我们发现，Claude 能吃下的参考材料可以复杂得多。除了简单的 markdown 文件，Claude 还能引用我们新的 artifacts 功能生成的 HTML artifact。

你也可以直接拿代码当参考材料给它。一份 spec 可以是一套详细的测试用例，也可以是另一个代码库里某个待移植的函数。

评分标准（rubric）是参考材料的另一种形态。有了 rubric，Claude 可以用动态 workflow 起几个验证 agent，带着这份 rubric 去检验你在某个领域的品味到底是什么——比如，什么样的 API 设计才算好设计。

落到你自己的 context 上

把这些串起来，你实际组装 context 的时候，它长什么样？

这几层各有各的职责，别互相抢活。

System prompt。 system prompt 和产品 context 是深度绑定的。它告诉 Claude 自己身处哪个产品、在做什么事。对 Claude Code 来说，你基本上永远不会去改它；但如果你在造自己的 agent harness，这里值得你花大量时间。

CLAUDE.md。 保持轻量，简短交代这个仓库是干什么的，然后把大部分 token 花在代码库里的坑上。比如你的代码组织方式可能是「所有类型都集中在一个巨型文件里，别处没有」。别写那些 Claude 看一眼文件系统、看一眼仓库就该知道的「显而易见的事」。

细节交给渐进式披露。比如你有好几条独特的验证规则，那就做一个验证 skill，从 CLAUDE.md 里指过去。

Skills。 把 skill 想成轻量的指南，让 Claude 需要时能找到信息。别把它写得约束过度——除非是特别要紧的地方。

skill 太长的话，尽量用渐进式披露：拆成多个文件，分出去。

skill 最好的用法，是把只属于你、你的团队、你的产品的那些主张、知识和实践编码进去。

References。 你可以用 @ 提及文件，把它们作为参考材料带进来。有了 references，Claude 就能查到当前计划的深层信息。

它可以是 spec 文件、设计稿，甚至整个代码库。总的来说优先给代码形态的文件——那是一种 Claude 极其熟悉的语言，指令清晰、保真度高。举个例子：一份 HTML 设计稿产出的结果，通常比一段文字描述或者一张截图要好。

试着做减法

不管是 system prompt、skills 还是 CLAUDE.md，你可能都需要像我们一样做一次减法。我们上线了一个新命令 claude doctor，它能帮你自动完成一部分。想更深入了解怎么给更强的模型写 prompt，可以看我们的 Fable field guide。

原文：The new rules of context engineering for Claude 5 generation models · 作者 Thariq Shihipar（Anthropic）· 2026 年 7 月 24 日。中文翻译与配图本地化：Yaqin Hei。