写完的 Skill 怎么证明有效？很多人第一句就答错了

如果你面试大模型Agent开发岗，被问到这个问题，千万别说“拿几个问题测一下就行”。

这句话一出口，面试官就知道：你做的是demo，不是工程。

因为Skill最常见的线上事故，根本不是“不会执行”，而是乱触发、抢任务、跑偏。用户明明只想查个天气，它跑去订了个机票；两个Skill描述差不多，互相抢同一个活；执行到一半自由发挥，把你写的约束全当耳旁风。

今天这篇文章，把Skill测评的完整体系讲透

01 为什么“测几个问题”是错的？

先想清楚一个问题：Skill和普通函数有什么区别？

普通函数，输入输出是确定的，已经被流程和规范写死的，写个单元测试就够了。

Skill不一样。它的前面挂着一个大模型做路由和判断——模型要判断“用户这句话该不该调用这个Skill”，这个判断本身就是概率性的。后面的执行过程，大模型也可能参与，输出同样不是100%确定的。

所以Skill的风险分布在整条链路上：该调的时候不调、不该调的时候乱调、调了之后执行歪了、多个Skill互相打架、最后输出质量不行。

你拿三五个问题跑一遍，最多覆盖到“正常情况下能不能执行”，剩下四个风险点全是盲区。

02 Skill测评的五大维度

一套正经的Skill测评，至少要覆盖这五个维度。

维度一：触发准确性

这是事故最多发的地方，没有之一。

核心就一句话：该触发的时候触发，不该触发的时候别乱动。

要测三类case：

• 正向case：用户意图明确匹配，能不能稳定调起来
• 负向case：用户说的根本不沾边，会不会误触发
• 边界case：意图介于两个Skill之间，路由判断对不对

举个例子，你做了一个“订机票”的Skill。用户说“帮我订一张明天去北京的机票”——这是正向，必须触发。用户说“北京明天天气怎么样”——这是负向，绝对不能触发。用户说“我明天要去北京”——这是边界，他没说要订票，你的Skill该不该跳出来？这就需要精心设计了。

维度二：独立执行能力

触发对了，接下来看它能不能自己把活干完。

• 输入参数能不能正确解析？用户说“下周三”，它能不能转成正确的日期？
• 执行中遇到异常有没有兜底？API超时了、返回空了，它是直接崩了还是能处理？
• 输出格式对不对？要求返回JSON，它给你返回一段自然语言，下游直接报错。

一个好的Skill，应该是“调用即完成”，不需要人工在中间擦屁股。

维度三：共存冲突

这是从demo走向生产环境最容易踩的坑。

你的系统里不可能只有一个Skill。当十几个、几十个Skill同时存在时，问题就来了：

• 两个Skill描述写得很像，用户一句话过来，两个都觉得“这活该我干”
• A Skill的输出里提到了某个关键词，结果误触发了B Skill
• 多Skill串联调用时，上一个的输出作为下一个的输入，上下文传着传着就歪了

单测的时候每个Skill都好好的，放一起全乱套。共存测试，就是要验证多个Skill同时在线时，系统还能不能正常工作。

维度四：指令遵循

大模型有个老毛病：自由发挥。

你在Skill描述里写了“输出必须是严格JSON格式，不要任何额外解释”，它偏要在前面加一句“好的，这是您要的结果：”。你写了“如果用户信息不足，先追问再执行”，它偏要自己脑补一个答案直接干。

指令遵循度就是测这个：Skill在执行过程中，有没有严格遵守你给它的所有约束——格式约束、行为边界、安全规则、角色设定。

这个维度不能靠感觉，必须量化。跑100个case，统计有多少个严格遵守了指令，低于95%就得回去改Prompt。

维度五：最终输出质量

前面四个维度都过了，最后才看结果本身好不好。

三个标准：

• 准确性：内容对不对，有没有事实错误
• 完整性：用户要求的点是不是都覆盖了
• 可用性：输出能不能直接被下游使用，还是需要人工再加工一遍

很多人只看这一个维度，觉得“结果对了就行”。但如果触发是误触发的，结果再对也没用——用户根本没让你干这个。

03 从基线到回流：工程化测试闭环

五个维度测完还不够，真正的工程化能力体现在有没有形成闭环。

完整的链路是这样的：

**第一步，建立基线。**先有一个稳定版本作为基准，每次改动后和基线对比，不然你根本不知道是变好了还是变差了。

**第二步，搭建测试用例集。**覆盖五大维度，每个维度至少几十条case，不能只测happy path。bad case比good case更重要。

**第三步，自动化回归。**Skill每次更新，自动跑一遍全量用例。今天改了个Prompt，可能把上个月修好的问题又搞坏了——没有回归测试，你发现不了。

**第四步，灰度上线。**先放1%的流量，观察真实用户场景下的表现。实验室里测不出的问题，线上一跑就全出来了。

**第五步，线上监控。**盯几个核心指标：触发率、成功率、人工介入率、用户负反馈率。指标异常立刻报警。

**第六步，数据回流。**把线上发现的bad case收集回来，补充到测试用例集里。每修一个bug，就加一条回归用例，系统越跑越稳。

这六步形成一个闭环，才叫“工程化”。跑几个demo看看效果，那叫“玩”。

04 面试标准答案

回到最开始的问题，如果面试官问你“写完的Skill怎么证明有效”，你可以这么答：

“我不会只拿几个问题测。Skill的风险分布在整条链路上，我会从五个维度系统评估：触发准不准、独立执行稳不稳、多Skill共存有没有冲突、指令遵循度够不够、最终输出质量好不好。每个维度搭建专门的测试用例集，做自动化回归。上线后灰度验证，监控触发率、成功率等指标，bad case回流补充用例，形成完整的测试闭环。”

这个回答和“拿几个问题测一下”的区别在哪？

后者是demo思维——能跑就行。前者是工程思维——知道哪里会出问题，并且有体系地去预防。