业务全 Skill 化，不叫 AI 落地

OpenClaw 最火那阵子，有朋友来问我：“基于 Skill 做点东西创业，靠不靠谱？“Skill 在我印象里不就是个工程手段，把工作流程打包成可复用指令，告诉 Agent 遇到某类任务该怎么做。什么时候变成商业机会了？

后来发现不止他这么想。身边好几个做 AI 落地的同事，正在热火朝天地把传统业务流程一个个包成 Skill，交给 Agent 自动跑，然后向老板汇报「AI 落地进展」。前阵子和一个同学聊，他家公司帮电商做店铺运营。他们老板给团队定了个目标：今年运营流程要全面 Skill 化，用 Skill 的使用次数作为衡量指标。

Skill 本身没错，问题出在更早的地方：人们在用旧流程的每一步来切 Skill，把步骤自动化当成了 AI 落地。

业务 Skill 化的坑

拿客服举个例子。

传统流程是这样的：客服登录系统，查订单记录，翻政策手册，按模板回复，关闭工单。五步，环环相扣，每一步都有人在等下一步。

把它 Skill 化怎么做？最常见的做法是按步骤来切：登录工单系统怎么操作、查订单调哪个接口、政策匹配的判断逻辑、回复模板怎么填、最后关闭工单，一步一个 Skill。五个 Skill 串起来，Agent 自动跑完，人不用动了。更极端的做法是把 UI 交互本身也写进脚本——登录页面点哪里、表单怎么填、每一步跳哪个菜单全部硬编码。这套东西叫 RPA，不是 AI 落地。看起来很 AI，速度快了，调用量也漂亮。

但流程一行没变。只是把客服换成了 Agent，旧流程加了 AI 还是旧流程。

换一种思路：用户直接说「我上周买的那个东西想退」，Agent 核对完登录身份和这个账号的订单，回「这笔订单 11 月 3 日购入，符合 7 天无理由，退款大概 3 个工作日，物流上门取件你选哪个时段」。如果是大额订单或者地址异常，再走人工。没有工单号，没有「请稍候转接」。

按步骤切的 Skill 解决的还是「这五步谁来按」，但用户要的其实是有人能直接把那个东西退掉。后面那个 Agent 底层同样可以是 Skill，区别只在于，它是按用户目标切的，不是按旧流程的步骤切的。按步骤切 Skill 本身有价值，能让旧流程跑快一点。问题是别把这件事叫做 AI 落地。

Agent 落地误区

回到企业里的那套 KPI。

做了多少个 Skill、被调用了多少次，这两个数字只能说明工具被用了多少，说明不了用户的问题有没有被更好地解决，也说明不了哪个旧流程因此被取消。

定这套 KPI 的人是在用过去管研发的方式管 AI。代码行数、需求数量，这些都是研发时代的老办法，搬到 AI 上就变成 Skill 数量。

前面提到的那个老板，自己装了 OpenClaw、亲手写了几个 Skill，觉得这事可行，就定了这个方向。Skill 越多，自动化程度越高，这套思路顺着老习惯搬到了 AI 上。

但这两件事不能直接画等号。

往”做更多 Skill”这个方向走下去，团队越努力越跑偏。Skill 如果按旧流程步骤写死，堆得越多，预设的流程越细，Agent 真正能自主判断的地方越来越少。Agent 只是个壳子，里面跑的还是预设流程。

回到客服那个例子。你想要的 Agent，是用户说想退货，它能自己核对身份、判断政策、安排取件。业务全 Skill 化做出来的，是把每一步都写死，遇到没预设到的情况，Agent 只能停在那。

该问的不是 Skill 数量

有一个问题我每次都会问自己：用了 AI 之后，用户的问题有没有被更好地解决？

流程跑快了、调用数好看了、Skill 多了几十个，但用户还是要先报工单号再被转接三次，那就还没到 AI 落地这一步。

KPI 定 Skill 数量，是在用工具使用量衡量业务变革。老板看到的是 Skill 调用数翻倍，用户那边感受到的还是同一个工单系统。

所以回到开头那个朋友的问题。如果他想做的是帮客户把现有流程包成 Skill 卖回去，那大概率是在帮客户把旧流程跑快一点，生意能做，但和 AI 落地是两回事。

衡量 AI 落地，回到一句话就够了：用了 AI 之后，用户的问题有没有被更好地解决？

你们公司用什么指标衡量 AI 落地？是 Skill 数量、调用次数，还是别的？留言聊聊。觉得这篇有用，转发给正在被 KPI 推着做 Skill 化的同事。想继续看 AI 落地相关的内容，点个关注。