最近圈子里聊得最多的就是给AI助手写Skill。无论你是用Codex跑代码任务还是给Claude配一套领域速查指令还是在自己搭的Spring AI应用里挂技能包本质都是在干同一件事把一团模糊的帮我做某事变成一个有边界、可重复、带约束的执行流程。Skill确实是好东西但问题出在大家验收它的方式上。我见过太多人写了一个Skill拿三五个例子试一遍输出看着靠谱就宣布成了结果换一批输入立马翻车。原因很简单大模型是随机的一次成功说明不了任何问题。Skill的价值必须靠三个东西来证明——对照、重复、证据。这篇文章就聊聊我是怎么用这三板斧来评估一个Skill到底值不值得用的适合正在写Agent技能包或者准备给团队推广Skill的人参考。1. 先说清楚Skill到底需要评估什么1.1 Skill是什么为什么火起来Skill这个概念这两年被AI插件生态带火了。Claude有Skills机制Codex支持自定义技能包OpenClaw、Spring AI这些框架也都在做类似的扩展能力。实际上Skill就是一个结构化的能力包里面包含了角色设定、执行步骤、输出格式约束、示例样本、质检清单甚至还可以挂外部工具调用和知识检索。它的目标很朴素——让通用大模型在特定任务上表现得像一位懂行的老师傅而不是一个什么都会一点的万金油。我自己写Skill的习惯是把它当新员工培训手册来看待。新人进组你不可能让他自己摸索三个月才上手你会给他一份SOP什么场景走什么流程、中间要检查什么、输出长什么样算合格、哪些红线绝对不能碰。Skill本质上就是把这份SOP从人话翻译成模型能稳定遵循的指令序列。所以Skill的价值不在于写得有多华丽而在于它能不能稳定地把模型的输出质量拉高一个档次。1.2 为什么能跑通一次不等于能用这是我认为最重要的认知先掰开揉碎讲清楚。大模型的解码过程自带随机性即使是温度参数设为0某些框架下也会因为采样策略、并行解码、上下文顺序等因素产生输出差异。这意味着同一个Skill、同一道题你上午跑和下午跑结果可能不一样。这里有个经典的幸存者偏差陷阱。人脑对成功的记忆权重远大于失败你写了一个Skill试了8次有2次效果惊艳剩下的6次你下意识地归因为输入不够规范或者模型今天状态不行。但事实是一个不能稳定复现效果的Skill和抽奖没什么区别。你做评估的唯一目的就是把这个模糊的感觉还行变成一组可以量化的数据这个Skill在给定场景下的成功率到底是多少输出方差大不大失败模式集中在哪一类。没有这些数据你后续所有的优化都是在碰运气。2. 对照法没有基线评估就是耍流氓2.1 对照设计的三条铁律做对照实验这件事很多搞技术的人反而是最容易犯错的。因为大家习惯了写代码时改一行就能看出效果但评估Skill是社会科学式的实验变量控制不好结论就是废纸。我给自己定三条铁律。第一条是单变量原则。对照组和实验组之间只有一个差异你有没有挂载这个Skill。模型版本要相同温度参数要相同上下文窗口要相同连发给模型的系统提示词都要保持一致。否则你分不清是Skill起作用还是换了模型才变好。第二条是同样的输入分布。很多人测试Skill时给对照组用的是简单问题给实验组用的是复杂问题然后得出Skill提升了效果的结论——这是典型的循环论证。两组必须跑同一批测试用例一字不改。第三条是环境冻结。Skill文件一旦确定版本整个评估期间不能边测边改。我见过有人测到一半发现某个规则写得不好当场改了然后之前的测试结果就全失去了可比性。改完必须重新从头跑这是基本功。2.2 对照组怎么搭三种对比维度实际工作中我常用三组对比根据你的目标选一组或全做。第一组是无Skill对Skill这是最基础的。目的是回答这个Skill到底有没有带来增量。如果裸agent的通过率是30%挂了Skill以后还是35%那这个Skill写得再精美也是自嗨直接重构。第二组是Skill-A对Skill-B这是版本迭代时用的。你准备了两套写法一套走极致详细路线一套走简洁关键点路线就看哪一套在同样的测试集上表现更好。这组对比最忌讳的是同时改了两个变量——比如既换了措辞风格又加了新的示例这样即使结果变好你也不知道是哪个改动起了作用。第三组是Skill对现有标准流程这适合团队内部推广场景。比如你们现在靠资深工程师人工做代码评审你写了一个Code Review Skill那就让Skill和人工评审在同样的代码样本上跑一遍用同一套评分标准打分。这里不用追求Skill完全超过老师傅只要它能把最基本的问题都抓出来就值得用来做第一道过滤把人工精力省下来去处理高难度问题。2.3 一个具体的对照实验记录拿我自己评估一个Code Review Skill的例子来说。测试集是10段真实业务代码每段都埋了3到4个问题空指针隐患、资源未关闭、魔法数、边界条件缺失评分规则是找出问题记1分误报扣0.5分总分10分7分以上算通过。组别通过率平均得分平均耗时(秒)裸agent30%5.258挂Skill v170%7.162挂Skill v290%8.361这个表格一出来结论就非常清楚了。v1相对于裸agent已经有明显提升但通过率只有70%不合格的3次里两次都是漏掉了资源未关闭的问题。我把失败案例拿出来看发现Skill的检查清单里虽然写了检查资源释放但没有给出具体的检查顺序。v2的改动就是加了一个强制步骤——先扫描所有try-with-resources和finally块再查空指针。就是这么一条针对性修改把通过率从70%拉到了90%。这个过程里如果没有对照组的数据你根本找不到这条优化线索。3. 重复法稳定性是用次数换来的3.1 为什么要重复大模型的手感漂移对照法能告诉你Skill有没有用但回答不了另一个关键问题它靠不靠谱。我管这叫手感漂移——同一个Skill模型这次发挥超常下次发挥失常你永远不知道下一次它会掉到哪一边。尤其是那些生产环境里的Skill比如自动生成周报、自动做代码扫描、自动整理客户会议纪要一次抽风可能就要害得你手动返工半天。稳定性差的根源通常有两个。一是Skill里的指令存在歧义模型每次解读都略有不同输出结构就跟着漂二是Skill对环境上下文太敏感用户随口多说了一句无关信息模型就被带跑偏。重复测试就是把这种漂移暴露出来的唯一办法。3.2 重复多少次才有效最少10次的理由很多人的第一反应是多跑几次——问题是跑几次才算多。我直接给个可用的底线最少10次重要Skill至少20到30次。为什么是这个数用最简单的统计学解释假设真实成功率是50%你做n次测试测出来的成功率误差范围大约在正负1.96乘以根号下(0.5乘以0.5再除以n)这个区间里。n等于10的时候误差带大约是正负31个百分点这意味着你测出来50%真实值可能落在19%到81%之间——这个精度基本不能用来决策。n到30的时候误差带缩到正负18个百分点左右勉强能区分明显可用和明显不行。所以我自己的习惯是快速试错阶段跑10次决定上线之前跑30次。这里有个重要的细节这10次或者30次必须在不同会话里跑每次都是全新的上下文而不是在同一个对话里重复追问。原因是模型对上下文有强依赖连续追问会产生上下文污染你测出来的稳定性是假的。3.3 怎么量化稳定成功率、方差、失败模式聚类重复跑完不能只记一个成功了几次要有三个层次的指标。第一个是成功率这个最简单直接。第二个是输出结构的一致性你可以把每次输出的标题层级、段落结构、关键字段抽取出来做个对比看看模型是否每次都按照Skill规定的模板在走。第三个是失败模式聚类把每一次失败归个类是漏了某类信息还是格式飘了还是中间步骤跳过了。你会发现失败不是均匀分布的而是集中在某几个弱点上这些弱点就是你下一轮优化的切入点。我自己还会顺手记录一个token消耗和耗时。稳定性不只是质量稳定还要成本可控。如果某个Skill平均跑一次要烧掉大几千token成功率再高也得掂量掂量值不值。4. 证据法别只看结果要看过程4.1 证据链由什么构成对照和重复回答的是行不行证据法回答的是为什么行。我观察到很多人评估Skill只看最终输出这是个巨大的盲区。大模型的生成是一个过程同样的最终结果背后可能走了完全不同的路径——有的路径是你Skill里那条正确路线有的路径是模型歪打正着靠运气撞出来的。我们要收集的证据链包括四类一是模型在任务里的推理摘要或思考过程二是它调用了哪些工具、按什么顺序调用三是每次调用返回了什么中间结果四是最终输出前的自查清单有没有被触发。把这些串起来你才能判断Skill里的哪一条规则真的在起作用哪一条形同虚设。打个比方你带新人干活新人最后把活干完了你肯定要追问一句你中间是怎么处理的——确认他走的是你教的那套流程而不是他自己瞎摸索凑巧干完的。Skill评估也是一样的道理。4.2 日志、中间产物、差分对比要拿到这些证据最常见的做法就是开详细日志模式。大多数Skill框架都支持把模型每一步的思考摘要和工具调用记录导出成JSON或者Markdown测试跑完直接保留现场。我习惯的做法是每次测试都导出完整的运行轨迹按测试用例编号归档。拿到轨迹之后重点做差分对比。把挂Skill和不挂Skill的轨迹放在一起同一道题逐段对照你会清楚地看到差异发生的节点可能是在识别问题类型这一步挂了Skill的模型会先做领域归类再动手而裸agent直接开跑可能是生成报告前挂了Skill的模型会额外执行一遍质量自检。这些节点就是Skill生效的证据点。如果差分结果告诉你挂了这个Skill之后模型的运行轨迹和不挂几乎一模一样只是最终输出的措辞好看了点——那你要警惕了这个Skill可能只是个表面装饰并没有真正改变模型的执行逻辑。这种Skill的价值非常有限。4.3 什么算实锤什么算巧合收集证据的时候要有一杆秤不然会被一两条好看的结果带偏。我自己把证据的可靠程度分三档。第一档是可复现的模式比如在5次成功案例里模型都严格执行了你Skill里的第3步质检动作而且去掉这一步之后成功率明显下降。这种属于实锤。第二档是单次轨迹某一次运行里模型确实走了你预期的路径但其他9次都没走。这最多算偶尔生效不能拿来当判断依据。第三档是主观印象你觉得加了Skill之后输出看起来更专业了但没有对应的轨迹数据支持。这种连证据都算不上。另外还要警惕安慰剂效应。有时候你辛辛苦苦写的Skill里真正起作用的就一条规则其余几十行全是模型本来就具备的能力。怎么验证做一个消融测试把Skill里的规则逐条删掉再跑一遍看通过率掉不掉。掉得多的是核心规则掉得少甚至不掉的就是冗余内容留着只会增加token消耗。5. 从零到一的评估实操流程5.1 准备测试集3类用例就够了很多人卡在第一步不知道该拿什么问题去测。我建议三类用例就够了。第一类是高频场景占比60%以上。就是你实际使用时最常遇到的输入比如Code Review的典型业务代码、周报生成的原始素材。第二类是边界场景占比约30%。包括输入格式不完整、内容超长、含有模糊表述、夹带无关信息等情况。第三类是反向场景占比10%。这些是Skill应该明确拒绝或者特殊处理的比如疑似敏感内容、超出能力范围的要求、明显恶意构造的输入。测试集的数量控制在10到20条之间比较合适。太少没有统计意义太多则每轮评估成本太高。关键是这组用例一旦定下来就要当资产管理后续Skill每次改版都用同一组用例做回归测试这样版本之间才能横向对比。我在本地维护着一个skill_regression文件夹里面是固定的测试集和历次评估结果每次改完Skill先跑一遍这个回归集再谈其他。5.2 跑一次完整评估的步骤清单按我实际执行的顺序完整评估流程如下。第一步冻结版本。把待评估的Skill文件、模型配置、参数设置全部固定下来代码仓库打个标签。第二步定义评分标准。把好不好翻译成可打分的行为比如代码评审任务就是找出预设问题的比例报告生成任务就是是否包含结论、数据来源、风险提示三个板块。评分表要在测试之前写清楚不能看到结果以后再补规则。第三步分批跑测试。用脚本循环依次调用每道题在全新会话里执行记录原始输出、轨迹日志、耗时和token消耗。第四步盲评打分。把输出结果里的人名、Skill版本信息全部抹掉只看裸输出打分。如果是重大项目找一位不参与Skill开发的同事来打分降低主观偏好。第五步汇总分析。把通过率、一致性、失败模式、证据轨迹整理成一张汇总表对照上次的基线数据看趋势。整个过程看起来不复杂但实际上很考验耐心因为跑测试的过程非常枯燥。我的建议是写一个简单的批处理脚本让机器自动跑自动记录人只负责最后的分析和判断。5.3 评估报告怎么写结论怎么下评估的结果不要只留在脑子里一定要落成一份简短的报告。报告不需要长篇大论四张表就够测试集清单、各组成功率对比表、失败模式分布表、关键证据轨迹摘录。结论的下法我遵循一个三分法。通过率大于80%且失败模式中没有不可接受的类型——可以上线。通过率在60%到80%之间——回到证据链里找失败集中点做一轮针对性优化后重新测不要硬上。通过率小于60%——别急着打补丁回到Skill的设计层面重新考虑这个技能包的核心思路是不是出了问题或者测试集本身是否偏离了实际场景。还有一个容易被忽视的决策维度维护成本。如果一个Skill需要你持续投入大量精力去调校但它的使用频率很低那我倾向于不上线。Skill不是越多越好而是每个都经得起这三板斧的检验才好。6. 常见问题与排查技巧6.1 技能只对标准问法有效这是我最常遇到的问题症状是评估集里通过率很高一到真实使用场景就拉胯。原因多半是测试用例的表述太统一了模型学的不是解决这类问题而是匹配这种问法。排查方法很简单把测试集里的每道题用三种不同的问法改写一遍再测。比如帮我检查这段代码有没有内存泄漏可以改成这段代码在长时间运行后会不会出问题再改成Review一下重点是别让服务挂掉。如果改写后通过率骤降说明Skill里缺少一个关键的意图识别环节需要在开头加一段明确的任务定义让模型先判断用户到底想让我干什么再决定走哪条流程。6.2 上下文污染与记忆残留这个问题在重复测试时尤其隐蔽。有些Skill会引导模型输出时引用对话历史里的内容如果你在一个会话里连续测试多次模型可能把上一次的输入或输出混进这一次的结果里。典型表现是你测到后面几轮发现结果里莫名其妙出现了前一轮测试的数据。应对方法是强制每次测试都开新会话并且随机打乱测试用例的执行顺序。我还会在测试指令里加一条不要假设本会话之前出现过任何内容从源头掐断模型自作主张回忆的念头。另外如果模型框架支持清理上下文缓存每轮测试前最好手动清一次。6.3 评估者的主观偏好干扰最后一个坑出在评估人自己身上。你辛辛苦苦写了一个Skill潜意识里就会希望它表现好打分的时候容易手松——这是人性不是态度问题。我自己的解决方式是双重盲评测试脚本把Skill版本信息从输出里移除评分时只看输出本身重要决策时拉一个没参与Skill开发的人来打分取两个分数的平均值。还有一个技巧是给评分标准里加反向指标比如是否出现了编造的数据是否遗漏了明确要求的板块。这类指标能让主观评分有硬约束不至于让感觉不错主导一切。说到底评估一个Skill和评估一个员工很像不要听他怎么说也不要看某一天的表现要看长期数据、看关键节点、看可复现的证据。说个我自己的实话。自从把评估体系搭起来之后我砍掉了一半以上的Skill。很多当初灵感迸发写出来的技能包在对照测试面前根本站不住脚要么是不如裸模型要么是只能靠运气生效。这个过程确实有点打击人但留下的每一个Skill都是真正经得起重复验证的。我现在的习惯是每个Skill配一张测试卡记录评估日期、成功率、失败模式每两周重跑一次回归。Skill不是写出来就完事了它像一个需要持续保养的工具你得不断用数据告诉它哪里还能更好。这套方法不玄乎就三步拿一面镜子照它有没有用拿一把尺子量它稳不稳拿一把手术刀剖开看它到底哪里在发力。希望你也能用起来别让你的Skill池里堆满漂亮但没用的装饰品。