删除80%系统提示词后的上下文工程新规则

来源：X @trq212

2026 年 7 月，Anthropic 工程师 Thariq Shihipar 发布了一篇面向 Claude 5 系列模型的上下文工程指南。其中有一项声明比任何基准都更显眼：为了让 Claude Opus 5 和 Claude Fable 5 发挥更好，团队将 Claude Code 的系统提示词删掉了超过 80%，而自家编码评测”没有可测量的损失” ^[0,1,6]。开发社区随后将其解读为一次规则重写 ^[2]。需要弄清楚的是：删掉的内容是什么、为什么删掉后没有损失，以及我们自己该怎样照做。

删除的是什么：给弱模型的补丁

Anthropic 的总结很直白：“我们发现，我们过度约束了 Claude Code——无论系统提示词，还是我们的 CLAUDE.md 文件和 skills” ^[0,2]。内部使用记录中，同一个请求里会出现相互矛盾的指令：“适当地留下文档”和”不要添加注释”一起出现 ^[0,2]。模型要先理顺这些重叠矛盾的约束，才能开始干活 ^[0]。

旧提示词的典型条目是强硬的禁令：“写代码时默认不写注释。绝不写多段 docstring 或多行注释块——最多一行。除非用户要求，不要创建规划、决策或分析文档” ^[0]。这类护栏是为了给旧模型兜底：没有它们，旧模型写的注释在很多情况下会出错 ^[0]。新提示词只保留一条原则：“写出像周围代码一样可读的代码：匹配它的注释密度、命名和惯用法” ^[0]——把密度、命名这些具体决定交还给模型的判断力 ^[0]。

规模上，这次删减把系统提示词从大约 2,686 词压到 514 词（关闭记忆时）^[7]。但口径要清楚：80% 是 Anthropic 基于自家编码评测自报的数字，原文没有公布具体基准，也没有分解哪些任务类别保持住了、哪些变弱了 ^[1,9]。另一个常被忽略的细节是，被删的是产品级系统提示词——它服务所有用户、所有代码库，天然只包含公共内容，所以删掉它没有损失，并不能推出”你自己的私有知识也该按 token 数砍” ^[10]。那 80% 从一开始就没承载多少信息，它只是给弱模型的补丁 ^[10]。

六大范式转变

指南将旧做法与新做法整理成六组对照 ^[0,6]。

规则 → 判断。上面注释的例子已经足以说明这一点：从绝对化禁令转向语境化原则 ^[0]。新模型的判断力更强，没有显式规则也能处理好这些决定 ^[0]。

示例 → 接口设计。过去工具用法的首要规则是”给例子”；在新模型下，例子会把模型锁进特定的探索空间 ^[0]。替代做法是设计工具接口本身——参数怎么表达、枚举怎么定义。例如 Todo 工具的 status 只枚举 pending、in_progress、completed 三种状态，以此暗示模型该如何使用；“同一时刻只保持一个 in_progress”这条约束则定义了期望的行为 ^[0]。

全量前置 → 渐进披露。旧系统提示词把代码审查、验证的详细流程全部放进了初始上下文 ^[0]。现在这些流程被拆成独立的 Skills，由模型按需调用；部分工具改为”延迟加载”，模型必须先用 ToolSearch 搜到完整定义才能使用 ^[0]。同样的思路适用于你自己的 CLAUDE.md 和 Skill.md：与其把所有实践堆进一个中央仓库，不如维护一棵按需加载的文件树 ^[0,21]。

重复 → 简单工具描述。早期模型有时需要重复指令，而且更容易听从上下文窗口末尾而不是开头的指令，所以系统提示词中要同时包含工具的引用和说明 ^[0,6]。团队发现这些重复可以删掉，把工具的使用说明放进工具描述本身 ^[0]。

CLAUDE.md 记忆 → 自动记忆。早期鼓励用户用 # 快捷键把信息写进 CLAUDE.md ^[0,6]。现在 Claude 会自动保存与工作相关的记忆 ^[0]。

简单 specs → 富引用。Plan 模式早前依赖 markdown 计划文件 ^[0]。现在 Claude 能处理复杂得多的引用：HTML artifacts、以测试套件形式存在的规格、另一个代码库里可移植的函数，以及用来验证品味的 rubrics——rubrics 可以驱动动态工作流、拉起验证 agent 来检验”好的 API 设计长什么样” ^[0]。

渐进披露的机制：工具延迟加载

渐进披露不是一句口号，它在 Claude Code 中落地为可量化的机制。MCP 工具描述一旦超过约 1 万 token 的阈值，工具就被标记为延迟加载（defer_loading）；模型收到的只有一个 ToolSearch 工具，取代了逐个工具定义。需要某个工具时，模型用关键词检索，每次只加载 3–5 个相关工具（约 3K token）^[26]。官方文档的定位是：把 agent 扩展到数千个工具，按需发现和加载 ^[34]。

数字能说明它为什么必要：ToolSearch 让工具 schema 的 token 占用减少 85% ^[30]；仅 GitHub 的 MCP server（91 个工具）就要吃掉约 4.6 万 token，约占 Claude Opus 上下文窗口的 22% ^[29]。上下文是有限资源，模型有”注意力预算”，每多一个 token 都在消耗这份预算，且收益边际递减 ^[53]。工具定义只是开始，社区已有人在提议把同样的”先注册元数据、按需加载”模式推广到 skills、MCP 连接、规则和指令 ^[30]。

自己的上下文怎么改

系统提示词：它与产品上下文强绑定，告诉模型自己在什么产品里、在做什么。Claude Code 用户几乎不会改它；但如果你在自建 agent harness，这才是最值得投入的地方 ^[0]。

CLAUDE.md：保持轻量。简要说明仓库的用途，把大部分 token 花在代码库的 gotchas 上——比如”类型集中放在一个单体文件里，别放别处” ^[0]。不要写 Claude 一看文件系统就知道的”显然之事” ^[0]。细节用渐进披露：若有独特的验证要求，就建一个验证 Skill，从 CLAUDE.md 引用它 ^[0]。

Skills：把它当轻量导航，让 Claude 需要时能找到信息 ^[0]。除非领域高度重要，否则避免过度约束 ^[0]。长 Skill 尽量拆成多个文件 ^[0]。Skills 最该编码的是你、你的团队、你的产品特有的观点和最佳实践 ^[0]。

References：用 @mention 文件作为引用，让 Claude 查阅当前计划的深入信息 ^[0]。优先选代码形式的文件：代码是 Claude 最熟悉的语言，一个 HTML mockup 通常比一段设计描述或截图效果更好 ^[0]。

如果不想手动做这些，指南里已把最佳实践打包进 claude doctor：在 Claude Code 里运行 /doctor，它会自动帮你把 skills 和 CLAUDE.md 调整到合适的体量 ^[0,21]。内置的 /doctor 会一次性检查安装、配置、MCP 与上下文，列出可疑项 ^[18,19]。

边界：删减不是万能药

自报口径之外，更应警惕的是把这次删减误解为”提示词不重要”。被删的是产品级公共提示词，你的 CLAUDE.md 里那些只属于自己团队的私有约定不在此列 ^[10]。“把判断交给模型”在业余项目和受监管的代码库里含义完全不同——后者对”判断”的要求恰恰是精确可审计 ^[1]。指南自己的建议也是灰度推进：先在非核心模块尝试简化 CLAUDE.md 和系统提示词，观察边界情况，再逐步建立对模型判断力的信任 ^[0]。