Claude Code 团队最新复盘：移除 80% 的系统提示词，AI 编程效果竟然没有变差

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% 内容