结论先行
没有严格的逻辑矛盾，但存在明显的统计口径错位，以及值得警惕的营销表达张力。
Anthropic 的窄口径主张——“面向 Opus 5、Fable 5 等前沿模型，Claude Code 的核心系统提示词减少了 80% 以上”——有独立测量提供方向性支持。
但如果把这句话理解成“Claude 的完整首轮上下文、上下文占用或 token 成本减少了 80%”，现有证据并不支持。
两份材料摆在一起，视觉冲击很强：
| 材料 | 表面信息 |
|---|---|
第三方仓库中的 OPUS-5.md |
约 20 万字符，看起来像一份极其庞大的“系统提示词” |
| Anthropic 官方文章 | 宣称针对 Opus 5、Fable 5 等模型，删除了 Claude Code 系统提示词的 80% 以上 |
如果默认两者描述的是同一个产品、同一种数据、同一个统计边界，那么当然像是矛盾。
问题恰恰在于：这三个前提都不成立。
- Claude.ai 不等于 Claude Code
- 核心 system prompt 不等于完整运行时上下文
- 20 万字符不等于 20 万 token
Anthropic 原文的主语和限定条件非常明确：
“We removed over 80% of Claude Code’s system prompt for models like Claude Opus 5 and Claude Fable 5…”
这句话只声称：
- 对象是 Claude Code；
- 适用于 Opus 5、Fable 5 这类较新的前沿模型；
- 减少的是 Claude Code 的 system prompt；
- 官方编码评测没有观察到可测量的能力损失。
它没有声称：
- Claude.ai 网页版的全部启动上下文减少了 80%；
- Claude Code 发给模型的完整请求减少了 80%；
- Tool schemas、Skills、Memory、
CLAUDE.md和会话历史都减少了 80%； - 用户实际可用的上下文窗口增加了 80%；
- 所有 Claude 模型都使用同样短的提示词。
官方文章描述的实际工程动作包括：
- 删除大量面向旧模型的规则、反例和“不要做什么”列表；
- 减少依靠大量 few-shot 示例来约束前沿模型；
- 将通用验证流程移入按需调用的 Skills；
- 将工具专属说明放进工具描述；
- 通过 ToolSearch 延迟发现或加载工具；
- 更多依赖新模型自身的判断能力。
所以更准确的转述是：
Anthropic 缩小了常驻的核心行为脚手架，并把一部分信息转移到更合适、可能按需加载的上下文组件中。
这是一项上下文架构调整，不等于“所有提示内容凭空消失了 80%”。
对该第三方文件按结构进行拆分后，得到以下结果：
| 内容区域 | 字节数 | 占比 |
|---|---|---|
| 核心行为、安全、产品和表达风格 | 22,880 | 11.3% |
| 长期记忆政策及大量示例 | 47,356 | 23.4% |
| 结束对话规则 | 3,192 | 1.6% |
| Artifact 持久化 API | 3,295 | 1.6% |
| Connectors 与历史聊天 | 10,037 | 5.0% |
| 文件、计算机、Artifacts、可视化 | 18,167 | 9.0% |
| Web、图片搜索及版权规则 | 23,749 | 11.7% |
| 工具描述与 JSON Schema | 55,670 | 27.5% |
| 用户配置、Skills、环境等动态附加块 | 18,416 | 9.1% |
| 合计 | 202,762 | 100% |
测量说明
- 以上为 UTF-8 文件字节数和人工结构分区，不是 Anthropic 官方分类。
- 文件约 2,049 行、29,011 个空白分隔字符串。
- 根据文本和 JSON 的混合结构，只能粗略估计为约 4.5 万至 5.5 万 token。
- 因此，“20 万字符”不能传播成“20 万 token”。
真正接近“核心模型行为提示”的部分约占 11%。其余大部分是：
- Memory 政策和示例；
- 工具定义及参数 schema；
- 搜索、连接器、文件和 Artifact 能力；
- Skills、用户画像和动态环境配置；
- 产品运行时说明。
文件中还明确包含面向 chat/web/mobile 产品的描述。它更接近 Claude 消费者聊天产品某种配置下的完整启动上下文转录，而不是 Claude Code 的精简核心提示词。
因此，将其称为“Claude Opus 5 的 20 万字符秘密核心系统提示词”并不严谨。更准确的名称是：
某次 Claude.ai 会话中，围绕 Opus 5 拼装的运行时上下文或 prompt envelope。
业界讨论经常在没有声明口径的情况下，混用下面三个概念。
主要包括：
- 模型身份；
- 通用工作方式；
- 安全和权限边界；
- 表达风格；
- 产品级行为要求。
这部分可能只有几千到一两万个字符。
只计算 API 请求里被标记为 system 的消息块。
工具通常放在独立的 tools 字段中，因此从请求协议看，“工具不是 system prompt”。
可能包括：
- 核心 system；
- 工具说明和 JSON Schema；
- Skills、Agents 目录；
- Memory 和用户画像；
- 项目
CLAUDE.md； - 动态 reminders 与环境元数据；
- 对话历史和工具返回结果。
Anthropic 的工具文档指出，启用工具时，系统会根据工具配置、工具定义和用户提供的系统提示构造特殊提示。这意味着：
- 从 API 字段和产品统计角度，
system与tools可以分开； - 从模型注意力和上下文占用角度，它们都会成为模型需要处理的输入。
参见 Anthropic：How to define tools。
可以把总上下文粗略表示为：
完整模型上下文
= 核心系统指令
+ 工具描述与 schemas
+ Skills / Agents
+ Memory / 用户画像
+ 项目级说明
+ 动态环境信息
+ 对话与工具历史
官方的“减少 80%”主要描述第一项；第三方文件接近展示整个加法结果。
于是，10k、27k、139k、203k 字符的“系统提示词”可以同时出现在讨论中，而各方未必都在造假——他们可能只是在使用完全不同的分母。
一项独立实验在同一台机器上捕获不同时期的 Claude Code 提示，并只统计 Anthropic 提供的指令正文，排除工具定义、项目 CLAUDE.md 和会话字段。
其结果为：
| 统计方式 | 旧版本 | 新版本 | 缩减幅度 |
|---|---|---|---|
| 新版本关闭 Memory | 2,686 词 | 514 词 | 约 81% |
| 两边均排除 Memory | 1,918 词 | 514 词 | 约 73% |
| 两边均计入 Memory | 2,686 词 | 830 词 | 约 69% |
来源：phuryn / claude-code-system-prompt-shrink
这组数据说明：
- 大幅缩减基本可信；
- 80% 并非毫无证据；
- 具体是 69%、73% 还是 81%，取决于 Memory 和迁移内容如何记账；
- 它仍然不能证明完整请求也缩减了 80%。
实验还观察到，不同模型会收到不同版本的提示：较旧模型保留较详细的行为脚手架，前沿模型使用更短、更依赖模型判断的配置。
Claude Code 团队成员在 Simon Willison 的采访中也确认：
- 不同模型使用不同系统提示；
- 80% 缩减主要针对前沿模型；
- 较旧模型仍保留更完整的提示；
- 外部评测和内部评测都无法覆盖 100% 的行为。
参见 Simon Willison：Claude Code team interview notes。
因此，最稳妥的事实判断是：
“核心常驻行为指令减少约 70%～80%”有方向性证据支持；“完整上下文成本减少 80%”没有。
另一个第三方 Claude Code Opus 5 提取文件约为 138,750 字节。按其结构粗分：
| 内容 | 占比 |
|---|---|
| 核心系统提示 | 7.5% |
| 动态会话上下文 | 1.0% |
| Agent 目录 | 1.8% |
| Skills 目录 | 4.0% |
| 工具描述与 schemas | 85.7% |
这份第三方材料同样不能视为官方、普适的固定配置，但它揭示了一个重要结构：
核心提示可以很短，完整请求仍然可以很大，因为工具定义可能占据绝大部分。
一项通过代理观察 Claude Code 实际请求的实验也得到相似方向的结果：在特定版本和配置下，首个请求在用户正文之前已约有 32.8k tokens，其中约 24k 来自工具定义。
来源：Systima：Claude Code vs OpenCode token overhead
该实验的原始捕获未完全公开，而且结果会受模型、版本、工具、MCP 和功能开关影响，因此不适合作为所有用户的固定数字。但“工具 schema 可能比核心行为提示大得多”这一方向，与其他提取结果一致。
另一个长期跟踪 Claude Code 编译产物的项目则整理出了 500 多个提示片段，覆盖条件式系统片段、内置工具说明、Agent 提示和内部辅助提示。这里同样必须注意：源码或目录中存在的提示总量，不等于每一次请求都会同时加载的提示量。
来源：Piebald-AI / claude-code-system-prompts
Prompt caching 也不能完全消除这个问题：
- 缓存可以降低重复前缀的价格和预填充延迟；
- 被缓存的内容通常仍占据上下文窗口；
- 内容过多仍可能稀释注意力，形成 context rot。
Anthropic 的观点并不是“提示词越短越好”，而是：
对能力足够强的模型，不要再用大量规则模拟它已经具备的判断能力。
旧式长提示通常包含：
- 每一步应该怎么做；
- 大量“不要做 X”；
- 大量正例和反例；
- 何时验证以及验证几次；
- 如何叙述过程；
- 遇到错误如何自我纠正；
- 重复的工具使用说明。
这些规则可能曾经用于弥补旧模型能力不足，但放到更强的新模型上，可能产生反作用：
- “必须验证”变成反复验证；
- “充分解释”变成过程直播；
- 大量示例把模型锁定在旧工作流；
- 多层禁令互相冲突，使模型保守或犹豫；
- 工具规则重复出现，挤压项目和任务信息。
Anthropic 的 Opus 5 提示指南也指出，新模型可能出现新的过度行为：
- 过度验证；
- 扩大任务范围；
- 过度委派子代理；
- 详细叙述自我修正；
- 输出长于用户所需。
官方因此建议用短而明确的范围、验证、叙述和委派约束来修正这些倾向。参见 Anthropic：Prompting Claude Opus 5。
这解释了为什么新提示可能经历这样的变化：
删除旧模型所需的大量通用脚手架
↓
依赖前沿模型自己的判断力
↓
针对新模型特有的失败模式，添加少量短规则
所以“删除 80%”和“后来又增加几条规则”也不矛盾。提示工程不是单向删减，而是持续寻找更高的信息密度。
这一派认为，长提示不一定提供更强约束，反而可能：
- 稀释真正重要的信息；
- 增加规则冲突；
- 让模型过拟合示例；
- 降低任务和项目级信息的权重；
- 增加 context rot。
Anthropic 早期的上下文工程文章主张寻找“最小但高信号”的上下文。这里的 minimal 并不等于字符数最少，而是每一段信息都值得占用模型注意力。
来源：Anthropic：Effective context engineering for AI agents
LangChain 将常见上下文工程策略概括为：
- Write：写入外部记忆；
- Select：只选择当前所需信息；
- Compress：压缩历史和观察；
- Isolate：利用子代理或独立空间隔离上下文。
来源：LangChain：Context Engineering for Agents
这派质疑的不是架构方向，而是统计表达：
从核心 system 删除
→ 放进 tool description
→ 放进 Skill
→ 放进 Memory
→ 需要时再加载
从系统设计看，这是合理的 progressive disclosure；但从总成本看，不能把所有迁移内容都视为永久消失。
因此“系统提示减少 80%”在窄口径下可以成立，传播成“Claude 上下文减少 80%”则会误导。
社区讨论中，有用户注意到 Claude Code 用非常短的硬编码指令限制未经请求的子代理或工作流使用，并报告行为发生明显变化。
无论个别用户体验是否可以普遍化，它都揭示了一个真实问题：
提示词的行为影响不与字符长度成正比。
删除五千字冗余说明可能没有副作用；改动一句承重规则，却可能改变整类工作流。
所以提示重构不能只看长度和 benchmark 均值，还应覆盖：
- 安全与权限边界；
- 长任务持续性；
- 工具选择；
- 错误恢复；
- 是否过度保守；
- 是否擅自扩大范围；
- 子代理和并行行为；
- 用户偏好遵循；
- 边缘场景回归。
相关讨论可参见：
这些帖子只能代表社区反馈，不能替代受控实验；其价值主要在于指出值得加入行为回归测试的具体风险。
Anthropic 倾向于：
- ToolSearch；
- Skills；
- progressive disclosure；
- 当前需要什么，才加载什么。
它可以减少工具选择混乱和注意力负担。
Manus 则强调长时间运行 Agent 的 KV-cache 命中率。动态添加或删除工具可能改变前缀、破坏缓存，因此更倾向保持稳定前缀，通过屏蔽机制控制当前可用工具。
来源：Manus：Context Engineering for AI Agents
| Anthropic 倾向 | Manus 倾向 |
|---|---|
| 减少当前可见工具 | 保持前缀稳定 |
| 降低注意力和选择负担 | 提高 KV-cache 命中率 |
| 按需展开说明 | 尽量追加，少修改前缀 |
| 适合大量工具的动态检索 | 适合长轨迹 Agent |
这不是简单的谁对谁错，而是在优化不同指标。API 是否支持缓存友好的动态工具变化，也会改变最终取舍。
第三方 prompt extraction 没有完整、可审计的证据链，因此不能确认：
- 文件是否完整或经过编辑；
- 对应哪个确切账号、版本和功能旗标；
- 是否所有 Opus 5 用户都会收到相同内容；
- 哪些内容来自 Anthropic，哪些来自 Connector 或环境；
- 它是否混合了 system、tool、动态上下文和其他消息层。
但其核心内容与 Anthropic 公开的 Claude.ai 核心系统提示存在明显重合。Anthropic 官方也持续发布 Claude.ai 与移动端使用的核心系统提示，并明确说明这些提示不适用于 API。
来源：Anthropic：System Prompts release notes
合理的可信度分层是：
| 判断 | 可信度 |
|---|---|
| 核心产品提示大体真实 | 较高 |
| 工具、Memory、Skills 的总体架构真实 | 较高 |
| 文件代表某个特定运行配置 | 可能 |
| 文件未经修改且绝对完整 | 无法确认 |
| 所有 Opus 5 会话都固定加载完全相同内容 | 不成立或至少未经证明 |
| Opus 5 有一个单体、秘密的 20 万字符核心系统提示 | 明显不准确 |
因此，讨论它时最好使用“第三方提取”“疑似运行时上下文”“该配置下的捕获”这类限定词，而不是把它当成官方确认的唯一真相。
不矛盾。
- 官方讨论 Claude Code，文件主要指向 Claude.ai；
- 官方统计核心常驻 system prompt，文件接近完整运行时 envelope；
- 20 万是字符量级，不是 token；
- 不同模型、版本和配置会使用不同提示。
存在营销口径张力。
“Claude Code 的核心系统提示减少 80%”可能真实；但不同时公布完整请求、工具、Memory 和迁移内容，公众很容易误解成“Claude 的实际上下文负担下降 80%”。
现有证据不能支持后一个宽泛结论。
真正值得关注的不是提示文件是否从 2,000 行变成 500 行，而是：
系统是否把通用行为、工具接口、项目知识、长期记忆和确定性验证放到了各自最合适的层次，并在正确的时机把高信号信息交给模型。
至少要求分别报告：
- 核心 system prompt tokens；
- 工具描述和 JSON Schema tokens；
- Skills、Agents 目录 tokens；
- Memory 与动态注入 tokens；
- 冷启动首轮请求的完整 tokens；
- Prompt cache 写入、读取与命中率；
- 实际上下文窗口占用；
- 整个任务的总 tokens、延迟和价格；
- 任务成功率与行为回归；
- 测试使用的模型、客户端版本、工具、MCP 和功能开关。
否则，“减少 80%”可能同时意味着：
- 真正删除了 80%；
- 把一部分内容迁移到按需加载；
- 只缩小了整个上下文中原本很小的一部分；
- 更换了统计分母。
Anthropic 很可能真的把 Claude Code 面向前沿模型的核心行为提示缩短了约 70%～80%；GitHub 上约 20 万字符的文件，则主要是另一产品形态下由核心提示、Memory、工具 schemas、Skills 和运行时配置共同组成的完整上下文。两者不构成形式矛盾，但“减少 80%”绝不能被等价理解为完整上下文或 token 成本减少 80%。
研究日期：2026-07-27。本文区分官方资料、独立测量与第三方提取；所有非官方捕获均仅作为结构性证据，不视为 Anthropic 对完整内容或普遍配置的确认。