最近半年，我观察到一个有意思的现象。
很多测试团队开始不招“会写Selenium脚本”的人了。取而代之的是，面试题变成了“你如何让AI自动判断这段JSON返回对不对”、“如何用一条指令生成100条合法用户数据”、“如何教AI看懂一张截图里的按钮状态”。
不是招聘标准变了。是测试对象变了。
以前的测试对象是代码，你用断言函数比较两个值。现在的测试对象是大模型输出、AI生成内容、多模态交互。你没法写“assert equals”去判断一段自然语言是否正确，也没法写正则去验证一张图片里有没有出现半个图标。
很多人已经开始感觉到：不是AI在做测试，而是你根本不知道怎么测AI。
一、生成式测试来了，没人再手写“等于预期”
先看三个真实场景。
场景A：你测一个AI代码助手。它生成了一个函数，你要判断这个函数有没有bug。传统做法是人工review或者静态扫描。但AI每次生成的代码都不一样，你没法写断言。
场景B：你测一个电商推荐系统。每次请求需要构造一个用户画像——年龄、浏览历史、购买记录、实时位置。传统做法是写脚本随机生成。但数据关联性一复杂，随机生成的数据根本覆盖不了业务规则。
场景C：你测一个多模态应用，比如“拍照识物”。AI返回了一段文字描述和一张标注图。你怎么验证标注框的位置对不对？文字描述里有没有幻觉？传统断言完全失效。
这三个场景不是边缘案例，而是2026年测试工程师每天都要面对的主流场景。
字节跳动的AI测试团队在2025年底公开过一组数据：在使用传统自动化测试框架时，AI类产品的测试用例维护成本是普通产品的4.7倍。核心原因是输出不确定，断言写不了。
本质是：确定性系统的测试方法，在非确定性系统面前彻底失效了。
观点句1：测试的底层逻辑变了——从“校验输出”变成“校验能力”。
二、测试的底层资产从“用例”变成“Skill”
以前的测试资产是“测试用例库”。一个用例对应一个输入输出对。维护成本随场景数量线性增长。
现在的逻辑完全不同。
Skill是一个“能力单元”。它封装的不是一个具体输入输出，而是一种“做某件事的方法”。比如“判断代码有没有bug”是一个能力，“构造一个20-30岁、有3年工作经验的程序员画像”是一个能力，“检查图片里按钮是否可点击”是一个能力。
核心区别在哪里？用例是一次性的，Skill是可组合、可复用的。
当你有了一个“构造合法邮箱地址”的Skill和一个“生成随机密码”的Skill，你可以在不写新代码的情况下，组合出“构造注册请求数据”的Skill。这种组合能力让测试资产从线性增长变成指数复用。
实际上，业界已经在做这件事。Anthropic的Claude Code引入Skills机制，Cursor的Composer模型背后是多Skill编排，OpenClaw则把Skills作为核心扩展单元。
三、三类核心Skill的技术拆解
下面直接拆解三类测试Skill怎么设计。我会给出抽象层面的实现逻辑，不绑定具体代码。
类型1：自动断言Skill
输入：一段文本/结构化数据 + 断言规则描述 输出：通过/不通过 + 失败原因
设计要点：
本质是把“人工判断逻辑”翻译成结构化描述，交给大模型执行判断，同时约束输出格式。
具体做法：
- 定义断言Schema，比如
{ "passed": boolean, "reason": string, "evidence": string } - 在Skill的提示词里明确约束：不允许输出其他内容，不允许用模糊词（“大概”“可能”）
- 针对数值类断言，要求模型先提取数值再比较，避免幻觉
为什么这么做？因为没有约束的大模型会给你写小作文，没法集成到自动化流程。强制结构化输出后，断言Skill的输出可以直接被下游流程消费。
解决的痛点：AI输出的内容无法用传统断言覆盖，比如“这段话的语调是否积极”“这个解释是否逻辑自洽”。
类型2：数据构造Skill
输入：数据规格描述（如“20-30岁，月收入8k-15k，购买过3C产品”） 输出：符合规格的JSON数据
设计要点：
核心是对“数据合法性”的定义和约束传播。复杂点在于关联字段，比如年龄和收入要有相关性，不能给18岁配50万年薪。
具体做法：
- 使用约束求解的思路，在Skill内部维护字段之间的依赖关系（通过JSON Schema的
dependentSchemas或自定义规则） - 分为两步：先生成“属性签名”，再根据签名生成具体值。这能保证字段间的逻辑一致性
- 加入随机种子控制，确保同一规格的可重复生成
为什么这么做？简单随机生成的数据往往在业务逻辑上非法。比如“性别=男，怀孕周期=20周”这样的组合，常规随机生成会出现，而Skill可以把这种业务规则编码进去。
解决的痛点：测试数据从手工作坊变成自动化工厂，一条指令生成百条合法数据。
类型3：多模态识别Skill
输入：图片/音频/视频 + 需要识别的目标描述 输出：结构化识别结果（如坐标、分类、转录文字）
设计要点：
多模态识别是三类Skill中最复杂的。因为大模型对图像的“理解”不是像素级精准的。
具体做法：
- 不要直接用多模态模型判断“按钮是否可点击”，而是让模型输出按钮区域的坐标，然后在另一层用图像处理校验坐标是否在合理范围内
- 对于OCR类的验证，要求模型返回文本及其边界框，再做规则校验
- 善用“工具链式Skill”：一个Skill调用OCR工具，另一个Skill调用目标检测模型，再一个Skill负责融合结果
实际案例：测试“拍照识物”时，先用目标检测Skill定位物体框，再用多模态大模型描述内容，最后比对两个结果是否一致（框内物体和描述匹配）。
为什么这么做？单一模型容易产生幻觉，多模态Skill的核心是“交叉验证”，而不是依赖单一模型的一次判断。
解决的痛点：传统图像识别脚本依赖于预定义特征，适应场景变化差。多模态Skill可以理解“一个红色圆形按钮”，而不需要提前训练模型。
观点句2：测试Skill不是“调API”，而是把测试经验编码成可执行的逻辑规则。
四、三个真实场景：手工作坊 vs Skills流水线
用一个对比表格把差异说清楚。
| 场景 | 传统做法 | 耗时 | Skills库做法 | 耗时 |
|---|---|---|---|---|
| 验证AI生成的代码没有死循环 | 人工review + 静态分析扫描 | 10分钟 | 调用“代码安全断言Skill”，输入代码片段，返回可疑点 | 10秒 |
| 构造100个“深圳地区、月消费5k-8k、偏好户外运动”的用户 | 写Python脚本，手写规则，调试关联逻辑 | 2小时 | 调用“用户画像构造Skill”，传参数，一次返回100条 | 30秒 |
| 验证APP截图里的“立即购买”按钮是否可见且可点击 | 手工点开检查，或用图像识别库写定位脚本 | 15分钟 | 调用“UI元素识别Skill”，输入截图+目标文字，返回坐标和状态 | 5秒 |
差别不是“快了一点”，而是数量级差异。更关键的是，Skil库一旦建立，后续所有类似任务都不需要重复劳动。
一个真实的工程数据：某中型互联网公司测试团队用了3周时间搭建了包含12个测试Skill的私有库，之后两个月内重复使用超过300次，平均每个Saved节省45分钟人力。
五、行业参照：OpenClaw/Claude Code的测试Skill思路
这个领域已经有很多可参考的实践。
OpenClaw 的 Skills 架构 OpenClaw的设计是：Gateway管理通信，Channels对接具体平台，Agents编排决策，Skills提供可执行模块。它的一个测试Skill案例很有意思——他们做了一个“邮件验证Skill”，可以在测试流程中自动检查邮件服务器是否有新邮件、提取验证码、完成验证。这个Skill被多个测试场景复用，效率提升约40%。
对测试团队的启示：不要把Skills做成“单次任务脚本”。要设计成输入输出清晰的独立模块，可被多个Agent编排调用。
Claude Code 的断言思路 Anthropic在Claude Code中倡导的做法是：用MCP协议连接静态分析工具（如ESLint、Pyre）作为“硬断言”基底，再用大模型做“软断言”（如代码可读性、命名规范）。两层结合，既避免了纯大模型断言的不确定性，又避免了纯规则工具的僵化。
这个思路值得借鉴到测试Skill中：自动断言Skill应该调用工具做确定性的校验，调用大模型做语义级的判断，两层结果加权得出最终结论。
Cursor 的数据构造启发 Cursor的自研模型Composer强调“上下文感知”。在数据构造场景，这意味着Skill需要感知被测系统的当前状态。比如构造“边界测试数据”时，需要先调用API获取当前字段的最大最小值，再生成边界值。Skill不应是孤立的功能，而应能主动查询系统状态。
六、三步落地：从第一个私有Skill到团队Skill库
说了这么多，怎么从0到1开始？我给出三条可以直接上手的路径。
第一步：选一个最高频的痛点场景，写第一个私有Skill
不要贪多。挑你每天都要做、但每次都要花5分钟以上的事。比如“验证返回的JSON里某个字段不为空且类型正确”。把这个判断逻辑写成结构化提示词，放在固定目录，让大模型读它执行。
关键原则：Skill的输入输出要极其简单。对第一个Skill来说，输入一个JSON路径和一个期望类型，输出true/false就够了。
验证标准：你连续用这个Skill处理10个真实任务，成功率在80%以上。如果达不到，说明你的提示词颗粒度不够细。
第二步：引入工具调用，扩展Skill能力
纯提示词的Skill有上限。下一步是让Skill能调用外部工具。比如数据构造Skill调用Faker库生成基础数据，断言Skill调用jq提取JSON字段。
MCP协议就是做这个事的。你可以运行一个本地MCP Server，暴露几个工具函数，然后在Skill里声明“我可以调用这些工具”。部署完之后，Skill的能力边界从“语言理解”扩展到“能执行真实代码”。
第三步：建立Skill版本管理与反馈机制
Skill是会退化的。大模型更新后，之前好用的Skill可能变差。需要一个闭环：
- 每次Skill执行后，记录输入、输出、用户是否接受结果
- 定期Review低分的执行记录，优化Skill描述
- 每个Skill维护一个版本号和一个测试集，每次修改后跑回归
当你的团队有5个以上活跃Skill，并且每周都有新人开始使用而不是自己重写时，Skill库就真正活起来了。
观点句3：没有反馈闭环的Skill库，迟早变成数字垃圾堆。
七、你的测试用例，还能被复用几次？
最后说一个判断。
未来三年，测试团队的竞争力不在于“写了多少条自动化用例”，而在于“封装了多少个高复用度的Skill”。
用例是线性的，Skill是指数级的。
当你的同事还在为每个新接口手写断言脚本时，你调用一个“RESTful断言Skill”三秒完成。当隔壁团队还在为构造测试数据发愁时，你的数据构造Skill已经产出了上千条合法数据。
Skill库会成为质量工程的基础设施。就像今天没有人会从零写排序算法一样，明天没有人会从零写测试逻辑。
那你现在要回答的问题是：
把你过去一周写的所有测试脚本翻出来，有多少段逻辑是可以被抽象成一个Skill，让其他人以后不用再写第二遍的？
如果你的答案是“几乎没有”，那也许该重新审视一下，你是在做测试，还是在搬砖。
