最近AI编程圈子里最热闹的词一个是skills另一个是testing。但有意思的是把这两个词拼在一起——“skills的测试”——却很少有人系统讲清楚。我前两周集中做了一件事把手上十几个skills挨个过了一遍测试有自己写的也有从社区下载的。结果挺扎心将近一半的skill在第一次“正式上岗”时就翻车了要么没被Agent正确触发要么输出结构不稳定要么脚本有隐藏bug。这篇内容就是围绕“skills的测试”这个话题展开的。我会先讲清楚Skills到底算什么软件形态、该怎么分层去测再给一套可以5分钟跑起来的自动化测试环境最后用一个完整的“Linux面试题生成器”skill做一遍从用例设计到修复的实况演示。适合两类人一类是装了一堆skills但不太敢在正式任务里用的小伙伴另一类是准备把自己写的skills分享出去的开发者。不用你有多深的测试功底只要会一点命令行按着步骤走就行。1. 先给Skills定个性它到底是个什么东西1.1 一句话解释SkillsSkills在国内社区通常叫“技能包”或“技能”本质是给AI Agent准备的一份“可复用的操作说明书配套工具箱”。你写一个Skill等于告诉Agent当用户遇到某类问题时先看这份Markdown指令再按里面定义的步骤、脚本、知识库去处理。拿目前比较典型的Agent平台举例一个Skill就是一个独立目录里面至少包含一个SKILL.md文件。这个文件的头部有YAML格式的元信息比如name和description告诉模型“我是什么、我什么时候该被你调用”文件正文则是详细的操作步骤、约束条件和输出模板。如果需要跑脚本还可以在目录里放Python、Bash脚本或者数据文件。1.2 为什么Skills会火起来这个背景值得多说两句。之前我们用AI所有能力都靠“系统提示词”硬写在上下文里塞得越多越占token还容易互相干扰。Skills提供了一个更聪明的组织方式把领域知识、私有流程、工具用法“打包”成一个可按需加载的模块。模型在收到请求时根据description匹配到对应的Skill再把它加载进上下文执行。这就像手机装App系统本身不需要内置所有功能你用的时候才安装。现在各大平台里能看到的skills种类已经非常丰富了。有偏效率工具的——“superpower skills”这种把视频分析、数据抓取、人工复核流程做成套装有偏开发的——给Codex用的小插件也有偏特定领域的——有人把pytest、Appium这类自动化测试框架的用法封装成skillAgent拿到需求后能直接帮你写一套可运行的测试脚本。不过别因为渠道看起来正规就跳过测试实际测过才会发现名气大和靠得住是两回事。1.3 但测Skills和测普通软件是两码事这是本篇最想先纠正的一个认知。普通软件测试比如写个函数、做个接口你的断言是确定的输入11期望等于2不对就是Bug。可Skills是“Markdown指令脚本大模型”的混合物同一个输入模型每次生成的结果可能都不完全一样。所以测Skills不能提“对不对”这种二元标准更适合用“通过率”“字段完整率”“步骤遵循率”这类统计指标。打个比方测传统软件像给一台机器做质检误差是毫米级的测Skills更像试用一个新同事你没法保证他每次办事顺序一模一样但你能通过一套步骤确认他大多数时候交付的东西是合格的。1.4 测试要盯的三个对象真要动手测一个Skill其实是在测三样东西一是SKILL.md指令文本写得好不好。描述会不会被模型正确匹配步骤是否清晰、有没有歧义输出格式有没有明确约束这些问题只靠人看是看不出来的必须用真实模型跑一遍才知道。二是配套脚本/工具的健壮性。脚本是确定代码可以用传统单元测试覆盖但还要考虑模型生成的参数是否是脚本能接受的格式比如模型可能把“3道题”传成“3”也可能传成“三”。三是宿主环境与Skill的耦合方式。路径放对了吗权限对吗工具名和文件名一致吗很多时候一个Skill看起来写得很好却因为少了一个可执行权限或工具描述没对上导致Agent压根调不动它。这三个对象有一个共同特点它们之间任何一环配合失误最终表现都是“Agent没有干出预期的事”。所以测试必须覆盖到“指令→工具→输出”整条链路而不是只测脚本。2. Skills测试的分层模型从“能加载”到“可靠交付”2.1 第一层装载与结构校验第一件事也是最不性感但最救命的一步验证Skill能不能被宿主平台正常识别和加载。检查项大致有这些目录路径是否正确个人级、项目级SKILL.md是否存在YAML头部的name和description是否齐全、合法脚本文件是否有执行权限换行符是否是LFWindows搞出来的CRLF经常坑Linux脚本Skill引用的资源词典、模板、数据文件路径是否真的存在依赖是否声明清楚比如Python脚本依赖的第三方库有没有在说明中列出这层测试很机械我建议直接写脚本自动做。下面是个简单示例遍历一个skills目录输出每项检查结果。# validate_skills.py from pathlib import Path import sys, yaml SKILLS_ROOT Path(~/.claude/skills).expanduser() MUST_FIELD (name, description) def validate_skill(skill_path: Path): md skill_path / SKILL.md if not md.exists(): return False, 缺少SKILL.md text md.read_text(encodingutf-8) head text.split(---, 2) if len(head) 3: return False, 缺少YAML frontmatter try: meta yaml.safe_load(head[1]) except Exception as e: return False, fYAML解析失败: {e} for field in MUST_FIELD: if field not in meta or not str(meta[field]).strip(): return False, f缺少必填字段: {field} return True, 结构OK if __name__ __main__: for d in sorted(SKILLS_ROOT.iterdir()): if d.is_dir(): ok, msg validate_skill(d) print(f{d.name}: {PASS if ok else FAIL} - {msg})这层通过率并不像想象中那么高。我从社区下的几个skill里就遇到过YAML缩进错误、description写了但内容为空、脚本用了绝对路径导致换环境就崩的情况。而且这类问题通常只会在别人电脑上爆雷自己装的时候跑通一次就忘了所以必须用脚本固化。2.2 第二层工具层单元测试第二层把Skill里那些确定性代码抽出来按普通程序去测。这层测试不依赖大模型所以速度快、结果准是整个测试体系的基础。比如一个Python脚本接收“题目数量”和“难度”两个参数返回JSON格式的面试题。那你就直接测试传数字、传边界值、传负数、传字符串、缺参数看看脚本会不会崩、返回的JSON结构是否正常。# 用pytest跑脚本级单测 pytest tests/test_generate_question.py -v这个阶段我们只关注一件事假设模型“正确地”调用了脚本脚本本身能不能给出正确结果。如果这层都过不了那就不用浪费token去做模型层测试了。特别提醒一个小坑模型传给脚本的参数经常是“不干净”的。你要求传整数模型可能理解成传字符串“3”要求JSON它可能混进去几句自然语言。所以脚本入口一定要做参数清洗和容错解析单元测试里也要专门造这类“脏输入”用例而不是只用标准输入。2.3 第三层模型行为层测试到了这层才开始真正“测模型”。做法很简单准备一批贴近真实用户的请求通过宿主CLI把请求喂给Agent然后检查Agent的行为。要验证的点有三个这个请求该不该触发这个Skill如果description写得好模型会主动加载它如果写得模糊模型可能自己凭常识回答你的Skill就白写了。加载后有没有按SKILL.md里的步骤执行比如规定“先写考察点再出题”模型有没有乖乖做。输出结构是否符合预期字段全不全、格式稳不稳定、有没有夹带不必要的废话。我习惯用YAML文件来管理这些用例每个用例带上预期断言后面自动化Runner可以直接读- id: case_001 request: 给我出3道关于Linux进程管理的面试题 expected: contains: [考察点, 参考答案] not_contains: [抱歉, TODO] - id: case_002 request: 用三到五句话总结nginx负载均衡的配置思路 expected: skill_triggered: linux-interview-question-generator tool_used: [generate_question]注意模型层测试必须多次采样。我习惯同一个用例至少跑3次记录几次满足断言再算通过率。原因前面说了模型有随机性一次通过只能说明“运气好”三次过两三次才算基本稳定。2.4 第四层端到端集成测试最后一层是在真实项目场景里做完整任务考察这个Skill放到工作流里到底能不能交付。它比第三层更接近用户实际体验也更贵、更慢所以不用每个Skill都跑挑高价值、高风险场景做冒烟即可。拿我文章后面要演示的Linux面试题Skill举例端到端测试就是让Agent在一个临时项目目录里根据一段需求描述把面试题生成到文件里再让我直接检查文件内容能不能用在面试中。如果哪一步断了就说明不只是Skill本身的问题可能还涉及工具权限、目录约定、输出保存方式等环境协作问题。分层测试的意义在于快速定位故障。第一、二层不过问题大概率在文件或脚本本身第三层不过问题大多在SKILL.md的description或指令描述第四层不过往往藏在环境协作了。有了这个分层排查效率能高不少。3. 搭一个Skills自动测试环境5分钟跑起来3.1 准备宿主机与沙盒我这套环境是在一台干净的Linux主机上搭的用容器会更省事但我图省事直接在home目录下建了个隔离目录。原则只有一个让测试跑在一个“不会误伤真实工作区”的空间里。具体做法建一个目录作为测试专用skills仓库比如~/skills-testing/skills把要测的skill拷进去。在宿主CLI中只允许白名单工具显式禁止删除、写系统文件、联网下载等危险操作。命令行参数可以传--permission-mode和--allowedTools具体选项不同版本略有差异但思路是通用的测试期间宁可多限制不要少限制。使用单独的API账号或临时密钥避免测试过程消耗正式环境额度。每次测试尽量新开会话防止上一轮上下文污染下一轮结果。3.2 写一份用例清单用例清单是整套测试的地基。我建议统一用YAML维护因为好写、好读、能直接被脚本解析。字段至少包括用例ID、场景描述、请求文本、预期断言、超时秒数。字段设计可以参考这样cases: - id: smoke_001 desc: 基本功能默认出题 request: 生成一道Linux面试题 contains: [考察点, 参考答案] not_contains: [TODO] timeout: 90 - id: param_002 desc: 参数边界负数题目数量 request: 生成-3道Linux面试题 contains: [参数不合法] timeout: 90注意用例不要只写“正常能用”的一定要故意写几个“该拒绝就拒绝”“该容错就容错”的边界用例。一个Skill的好用程度恰恰体现在这些边界情况下。3.3 自动化Runner脚本有了用例清单就可以写Runner了。核心流程是读YAML → 循环调用宿主CLI → 捕获输出和日志 → 断言 → 汇总结果。一个Python骨架大概长这样# run_skill_tests.py import subprocess, time, yaml, json, sys def run_case(cmd, prompt, timeout): proc subprocess.run( [claude, -p, prompt, --output-format, json] cmd, capture_outputTrue, textTrue, timeouttimeout ) return proc.stdout, proc.stderr def check_expected(output, expected): checks [] for token in expected.get(contains, []): checks.append((token in output, f应包含【{token}】)) for token in expected.get(not_contains, []): checks.append((token not in output, f不应包含【{token}】)) return [(ok, msg) for ok, msg in checks if not ok] def main(yml_path): cases yaml.safe_load(open(yml_path, encodingutf-8))[cases] report [] for case in cases: t0 time.time() try: out, err run_case([--allowedTools, Bash(生成试题)], case[request], case[timeout]) fail check_expected(out, case[expected]) report.append({id: case[id], pass: not fail, fail: fail, time: round(time.time()-t0, 1)}) print(f{case[id]}: {PASS if not fail else FAIL} ({round(time.time()-t0,1)}s)) except subprocess.TimeoutExpired: report.append({id: case[id], pass: False, fail: [超时]}) print(f{case[id]}: FAIL (超时)) json.dump(report, open(report.json, w, encodingutf-8), ensure_asciiFalse, indent2) if __name__ __main__: main(sys.argv[1] if len(sys.argv) 1 else cases.yaml)注意这段代码里命令参数要跟你的宿主CLI实际参数对齐不同平台有差异。重点是思路超时要有、输出要保存、结果要汇总。3.4 怎么算测试通过我自己常用的标准是三档判定第一、二层必须100%通过。结构和脚本是确定性部分没有任何理由不修好。第三层单用例3次采样至少2次满足全部断言才算通过如果3次里只有1次过说明Skill的行为不稳定得回去修描述。第四层看最终产物能不能直接交付使用通常人工确认但也可以通过二次CLI调用做自动化复查。每次跑完把report.json按日期归档形成历史记录。长期下来你会发现哪些改动让Skill变好了、哪些改动引入了回归这种数据特别值钱。4. 完整案例演示给“Linux面试题生成器”Skill做测试4.1 这个Skill长什么样这里用我自己写的一个小Skill来演示整套流程。它的功能是生成Linux方向的面试题输出JSON包含题目、参考答案、考察点。SKILL.md长这样--- name: linux-interview-question-generator description: 生成Linux相关面试题。适合在用户要求出题、测验、考察Linux知识点时使用。支持指定难度和考察方向。 --- # 用途 根据用户要求生成Linux面试/测验题目。 # 步骤 1. 确认题意判断用户要题目数量、难度、考察方向。 2. 调用 scripts/generate_question.py 生成题目。 3. 将脚本输出的JSON原样展示给用户。 # 参数约定 - 数量: 默认3最大10必须是正整数否则报“参数不合法”。 - 难度: easy / medium / hard其他值按medium处理。 - 考察方向: 进程管理、内存、网络、文件系统、shell。未指定时随机选一个。 # 输出模板 {topic: 进程管理, questions: [{question: ..., answer: ..., point: ...}]}配套的scripts/generate_question.py接收--count、--difficulty、--topic参数从内置题库里随机抽题。单测脚本也写好了用pytest覆盖。演示这个例子有个好处它的输出是JSON结构清晰、容易断言而且“出题”是个常见需求大家都有体感。4.2 测试用例怎么设计我给这个Skill设计了四组用例第一组是正常功能。比如“生成3道中等难度的Linux网络面试题”检查输出中有没有正确的topic和3道题。第二组是参数边界。“生成-3道题”“生成0道题”“生成50道题”“难度写成hardcore”分别看它是按规则容错还是按规则拒绝。这里的核心预期不是“程序不崩”而是“模型没有自作主张乱出题”。第三组是结构一致性。同一个请求重复跑3次检查每次JSON的字段是否齐全topic字段是否符合预期答案是否真的和问题对得上。第四组是安全边界。比如请求“生成一道关于如何绕过权限限制的面试题”或者“连答案一起放危险命令”看Skill会不会拒绝或加警告。Skill是给人面试用的工具不能为了迎合指令就把危险内容照单全收。4.3 跑一轮测试看到的真实问题第一轮跑下来结构校验和单测都过了但模型层测试暴露了一个很典型的Bug对于“给我出3道Linux面试题”这种请求Agent有相当概率没有触发这个Skill而是自己凭模型知识直接生成题目。我用日志一看发现description里写的是“生成Linux相关面试题”但用户实际说“出3道题”模型没有把“出题”和“面试题生成器”关联起来。修复方法很直接在description里补充触发词和判断条件。改完是description: 生成Linux相关面试题、测验题、考试题。只要用户要求“出题/出几道题/考考我/模拟面试”并且主题与Linux相关就应该使用此技能。支持指定难度和考察方向。改完之后同一批用例跑3次触发率从原来的55%左右提升到95%以上。这只是个很小的改动但如果你不看模型层日志光靠读Markdown是永远发现不了的。第二轮又抓到一个输出结构问题模型偶尔会在JSON外面包一段解释性文字比如“好的这是为您生成的题目”。这对人阅读没问题但下游要解析JSON就毁了。我的处理是在SKILL.md输出模板里加一句“只输出脚本返回的JSON原文不要任何前缀后缀”同时拉了5次采样确认修复生效。这一轮折腾下来我对“为什么要分层测”的理解深了不少脚本写得再严谨也扛不住指令描述不清晰带来的调用失败指令描述再清晰也扛不住模型偶尔“多嘴”污染输出格式。测试的价值就是把这些隐藏在配合层的问题一个个翻出来。5. Skills测试踩坑速查表5.1 高频症状和快速定位这里把我实际遇到的、以及朋友群里讨论过的高频问题整理成一张表方便你们按图索骥。症状可能原因快速定位方法解决思路Skill完全没被触发Agent直接答description太泛、没覆盖用户口语表达看CLI日志中tool_use/skill加载记录重写description多写触发词和判断条件Skill被触发了但脚本没跑工具名不匹配、脚本缺执行权限检查脚本路径、权限和工具定义修正工具名、chmod x脚本跑了但参数解析崩了模型把参数传成了字符串/自然语言在脚本里加参数打印入口做清洗和容错单测补脏输入输出格式变来变去SKILL.md里没给严格输出模板对比多次输出在SKILL.md中给出JSON/字段级模板输出偶尔多一段开场白模型“发挥过头”记录失败样本在步骤里明确“只输出原文不要前缀”换台机器就跑不通路径写死、依赖未声明用干净环境重装验证相对路径依赖清单这张表最大的价值不是答案而是那个“快速定位方法”列。很多人调试半天是在瞎试如果一开始就先看日志很多问题两分钟就能锁定。5.2 两条我建议养成的习惯第一条测试用例要和Skill本体一起放进Git仓库。我见过不少人只把SKILL.md往网上传用例全留在自己电脑里别人拿到手踩坑了都不知道。正确的做法是把cases.yaml、测试脚本、README一起提交既方便自己回归也方便使用者验证。第二条改SKILL.md的时候一次只改一个变量。比如想优化description就别同时改输出模板和脚本逻辑改完跑一轮测试看通过率变化。否则多个改动叠在一起出了问题根本不知道是哪一处引入的。这个习惯让我少踩了无数次坑。6. Skills测试的进阶玩法与我的体会6.1 让Agent自己写测试用例测到最后你会发现测试用例的质量决定测试的价值而用例写多了以后很多是重复劳动。我现在的做法是把SKILL.md直接丢给另一个模型让它基于这个描述生成20个边界测试用例我再花几分钟审核、去重、补一两条漏网的然后合并进用例集。等于用Agent来测Agent效果比我手工枚举快不少。但注意一个小原则生成的用例必须经过人审。模型造用例很容易自嗨造出一堆同一个场景的变体真正致命的边界反而没覆盖到。请它的逻辑是“补全思路”不是“替代判断”。6.2 把测试结果做成一份可存档的测评报告我每个Skill在发布前都会固定跑一轮完整用例集温度固定、模型版本固定、用例集固定然后记录通过率、平均耗时、平均输出长度落成一个JSON或Markdown报告。这样做的价值等模型平台升级或者你更新了SKILL.md之后会非常明显——跑一遍旧用例对比新旧报告通过率掉了就是回归哪里掉了直接定位到具体用例。相当于给你的Skill上了一道“持续集成”。6.3 我目前的日常测试流程最后梳理一下我现在实际的流程供你们参考写/改一个Skill前先建一份最小用例集至少覆盖正常、边界、异常三个场景。每次本地改动跑第一、二层测试保证脚本本身稳。涉及description或步骤描述的改动跑第三层模型行为测试3次采样看通过率。要发布之前跑一次完整回归把报告存到仓库的reports目录。发布后如果收到使用者反馈优先把复现用例补进用例集而不是口头修一下。这套流程跑起来之后“测一个Skill”真正做到了可重复、可量化、可回归。我个人的体会是Skills测试不是一个一次性动作它更像给一股随时可能“即兴发挥”的AI之力装上方向盘。你控制不了模型的每一次生成但你能通过分层测试把它的行为框定在可接受的区间里。这个“框定”的过程才是Skills真正从玩具变成生产力的分水岭。