Claude 5系列模型的上下文工程已经彻底变了！
针对Claude Opus 5、Claude Fable 5这类新一代模型,Anthropic把Claude Code的系统提示词删掉了超过80%,编码测试成绩没有出现可衡量的下降。
CC技术团队成员Thariq Shihipar发了一条帖子,阅读量很快冲到229万。题目是《The new rules of context engineering for Claude 5 generation models》。文章讲了一件事:上下文工程的规则正在被重写。全新命令「/doctor」可以帮你一键落地新玩法。
提示词只是冰山一角
发给Claude的一条消息里,提示词本身只占很小一部分。真正构成上下文的,是系统提示词、技能(Skills)、CLAUDE.md文件、记忆,以及其他各种来源拼装起来的信息。这套拼装的工作,Anthropic内部管它叫上下文工程。
和提示词不一样,上下文要被用在成千上万次不同的请求上,没法写得那么具体。用户会输入什么样的话,写上下文的人根本没法提前知道。这也是为什么随着Claude能力的进化,写法也在跟着变。
团队查看了内部使用Claude Code的记录,发现一个反复出现的问题:同一次请求里,经常混进相互打架的指令。比如系统提示词里写着尽量不要写注释,某个技能又说该保留文档,用户自己还提了第三种要求。以前的模型面对这种冲突容易懵,新模型能理解用户意图、判断该听谁的,但前提是它得先把这堆互相矛盾的信息想明白,再做决定。
而且随着Claude Code工具变多,CLAUDE.md不再是唯一的记忆和信息来源。现在有了记忆功能、artifacts、技能,跨会话加载和共享上下文的方式已经不止一种。
六条被推翻的老规矩
文章把这次变化总结成六组对比,每一组都是一条曾经被当成金科玉律、现在被推翻的经验。
以前:给Claude定规矩。现在:让Claude自己判断。
Claude Code刚上线时,团队最担心的是模型做出删文件这类不可挽回的操作,所以系统提示词写得极其死板。举个例子,以前的系统提示词里有这样一段要求:代码里默认不写注释,绝不写多段落的文档字符串或多行注释块,最多一行,不要在用户没要求的情况下创建规划、决策或分析类文档,要靠对话上下文工作,而不是靠中间文件。
问题是,这条规则并不总是对的。有的用户就喜欢详细注释,有的复杂代码段确实需要多行说明。旧模型判断力有限,不加这些护栏就容易写错,团队只能接受这个代价。新模型判断力更强,不靠死规则也能处理好这些取舍。
现在系统提示词里的说法变成了:写的代码要和周围代码风格保持一致,注释密度、命名习惯、写法都跟着走。
以前:给Claude示例。现在:设计接口。
过去教Claude用工具,第一原则是给例子。团队现在发现,示例反而会把模型的探索空间限制住。
更值得花心思的是工具、脚本、文件本身的设计:Claude能拿到哪些参数,这些参数怎样设计才能表达更多信息。
拿Todo工具举例,如果状态字段只是简单列出待处理、进行中、已完成这几个枚举值,这本身就已经在暗示Claude该怎么用它。要求同一时间只能有一项处于进行中状态,这条约束本身就把期望的行为定义清楚了,不需要额外举例说明。
以前:一次性全部给。现在:渐进式披露。
早期Claude Code专注编程,系统提示词里塞满了代码审查和验证的细节。这些内容不是每次都用得上,但真正用到的时候又极其关键。
后来Claude Code在按需加载上变得很擅长,团队把验证和代码审查这类内容拆成独立的技能,由Claude Code在需要时自己去调用,而不是一股脑写进系统提示词。
渐进式披露不止用在技能上,工具本身也是这样。有些工具采用延迟加载,agent必须先用ToolSearch搜出完整定义才能使用,这样团队就能塞进更多工具,比如Task类工具,平时不占上下文,用到时才加载。
同样的思路可以套用到CLAUDE.md和Skill.md文件上。一个常见的误区,是把这些文件当成收纳所有已知经验的总仓库,以为不写进去Claude就找不到。更好的做法是做成一棵文件树,让内容在合适的时机才被加载进来。
以前:反复强调。现在:简单的工具描述。
早期的Claude有时需要指令被重复几遍才记得住,也更容易听从出现在上下文末尾的指令,而不是开头的。所以过去的系统提示词经常是双重表达,主体部分提一遍工具用法,工具描述里再写一遍。
现在团队发现这类重复可以删掉,工具的用法说明直接写进工具描述本身就够了,不用再在系统提示词里重复一遍。
以前:记忆写进CLAUDE.md。现在:自动记忆。
过去团队鼓励用户用井号快捷键,把想记住的内容手动写进CLAUDE.md当作记忆。现在Claude会自动保存和当前工作、和用户相关的记忆,不需要用户手动维护这份文件。
以前:简单规范。现在:丰富引用。
在计划模式下,Claude Code过去很依赖markdown文件存放计划,方便Claude在需要时回头查阅。类似的做法还包括把规范文档存进代码库,供Claude在跨度较长的项目里参考。
团队发现Claude现在能处理更复杂的引用形式。相比简单的markdown文件,Claude可以直接引用由artifacts功能生成的HTML产物。
规范也可以用代码的形式给出,比如一份详细的测试套件,或者另一个代码库里那个需要被移植过来的函数。
评分标准(rubrics)是另一种引用方式。它能让Claude尝试理解并验证使用者的审美判断,比如什么样的API设计才算好,具体做法是启用动态工作流,派出带着这套评分标准的验证agent去打分。
把这套方法用到自己的上下文里
文章最后给出了四块内容各自该怎么写。
系统提示词和具体产品场景强绑定,它要告诉Claude现在身处什么产品、正在做什么事。如果只是用Claude Code,这部分基本不用自己动手改;但如果是在搭建自己的agent框架,这里恰恰是最该花心思打磨的地方。
CLAUDE.md要写得轻量,简单交代清楚这个仓库是干什么的就够了,大部分篇幅应该留给代码库里的坑点。比如某类代码只集中放在一个文件里、别处不允许再放,这种信息才值得写进去,而不是把Claude看一眼文件系统就能知道的显而易见的事情也写进来。渐进式披露在这里同样适用,如果有一整套独特的验证流程,单独做成一个验证技能,在CLAUDE.md里引用它就行。
技能应该被当成轻量级的查阅指南,让Claude在需要的时候能找到相应信息,除非是特别重要的领域,否则不要写得太死。篇幅长的技能尽量拆成多个文件,配合渐进式披露使用。技能最适合用来沉淀那些属于你自己、你的团队或者你的产品特有的经验、知识和最佳实践。
引用可以通过@提及文件的方式加入,让Claude参考跟当前计划相关的深入信息,可以是规范文件、原型,甚至整个代码库。总体上应该优先选择代码形式的文件,因为它们能给Claude提供清晰、高保真的指令,而且这是Claude本身就很熟悉的语言。比如一份设计的HTML原型,通常会比一段文字描述或者一张截图带来更好的结果。
claude doctor登场
围绕这套新思路,Anthropic上线了一个新命令claude doctor。在Claude Code里输入斜杠doctor,就能帮用户自动给技能文件和CLAUDE.md瘦身,把这套化繁为简的经验直接落地成一个工具。
