给 AI 加能力，还是给它上枷锁？

一句"你好"背后的三块钱。

从一句"你好"说起

有位朋友跟我讲他用某buddy的经验。

他给这个AI 助手装了两百多个skills。文档处理、表格清洗、PPT 生成、图像识别、语音合成、行业检索……每加一个，他都觉得又强了一点。加到两百个的时候，他很有成就感地打开对话框，就输入了两个字：

你好。

然后去看了后台的账单。

就输入两个字，消耗了几十万 Token。

如果把某些平台的默认装载策略再算进去，冲到上百万Tokens其实也并不稀奇。

然后他带着这个问我：这些 Tokens 是哪来的？

我的回答是：来自你安装的那两百多个skill啊，来自每一轮对话都要重新付一遍的"以防万一"。

这虽然是个玩笑，但是事后我认为这个事儿里最值得琢磨的，不是钱。

是那个"加一个就觉得强一点"的直觉。这个直觉在某个临界点之后彻底失效了，但很少有人意识到它失效了。

SOP 本来是为了让 AI 更靠谱

先把话说公道一些。

给 AI 立规矩，写 SOP，封装Skill，这件事本身是对的，而且是必需的。

理由很简单：一件事做一次靠提示词，重复做一千次就必须靠 SOP。

你和 AI 单聊，靠临场发挥就能得到不错的结果。

但如果你要把它放进组织的业务流程里，每天处理几百上千份文件、几百张单据、几百个客户，那让AI临场发挥就会成了灾难。

同样的输入，这次给你这样的答案，下次给你那样的答案；同一个错误，纠正过一次，换个说法又犯了。

SOP 的本质，是把我们的判断力沉淀下来，形成方法论。

它回答的不是"第一步做什么、第二步做什么"，而是：

什么叫对，什么叫错；边界在哪里，哪些事绝对不能碰；遇到没见过的输入，怎么兜底；交付物长什么样才算完成；哪一步必须留痕，将来能查。

这些内容一旦写清楚，AI 的智力其实变大了。大量低级错误的空间被提前排除，它可以在剩下的空间里放开手脚去推理、去串联、去尝试没见过的路径。

一个写得好的 Skill，是把老师傅的直觉变成模型可以随时调用的先验。这当然是加能力。

但是问题往往出在了另一半。

枷锁是怎么被自己亲手焊上去的

没人会主动想给 AI 上枷锁。

枷锁都是善意堆出来的，有三种典型形态，一种比一种隐蔽。

一：锁路径，而不是锁结果

最常见的一种，是把 SOP 写成了动作清单，比如下面这种：

第一步，调用文档解析工具； 第二步，调用字段识别模型； 第三步，将结果与字典比对； 第四步，输出检查结论。 

看起来非常规范，非常"工程化"。

但它有一个致命问题：这四步是人的手和眼在特定条件下走出来的路径，并不是任务本身的逻辑。

智能体最值钱的能力，恰恰是跳步、并联、遇到新情况当场重组路径。

你把它钉死在四步上，等于用它的短板换掉了它的长处。

标准场景跑得挺顺，一旦遇到没见过的，就沿着错误的路径一路走到底，崩得毫无余地。

检验方法很简单，可以亲自用你常用的AI助手试试：这条 SOP 允许Agent用不同方式达成同一个结果吗？如果答案是"不允许"，那它约束的就是过程，不是质量标准。

二：全量常驻，以防万一的囤积症

回到那句"你好"。

今天的智能体，几乎都支持"技能""插件""工具"这类扩展。

装得越多，感觉越强。

但绝大多数平台的默认装载策略是：全部常驻。

于是系统的上下文里，每一轮都塞着这些东西：

第二行是大头，也是最多人忽略的一行。

一个工具的 JSON Schema 要写清参数名、类型、枚举值、必填项、默认值和一段使用说明，稍复杂一点的工具就是五六百 token。

几百个工具叠起来，二三十万就这么来了。而且它们每轮都要重新发一遍，因为请求是完整的，不是增量的。

注意最后一行那个"每轮"，这东西不是一次性开销。

它是一份按对话轮数计费的订阅。 

用户看到的是一句"你好"，系统付的是一整本说明书；聊二十轮，就是二十本。

而这里面绝大部分内容，和这次对话毫无关系。

我们也曾嘲笑过那种把公司所有制度装订成一本、新员工入职第一天必须通读八百页的做法。

轮到给 AI智能体 配置能力，又一模一样地做了一遍。

三：拒绝减薄，规矩比模型活得久

这是最隐蔽、也最费钱的一种。

每一条 SOP，当初都是为了堵一个具体的坑写下的。

模型在某个版本上把某类文件解析错了，于是加一条"必须校验格式"；模型在某个场景下把金额单位搞混了，于是加一条"必须二次确认单位"。

这些都对，但今年的模型迭代的都很快，每升级一代，甚至是一次小更新，就比如最近的deepseek-v4.1:1017这个小迭代升级，当年那些补丁的必要性就下降一层，而几乎没有人会回头去拆。

判断一条规则该不该降级，有个很常见的信号：这件事模型已经连续多久没犯过错了？ 如果半年没再出现，它就不该继续当强制步骤，应该从"必须检查"改成"事后校验"——从里面挪出来，变成一段代码。

半年之后，你看到一个很奇怪的现象：这个智能体刚开始使用时挺聪明，现在反而变笨了，动作越来越僵，遇到新情况越来越不敢动。

不是模型退化了。而是当初的枷锁没卸。

SOP 应该是一层会随着模型能力上升而不断变薄的东西。 

它不该像混凝土一样越浇越厚。

三条判据，一句口诀

那么问题回到最本质的地方：怎么判断一条 SOP 是在加能力，还是在加枷锁？

我给出的是三条判断依据，大家可以试一下。

一：看可行动空间是变大还是变小。

看完这条 SOP，模型能覆盖的场景变多了，还是变少了？

变多，说明它在更多情况下都能给出可接受的输出，哪怕内部走法和你设想的不一样，这是加能力。

变少，说明它只能照抄你给的路径，一越界就失败，这是枷锁。

这条判据的好处是不看 SOP 写得漂不漂亮，只看结果。

二：看约束的是结果，还是过程。

约束结果就是加能力，约束过程就是枷锁。

具体到写法上，差别非常明显：

过程式写法是"先解析 PDF，再用 OCR，再比对规则库"。

结果式写法是"给出源文件名、附件类型、标准编号、检查结论；结论只能是'通过／禁止／待定'三种；任何一步无法确认，必须落到'待定'并留痕"。

后一种写法里，模型怎么走到终点是它的事，但终点长什么样、边界在哪里、异常怎么处理，一步都不能含糊。

三：这条 SOP 有多久没做过减法。

问问自己：上一次删掉一条规则，是什么时候？

如果答案是"从来没有"，那它已经在往枷锁的方向滑了。

模型的迭代速度远快于流程文档的迭代速度，只加不减的系统，必然越来越沉。

三条落成一句能贴在墙上的话：结果硬，路径软。

硬的东西放在流程外面，规则校验、决策表、兜底与待定机制、审计留痕。这些是工程，是代码，是确定性，不依赖模型心情。

软的东西放在提示里面，领域知识、范例、判定标准、常见坑。这些是上下文，是判断依据，让模型自己组合。

反过来做就一定两头落空：提示词里写死步骤，指望模型老老实实执行；验收环节靠人肉眼看，指望人不出错。

确定性归工程，灵活性归模型。搞反了，两边都是灾难。

把成本摊开仔细看看

回到开头那个Skill装载的问题，它不只是个架构问题，还是个产品态度问题。

技术上其实有很成熟的解法，而且都不难。

一，目录化 

常驻上下文里只放Skill的"名字加一句话触发词"，三十字以内，正文按需加载。目录是路由表，不是说明书。

二，工具延迟挂载 

先做意图识别，只把命中的三五个技能的工具定义注册进去，其余不进上下文。这一条通常能砍掉九成以上的常驻开销——因为砍掉的正是占比最大的那部分，也就是几百个工具的 JSON Schema。

三，描述瘦身

技能描述的唯一职责是回答"什么情况下应该用我"，而不是"我有多强大"。把后者写进去，不仅费钱，还会让路由判断更模糊，因为每个技能都在喊自己很强，结果是三个技能同时被命中，上下文又膨胀一圈。

四，成本可见

界面上显示一行字："本次上下文消耗 XX K Tokens"。

前三条是工程能力。

第四条不是技术问题，是要不要把钱摊开给人看的问题。

今天市面上的绝大多数产品选择不摊开。

用户的界面里只有一句"你好"，Token 计量藏在后台，按次感知、按 Token 结算，消耗静默而持续。用户很难发现，直到某天看见账单。

这不是用户不够懂，这是产品把能力的边际成本藏起来了。

而一旦被发现，损失的往往不是钱，是信任。

"我什么都没干，钱就没了"这件事，比"做得不够好"更能劝退一个用户。

本质上是管理问题

写到这里，那个隐喻一直在往一个方向走。

SOP 之于 AI，就是制度之于人。

我们都太熟悉那种糟糕的公司了：制度写得密密麻麻，每一条都是因为出过事，流程节点一层叠一层，谁都不敢跳过任何一步。

结果是什么？

所有人都在合规地低效，没有人敢做判断，遇到制度没覆盖的情况就停下来等指示。

制度本来是为了让组织跑得更快，最后成了组织跑不动的原因。

好的制度长什么样？

边界清晰，内部自由。

它告诉你什么绝对不能做、什么必须交付，然后把怎么做留给你。

给 AI 写 SOP，逻辑完全一样。

所以那个最初的问题，答案不在 SOP 本身，在于写它的人当时在想什么。

如果我们在想：这个行业里，什么算对，什么算不能碰，交付要什么样才算数。

那我们写下来的就是判断力，是给 AI 加能力。

如果我们在想：万一它出错怎么办，万一它乱来怎么办，最好每一步都写死。

那我们写下来的其实是自己的不安全感。

不安全感会变成枷锁，套在 AI 脖子上，最后套在自己身上，因为它会以成本和迟钝的形式，反过来找你收账。

芯知见解

那句"你好"，其实是一场成本极低的压力测试。

它测出来的不是模型有多强，是我们给这个智能体背上了多重的行李。

行李里有些是必须的：行业知识、验收标准、合规红线。

有些是当年为了防一个具体的坑临时塞进去的，坑早就填上了，行李还在。

其实目前我们绝大多数人都有一个误区，就是会觉得我给智能体装了多少技能、接了多少工具、写了多少条规则，仿佛数字越大越接近"通用"。

但真正的工程能力，从来不是能装多少。

而是敢在没命中时，把它拿掉。

轻装上阵吧，别背负太多的包袱。