扒开AI Skill的底层：自动断言、数据构造、多模态识别怎么做到的

最近在团队里做了一次技能盘点。

问了一圈：你们用AI辅助测试，最卡在哪？回答高度集中——AI生成的脚本，断言太弱。要么只检查HTTP 200，要么把整个响应体做字符串匹配，稍微换个字段顺序就挂了。

又问：那测试数据呢？有人苦笑。让AI造100条用户数据，它能给你100个“张三”，手机号全是11个1。

再问：UI自动化里最烦什么？所有人异口同声：元素定位。xpath像玻璃做的，UI一改全碎。

这些痛点，AI本身解决不了。因为它不懂你的业务规则，不知道什么是“正确”，不认识你的UI控件。

但有一样东西能解决：Skill。

不是那种“写段Prompt让AI自己猜”的野路子。是真正封装的、可执行的、带工具的Skill。今天直接拆三个最实战的：自动断言、数据构造、多模态识别。看它们到底怎么在底层跑起来的。

目录

• 一、不是AI不行，是你没给它“比较标准”
• 二、从“猜”到“测”：Skill让不确定性变确定性
• 三、三个核心Skill的底层实现
• 四、传统脚本 vs AI+Skill：一个文件上传功能的测试
• 五、你现在就能动手封装的三个Skill
• 六、测试Skill会成为下一个“JUnit”

一、不是AI不行，是你没给它“比较标准”

上周看了一个实际案例。

某人用Cursor Agent生成的接口测试脚本，断言部分长这样：

assert response.json() == expected_json

跑一次没过。因为实际返回里多了一个timestamp字段。他把expected_json加上timestamp，再跑又没过。这次是因为浮点数精度不一致。

改了三轮，最后放弃。结论是“AI不行”。

但问题不在AI。问题在于，他没有给AI一个“比较器”Skill。AI不知道你要的是“忽略时间戳”“浮点数误差小于0.01”“数组顺序无关”。

你让一个实习生去判断两张报表是否一致，不给规则，只给一句“你自己看看”——他也做不好。

这就是自动断言Skill要解决的问题。

本质上，AI不需要自己去比。它只需要学会调用一个专门做比较的Skill。这个Skill里封装的不是大模型，是确定性的比较算法——deepdiff、json schema validator、正则表达式。

可以截图传播的观点句1：好的断言Skill，是把“怎么比”从“比什么”里拆出来，让AI只操心前者。

二、从“猜”到“测”：Skill让不确定性变确定性

大模型的强项是理解和生成。弱项是精确计算和规则执行。

你让AI生成一个18位的身份证号，它能给你一个字符串，但校验位可能算错。你让它判断两张截图里的按钮是否在同一位置，它可能看出“都在右下角”，但像素误差是多少？说不准。

Skill就是来解决这个错配的。架构如下图：

┌─────────────────────────────────────────────────────────┐
│                      AI Agent                            │
│   理解需求 → 规划步骤 → 决定调用Skill → 解释结果         │
└─────────────────────────────────────────────────────────┘
                              │
                              ▼ MCP协议
┌─────────────────────────────────────────────────────────┐
│                    Skill 调度层                          │
├───────────────┬───────────────┬─────────────────────────┤
│ 自动断言Skill │ 数据构造Skill │ 多模态识别Skill          │
└───────────────┴───────────────┴─────────────────────────┘
          │               │               │
          ▼               ▼               ▼
┌───────────────┐ ┌───────────────┐ ┌─────────────────────┐
│ deepdiff      │ │ Faker         │ │ 视觉大模型(定位)     │
│ json schema   │ │ 规则引擎       │ │ OpenCV(像素比对)     │
│ 正则表达式     │ │ 校验闭环       │ │ 目标检测             │
└───────────────┘ └───────────────┘ └─────────────────────┘

每一层都有分工。Agent不直接干活，它负责“派活”。Skill里的工具函数负责“干精准的活”。

核心变化是什么？不确定性的大模型输出，被确定性工具函数“锚定”住了。 AI说“这个响应应该符合某种结构”，然后调用JSON Schema校验器——后者给的是肯定正确的布尔值。

三、三个核心Skill的底层实现

自动断言Skill：把“比较规则”参数化

怎么做的？

第一步：定义Skill的输入。不传整个预期响应，而是传一组比较规则。例如：

• 忽略字段列表：["timestamp", "traceId"]
• 数值精度容忍度：1e-6
• 数组比较模式：无序
• 必存在字段：["code", "data.userId"]

第二步：Skill内部调用deepdiff或自定义比较器，按规则逐项对比。 第三步：返回结构化差异报告。不是简单的True/False，而是“data.userName期望是张三，实际是张四”。

为什么这么做？因为AI擅长生成本地化、语义化的比较规则（“忽略时间戳字段”），但不擅长逐字节比对。把后者交给确定性代码，准确率100%，效率高两个数量级。

数据构造Skill：生成-校验闭环

怎么做的？

不是让AI一次性生成100条数据。而是：

1. Agent根据字段描述，生成一条候选数据。
2. 调用数据校验Skill，检查合法性（手机号格式、身份证校验位、业务关联约束）。
3. 校验不通过，把错误信息喂回Agent：“手机号段130开头已停用，请用150段”。
4. Agent修正，重新生成。循环直到通过。
5. 通过后加入结果集，继续下一条。

核心机制是“反馈闭环”。AI负责试，校验器负责把关。试错成本很低，因为生成是廉价的。

解决了什么问题？解决了“AI瞎编”的问题。不让AI一次搞定，让它迭代逼近正确答案。同时，合规数据可以被缓存成模板，下次直接复用。

多模态识别Skill：视觉定位 + 语义理解

UI自动化最大的坑是元素定位。xpath依赖DOM结构，小程序和原生应用根本拿不到。

多模态Skill换了一条路。怎么做的？

输入：截图 + 目标描述（“红色的提交按钮”）。 流程：

1. 截图传给视觉大模型（GPT-4V或专用模型）。
2. 模型返回目标元素的边界框坐标（x,y,width,height）。
3. Skill调用本地点击工具，在坐标处执行点击。
4. 如果需要断言按钮状态，再次截图传模型问“按钮是否是置灰状态”。

为什么不直接用传统CV？因为传统CV不识语义。“红色的提交按钮”里有“提交”这个语义信息，只有大模型能理解。传统模板匹配做不到。

解决了什么问题？跨平台、跨技术栈的UI自动化。Flutter、React Native、小程序、甚至桌面应用，通吃。只要你能拿到屏幕截图。

可以截图传播的观点句2：多模态识别Skill的本质，是把“找元素”从DOM解析变成了“看图说话”，通用性直接拉满。

四、传统脚本 vs AI+Skill：一个文件上传功能的测试

测试点：用户上传一张头像图片，要求jpg/png格式，大小不超过2MB，图片中必须有人脸。

传统自动化脚本：

• 断言1：检查上传接口返回的URL后缀是否为.jpg或.png
• 断言2：检查返回的文件大小字段 < 2MB
• 断言3：无法做——脚本不认识“有没有人脸”。需要单独集成人脸检测SDK，写几十行代码调用。
• 测试数据：手工准备多张不同格式、不同大小的图片，放git仓库里。

总代码量：约150行。维护成本：每次换人脸检测库都要改代码。

AI + Skill方案：

Agent收到需求，自动规划：

1. 调用“数据构造Skill”生成jpg、png、gif、txt、大于2MB的图片文件。用的是本地Faker+ImageMagick，几分钟生成几十个变体。
2. 对每张图片执行上传操作。
3. 调用“自动断言Skill”比较接口返回。规则：格式错误返回400，大小超限返回413，成功返回200且URL不为空。
4. 对于成功上传的图片，再调用“多模态识别Skill”判断图片内容是否包含人脸。输入是下载的图片，输出是人脸数量及置信度。
5. 汇总报告。

Agent写的总代码（调用Skill的胶水代码）不到30行。数据构造Skill和多模态识别Skill提前封装好，可复用。

对比结果：

• 开发速度：AI+Skill方案是传统脚本的1/5时间。
• 可维护性：换人脸检测库，只改多模态Skill内部实现，Agent和测试脚本完全无感。
• 覆盖率：传统脚本只测了3张图，AI+Skill方案测了20+种变体。

五、你现在就能动手封装的三个Skill

不用等公司平台。个人电脑上就能做。

推荐用MCP Python SDK（https://github.com/modelcontextprotocol/python-sdk）。

Skill 1：JSON断言器

输入：{"actual": {...}, "rules": {"ignore_fields": [...], "tolerance": 0.0001}}内部调用deepdiff。 输出：{"passed": true/false, "diff": {...}}

Skill 2：身份证号生成与校验

输入：{"birth_date": "1990-01-01", "sex": "M"}内部调用id_validator库计算校验位。 输出：合法的身份证号字符串。

Skill 3：截图元素定位

输入：{"screenshot_path": "/tmp/screen.png", "target_description": "登录按钮"}内部调用gpt-4-vision-preview（需API key）。 输出：{"found": true, "coordinates": [x,y,w,h]}

封装好之后，在Agent配置里注册MCP server。然后你就可以对Agent说：“帮我生成10个合法的身份证号，存到test_data.json里。”Agent会自动调用你的Skill。

可以截图传播的观点句3：封装Skill不是造轮子，是把你的领域知识变成AI可调用的API。

六、测试Skill会成为下一个“JUnit”

回忆一下JUnit出现之前。每个测试员自己写main函数跑用例，断言用if-else，结果打印到控制台。JUnit标准化了“测试结构”和“断言方式”，让整个行业能复用。

现在测试Skill在做类似的事。但维度更高——不是标准化代码结构，而是标准化“能力接口”。

预测未来三年：

第一，大厂会开源自己的测试Skill集。比如“支付场景数据构造”“智能风控断言库”。就像今天开源测试框架一样。

第二，Skill的评测会成为新方向。一个断言Skill好不好？不是看代码写得漂亮，而是看Agent调用它的准确率和效率。会涌现专门的Skill benchmark。

第三，测试工程师的技能树分叉。一条路是“Skill设计者”——懂业务、懂测试方法、能封装成标准化模块。另一条路是“Agent编排者”——会写调用Skill的智能体流程。两条路都比“写脚本”值钱。

最后一个问题，留给你：

如果你只能封装一个Skill来解决你当前最痛的点，你会选自动断言、数据构造还是多模态识别？它的输入和输出长什么样？