PagePilot — PC端AI测试Skill设计与实战

支付宝商家中心(b.alipay.com)是支付宝官方的商家服务平台,面向蚂蚁生态内所有商家,聚合产品签约、账户资金管理、营销运营、账单对账等能力,为商家提供一站式综合服务,帮助其更高效地开展日常经营，我们团队负责该平台的 PC 端业务测试。

挑战1：基本都是面向B端和小二端，PC端业务多，测试链路长：

以支付宝商家中心核心业务为例，店铺开通、商户入驻每一条都是跨系统、多步骤的长链路：

• 店铺开通：登录 → 选类目 → 选经营类型 → 设置结算 → 上传资质 → 勾协议 → 提交 → 产品签约 → DB验证，一个case 15+步

• 商户入驻：营业执照OCR → 经营场景 → 法人身份证 → 人脸核验 → 邮箱绑定 → 密码设置 → 签约，20+步

挑战2：以前的PC测试，不管是人工测试还是人工编写自动化脚本，都需要极高的人工投入成本

由于商家的业务特点是步骤多、弹窗多、上传多、异步等待多、SPA路由复杂。传统自动化写case维护成本极高，React受控组件、qiankun微前端fetch隔离、弹窗内状态被上传重置，每个都是坑。踩一个坑写一段workaround，换个业务场景又从头开始。再加上公司内除商开部门外，其它对PC自动化依赖不高，也使得自动化平台存在功能扩展慢（qiankun微前端、非标组件不支持）、录制调整成本高、部分功能不支持等问题。

在自动化ROI比较低的情况下，商开部门的大量外包总是需要花费大量时间去执行前端页面点点点的验证，事情繁琐，人力成本仍然极高。

挑战3：PC端线上问题风险高，在前端正式研发人员不断缩减的过程中，风险进一步放大。

PC端是商家的主入口，在近几年内先后出现过：由于组件升级导致某商家子页面不可用/提交报错等阻断性问题，由于前端代码冲突导致某个关键字段没有提交至服务端带来重大线上问题。并且由于前端监控覆盖率的缺失，以及前后端核对难以布防等痛点，使很多前端线上问题的影响面不断放大最终导致客诉。

核心思路转变：不写测试代码，写测试知识。把踩过的坑、验证过的交互代码、有效的DOM选择器封装成"组件md"，AI执行时查阅对应组件直接复用，每一次执行都在让组件库更完善，稳定性随知识积累递增。

核心公式：AI Agent + 组件化知识库 + 浏览器自动化 + DB验证 = 端到端AI测试

关键词：稳定·通用·轻量

稳定执行不出错，一套方案通多业务，开箱即用成本低。AI 替你跑浏览器、填表单、查 DB、分析trace、出报告、发钉钉，验收一条龙。

初期选用店铺业务作为试点，先后尝试了平台提供的两类 AI 测试能力。

• 自然语言驱动：模型对自然语言理解不稳定，导致 Case 编排出现偏差；执行下游存在资源瓶颈，单 Case 执行成功率低；前置步骤繁琐，需先配置空间测试账号、选择登录方式和执行账号。尤其店铺场景存在账号独占性（一个账号只能开通一个店铺），审核通过后该账号即不可复用，每次执行需重新配置账号，流程沉重。

• 智能测试流：平台作为解决自然语言理解不稳定问题的推荐方案，但实际落地后，录制本身有成本，录制后仍需手动调整 Case 编排；后置执行也并不能解决业务问题

实践过程中，平台方案在商家侧场景中暴露出明显短板：

结论：平台方案在通用场景具备一定价值，但在多步骤、强状态、深交互的业务场景中，执行稳定性、维护成本与适配性尚存差距。经一个月持续协作，店铺场景核心能力仍在推进中，暂未跑通完整链路。为更快支撑 AI 测试转型，决定同步探索自建 Skill 方案。

选型原则：能稳定执行。

Browser Agent 相比 Playwright 的核心差异是在 CDP 之上引入了大模型推理层，能理解自然语言意图、自主定位元素并生成操作序列，省去预编写选择器脚本。简单页面导航和基础表单，它能精准理解步骤描述、准确定位交互位置。但在商家侧的复杂组件上，通用推理难以覆盖边界情况，执行出现大量偏差：

这些问题的共性是同类交互的底层实现因框架、组件库、业务场景而异，我们靠组件知识逐一沉淀。每遇到一个偏差，就把正确的交互方式写入组件 md 的踩坑段，下次直接复用而非重新推理。踩坑段只增不删，即使 bug 已修复也保留记录，避免同类问题换一种表现形式再次出现。不同业务场景持续喂入、持续校正、持续沉淀。随机出错率从首轮 40% 降到 4 轮后 5% 以下，靠的就是踩坑段的积累效果。它不是一次写对的，是在业务锤炼中变聪明的。

1. Case 解析：四趟编译——把人话变成机器能跑的指令

用户写 Case 用自然语言，但 AI 不能直接拿着自然语言操作浏览器。于是设计了一个四趟编译管线，把人话逐步"翻译"成可执行内部指令，每一趟只做一件事、只承担一个职责，既保证解析精度，也让错误能被早发现、早拦截。

第 1 趟｜风格检测

职责：识别 Case 写法，用户不需要声明格式。

用户可能用三种风格写 Case：AI 自动识别风格，用户无需指定，降低使用门槛的第一步。

表格风格（推荐，最易解析）：

自然语言风格："主营类目选本地生活-餐饮" （最常见、最灵活）

帮我执行 新增非标品牌 → 审核通过站点：B站预发 https://b.alipay.com/page/brandManage/home账号密码：**** / ***数据库：数据库ARN:*****商户载体ID(carrierId)：******审核工具：brand-audit skill操作步骤：登录B站，进入品牌管理首页点击【添加品牌】→ 跳转 /page/brandManage/home/brandReport添加方式：选择【新增品牌】品牌材料：选择【非标品牌】品牌名称：输入「测试+当前时间戳」点击「补充更多品牌信息」，品牌logo：上传reference里的图片品牌故事：输入「这个是一个品牌故事」品牌类目：选择 电商平台 → 工厂优选平台门头店招：上传reference里的图片勾选同意《支付宝品牌商服务协议》点击【确定】→ 跳转 /page/brandManage/home/confirmResult，提示"已提交，预计1-2个工作日完成审核"审核（brand-audit skill）：从提交结果页获取brandId调用 brand-audit，action=pass，eventCode=****_AUDIT等待10s预期结果：提交后跳转确认页，文案含"已提交"回到首页，已认领列表可见该品牌，状态为"审核通过"/"可使用"DB校验：SQL-- 品牌主表：status=1（已通过），source=MRCH，owner_name=**测试的公司SELECT * FROM **** WHERE brand_chs_name = '{brandName}' ORDER BY gmt_create DESC LIMIT 1;-- 审批流水：approval_type=1，status=3（审核通过）SELECT * FROM **** WHERE brand_id = '{brandId}' ORDER BY id DESC LIMIT 1;

清单风格：- [ ] 主营类目选择本地生活 （Markdown)

第 2 趟｜元数据抽取

职责：提取非操作步骤的结构化上下文，为执行准备"弹药"。

这些不是操作步骤，而是执行前必须知道的"环境参数"：

• 账号密码：登录需要

• 入口 URL：从哪里开始

• DB ARN：验证需要查哪张表

• 期望断言：如 biz_status = BLOCK_WAIT

• 钉钉群号：结果通知发到哪里

元数据与操作步骤分离，保证步骤序列干净，也保证执行阶段不会因为缺了密码而卡住。

第 3 趟｜组件匹配 + 置信度评分

职责：把每一步操作匹配到对应的 UI 组件，并给出"我有多确定"的评分。

这是四趟编译的核心环节——也是最容易出错的地方。评分规则：

未匹配到的步骤标记为 unmatched，同时建议可能需要新建的组件——既暴露问题，也给出建设性方向。

第 4 趟｜输出可执行的任务step列表

职责：合并前三趟结果，输出 AI 能逐步执行的内部格式。

最终产物是一个 steps 列表，每步绑定组件和参数。同时自动注入：trace-collector 作为第 0 步——用户不需要写"采集 trace"，系统默认带上，保证可观测性。

置信度门控，可多问一句，不让 AI 猜错一步，置信度评分不是"参考值"，它是门控阈值，直接决定执行策略：

核心思想：一条 Case 15 步操作，第 3 步猜错的代价是后面 12 步全白跑——宁可多问一句，不让 AI 猜错一步。

这不是保守，是工程上的止损逻辑：在不确定的环节停下来让人类拍板，比让机器蒙头冲完再发现全错，成本要低得多。

2. 组件查找优先链--平台兜底，业务按需覆盖

第 3 趟组件匹配时，AI 不是只在一个地方找组件，而是按优先级依次查找三层目录：

核心逻辑：同名组件，local-components/ 胜出，业务方可以局部覆盖平台行为，而不需要修改平台源码。

类比 CSS 的层叠规则：局部样式覆盖全局样式。业务方不需要向平台提排期等排期，自己写一个 .md 放进 local-components/ 就能生效。

实际使用场景：

• 覆盖：支小店的页面结构跟 B 站完全不同，同一个"登录"操作需要走不同的 DOM 路径 → 支小店在 local-components/ 放自己的 login.md，覆盖平台的 login.md
  

• 扩展：店铺开通的"结算设置"需要额外做支付宝账号校验 → 在 local-components/ 写一个 settle-modal.md，比平台版多一步校验
  

• 新增：棋盘密云的"私域用户筛选"两个目录都没有 → unmatched，提示用户新建，下次就不再 unmatched 了

一句话总结：平台提供通用能力兜底，业务方按需局部定制覆盖，覆盖不了的新增。三层优先链保证了扩展性和可控性的平衡。

3. 脚本优于 eval 纪律

组件层（components/）写的是知识——"这个组件怎么交互、有什么坑"。但 AI 每次执行时如果自己拼 agent-browser eval 命令，拼出来的代码不稳定，容易出错。脚本层把验证过的操作固化成 .sh 文件。组件说"有脚本调脚本，禁手动拼 eval"，确保每次走的是同一条经过实战的代码路径。

4. Phase 0→6 门控

整个执行流程是 7 个阶段串联，但不是"无脑顺序往下跑"——每个 Phase 都有前置通过条件，条件不满足就卡住不推进，输出原因然后停下来：  

没有门控，AI 一路往下跑，登录失败了还在"填表"，填完表发现页面没变，又去查 DB，查到空结果还硬比，最后生成一个全是 FAIL 的报告归档到语雀——浪费了 15 分钟跑了一条从头就错的 Case，浪费了 token，浪费了 context，产出的报告毫无价值。

• 置信度门控解决的是：AI 可能在猜 → 不确定时停下来让人类确认

• Phase 门控解决的是：前置条件可能不成立 → 条件不足时停下来不白跑

两者同源：宁可早停报告原因，不让错误往下传播放大。 一条 Case 15 步操作 + 7 个 Phase，如果在 Phase 1 就发现登录失败，后面 6 个 Phase 全免——省下来的不是时间，是整条链路的无效执行成本。

一句话总结：每个 Phase 是一道关卡，关卡不放行，后面的路不许走。不是"跑完看结果"，是"跑前先验路"。

5. 失败自学习

Case 失败 → 按 errorCode 匹配 known-failures → 命中则标注模式 ID → 未命中则自动补录新模式，只增不删。

假设场景你跑了一条 Case，提交后返回错误码 THIRD_SYSTEM_ERROR，Case 失败了。第一次遇到这个错误Skill 去 known-failures.md 里搜 THIRD_SYSTEM_ERROR，没找到——这是第一次遇到。于是自动往文件里追加一条新记录：  F-017  状态: 活跃  首次发现: 2026-06-22  最近发现: 2026-06-22  出现次数: 1  errorCode: THIRD_SYSTEM_ERROR  失败特征: 提交店铺开通时下游三方系统异常  根因: 待补充  owner: 待分配  建议: 重试即可，非本系统问题 这就是"未命中则自动补录"——第一次见，记录下来。第二次遇到同一个错误又跑了一条 Case，同样的 THIRD_SYSTEM_ERROR。这次去 known-failures.md 里搜，命中了 F-017。报告里直接写：失败模式 F-017（THIRD_SYSTEM_ERROR），建议：重试即可，非本系统问题不用再人工诊断——"命中则标注模式 ID"，直接复用之前的结论。

案例 1：蚂蚁答疑助手评测—4 波 137 条用例 AI 自动评测，发现 64 个 Bug

百晓蚂蚁答疑助手是AI驱动业务智答运营平台。一站式解答商家、商品、交易、营销技术和运营问题，需要验证多轮对话能力。评测方用 Skill 执行了 4 波自动化评测：

原先人工怎么测：测试同学手动在对话框一条条输入、等回复、判断结果、截图、记录。一条用例平均 5分钟，多轮用例更长。4 波 137 条，人工约需2天（含截图整理和报告写作）。

AI 自动执行：Skill 按用例脚本自动输入、等回复、抽取响应内容、判定 OK/FAIL、截图归档。4 波合计约 3 小时完成（含等待 Agent 响应时间和截图整理），节省 70% 人力。

发现问题：4 波累计发现 10 类Bug

P0 级 2 个：MCP 工具列表泄露 + 接受"生成周报"超能力请求

P1 级 4 个：导出未拦截/超范围未拦截/Agent 执行报错/能力边界未拦截

P2 级 4 个：第四波多轮评测额外发现 64 个问题（无响应 17 次、响应超慢 29 次、上下文丢失 4 次、回复为空 14 次）。

案例 2：支付宝卡券频道-店铺开通——7 条 Case 30分钟跑完，人工需半天-1天

店铺开通是商家侧最复杂的长链路：每条 Case 15 步表单填写 + 文件上传，涉及 账号切换（B站/P站/支小店不同账号），结算信息填写，类目资质等重要材料上传，每步需要等页面渲染、等接口返回、截图留证。

原先人工：一条 Case 手动操作约 30分钟（含等页面渲染、填表、上传、截图），7 条需要半天-1天

Skill 自动执行：7 条 Case 在 30 分钟内全部跑完，提交+撤销 DB 双验证全过，自动截图 + 自动归档语雀 + 自动发钉钉通知。

店铺-神券 + 支小店——最成熟的业务域，7 Case 全流程冷启动验证

店铺开通是商家侧最复杂的长链路：15 步表单填写 + 文件上传 + 异步等待 + SPA 路由切换。Skill 覆盖了 B 站自开通（独立门店/品牌连锁/mall 店）、P 站代开通（独立/品牌）、支小店（官方旗舰店/普通企业店）共 7 条 Case，提交+撤销 DB 双验证全部 PASS，最长一条 236 秒完成。

企业商户入驻——跨 iframe + 人脸验证 + 邮箱验证码

商户入驻 20+ 步，是目前人工介入最密集的 Case：iframe 内嵌开户验证页面（必须直接打开 iframe src 操作）、人脸验证扫码等待（session 5-10 分钟过期需重新登录）、邮箱验证码（必须先点发送按钮再填码），Skill 跑通了 97+50 老页面全流程。

品牌管理（B站）——12 Case 全量覆盖，通过率 100%

首次做全量用例覆盖而非只跑关键 Case，12 条从非标/标准品牌新增、审核通过/驳回、认证、认领、搜索筛选、品牌资产（门店/收款账号/小程序/会员卡/设备）到修改品牌、驳回重申请、首页冒烟，11/11 PASS。

品牌管理（P站）——跨 Skill 联合验证，发现前端 Bug

P站与 B 站共用组件体系但域名和交互细节不同。Skill 首次实现 UI 自动化 + 品牌审核 skill HTTP 审核的跨 Skill 联合验证——AI 提交品牌后自动调用 brand-audit skill 完成审核，再回到 UI 验证结果。7/12 PASS，3 条 BLOCKED 发现了 P站前端 Bug（品牌资产面板 API 绑定错误 brandId）。

数商域客户管理——非标准登录体系 + 表单动态联动

数商域用非标准登录体系三段登录（输密码→选账号→点登录）。行业字段有动态联动：选"自助餐"触发额外必填字段，选"日化家清"则不会，AI 需动态对比表单差异才能正确填写。品牌选择弹"已被其他客户挂载" Modal，点取消会清空品牌——必须点确定继续挂载。

跨域扩展——万知管理平台 + **订单管理页面**安全越权 + 蚂蚁答疑助手助手

Skill 的组件库不止服务商家平台侧，已被三个跨域团队复用：

• 万知管理平台：100 条 Monkey 测试（导航/搜索/弹窗/表格），100% PASS，15 分钟完成。首次适配 Tailwind CSS（非 Ant Design）组件体系

• 订单管理页面安全越权校验：两个账号交叉走"有权限 UI 正路 + 无权限接口攻击"双路径验证，4/4 PASS

• 蚂蚁答疑助手评测：90 条三波评测，口径查询 93%、数据资产查询 100%，发现 MCP 工具泄露 P0 级漏洞

42 个组件 md + 34 个脚本，分 5 类覆盖商家侧 90% 高频操作：

• 基础能力 9 个：登录（authsa128/pubbuservice 双体系）、入口校验、Trace 采集、崩溃恢复、钉钉通知、ODC precheck

• React/Ant Design 通用 7 个：表单填写（React setter）、Select（虚拟列表滚动）、Cascader（逐级+异步）、Modal、DatePicker、Form 定位、高德地图

• 上传/CDP 5 个：fiber 注入上传、多图批量上传、CDP 真实鼠标事件、资质/品牌 logo 上传

• 业务专属 14+ 个：主营类目、经营类型、品牌搜索、结算弹窗、门店地址、经营/认证信息段、提交拦截、撤销审核、P站客户、商标、支小店组件组

• 流程归档 7+ 个：语雀报告归档、DB 查询、钉钉模板、报告三段式、失败模式库、安全清单、经验沉淀

前置依赖

执行 Case

①建议先加载skill，避免模型幻觉未使用skill执行

② 执行case

查看结果