P.S. 推荐一个大神的教程给想要了解或者学习人工智能知识的读者，这个教程里内容讲解通俗易懂且风趣幽默，对我帮助很大。我想与大家分享这个宝藏教程，请点击下方链接查看， 传送门https://blog.csdn.net/qq_74013365

1. 为啥你写的Skill，自己用还行，给同事就翻车

很多人写完一个Skill，随便找段输入跑一遍，一看输出整整齐齐，当场就觉得大功告成。

咖啡还没凉，已经开始琢磨怎么发到群里，等着同事喊大神。

结果一周不到，同事过来找你：我输了段会议记录，它怎么没反应？

再过两天又来：它怎么还给我编了个会议日期？我根本没写啊。

场面一度十分尴尬，堪比你写的代码本地跑通，上线直接崩给全公司看。

1.1 绝大多数人都踩过这个坑

说真的，这真不是你一个人的毛病。

大部分人做Skill，都是“一次跑通=做完了”。

毕竟肉眼看着结果没问题，谁还愿意费劲儿反复测啊。

可问题是，AI这东西，这次跑对了，不代表下次也对；你这么输入对了，不代表别人换个说法也对。

就像你楼下的煎饼摊，今天酱料刷得刚刚好，明天老板心情不好，给你刷三倍辣酱，你也没地方说理去。

Skill要是没经过测试，本质上就是个玄学工具——能用，但你永远不知道它什么时候掉链子。

1.2 一个靠谱的Skill，必须答得上这三个问题

想把一个Skill从“能跑”变成“靠谱”，你得先答得上三个问题，一个都不能少。

第一个，该它干活的时候，它能不能准确出来？不该它干的活，它会不会瞎凑热闹？

第二个，它干出来的活对不对？有没有自己瞎编东西，格式有没有按要求来？

第三个，它能不能稳定发挥？同一段输入跑十次，是不是每次结构都大差不差？

这三个问题但凡有一个答不上来，你的Skill就还属于“抽奖款”，用不用全看运气。

2. 测试也分三档，别上来就搞大动作

2.1 不同段位的Skill，配不同强度的测试

当然了，也不是所有Skill都得搞一套完整的测试流水线。

测试这东西，投入得和重要程度匹配，杀鸡就别用牛刀了。

第一种，手动测试。直接对着对话框输请求，看它触发不触发、结果对不对。

好处是快，啥额外准备都不用，写完随手测一遍就行。自己平时用的小Skill，这么测基本够了。

第二种，脚本测试。把测试用例写成自动化脚本，以后改完Skill一键重跑。

团队共用的Skill，最好搞上这个，不然每次改完你手动测十几条，一下午就没了。

第三种，程序化评估。整套完整的评测体系，用API批量跑测试集，量化打分。

这种一般是面向大量用户的产品级Skill才用得上，普通团队真没必要，太费劲儿。

2.2 高手都先啃最难的那个样本

这里说个很实用的小经验，能帮你省好多时间。

别一上来就整二十个测试用例挨个跑，没用。

真正会做Skill的人，都会先找一个最难搞的样本——比如你能找到的最乱、最没章法的输入。

然后死磕这一个，把Skill调到能完美处理它为止。

搞定一个难到离谱的失败案例，比十个简单用例全通过都有用。

就像打游戏，你先把最难的BOSS过了，后面的小怪不都是砍瓜切菜？

等难样本稳了，再慢慢扩充测试用例，效率高多了。

3. 三步自测法，测完心里才有底

3.1 第一步：该触发的时候得醒着，不该触发别瞎凑热闹

先来说第一个测试：触发准不准。

大家都知道，Skill能不能被调用，全看它的描述写得怎么样。

描述写得太窄，用户正常说话它识别不到；写得太宽，八竿子打不着的请求它也往上凑。

所以测触发，你得准备两份清单。

一份是“应该触发”的：比如用户各种口语化的说法，“帮我整理下会议记录”“把刚才的会总结下”，甚至直接甩一段乱七八糟的笔记过来。

另一份是“不该触发”的：看着沾边但其实没关系的，比如“帮我写个周报”“做个支出表格”。

别觉得第二份没用。一个啥请求都敢接的Skill，和一个永远叫不醒的Skill，一样没用。

就像你家智能音箱，你喊它开电视它没反应，你打个喷嚏它给你放首歌，你说气不气人。

嫌麻烦的话，可以先问一句：你什么时候会用这个Skill？

它的回答要是连你觉得最常用的场景都没覆盖到，那别犹豫，先改描述去。

3.2 第二步：输出得守规矩，不能自己加戏

触发没问题了，就得看活干得漂不漂亮。

测这个之前，你得先想清楚：你这个Skill的成功标准到底是什么？

就拿会议纪要整理来说，得有固定的几个章节吧？不能瞎编原文没有的信息吧？行动项得有负责人吧？最后得比原文短吧？

功能测试，就是拿一段已知内容的输入，对着这些标准一条条核对。

比如你输入一段明确的会议内容，里面有参会人、有决定、有行动项、有没定下来的事。

然后看输出是不是全对上了，有没有多出来什么奇奇怪怪的内容。

这里特别提醒一句：一定要测“没说的信息它会不会瞎编”。

这真的是重灾区。很多Skill啥都好，就是爱自作主张，原文没提日期，它非要给你补个具体日期，说得跟真的一样。

不知道的还以为它去现场开会了。

测试用例里务必留一个“正确答案就是没说明”的坑，专门治这种爱加戏的毛病。

3.3 第三步：别周一一个样，周五直接换了个模样

前两项都过了，还有最关键的一关：稳不稳定。

很简单，同一段输入，你连续跑个五次。

然后看看五次输出，是不是结构都一样。

不是说文字必须一模一样，AI本来就会换措辞，这很正常。

但章节不能变吧？格式规则不能变吧？没信息的时候该标“未分配”就标“未分配”，不能这次标下次就自己瞎猜一个。

要是第一次四个章节全齐，第三次直接丢了一章，那哪怕单次结果再好看，也没法放心用。

总不能每次用之前都先拜一拜，祈祷今天AI状态好吧？

真出现这种结构漂移的情况，一般就是你指令写得还不够严。

把核心规则往前提，写得再直白点，明确告诉它什么才叫完成了。

毕竟一致性本来就是我们用Skill的初衷。要是每次结果都开盲盒，那我们干嘛不自己整理呢？

4. 懒人必备：写个脚本，以后改完一键跑

4.1 一个最小可用的测试脚本长啥样

说到这儿肯定有人嫌麻烦：每次改完都要手动测这么多，也太费时间了。

没错，所以我们得把它自动化。

写个小小的测试脚本，以后改完Skill，运行一下，几秒钟就能知道全没全挂。

结构也不复杂，就在你的Skill目录里建个tests文件夹，放个测试脚本就行。

脚本直接读你真实在用的SKILL.md文件，不用单独再维护一份指令，省得改了主文件忘了改测试的，两边对不上。

用Python标准库就能写，不用装乱七八糟的依赖，配置好API Key就能跑。

跑出来结果清清楚楚，哪些过了哪些挂了，一眼就能看见。

4.2 这个脚本的几个小心思

这个脚本别看小，该测的地方一点没落下。

触发测试，它会把Skill的描述发给模型，直接问这个场景该不该触发，专门测你描述写得到不到位。

功能和一致性测试，它会把完整的Skill指令喂给模型，然后用代码自动核对结果。

比如章节全不全、有没有超字数、没给日期的时候会不会瞎编出日期格式的内容，都能自动查。

当然了，它不是什么生产级的完整评测系统，也不是所有平台都通用。

但用来做快速回归测试，完全够用了。

后续想加测试用例也简单，在脚本顶部加一行就行，成本几乎为零。

5. 测挂了别慌，对着症状找病根

测试跑挂了别慌，不同的挂法，对应不同的改法。

第一种，该触发没触发，漏触发了。

大概率是你描述写得太模糊，没覆盖用户真实的说法。补点常用的触发词，技术类的Skill可以加上准确的关键词和文件类型。

第二种，不该触发瞎触发，误触发了。

那就是你描述范围写太宽了。收一收，明确说清楚哪些场景不归它管。

第三种，触发没问题，但结果不对或者不稳定。

这就和描述没关系了，是你正文指令的问题。把操作步骤写细一点，关键规则往前放，明确合格的结果长啥样。

说白了就三句话：没触发就补描述，乱触发就收范围，结果不稳就加规则。

其实测试这东西，从来不是为了让你第一次就全绿通关。

它真正的用处，是等你后面改Skill的时候，能一眼就知道哪块改坏了，不用瞎猜。

Skill这东西本来就是越迭代越好的，后面总会遇到各种奇奇怪怪的输入。

有一套测试在那儿撑着，你改的时候心里就有底，不用担心越改越烂。

等你真把它测稳了，再发给同事用，腰杆都硬得多。

P.S. 推荐一个大神的教程给想要了解或者学习人工智能知识的读者，这个教程里内容讲解通俗易懂且风趣幽默，对我帮助很大。我想与大家分享这个宝藏教程，请点击下方链接查看，传送门https://blog.csdn.net/qq_74013365