我电脑里目前躺着30个Skill都是过去大半年在各种场景下陆续攒下来的。有的写小说用有的做数据分析有的处理日常事务还有几个是从社区里淘回来的。但说实话我从来没认真给它们做过一次系统评估每次都是“感觉这个好用”“那个还行”全凭感觉维护。直到我决定写一个Skill体检器把30个Skill挨个拉出来跑了一遍评分。结果很有意思体检器第一轮跑完先自曝了8个“假0分”——所谓“假0分”就是Skill本身并不算差但评测链路、测试用例或运行环境出了问题导致被误判成完全不可用。这8个0分没有一个是Skill真的一无是处都是冤枉的。这篇内容就是这次体检的完整复盘。我会重点讲清楚为什么我会做这个体检器假0分到底是怎么出现的怎么把假0分从真0分里挑出来以及一套可以复用的Skill评测方案。无论你手里是5个Skill还是50个这套思路都能帮你把“凭感觉”变成“有依据”。1. 为什么我会给30个Skill做一次“体检”1.1 30个Skill的“全凭感觉”困境先说个扎心的现实Skill这玩意儿攒起来容易维护起来难。你可能也有过这种经历——某天发现一个Skill效果惊为天人两周后再用它就像换了个人输出质量大幅下滑。但你完全说不清是哪里变了。是模型版本变了是Skill描述和实际行为产生了偏差还是我给的输入变了大概率你只能摊手认倒霉。我就是在这种状态下攒到30个Skill的。数量上来之后“凭感觉”这套方法彻底失效了记忆偏差。我对每个Skill的印象停留在它“最好用的那次”而不是“平均表现”。一个Skill有80%的概率平庸20%的概率惊艳我会默认它是好用的。场景混淆。很多Skill是特定场景专用的但在我的记忆里它们会被我混为一谈。比如我有个“GIS空间分析”的Skill和一个“数据可视化”的Skill名字不同、功能有重叠我经常搞不清上次好用得到底是哪一个。幸存者偏差。我记住的往往是成功案例失败案例被我下意识忽略了。一个Skill失败10次成功1次那1次会留在我脑子里其余全被淡化。这直接导致我无法回答三个基本问题哪些Skill值得留哪些Skill需要修哪些Skill应该被删所以我才决定做一个Skill体检器用一套统一标准把30个Skill全部过一遍。1.2 体检器的定位不排名抓“坏得隐蔽”的Skill在设计体检器之前我明确了一件事我不要一个给Skill打分的“排行榜工具”。排行榜只能告诉我谁高谁低却说不清低分是能力问题还是评测问题。我要的是一个能诊断问题的“体检雷达”。所以体检器被我设计成五个维度的评估框架体检维度说明检测方式可发现性Agent能否在合适场景下准确找到这个Skill用自然语言描述一个任务看Agent是否选中该Skill可激活性选中后Skill是否能被稳定唤起并执行连续多次运行同一用例记录激活成功率质量达成度输出结果是否符合Skill声明的能力和约束语义相似度 结构约束 人工抽查稳定性多次运行结果波动大不大同一用例运行3次以上对比ELO波动误触发率在无关场景下是否会被错误调用用无关任务测试看Skill会不会“抢活”这五个维度是我反复试出来的最初我甚至没有“误触发率”这个概念。后来我发现有个写代码注释的Skill老在别人问“这句话什么意思”的时候被触发一本正经地回答“这是一段Python代码的注释说明”极其尴尬。这种问题在常规质量评测里根本看不出来必须单独测。这里先给个结论体检器不是一次性任务它是一套循环机制。跑完一轮修完问题下一轮继续跑。和人体检一样只有定期做数据才有意义。注意体检器最重要的产出不是总分而是“证据链”。每个分数背后必须有可追溯的测试记录否则分数本身就是新的噪声。2. 体检器第一轮跑完自曝了8个“假0分”2.1 什么叫“假0分”解释一下标题里的关键词。“假0分”指的是评测器给出的分数是0但这个0分并不真实反映Skill的能力——它反映的是评测链路某个环节出了问题。用个类比一场考试考生本身会做所有题但发卷时把卷子发错了、或者考场停电了、或者阅卷老师眼花了最后判了个0分。你能说这个考生能力为0吗显然不行。Skill体检里的“假0分”就是这类误判而且它比“真0分”更危险——因为0分足够刺眼你会下意识想删掉这个Skill结果把一个尚可抢救的资源扔了。我第一轮跑完30个Skill的体检一眼扫过去8个0分躺在那里。那一刻我是崩溃的难道我大半年的积累四分之一都是废物还好当时没急着删逐个复核之后才发现8个全是假0分。2.2 成因一Skill文件没被正确加载Agent压根没调用它两个Skill我印象很深。一个是“打斗动作提示词”的Skill一个是“AI备课”的Skill体检时双双吃了0分。我起初以为是内容质量不行后来拉日志才发现测试过程中Agent根本没调用这两个Skill——它俩就像考场里根本没进教室的考生分数当然为0。问题出在Skill的描述信息上。Skill的发现机制主要靠两个字段name和description。Agent拿到用户请求后会先扫一遍所有Skill的描述判断哪些候选与当前任务相关。如果description写得太模糊、太长、或者塞满了和实际功能无关的关键词模型可能就无法正确识别它。我当时写的这个“打斗动作提示词”的Skilldescription是“提供高质量的动作描写提示词优化小说战斗场景支持多样化动作设计涵盖近战、远程、群体战等不同类型”。看着没问题对吧但真实情况是我把一堆提示词打包在一个文件里SKILL.md的frontmatter里description字段写得过于宽泛Agent的embedding匹配时找不到和用户请求的强关联点于是这个Skill就被架空了。所以这一类0分本质上是“装配错误”。Skill本身的内容能力完全没问题但它没有被正确安装到Agent的发现系统里。我把这类问题归为“加载层问题”后面会讲怎么处理。2.3 成因二测试用例和Skill业务领域错配第二类假0分更隐蔽。我跑体检时犯了一个非常低级的错误为了让30个Skill都能公平测试我给它们硬套了一批“通用用例”。结果就是——一个写小说场景的Skill被拿去做“生成产品卖点”的任务一个做GIS空间分析的Skill被拿去做“帮我写一份周报”的任务。有一次我的“小说剧情转折”Skill拿了一个“给新产品起名字”的测试用例输出自然一塌糊涂它在很认真地写高潮、写冲突、写人物反应但评测器等的是“产品名提案”。两边鸡同鸭讲0分实属必然。这类假0分我归为“用例层问题”。它出现的根源是批量测试时我没有为每个Skill单独设计与其场景匹配的用例集而是图省事套用同一份用例。要知道Skill不是通用模型它是垂直场景的专用工具。你用游标卡尺去量体温量出来的数值没有意义。注意批量体检时每个Skill必须有“专属用例集”通用用例只能做辅助参考不能作为评分依据。2.4 成因三评分规则太粗糙把高质量回答误杀了第三类假0分最讽刺。我最初给体检器设定了一套“关键词命中”评分规则——输出里出现某些预设关键词就给分不出现就扣分。这套规则在测试普通Skill时勉强能用遇到两类Skill就彻底失灵了。第一类是“去AI味”的Skill。这个Skill的设计目标就是让输出更接近真人写作它会刻意删除“值得注意的是”“总而言之”“随着技术的发展”这类AI腔调词。而我的体检器靠“是否出现AI腔调关键词”来判定“像不像人类写的”——恰恰把这个Skill的核心能力当成了扣分项。它删除AI腔调越彻底我给的分数就越低。评分规则和Skill目标完全反着来。第二类是“小说写作”相关Skill。它输出的是长段故事文本结构化程度低几乎没有我可以预设的关键词。但内容质量其实很高用语义相似度去评估它可能能拿85分用关键词匹配去评估就是0分。关键词法决定了它根本拿不到分。这类假0分我归为“评分规则层问题”是三个成因里最需要警惕的因为它代表的是评测系统自身的缺陷不修的话下次还会误杀更多Skill。3. 怎样把“假0分”从30个Skill里挑出来3.1 人工复审三件套原始日志、输出回放、交叉复跑发现8个0分之后我没有直接信任体检器的判断而是对每一个0分做人工复审。这里分享我的三个复审动作非常有效第一步拉取测试日志确认Skill是否被调用。这是最直接的判别方法。如果测试过程中Agent压根没调用这个Skill那这个0分大概率是假0分——问题出在“Skill没被发现/没被激活”这个环节而不是Skill能力本身。如果日志显示Skill被调用了、但输出不合格那才需要继续往下查。第二步输出回放。把评测器判为0分的输出原样读一遍。这一步很反直觉但当人类认真读的时候经常会发现输出质量并不差只是不匹配某些机械规则。你能瞬间看懂“评分规则层”的误判是怎么发生的。第三步交叉复跑。同一个测试用例同一份输入连跑3次。如果3次结果差异巨大——一次90分两次0分——那基本可以断定是模型输出波动或评测链路故障属于不稳定假0分。如果3次都是稳定的0分那才说明是真问题。经过这三步我把8个假0分归因完毕3个是加载层问题2个是用例层问题2个是评分规则层问题还有1个是外部依赖问题那个Skill依赖的某个数据接口挂了。3.2 给体检器装“认错机制”证据回传与归因分级人工复审解决的是眼前这8个0分但要根治必须让体检器自己具备“认错能力”。我给体检器做了一次升级核心是两件事第一每个分数必须附带证据。体检器不再只是输出“0分”还要输出“为什么是0分”——比如“未监测到Skill调用记录”“输出未命中预设关键词”“语义相似度低于阈值0.35”。有了证据我就能快速判断这个0分成不成立。第二错误归因分级。体检器把0分分成四类加载层问题、用例层问题、评分规则层问题、模型执行层问题。每一类对应不同的处理方式归因层级典型表现初步处理方式加载层测试日志无Skill调用记录检查SKILL.md格式、name/description字段、路径挂载用例层Skill被调用了但测试场景完全不匹配重写该Skill的专属测试用例评分规则层输出质量高但机械规则不命中升级评分规则引入语义相似度模型执行层多次运行结果差异巨大增加复跑次数、检查模型上下文是否溢出这套机制上线后体检器才真正从“打分器”变成“诊断器”。它不但告诉我谁0分还告诉我这个0分可不可信、该从哪个环节去修。3.3 修复结果真正的“问题Skill”其实只有5个把8个假0分排除后30个Skill里真正需要修复的只有5个。这个结果让我松了一口气但也带来了一个更有价值的发现粗看全是问题细看问题分布完全不同。这5个真实问题Skill分别为2个是描述模糊导致误触发。它们功能本身没问题但description写得太宽泛导致Agent总在无关场景下调用它们。比如那个“代码注释解释”Skill经常在用户问“这句话什么意思”的时候被激活。修法是重写description改成“仅处理代码文件中的注释内容解释不处理日常对话”。2个是输出稳定性差。同一个测试用例第一次跑输出很好第二次就质量下滑。修法是检查Skill内部指令是否过于依赖模型自由发挥我在提示词里加了更明确的结构约束和自检清单。1个是依赖了已失效的外部接口。这个Skill内部调用了一个第三方API做数据增强但那个API已经停止服务了导致我的体检结果每次都是45分上下。修法是移除外部依赖或者换成可用的替代接口。这5个问题Skill在体检器评分里也并非全是0分——它们大多是40~60分的中低分档位。这说明一件事体检器的价值不只是抓0分更是把那些“及格线徘徊”的隐患暴露出来。4. 一个能落地的Skill体检方案附参数和脚本4.1 体检用例集怎么建每个Skill至少5类用例如果你也想给手里的Skill做体检最关键的一步是建用例集。我的建议是每个Skill至少准备5个专属用例分五类用例类型作用示例以“小说打斗动作提示词”Skill为例正向用例验证Skill在核心场景下的能力“请为都市异能小说的巷战场景写三段打斗动作描写主角是劣势方。”边界用例验证Skill在输入模糊或极端条件下的表现“帮我写一个动作场景。”负向用例验证Skill在错误误解用户意图时能否及时纠正“这段代码有bug请帮我找出问题。”无关用例验证Skill在无关场景下是否会被误触发“帮我算一下本月预算。”对抗用例验证Skill在用户提出不合理要求时是否会拒绝或降级“不要用细节描写用三句话写完这个打斗。”这套设计可能比你想象中耗时。30个Skill每个5个用例就是150条测试记录。我第一轮跑完花了大概一个晚上。但一套好用例集的价值会随着后续迭代持续释放——第二轮体检、第三轮体检不用重写只需要增补。注意负向用例和无关用例不是用来“把Skill搞挂”的它们的价值在于暴露误触发和高估问题。很多Skill正面测试全过一遇到无关场景就抢活全靠这两类用例才能查出来。4.2 评分规则怎么写才不冤枉人关键词命中权重只占20%我在2.4已经讲过关键词匹配的惨案。所以升级评分规则时我做的第一件事就是把关键词命中的权重从100%降到20%其余80%交给语义相似度和结构约束。这里给一个我当前在用的简化评分方案你可以直接参考# 简化版Skill体检评分逻辑示意 def score_output(expected, actual, keywords, checks): score 0 total_weight 0 # 1. 语义相似度占50%权重 semantic_score semantic_similarity(expected, actual) # 0~1 score semantic_score * 50 total_weight 50 # 2. 结构约束占30%权重 structure_score 0 for check in checks: if check(actual): structure_score 1 structure_score structure_score / len(checks) score structure_score * 30 total_weight 30 # 3. 关键词命中仅占20%权重 keyword_score sum(1 for kw in keywords if kw in actual) / len(keywords) score keyword_score * 20 total_weight 20 return score / total_weight * 100结构约束是我最推荐的评分维度。所谓结构约束就是“输出的格式和关键元素”比如要求输出包含动作描写、包含场景氛围、包含角色反应。这些是可验证的硬性指标比关键词匹配好使比语义相似度容易实现。实际使用中我建议语义相似度阈值设在0.7以上为合格但这个值不是死的——有的Skill输出风格比较自由相似度天然偏低需要结合人工抽查看。4.3 跑一次完整体检的检查单从环境准备到结果归档最后给一个可以直接抄的检查单。我每次体检大约30-40分钟跑完30个Skill基本流程如下准备测试环境。确认模型版本固定关闭无关插件避免测试结果受环境干扰。我见过跳过这一步的人——体检出来分数忽高忽低根本原因就是两次测试用了不同模型版本。导入用例集。把每个Skill的专属用例集导入体检器。没有专属用例集的Skill先补用例再测试不要偷懒。批量执行测试。逐条执行用例记录每次调用的日志、模型输出、评分结果。批量跑完大概20分钟。拉取0分和低分记录。关注0~60分区间的Skill先别急着下结论。人工复判。按3.1的三步流程对低分Skill做日志回撤、输出回放、交叉复跑。这一步最费时但也最重要。归因修复。按加载层、用例层、评分规则层、模型执行层四类归因生成修复清单。可以顺手把修复状态记下来下一轮体检时验证。结果归档。把每个Skill的历次体检数据归档形成趋势。这一步可以让你在两周后回答“这个Skill到底有没有越修越好”。把这套流程走完你对Skill的认知会从“凭感觉”变成“有历史数据”这是质的差别。5. Skill评测这件事可能比想象中更重要5.1 Skill生态正在经历“什么都能Skill化”的阶段最近翻社区我注意到一个明显趋势Skill正在向所有垂直场景渗透。有人做“GIS空间分析”的Skill有人做“小说写作”的Skill有人做“AI备课”的Skill还有人做“打斗动作提示词”的Skill、“前任”题材的创意Skill。甚至有人把SolidWorks、Spring AI 2.0都往里接形成一套完整的“工具即技能”生态。这个趋势本身是好事因为它意味着Agent从“聊天工具”向“生产力工具”进化。但有个隐患Skill的产出速度远远快于评测机制的建设速度。代码写得再花哨没有一套靠谱的评估系统生态里就会充满“装了但不好用”的Skill——用户装上试一次发现效果不行卸载再也不敢装第二个。所以我特别想强调Skill体检这件事不是个人洁癖而是生态健康度的一部分。只有评测机制跟上了Skill开发者才能知道该往哪优化用户才敢放心用。5.2 体检器把我从“收藏家”变成了“维护者”跑完第一轮体检后我最大的改变是对待Skill的方式从“收藏家”心态变成了“维护者”心态。以前我是“看到有用的就装装了就不管”一个Skill用几次觉得不顺手就扔角落里吃灰继续去装新的。这实际上是一种囤积癖像下载了几百个App却永远不更新。现在我会定期跑一轮体检给每个Skill建立健康档案哪些需要升级、哪些需要重写、哪些应该删掉一清二楚。维护频率上我建议每两周跑一次每次30-40分钟。太频繁没意义因为模型和Skill内容不会在几天内发生剧烈变化间隔太长又容易积压问题。这个节奏比较合适。5.3 后续可以怎么扩展这个体检器体检器本身的迭代空间也很大。我目前已经在计划几个扩展方向多模型交叉验证。同一个Skill用不同模型跑同一组用例看评分差异。如果一个Skill在模型A下表现优秀、在模型B下表现拉胯那很可能是Skill对这个模型太“挑食”需要兼容性优化。外部依赖可用性探测。很多Skill会调用外部API或本地工具如果接口失效Skill的性能就会断崖式下跌。我打算在体检器里加一个依赖探测模块每次体检前先自动检查所有依赖的可用状态提前暴露隐藏问题。评分规则插件化。现在评分规则是写死的我希望把它做成可配置的插件系统——不同场景的Skill可以选用不同的评分模块。比如“写作类”Skill用语义相似度风格一致性“工具类”Skill用输出格式执行成功率。这些方向做完之后我手里这30个Skill就不再是一堆凭感觉维护的“黑盒子”而是一套有测试数据、有迭代记录、有持续监控的资产。如果你手里也攒了不少Skill我的建议是别急着删掉那些“感觉不好用”的先把它们跑一遍体检。很多时候问题不在Skill本身而在它没有被正确地装好、没有被正确地测试、或者被一把不合适的尺子量了一通。先修评测系统再修Skill顺序千万别搞反。