claude.dev 解读
EngineeringThariq Shihipar2026-07-24约 7 分钟阅读原文 ↗

The new rules of context engineering for Claude 5 generation models

新一代模型删掉八成系统提示仍无可测损失,上下文该给判断与接口而非规则

主张
6
审视
7
遗漏
3
  1. 01Anthropic 称,面向 Claude Opus 5、Claude Fable 5 这一代模型,他们删掉了 Claude Code 系统提示中超过 80% 的内容,内部编码评测上没有可测到的损失。原因是新模型判断力更强,旧时代的硬规则、示例和重复指令反而会互相冲突,或把模型限制在示例划定的探索范围里。
  2. 02新的上下文工程有五条要点:用判断力代替规则;用接口设计(参数、enum)代替示例;用渐进式披露代替把所有东西塞在开头;工具说明只写在工具描述里;用 auto-memory 和富引用(HTML artifact、测试套件、rubric)代替手写记忆和简单 spec。
怎么读这篇
作者主张 · Thariq Shihipar我们的审视
01

删掉八成系统提示

新一代模型下,系统提示可以大幅缩减,基本不损失效果。

机制拆解

旧系统提示里的很多条目,原本是为了防止能力较弱的模型出现最坏情况(比如删文件、乱写注释)而加的保险。模型判断力提升后,这些保险的边际价值趋近于零,却仍然占着上下文、带来约束。删掉之后,模型改用周边上下文自行判断。这条主张的依据只有 Anthropic 自己的编码评测,正确性取决于这些评测能否灵敏地测出差异,见 critique。

“We removed over 80% of Claude Code’s system prompt” ¶4

数字口径

「over 80%」「no measurable loss」只限于 Anthropic 内部的 coding evaluations。评测集、指标、样本量和置信区间都没有公开。「测不出损失」不等于「没有损失」,还取决于评测的灵敏度。而且内容创作、品牌合规这类任务不在这些评测的覆盖范围里。

自己验证每种配置重复多次,看差异是否超过同配置内部的波动。
02

冲突指令不如判断标准

系统提示、技能和用户请求里互相冲突的指令,会迫使模型额外推理来调和,所以应该从「给规则」改成「给判断标准」。

机制拆解

上下文由多个来源拼装而成:系统提示写「酌情写文档」,技能写「不要加注释」,用户又说「照旧的做」。每条都是绝对化的规则,合在一起就自相矛盾,模型必须先判断听谁的。新写法把规则换成可推断的标准,例如「匹配周边代码的注释密度、命名和习惯」,让模型从现场上下文推出答案,而不是在多条硬规则之间仲裁。

“Claude must think more carefully about these overlapping and conflicting messages” ¶8

遗漏

文章没有说明哪些规则必须保留。「except in highly important areas」没有给出判定标准。它也没有讨论不同来源指令冲突时的优先级,只说「删掉」。

自己验证自己定一条判定标准:一旦出错,代价是否不可逆或会对外暴露。拿现有 CLAUDE.md 逐条打标,只删可逆、对内的条目,并记录删除理由,事后回看有没有踩坑。
03

示例会锁住探索空间

工具示例会把模型锁在示例划定的探索空间里,更好的办法是把意图编码进接口设计。

机制拆解

示例是一种很强的锚定,模型倾向于照着示例的样子用工具。参数结构本身就能表达用法,比如 TodoWrite 的 status 只设成 pending / in_progress / completed 三值 enum,再加一条「同一时刻只能有一项 in_progress」,就足以约束行为。原文图里,TodoWrite 的工具描述从约 9,100 字符缩成了一句话。

“giving examples actually constrains them to a certain exploration space” ¶17

数字口径

TodoWrite 描述从约 9,100 字符缩成一句话,原文只给了前后对比图,没有给出行为层面的对比数据(例如任务列表的使用率、状态错误率)。

自己验证无法直接复现官方数据。可以在 agent-harness-lab 里自造一个工具,分别写一版长描述带示例、一版 enum 短描述,跑同一组任务,统计调用是否合规。
04

上下文做成按需文件树

渐进式披露:不要把 CLAUDE.md 和 SKILL.md 写成无所不包的中央仓库,而是做成一棵按需加载的文件树。

机制拆解

代码审查、验证这类偶尔才关键的知识,从常驻的系统提示移进技能,需要时才调用。工具也一样,可以做成 deferred loading,用 ToolSearch 按需拉取完整定义,不用时不占上下文。原文认为「不写进主文件模型就找不到」是一个过时的迷思,新模型已经很会在合适的时机加载合适的上下文。

“consider having a tree of files that can be loaded at the right time” ¶23

可复现性

渐进式披露和「拆 CLAUDE.md」的收益可以在本地验证:拆完之后,模型是否仍然在需要时读到正确的子文件,可以观察出来。

自己验证按 L-033 的思路,用 PreToolUse hook 记录技能调用和 Read 的文件路径。
05

CLAUDE.md 只写坑

CLAUDE.md 要轻量:简短说明仓库是做什么的,大部分 token 留给代码库里的坑(gotchas),不写模型自己看文件系统就能知道的「显而易见」的事。

机制拆解

CLAUDE.md 每次请求都会加载,适用面广,所以不能写得太具体。值得常驻的只有反直觉、从仓库结构推不出来的约定,比如「类型只放在一个单体文件里」。其余内容(比如验证流程)做成技能,在 CLAUDE.md 里引用。技能则应编码只属于你或你团队的观点和实践,除高度重要领域外避免过度约束。

“spend most of the tokens on gotchas inside of the codebase” ¶33

这一点暂无对应的审视。

06

代码形态引用保真最高

引用(reference)优先用代码形态的高保真材料,比如 HTML mockup、测试套件、可移植的函数;rubric 加 verifier 代理可以用来校验「品味」。

机制拆解

代码是模型非常熟悉的语言,表达的指令精确、无歧义。一份 HTML 设计稿携带的信息,比文字描述或截图更完整、更可执行。rubric 把隐性的品味标准显式化后,可以借助 dynamic workflows 派生 verifier 代理逐条核对,见 ¶30。

“a HTML mockup of a design will generally produce better results” ¶39

这一点暂无对应的审视。

作者没有直接谈到这一点。

厂商视角

文章作者是 Anthropic 员工,内容同时在推广自家功能:claude doctor、auto-memory、artifacts、dynamic workflows、deferred tools。「少写约束、交给模型判断」的叙事,也天然有利于展示新模型的能力。

自己验证不要直接相信「无损失」。

作者没有直接谈到这一点。

遗漏

文章推荐 auto-memory 代替手写记忆,但没有谈记忆的质量控制:错误记忆如何发现和清除,记忆膨胀如何治理。

自己验证定期抽查记忆文件,看其中提到的路径和标识符是否仍然存在,统计失效比例,作为 auto-memory 可信度的本地指标。

作者没有直接谈到这一点。

遗漏

文章没有讨论上下文结构变化对 prompt cache 命中率和成本的影响(比如精简系统提示、deferred loading、按需加载技能)。

01

机制聚焦

TodoWrite 描述的瘦身

把用法从示例搬进参数设计,描述更短,反而不再束缚模型的探索

示例式描述
接口式描述
篇幅
约 9,100 字符的用法清单与示例
一句话说明用途
用法引导
列出何时使用并逐个演示
status enum 本身暗示用法
行为约束
靠示例覆盖各种情形
只规定同时一个 in_progress
探索空间
被限制在示例划定的范围
由参数表达意图,留出判断
依据原文 ¶17 ↗
02

核心观点

01

删掉八成系统提示

新一代模型下,系统提示可以大幅缩减,基本不损失效果。

机制拆解

旧系统提示里的很多条目,原本是为了防止能力较弱的模型出现最坏情况(比如删文件、乱写注释)而加的保险。模型判断力提升后,这些保险的边际价值趋近于零,却仍然占着上下文、带来约束。删掉之后,模型改用周边上下文自行判断。这条主张的依据只有 Anthropic 自己的编码评测,正确性取决于这些评测能否灵敏地测出差异,见 critique。

We removed over 80% of Claude Code’s system prompt¶4 ↗

02

冲突指令不如判断标准

系统提示、技能和用户请求里互相冲突的指令,会迫使模型额外推理来调和,所以应该从「给规则」改成「给判断标准」。

机制拆解

上下文由多个来源拼装而成:系统提示写「酌情写文档」,技能写「不要加注释」,用户又说「照旧的做」。每条都是绝对化的规则,合在一起就自相矛盾,模型必须先判断听谁的。新写法把规则换成可推断的标准,例如「匹配周边代码的注释密度、命名和习惯」,让模型从现场上下文推出答案,而不是在多条硬规则之间仲裁。

Claude must think more carefully about these overlapping and conflicting messages¶8 ↗

03

示例会锁住探索空间

工具示例会把模型锁在示例划定的探索空间里,更好的办法是把意图编码进接口设计。

机制拆解

示例是一种很强的锚定,模型倾向于照着示例的样子用工具。参数结构本身就能表达用法,比如 TodoWrite 的 status 只设成 pending / in_progress / completed 三值 enum,再加一条「同一时刻只能有一项 in_progress」,就足以约束行为。原文图里,TodoWrite 的工具描述从约 9,100 字符缩成了一句话。

giving examples actually constrains them to a certain exploration space¶17 ↗

04

上下文做成按需文件树

渐进式披露:不要把 CLAUDE.md 和 SKILL.md 写成无所不包的中央仓库,而是做成一棵按需加载的文件树。

机制拆解

代码审查、验证这类偶尔才关键的知识,从常驻的系统提示移进技能,需要时才调用。工具也一样,可以做成 deferred loading,用 ToolSearch 按需拉取完整定义,不用时不占上下文。原文认为「不写进主文件模型就找不到」是一个过时的迷思,新模型已经很会在合适的时机加载合适的上下文。

consider having a tree of files that can be loaded at the right time¶23 ↗

05

CLAUDE.md 只写坑

CLAUDE.md 要轻量:简短说明仓库是做什么的,大部分 token 留给代码库里的坑(gotchas),不写模型自己看文件系统就能知道的「显而易见」的事。

机制拆解

CLAUDE.md 每次请求都会加载,适用面广,所以不能写得太具体。值得常驻的只有反直觉、从仓库结构推不出来的约定,比如「类型只放在一个单体文件里」。其余内容(比如验证流程)做成技能,在 CLAUDE.md 里引用。技能则应编码只属于你或你团队的观点和实践,除高度重要领域外避免过度约束。

spend most of the tokens on gotchas inside of the codebase¶33 ↗

06

代码形态引用保真最高

引用(reference)优先用代码形态的高保真材料,比如 HTML mockup、测试套件、可移植的函数;rubric 加 verifier 代理可以用来校验「品味」。

机制拆解

代码是模型非常熟悉的语言,表达的指令精确、无歧义。一份 HTML 设计稿携带的信息,比文字描述或截图更完整、更可执行。rubric 把隐性的品味标准显式化后,可以借助 dynamic workflows 派生 verifier 代理逐条核对,见 ¶30。

a HTML mockup of a design will generally produce better results¶39 ↗

03

批判性审视

厂商视角

文章作者是 Anthropic 员工,内容同时在推广自家功能:claude doctor、auto-memory、artifacts、dynamic workflows、deferred tools。「少写约束、交给模型判断」的叙事,也天然有利于展示新模型的能力。

自己验证不要直接相信「无损失」。
数字口径

「over 80%」「no measurable loss」只限于 Anthropic 内部的 coding evaluations。评测集、指标、样本量和置信区间都没有公开。「测不出损失」不等于「没有损失」,还取决于评测的灵敏度。而且内容创作、品牌合规这类任务不在这些评测的覆盖范围里。

自己验证每种配置重复多次,看差异是否超过同配置内部的波动。
数字口径

TodoWrite 描述从约 9,100 字符缩成一句话,原文只给了前后对比图,没有给出行为层面的对比数据(例如任务列表的使用率、状态错误率)。

自己验证无法直接复现官方数据。可以在 agent-harness-lab 里自造一个工具,分别写一版长描述带示例、一版 enum 短描述,跑同一组任务,统计调用是否合规。
可复现性

渐进式披露和「拆 CLAUDE.md」的收益可以在本地验证:拆完之后,模型是否仍然在需要时读到正确的子文件,可以观察出来。

自己验证按 L-033 的思路,用 PreToolUse hook 记录技能调用和 Read 的文件路径。
遗漏

文章没有说明哪些规则必须保留。「except in highly important areas」没有给出判定标准。它也没有讨论不同来源指令冲突时的优先级,只说「删掉」。

自己验证自己定一条判定标准:一旦出错,代价是否不可逆或会对外暴露。拿现有 CLAUDE.md 逐条打标,只删可逆、对内的条目,并记录删除理由,事后回看有没有踩坑。
遗漏

文章推荐 auto-memory 代替手写记忆,但没有谈记忆的质量控制:错误记忆如何发现和清除,记忆膨胀如何治理。

自己验证定期抽查记忆文件,看其中提到的路径和标识符是否仍然存在,统计失效比例,作为 auto-memory 可信度的本地指标。
遗漏

文章没有讨论上下文结构变化对 prompt cache 命中率和成本的影响(比如精简系统提示、deferred loading、按需加载技能)。

本篇未覆盖(3)
风格