Claude Code团队复盘发现：删掉80%系统提示词，AI编程效果未降反优，揭示过度约束拖累模型的真相。
核心内容：
1. Anthropic删减80%系统提示词的实践及效果
2. 过度提示词导致系统与技能指令冲突的内耗问题
3. 新提示词策略：从给规则到让模型自主判断，从给示例到设计接口

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% 的系统提示词。我们普通用户，大概也该学着做减法了。

最后和大家分享一个好消息：我的星球社群已经持续运营 800 多天，累计发布主题 2000 个，加入星球的人数达到 1800+ 人，收录精华主题 300+ 篇，各类专栏课程累计上百篇，今年更新的视频教程也已有 50+。

如果感兴趣，可以查看具体介绍：

《AIGC·掘金成长研习社值得你加入》

登录后查看剩余 70% 内容