我听 Claude 官方的，砍掉了 80% 的提示词，结果。。

大家好，我是程序员鱼皮。

前段时间 Anthropic 在官方博客发了一篇文章，说他们针对 Claude Opus 5 和 Fable 5 这两个新模型，删掉了 Claude Code超过 80%的系统提示词，但在编码评测上的表现居然没有下降！

我当时的第一反应是：之前我花大力气写的那些提示词都白写了？？？

删掉 80% 的提示词，效果居然没变？

但仔细想想，又觉得很合理。之前我写的很多规则，本质上是在弥补旧模型判断力的不足。当模型能力跟上来之后，这些规则反而成了束缚。

这就好比你教一个新手司机开车，需要告诉他红灯停绿灯行、转弯前先打转向灯。

但你不会对一个十年驾龄的老司机重复这些话，因为他早就内化了这些规则。你多说一遍，他反而会分心。。

Anthropic 在他们关于上下文工程的系列博客中提出了 2 个概念，可以很好地解释这件事。

第一个叫注意力预算（Attention Budget）。AI 模型和人一样，工作记忆是有限的。你给它的上下文规则越多，它花在权衡这些规则上的注意力就越多，留给真正干活的注意力就越少。

第二个是上下文的边际递减效应。上下文中的 Token 数量越多，模型精确召回信息的能力就越差。就像你一次性塞给一个人 100 页文档，让他同时记住每一页的细节，根本不现实。

注意力预算与边际递减效应

现在大家应该明白 Anthropic 为什么要砍这么多系统提示词了吧。

那具体是怎么砍的呢？

Anthropic 具体改了什么

Anthropic 在这篇官方博客中总结了好几个关键转变，我挑几个最有价值的来聊聊。

1、从定死规则到让模型自己判断

早期为了防止 Claude 误删代码或乱写注释，通过系统提示词把规则写得很死，比如下面这段：

默认不写注释。永远不要写多行文档字符串或多行注释块，最多一行简短注释。除非用户要求，否则不要创建规划、决策或分析文档。

这种「一刀切」的规则肯定不够灵活。比如有些复杂代码确实需要多行注释，有些用户也有自己的文档偏好。

但没办法，旧模型的判断力不够，不这么约束它就容易乱来，团队只能接受这个折中方案。

到了新模型时代，这条长长的规则被精简成了一句话：

写出来的代码要像周围的代码，匹配它的注释密度、命名方式和惯用法。

这样一来，模型就会根据项目现有的代码风格来自动适配，而不是被前置规则限制住了选择。

从定死规则到让模型自己判断 2、从给示例到设计好接口

以前有个经典的提示词技巧叫 Few-shot，就是给 AI 举例子。

比如 AI 不知道怎么调用某个工具，你就写 3 个示例给它看。

但 Anthropic 发现，在新模型上面，示例反而会限制模型的探索空间，因为新模型的理解能力比你给的示例更强，示例反而把它框住了。

他们的建议是，与其写一堆示例教 AI 怎么用工具，不如把工具本身的用法设计得更清晰。

他们拿 Claude Code 里管理待办任务的 Todo 工具来举例，这个工具有待办、进行中、已完成三种状态，参数名分别叫pending、in_progress、completed，AI 一看就知道什么意思，根本不需要你再写示例教它。设计好的接口自己就能说明用法，只有设计辣鸡的接口才需要一堆说明书。

3、从一股脑全塞进去到按需加载

以前 Claude Code 的系统提示词里包含了大量关于代码审查、验证等方面的详细指引。这些内容不是每次都用得到，但万一需要的时候又很关键，所以只能全塞进去。

现在 Anthropic 把这些内容拆成了独立的 Skills 技能包，模型在需要的时候才去加载。甚至连一些工具定义也做成了「延迟加载」模式，模型要用的时候才会通过 ToolSearch 去获取完整的工具描述，平时不占用上下文。

Anthropic 把这种策略叫做Progressive Disclosure 渐进式披露，经常看我文章的朋友应该对这个术语不陌生了吧？

渐进式披露按需加载

这个思路也适用于我们自己写的 CLAUDE.md 和 Skills 文件。很多人喜欢把 CLAUDE.md 写成一个事无巨细的百科全书，觉得如果不写全，模型就找不到。

但 Anthropic 建议把内容拆成多个文件，形成一个树状结构。就像你整理电脑文件一样，不会把所有文档都堆在桌面上，而是按类别分到不同的文件夹里，需要什么就打开什么。模型处理上下文也是同样的道理，让它在合适的时机加载合适的内容就行了。

4、从手动记忆到自动记忆

以前用户需要手动按#快捷键把重要信息保存到 CLAUDE.md，现在 Claude 会自动保存和你工作相关的记忆。

CLAUDE.md 的定位也因此发生了变化，Anthropic 建议将它保持轻量，重点写项目中的「坑」和那些模型看代码看不出来的特殊约定。像目录结构、依赖列表这种模型自己就能读到的信息，就不需要再手动写进去了。

从手动记忆到自动记忆 5、矛盾指令的问题

Anthropic 在审查自己团队使用 Claude Code 的对话记录时，还发现了一个有意思的问题。

同一个请求里，系统提示词说的是「适当添加文档」，但 Skills 里又写了「不要添加注释」，两条指令是矛盾的。

虽然模型大部分时候能根据上下文猜到用户的真实意图，但它得额外花精力去处理这些冲突，白白浪费了注意力预算。

于是他们砍掉了冗余的规则，这类矛盾自然就少了很多。

矛盾指令让模型困惑

OK，原理讲得差不多了。为了直观地感受新模型在短提示词下的表现，我做了一组实战对比测试。

实战对比

我用的是 Cursor + Claude Opus 5 来做这个测试，任务是让 AI 复刻一个 Cursor 网页版，分别用风格完全不同的两种提示词来跑。

第一种是规则堆砌型的长提示词，包含一堆具体的技术要求和开发步骤：

第二种是短提示词，就 5 行话，只说了要做什么和用什么方式调研：

基于 VS Code 开源生态做一个类似 Cursor 的 Web AI 编程工具，
支持 Editor Window 和 Agents Window。
先用 Firecrawl 搜 Cursor 3 的产品设计，
再用 Context7 查 monaco-vscode-api 的 Web 集成方案，
调研完先出技术方案，确认后再写代码。

有趣的是，两种提示词在正式写代码之前就表现得不一样了。

在前期调研规划阶段，短提示词那边主动进入了 Plan 模式，先规划好完整的 Todo 列表才开始动手；长提示词那边反而没有进入 Plan 模式，收到指令就直接开写了。

短提示词规划后的 Todo 列表

从代码量来看，短提示词版本一共跑出了12984行代码，长提示词版本只有8384行，少了将近三分之一。可能我们正常的直觉是，提示词越长、信息量越大、生成的代码量就应该越多。但结果恰恰相反，说明短提示词下 AI 反而更能「肆无忌惮」地探索和生成。

从成品效果上来看，短提示词生成的代码一次跑通，而且功能相当齐全。

可以正常切换 Edit 和 Agent 模式窗口，目录树加载正常，文件的增删改查都没问题，代码语法高亮和自动补全也有，甚至连 git 功能都做了。除此之外还支持切换主题、终端可以正常使用、搜索和快捷键也都到位了。最关键的是，Agent 模式可以正常接入模型来生成代码。

短提示词版本

长提示词生成的效果就有点儿翻车了…… 放张图大家自己感受一下差距吧，高下立判。

长提示词版本

得益于 Opus 5 模型的智能，两种提示词生成的 Cursor 网页版都能正常调用 AI Agent 来生成代码。我把它们都接入了 DeepSeek API，让它们各自写一个贪吃蛇小游戏，用的模型是最新的 DeepSeek V4 Flash，生成过程很丝滑。

短提示词做的 Cursor 在生成代码前会显示思维链和调用了什么工具，整个交互体验更完整。

长提示词做的 Cursor 则是直接开写，没有思维链展示。

不过两个版本的交互体验都做得不错，举个例子，生成的代码都带有接受和拒绝的操作按钮。

最后两个版本的 Cursor 生成的贪吃蛇小游戏都能正常运行。AI 发展成现在这样，我居然能够轻松地用 AI 编程工具做个 AI 编程工具，然后让做出来的 AI 编程工具再来 AI 编程了……

测试做到这里结果已经很明显了。短提示词开发的 Cursor 无论是功能完善度、代码质量还是一次跑通的成功率，都完胜长提示词版本。

核心原因就在于，长提示词把模型的行为框住了，它只敢在你划定的范围内做事。而短提示词给了模型足够的探索空间，模型自己根据对 Cursor 这个产品的理解，主动补全了很多它认为应该有的功能。

我们应该怎么做

以前模型能力不够，对很多产品和技术的认知是模糊的，你必须手把手告诉它每个细节。现在新模型的训练数据更丰富、推理能力更强，再加上有 MCP、Skills 这些工具让模型的探索自由度更高，那些重复的规则反而成了负担，既浪费 Token，又抢占模型干活时的注意力，还容易跟其他 Skills 的规则产生冲突。

那我们该怎么判断一条提示词有没有必要写呢？

我是这样判断的：如果一件事是这个任务天然就包含的常识，就不用写。

比如你让 AI 写一个 REST API 接口，不需要告诉 AI 要处理错误、要返回 JSON，这些模型已经知道了。

如果一件事是这个任务的特殊要求，跟通常做法不一样，才需要明确告诉模型。

比如你的项目规定所有接口必须用 snake_case 命名、错误码必须遵循某个内部标准，这些才是值得写进规则的内容。

换个角度来说，你的代码仓库本身就是很好的提示词。项目结构、代码风格、测试用例，这些模型都能自己读到并理解。你要做的是把项目架构设计好，而不是把规则写成一篇小作文。规则写太多，模型反而会把注意力浪费在权衡你的各种约束上面。

用 /doctor 优化项目规则

为了帮开发者跟上这个变化，Claude Code 还内置了一个/doctor命令（也可以用/checkup）。这个命令可以自动扫描你的 Skills、CLAUDE.md 等配置文件，帮你检测哪些内容是冗余的、哪些可以精简。

具体来说，它会检查你的 CLAUDE.md 里有没有写目录结构、依赖列表这些模型自己就能从代码库读到的信息，如果有就建议你删掉。它还会找出没用到的 Skills 和 MCP 服务，检测本地和仓库里的 CLAUDE.md 有没有重复或矛盾，针对那些不需要每次都加载的内容，建议你迁移到可以按需加载的 Skills 里。而且所有变更都会先给你看报告，等你确认后才会执行。

我用自己的项目实测了一下，它帮我优化了一部分配置内容，但没有对 CLAUDE.md 做大的改动，说明我这个项目的规则还算健康。

AI 编程领域的变化真的太快了，前几个月我还在研究怎么把提示词写得更完美，还觉得项目规则写得越详细 AI 干活的方向就越准确。结果现在官方直接宣布，之前精心打磨的很多规则其实都是束缚。。

Anthropic 在官方博客的最后总结了一句话，我觉得特别精妙：找到那组最小的、高信号的 Token 集合，来最大化你想要的结果。

以后写提示词，少即是多。

Less is More，你的很多提示词真的可以丢掉了。

OK 就分享到这里，如果你对 AI 编程感兴趣，欢迎阅读我免费开源的 ，上千张图、几十万字，带你从 0 开始快速学会 AI 编程，做出自己的产品、跑通变现全流程，一次拿捏。

我是鱼皮，持续分享 AI 编程干货，觉得有用的话记得点赞收藏和关注。

评论区聊聊：你有自己写过完整的提示词或者 CLAUDE.md 规则文件吗？