AI如何从聊天能力进化到做事能力 Skill的实践之路

今天这篇，咱们聊一个听起来很抽象，但落地之后特别带感的话题——怎么让 AI 从“嘴炮王者”，变成真正能替你干活的“靠谱队友”。

这一切的核心，就藏在一个词里：Skill（技能）。

后端出身，这两年一直在折腾大模型应用落地的人可能都有同感：如果你用过 ChatGPT，你会觉得它什么都知道，聊起来行云流水。可一旦你跟它说：“帮我把上周的销售数据导出成 Excel，发到老板邮箱”，它就立马露馅了。

为啥？因为它只会“说话”，不会“做事”。

那怎么让 AI 开始做事？这中间的关键一步，就是给它装上 Skill。而这一步，团队踩过的坑，够写三篇血泪史了。

只会聊天的模型，就像被关在玻璃瓶里的天才

我们公司打算做一个内部运维助手，一开始信心满满，基座模型选个强的，提示词写得漂漂亮亮，心想这事儿有啥难的？

结果第一个需求就翻车了：同事在群里 @机器人 “帮我重启一下测试环境的订单服务”。

模型思考了半天，回了一句：“好的，已为您生成重启服务的命令：docker restart order-service。请在服务器上执行。”

同事当场崩溃：“你不能自己执行吗？”

那一刻暴露了一个根本问题：大模型没有手。它只能生成文本，不能真的去按某个按钮、调某个接口。它生成的那串指令，再漂亮也是纸上谈兵。

想让模型从“会聊天”变成“会做事”，就必须给它“手”——也就是 Skill。

Skill 到底是什么？别想复杂了，就是一个“能力包”

你可以把 Skill 理解成一个“被精心包装过的函数”。但它又不仅仅是函数。

一个完整的 Skill，包含三个关键部分：

1. 功能本身：一段能真正执行操作的代码，比如调 Jenkins 触发重启、查数据库、发邮件。
2. 清晰的说明书：告诉模型这个功能是干嘛的、什么时候该用它、需要什么参数、每个参数是什么意思。
3. 结果翻译器：执行完以后，把结果（比如状态码、错误信息）翻译成模型能看懂的自然语言，方便它下一步决策。

这三个东西打包在一起，就是一个 Skill。

说人话就是：Skill 是让模型“长出手”的东西。

想让模型用 Skill？你得先给它写份“菜单”

最早在搞这个运维助手时，直接把几个 Python 函数写好，用提示词告诉模型：“你可以调用这些函数”。

结果模型要么从来不用，要么乱传参数。让它“重启订单服务”，它传过来的服务名是 order_service_2，但系统里根本没有这名字。

排查了好久，问题出在“说明书”上。

模型不是人，它不知道你的内部命名规则。你必须用一种它完全能懂的格式，精确描述每个 Skill。现在主流的做法是采用Function Calling（函数调用）的格式，也就是用 JSON Schema 去描述你的函数签名。

举个例子，一个“重启服务”的 Skill，它的“菜单”大概是这样的：

{
  "name": "restart_service",
  "description": "重启指定的微服务。当用户希望重启某个服务时调用此函数。",
  "parameters": {
    "type": "object",
    "properties": {
      "service_name": {
        "type": "string",
        "description": "要重启的服务名称，必须是以下之一：order-service, user-service, payment-service"
      },
      "env": {
        "type": "string",
        "enum": ["test", "staging", "production"],
        "description": "目标环境"
      }
    },
    "required": ["service_name", "env"]
  }
}

注意这段 description 写得多细。把合法的服务名列出来了，把环境用枚举值限制住。这就是血的教训——永远不要高估模型的推理能力，也永远不要低估一份精确描述的力量。

挂上这个 Skill 之后，用户再说“帮我在测试环境重启订单服务”，模型就会自动返回一个函数调用请求，执行框架收到后，就去调真正的重启脚本。模型有了手，终于能干实事了。

好 Skill 是“打磨”出来的，不是“写”出来的

能干活，只是第一步。能干得稳、干得好，才是真正的挑战。

团队在给市场部做自动化报表 Skill 时，就遇到了几个典型的坑：

坑一：参数校验不能只靠模型

有一次，模型把查询日期参数传成了 "2024-02-30"，直接把数据库查崩了。后来学乖了，不管模型传什么，Skill 的执行代码里一定要加一层硬校验，参数不合法直接返回清晰的错误信息，让模型有机会纠正。

坑二：执行结果必须“翻译”给模型

你调 API 返回一个 {"code": 503, "message": "Service Una vailable"}，如果直接把这串 JSON 扔给模型，它大概率会跟用户说“抱歉，出现了一些错误”。用户一脸懵。

正确的做法是，Skill 在执行完后，把结果转成一句人话，再交还给模型。比如：“订单服务重启失败，因为服务当前不可用（503），请稍后重试。” 模型就能用体贴的话告诉用户，甚至自己再试一次。

坑三：Skill 的边界要单一

犯过一个错，把“查询销量并生成图表”做成了一个 Skill。结果这个 Skill 又查数据库又画图又推送到企微，逻辑一长，模型在中间卡住后很难恢复。后来拆成三个：“查销量”、“生成图表”、“推送到企微”，每一个极简，模型自己编排调用顺序，反而更稳。记住：Skill 应该是原子的、可组合的乐高块，而不是一整面墙。

从玩具到工具，Skill 就是那道分水岭

这一年多走过来，越来越觉得，AI 落地的分水岭，不在模型参数有多少，而在于它手里能调动多少靠谱的 Skill。

一个没 Skill 的 AI，就是一个只会空谈的顾问；
一个有 10 个高质量 Skill 的 AI，就是一个能打十个工种的超级数字员工。

现在，整个行业都在往这个方向狂奔。MCP、A2A 这些协议的出现，其实都在解决一个共同的问题——让 Skill 可以标准化生产、跨平台复用。未来你可能会看到类似应用商店一样的“Skill 商店”，AI 缺什么能力，直接下载安装一个 Skill 就好。

对于正在阅读的你，如果今天只能记住一件事，那就是：想让 AI 做事，就把它需要的能力，封装成一个一个精致的 Skill，再清清楚楚地告诉它怎么用。这活儿没有什么高深魔法，全是体力活和细节控。

下班前，把个思路讲给了那个实习生。他照着框架，花了一下午，给助手装了个“查询加班餐补”的 Skill。当他看到机器人真的从系统里查出数据并 @他 的时候，他兴奋得拍了下桌子。

那个瞬间，他摸到门道了。你也来试试吧，亲手为你的 AI 装上第一个 Skill，那种感觉，真的很爽。