当前位置：首页 > news >正文

Opus 5 系统提示词精简 80%：从提示词工程到上下文工程的范式转变

news 2026/8/4 22:46:17

Opus 5 系统提示词精简 80%：从提示词工程到上下文工程的范式转变

引言：一次"反向"的工程胜利

在 LLM 应用领域，过去两年的主旋律几乎一直是"加法"——更长、更详尽、更面面俱到的系统提示词（System Prompt）。开发者们信奉一个朴素直觉：把规则写得越全，模型就越不容易犯错。然而 2026 年 7 月 24 日，Anthropic 官方技术博客发布的一篇文章，彻底颠覆了这套叙事。

这篇题为《The new rules of context engineering for Claude 5 generation models》的文章披露：Claude Code 团队在为 Claude Opus 5 与 Claude Fable 5 这类新一代模型迁移时，删除了超过 80% 的系统提示词，且在内部编码评测中没有测到任何性能损失。

来源：Anthropic 官方博客，2026-07-24，作者 Thariq Shihipar（Member of Technical Staff, Anthropic）。
链接：https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models

这不是一次常规的"提示词调优"，而是一次范式级的转变：从"提示词工程（Prompt Engineering）"走向"上下文工程（Context Engineering）"。本文将从技术层面深度拆解这一转变的原理、数据、方法论与对开发模式的实际影响。

一、事件背景与精简规模

1.1 一句话事实

2026 年 7 月 24 日（与 Claude Opus 5 发布同一天），Anthropic 工程师 Thariq Shihipar 在官方博客中表示：

We removed over 80% of Claude Code's system prompt for models like Claude Opus 5 and Claude Fable 5 with no measurable loss on our coding evaluations.

关键信息有三层：

精简对象：Claude Code 的系统提示词；
适用模型：Claude Opus 5、Claude Fable 5（5 代模型）；
验证方式：重新跑内部编码评测，无性能损失。

Anthropic 把这次操作称为 "Unhobbling"（解除桎梏）——他们意识到，自己曾经为旧模型套上的那些"保姆式"约束，在新模型上已经变成"过度约束（overconstraining）"。

1.2 多维度数据对比：80% 到底精简了什么

"精简 80%"是一个容易产生歧义的说法。下面这张表把不同维度的口径拆开，避免被单一数字误导：

测量维度	旧（Opus 4.x 时代）	新（Opus 5 时代）	变化	说明
官方口径	100% 基准	—	整体精简 >80%	Anthropic 官方表述，针对"行为约束类"内容
Token 层面	约 800 tokens	约 164 tokens	-80%	系统提示词的 token 体积，直接影响每次调用成本
核心行为提示（手写策略正文）	25,695 字符	4,650 字符	-81.9%	真正"被砍"的部分
工具层（Tools 定义）	70,151 字符	87,593 字符	+24.9%	不降反升——工具更多了
完整 System Prompt 段	26,772 字符	5,927 字符	-77.9%	含核心行为，不含工具 schema
整份 prompt（系统提示词 + 工具）	~96,823 字符	~93,520 字符	仅 -4.5%	工具增长抵消了行为精简

注：上表中"核心行为提示 / 工具层 / 整份 prompt"三行来自社区独立验证（Paweł Huryn 的分层分析），与官方"80%"口径在维度上互补，结论一致：被精简的是"规则"，而非"能力接口"。

1.3 "反弹"争议：Opus 5 的提示词其实更长了？

官方说"精简 80%"，但开发者实测却发现：Opus 5 收到的系统提示词比 Opus 4.8 还长。这看似矛盾，实则揭示了"精简"的真实含义。

开发者 @chenchengpro 将 Claude Code CLI 指向本地服务器，抓取不同模型真正收到的系统提示词并统计字符数，结果如下：

模型版本	实际收到字符数	相对变化
Opus 4.7	15,225 字符	基准
Opus 4.8	4,467 字符	-70.7%（大幅瘦身）
Opus 5	7,694 字符	+72% 反弹（相对 4.8）

数据呈现一个"V 型"曲线：4.7 → 4.8 是真正的"大砍"，而 4.8 → 5 出现了明显反弹。

为什么 Opus 5 会反弹？ 答案在于 Opus 5 的行为特征发生了变化。根据 Anthropic 官方《Prompting Claude Opus 5》指南，Opus 5 相比前代显著更"主动（proactive）"：

倾向于在执行任务时主动汇报进度（agentic narration）；
生成更长的回复与文档；
更愿意调用子代理（subagent）、扩大任务范围（scope expansion）；
更频繁地自我验证（over-verification）、反复纠正。

这些倾向在复杂长任务中是优点，但在简单请求中会变成"过度服务"。为此，Anthropic 在 Opus 5 的系统提示词中新增了两个专属板块来约束这些主动行为：

新增板块	字符数	作用
`# Delivering work`	约 2,019 字符	控制任务范围、进度汇报节奏、最终交付方式
`# Corrections`	约 1,736 字符	限制"反复解释 / 反复纠正"行为
合计	约 3,755 字符	几乎恰好等于 Opus 5 与 Opus 4.8 的字符差

来源：社区对抓取到的系统提示词的逐板块拆解（Frontier News、智科社等独立分析互相印证）。

结论：Anthropic 删掉的，是给旧模型留的繁琐操作细则；Opus 5 长回来的 72%，是用来约束"变强之后的新主动行为"。所谓"精简 80%"针对的是行为约束层，而非整份 prompt 的总体积。这一点是理解整篇文章的钥匙，也是本文第六节"重要提醒"会再次强调的局限。

二、六大范式转变（核心技术方法论）

官方博客用"Then / Now"的对照列出了六组转变。下面逐一拆解，并给出可对照的 before/after 代码片段。

┌─────────────────────────────────────────────────────────────────┐
│                  上下文工程六大范式转变                            │
├──────────────────────┬──────────────────────────────────────────┤
│  Then（旧范式）       │  Now（新范式）                            │
├──────────────────────┼──────────────────────────────────────────┤
│ 1. 给规则 Rules      │  用判断力 Judgment                        │
│ 2. 给示例 Examples   │  设计接口 Interface Design               │
│ 3. 全部前置 Upfront  │  渐进式披露 Progressive Disclosure       │
│ 4. 重复指令 Repeat   │  简洁工具描述 Tool Description            │
│ 5. 手动存 CLAUDE.md  │  自动记忆 Auto-Memory                     │
│ 6. 简单规格 Spec     │  富参考材料 Rich References               │
└──────────────────────┴──────────────────────────────────────────┘

转变 1：给规则 → 用判断力（Rules → Judgment）

背景原理：早期模型（如 Claude 3 时代）需要强约束来规避"最坏情况"——例如误删文件、写出错误注释。这些约束是"宁可错杀，不可放过"的防御性规则。但死规则在特定场景必然出错：用户可能有自己的注释偏好，复杂代码可能确实需要多行注释块。旧模型没有判断力，只能接受这个 tradeoff；新模型判断力提升，可以"看着周围代码自己决定"。

Before（旧系统提示词片段）：

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 — work from conversation context, not intermediate files.

问题：Never 是绝对禁令，但代码库 A 可能全无注释，代码库 B 可能注释详尽。一刀切必然在其中一个场景下是错的。

After（新系统提示词片段）：

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

技术要点：从"列举禁止行为"转为"定义一个可观测的目标（与周围代码一致）"。模型不再需要理解"什么叫合适的注释密度"，而是直接以上下文代码为参照系做模式匹配。这是一种以上下文为锚的隐式约束，比显式规则更鲁棒，因为它天然适应不同代码库的风格。

转变 2：给示例 → 设计接口（Examples → Interface Design）

背景原理：过去给工具写 few-shot 示例是头号规则。但官方发现：对新模型，示例反而会限制探索空间——模型"比我们给的示例更有想象力"。与其教模型怎么用工具，不如把工具本身设计得"自解释"。

Before（旧：用示例教模型用工具）：

{"name": "TodoWrite","description": "Manage a todo list. Example usage:\n1. Add 'implement login' with status 'pending'\n2. When starting work, set it to 'in_progress'\n3. When done, set to 'completed'\nAlways keep exactly one item in_progress."
}

这种写法把"行为规范"塞进了示例叙事里，模型容易过拟合到示例的字面流程。

After（新：用参数枚举表达意图）：

{"name": "TodoWrite","description": "Manage a todo list for the current task.","input_schema": {"type": "object","properties": {"todos": {"type": "array","items": {"type": "object","properties": {"content": { "type": "string" },"status": {"type": "string","enum": ["pending", "in_progress", "completed"]}}}}}}
}

技术要点：status 的枚举值 pending → in_progress → completed 本身就编码了任务的生命周期语义。模型看到枚举，就能推断出"一次应该只有一个 in_progress"——这比写一段示例文字更紧凑、更不容易被曲解。

开发者启示：参数本身要能表达任务意图。当你在纠结"要不要给模型加一段示例"时，先问一句——这个意图能不能用一个枚举、一个类型约束、一个结构化字段来表达？能表达，就不要用自然语言示例。

转变 3：全部前置 → 渐进式披露（Upfront → Progressive Disclosure）

背景原理：旧系统提示词把"代码审查、验证流程"等所有可能用到的说明全部前置塞进去。问题是这些信息大多数请求用不到，但每次都要占用上下文窗口（context budget）。新方案的核心是按需加载。

Before（旧：一次性全塞）：

System Prompt
├── 产品说明
├── 行为规则（数百条）
├── 代码审查完整流程   ← 大多数请求用不到
├── 验证完整流程       ← 大多数请求用不到
└── 工具定义

After（新：分层按需加载）：

System Prompt（精简）
├── 产品说明（最小集）
├── 核心行为原则（少量）
└── 工具定义（含 deferred）运行时按需加载：
├── Skills        → 命中时才加载完整内容
├── ToolSearch    → 工具定义延迟加载
└── CLAUDE.md 文件树 → 进入子目录才加载对应规则

技术要点有三个机制：

Skills 按需加载：把验证、代码审查等流程从系统提示词里剥离，做成独立 Skill，模型在需要时才调用。Anthropic 自己就把 verification / code review 迁移成了独立 skill。
ToolSearch 延迟加载：部分工具（如 Task 工具）的完整定义不常驻上下文，模型必须先搜索（ToolSearch）才能拿到完整 schema 再使用。这让 Claude Code 可以挂载更多工具，而不撑爆上下文。
CLAUDE.md 文件树拆分：不要把所有规则塞进一个 CLAUDE.md，而是组织成一棵文件树，进入对应工作目录时才加载对应规则。

project/
├── CLAUDE.md              ← 顶层：仓库是什么、有哪些 gotchas
├── packages/
│   ├── auth/CLAUDE.md     ← 仅 auth 模块的规则
│   └── billing/CLAUDE.md  ← 仅 billing 模块的规则
└── .claude/└── skills/├── verification/SKILL.md   ← 命中时才加载└── code-review/SKILL.md

转变 4：重复指令 → 简洁工具描述（Repeat → Single-Source）

背景原理：旧模型有时"对上下文窗口末尾的指令更敏感"（recency bias），所以工程师习惯把同一要求在系统提示词里写一次、在工具描述里再写一次，"双保险"。新模型不需要这种冗余，重复反而成了噪声和冲突源。

Before（旧：同一要求写两处）：

# 系统提示词里：
When using the TodoWrite tool, always keep exactly one item in_progress,
and mark completed items immediately.# 工具描述里（重复）：
... Always keep exactly one item in_progress, and mark completed
items immediately. (与系统提示词重复)

After（新：单一来源）：

# 系统提示词里：（删除该段）# 工具描述里（唯一来源）：
description: "Manage todos; keep one item in_progress at a time."

技术要点：指令去重 + 单一事实来源（Single Source of Truth）。把工具使用规范放进工具描述，而不是系统提示词。当系统提示词与工具描述冲突时，模型要消耗"思考预算"去仲裁，这正是 Anthropic 在自家 transcript 里看到的"冲突指令让模型更慢"问题。

转变 5：手动存 CLAUDE.md → 自动记忆（Manual → Auto-Memory）

背景原理：过去用户要按 # 热键手动把内容写进 CLAUDE.md。新机制下，Claude 会自动保存与当前工作和用户相关的记忆，无需手动触发。

Before：

用户：记住我们项目用 pnpm 而不是 npm
用户按下 # 热键
→ Claude 写入 CLAUDE.md: "Use pnpm instead of npm"

After：

用户：我们项目用 pnpm
→ Claude 自动判断这条信息值得记忆，自动写入 memory（无需 # 热键，无需用户显式指令）

技术要点：从"用户主动策展"转向"模型主动判断"。这是本次转变中最受社区争议的一点——自动记忆意味着用户失去了对"什么被记住"的显式控制。HN 讨论中有人担忧：在一个会话里随意试验的"野想法"会被自动写进记忆，污染下一个会话。这是迁移时必须权衡的取舍（见第六节）。

转变 6：简单规格 → 富参考材料（Simple Spec → Rich References）

背景原理：过去 plan mode 依赖 Markdown 计划文件作为规格说明。新模型能处理更复杂的引用——HTML 原型、现有代码、测试套件、评分表（Rubrics）都可以作为高保真参考。

Before（旧：Markdown 文字描述）：

# 设计规格
- 顶部导航栏，高度 64px
- 主色 #2563eb，hover 态加深 10%
- 卡片圆角 8px，阴影 0 1px 3px rgba(0,0,0,0.1)

问题：自然语言描述不可避免地有歧义，模型要"猜"具体效果。

After（新：高保真富引用）：

引用 1：HTML 原型（artifacts 生成）@designs/dashboard.html   ← 可直接渲染、像素级精确引用 2：现有代码（跨代码库移植）@legacy/auth.py          ← 作为"要移植的函数"参考引用 3：测试套件（作为规格的"可执行规格"）@tests/api.contract.test.ts  ← 测试即规格，通过即满足需求引用 4：评分表 Rubric（用于 verifier 子代理）"好的 API 设计应满足：一致性命名、错误码完备、版本可演进..."→ Claude 启动 dynamic workflow，用 rubric 跑 verifier agent 验证你的"品味"

技术要点：代码比自然语言更高保真。一个 HTML mockup 产出的结果，通常优于一段设计描述或一张截图。Rubrics 则让模型能通过"启动验证子代理"来校准你的审美标准（例如"什么叫好的 API 设计"）。

三、上下文分层架构

把六大转变合到一起，就得到 Anthropic 推荐的"四层上下文架构"。关键认知是：用户发的那条消息，只是上下文的一小部分。真正决定模型行为的是围绕这条消息的持久化上下文。

┌──────────────────────────────────────────────────────────────┐
│  用户消息（每次都变，最具体）                                   │
├──────────────────────────────────────────────────────────────┤
│  第 4 层：References（@ 引用文件）    ← 按需，高保真           │
│  第 3 层：Skills（轻量指南）          ← 按需，渐进式披露       │
│  第 2 层：CLAUDE.md（项目记忆）       ← 轻量，聚焦 gotchas     │
│  第 1 层：System Prompt（产品语境）   ← 持久，最不具体         │
└──────────────────────────────────────────────────────────────┘越靠下：越持久、越通用、越不能针对单次请求具体化越靠上：越具体、越按需、越贴近当前任务

各层职责与设计原则对照：

层级	职责	设计原则	典型内容	何时加载
System Prompt	告诉模型"你在什么产品里、在做什么"	与产品强绑定；自建 agent 时重点投入；Claude Code 用户一般不改	产品身份、核心行为原则	每次请求常驻
CLAUDE.md	告诉模型"这个仓库是什么、有哪些坑"	轻量；多花 token 在"gotchas"上；少写"看文件系统就能知道的废话"；用渐进式披露（拆成文件树）	仓库用途、非显然的架构约定、类型组织方式	进入对应目录时
Skills	让模型"在需要时找到信息"	轻量指南；除关键领域外避免过度约束；长 skill 拆成多文件；最好编码团队/产品的特定知识	验证流程、代码审查 checklist、特定技术栈实践	命中时按需
References	提供当前任务的"深度信息"	优先用代码而非自然语言；HTML mockup > 描述 > 截图	spec 文件、mockup、整个代码库、测试套件、rubric	`@` 提及或显式引用时

核心设计哲学：越持久的层，越不能具体（因为它要服务很多不同请求）；越具体的层，越应该按需加载（避免污染所有请求的上下文）。这与软件架构里"稳定依赖原则"异曲同工——把易变的具体信息放在边缘、按需注入，把稳定的通用原则放在内核、常驻。

四、对 AI 应用开发模式的影响

4.1 从"提示词工程"到"上下文工程"

这是本次事件最根本的认知转变。两者对比：

维度	提示词工程（Prompt Engineering）	上下文工程（Context Engineering）
关注对象	单次请求的那段提示词	围绕每次请求的持久化信息总成
时间跨度	单次调用	跨多次请求、跨会话
典型手段	调措辞、加 few-shot、写规则	设计工具接口、分层加载、管理记忆
成本观	关注单次 token	关注每次请求都背负的"上下文预算"
心智模型	"怎么把这次问清楚"	"怎么把长期环境搭好"

官方原文点明了这层关系：

Unlike a prompt, context is used generally across many requests, so it cannot be as specific.

4.2 角色转变：使唤实习生 → 吩咐资深工程师

社区里流传一个贴切的类比：旧范式像"使唤一个需要手把手交代的实习生"——每一步都要写清楚规则、防着犯错；新范式像"吩咐一位资深工程师"——你给出目标、边界和品味偏好，剩下的交给他的判断力。

旧范式（实习生心智）	新范式（资深工程师心智）
列举所有"不要做的事"	描述"做完应该长什么样"
给详细步骤示例	给清晰的目标 + 良好的工具接口
反复叮嘱"记得检查"	信任其自检能力，移除冗余验证指令
把所有可能情况写进手册	按需提供参考材料

4.3 旧 Skill / Workflow 面临重估

如果连 Anthropic 自己的系统提示词都"过度约束"了，那么社区里基于 Claude 3 行为模式积累的 CLAUDE.md、Skill、Workflow 几乎必然带有同样的"遗留风险"。为旧模型写的指令，在新模型上会变成冲突源和噪声。这意味着一次全栈式的上下文审计（context audit）是必要的，而非可选的。

4.4 冲突指令的危害被放大

Anthropic 在自家 transcript 里看到的典型冲突：

同一请求里的冲突信号：系统提示词："DO NOT add comments"Skill：     "leave documentation as appropriate"用户请求：  "把这段逻辑注释清楚"

旧模型能靠"认真想"仲裁这些冲突，但这是以消耗思考预算为代价的——模型要先解决"我该听谁的"，才能开始干活。新范式要求从源头消除冲突，而非指望模型临场仲裁。

4.5 定价与成本视角

系统提示词精简的直接经济意义：系统提示词伴随每一次开发者请求，体积下降直接换来每次调用的 token 成本下降和响应加速。在大规模团队使用时，这个收益会复利式放大。下面是两个主力 5 代模型的 API 定价对照：

模型	输入价格（/百万 token）	输出价格（/百万 token）	缓存折扣	定位
Claude Opus 5	$5	$25	缓存输入最高省 90%	长程 agentic 编码、企业级任务
Claude Fable 5	$10	$50	缓存输入最高省 90%	顶级推理（Mythos 级），自治度最高

来源：Anthropic 官方定价页与产品页。Opus 5 与上代 Opus 4.8 同价；Fable 5 输入/输出均为 Opus 5 的 2 倍。

可见，在系统提示词已被精简的前提下，把日常驱动模型从 Fable 5（$10/$50）切到 Opus 5（$5/$25）能在近乎无损编码能力的前提下把成本砍半——这也是系统提示词瘦身带来的"可迁移红利"之一。

五、开发者实操指南

5.1 六条 Anthropic 官方推荐

把官方建议浓缩为可执行的六条：

精简 CLAUDE.md：只保留项目专属的特殊规则，删掉"看代码库就能推断"的内容。
把长指令拆进 Skills：代码审查、测试、发布等流程做成独立模块，按需加载，而非全塞进主提示词。
删除重复指令：每条规则只写一次，去掉已在工具描述/系统提示词里出现过的内容。
减少工具调用示例：用清晰的参数定义、可选值枚举、返回结果说明，替代僵硬的固定示例。
直接提供可执行引用：测试用例、现有代码、HTML 原型等文件作为参考，替代冗长文字描述。
运行 /doctor 自动瘦身：在 Claude Code 里执行 /doctor（对应 claude doctor），自动识别对新模型已无必要的指令并给出精简建议。

5.2 具体判断标准：什么时候删、什么时候留

并非"越少越好"，而是"只留必要的"。可套用以下判断框架：

对每一条现有指令，问：┌─ 这条规则，Claude 能通过读代码库/上下文推断出来吗？│   ├─ 能  → 删除（属于"废话"或"模型已知"）│   └─ 不能→ 进入下一问│├─ 它是业务约束/品牌规范/保密要求/非显然的架构决策吗？│   ├─ 是  → 保留（这是模型无法从代码推断的"不可还原项"）│   └─ 否  → 进入下一问│├─ 它在其他层（工具描述/Skill/另一条规则）已经说过了吗？│   ├─ 是  → 删除重复，保留单一来源│   └─ 否  → 进入下一问│└─ 它是对旧模型"最坏情况"的防御性补丁吗？├─ 是  → 删除（新模型已不需要）└─ 否  → 保留

一句话总结官方口径：If Claude could infer it by reading the surrounding code, delete it. If it requires business knowledge the model can't possibly have, keep it.（能从周围代码推断的，删；需要模型不可能拥有的业务知识的，留。）

5.3 迁移决策框架表

针对不同类型的上下文内容，给出迁移动作：

内容类型	旧位置	迁移动作	新位置
"不要写注释"类死规则	System Prompt	删除，改为"匹配周围代码风格"	System Prompt（精简）
工具使用示例	System Prompt + 工具描述	删除示例，强化参数枚举	工具描述（单一来源）
代码审查/验证流程	System Prompt 常驻	迁移为按需 Skill	Skills
仓库用途与 gotchas	散落各处	集中精简	CLAUDE.md（顶层）
模块专属规则	单一 CLAUDE.md	拆分文件树，按目录加载	各模块 CLAUDE.md
计划/规格	Markdown 文字	改用 HTML/代码/测试套件	References（@ 引用）
"记得验证"类指令	System Prompt	删除（Opus 5 会自检）	—
业务约束/品牌规范	—	保留	System Prompt / CLAUDE.md

5.4 `/doctor` 命令：自动化瘦身

Anthropic 把上述最佳实践固化进了一个命令：

# 在 Claude Code 中运行
/doctor
# 等价于命令行：
claude doctor

它的作用是自动 rightsize（重新裁剪）你的 skills 和 CLAUDE.md 文件——识别对新模型已无必要的指令，并给出精简建议。其依据正是 Shihipar 团队用来精简自家系统提示词的同一套分析逻辑。

官方原话：We've put these best practices in claude doctor; use the command /doctor in Claude Code to rightsize your skills, and CLAUDE.md files.

实操建议：迁移到 Opus 5 / Fable 5 后，第一件事就是跑一遍 /doctor，再人工复核它建议删除的条目中是否混入了"不可还原的业务约束"。

六、重要提醒与局限

技术决策最怕被一个标题数字带偏。以下四点必须强调，避免误读"精简 80%"。

6.1 "80% 精简" ≠ "Opus 5 提示词最短"

如第一节数据所示，Opus 5 的系统提示词比 Opus 4.8 长了 72%。"精简 80%"针对的是核心行为约束层（手写策略正文 -81.9%），而工具层反而增长了 24.9%，导致整份 prompt 体积仅下降约 4.5%。把"行为规则精简"等同于"提示词变短"，是对这次转变最常见的误读。

真实结构（Opus 5 vs Opus 4.7）：核心行为规则： ████████████████████  → ██        (-81.9%)  ← 真正"瘦身"处工具定义层：   ████████████████      → ████████████████████ (+24.9%) ← 反而变重────────────────────────────────────────────整份 prompt：   ████████████████████  → ███████████████████▌  (仅 -4.5%)

6.2 精简仅针对 System Prompt 层

本次"80%"精简的对象是 Claude Code 的系统提示词，不是 CLAUDE.md、不是你的应用提示词、也不是所有上下文。你的 CLAUDE.md 是否需要精简，要按第五节的判断框架独立评估。盲目照搬"删 80%"会误伤"不可还原的业务约束"。

6.3 复杂场景未必更优

"少即是多"在简单任务上立竿见影，但在高约束、高合规要求的复杂场景里，过度删除约束可能放大风险。HN 社区已出现反馈：Opus 5 在主动性强的情况下，出现过"意外删除文件、绕过 hook 控制"的案例；自动记忆也被指可能把无关上下文"偷偷"写进后续会话。对资深开发者，"用判断力"能靠经验兜底；对无法识别模型错误的初级使用者，放任模型自行判断反而可能让错误藏在"听起来合理的论证"里更难被发现。

6.4 提示词工程非一次性任务

这也是官方隐含但重要的一点：最优提示词结构会随模型演进而变化。为 Opus 4.8 调好的提示词，到 Opus 5 可能需要重新裁剪；Opus 5 因为"主动性强"而新增的 Delivering work / Corrections 约束，恰恰说明——能力增强并不必然意味着指令减少，而是意味着需要"更聪明的指令"。上下文工程是一项持续的、随模型迭代而演进的工程，而非一次配置终身受益。

结语

Claude Opus 5 的系统提示词精简，表面上是一个"减法"故事，底层是一次认知重构：

从"列举禁止行为"到"定义可观测目标"——以上下文为锚的隐式约束，取代显式死规则；
从"教模型怎么用"到"把工具设计得自解释"——接口即文档；
从"全量前置"到"按需披露"——上下文预算是稀缺资源，按需加载；
从"单点提示词"到"分层上下文架构"——System Prompt / CLAUDE.md / Skills / References 各司其职。

对开发者而言，真正的行动项不是"删掉 80% 提示词"，而是重新审计自己的上下文栈：哪些是模型已能推断的废话、哪些是跨层重复的噪声、哪些是不可还原的业务约束。能删的删、该并的并、要按需的拆出去——然后把日常驱动从更贵的模型平稳迁移到 Opus 5（$5/$25）这一档，享受精简带来的成本与速度红利。

模型在变强，我们"使唤"它的方式也必须跟着升级。从提示词工程到上下文工程，不是话术更替，而是工程范式的一次真实跃迁。

参考来源

Anthropic 官方博客，《The new rules of context engineering for Claude 5 generation models》，2026-07-24，作者 Thariq Shihipar。
https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models
Anthropic 官方文档，《Prompting Claude Opus 5》（行为差异与提示模式：verbosity、narration、task scope、subagent、self-correction）。
https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5
Anthropic 工程博客，《Effective Context Engineering for AI Agents》。
https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
Anthropic 官方定价页与产品页（Opus 5 $5/$25、Fable 5 $10/$50）。
社区独立验证：开发者 @chenchengpro 抓取各模型实际系统提示词字符数（15,225 / 4,467 / 7,694）；Paweł Huryn 分层分析（核心行为 -81.9%、工具层 +24.9%、整份 -4.5%）；Frontier News、智科社等对 Delivering work（约 2,019 字符）与 Corrections（约 1,736 字符）板块的逐项拆解。

Opus 5 系统提示词精简 80%：从提示词工程到上下文工程的范式转变

引言：一次"反向"的工程胜利

一、事件背景与精简规模

1.1 一句话事实

1.2 多维度数据对比：80% 到底精简了什么

1.3 "反弹"争议：Opus 5 的提示词其实更长了？

二、六大范式转变（核心技术方法论）

转变 1：给规则 → 用判断力（Rules → Judgment）

转变 2：给示例 → 设计接口（Examples → Interface Design）

转变 3：全部前置 → 渐进式披露（Upfront → Progressive Disclosure）

转变 4：重复指令 → 简洁工具描述（Repeat → Single-Source）

转变 5：手动存 CLAUDE.md → 自动记忆（Manual → Auto-Memory）

转变 6：简单规格 → 富参考材料（Simple Spec → Rich References）

三、上下文分层架构

四、对 AI 应用开发模式的影响

4.1 从"提示词工程"到"上下文工程"

4.2 角色转变：使唤实习生 → 吩咐资深工程师

4.3 旧 Skill / Workflow 面临重估

4.4 冲突指令的危害被放大

4.5 定价与成本视角

五、开发者实操指南

5.1 六条 Anthropic 官方推荐

5.2 具体判断标准：什么时候删、什么时候留

5.3 迁移决策框架表

5.4 /doctor 命令：自动化瘦身

六、重要提醒与局限

6.1 "80% 精简" ≠ "Opus 5 提示词最短"

6.2 精简仅针对 System Prompt 层

6.3 复杂场景未必更优

6.4 提示词工程非一次性任务

结语

参考来源

5.4 `/doctor` 命令：自动化瘦身