Claude 5 时代，上下文工程的新规则 - Anthropic 为什么删掉了 80% 的系统提示词

Anthropic 的 Claude Code 团队成员 Thariq 最近发了篇文章，复盘他们为 Claude 5 一代模型做上下文工程的新规则。他是这么说的：

我们把 Claude Code 的系统提示词删掉了 80% 以上 - 针对 Opus 5、Fable 5 这类新模型 - 编码评测却没有任何可测的下降。

我读完挺受启发，今天就来分享一番。

先对齐一个概念。你给 Claude 发一条消息，那条 prompt 其实只是模型看到的上下文里很小的一块。真正的上下文，是系统提示词、Skills、CLAUDE.md、记忆这些东西拼装到一起的结果。怎么设计这些通用的指令，就叫上下文工程。它跟 prompt 不一样 - prompt 针对一次具体任务，上下文要管很多次请求，你甚至不知道用户下一句会问什么，所以没法写得太具体。

先看那个 80%：过度约束，是怎么拖后腿的

Thariq 说，他们翻自己团队用 Claude Code 的对话记录，经常在同一个请求里看到互相打架的指令 - 系统提示词说“该写文档就写文档”，Skills 又说“绝不要加注释”，再叠上用户自己的要求。模型大多数时候还是能猜对你想要什么，但它得先在这堆冲突的指令里绕一圈，才能决定到底怎么做。

这些约束当年是有用的。老模型能力有限，没有硬性规则，写出来的东西很多时候是错的，只能硬着头皮接受这个取舍。但新一代模型判断力够好，很多约束可以直接删掉，让它靠上下文和自己的判断来做决定。Thariq 给这件事起了个名字，叫 unhobbling，给模型松绑。

所以“删掉 80%”不是图省事，是发现那 80% 里有相当一部分，在新模型手里已经从“硬性规则”变成了“内耗”。

从“给规则”到“给判断力”

这篇最要紧的一件事，就在这个转变上。

过去我们怕模型闯祸，比如误删文件，就给很强硬的规则。系统提示词里甚至写死：“代码里默认一条注释都别写，绝不写多行注释块。”可对一部分任务，这条就是错的 - 有的用户就喜欢详细文档，有的复杂代码就是需要多行注释。老模型没有这条硬性规则会写错，只能接受；新模型不需要了。

新版系统提示词里，这条规则换成了一句话：“写出来的代码要像它周围的代码 - 注释密度、命名、风格都跟着上下文走。”

不再给死规矩，交给判断力。这一句，几乎是整篇文章的缩影。剩下的五组变化，都是它的不同侧面。

六组“过去 → 现在”

给示例 → 设计接口。 过去用工具的头号铁律是给模型示例，一步步教它怎么调。新模型上他们发现，给示例反而把模型框死在某个范围里。现在的做法是别堆示例，去打磨工具本身的设计 - 参数取什么名、枚举值怎么定，让接口自己把用法说清楚。比如 Todo 工具，状态就三个值 pending / in_progress / completed，再加一句“同一时间只保留一个 in_progress”，模型自然就知道该怎么用。

全塞在前面 → 渐进式披露。 过去系统提示词里塞了一大段怎么做代码审查、怎么验证的细节，不常用，可一旦要用又很关键。现在换成渐进式披露 - 该用的时候再加载：代码审查、验证拆成了独立的 Skills，模型需要时自己去调；有些工具做成“延迟加载”，模型得先用 ToolSearch 搜出完整定义才用，平时根本不占上下文。这条同样适用于你的 CLAUDE.md 和 Skills - 别把所有可能用到的规矩都堆进一个大文件，而是拆成一棵树，该加载哪块就加载哪块。

反复叮嘱 → 简洁的工具描述。 老模型有时需要反复叮嘱，而且更容易听上下文末尾的话。所以系统提示词里会重复提某个工具，工具描述里又写一遍。现在这些重复都删了，把怎么用直接写进工具描述，不在系统提示词里说第二遍。

手动存记忆 → 自动记忆。 过去鼓励你用井号快捷键把要记的东西写进 CLAUDE.md。现在 Claude 会自己把跟当前工作、跟你相关的东西存进记忆，不用你手动记。

简单 spec → 富引用。 过去 plan 模式很依赖 markdown 写的计划，长项目就把规格存进代码库。现在模型能吃下复杂得多的引用了 - 不止是 markdown，可以是 artifacts 生成的 HTML，可以是一段代码、一套详尽的测试，甚至另一个代码库里的某个函数。还有一种叫 rubric、评分标准 - 帮模型摸清你在某个领域的偏好，比如什么才算好的 API 设计，再派验证 agent 拿着这套标准去核对。

六组看下来是一个方向：把“替模型做决定”的部分，尽量还给模型。

落到实处：四个每天要碰的地方

Thariq 把这些落到你每天要碰的几个地方，我觉得这段最实用。

系统提示词和产品强绑定，告诉模型它在哪个产品里、在干什么。用 Claude Code 你基本不用改它；但如果你在自建 agent，这里值得下功夫。

CLAUDE.md 保持轻。简单说清楚仓库是干嘛的，然后把篇幅主要花在代码库里的坑上 - 比如“类型全放在这一个文件里”。别写那些模型看一眼文件结构就知道的废话。细节交给渐进式披露，拆成 Skill 再引用过去。

Skills 当成轻量的向导，让模型需要时能找到信息，别写得太死 - 除非是特别关键的地方。长 Skill 就拆成多个文件。它最适合装那些属于你、你团队、你产品的独有经验和判断。

References 用 @ 引用文件。尽量用代码形式的引用，因为代码是模型最熟的语言 - 一个 HTML 的设计稿，通常比一段文字描述或一张截图管用得多。

实战：拿我自己的一组 Skills 来改

光讲原则有点虚，我拿自己的一个开源项目来试。这是我做视频用的一组 Skills，叫 boring-video-studio，按 orchestration、building-blocks、assets 分了三层，每个 skill 是一个 SKILL.md 加一个 references 文件夹。对着这几条新规则，我挑两处能改的。

第一处，渐进式披露。 我那个 blockframe-video 的 SKILL.md 有三百多行 - 从定题、格式、目录结构，到渲染、封面、章节化重建，全塞在一个主文件里。按渐进式披露的思路，主文件只该留“什么时候用它、大致骨架、委托给谁”，像格式配置表、项目目录结构、增量重建这些细节，该下沉到 references，用到再加载。好在这套 Skills 本来就有 references 的习惯，顺着往下拆就行。

第二处，是分寸。 我这几个 Skill 满屏都是“铁律”。文章说 Skills 别写太死，除非特别关键的地方 - 关键就在这个“除非”。有些铁律是真该留的硬性规定：比如财经视频那条 Skill 里约定的“数字必须核对官方原件”，封面那条里的“codex 会谎报保存路径”。这些恰恰是文章夸的、属于任务执行里的避坑指南，删了会出事。而另一些更像品味层面的硬话，完全可以交给模型判断。

所以这条原则的真正难点，不是“删掉所有硬规则”，而是分清哪些是该留的硬性规定、哪些是过度约束。有意思的是，我翻自己最近一次提交，正好在做这件事 - 把平台文案从写死的骨架，改成了占位符加 agent 判断。方向和文章说的是一样的，只是我当时没意识到这背后是同一条规律。

---

用一句话总结下吧：模型变强了，上下文工程的方向也跟着反了过来 - 从“拼命约束”变成“该删就删，给它判断的空间”。

Anthropic 还上线了一个 claude doctor 命令，在 Claude Code 里敲斜杠 doctor，能帮你自动给 Skills 和 CLAUDE.md 瘦身。如果你手里也有一堆写了很久、越堆越厚的 CLAUDE.md 和 Skills，这篇文章值得当成一次借口，回去删一删。

• 配套视频（YouTube）：https://youtu.be/FrAAxWbxSyE
• 原文（Thariq · X）：https://x.com/trq212/status/2080710971228918066
• 文中实战用到的开源 Skills 仓库：https://github.com/sugarforever/boring-video-studio