Claude 5 时代的新上下文工程规则：Anthropic 砍掉了 80% 的系统提示

原文来源：Claude by Anthropic — Anthropic 从 Claude Code 的系统提示中删掉了 80% 以上内容，并解释了如何将这些经验应用到你的上下文工程中。

上周，Anthropic 发布了一篇值得每个使用 Claude Code（或任何 Claude 5 系列模型）的开发者认真阅读的文章：Claude 5 时代的新上下文工程规则。

文章的核心信息非常直接——你以前学到的"最佳实践"，很多已经过时了。

Anthropic 的产品团队成员 Thariq Shihipar 在文章中说得很清楚：在 Claude Opus 5 和 Claude Fable 5 这样的新模型上，他们从 Claude Code 的系统提示中删掉了超过 80% 的内容，而编码评估指标没有任何下降。

这不是小修小补。这说明 Claude 5 的能力提升已经让旧的提示工程方法变成了束缚。

上下文工程的本质变了

当你给 Claude 发消息时，你写的提示只是它收到的上下文的一小部分。大部分上下文来自系统提示、Skills、CLAUDE.md 文件、记忆等来源。Anthropic 把这整套做法叫做上下文工程。

和提示不同，上下文是跨请求通用的，不能太具体。你不可能知道用户下一段提示会问什么，但你可以通过上下文告诉 Claude 它工作环境的"规矩"。

但问题来了：Claude 自己的能力强了之后，原来那些规矩反而变成了枷锁。

Anthropic 观察到，在他们内部使用 Claude Code 的过程中，有时候一条请求里有好几个互相矛盾的指令——"适当的时候写文档"和"不要加注释"同时出现。以前 Claude 需要花更多精力去判断哪个指令更重要，现在新一代模型可以直接根据上下文和你给的意图来做出合理判断。

从"给规则"到"让模型自己判断"

以前：给 Claude 写规则

现在：让 Claude 用判断力

最早的 Claude Code 需要非常严格的指令来避免最坏情况——比如删除文件。当时系统提示会写：

"默认不写注释。永远不要写多段落的文档字符串或多行注释块——最多一行短注释。除非用户要求，不要创建计划、决策或分析文档——直接从对话上下文工作，不要依赖中间文件。"

但这种做法有个硬伤：在某些场景下，这些规则反而是错的。用户可能有自己的文档偏好，复杂代码的某些部分确实需要多行注释块。在老模型上，不写这些规则，Claude 写的注释确实经常会出问题。

新模型不一样了。Anthropic 现在在系统提示里只写一句话：

"写出的代码要读起来像周围的代码：注释密度、命名风格、惯用写法都保持一致。"

听起来很简单对吧？但这就是新模型能理解的东西——不靠规则列表，而是靠上下文感知和判断力。

以前：给 Claude 例子

现在：设计接口

以前工具使用的第一原则是：给 Claude 提供如何使用工具的例子。Anthropic 发现，在新模型上，给例子反而让模型被限制在特定的探索空间里。

更好的做法是：设计好你的工具、脚本和文件的接口。工具的参数是什么？如何让它们更有表现力？

比如 Todo 工具，只要把 status 定义为枚举值（pending / in_progress / completed），Claude 就能理解怎么用了。再加上"一次只保持一个 in_progress 项目"的说明，就定义了期望的行为——根本不需要示例。

以前：把所有内容堆在前面

现在：渐进式披露

因为 Claude Code 聚焦编程，系统提示包含了关于代码审查和验证的详细信息。这些信息不是每次都需要，但需要的时候又至关重要。

现在 Claude Code 已经非常擅长渐进式披露——在正确的时机加载正确的上下文。验证和代码审查被移到了单独的 Skills 里，Claude 可以选择性调用。

渐进式披露不仅限于 Skills，工具也可以用。 有些工具使用"延迟加载"——Agent 必须先用 ToolSearch 搜索它们的完整定义才能使用。这让系统可以支持更多工具（比如 Task 工具），而不会在不需要时占用上下文。

这条原则也适用于你自己的 CLAUDE.md 和 Skill.md 文件。不要把这些文件做成已知实践的知识库——Claude 找不到的话就没用。更好的做法是创建一个分层结构，让 Claude 在需要的时候加载。

以前：重复说同一件事

现在：简洁的工具描述

早期的 Claude 模型有时候需要重复指令，或者更倾向于听从上下文窗口末尾的指令。这让系统提示里既要有工具本身的信息，又要有工具说明中的指令。

Anthropic 发现这些重复可以全部删掉——把工具使用说明放在工具描述里，而不是系统提示里。

以前：在 CLAUDE.md 里存记忆

现在：自动记忆

以前用户需要手动用 # 快捷键把信息保存到 CLAUDE.md。现在 Claude 会自动保存与工作相关的记忆。

以前：简单的 spec

现在：丰富的引用

在计划模式下，Claude Code 严重依赖 markdown 文件中的计划。把这些文件存为计划，Claude 可以在需要时引用。另一个类似的做法是把 spec 存在代码库里供 Claude 跨项目引用。

Anthropic 发现，Claude 现在可以处理越来越复杂的引用。除了简单的 markdown 文件，Claude 可以引用新的 artifacts 功能创建的 HTML 产物。Spec 可以是一个详细的测试套件，或者另外一个代码库里 Claude 需要移植的函数。评分标准（rubrics）则是另一种引用形式——通过动态工作流启动验证 Agent，用评分标准来判断你的"品味"（比如好的 API 设计应该是什么样的）。

如何应用到你的上下文中

把这些汇总起来，你的上下文应该怎么组织？

系统提示

系统提示与产品上下文紧密相关。它告诉 Claude 它在什么产品中运行、在做什么。对于 Claude Code，你大概率永远不会修改它。但如果你在构建自己的 Agent 框架，这是你应该投入时间的地方。

CLAUDE.md

保持 CLAUDE.md 轻量，简要描述你的仓库是做什么的。大多数 token 应该用在代码库中的特殊场景上（gotchas）。比如："类型定义集中在 types.ts 文件中，其他地方不要手写类型。"

避免写"显而易见"的东西——Claude 通过文件系统就能了解的信息不需要你写。如果有一些验证工作的独特说明，创建一个验证 Skill 然后在 CLAUDE.md 中引用它。

Skills

把 Skills 看成轻量级指南，让 Claude 在需要的时候找到信息。不要让它们过度约束，只对特别重要的领域做限制。对于长 Skills，尽可能使用渐进式披露——拆成多个文件。

参考文件

你可以用 @ 引用文件。引用让 Claude 可以访问当前计划的深度信息。这可以是 spec 文件、mockup、甚至完整的代码库。通常代码文件更好——用 Claude 非常熟悉的语言提供清晰、高保真的指令。比如一个 HTML mockup 通常比设计文字说明或截图效果好得多。

尝试简化

最后一步：检查你的系统提示、Skills 和 CLAUDE.md 文件，看看和 Anthropic 做的一样——能不能简化？

Anthropic 发布了一个新命令 claude doctor，可以帮你自动做这件事。在 Claude Code 中输入 /doctor 就能对 Skills 和 CLAUDE.md 文件进行优化。

核心启示

这篇文章的核心启示不是"AI 越强，人类越不重要"。恰恰相反：

Claude 越强，你越需要思考如何设计接口，而不是如何写指令。

从"教 Claude 怎么做"变成"让 Claude 理解你要什么"——这是上下文工程在 Claude 5 时代的关键转变。你不必再写一大堆"不要这样做"的规则来防止最坏情况，而可以专注于描述你想要的结果、你代码库的惯例、以及那些真正只有开发者才知道的特殊场景。

对于 Claude Code 用户：在终端中运行 claude doctor 来优化你的配置。对于在构建自己的 Agent 框架的开发者：重新审视你的系统提示，把那些新模型不再需要的约束删掉——大概率可以砍掉一大半。