别给你的 AI 工具做满汉全席

你那个专门写专利的 skill，提示词写到多少字了？

我见过有人把一份 skill 写到两千多字——背景介绍、操作规范、输出格式、例外情况、语气要求、避坑指南，全塞进去。看着很专业，像一份满汉全席。

但满汉全席的问题，不是不好吃，是太难做、太难收拾。

一、什么都往里塞的冲动

什么都往里塞，skill 就成了一颗不断膨胀、没人敢动的巨无霸

做 skill 的人，天然有个冲动：怕漏。

怕模型不懂背景，加一段背景；怕模型输出不统一，加一段格式规范；怕模型踩坑，加一段避坑清单。每遇到一次翻车，就补一条规则进去。补着补着，skill 变成了一个不断膨胀的巨无霸。

这背后的心理很好懂：多写一条，就多一分安心。可安心是安心了，代价是另一头的。

更隐蔽的是，塞得越多，你越不敢动它。哪天想删一条，又怕删了哪次翻车会复发，于是只能继续叠。到头来，这份 skill 没人敢改、没人说得清每条还在不在起作用——它从一个工具，变成了谁都不敢碰的祖传代码。

二、维护成本的隐性爆炸

skill 越长，越难维护。

最现实的一刀，是模型更新。

底层模型一升级，它理解指令的方式、它偏好的输出格式，都可能变。你那两千字的精细约束，可能一半在新模型下失效，甚至起反作用——旧模型要你反复强调"别啰嗦"，新模型本来就精简，你那句反而让它束手束脚。

于是每次模型变了，你得把整份 skill 重新读一遍、逐条验证、逐条改。skill 越长，这次返工越痛苦。你花在"伺候 skill"上的时间，可能已经超过了它替你省下的。

这还没算另一笔账：新人接手时，面对两千字的天书，根本不知道哪条有用、哪条是历史包袱，只能全文照搬，越积越重。

还有一层，叫场景漂移。

你半年前写的那些"如果客户是外企则……"，现在客户结构早变了，那条规则还在 skill 里占着位置，既不触发又干扰判断。业务在跑，skill 停在原地，两者的缝隙越大，维护成本越高。

三、加法要做，减法更要做

不是说不能加东西。该加的得加。

判断标准只有一个：这条规则，是在解决一个真实发生过的翻车，还是你在想象一个还没发生的万一？前者该加，后者别加。

为"万一"写的规则，大多永远用不上，却一直占着地方、干扰模型注意力。

每次想往 skill 里加东西前，先问自己：这是救过火的，还是防着火的？救过火的留下，防着火的先放着。等它真着了火，再加不迟。

四、最小可用 skill 的三条原则

最小可用 skill 的三条原则：单一职责 / 可丢弃 / 留修改史

我自己的做法是，把 skill 压到"最小可用"，只守三条：

一是单一职责。一个 skill 只干一件事。写权要的别顺手管格式，管格式的别操心检索。职责越单一，越不容易互相打架，改起来也清清楚楚。比如"格式检查"就单独拆成一个小 skill，权要撰写需要时用一下，互不污染。

二是可丢弃。假设这份 skill 明天删了重来，你花半小时能不能重建？我要求自己做到：任何一份 skill，换个新人看一眼就能重写，而不是只有写过的人才懂。能放心丢弃的 skill，才是健康的 skill。

三是留修改史。每次为什么加、为什么删，留一行记录。哪天模型大版本更新，你对着修改史，能很快判断哪些老规则该退休，不用通读两千字去猜。

五、一个精简前后的对照

说个真事。我早期那份专利 skill，提示词一千八百字，里面三分之一是各种"如果……则……"的例外处理。后来我狠心砍：把没实际触发过的例外全删，把重复强调的格式合并成一句话。

砍完剩六百字出头。有人担心：砍这么多，会不会漏掉关键约束？我的经验是，真关键的约束，你砍十次它也还在——因为它每次翻车都被你用上；而那些你犹豫要不要删的，多半本来就没派过用场。精简不是冒险，是把一直在用的留下来、把从没用过的请出去。

结果呢？输出质量没降，反而更稳了——模型不用在十几条互相掣肘的指令里左右为难。省下来的，是我之后每次升级只用看六百字，而不是一千八。毕竟大模型更新后会更加智能。

如果你手头正有一份臃肿的 skill，别想着一次改到位。拿个周末，把所有"如果……则……"的例外列出来，逐条标上"近三个月是否真触发过"。没触发过的，先注释掉而不是删除——跑两周没事，再彻底删。这一步做下来，你大概率能砍掉三成以上，而输出不会变。

满汉全席看着气派，简餐吃着顺心。给 AI 工具做配置，也是这个理。