Claude Code 团队删掉八成系统提示词，提示词工程开始从堆规则转向给模型判断空间。
冷月清谈：
怜星夜思：
2、哪些项目规则你会坚决保留在 CLAUDE.md 或 Cursor rules 里？
3、文章说代码是比文字描述更高保真的引用，你实际用 AI 写代码时会怎么给参考材料？
4、如果模型越来越会判断，提示词工程以后还重要吗？
原文标题：Claude模型的上下文工程，新规发布了！
原文作者：数据派THU
原文内容
本文约3000字，建议阅读5分钟他们把 Claude Code 的系统提示词删掉了超过 80%，编码评测上没有测到任何损失。
删掉的是他们过去几年精心写下的那些规则。而且这是设计者自己动手删、拿评测验证过的结论。
如果你在用 Claude Code、Cursor 这类 AI 编程工具，大概率干过和他们过去一样的事：给它写规则。先写一个 CLAUDE.md 告诉它项目是干嘛的，发现它不按你的意思来就补一条，过几天又踩坑再补一条。规则文件越堆越厚，塞满了诸如不要加注释、文档要保留、先写测试之类的叮嘱，你隐隐觉得写得越细模型越听话。Thariq 这篇复盘给出的判断正好相反：到了 Claude 5 这一代，你写的那堆规则，很多正在拖累模型。给最新一代模型写提示词的方式发生了一次大反转，过去那套加规则、堵漏洞的经验大面积失效了。
一、模型变强了，规则反而成了负担
要理解规则怎么成了负担，先得看清模型每次干活时到底拿到了什么。
上下文工程指的是模型每次干活时拿到的全部背景，不只是你当场输入的那句话。它还包括系统提示词、Skills、CLAUDE.md 文件、记忆等一堆来源。你发一条消息，提示词只是其中很小一块，剩下的大量上下文是系统替你拼进去的。
Thariq 他们读自己团队用 Claude Code 的记录，发现同一次请求里经常有互相打架的指令。系统提示词说「文档酌情保留」，某个 skill 又说「不要加注释」，用户的话可能还有第三种要求。几方彼此冲突，模型得先在这堆重叠又矛盾的消息里想明白该听谁，才能动手。
这些约束当初是有用的。早期模型判断力不够。不给硬规则，它可能写出一堆错注释，甚至误删文件。为了堵住最坏情况，Anthropic 宁可把话说死，写下「默认不写注释，绝不写多行注释块」这种一刀切的规则。哪怕这话在某些场景下是错的。
对 Claude Opus 5 和 Claude Fable 5 这一代模型，情况变了。Thariq 给出的判断是：新模型判断力已经够好，能自己处理这些决定，不再需要明确规则兜底。于是他们把系统提示词里超过 80% 的内容删掉，编码评测没有可测到的损失。原来那条「绝不写注释」，现在改成一句话：写出读起来和周围代码一致的代码，匹配它的注释密度、命名和惯用写法。
二、过去广泛认可的经验，现在都要改
Thariq 把这次反转拆成了六组从前和现在的对照。每一组，过去都是被广泛认可的最佳实践，现在都成了该改的习惯。
第一条 从给规则，到给判断力
上面那个注释的例子就是。过去为了防最坏情况，把话说死。现在描述你想要的效果，让模型自己拿捏。写死的规则在一部分场景里必然是错的，模型判断力上来后，宽泛的意图反而比僵硬的规则命中率高。
第二条 从举例子，到设计接口
过去教模型用工具，头号规则是给它举例子，演示怎么调。Thariq 说，在最新的模型上，举例子反而把模型框死在某个特定的探索空间里。
替代做法是把心思花在工具本身的设计上。模型拿到哪些参数，这些参数怎样才更有表达力。他举的例子是 Todo 工具：光是把状态列成 pending、in_progress、completed 这样一个枚举，就已经在提示模型该怎么用了。再加一句「保持只有一项处于 in_progress」，想要的行为就定义清楚了，不用再举例。
第三条 从全塞前面，到渐进式披露
过去有个常见做法，是把所有可能用到的实践一股脑塞进 CLAUDE.md，担心不这样模型就找不到。现在 Claude Code 很擅长在恰当的时机加载恰当的上下文，你可以把内容拆成一棵文件树，需要哪块加载哪块。验证和代码审查这类不常用但一旦用到很关键的信息，被单独拆成了 skill，按需调用。工具也能延迟加载，模型先用 ToolSearch 搜出完整定义再用，没用到就不占上下文。
第四条 从反复强调，到简洁的工具描述
更早的模型有时需要反复叮嘱，而且更容易听进上下文窗口末尾的指令。这导致系统提示词里提到一个工具，工具描述里又写一遍用法。新模型不吃这套重复，他们把用法说明放进工具描述本身，从系统提示词里删掉了那些重复。
第五条 从把记忆写进 CLAUDE.md，到自动记忆
过去鼓励用户用 # 快捷键手动把东西存进 CLAUDE.md 当记忆。现在 Claude 会自动保存和当前工作、和你相关的记忆，不用手动记。
第六条 从简单规格，到丰富引用
plan 模式过去大量依赖写着计划的 markdown 文件，把规格存成文件供模型查阅。现在模型能处理复杂得多的引用：HTML artifact、一段代码、一套测试、另一个代码库里待移植的函数，都能当规格用。Thariq 特别提到，代码是最高保真的引用，因为那是模型最熟的语言。一份设计的 HTML 原型，产出通常比一段文字描述或一张截图更好。
三、落到你的 CLAUDE.md 该怎么改
道理讲完，落到你每天动的那几个文件上，Thariq 给了分层建议。
系统提示词和产品深度绑定，告诉模型它运行在什么产品里、在干什么。用 Claude Code 的话你基本不用碰它。但如果你在搭自己的 Agent，这里值得花大力气。
CLAUDE.md 保持轻量。简短说清仓库是干嘛的，然后把大部分篇幅花在代码库里的坑上。比如你把类型全放在一个大文件里、别处一概不放，这种反常规的约定就该写。反过来，模型看一眼文件系统就能知道的显而易见的事，别写。细节用渐进式披露处理。有好几条独特的验证规则，就做一个验证 skill 从 CLAUDE.md 里引用，而不是全铺在主文件里。
Skills 当作轻量指南，让模型在需要时找得到信息，别做得过度约束。它最适合用来沉淀属于你、你的团队或你的产品的特定观点和最佳实践。skill 很长的话，尽量拆成多个文件分开放。
引用优先给代码文件。你可以用 @ 提及文件把它作为引用带进来，规格文件、原型、甚至整个代码库都行。给代码里的文件，等于给模型清晰高保真、又是它熟悉语言的指令，效果好过一段描述或一张截图。
哪些能删，哪些必须留
看到这里容易走向另一个极端：既然删了没事，那是不是越少越好。
不是。松绑的前提是模型判断力够强。Thariq 讲得很明确，删规则的底气来自 Opus 5、Fable 5 这代模型的能力跳变。换成更老的模型，没有那些护栏，写出来的东西很多时候仍然是错的。那个取舍当年只能接受。
还有一类场景该留约束。Thariq 说 skill 别做得过度约束，但补了一句例外：在特别重要的领域仍要约束。判断标准是后果的严重性。防止删文件、防止碰生产数据这类一旦出错代价极高的地方，硬规则该留就留。可以交给模型判断的，是那些怎么做都不算错、只关乎风格偏好的地方，比如注释密度、文档详略。把这两类分开，就知道自己配置里哪些能删、哪些得留。
现在就打开配置开始删
如果你手里正好有一个越写越厚的 CLAUDE.md，或者一堆互相打架的 Cursor rules，Thariq 这篇复盘给的第一个动作很简单：试着删。
打开你的规则文件，逐条问两个问题。这条是不是模型看一眼代码就知道的显而易见的事，是就删。这条是不是怎么做都不算错的风格偏好，是就换成一句宽泛的意图，别写死。真正留下的，应该是代码库里那些反常规的坑，和一旦出错代价很高的硬约束。
Anthropic 为此还推出了一个 claude doctor 命令，在 Claude Code 里用 /doctor，帮你把 skills 和 CLAUDE.md 调整到合适的规模。方向和上面一致，把过度约束清理掉，让新一代模型有空间用自己的判断力。
模型在变强，输入给它的上下文也得跟着换写法。过去那套加规则、堆例子、全塞前面的经验，很多到了 Claude 5 这代该退场了。下次再想给模型补一条规则前，先想想它是不是真的需要这条。
编辑：文婧
