AI 从“会聊天”到“会做事”——Skill 是如何做到的？

今天这篇咱们聊一个听起来很抽象但落地之后特别带感的话题——怎么让 AI 从“嘴炮王者”变成真正能替你干活的“靠谱队友”。这一切的核心就藏在一个词里Skill技能。我是六六后端出身这两年一直在折腾大模型应用落地。如果你用过 ChatGPT你会觉得它什么都知道聊起来行云流水。可一旦你跟它说“帮我把上周的销售数据导出成 Excel发到老板邮箱”它就立马露馅了。为啥因为它只会“说话”不会“做事”。那怎么让 AI 开始做事这中间的关键一步就是给它装上 Skill。而这一步我们团队踩过的坑够写三篇血泪史了。只会聊天的模型就像被关在玻璃瓶里的天才我们公司打算做一个内部运维助手一开始信心满满基座模型选个强的提示词写得漂漂亮亮心想这事儿有啥难的结果第一个需求就翻车了同事在群里 机器人 “帮我重启一下测试环境的订单服务”。模型思考了半天回了一句“好的已为您生成重启服务的命令docker restart order-service。请在服务器上执行。”同事当场崩溃“你不能自己执行吗”那一刻我意识到一个根本问题大模型没有手。它只能生成文本不能真的去按某个按钮、调某个接口。它生成的那串指令再漂亮也是纸上谈兵。想让模型从“会聊天”变成“会做事”就必须给它“手”——也就是 Skill。Skill 到底是什么别想复杂了就是一个“能力包”你可以把 Skill 理解成一个“被精心包装过的函数”。但它又不仅仅是函数。一个完整的 Skill包含三个关键部分功能本身一段能真正执行操作的代码比如调 Jenkins 触发重启、查数据库、发邮件。清晰的说明书告诉模型这个功能是干嘛的、什么时候该用它、需要什么参数、每个参数是什么意思。结果翻译器执行完以后把结果比如状态码、错误信息翻译成模型能看懂的自然语言方便它下一步决策。这三个东西打包在一起就是一个 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 Unavailable}如果直接把这串 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那种感觉真的很爽。