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

作者：袖梨 2026-07-17

PagePilot为PC端AI测试带来创新，通过组件化知识库与AI Agent结合，实现稳定高效的端到端测试。核心内容：1. PC端业务测试面临的三大核心挑战2. 从编写代码到积累知识的AI测试新思路3. 稳定、通用、轻量化的PagePilot解决方案设计

阿里妹导读

文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。

一、背景介绍

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

1.1 问题与挑战

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

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

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

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

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

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

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

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

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

1.2 AI时代下的思考

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

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

二、解决方案设计

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

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

2.1 方案演进：从使用平台到自建 Skill

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

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

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

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

痛点	具体问题
账号体系受限	不支持指定账号切换，审核通过分支每次必须换号，全流程 Case 无法自动执行
流程控制粒度不足	录制产出需大量手动修正；无法衔接 DB 验证、语雀归档等非浏览器环节，断链需人工补接
文件上传能力缺失	多处图片上传（营业执照、身份证、门头照）无法指定文件与校验
验证手段单一	无法获取接口响应和 trace_id，无法从 URL 提取业务单号串联 DB 验证，页面验证仍依赖人工
扩展受平台排期约束	qiankun fetch 隔离、非标组件、CDP 真实鼠标事件等均需等排期，无法自主解决

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

2.2 Skill 设计：框架选型

选型原则：能稳定执行。

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

问题	偏差	解法
React 受控组件	input.value = 'xxx' 赋值后 React 不感知，提交拿不到值	走 prototype.value setter + dispatchEvent 触发合成事件
图片上传	CDP 无法操作原生文件选择 dialog	绕过 dialog，用 DOM.setFileInputFiles 直塞文件路径
Cascader 异步加载	AI 倾向跳级选择，面板未展开就点击	逐级选 + 等待 500ms 下级菜单渲染
异构搜索组件	同一"搜索"功能三种实现（ant-select / .optionItem / input+button），定位策略不统一	DOM 预扫描判断组件体系，分别走对应交互路径
上传触发重渲染	上传多图后 radio/cascader 被清空	先上传、再选 radio/cascader、最后填 input，顺序与直觉相反
SPA 路由销毁拦截器	提交前注入的 fetch 拦截器被路由切换销毁，拿不到响应	每次 submit 前 0.5 秒内重注入，不等"之前装过就用"
按钮无响应	button.click() 和 dispatchEvent 均不响应	用 CDP 真实鼠标事件（mouse move → down → up）
页面崩溃表单丢失	CDP session 崩溃，已填表单全部丢失	window.__formState 表单快照 + 崩溃后重登恢复，上传放最后最小化崩溃暴露面

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

三、skill架构设计

3.1 架构图

3.2 核心设计

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

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

第 1 趟｜风格检测

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

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

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

序号	操作	参数
1	选择主营类目	本地生活-餐饮
2	填写经营类型	个体工商户

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

帮我执行 新增非标品牌 → 审核通过站点：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 组件，并给出"我有多确定"的评分。

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

置信度	匹配条件	说明
95%+	确命中触发词	术语完全匹配，如"选择主营类目"→ CategorySelector
80-89%	部分命中 + 语义	关键词部分匹配 + 语义推理
60-69%	纯语义推理	仅靠语义推断，无关键词支撑
<50%	猜测	几乎无依据，不建议执行

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

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

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

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

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

置信度区间	执行策略
90–100%	静默执行，不打扰用户
70–89%	展示摘要，需用户确认
50–69%	拒绝执行，要求修正 Case
<50%	提示无法解析，建议改写

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

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

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

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

优先级	目录	职责	举例
最高	local-components/	业务方本地自定义组件，覆盖平台默认行为	业务觉得平台的"类目选择"组件不够用，自己写了一个 category-selector.md，加了品牌绑定逻辑
其次	components/	平台级共享组件，所有业务通用	平台提供的标准 category-selector.md，只做了基础 Cascader 逐级展开
未命中	无匹配	标记 unmatched，提示用户新建	新业务"棋盘密云"有个"私域用户筛选"操作，目前两个目录都没有对应组件

核心逻辑：同名组件，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 都有前置通过条件，条件不满足就卡住不推进，输出原因然后停下来：

Phase	干什么	门控条件（准入证）	不满足会怎样
Phase 0	执行环境 precheck	ODC MCP 连通 + yuque CLI 可用 + allowlist 配好	ODC 不通不执行——连数据库都查不了，跑下去验证也没意义
Phase 1	浏览器自动化执行	登录成功 + 页面已到达	登录失败不填表——没登录进去，后面填表点按钮都是空操作
Phase 2	URL 提取 & ID 解析	从 URL/拦截器拿到 brandId 或 astoreId	无 ID 不查 DB——不知道查哪条记录，DB 查询无从下手
Phase 3	数据库查询	SQL 返回结果（至少 1 行）	SQL 无结果不比对——空结果比对什么？不是"比对失败"，是"没东西可比"
Phase 4	数据比对	比对完成，状态明确（PASS/FAIL/WARNING）	生成结论
Phase 5	生成报告	报告含截图 + 无敏感信息	报告无截图不归档——没有截图的报告无法回溯验证
Phase 6	归档到语雀	报告完整 + 图片已上传	归档成功

没有门控，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"，直接复用之前的结论。

四、业务实践 && 快速上手

4.1 优秀实践分享

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

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

波次	用例数	类型	通过率	发现 Bug
第一波	15 条	单轮问答	73.3%	发现 MCP 工具列表泄露 P0 漏洞
第二波	35 条	单轮问答	71.4%	发现"全公司"超范围查询未拦截
第三波	40 条	单轮问答	75.0%	发现"导出数据"能力边界未拦截
第四波	47 条 / 157 轮	多轮对话	89.2%	发现 64 个问题（3类大问题）响应慢，无响应、响应空

原先人工怎么测：测试同学手动在对话框一条条输入、等回复、判断结果、截图、记录。一条用例平均 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 双验证全过，自动截图 + 自动归档语雀 + 自动发钉钉通知。

4.2 其它业务实践案例

店铺-神券 + 支小店——最成熟的业务域，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）。