提示词越写越长？Anthropic说可以砍掉80%，我试了真的行

花叔解读 Anthropic 官方文章《The new rules of context engineering for Claude 5 generation models》—— Claude Code 团队将系统提示词删掉 80% 以上，编码评测没有明显下降。文章给出六条策略对照表，并分享作者本人照着精简的结果：23,504 → 9,259 字符（-60%），发现”一多半是坏的”。

核心观点

1. Anthropic 将 Claude Code 系统提示词删掉了 80% 以上，适用于 Claude Opus 5 和 Claude Fable 5 这一代模型。评测口径是编码评测没有可测量的下降。最容易被忽略的是：他们现在每个模型配一套不同的系统提示词，旧模型还是完整版。

2. 核心判断标准有两条：① 这条 Claude 读文件能不能自己推断出来？能，就别写。② 这是判断框架还是别做什么的禁令？能写成”你相信什么”，就别写成”你不许什么”。

3. 六条策略的对照表（过去 → 现在）：① 给规则 → 让它判断（如把”默认不写注释”改为”匹配周围代码风格”）；② 给示例 → 设计接口（few-shot 尽量别用了，参数命名和枚举值定义到位就行）；③ 全部前置 → 渐进披露（长 skill 拆多文件，工具延迟加载，用到才读）；④ 反复强调 → 单一位置（同一指令在三处重复会导致相互打架）；⑤ CLAUDE.md 存记忆 → 自动记忆（索引+按需读取而非全量加载）；⑥ 简单规格 → 富引用（测试套件比文字描述更准）。

4. 四类文件的撰写建议：系统提示词只负责”告诉 Claude 它在哪在干什么”（高度绑定产品上下文）；CLAUDE.md 保持轻量，只写代码库特殊情况，避免陈述”Claude 自己能看到”的内容；Skill 写成轻量指南，最该编码进去的是”模型不可能自己知道的那部分”（团队特定观点、踩坑、历史包袱）；References 用测试套件和HTML文件替代文字描述。

5. 两条含金量高的方法论：① 软化绝对表述（“必须验证所有前端更改”→“较大 UX 变更时运行本地应用”），避免模型认真执行一条并不总是对的指令；② Cat 的启发式——写 prompt 时”想一想一个善意的人会怎么误解这句话”，用这条审自己的 CLAUDE.md 一审一个准。

6. 作者本人实践结果：全局 CLAUDE.md 减少 48%（1,289→673）、写作总纲 CLAUDE.md 减少 67%（4,160→1,355）、自动记忆索引减少 28%（7,786→5,606）、手工记忆整体下线（8,645→0），合计从 23,504→9,259 字符（-60%）。Anthropic 精简后的整个 Claude Code 系统提示词约 13k。核心发现：真正的问题不是它大，是里面有一多半是坏的（矛盾信息、过期版本、未索引的记忆、引用不存在的规则文件）。

7. 情境领导框架类比：Hersey 和 Blanchard 的情境领导理论——下属能力低时用指导型，能力高时用授权型。Anthropic 按模型能力配不同的系统提示词就是情境领导的工程实现。prompt 越写越长是管理者还没从”自己把活干好”转变到”通过别人把活干好”。

实操内容保留

六条策略对照表

过去（原文划掉的）	现在
Give Claude Rules	Give Claude Judgement
Give Claude Examples	Design Interfaces
Put it all upfront	Use Progressive Disclosure
Repeat Yourself	Simple Tool Descriptions
Memory in CLAUDE.MDs	Auto-memory
Simple Specs	Rich References

实操精简清单（作者三步法，半小时完成）

一、测量启动 token 成本：把每次会话自动加载的文件（全局 CLAUDE.md、项目 CLAUDE.md、记忆文件）字符数加起来除以 2.2，得到”还没开口就废掉的 token 数”。

二、用两个标准过一遍：每行问：① Claude 读文件能不能推断出来？能，删。② 这是判断还是禁令？禁令改写成正向表述。

三、把禁用词清单和坏例子挪出主上下文：挪到只有审校环节才读的文件里。收益最大、风险最低——不删任何规则，只换位置。

关键改写示例

• ❌ “In code: default to writing no comments. Never write multi-paragraph docstrings or multi-line comment blocks — one short line max.”

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

• ❌ “必须验证所有前端更改”

• ✅ “较大的 UX 变更时运行本地应用”

四条建议

• 系统提示词：只负责告诉 Claude “在哪运行”和”在干什么”，高度绑定产品上下文
• CLAUDE.md：轻量，只写代码库的特殊情况；目录结构、框架等 Claude 自己能看到的不写
• Skill：轻量指南，最核心的是 “模型不可能自己知道的部分”（团队为什么放弃某个方案、接口的历史包袱、什么情况下找谁确认）
• References：基于代码的规格和测试套件

工具设计原则

• 每个工具功能互不重叠，让 Claude 一眼能分清什么时候调哪个
• 砍掉 grep 和 glob 改用原生 bash（功能重复）；但保留了专门的编辑工具（UI 展示需要）
• Thariq 说工具设计”是生物学不是物理学”，很难用 eval 完全量化

关键概念

• 上下文工程 — 从 prompt engineering 到 context engineering 的范式转变
• CLAUDE.md 项目指令 — 如何精简项目级指令文件
• 渐进式披露 — 不是删掉，是挪到用到时才读的位置
• Claude Code — 这次 80% 删减的实践对象
• 提示词工程 — 新旧范式对比
• Fable 5 — 首次全员被删的模型线
• Skill — 如何按新范式写 skill

与其他素材的关联

• 2026-07-05-juejin-context-engineering-harness 同样讨论上下文工程取代传统提示词工程
• 2026-07-26-youtube-fable5-one-prompt-business 展示了新版精简提示词在 Fable 5 编排工作中的实际威力
• 2026-07-25-bnext-karpathy-voice-prompting-method Karpathy 的 10 分钟碎念法是”用更少提示词”的替代策略
• 2026-07-19-juejin-ai-skills-specialized-employee Skills 工程手册同样强调渐进式披露

原文精彩摘录

第一条，软化绝对表述。他们把「必须验证所有前端更改」改成了「较大的 UX 变更时运行本地应用」。Thariq 的解释是要让 prompt 做到 100% 准确。always verify 听起来很负责，但它并不总是对的，存在大量不需要验证的边缘情况。而模型会认真执行一条并不总是对的指令，于是你得到一堆无谓的动作。

他们删掉的那一句是这样的：「In code: default to writing no comments. Never write multi-paragraph docstrings or multi-line comment blocks — one short line max.」换上去的是这句：「Write code that reads like the surrounding code: match its comment density, naming, and idiom.」前一句是规则清单，规定注释写几行；后一句是判断依据，告诉模型拿什么当参照。规则消失了，约束其实更准了。你想，在一个注释本身就迟钝的老代码库里，默认不默认不写注释这条硬规则本身就是错的，而模型会认真执行一条错的指令。

过去有种做法是重要的话说三遍，系统提示词写一次、skill 里再写一次、CLAUDE.md 里又写一次，图个保险。文章说旧模型有时确实需要重复指导，但对新模型已经不需要了。不但不需要，而且有害。同一请求里，「酌情保留文档」和「不要添加注释」这两条同时出现，分别来自系统提示词、skill 和用户请求。模型收到的是一堆互相打架的指令，它只能猜你到底想要哪个。

Anthropic 这次删减，表面是工程决策，本质是一次管理动作。情境领导理论中，领导风格分四档：下属能力低时用指导型、能力高时用授权型。现在再回头看每个模型配一套不同系统提示词这个设计，它就是情境领导的工程实现。前沿模型是能力高的下属给授权，旧模型是能力低的下属给指导，同一件事两套管法。而人做不到，是因为从管理自己到管理他人这一关卡的不是技能，是价值观，你得从自己把话干好变成通过别人把话干好。prompt 越写越长，就是这个卡点的症状。你在替它想每一步，因为你还没把自己当成管理者。