霍格沃兹测试开发学社
想让模型用 Skill？你得先给它写份“菜单”最早我在搞这个运维助手时，直接把几个 Python 函数写好，用提示词告诉模型：“你可以调用这些函数”。结果模型要么从来不用，要么乱传参数。让它“重启订单服务”，它传过来的服务名是 order_service_2，但我们系统里根本没有这名字。排查了好久，问题出在“说明书”上。模型不是人，它不知道你的内部命名规则。你必须用一种它完全能懂的格式，精确描述每个 Skill。现在主流的做法是采用 Function Calling（函数调用） 的格式，也就是用 JSON Schema 去描述你的函数签名。举个例子，一个“重启服务”的 Skill，它的“菜单”大概是这样的：好 Skill 是“打磨”出来的，不是“写”出来的能干活，只是第一步。能干得稳、干得好，才是真正的挑战。我们团队在给市场部做自动化报表 Skill 时，就遇到了几个典型的坑：坑一：参数校验不能只靠模型有一次，模型把查询日期参数传成了 "2024-02-30"，直接把数据库查崩了。后来我们学乖了，不管模型传什么，Skill 的执行代码里一定要加一层硬校验，参数不合法直接返回清晰的错误信息，让模型有机会纠正。坑二：执行结果必须“翻译”给模型你调 API 返回一个 {"code": 503, "message": "Service Unavailable"}，如果直接把这串 JSON 扔给模型，它大概率会跟用户说“抱歉，出现了一些错误”。用户一脸懵。正确的做法是，Skill 在执行完后，把结果转成一句人话，再交还给模型。比如：“订单服务重启失败，因为服务当前不可用（503），请稍后重试。” 模型就能用体贴的话告诉用户，甚至自己再试一次。坑三：Skill 的边界要单一我们犯过一个错，把“查询销量并生成图表”做成了一个 Skill。结果这个 Skill 又查数据库又画图又推送到企微，逻辑一长，模型在中间卡住后很难恢复。后来拆成三个：“查销量”、“生成图表”、“推送到企微”，每一个极简，模型自己编排调用顺序，反而更稳。记住：Skill 应该是原子的、可组合的乐高块，而不是一整面墙。
发布于 北京
分享
评论
赞
未登录
友善发言
评论
加载中
