Claude Code削减80%系统提示——Opus 5为何仍增长72%

引言

Anthropic最近介绍了Claude Code向其最新模型提供上下文方式的一次重大变革。

对于Claude Opus 5、Claude Fable 5以及其他高级Claude 5模型，该公司表示移除了此前用于引导旧模型正确运行的超过80%的系统提示内容。Anthropic还表示，这一精简并未导致其编码评估出现可衡量的性能损失。

这听起来像是一个直白的故事：更强的模型需要更少的详细规则。

然而，一位独立开发者陈诚（@chenchengpro）捕捉到了Claude Code为多个模型版本生成的输出上下文，并报告了一个令人惊讶的序列：

从Opus 4.8到Opus 5，测得的提示内容增长了约72%。

乍看之下，Anthropic"移除超过80%"的说法与开发者"增长72%"的结果似乎相互矛盾。

事实并非如此。

这两个数字使用不同的基准，描述了Claude Code转型过程的不同方面。Anthropic描述的是脱离老旧、高度规定的提示架构的转变。而开发者是在对Opus 5与特定捕获设置中Opus 4.8所使用的异常紧凑提示进行比较。

Claude Code确实移除了大量旧的指令框架。Opus 5随后获得了一套规模较小的新针对性约束，用于管控随着模型自主性增强而变得更加突出的行为。

Anthropic移除了超过80%的旧提示内容

Anthropic的官方解释始于许多智能体开发者都会认识到的问题：指令在堆积。

当早期模型反复出现某个错误时，产品团队就会添加一条规则。如果它写了不必要的注释，就添加一条注释规则。如果它创建了不必要的规划文档，就添加一条文档规则。如果它误用了某个工具，就添加工具使用示例。如果它未能验证工作成果，就再添加一条验证指令。

久而久之，系统提示就开始变得像一本一次只处理一个事件而拼凑起来的员工手册。

这种方法帮助了早期模型，但也引入了新的问题。

指令重叠造成摩擦

Claude Code接收的并非只有一条提示。其工作上下文可能包括：

• 产品系统提示
• 工具定义
• CLAUDE.md文件
• 规则
• 技能
• 记忆
• 用户指令
• 代码仓库文件
• 命令和工具的输出

当多层指令重复或相互略微矛盾时，模型必须花费推理精力来决定哪条指令应该占主导地位。

例如，某一层可能说要在适当时添加文档，而另一层则说除非明确要求，否则不要创建注释或文档。然后一个项目文件可能还会添加涵盖相同行为的第三条规则。

模型可能仍然得出正确的结果，但在编码任务甚至尚未开始之前，上下文就已经在做不必要的工作了。

更新模型可更多依赖局部判断

Anthropic 给出了一个涉及注释和文档的清晰示例。

旧版 Claude Code 指导使用了严格而详细的限制，旨在阻止低质量注释和不必要的计划文件。而更新后的指令则简洁得多：编写与周围项目风格一致的代码，包括其命名习惯、惯用风格和注释密度。

这一变化将决策依据从全局规则转向了局部证据。

系统不再告诉 Claude 注释总是不可取的，而是要求它检查仓库中现有的代码是如何传达意图的。

这便是精简提示背后的更广泛模式：

旧方法：
描述可能出现的各种错误，并预先禁止它们。

新方法：
提供产品角色、工具、边界和相关证据，
然后让模型在这些约束内自行判断。

Anthropic 报告称，删除旧系统提示中超过 80% 的内容并未导致其编码评估结果出现可衡量的下降。

这一结果并不意味着指令不再重要。它意味着有效的指令已经改变了。

上下文工程的新规则

Anthropic 的重新设计可以通过几个“过去与现在”的转变来概括。

这些变化不仅适用于 Anthropic 的内部系统提示。它们也影响着开发者应如何维护 CLAUDE.md、技能、工具和自定义代理框架。

保持 CLAUDE.md 专注于项目特有的事实

CLAUDE.md 文件在 Claude Code 会话开始时被加载。这使得它非常适合放置 Claude 需要持续了解的仓库信息。

良好的内容包括：

• 无法从代码中推断出的架构决策。
• 所需的构建和测试命令。
• 仓库特有的约定。
• 重要目录和所有权边界。
• 项目需要或禁止使用的库。
• 不明显的安全或部署约束。

不太有用的内容包括：

• Claude 已经了解的通用建议。
• 仅偶尔使用的冗长操作步骤。
• 在包文件或源代码中直接可见的事实。
• 在工具、技能和用户提示中重复的相同指令。
• 每次请求都会消耗上下文的大型示例。

Claude Code 的当前文档建议保持 CLAUDE.md 简洁，并将程序性或参考密集型材料移入按需加载的技能文件中。

需求。

一个集中的文件可能如下所示：

# 项目指南

- 所有包管理命令均使用 pnpm。
- 在报告代码变更完成前，运行 `pnpm test` 和 `pnpm lint`。
- 公共 API 定义在 `packages/sdk` 下；避免破坏性更改。
- 数据库迁移需包含对应的回滚文件。
- 请勿直接编辑 `src/generated` 下的生成文件。

无需详尽解释通用的软件工程行为。

将长步骤迁移至技能

技能将可复用的指令打包在 SKILL.md 文件中。当使用该技能时，才会加载其完整内容，而不会占用每个无关任务的上下文。

这使得技能更适合承载以下工作流程：

• 拉取请求审查。
• 发布准备。
• 安全检查。
• 前端验证。
• 数据库迁移。
• 事件调查。
• 文档发布。

一个最小化的审查技能可结构如下：

description: 审查拉取请求的正确性、回归问题及缺失的测试。

# 拉取请求审查

1. 阅读完整差异及受影响的测试。
2. 优先识别具体缺陷，而非样式偏好。
3. 运行最小的相关测试套件。
4. 检查公共行为或兼容性是否改变。
5. 按严重程度报告发现，并附上文件引用。

该步骤仅在审查工作开始时可用，但不会给仅要求 Claude 修改变量名的请求增加负担。

这是一种渐进式披露：在关键节点提供适当的上下文。

移除重复指令

通常，每条指令应只存在于一个权威位置。

例如：

• 产品级行为属于系统提示。
• 项目级事实属于 CLAUDE.md。
• 可复用步骤属于技能。
• 工具特定要求属于工具定义。
• 确定性执行属于钩子、权限、测试或脚本。

在每个层级重复相同的规则并不一定会增强其效力，反而可能增加上下文大小、引入措辞差异，并增加后续维护难度。

在添加另一条指令前，请先问自己：

1. 这一点是否已在其他地方表达？
2. Claude 能否从代码库中推断出来？
3. 这是事实、步骤还是硬性执行要求？
4. 是否需要在每次请求时加载？
5. 测试或钩子是否比文本描述更可靠地执行该规则？

设计更好的工具，而非编写更多示例

早期的提示工程指南通常建议提供多个工具使用示例。

Anthropic 认为，示例可能会限制高级模型遵循演示路径。模型可能模仿样本，而非为当前任务选择更优的参数或工具组合。

设计良好的工具应通过其界面清晰传达使用方法：

• 明确的参数名称。
• 准确的描述。
• 显式的可选字段。
• 有用的枚举值。
• 可预测的输出。
• 可操作的错误消息。

例如，如下枚举值：

{
"status": "pending | in_progress | completed"
}

比冗长的段落更直接地传达了有效的状态转换规则。

包含几个固定的示例。

当格式或边界行为可能含糊不清时，示例仍然有用。这一变化并非"永远不要用示例"，而是"不要用示例来替代设计良好的接口。"

提供可执行的参考

新型号Claude模型可以直接根据更丰富的参考开展工作。

开发者无需用文字描述每项需求，而是可以提供：

• 现有代码。
• 测试用例。
• 一个失败的命令。
• 一个HTML原型。
• 一张截图。
• 一个模式。
• 一个设计产物。
• 一个基准测试脚本。
• 一个样例输入和预期输出。

一个可执行的测试通常比几段说明"实现应该正确"的文字更能明确地定义成功标准。

这将上下文工程从编写大型操作手册转变为设计更好的工作环境。

独立抓取发现72%的回弹

在Anthropic宣布减少80%后，开发者陈成报告测试了Claude Code实际为多个Opus模型发送的内容。

他将CLI重定向到本地服务器并记录了出站请求内容。他公布的字符数如下：

Opus 4.7：15,225个字符
Opus 4.8：4,467个字符
Opus 5：7,694个字符

这些数字显示了三种不同的比较：

因此，这次抓取到的Opus 5提示词比Opus 4.8长得多，但大约只有Opus 4.7的一半长度。

这些是字符数，而非令牌数。它们也只代表一个被抓取的Claude Code设置，而非每个请求的通用规范。

Claude Code可以根据工具、配置、功能和产品状态动态组合上下文。确切的传输内容可能随版本和环境而变化。

为何80%和72%这两个数字都可能正确

一旦区分了不同的基准，这个明显的矛盾便不复存在。

Anthropic的数字描述的是架构清理

Anthropic表示，与旧式的指令密集型设计相比，它删除了高级Claude 5模型使用的系统提示词中超过80%的内容。

这个数字涉及在向更新的上下文工程架构过渡期间被移除的遗留提示词的数量。

它并非声称每个Opus 5请求按字符数计算都比每个Opus 4.8请求短80%。

开发者的数字比较的是两个相邻的抓取结果

72%这个数字比较的是被记录的Opus 5请求与开发者抓取到的异常小的Opus 4.8请求。

Opus 4.8似乎是那种三个模型比较中的最低点。而Opus 5则

增加了针对性指导，同时整体长度仍比旧版Opus 4.7路径短得多。

因此，这两种说法可以并存：

旧版提示架构 → 高级模型提示：
整体大幅缩减。

Opus 4.8 捕获 → Opus 5 捕获：
最小测量版本基础上的部分增长。

Claude Code 似乎维护着不同的提示路径

开发者的检查还报告称，Claude Code 的实现中包含两套提示路径。

一个路由函数为较旧的模型标识符选择更详细的旧版提示，为较新的模型选择简化的提示。

据报告的逻辑，旧版Opus、Sonnet、Haiku 和 Claude 3 系列等模型位于详细提示路径上，而 Opus 4.8、Opus 5、Fable 5 以及其他较新模型则使用更短的架构。

这个路由细节来自第三方检查，而非 Anthropic 官方的架构文档。

然而，这与 Anthropic 的公开解释相符：更强的模型可以在较少的规范性框架下运行，而较旧的模型可能仍然需要新模型能从上下文推断出的显式约束。

为什么 Opus 5 需要新的针对性指导

Claude Opus 5 在长期自主工作方面的能力比早期的 Opus 模型更强。这种能力引入了在大任务中有用、但在小任务上昂贵或分散注意力的行为。

Anthropic 官方的 Opus 5 提示指南强调了几个可能需要调整的方面：

• 回答长度和冗长程度。
• 面向用户的进度更新。
• 书面交付物的长度。
• 任务范围。
• 过度验证。
• 子代理委托。
• 自我修正。

据报告的开发者差异分析，围绕交付工作和处理修正，出现了大量新内容。

确切的私有文本不应被视为官方的公开规范，但这些类别与 Anthropic 已发布的 Opus 5 指南高度一致。

进度更新可能变得过于频繁

对于长时间的迁移或仓库范围的调查，进度报告是有帮助的。

对于小改动来说，频繁的叙述会增加延迟和令牌消耗，而不会改善代码。

一个有用的代理策略需要区分这两种情况：

在长时间、多阶段的工作中报告进度，当更新有助于用户了解状态或做出决策时。
不要叙述每一个例行的工具调用。

目标不是沉默，而是相称的沟通。

更强的模型可能过度扩展任务范围

一个高级编码代理在完成所请求更改的同时，可能会注意到相关的问题。

有时这种主动性是有价值的。其他时候，它可能将一个简单的请求演变成用户未批准的广泛重构。

对于 Opus 5，任务边界变得更为重要，正是因为模型的能力更强。

更擅长寻找额外工作。

清晰的请求可以这样表述：

修复报告的问题及直接受影响的测试。
不要重构无关模块或扩展公共API。

边界条件定义了"完成"的含义，无需规定每个实现步骤。

子代理可能增加成本

Anthropic表示，Opus 5比之前的模型更倾向于使用子代理。

当工作真正独立且规模足够并行处理时，委派是有价值的。当任务可以通过少量工具调用直接完成时，委派反而低效。

官方指南建议提供明确条件或确定性限制。

实用的指令如下：

仅将子代理用于规模较大且独立的工作流程。
不要创建子代理来重复或验证你可以直接完成的工作。
保持并发代理数量较少。

这能在不禁用有用功能的前提下控制成本和时间。

重复自我修正可能造成浪费

Opus 5设计用来发现并修复自身的许多错误。

反复要求"双重检查所有内容"、"再次验证"或"使用另一个代理重新验证"的提示，会叠加模型的本能行为。

Anthropic表示，移除冗余的验证指令可以在不降低质量的情况下减少无用token消耗。

验证仍然至关重要，但应基于具体证据：

• 运行相关测试。
• 编译项目。
• 检查渲染页面。
• 将输出与规范对比。
• 检查最终差异。

低效的模式是在客观检查已经通过后，要求额外的抽象反思。

开发者现在应如何调整

官方指南与独立测试指向了相同的实践教训：上下文应围绕功能组织，而非因顾虑堆积。

1. 审查完整上下文栈

检查所有可能影响Claude的环节：

• CLAUDE.md
• 规则
• 技能
• 工具描述
• 钩子
• MCP服务器指令
• 用户提示
• 代理框架中的自定义系统提示

查找重复、冲突、过时及过于宽泛的指令。

1. 仅在CLAUDE.md中保留非显而易见的项目规则

删除Claude能从源文件、包清单或标准规范中直接获取的信息。

保留否则不可见的决策内容。

1. 将流程转移到技能中

如果某部分描述的是可重复的序列而非固定事实，将其转化为技能。

这样能缩小默认上下文的规模，并使工作流程可复用。

1. 将工具说明放入工具内

不要在系统提示、CLAUDE.md和每次用户请求中重复工具的参数规则。

为工具提供表达清晰的架构和准确描述。

1. 用测试和引用替代冗长描述

尽可能提供定义成功的实际产物。

失败的测试、原型、架构或预期输出，比描述"结果应像什么"的长篇大论更精确。

1. 为Opus 5的主动行为设定边界

对于小型任务，明确：

• 允许的范围。
• 是否合理使用子代理。
• 如何

大量进展叙述是有用的。

• 需要什么验证。
• 代理何时应停止。

不要通过恢复庞大的通用手册来补救。

1. 运行 Claude Code 的诊断工具

Anthropic 表示，当前的最佳实践已纳入 Claude Code 的医生工作流。

在 shell 中，运行：

claude doctor

在 Claude Code 内部，运行：

/doctor

诊断可以检查安装、配置、MCP 服务器和上下文使用情况。当前版本还可能帮助识别过大或无效的上下文配置。

应审查其建议，而非盲目删除项目指导。

一个前后对比的上下文示例

过载的配置

CLAUDE.md（过载示例）

• 在编辑前始终检查仓库。
• 始终编写干净的代码。
• 始终测试每个更改。
• 绝不添加不必要的注释。
• 绝不添加不必要的文件。
• 完全按照下面示例所示使用测试工具……

后续还包含数页审查、发布、测试和工具说明。

这个文件包含通用的期望、可重复的流程以及在不同任务中适用性不均的工具文档。

聚焦的配置

CLAUDE.md（聚焦示例）

• 使用 pnpm；此仓库不支持 npm 或 yarn。
• 在 packages/sdk 下需要公共 API 兼容性。
• 在完成代码更改前运行 pnpm test 和 pnpm lint。
• 发布步骤位于 /release-check 技能中。
• 安全审查步骤位于 /security-review 技能中。

较小的文件保留了项目特定的信息，并将条件性流程委托给技能。

这就是提示缩减的实际意义：更少的永久指令，更好的结构化上下文。

测量结果并不能证明什么

报告中的字符数很有用，但不应过度解读。

它们并不能证明：

• 每个 Opus 5 请求始终包含恰好 7,694 个字符。
• 系统提示长度直接预测编码质量。
• 较短的提示自动更好。
• Anthropic 的 80% 数据是假的。
• Opus 5 在每个会话中需要的总上下文比 Opus 4.8 多 72%。
• 捕获的文本包含了产品使用的每个动态指令。

提示长度只是变量之一。

指令的质量、上下文的顺序、提示缓存、工具设计、技能、仓库证据以及模型能力都会影响结果。

简洁的提示可能模糊；较长的提示可能精确。目标不是最小的字符数，而是可靠地为模型提供所需信息和边界的最小的上下文。

对代理构建者的更大启示

随着模型的改进，指令设计从微观管理转向治理。

较老的代理通常需要关于如何执行每个步骤的详细描述。更强的代理可以从工具和证据中发现更多方法。

这并没有消除人类的角色。它改变了人类努力最有价值的地方。

代理构建者应减少列举每个期望行为的时间，而更多地定义：

• 可用工具。

• 权限边界。

• 事实来源。

• 成功标准。

• 范围限制。

• 成本控制。

• 升级路径。

• 确定性检查。

模型在每个动作上需要更少的建议，同时对其可以做什么、必须证明什么以及何时停止，需要更清晰的权限。

常见问题

Anthropic 真的删除了 Claude Code 超过 80% 的系统提示吗？

Anthropic 官方表示，已删除用于 Claude Opus 5 和 Claude Fable 5 等高级模型超过 80% 的系统提示内容。该公司还表示，此更改未导致其编码评估出现可衡量的损失。

为什么捕获的 Opus 5 提示比 Opus 4.8 长 72%？

72% 这一数字以 Opus 4.8 为基准。在开发者的捕获中，Opus 4.8 的提示异常紧凑，仅 4,467 个字符，而 Opus 5 在接收额外针对性指导后测得 7,694 个字符。

15,225、4,467 和 7,694 这些数字是 Anthropic 的官方数据吗？

不是。这些数据由一位独立开发者报告，他将 Claude Code CLI 重定向至本地服务器并检查了出站请求。Anthropic 尚未将这些字符数公布为固定或标准总数。

Opus 5 的提示仍然比 Opus 4.7 的提示短吗？

在报告的捕获中，是的。尽管 Opus 5 的 7,694 字符提示比 Opus 4.8 长，但仍比 Opus 4.7 的 15,225 字符提示短约 49.5%。

CLAUDE.md 中应保留什么？

保留模型无法从仓库中可靠推断出的项目特定事实和规则。将冗长、有条件的流程移至技能中，并移除通用或重复的指导。

为什么长工作流应成为技能？

技能的详细内容在需要时加载，而非占用每个请求。这支持渐进式披露，并防止无关会话在其默认上下文中携带审查、发布或部署流程。

Opus 5 是否需要比旧模型更严格的提示？

它需要不同的提示。Anthropic 建议控制冗长性、进度更新、任务范围、过度验证、子代理生成和自我纠正，当这些行为会增加不必要的成本或时间时。

如何检查我的 Claude Code 上下文是否过大？

在 shell 中运行 claude doctor，或在 Claude Code 内运行 /doctor。同时手动检查 CLAUDE.md、技能、工具描述和重复指令，因为自动诊断无法确定每个项目特定的要求。

相关工具

• Claude Code：Anthropic 的代理编码环境，用于仓库探索、编辑、测试和自动化。
• Claude Code Skills：将可重复使用的工作流和参考资料打包到 SKILL.md 文件中，在需要时加载。
• Claude Code 配置调试器：帮助诊断指令、技能、钩子、设置或 MCP 服务器未生效的原因。
• Claude Opus 5 提示指南：针对范围、冗长性、进度、子代理、验证等方面的官方模型特定指导。

更正内容。

• Model Context Protocol：一种开放标准，用于将智能体系统与外部工具和数据源连接。

相关链接

• Claude 5 模型上下文工程的新规则：Anthropic 关于 80% 缩减及其更新后上下文工程原理的官方说明。
• 提示 Claude Opus 5：控制新模型主动性和智能体行为的官方指南。
• 提示最佳实践：Anthropic 关于指令、工具、推理、智能体系统和迁移的广泛参考。
• 使用技能扩展 Claude Code：创建和组织可复用的按需上下文的官方说明。
• Claude Code 功能指南：解释何时使用 CLAUDE.md、技能、钩子、子智能体及相关控制。
• 开发者测量帖子：报告中的系统提示字符数所引用的第三方截图。

总结

Anthropic 的 80% 缩减与开发者报告的 72% 反弹描述了不同的对比。Claude Code 移除了大量针对高级模型的遗留且高度规定性的指令。捕获的 Opus 5 提示随后相对于极其紧凑的 Opus 4.8 版本增加了针对性指导。

报告的 Opus 5 提示长度仍然约为捕获的 Opus 4.7 提示的一半。其新增的指导与 Anthropic 公开指出的 Opus 5 行为一致：更多的进度叙述、更广的任务范围、更频繁的子智能体委托、更长的交付物以及重复的自我纠正。

对于开发者而言，有用的回应不是追求最短的提示。保持 CLAUDE.md 聚焦，将条件工作流移至技能中，消除重复，改进工具界面，提供可执行的参考，并为范围、成本和完成设定明确的界限。

新的上下文工程规则不是“不惜一切代价说更少的话”，而是“在所属的层级上，只加载模型所需的指导。”