最近在团队里做了一次技能盘点。
问了一圈：你们用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条数据。而是：
Agent根据字段描述，生成一条候选数据。
调用数据校验Skill，检查合法性（手机号格式、身份证校验位、业务关联约束）。
校验不通过，把错误信息喂回Agent：“手机号段130开头已停用，请用150段”。
Agent修正，重新生成。循环直到通过。
通过后加入结果集，继续下一条。
核心机制是“反馈闭环”。AI负责试，校验器负责把关。试错成本很低，因为生成是廉价的。
解决了什么问题？解决了“AI瞎编”的问题。不让AI一次搞定，让它迭代逼近正确答案。同时，合规数据可以被缓存成模板，下次直接复用。
多模态识别Skill：视觉定位 + 语义理解
UI自动化最大的坑是元素定位。xpath依赖DOM结构，小程序和原生应用根本拿不到。
多模态Skill换了一条路。怎么做的？
输入：截图 + 目标描述（“红色的提交按钮”）。 流程：
截图传给视觉大模型（GPT-4V或专用模型）。
模型返回目标元素的边界框坐标（x,y,width,height）。
Skill调用本地点击工具，在坐标处执行点击。
如果需要断言按钮状态，再次截图传模型问“按钮是否是置灰状态”。
为什么不直接用传统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收到需求，自动规划：
调用“数据构造Skill”生成jpg、png、gif、txt、大于2MB的图片文件。用的是本地Faker+ImageMagick，几分钟生成几十个变体。
对每张图片执行上传操作。
调用“自动断言Skill”比较接口返回。规则：格式错误返回400，大小超限返回413，成功返回200且URL不为空。
对于成功上传的图片，再调用“多模态识别Skill”判断图片内容是否包含人脸。输入是下载的图片，输出是人脸数量及置信度。
汇总报告。
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来解决你当前最痛的点，你会选自动断言、数据构造还是多模态识别？它的输入和输出长什么样？
