Claude 5时代：精简规则，释放模型判断力

当新一代大语言模型的能力实现跃迁，AI编程工具的提示词编写方式正在发生彻底反转。有团队做了一个反直觉的实践：删掉了系统提示词中超过80%的预设规则，而通过编码评测验证，最终的工具表现没有出现任何可测的性能损失。

很多使用AI编程工具的用户，都有过给工具写规则的经历：先创建配置文件说明项目背景，发现模型不按预期工作就补充规则，久而久之规则文件越来越厚，塞满了各类叮嘱，默认觉得规则越细模型越听话。但最新的复盘结论恰恰相反：大量手写的规则反而成了拖累模型的负担，过去靠加规则堵漏洞的提示词经验已经大面积失效。

要理解规则如何成为负担，首先要清楚模型每次处理请求时的上下文不仅仅是用户当场输入的内容，还包括系统提示词、技能配置、配置文件、内置记忆等多个来源。团队在查看内部使用记录时发现，不同来源的指令经常互相冲突：系统提示词的要求和某个技能模块的规则不一致，用户的即时请求还可能带来第三种要求，模型需要先在这些重叠矛盾的指令中理清优先级，才能开始执行任务。

早期的硬规则是必要的：早期模型的判断力不足，如果不给出明确的硬规则，很可能出现错误的输出，甚至误操作。为了规避最坏情况，开发者当时宁可制定一刀切的规则，哪怕这类规则在部分场景下并不适用。但到了新一代模型，模型的判断力已经足够强，可以自主处理这类决策，因此大量的预设规则就不再必要，仅保留最核心的约束即可。

提示词编写的六大转变

从硬定规则到给出意图

最典型的就是代码注释的规则例子。过去为了防止最坏情况，会把规则写死，但现在只需要描述想要的效果，让模型自主拿捏细节。写死的规则在部分场景下必然会出错，而新一代模型的判断力提升后，宽泛的意图指令反而比僵硬的硬规则命中率更高。

从举例演示到设计工具接口

过去教模型使用工具的主流方法是给出具体的使用例子，但在最新的模型上，举例反而会把模型限制在特定的探索空间里。更好的做法是优化工具本身的设计：明确模型可以调用的参数，让参数本身具备足够的表达力。比如待办工具：仅将任务状态设置为pending、in_progress、completed这样的枚举类型，就已经在暗示模型的使用逻辑，再补充一句“同一时间仅保留一个处于进行中的任务”，想要的行为就清晰定义了，完全不需要额外举例。

从全量塞去到渐进式披露

过去的常见做法是把所有可能用到的实践一股脑塞进配置文件，担心模型找不到必要的信息。但现在的工具已经可以在恰当的时机加载恰当的上下文，可以将内容拆分为文件树结构，按需加载需要的部分。比如验证和代码审查这类不常用但关键的信息，可以单独拆分为技能模块，只有在需要时才调用；工具也可以采用延迟加载的方式，模型先用搜索工具获取完整定义再使用，未被用到的内容不会占用上下文窗口。

从反复强调到简洁的工具描述

更早的模型需要反复叮嘱，且更容易记住上下文窗口末尾的指令，这导致系统提示词里提到一个工具，工具描述里还要再写一遍用法。但新一代模型不再需要这类重复信息，可以将用法说明直接整合到工具描述本身，从系统提示词中删掉重复的内容。

从手动存记忆到自动记忆

过去会鼓励用户用快捷键手动将内容存入配置文件作为记忆，但现在的工具会自动保存与当前工作和用户相关的记忆，完全不需要手动记录。

从简单规格到丰富引用

过去的计划模式大多依赖写着计划的文档，将规格存为文件供模型查阅。但现在的模型可以处理复杂得多的引用形式：HTML原型、一段代码、一套测试、另一个代码库中待移植的函数，都可以作为规格使用。代码是最高保真的引用形式，因为这是模型最熟悉的语言，一份设计的HTML原型产出的结果，通常比一段文字描述或一张截图更好。

如何调整你的配置文件

针对日常使用的配置文件，可以按照分层的方式调整：

首先是系统提示词，它和产品深度绑定，用于告诉模型当前运行在什么产品中、正在执行什么任务。如果只是使用通用工具，基本不需要修改这个部分；但如果是搭建自定义的智能体，则值得投入精力精心设计。

核心配置文件需要保持轻量：简短说明项目的用途即可，大部分篇幅应该留给代码库中的特殊坑点。比如如果你的项目将类型定义全部放在一个大文件中，其他地方一概不放，这种反常规的约定就需要写在配置里。反过来，模型看一眼文件系统就能知道的显而易见的信息，就不要写进去。细节内容可以采用渐进式披露的方式处理：如果有多个独特的验证规则，可以创建一个验证技能模块，从主配置中引用，而不是全部铺在主文件里。

技能模块应该作为轻量指南使用，让模型在需要时能够找到必要的信息，而不要过度约束。技能模块最适合沉淀属于你、你的团队或你的产品的特定观点和最佳实践。如果技能模块内容较长，尽量拆分为多个文件分散存放。

在引用信息时优先选择代码文件：可以通过提及文件的方式将其作为引用带入上下文，无论是规格文件、原型还是整个代码库都可以。直接引用代码中的文件，相当于给模型提供了清晰高保真且它熟悉的语言指令，效果远好过一段文字描述或一张截图。

哪些可以删除，哪些必须保留

很多人看完可能会走向另一个极端：既然删了没事，是不是越少越好？答案是否定的。松绑的前提是模型的判断力足够强，这次实践的底气正是来自新一代模型的能力跃迁。如果换成更早的模型，没有这些硬约束的话，产出的结果很多时候仍然会出错，当时的取舍是必要的。

还有一类场景需要保留约束：技能模块不要过度约束，但也有例外——在特别重要的领域仍然需要约束。判断的标准是后果的严重性：防止删除文件、防止触碰生产数据这类一旦出错代价极高的操作，硬规则该保留就保留。而可以交给模型自主判断的，是那些怎么做都不算错、只关乎风格偏好的内容，比如注释密度、文档详略等。将这两类内容分开，就能清楚自己的配置文件里哪些可以删除，哪些必须保留。

如果你手里正好有一个越写越厚的配置文件，或者一堆互相冲突的规则，给出的第一个动作非常简单：试着删除。打开你的规则文件，逐条问自己两个问题：第一，这条规则是不是模型看一眼代码就能知道的显而易见的事？如果是，就可以删掉。第二，这条规则是不是只关乎风格偏好的选择？如果是，就换成一句宽泛的意图描述，不要写死。真正需要保留的，应该是代码库中那些反常规的坑点，以及一旦出错代价很高的硬约束。

相关工具还推出了辅助命令，可以帮助你调整技能模块和配置文件的规模，核心方向就是清理过度的约束，让新一代模型有空间发挥自己的判断力。

模型在变强，输入给它的上下文也需要跟着更新写法。过去靠加规则、堆例子、全量塞取的提示词经验，很多到了新一代模型已经该退场了。下次再想给模型补充一条规则前，不妨先想一想：它是不是真的需要这条规则？