Claude Code 把系统提示词缩短 80% 后：提示工程正升级为上下文工程

核心结论： Claude Code 团队表示，面向其最新一代前沿模型时，系统提示词已缩短约 80%，在内部编码评估中没有观察到可测量的性能下降。它并不意味着“提示工程已死”，而是说明：把所有规则、示例和流程长期塞进系统提示词，正在被“最小必要指令 + 按需上下文 + 工具约束”的架构替代。

---

7 月下旬，Anthropic 释放了两个值得连起来看的信号。

第一，Claude Opus 5 发布：输入 / 输出价格为每百万 token 5 / 25 美元，与 Opus 4.8 相同。Anthropic 称，它在 CursorBench 3.2 的最高推理强度下距 Fable 5 峰值仅 0.5%，并在 Frontier-Bench v0.1 上以更低单任务成本取得了超过 Opus 4.8 两倍的成绩。基准是厂商和合作方的特定运行结果，应把它视为选型信号，而不是你项目中的性能承诺。

第二，更值得关注的是 Claude Code 团队在公开访谈中透露：针对 Fable 5、Opus 4.8 及后续前沿模型，他们将系统提示词缩短了约 80%，在编码评估中“没有看到可测量的退化”。这不是“所有模型都可以删掉 80% 提示词”的通用结论：团队同时说明，旧模型仍保留较完整的系统提示词，而且不同模型使用不同版本的提示词。

Claude Code 的 /doctor 则可检查安装、设置、扩展和上下文使用情况，并在你确认后建议或应用修复；它是诊断工具，不是自动替你重写 Skills 或 CLAUDE.md 的“提示词瘦身器”。

如果你一直在精心打磨几十条全局规则，真正该得到的启发不是“全部删掉”，而是：把每条规则放到最合适的执行位置，并用评估验证它是否真的有用。

一、删掉了什么：从"保姆式规则"到"让模型自己判断"

Anthropic 的核心发现可以用一句话概括：他们在过度约束 Claude Code。

团队翻阅内部使用 Claude Code 的对话记录时，发现同一次请求中经常出现互相矛盾的指令。系统提示词说"酌情保留文档"，Skills 说"禁止添加注释"，用户请求又说"给我加详细注释"。三个层级的指令在打架。

Claude 通常能理解用户的真实意图，但它必须先在这些重叠、冲突的指令之间反复权衡，才能决定该怎么做。这些约束在过去是必要的——用来规避最坏情况。但团队后来发现，其中很多都可以删除，让模型依据周边上下文和自身判断力行事。

从这次访谈、Anthropic 的上下文工程文章与 Skills 文档中，可以归纳出 6 个 “Then → Now” 的变化：

1. 给规则 → 让模型判断

以前：

In code: default to writing no comments.
Never write multi-paragraph docstrings or multi-line comment blocks — one short line max.
Don't create planning, decision, or analysis documents unless the user asks for them.

现在：

Write code that reads like the surrounding code: match its comment density, naming, and idiom.

旧指令是一个全局否决——不管什么场景都不许写多行注释。新指令是自适应的——看周围代码的风格，匹配它。Claude 5 的判断力已经好到 Anthropic 更愿意让模型匹配局部习惯，而不是执行绝对禁令。

2. 给示例 → 设计接口

以前教 Claude 用工具的第一法则是：给大量示例。但对于新一代模型，Anthropic 发现给示例反而会收窄探索空间。

取而代之的做法是设计更好的工具接口。比如 Todo 工具，不再用一大段示例教模型怎么用，而是通过 pending | in_progress | completed 的枚举状态 + "保持一个 in_progress"的约束，通过 Schema 本身就教会了模型行为。

3. 全部塞前面 → 按需加载

把代码审查、验证流程等内容全部放在开头，会让每次请求都承担无关上下文。这些信息并非总需要，但在相关任务中又很关键。

更可靠的模式是渐进式披露（progressive disclosure）：先让 Agent 看到 Skill 的名称和触发条件，只有任务匹配时才加载完整的 SKILL.md，再按需读取关联资料或执行脚本。可用工具很多并不等于每个工具的完整说明都必须常驻上下文。

flowchart LR
    A[用户任务] --> B[最小全局指令]
    B --> C{需要专门知识？}
    C -- 否 --> D[检索代码 / 调用工具]
    C -- 是 --> E[加载匹配的 Skill]
    E --> F[按需读取参考资料与脚本]
    D --> G[执行、验证、交付]
    F --> G

4. CLAUDE.md 当瑞士军刀 → 拆成 memory + artifacts + skills

不要把 CLAUDE.md 当成唯一的持久上下文来源。它适合放仓库定位、常用命令、关键约束和不易从代码推断的坑；可复用流程放 Skills，任务过程放可审阅的产物或进度文件。自动 memory 有用，但应当可查看、可纠正，也不应成为唯一事实来源。

5. 硬性约束编码品味 → 让模型匹配局部风格

旧提示词用 ALL-CAPS 的 NEVER 和 ALWAYS 来约束代码风格。新范式是：让模型观察周围代码的注释密度、命名习惯和惯用写法，然后匹配它。品味不再需要硬编码进提示词。

6. 安全护栏放系统提示词 → 放进工具描述

安全指令没有消失，只是应当被分层。需要百分之百执行的动作，不能只依赖自然语言提示：应由工具权限、审批、hooks、沙箱或 CI 策略强制执行。工具描述可以提供临近操作的提醒，但它不是确定性的安全边界。

二、为什么这件事比 Opus 5 本身更重要

Opus 5 以较低成本接近旗舰模型是重要信号；系统提示词缩短则更直接触及 Agent 的构建方式。

它意味着"提示工程"正在变成"上下文工程"。

传统提示工程强调用规则和示例把模型引导到预期轨道。它并没有失效，但“规则越多越可靠”的假设正在失效。

对前沿模型而言，过多示例、绝对禁令和互相重叠的规则，可能限制探索、制造冲突，甚至降低指令遵循。Anthropic 的结果证明的是其特定模型和评估上的收益；你的任务仍需用自己的失败案例和评测集验证。

能力上去了，可以删掉冗余叙述；但硬性安全、合规和产品约束必须保留，并尽可能落到可执行机制中。

新的范式不是"怎么告诉模型怎么做"，而是"怎么设计工具接口和上下文结构，让模型自己搞清楚该怎么做"。竞争壁垒从提示词的手艺，转移到了工具设计和上下文架构。

三、别把“80%”读成三件错误的事

1. 它不是总上下文缩短了 80%

系统提示词变短，不等于 Agent 在一次任务中接触的总上下文变少。部分内容被转移为按需加载的 memory、Skills、工具说明和文件检索。真正要观察的是：相关信息是否在正确时机进入上下文，以及它是否提高了任务成功率。

2. 它不是所有项目都该“少即是多”

对明确、重复、低风险的工作，短提示词往往更好；但对高风险操作、复杂领域知识、严格输出格式或不稳定工具，仍可能需要具体示例、验证步骤和明确约束。正确动作是删一条、测一条，而非凭感觉大扫除。

3. 它不是把安全护栏删掉

“让模型自行判断”适用于判断性任务，不适用于不可逆或受监管动作。删除数据、发版、生产环境变更、支付与权限操作，应继续要求审批或使用确定性拦截。

四、开发者现在该做什么

如果你在用 Claude Code 或构建自己的 Agent，可以从这四步开始：

第一，先建立基线，再改提示词。 选 10～30 个真实任务，记录成功率、返工次数、工具调用错误、耗时和 token 消耗。没有基线，“优化”只能是主观感受。

第二，审计规则并标记去向。 搜索 NEVER、ALWAYS、DO NOT、重复示例和相互矛盾的表述。每一条都要回答：它是必要的全局指令、任务级知识、工具前置条件，还是必须由代码/权限强制的约束？

第三，拆分并按需加载。 让 CLAUDE.md 保持短而具体；把领域流程拆成 Skills；把体积大的参考资料分文件链接；把工具的有效参数、枚举和错误反馈设计清楚。Anthropic 的 Skills 文档正是这种三层渐进式披露的一个实现例子。

第四，运行 /doctor，但别误解它的职责。 它适合诊断 Claude Code 的安装、配置、扩展与上下文状态；提示词是否该删、Skill 是否有效，仍需要结合你的评测结果判断。

五、我的观点

1. 提示工程没有死，是升级了

"提示工程已死"这种说法太粗暴。准确的说法是：提示工程从"写规则"升级成了"设计系统"。 以前你给模型一长串规则和示例，现在你设计工具接口、规划上下文加载顺序、构建渐进式披露的 skills 树。这不是更简单了，是换了种复杂——从写散文变成了做架构。

2. 成本重要，但不能单独解释这次变化

系统提示词会随每轮请求进入上下文，因此冗余内容会影响成本与注意力分配。更关键的工程收益却是减少冲突、提高有效信息密度，并让任务相关知识在需要时才出现。

不要把“节省 token”当成唯一 KPI：若删掉一条规则导致一次生产事故或多轮返工，省下的 token 没有价值。

3. 这次范式的赢家和输家

赢家是工具设计、评估体系和上下文架构做得好的团队。他们能把“模型该知道什么”落实到可维护的结构，而不是沉积在一段越来越长的散文里。

风险最大的是把全部 know-how 堆在系统提示词、却没有测试体系的团队。迁移新模型时，旧规则可能失效、互相冲突或拖累性能；需要把积累重构为“可执行约束 + 工具接口 + 可按需加载的知识”。

4. 真正值得警惕的是"可移植性"的消失

平台提供的 memory、artifacts 和 Skills 能提升效率，但会带来一定迁移成本。若上下文工程完全依赖某个产品特有的触发和存储语义，换模型时重构的不只是提示词，而是整个加载架构。

我的建议：把范式学过来，但不要把实现绑死在一家平台上。 progressive disclosure、interface design、judgement over rules——这些原则是通用的。但具体实现上，保持你的核心逻辑在可移植的格式里（标准 markdown、标准 JSON schema），而不是某家公司的专有格式。

结语

Claude Code 缩短系统提示词，首先是一项针对前沿模型的工程实践；它的价值在于提醒我们重新审视上下文的“默认常驻”与“按需出现”。

它传递的不是“再也不要写提示词”，而是：不必把每一步都写成全局规则；应当设计好让模型获取正确上下文、调用正确工具、并在关键节点接受确定性约束的基础设施。

过去几年，我们花了大量时间教 AI 遵守规则。接下来几年，更重要的能力是：知道什么时候该放手，什么时候必须用系统来兜底。

---

本文是「AI Agent 工程化」系列的一部分。前几篇覆盖了 Agent 记忆层、任务调度、多 Agent 协作和安全防线，这篇讲的是 Agent 的上下文工程范式转变——当模型本身变聪明了，我们围绕模型构建的基础设施也需要跟着变。

参考资料

1. Anthropic：Introducing Claude Opus 5（发布时间、定价与基准说明）
2. Simon Willison：A Fireside Chat with Cat and Thariq from the Claude Code team（系统提示词缩短约 80%、按模型区分提示词的访谈原文）
3. Anthropic：Effective context engineering for AI agents（最小必要上下文、评估与渐进式检索）
4. Anthropic：Equipping agents for the real world with Agent Skills（Skills 的渐进式披露机制）
5. Claude Code 文档：Troubleshooting（/doctor 的官方功能说明）