看到社区里最近聊AI Agent的朋友越来越多各种平台也开始推Skill玩法——从前段时间的豆包Skill、Spring AI 2.0 Skill到Codex自定义Skill、OpenClaw挂载技能包感觉一夜之间Skill成了Agent生态的关键词。我不反对追逐热点但有个问题一直没人认真聊你下载的、自己写的、朋友丢给你的这个Skill到底是真能干活还是包装得好看我前后试用过不下几十个Skill包含金量参差不齐。有的装上之后Agent水平肉眼可见地提升有的装上跟没装一个样还有的第一次跑惊艳、第二次跑摆烂。这就引出今天想写的东西怎么用对照、重复、证据这套朴素方法给Skill做一次有效的评估。这篇不是学术论文是我自己反复实操后沉淀下来的方案面向所有自己写Skill、或者从网上找Skill来用的人。1. 先想清楚一件事Skill的有效和稳定到底指什么1.1 一个Skill到底在卖什么Skill这个词在不同平台里叫法不完全一样但本质上干的是同一件事把某一个特定任务的提示词模板、工具调用流程、参考文档甚至代码片段打包成一个可以被Agent加载的模块。你可以把它理解成给通用Agent装了一个行业专用的作业手册工具箱。裸的Agent能力是广而不深你让它写诗、写代码、做数据分析都能来一点Skill的作用是把某一条任务线做深让它从知道一点变成按标准流程高效执行。举个最朴素的例子很多做GIS相关工作的朋友会去下GIS空间分析Skill这种包里面一般包含空间分析工具的调用方式、地理数据处理的参数模板、常见坐标系校验规则。装上之后Agent遇到空间分析任务就不用你从头交代应该先投影、再裁剪、再叠加分析这些步骤了。再比如有人专门做看图技能Skill让Agent能按照固定格式去解析图片尺寸、色彩空间、主体区域——这类Skill本质上是预置了一套视觉任务的SOP。所以我们在评估一个Skill时首先得搞清楚它在卖什么。它可能只卖一份更强的提示词也可能卖一套工具绑定还可能卖一份文档检索能力。如果连这个包提供了什么增量价值都没想清楚后面的对照和重复都是白做。1.2 有效性和稳定性是两套指标别混着说很多人在评价Skill时只会说一句感觉好用或者效果不行这种模糊评价对优化毫无帮助。我把评估拆成两个独立维度有效性Effectiveness加载Skill之后任务结果相比不加载时是否变好了。比如写分析报告结构完整度是否提升、术语是否更准确、结论是否更可靠。稳定性Stability在同样的输入、同样的模型参数、同样的工具环境下多次运行的结果是否一致。同一个任务跑五次三次给出A答案、两次给出B答案这样的Skill没什么可信度。这两者的关系可以用一个生活类比来记买一把电钻有有效等于它能不能真的打出孔稳定等于连续打十个孔是不是每个孔位都准。很多Skill的问题是经不起重复测试。第一次跑任务A给你一个完美方案第二次跑同样的任务A给你换一个思路第三次直接报错。这时候它的有效性完全不可依赖。评估维度回答的问题典型测量指标对应方法有效性装上有没有变得更好正确率提升、完整性评分、交付用时对照实验稳定性多次跑是否一致一致率、成功率、变异系数重复测试2. 对照怎么做才有参考价值2.1 三组对照实验分别回答不同层级问题判断一个Skill是否有效最忌讳的做法是拿一个任务加载Skill跑一遍看着输出还行就说这个Skill好用。这种评估方式没有参照系全靠主观感觉换了任务、换了模型可能就翻车。我建议最少做三组对照每一组回答一个不同的问题。第一组有/无对照基线对照。在同一任务集上先跑一遍不加载任何Skill的裸Agent记录输出质量再跑一遍加载目标Skill的Agent记录输出质量。两组用完全相同的任务描述、相同的模型版本、相同的参数设置。只有一个变量是否加载Skill。这组实验回答的问题是这个Skill到底有没有带来增量。第二组消融对照Ablation。把Skill里的组成模块拆开比如一个包的提示词模板、参考文档、工具配置是三部分那就分别加载全量Skill没有提示词模板的Skill没有参考文档的Skill各跑一次。这组实验回答的问题是Skill里到底是哪一部分在起作用。这一步很多评估都会跳过但不做的话你永远不知道那些核心拆解到底有没有价值——有些Skill真正起作用的部分其实只有两句关键提示词剩下的大段文档只是凑篇幅你可以据此做精简优化。第三组横向对照。在市面上找到两到三个解决同类问题的Skill放在同一任务集上对比评测。这里要注意版本比如Spring AI 2.0的Skill生态里、豆包Skill市集、社区分享的Codex自定义Skill同一类功能不同实现非常多。横向对照回答的问题是我该选哪个。2.2 任务集和评分阵不能拍脑袋定对照实验要做得好前提是任务集选得准。我给的标准是准备三大类任务总数在20个左右常规任务约10个Skill本应最擅长处理的标准场景比如一个报告生成Skill就让Agent生成不同主题的周报。边界任务约5个输入格式不那么标准、参数边缘化、工作流中途需要调整的场景这类任务最考验Skill的容错能力。异常任务约5个故意给错误格式、缺参数、超出范围的输入看Skill能不能给出合理的拒绝或降级方案。有了任务集还得有一套评分阵。我常用的评分维度是正确性答案是错是对、完整度有没有漏项、格式遵循输出结构是否符合预设模板、执行效率从输入到输出的步数/时长。每项打1到5分加起来是总分。评分标准必须落到纸面上每个分数要有锚点描述。比如正确性4分核心结论正确但有一处次要推导瑕疵——没有锚点的话同一个输出两个人能打出两个分隔了一天一个人也能打出两个分。补充一个实操技巧任务集一旦定下来就不要轻易改。评估这种事最怕的是跑了一半觉得自己选的用例不合心意临时换题一换题前后数据就失去了可比性。3. 重复跑多次才会暴露真实稳定性3.1 重复实验的最小可行方案稳定性评估的底层逻辑很简单同一输入多跑几次看结果是否一致。但几次是有讲究的。我个人的经验是关键任务你验证的Skill最核心的那个亮眼功能至少重复跑10次普通任务重复跑5次条件允许的情况下用不同的时间点、不同的上下文窗口长度再跑一组排除偶然性。重复之后记录三个统计量成功率多少次输出是可用结果、结果一致率多少次输出指向同一主要内容描述可以不同但结论口径一致、变异系数如果输出是数值型内容用标准差除以均值看波动幅度。这里说句题外话很多严谨的评估会去做统计检验甚至有人专门提到重复测量方差分析这类工具——我只能说如果你的评估样本量足够、任务有大量数值指标那用统计方法是加分项但日常验证Skill算成功率、一致率就够用了。举一个我实测过的例子。我评估过一个开源的小工具型Skill它的能力是自动批量对比两份文件名相似度很高的文件判断是不是重复文件。我准备了同样一组文件跑10次结果相当有意思第1、3、5、7、9次给出一份清单第2、4、6、8、10次给出一份略有差异的清单。后来拆开日志发现Skill里有一段排序逻辑没有指定稳定排序而底层工具返回文件顺序不稳定。这就是非常典型的有效性还行、稳定性翻车——它确实能找到重复文件但每次找的结果不是同一批让人没法放心用。3.2 影响稳定性的不只有Skill本身的文本很多人以为稳定性差 提示词写得不好实测下来远没那么简单。我踩过好几次坑总结出这几类常见的稳定性破坏源第一类是模型侧。采样参数没有固定Temperature、Top-P这些参数对开放式任务的输出影响巨大。评估时一定要固定模型版本和采样参数否则你根本区分不了Skill不稳定还是模型本身随机性大。第二类是Skill内部指令冲突。这个问题非常隐蔽很像单片机开发里遇到的重复定义错误——你引入了两个头文件里面各自的同一个函数被定义了两次编译器直接罢工。Skill也是一样很多打包好的Skill是从多个模板拼凑出来的同一操作既有最终以用户原话为准的指令又有必须按系统给定格式改写的指令Agent运行时就会在这两条规则之间反复摇摆导致输出不稳定。我甚至见过一个Skill里塞了三套互相矛盾的输出格式要求跑出来的结果一次一个样。第三类是外部工具和环境的幂等性。这里想借消息队列重复消费问题打个比方。在分布式系统里消费者从队列里拿消息往往不止拿一次如果你处理逻辑不处理幂等数据就会重复更新。Skill的测试环境也是一样如果某个API调用或工具执行本身就不幂等那么即便Skill写得再严谨输出也会跟着外部状态波动。评估一个Skill时要顺手排查它依赖的工具、网络请求、临时文件是不是每次执行都处于一致的状态。要谨记一个稳定的Skill是提示词工具运行环境共同作用的产物。在搭建评估环境时把环境变量、软件版本、依赖工具的版本全部固定住才能测出Skill引擎本身的稳定性。4. 证据链让评估结果经得起复检4.1 记录哪些信息才算有证据不知道你们有没有这种经历测完一个Skill觉得效果不错跟朋友推荐时想拿当时跑出来的结果当证据结果翻了半天聊天记录没找到或者找到了一张截图但完全想不起来这是哪个版本跑的、用的是什么参数。评估Skill最忌讳口说无凭所以从第一轮实验开始就必须留证据。我这里给一个自己在用的最小证据记录模板每次跑一条用例往里填一条字段说明用例编号Task-01 ~ Task-20评估对象Skill名称/版本号/来源地址运行环境模型名称、温度、上下文长度、平台部署版本输入原文保留完整输入不能只存摘要输出快照原始输出文本/JSON/截图OCR或复制粘贴均可评分明细四个评分维度分别的分数异常备注报错信息、重试情况、工具返回异常等这个表看起来简单但能把我测过我这版本可用这两种模糊说法变成可追溯的记录。注意事项记录原始输出不要记录转述版你转述一遍就已经丢失信息了。保存原始对话日志这件事很多人嫌麻烦不做我强烈建议做——至少保留控制台输出的存档。4.2 证据的三种失真情况遇到直接作废有了证据记录还得防证据失真。我见过三类特别典型的情况失真场景一只留了成功案例失败案例顺手删了。评估Skill不是发朋友圈不需要只展示光鲜的截图。恰恰相反失败案例才是排查稳定性的金矿。我自己的习惯是建两个文件夹一个放success-case一个放failure-case定期对比。如果发现某个Skill的失败案例越来越多基本可以判断它在你当前环境里是带病运行的。失真场景二前后环境不一致。有人今天在本机跑明天换到云端跑后天换了个模型版本又跑然后把三次结果合并成一套总结论。这种证据链是断裂的因为干扰变量太多。证据记录里必须带上环境信息不同环境的评估数据要分开汇总不能混着说。失真场景三只信口头效果不看原始输出。这里我想提一嘴去AI味类的写作Skill。我在市场上见过不止一个号称去AI味的Skill装加载后生成的文本乍一看像那么回事然而如果你对它的输出做输出文本重复度/模板句式频率统计跑5轮以上你会发现它只是换着花样重复那几个常见的过渡句。如果只看单次输出你很容易被骗只有把多次输出拉出来做重复计数式的对比才能看出内容同质化程度。这就是证据的价值——它逼着你看数据而不是看感觉。另外提醒一下Skill更新迭代之后旧版本跑出来的评估结果自动作废。记录里要有版本号甚至内容哈希。你今年用一个Skill的1.0版本跑出的结论不能指导你在2.0版本上做决策。5. 完整走一遍一个开源Skill的评估实录5.1 评估对象与准备工作前面讲了一堆方法论这部分我拿一个实际案例从头到尾演示一遍。前段时间我从社区搞到一个开源的看图技能Skill它的目标是让Agent能自动分析一张图片输出结构化结果包含主体物、颜色分布、构图特征。听起来挺实用又是用Agent制作AI像素动画时需要的辅助判断工具。我决定按上面提到的方法做一轮完整评估。准备工作做了三件事固定环境锁定同一个模型版本、Temperature设为0.2、上下文窗口长度设为模型默认值运行平台统一说明白了这次所有数据只在当前环境内有效。准备任务集按要求设计20个用例10个常规图片清晰的单个主体物体、配色简单的场景、5个边界图片过曝、图片上带有文字干扰、主体不明确、5个异常输入非图片文件、损坏的图片、尺寸极小的缩略图。选定对照组已知社区里还有一个同类看图技能Skill也做类似功能把它作为横向对照。再加上裸Agent基线正好凑齐三组。5.2 二十五轮实验与结果解读这里我简化展示一下核心数据。常规任务的10个用例验证时每个用例重复跑5次总共50次运行边界和异常任务各重复跑3次。整体运行下来汇总出这样一张表组别常规任务总得分均值完整度得分格式遵循得分异常输入可处理率裸Agent基线37 / 503.12.820%目标Skill全量43 / 504.24.560%社区同类Skill38 / 503.43.540%看完有效性这块第一印象是目标Skill确实有效常规任务比裸Agent提升了6分高于同类竞品。但我没有急着下结论因为稳定性的数据还没汇总。再看重复执行一致率统计的时候问题就出来了同样是常规任务-001这个用例目标Skill在5次重复运行里只有3次输出内容一致另外2次输出的主体物结论完全不同。相比之下裸Agent虽然得分低但连续5次都给出了一致的结论。这种时好时坏的状态正是稳定性极差的表现。后来我去翻证据日志定位到根因Skill的指令里同时存在两种对任务优先级的描述一种要求按图像显著性区域排序一种要求按输入顺序依次分析模型在不同运行周期里随机采纳了不同的排序策略。这就跟代码里的重复定义类似——同一个行为被定义了两遍执行器只能二选一选哪个看运气。基于整套评估的结论是这个Skill建议修改后再用或者暂时挂起不用。它在格式遵循和完整度上有明确的增量但在核心结论口径上的一致性不达标。对这类看图场景输出颠三倒四带来的风险远大于节省几分钟的价值。6. 常见问题与避坑速查6.1 六类典型翻车场景我猜看到这里很多人已经在心里对齐了自己的经历。下面我把自己干评估时踩过的坑、以及帮朋友排查过的问题做成速查表从安装到测完每个环节都碰过雷。现象根因处理办法对照实验跑完两组结果几乎一样任务太简单裸Agent已经能解决出现天花板效应把任务难度往上提换成Skill声称最擅长的复杂场景第一次跑效果好第二次效果差模型采样参数浮动或Skill内部指令存在冲突固定采样参数排查提示词里互相矛盾的规则给Skill去重测试集表现完美换个场景就废任务集与真实使用场景分布不一致边界任务设计不足测试集内补充贴近真实业务的用例尤其是带脏数据、缺字段的场景不同人评同一份结果分数不同评分维度没有锚点示例全靠主观感受为每个维度每个分数写一段描述性锚点安装完Skill后Agent行为异常来源不明的Skill包夹杂了不兼容的工具配置或网盘分享包版本不对先隔离安装试跑单一用例不要直接在主要工作流上加载新版本Skill一出旧结论全部失效版本迭代改变了触发逻辑旧评估数据不再代表现状每个版本单独保留证据记录版本间结论不自动迁移6.2 一套可复用的评估清单模板上面这些经验最终我整理成了一个固定检查清单。现在每次拿到新的Skill我都会按照这个清单走一遍[ ] 确认Skill的功能边界和宣称效果写一句话目标声明[ ] 固定模型版本、采样参数、部署环境并在证据表中登记[ ] 设计20个任务用例覆盖常规、边界、异常各若干[ ] 跑裸Agent基线组保存原始输出[ ] 跑目标Skill全量实验组每组重复5次以上记录每次输出[ ] 跑消融实验或横向对比按需[ ] 统计成功率和一致率计算四个评分维度的平均分[ ] 复盘失败用例定位根因指令冲突、工具非幂等、模型随机性[ ] 归档所有日志、评分和结论注明Skill版本号[ ] 做决策可以用/修改后再用/弃用这个模板看起来不复杂但坚持执行下来能少踩很多感觉好用的坑。我自己最大的转变是不再凭单次输出的直觉下判断而是把能不能稳定复现作为底线。你跑到第3次发现输出翻车比你在正式环境跑到第47次才发现代价小得多。最后再分享一个我这两年的实际体会评估Skill是一件反着来的工作——大多数人的本能是赶紧装上用一个实际任务跑跑看能不能交付而评估要求你刻意地重复、反复地对照、甚至在发现这包效果没有那么好时还要继续记录。但恰恰是这种反本能的行为帮我在一堆包装精美的Skill里筛出了真正能放进工作流的少数几个。你能找到什么好Skill当然重要但更重要的是你拿什么标准判断它值不值得信任。