前段时间，Anthropic 官方透露，面向 Claude 5 的 Claude Code 系统提示词被删掉了 80% 以上。代码评测成绩却几乎纹丝不动。
刚看这个消息时我也很困惑。大家原本还在琢磨怎么把提示词写得更细，怎么突然就大删特删了？这不是自我否定吗？翻完这篇分享才发现，以前为防止模型犯错而加的规则，到了 Claude 5 这里，可能反而开始拖后腿了。
规则写得越多，Claude 怎么还变笨了？
很多人的 CLAUDE.md 都是这么膨胀起来的。Claude 乱加注释，就补一句“禁止添加注释”。它擅自新建 Markdown，再补一句“禁止创建文档”。顺手改了别的文件，赶紧加一条“永远不要修改任务范围之外的代码”。基本是犯一次错，补一条规则。半年后回头一看，文件里全是“必须”“禁止”“永远不要”，不少条目的来历自己都记不清了。
这正好戳中 Anthropic 观察到的痛点：用户说“该写文档的地方就写文档”，系统提示词却说“不要创建分析文档”，而项目里的 CLAUDE.md 又要求“复杂模块必须补文档”。每条单独看都合理，放在一起就相互矛盾。Claude 还没干活，得先判断到底听谁的。上下文是堆了很多，真正重要的信息却被埋在一堆历史补丁里。
这些强规则在老模型上确实有用。模型判断力不足，直接把错误路径堵死，至少能规避最差的结果。但 Claude 5 已经能够结合代码和用户意图做判断，这时候还保留全部防傻规则，模型反倒要花更多精力处理这些枷锁。
删掉规则以后，Claude 靠什么做决定？
留下的规则该怎么写？Anthropic 没有继续把每个动作定死，而是让模型遇到具体问题时先看看项目里的真实情况。比如旧版 Claude Code 对代码注释的要求就非常极端：
默认不写注释。
不要写多段文档字符串。
多行注释最多只能写一行。
这套指令很直白，Claude 绝对看得懂。但它有一个大问题：无视项目原本的风格。有些项目天生注释密集，有些复杂算法也确实需要多行解释。死守“最多一行”的教条，写出来的代码反而格格不入。
新版提示词换成了另一种表述：
写出的代码要像周围原有的代码。
保持相近的注释密度、命名方式和代码习惯。
你可以体会一下两种写法的差异。一种是在告诉 Claude“你只能怎么做”，另一种是给它判断标准，让它先观察项目，再决定怎么做。
这很像带新人。能力不足时，你得把每一步都说死：文件放哪、函数叫什么、注释写几行，恨不得手把手盯着。等他能够独立干活了，再这么管只会把人管废。更有效的说法是：“先看看项目里同类模块怎么写，保持一致，有拿不准的地方再问我。”模型这边其实也差不多。Anthropic 的思路变了——以前很多规则是提前替模型选答案，现在更希望它先看看项目本身，再决定这一处代码到底该怎么写。
上下文工程，重点不是使劲塞上下文
不过在往下聊之前，得先区分一下 prompt 和 context。我们输入的那句话只是 prompt，Claude 真正拿到的 context 还包括系统提示词、CLAUDE.md、Skill、记忆和临时引用的文件。平时说的上下文工程，管的其实是这一整套东西，不只是把用户提示词写得更长。
还有一个变化很关键：很多人理解的上下文工程，就是给模型塞更多资料——项目介绍、技术文档、代码规范、测试流程，反正上下文窗口够大，不塞白不塞。听起来合理，但每次任务真的都需要这些吗？只是改一个按钮颜色，需要先读完整套后端部署规范吗？只补一个单元测试，需要提前知道生产环境怎么回滚吗？绝大部分时候，不需要。
Anthropic 现在采用的办法叫 progressive disclosure（渐进式披露）。做法不复杂：先把当前任务肯定用到的内容放进去，后面真的要审查代码或执行验证时，再让 Claude 去读对应的 Skill。以前 Claude Code 会把代码审查、验证流程等一大堆说明直接塞进系统提示词，模型每次启动都要读，不论用不用得上。现在这些内容被拆到了不同 Skill 里，做代码审查时才加载审查 Skill，需要验证时才读取验证流程。这样一来，Claude Code 能用的工具和知识变多了，常驻上下文反而更轻。这个思路和按需加载模块很像，只是以前给 AI 准备上下文的时候，大家总觉得多放一点总没坏处。
而且渐进式加载除了省 token，也能减少干扰。当前任务只看到眼下需要的信息，模型不容易被无关规则带偏，那几条重要约束也更容易被注意到。所以现在让我重新整理一份上下文，最难的已经不是资料够不够多，而是怎么取舍——有些东西每次都得带着，有些临时再找就行，还有些写进去基本只会添乱。
除了少塞上下文，Claude Code 还改了什么？
另外三处不那么显眼的变化也跟日常使用关系很大。
先说重复指令。早期模型有时记不住上下文前面的要求，或者更容易听后面出现的指令。为保险，Claude Code 会在系统提示词里介绍一次工具，又在工具描述里再讲一次用法。现在 Anthropic 把重复内容删了，工具怎么用，就放回工具自己的描述里。自己项目的规则也一样，同一条要求如果在 CLAUDE.md、Skill 和工具描述里各写一遍，后面很容易改漏，几份内容慢慢就对不上了。
再一个变化是记忆。以前 Claude Code 鼓励用户按 # 把要记住的信息写进 CLAUDE.md。现在有了 Auto-memory，它会自动保存和当前工作、用户相关的记忆，不需要什么都往项目文件里塞。团队约定和仓库里的特殊坑点还是该写，至于个人习惯、上次做到哪里这类信息，继续塞进项目规则里就有点奇怪了。
最后一个变化，我以前还真没太注意。做长任务时，大家习惯先写一份 Markdown 计划或规格文档，再让 Claude 照着做。现在规格不一定非得是一篇文字说明，也可以是一套详细测试、另一个代码库里的参考函数、HTML 原型，甚至是一份评价标准。测试和 HTML 原型最好理解——你花半天描述一个页面每块区域该放哪里，可能还是有歧义，直接给一个能打开的 HTML，信息会具体很多。接口也差不多，一套测试有时比大段文字说得更清楚。规格文档当然还能写，只是碰到合适的任务，可以多给 Claude 一些它能直接检查的东西。
CLAUDE.md 到底该怎么改？
讲了这么多，最后还是得落到自己的项目上。如果你现在的 CLAUDE.md 已经写得又长又全，先别急着继续加规则，可以抽时间做一次大扫除。
第一件事，删掉 Claude 自己就能看懂的内容。项目用 React 还是 Vue，目录里已经清清楚楚；代码用什么命名风格，扫几份文件也能看出来。这类信息没必要每次启动都重复念一遍。
更值得常驻的，是那些只看代码不容易知道的坑：比如某个旧接口暂时不能删，因为还有外部系统在调用；类型必须集中放在一个文件里，这是团队刻意做的约定；测试不能连接某个环境，因为真出过事故。这类信息最好直接告诉它，靠模型自己猜不出来。
第二件事，检查那些特别绝对的规则。搜索一下 CLAUDE.md 里的“永远不要”“任何情况下都禁止”“必须始终”。不是说这些词一律不能用，涉及生产数据、安全边界、危险命令，该严格还是得严格。但如果只是代码风格和工作习惯，可以试试把死命令改成判断标准。
比如：
修改代码时不要添加任何注释。
可以改成：
遵循当前模块的注释习惯。
只在逻辑无法通过代码本身说清楚时补充注释。
第三件事，把不是每次都用到的流程拆出去。代码审查有一套复杂规范，就做成 Review Skill。发布前有十几项检查，就做成 Deploy Skill。前端和后端的要求差别很大，也可以分别放到对应目录。别再让一个 CLAUDE.md 扛下整个公司的知识库，它真的扛不住。
工具方面还有一个有意思的转变。以前大家喜欢给 Claude 大量示例，生怕它不会用。现在 Anthropic 发现，示例给得太死，反而会限制新模型的探索空间。比起一口气写十个工具调用例子，现在更应该先把工具接口整理清楚——参数叫什么，状态有哪些，什么情况下能调用，返回结果长什么样。这些如果没说清楚，后面补再多示例，Claude 用起来还是容易出问题。
▲ TodoWrite 工具描述精简前后对比，旧版约 9100 个字符，新版只保留简短说明、状态枚举和一条约束
如果不想完全靠自己一条条检查，Claude Code 现在也提供了 claude doctor。在 Claude Code 中可以用 /doctor，让它帮忙看看 Skill 和 CLAUDE.md 有没有写得太重。当然，这个结果也不用照单全收，项目里有些坑只有自己知道，最后还得人工过一遍。
为什么模型越强，提示词反而越要少？
前面聊的这些，主要都是 Anthropic 这次对 Claude Code 的调整。再往下，是我最近观察到的另一个现象：有些使用 GPT-5.6 Sol 的开发者装上 Superpowers Skill 后，效果没觉得好多少，任务反而变慢了，Token 消耗也跟着涨。明明只是改个小东西，最后却跑出一整套流程。Superpowers 会带着 Coding Agent 讨论需求、设计方案、写计划、做 TDD，然后再开子 Agent 开发和审查代码。这套方法本身很专业，但它的 using-superpowers Skill 要求，只要有 1% 的可能适用，就必须调用 Skill，“任务太简单”也不能成为跳过理由。哪怕是只改一个函数、改一处配置，也要先做设计、让用户确认、写规格文档，然后才能进入实现计划。
放在以前的模型上，这套流程很好理解：模型容易漏步骤，那就提前把路铺好，让它照着走。但 GPT-5.6 Sol 自己已经会看仓库、做计划、调用工具、开子 Agent，最后也知道要验证结果。这时候 Skill 再把这些步骤规定一遍，多少有点重复指挥了，模型自己想一遍，Skill 又带着它从头走一遍。
有网友提到，规划阶段几乎把代码写了一遍，到了执行阶段又重新写一遍，Token 消耗直接翻了几倍。这件事也让我重新想一下，为什么现在的模型越来越强，Anthropic 和 OpenAI 反而都在让大家精简提示词。
以前模型不会规划，我们就把第一步、第二步都给它写好；它不会检查结果，那就再补一套固定的自检流程。这些规则当时有用，但模型自己慢慢学会以后，再全部留着，可能就成了额外负担。OpenAI 在 GPT-5.6 的官方提示指南里，第一条建议就是“使用更精简的提示词”。他们还给出一组内部 Coding Agent 评测数据：删掉重复指令和示例、简化工具描述以后，评测分数提升约 10%~15%，总 Token 减少 41%~66%，成本下降 33%~67%。这个结果多少有点反直觉，但也说明提示词写得多，确实不等于模型做得好。
所以我现在越来越觉得，模型能力上来以后，我们反而要开始给 AI 做减法了。过去大家总觉得，要把 AI 用好，就得装更多 Skill、写更长的提示词，再把每一步安排得清清楚楚。这个思路放在能力没那么强的模型上确实有用，因为你不告诉它下一步做什么，它可能真不知道。但到了新模型这里，情况有点变了。以前那些约束很重的 Skill，可能不再是在帮它，反而会挡住它自己的判断。明明改一个函数就能结束，Skill 却要求它先讨论需求、写设计、拆计划，再开子 Agent。流程走得很完整，活反而干慢了，有时还会被带偏。
这么看，给 Skill 做减法，也不只是少装几个就行。更该删的，其实是 Skill 里那些替模型做判断的内容。规定第一步做什么、第二步做什么，这类流程会随着模型变强越来越容易过时。项目内部知识、专用工具、安全边界和验收方法，这些模型自己猜不到，该留还是要留。真碰到复杂架构改造、线上故障或者安全审查，Superpowers 这类完整流程也有价值。那以后怎么判断一个 Skill 还该不该用？可以先看一件事：它有没有给模型补充新的信息和能力。要是只是把模型每一步该怎么做重新规定一遍，新模型可能已经会了，再套一层流程，反而容易碍事。
最后
看完 Anthropic 这次调整，我也准备回头翻一下自己项目里的 CLAUDE.md。以前模型出一次问题，我就顺手补一条规则，时间久了，里面估计也留了不少现在已经没必要的东西。当然，我不会因为这篇文章就把规则全删掉——生产环境、安全边界，还有项目里那些只看代码看不出来的坑，该写还是得写。只是下次 Claude 做错事情时，我可能不会马上再补一句“永远禁止”，而是先看看，这到底是模型不知道，还是我已经管得太细了。
如果你也有一份写了很久的 CLAUDE.md，可以抽时间重新翻一下。里面有些规则可能还很重要，也可能只是当年为了解决某一次问题临时加上去，后来一直没人动。哪些该留，哪些可以先拿掉，还是得结合自己的项目试一试。更多开发者经验分享，欢迎来云栈社区一起交流。
参考资料：https://x.com/trq212/status/2080710971228918066
发表于 昨天 04:04
|
查看: 12|
回复: 0
