Claude Code 的负责人 Thariq Shihipar 最近写了一篇博客，关于 Claude 5 模型 context engineering 新规则的文章，读完之后收获很大。
这篇文章讲的是，随着模型能力的进化，过去那些给 AI 写提示词、搭建上下文的最佳实践，很多已经过时了。Anthropic 自己在 Claude Code 这个产品上做了大量删减，系统提示词砍掉了超过 80%，结果在编程评测上的表现居然没有下降。
这个数字挺震撼的。我们平时写提示词，总觉得写得越详细越好，规则越多越安全。但 Anthropic 的经验告诉我们，过度约束反而会拖累模型的表现。
他们在复盘内部使用记录的时候发现，系统提示词、技能指令和用户请求之间经常互相打架。比如系统提示词说「适当写注释」，技能指令又说「不要加注释」，模型夹在中间，得花额外的精力去判断到底该听谁的。这种内耗是看不见的，但确实在消耗模型的推理能力。
想想我们日常工作中也是这样。一个新员工入职，如果你给他一本 200 页的操作手册，里面还有好几处自相矛盾的规定，他大概率会变得畏手畏脚，每做一步都要翻手册确认。但如果这个人本身能力很强，你只需要告诉他大方向和几个关键的坑，剩下的让他自己判断，效果反而更好。
Anthropic 总结了六条过去被奉为圭臬、现在已经变成误区的做法，我觉得每一条都值得细说。
从「给规则」到「让模型自己判断」
过去为了避免最坏情况，比如模型乱删文件，他们会写非常强硬的规则。像是「代码里默认不写注释」「永远不要写多行文档字符串」「不要创建规划文档」这种。
这些规则在大多数情况下确实管用，但总有一部分场景是例外。比如某段特别复杂的代码，确实需要多行注释才能让后来的人看懂。旧规则一刀切，模型只能照做，结果就是该写注释的地方也不写了。
现在新的提示词变成了一句话：写出来的代码要和周围的代码风格一致，匹配它的注释密度、命名习惯和惯用写法。
这个转变的本质是，模型已经有足够好的判断力了，你不需要替它做每一个决定。你只需要告诉它原则，它能根据具体情况灵活应对。
这让我想到教育孩子。小时候你得告诉他过马路要看红绿灯，不能碰插座，这些是硬规则。但等他长大了，你还事无巨细地规定他几点睡觉、穿什么衣服，那就是过度管控了。好的引导是给方向，不是给清单。
从「给示例」到「设计好接口」
以前教模型用工具，第一条铁律就是给它看示例。你怎么调用这个 API，参数怎么填，返回什么结果，都得写清楚。
但 Anthropic 发现，对于新一代模型来说，示例反而会限制它的探索空间。模型看到示例之后，会倾向于照着示例的模式来，不太敢尝试其他可能更好的用法。
他们现在的做法是，把精力花在工具本身的设计上。参数名起得清楚，枚举值列得明白，工具的功能边界定义得清晰。模型看到这些信息，自然就知道怎么用了。
比如一个待办事项工具，状态字段设计成 pending、in_progress、completed 三个枚举值，再加一句「同时只保持一个任务处于进行中」，模型就完全理解了该怎么操作。不需要写一大段示例来演示。
这个道理放到产品设计里也成立。一个好的产品界面，用户看一眼就知道怎么用，不需要看说明书。如果你的工具必须配一堆教程才能用起来，那多半是设计本身有问题。
从「一股脑全塞进去」到「按需加载」
过去 Claude Code 的系统提示词里塞了大量信息，包括怎么做代码审查、怎么验证结果这些内容。这些信息不是每次都用得上，但万一用到了又很关键，所以就一直放在那里占着位置。
现在他们把这些内容拆出来，做成独立的技能模块。模型需要的时候自己去调用，不需要的时候就不加载。甚至有些工具也做成了延迟加载的形式，模型得先搜索到它的定义，才能使用。
这个思路叫渐进式披露。核心信息放在最前面，详细信息按需展开。
我觉得这个思路特别适合用来管理知识。我们很多人记笔记，喜欢把所有东西都堆在一个文档里，觉得这样方便查找。但实际上，信息太多的时候，找东西反而更难。不如把笔记分层，核心要点放在最上面，细节放在子文档里，需要的时候再点进去看。
从「重复强调」到「工具描述里写清楚就行」
早期的模型有个毛病，上下文窗口里靠后的内容比靠前的更容易被注意到。所以为了确保模型记住某些规则，他们会在系统提示词里写一遍，在工具描述里再写一遍。
现在不需要了。新模型对整个上下文窗口的注意力分配更均匀，把指令写在工具描述里就够了，不用在系统提示词里重复。
这个变化看起来小，但意义很大。它意味着你可以把系统提示词写得更精简，把每个工具的使用说明放在它自己的描述里，各管各的，互不干扰。整个上下文的结构会更清晰，维护起来也更方便。
从「手动存记忆」到「自动记忆」
以前用 Claude Code，用户得主动按快捷键把重要信息存到 CLAUDE.md 文件里，相当于手动帮模型记笔记。
现在模型会自动保存和你工作相关的记忆。你不用操心哪些该记哪些不该记，它自己会判断。
这个进步看起来理所当然，但背后反映的是模型对「什么信息重要」的理解能力在提升。它不再是一个被动的工具，开始有了一点主动管理上下文的能力。
从「简单的文字规格」到「丰富的参考资料」
过去给模型看的参考资料，基本就是 Markdown 格式的规格说明文档。
现在模型能处理更复杂的参考形式了。可以是 HTML 格式的设计稿，可以是另一个代码库里的函数实现，可以是一套完整的测试用例，甚至可以是一份评分标准，让模型按照这个标准去验证输出质量。
这意味着你跟模型沟通的方式可以更丰富。与其用文字描述你想要什么样的设计，不如直接给它一个 HTML 原型。与其解释你的代码风格偏好，不如给它看一段你觉得写得好的代码。模型能从这些具体的参考中提取出比文字描述更精确的信息。
最后，怎么组装你的上下文
Anthropic 把整个上下文分成了四层。
系统提示词，告诉模型它在什么产品里、要做什么事。这一层跟产品强绑定，普通用户一般不用改。
CLAUDE.md 文件，保持轻量，简单说明你的项目是干什么的，重点写那些模型看文件系统看不出来的坑。比如你的项目有个特殊规定，所有类型定义都放在一个文件里，这种事模型自己猜不到，你得告诉它。
技能模块，当作轻量级的指南，让模型在需要的时候去查阅。不要把技能写得太死板，除非是特别重要的领域。长的技能要拆分成多个文件，用渐进式披露的方式组织。最好的技能是那些编码了你个人、你的团队或者你的产品特有的观点、知识和最佳实践的内容。
参考资料，用来提供当前任务的详细背景。优先用代码形式的参考，因为代码对模型来说是一种高保真的指令语言。一个 HTML 设计稿通常比一段文字描述或者一张截图能产生更好的结果。
读完这篇文章，我最大的感受是，和 AI 协作这件事，正在从「精确控制」走向「信任与引导」。
早期的模型像一个刚入行的实习生，你得手把手教，每一步都写清楚，不然它就会犯各种低级错误。但现在的模型更像一个有经验的同事，你告诉他目标和几个关键约束，剩下的他自己能搞定。
如果你还在用老方法写提示词，写了一大堆规则和示例，可能反而在限制模型的发挥。试着删掉一些，给模型更多判断空间，看看效果会不会更好。
Anthropic 自己都砍掉了 80% 的系统提示词。我们普通用户，大概也该学着做减法了。
粤ICP备14082021号
免费POC，
零成本试错
