Claude 第 5 代模型刚发布就上手体验了一下，这一代模型（Opus 5、Fable 5，以及走量型的 Sonnet 5），有一个结论越用越清晰：这一代模型最反直觉的变化，不是它更聪明，而是它"更不需要你教"。

Anthropic 在 Claude Code 上做了一件很夸张的事：把整套 system prompt 砍掉了 80% 以上——针对 Opus 5 / Fable 5 这类新模型，直接删掉八成的系统提示，编码评测成绩没有可测量的下降。换句话说，过去我们花大量精力写的那一长串"规矩"，大部分是写给"旧模型"听的，新模型根本不需要。

这篇文章我想聊的，就是这 80% 到底删了什么、为什么能删、以及对你自己写 agent / 写 CLAUDE.md / 写 Skill 有什么可直接套用的启发。我尽量用工程师能秒懂的方式讲，少喊口号。

---

一、先厘清：什么是"上下文工程"

很多人把"提示词（prompt）"和"上下文（context）"混为一谈。它们是两回事。

你每次发一条消息给 Claude，真正进模型上下文的，prompt 只是很小一块。剩下的大头是从这些地方动态拼装出来的：

• system prompt：产品层面的"你是谁、你在哪个产品里"
• Skills：可被按需调用的能力说明书
• CLAUDE.md：仓库级的记忆与约定
• memory：跨会话自动沉淀的记忆
• 其它来源（artifacts、工具定义、引用文件……）

Anthropic 把这件事命名为 context engineering（上下文工程）。它的难点在于：prompt 是"针对这一次请求"的，可以很具体；而 context 是"跨很多请求通用"的，你写它的时候并不知道用户下一句会问什么。

所以 context 不能像 one-shot prompt 那样硬编码规则，它必须是一种"通用的引导框架"。而新模型的判断力的跃升，正好让这个框架可以大幅做减法。

二、核心动作：给 Claude"松绑"（Unhobbling）

砍掉 80% 的本质，是一次解除过度约束（unhobbling）。

他们在内部翻自己的 Claude Code 使用记录时，发现一个很讽刺的现象：一条请求里经常同时出现互相打架的指令——system prompt 说"不要加注释"，Skills 说"该写文档就写"，用户又说"帮我把这块讲清楚"。三种声音怼在一起，模型得先花心思"调和矛盾"，才能动手干活。

这不是个例，是旧范式下的通病。过去为了堵住"最坏情况"（比如误删文件），我们会写很多宁可错杀也不放过的强约束。例如旧版 system prompt 里赫然写着：

默认不写注释。绝不写多段 docstring 或多行注释块——最多一行短注释。除非用户要求，否则不要创建任何规划、决策、分析文档——从对话上下文工作，不要用中间文件。

但真实场景里，这套规矩常常是错误的：用户可能就偏好详细注释；某些极复杂的代码段，恰恰需要多行注释才讲得清。

老模型没这判断力，不写这些护栏就会乱写注释，所以当时不得不接受这个 tradeoff。新模型不一样——它有足够的判断力，能在"不写注释"和"该写就写"之间自己拿捏。于是新版 system prompt 只剩一句：

写出的代码要像周围的代码：匹配它的注释密度、命名风格和习惯用法。

从"下令禁止"变成"给审美标准"。这一句话，顶过去一整段负面清单。

技术视角：这其实是把"防御性编程"的思路从代码层搬到了 prompt 层。旧做法是 if (worst_case) block()，新做法是给一个可度量的目标函数（match surrounding idiom），让模型自己优化。约束从"禁止集合"退化为"评测标准"，模型的探索空间一下就打开了。

三、六组 Then / Now：哪些"最佳实践"已经成了神话

下面这六组对照，是我觉得最有迁移价值的。每一组我都补一句工程师视角的理解。

1. Then：给 Claude 规则 → Now：让 Claude 用判断力

上面"松绑"已经讲透。一句话：规则是用来堵旧模型短板的，短板补齐了，规则就该退场。

2. Then：给 Claude 示例 → Now：设计接口

这是我最想展开的一组。旧的"工具使用第一法则"是给 few-shot 示例，教模型怎么调你的工具。但新模型上发现：示例反而把模型的探索空间框死了。

更好的做法是反过来——好好设计你的工具 / 脚本 / 文件的接口：

• 参数怎么设计才更有表达力？
• 用枚举（enum）去"暗示"语义，而不是用一长串示例去"教"语义。

举个 Todo 工具的例子：只要把 status 定义成 pending / in_progress / completed 的枚举，模型自然就懂怎么用；再补一句"同一时刻只保持一个 in_progress"，行为就定下来了。你没给任何示例，模型却用得很对。

技术视角：这跟我们设计 API 是一个道理——好的类型签名和枚举就是最好的文档（self-documenting API）。few-shot 示例本质是"用数据教模型分布"，而一个强类型的接口是"用结构传达先验"。当模型够强，结构比样本更高效，也更不容易带偏。

3. Then：一股脑前置 → Now：渐进披露（progressive disclosure）

旧 system prompt 把代码审查、验证这些"偶尔才用"的细节全堆在前面。新做法是按需加载：把代码审查、验证拆成独立的 Skill，Claude Code 只在需要时才去调。

不止 Skill，工具也这么干。一部分工具是 deferred loading（延迟加载）——模型必须先用 ToolSearch 查到它的完整定义才能用。这样工具数量可以很多（比如一整套 Task 工具），但不占上下文，直到被需要。

技术视角：这就是上下文层面的 lazy loading / 动态链接。把"常驻内存的符号表"换成"按需解析的动态符号"。你给模型的不是一份永远加载的大字典，而是一套 import 机制。对你的 CLAUDE.md / Skill.md 同理：别把它们写成"所有可能用到的实践的大杂烩"，而是做成一棵能在正确时机被加载的文件树。

4. Then：反复强调 → Now：精简的工具描述

旧模型有个毛病：爱听上下文窗口末尾的指令，开头说的容易忘，所以 system prompt 里提一遍工具、tool description 里再提一遍，靠"重复"保命。

新模型没有这个位置偏差问题，于是重复的示例可以全删，把"怎么用这个工具"的指令只放在 tool description 里，system prompt 不再赘述。

技术视角：这是把知识归到"离使用点最近的地方"。指令的权威源（single source of truth）从"散落各处"收敛到"工具自身的 schema"，符合我们写代码时"把契约放在接口定义里"的直觉。

5. Then：记忆写在 CLAUDE.md → Now：自动记忆

过去鼓励用户用 # 快捷键把东西写进 CLAUDE.md 当记忆。现在 Claude 会自动保存那些和当前工作、和你相关的记忆，不用你手动塞。

技术视角：从"显式持久化"变成"自动抽取 + 检索"。本质是把记忆管理从"文件写入"升级成一套带相关性的自动沉淀机制——你专注干活，该记的它自己记。

6. Then：简单 spec → Now：富引用（rich references）

Plan 模式下，旧做法是依赖 markdown 计划文件。现在模型能消化复杂得多的引用：

• 与其给 markdown，不如给 HTML artifact（设计稿）——实测比文字描述或截图效果好得多；
• spec 也可以是一段详尽的测试套件，或是另一个代码库里某个可移植的函数；
• 还有 rubric（评分量规）：让模型用 dynamic workflows 拉起一帮 verifier agent，按你的 rubric 去验证"什么叫好的 API 设计"。

技术视角：引用的"保真度"决定了模型的发挥上限。代码 / HTML 是高保真指令——用的是模型最熟的语言；截图 / 自然语言描述是低保真——信息在转译中折损。所以能给代码/结构化产物就别给描述。rubric + verifier 这条，其实就是把"LLM-as-Judge"从拍脑袋变成"带评分标准的可复现评审"，比单纯让模型自评稳得多。

四、落到你自己的上下文：四块怎么搭

把上面这些收拢起来，真正动手搭你自己的 agent 时，四块各司其职：

System Prompt
高度绑定产品语境——告诉 Claude 它身处哪个产品、在干什么。Claude Code 你基本不会动它；但如果你在自建 agent harness，这块才是你该花最多时间的地方。

CLAUDE.md
保持轻量。用少量 token 讲清"这个仓库是干嘛的"，把大部分 token 花在仓库内部的坑（gotchas）上。比如"类型全塞在一个大文件里，别处不要放"。别写那些 Claude 看一眼文件系统就知道的废话。细节用渐进披露：如果你有一堆独特的验证约定，做成 verification skill，从 CLAUDE.md 里引用它。

Skills
把 Skill 想成"让 Claude 在需要时找到信息的轻量指南"。除了极少数高危区，别把它们写得太死。长的 Skill 尽量拆分文件、用渐进披露。Skill 最值钱的时候，是它编码了"只属于你 / 你团队 / 你产品的特定观点、知识和最佳实践"——也就是不可替代的隐性经验。

References
用 @ 引用文件，把深度信息喂给当前计划。可以是 spec 文件、mockup、甚至整个代码库。优先给代码形态的文件——那是模型最熟、保真度最高的指令语言。

---

五、实在懒得手动精简？用 claude doctor

Anthropic 顺手发了个命令叫 claude doctor（在 Claude Code 里用 /doctor 触发），会自动帮你把 Skills 和 CLAUDE.md 瘦身到合适体量。

我自己试下来的体感：它干的事，就是把上面那套"删规则、做渐进披露、收口工具描述"自动化。如果你手上的 CLAUDE.md 已经长成了"万物百科"，先跑一遍 /doctor 比自己硬删省事。

---

六、为什么我说 Opus 5 “半价逼近 Fable 5”

讲回标题里那句话。Fable 5 是这一代的天花板，但价格也最顶；Opus 5 大致只有它一半的价位，却在前述"上下文工程"的加持下，把能力差距压得很小。

我的理解是：那一刀砍掉的 80% system prompt，省下的不是"能力"而是"成本"——过去靠堆长提示来防呆的活儿，现在模型自己用判断力扛了。于是你不用为那段冗余提示买单，也能拿到接近旗舰的体验。对日常工程任务（重构、修 bug、写特性），Opus 5 + 一套干净的上下文，基本就是性价比甜点。

注：上面"半价"是我基于这一代定价档位的定位判断，具体数字请以官方定价页为准——本文重点在"删提示语"这件事的方法论，价格只是顺带的体感。

---

写在最后

这一代模型给工程师的启示，其实一句话：少写规则，多写接口和标准。把"禁止清单"换成"审美标准"，把"前置大字典"换成"按需加载的文件树"，把"示例"换成"有表达力的类型"。模型越强，你越该相信它的判断力，而不是用 prompt 去替它做决定。

那些旧的最佳实践，很多已经成了"神话"。该删就删——你的上下文越干净，模型跑得越准。