做前端的时间一长你会发现最烦人的往往不是写业务代码而是反复去“点”同一个后台页面。尤其是控制台类的管理系统菜单嵌套、权限点多、表单校验奇奇怪怪每次发版前我都要手动把核心流程点一遍点得人只想写个机器人替我上班。后来我把这套前端测试直接写成了一个 Skill在 AI 编程助手里挂一个自定义技能包然后我只需要输入一句话比如“从登录开始把所有用户管理的增删改查流程全部走一遍”AI 就会自己打开控制台顺着操作路径点击、输入、校验、截图把整个控制台点完最后给我一份带证据链的测试报告。这篇就聊聊我是怎么把这个 Skill 做出来的包括 Skill 和普通 Prompt 的区别、控制台测试的核心建模思路、落地步骤以及我实测中踩过的几个坑。1. 控制台这类页面的测试为什么这么折磨人1.1 控制台页面的特性状态多、链路长、权限杂控制台和普通官网页面完全是两种生物。官网页面基本是“展示型”打开就能看交互最多到表单提交。控制台则是“操作型”每个页面背后都是一串状态列表筛选、弹窗新建、编辑保存、批量删除、权限校验、操作日志每一步都依赖前一步的结果。最典型的就是用户管理你要测“新建用户”就得先准备角色、分配权限、再填账号信息测“编辑用户”又得先有一条已存在的用户数据测“删除用户”还要考虑当前用户是不是管理员、被删用户是否被其他业务引用。这些操作串起来是一条很长的链路任何一个环节的数据缺失、权限不足、接口异常都会导致后面全部跑不动。更麻烦的是权限矩阵。同一个控制台超级管理员看到的菜单和普通操作员看到的完全不同。有些按钮只有特定角色才显示有些接口只有特定 IP 段才允许访问。手工测试还能凭“经验”绕过去自动化脚本一旦写错判定条件就会在权限边界上反复横跳最后测出来的结果根本不能说明问题。1.2 传统自动化测试的“三个断层”我最早也试过用 Playwright、Cypress 这类工具写 E2E 脚本。刚开始觉得挺美好真正维护起来才发现有三个断层第一个断层是选择器不稳定。从开发者工具里复制出来的 CSS 路径页面改一次版就崩一次。控制台又是动态组件重灾区表格行会复用、弹窗会重渲染、按钮 ID 经常带一串随机数。你花一下午写好的几十个 selector可能因为前端加了一个 loading 状态就全部失效。第二个断层是数据状态不可控。测试脚本跑在最理想的数据假设上环境里恰好有一条叫“test_user”的数据、恰好没有脏数据挡住弹窗。但实际上控制台测试环境往往是共用的你上一条用例产生的数据可能就污染了下一条用例的判定。要解决就得做数据初始化、接口 Mock、数据库清理工作量比写脚本本身还大。第三个断层是断言成本高。前端页面大多是异步渲染你点完保存到底什么时候该断言“成功提示”sleep 3 秒太蠢等待某个接口返回又需要额外封装。更别说控制台里有大量表格、图表、状态流转断言逻辑写得稍微粗一点就会出现“测试全绿但功能实际上已经坏了”的假阳性。这三个断层叠加起来最终的结果就是自动化测试脚本变成了团队里的“摆设”平时不敢跑发版前才跑一次跑挂了也没人愿意去修。这不是工具的问题而是我们一直在用“固定路径脚本”去对抗“高度动态页面”路径一断整个测试就塌了。2. Skill 与传统 Prompt/脚本的根本区别2.1 Skill 是一套“可复用的任务能力包”很多朋友一听到“把前端测试写成 Skill”第一反应是这不就是写一个Prompt吗让 AI 去点击页面然后我再补一句“小心点别点错了”就行了。但真正的 Skill 不是一句话而是一整套结构化的技能包。你可以把它理解成给实习生一本工作手册而不是在口头交代任务。手册里写清楚了这个岗位负责什么、有哪些操作规范、遇到异常怎么处理、哪些事情绝对禁止。而 Prompt 只是你临时说的一句“帮我去把用户管理测一下”AI 可能理解成“用接口测”也可能理解成“用浏览器测”完全看运气。我用的这套 Skill 目录大概长这样skill-frontend-console-test/ ├── SKILL.md ├── commands/ │ ├── login.md │ ├── navigate.md │ └── assert.md ├── pages/ │ ├── login.md │ ├── user-list.md │ └── role-manage.md ├── workflows/ │ └── smoke-test.md └── examples/ └── user-crud.mdSKILL.md 是入口文件定义了技能的名称、用途、触发条件、操作边界commands 里是 AI 可以使用的原子动作比如登录、跳转、断言pages 里是控制台每个页面的关键元素和可用操作workflows 里是常用业务流程的串联方式examples 里放几个经典的执行样例。当 AI 加载这个 Skill 时它看到的不是散落的指令而是一个“完整的工作环境”。它知道自己在测试控制台知道每个页面长什么样知道每个流程应该按什么顺序走知道哪些按钮危险不能随便点。这才叫把前端测试写成了 Skill而不是写了个花哨的提示词。2.2 为什么一句话能驱动它为什么我只需要输入“从登录开始把用户管理流程走一遍”AI 就能自动跑完整条链路因为它读完 Skill 之后已经把这句话拆成了“登录→进入用户管理→新建→编辑→删除→退出登录”这样的任务列表然后从 pages 和 workflows 里找到了每一步对应的操作描述再调用 commands 里的原语去实际执行。这本质上是一个“意图识别 路径规划 原语执行”的过程。用户的一句话是意图Skill 里的 workflows 是路径commands 和 pages 是执行细节。没有 Skill 的时候AI 只能靠猜有了 SkillAI 是在“照章办事”。所以“一句话点完整个控制台”并不是魔法而是我把原本需要在测试文档里写几千字的操作步骤提前结构化地塞进了 Skill。AI 只是那个替我照着文档执行的人。2.3 和传统 E2E 脚本的本质区别为了说清楚这件事我列了一个对比表格你可以直观感受一下差异对比维度传统 E2E 脚本Skill 化的 AI 测试执行方式固定代码路径一步不能错意图驱动AI 自动规划路径页面变更手动改 selector 和流程代码改 pages/workflows 里的语义描述异常处理脚本遇到异常就退出AI 能读页面、截图、自纠错断言策略硬编码的 expect结合页面状态机和预期反馈动态校验维护成本每次需求变更都要改代码主要是补充语义描述和示例可解释性失败日志是堆栈输出带截图的完整操作理由传统脚本像是在铁轨上跑火车铁轨铺到哪火车就只能跑到哪。轨道一断火车就趴窝。Skill 化的 AI 测试更像一个会看地图的司机你告诉他目的地他自己找路、自己避坑、自己确认有没有到。我不否认传统 E2E 的价值但面对控制台这种高动态、多状态、长链路的场景传统脚本的维护成本实在太高了。Skill 的思路不是彻底取代脚本而是把“怎么写脚本”这个问题变成了“怎么描述页面和流程”而 AI 最擅长的恰恰就是理解描述。3. 把前端测试装进 Skill 的核心设计3.1 先给控制台画一张“操作地图”做 Skill 之前我做的第一件事不是写代码而是把控制台的每个页面都梳理成一张“操作地图”。这张地图不需要精确到 CSS 选择器但必须把语义信息写清楚这个页面有哪些功能按钮、每个按钮点了之后预期出现什么反馈、当前页面从哪里可以跳转到哪里。我以用户管理模块为例建了这样一张表页面可用动作关键元素预期反馈登录页输入账号密码、点击登录用户名输入框、密码输入框、登录按钮跳转首页右上角出现用户头像用户列表搜索、新建、行内编辑、删除搜索框、新建用户按钮、表格行、操作列列表刷新、弹窗打开、出现操作成功提示新建用户弹窗填写表单、保存、取消姓名输入框、手机号输入框、角色下拉框、保存按钮弹窗关闭列表出现新用户接口调用成功角色管理创建角色、分配权限角色名称输入框、权限树、保存按钮角色列表更新权限勾选被保存我把这些信息写进 pages 目录下的对应文件里。注意我没有用“#user-list .edit-btn”这种选择器而是写“用户列表行右侧的编辑按钮”。因为 AI 在处理这种语义描述时会比处理一串随机生成的 class 名稳定得多。这算是整份 Skill 能跑通的一个关键设计原则用人的语言描述页面而不是用机器的语言。3.2 把自然语言指令翻译成可执行动作有了操作地图接下来要定义一层“可执行动作原语”。这层原语相当于 AI 的手和脚每个动作都要有明确的输入、输出和失败条件。我在 Skill 的 commands 目录里定义了一组基础动作open(url)打开目标环境地址login(user, password)执行登录流程navigate(页面描述)通过菜单或路由跳转到指定页面click(元素描述)点击页面上某个语义元素fill(元素描述, 值)在输入框填入内容wait_until(状态描述)等待某个预期状态出现比如“表格加载完成”assert_visible(元素描述)断言某个元素可见assert_text(元素描述, 预期文本)断言某个元素包含预期文本screenshot(名称)给当前状态截图留证当 AI 接到“测试新建用户功能”这个指令时它会根据 workflows 文件里的定义生成类似下面这样的动作序列navigate(用户管理) wait_until(用户列表已加载) click(新建用户按钮) wait_until(新建用户弹窗已打开) fill(姓名输入框, test_user_01) fill(手机号输入框, 13800138000) click(保存按钮) assert_visible(操作成功提示) screenshot(新建用户完成)这些动作看起来很像传统测试脚本但区别在于每一个动作里的“元素描述”都是语义化的。AI 会在执行时自己去页面上寻找匹配的按钮、输入框、弹窗而不是依赖一个写死的 selector。所以哪怕前端微调了布局只要文案和层级没有大变这个序列大概率还是能跑通。3.3 测试断言与 UI 状态机的结合控制台测试最容易忽略的一点是页面是有状态的断言必须跟着状态走。我用了一个很朴素的状态机思路每个页面定义“前置状态”和“后置状态”。点击“保存”之前表单处于“可编辑状态”点击保存之后预期状态应该是“弹窗关闭、列表刷新、出现成功提示”。AI 每执行完一个动作都要用wait_until和assert_visible去校验状态是否如期迁移。如果状态没有迁移比如点击保存后弹窗没关、列表没刷新AI 就要启动“自我修正”流程先截图、读取当前页面文本、对比预期再决定是重试一次还是调整操作。这一步是整个 Skill 里最重要的设计。因为没有断言的“点完”只是走马观花只有把状态校验也包进去测试才算真正有说服力。4. 从零到一落地这个 Skill 的关键步骤4.1 搭建 Skill 骨架定义边界和授权任何 AI 编程助手里的 Skill第一步都是把目录结构和入口文件搭起来。别急着写 pages 和 workflows先把“这个技能能干什么、不能干什么”说清楚。我在 SKILL.md 开头写了这样一段元信息--- name: frontend-console-test description: 用于Web控制台的前端自动化测试根据自然语言指令执行点击流程并输出报告 allowed_operations: [open, navigate, click, fill, wait_until, assert, screenshot] forbidden_operations: [delete_without_confirm, export_without_confirm] ---这段信息的作用是给 AI 一个“行为红线”。控制台里有很多高危操作删除数据、批量导出、修改权限这些动作一旦误触代价非常大。所以我明确告诉 AI删除和导出这类操作如果没有在指令里显式说明并且经过我的二次确认一律禁止执行。各家 AI 助手的 Skill 格式可能会有一点差别但核心思想是通用的你给出的边界越清楚AI 就越不会自作主张。很多人在这个环节偷懒结果后面 AI “发挥想象力”点了一堆不该点的按钮这不是 AI 的错是你没教好。4.2 在真实控制台上跑通第一个用例骨架搭好之后我没有急着写全量页面而是先挑最简单的“登录→进入用户管理→退出”跑通。这个过程其实是一场“调教”我打开真实控制台让 AI 开始执行。我输入“登录测试账号进入用户管理截图当前页面”。然后盯着 AI 的行为序列看注意它是不是先打开了地址、再填账号密码、点击登录、等待跳转最后才截图。如果 AI 点了错误的按钮或者跳过了等待步骤我不会直接说“重新来一次”而是回到 pages 文件里修正对应的语义描述。比如它总是找不到“登录按钮”我就把元素描述改得更具体一点“登录按钮是页面右下角蓝色的圆角按钮”。重复几轮之后AI 的行为会越来越稳定这就是让 Skill 真正学会“你的控制台长什么样”的过程。4.3 从单条指令扩展到全控制台巡检第一个用例跑通后后面的扩展其实就是复制粘贴加调整。我把日常手工测试的高频流程全部写成了 workflows用户管理、角色权限、订单审批、数据导入、配置发布每个流程链都包括前置条件、操作步骤、预期结果和后置清理。然后我再定义了一个复合任务叫“全控制台巡检”依次执行所有 workflows每个流程结束都截图并记录结果。这样我每天早上只需要对 AI 说一句“执行全控制台巡检”它就会自己跑完所有核心链路再输出一份 Markdown 报告里面包含每个流程的通过/失败状态、关键操作截图、失败原因分析。实测下来一次巡检大概能覆盖我平时手动测试 40 分钟的内容AI 最快五分钟内就能跑完。当然个别流程因为数据准备原因偶尔会失败但 AI 会把失败原因写得明明白白我只需要看报告决定是修脚本还是修数据。5. 跑通之后我踩过的那些坑5.1 选择器不是唯一解语义、角色、坐标最开始我犯了一个非常经典的错误为了让 AI 定位准确我在 pages 里塞了大量 CSS 选择器。结果页面一改版选择器失效AI 直接抓瞎。后来我改成“语义定位优先”优先用页面上可见的按钮文字、菜单名称、表单 label 来定位。比如“点击用户列表右侧操作列的编辑按钮”而不是“点击 #edit-3”。你会发现 AI 对这种描述的理解能力远超预期因为它在处理时不只是读 DOM还会结合可访问性树和视觉信息。如果元素没有清晰的文字标签那就给它加一个语义别名。比如“保存按钮”可能页面上有多个我会写成“新建用户弹窗右下角的保存按钮”。用坐标定位是最不得已的方案我几乎不用因为控制台是响应式布局坐标在不同视口下完全不一样。5.2 AI 操作过快导致状态不同步第二个坑是 AI 的手速太快了。它刚点完“进入用户管理”下一秒就要去点“新建用户按钮”但这时候表格还在加载按钮还没渲染出来结果就扑了个空。解决方案不是加 sleep而是在 Skill 里强制约定每个动作执行完之后必须先wait_until等预期状态出现再执行下一步。等什么等接口返回后页面出现的确定信号比如“用户列表已加载”或“弹窗已打开”。这个约定看起来让流程变慢了但换来的是整体成功率的大幅提升。我还给 AI 加了“单步确认”模式。最开始调试 Skill 时每一步都会输出当前操作和当前页面状态方便我看它有没有按预期走。跑稳定之后再关掉确认让它自动连续执行。5.3 断言失败时让 AI 自己“纠错”第一版 Skill 遇到断言失败就直接停。后来我加了一个“自纠错循环”断言失败之后AI 先截图并读取当前页面文本把“预期”和“实际”做一个对比然后分两种情况处理。如果是页面元素描述过时了它就去更新 pages 里的语义描述然后重新执行这一步。比如我写过“保存成功提示”但前端后来改成了“操作成功”断言失败后 AI 发现文案变了会把这个文案更新为两种都可接受并在最终报告里标注“页面文案发生变更”。如果是真正的功能 BugAI 会把这个失败原样记录到报告里标红不会擅自修改断言去“掩盖问题”。这个机制非常关键因为它的本质是让测试脚本自己进化而不是每次前端一改版就需要人工去维护断言。5.4 权限与安全边界是必须提前设好的我刚做完 Skill 的时候很兴奋有一次让 AI“把控制台所有按钮点一遍”结果它真的差点去执行一个生产环境的数据清理任务。虽然我的 Skill 前缀带了forbidden_operations但那次我用的指令是“所有按钮”绕过了具体限制。这件事之后我把安全逻辑做了两层加固第一层Skill 只允许在指定测试域名下工作非测试环境直接拒绝执行第二层凡是涉及删除、导出、修改权限这类高危动作AI 必须先暂停并问我“是否确认执行”我不确认就不动。永远不要假设 AI 有“常识”。在 Skill 里把边界写到足够死才是负责任的用法。控制台测试的终极目标不是让 AI 替我乱点而是让 AI 在一个受控的范围内帮我做重复劳动。6. 这个 Skill 带来的延伸价值和个人体会做完这个 Skill 之后我发现它最大的收获其实不是“省了几个小时手点”而是让我重新理解了前端测试这件事。以前写测试用例最后沉淀下来的是几百行代码和一群没人看的文档。现在这些知识全部变成 Skill 里的语义描述和 workflow每次页面改版我更新 pages 文件的过程本质上就是在整理“当前控制台到底长什么样”。这份活文档对团队新人也特别友好新同学想了解控制台的核心流程不用再看几十页 case直接让 AI 跑一遍巡检再看报告就能理解七七八八。另外AI 在点击过程中还会“顺便”发现一些可访问性问题。比如某个按钮没有可访问性标签AI 定位时会犹豫很久某个页面打开后焦点没有落在预期位置AI 会把它记成一条体验问题。这些都是以前写自动化测试脚本时根本不会留意到的细节但恰恰是控制台这类后台系统日常最容易忽略的质量问题。如果让我重新做一次我会更早放弃“写死脚本”的执念直接从语义描述和状态机入手。给 AI 一本好的工作手册比教它一万句临场指令管用得多。而且别指望第一天就能“一句话点完全部”先把最高频的一条流程做到百分百稳定再一点点把整个控制台装进 Skill 里。这个不断沉淀的过程才是这类 AI 测试方案真正值得投入的地方。