尧图网站建设 
实不相瞒我自己最早做 Agent 测试助手的时候也干过“一把梭”的事把需求解析、用例设计、脚本生成、执行调度、报告输出全塞进一个 Skill 里。Prompt 写到三千字看起来无所不能真正跑起来处处碰壁。后来痛定思痛把整套能力拆成了 5 个垂直 Skill串成一条从“UI 自动化执行”到“报告生成”的流水线才算是把 AI 测试提效这件事真正落地了。这篇文章就围绕这个思路展开为什么我强烈建议“别搞万能 Skill”5 个 Skill 各自怎么设计、边界画在哪、参数怎么配、坑在哪里以及它们在一次真实回归测试里是怎么串联起来的。如果你正在用 Agent 做 UI 自动化测试或者正准备拿 AI 提效测试流程这篇文章应该能给你一套拿来就能用的方案。1. 为什么“别搞万能 Skill”一次踩坑后的思路转变1.1 万能 Skill 的典型症状我最早做的“万能测试助手”把所有测试能力塞进一个 Skill 里Prompt 里既有用例分析方法论又有脚本编写规范还有报告模板说明。表面上看功能很全实际用起来问题一个接一个。最典型的症状是上下文窗口被严重浪费。每次调用这个 Skill 时系统都要把三千字的 Prompt 加上历史对话一起塞给模型。轮到真正执行任务时可用上下文已经少了一大截复杂项目里经常出现“前半段记得需求后半段忘了格式”的情况。更难受的是角色混乱。同一个 Skill 里模型有时候把自己当测试分析师输出用例写得头头是道等下一轮让它写脚本时它又把断言规则和报告模板混在一起生成的代码里全是跑不通的“缝合怪”。改 A 坏 B 是家常便饭调试一次往往要花比手写脚本更长的时间。这种“样样通、样样松”的体验其实触及了一个核心问题Agent Skill 不是一个“百科全书”而是一个“岗位角色”。你让一个人同时做需求分析师、脚本工程师、执行调度员、故障诊断专家、报告编辑他一定会手忙脚乱。正确的做法是把岗位拆开让每个角色专注一件事。1.2 “小步快跑”的垂直分解思路后来我换了个思路不再追求一个大而全的 Skill而是把测试流程拆成 5 个职责单一、输入输出明确的垂直 Skill。每个 Skill 只做一件事但把这件事做到位。这样做有几个立竿见影的好处。第一Prompt 对上下文窗口的压力指数级下降模型能够把全部精力放在当前环节第二每个 Skill 可以独立调试、独立测试出问题的时候你很清楚该改哪里第三Skill 之间通过明确的输入输出衔接可以灵活替换比如今天用 A 家的脚本生成模型明天换成 B 家的只改一个模块就行。我拿这个思路跟团队里的同事聊有人问“拆成 5 个 Skill 是不是太重了直接写一个工作流脚本里面 call 不同的函数不就行了”我的回答是如果每个环节的职责很简单纯函数调用确实够了但测试这个场景里需求理解、脚本生成、失败诊断的节点都涉及“生成式判断”不是固定逻辑能覆盖的。把这些判断逻辑放进带 Prompt 的 Skill 里再交给 Agent 编排才有足够的灵活度去处理真实世界的各种异常情况。打个比方。一条手工流水线上你不会让一个工人既负责切菜又负责掌勺又负责摆盘。AI 测试也一样把复杂任务切分成有边界的子任务每个子任务用专门的 Skill 处理整体效率和稳定性都会好很多。这也是我认为“万能 Skill”这条路从一开始就走歪的原因。2. 五个 Skill 的整体设计与拆解2.1 从需求到报告的完整流水线先说整体流程方便大家有个全局印象。整套流水线的输入是一段需求描述或者产品需求文档链接、页面截图输出是一份可以直接分享给团队的测试报告。中间经过 5 个 Skill分别是Skill 名称核心职责主要输入主要输出RequirementSkill需求解析、场景梳理、用例生成需求描述、PRD 链接、页面截图测试场景列表、测试用例、优先级、断言建议ScriptSkill测试脚本的生成、录制转换与修复建议测试用例、页面 DOM 结构、录制数据可直接运行的自动化测试脚本ExecSkill执行调度、环境配置、结果采集测试脚本、运行环境、测试素材执行结果、日志、截图、视频DiagnoserSkill失败原因分析与修复建议截图、日志、网络请求、断言数据失败原因分类、置信度、修复建议ReporterSkill数据聚合、报告生成、要点提炼各 Skill 输出、执行结果汇总结构化测试报告Markdown/HTML为了让大家好记我习惯把这 5 个 Skill 叫成“需求拆解—脚本生成—执行调度—失败诊断—报告输出”。它们之间有一条默认数据流同时也有条件分支只有执行结果异常时才会触发 DiagnoserSkillDiagnoserSkill 的修复建议会回传给 ScriptSkill 做脚本修复形成一个闭环。2.2 为什么是这 5 个边界划分逻辑有人可能会问为什么不是 3 个也不是 7 个这个数量其实是跟着“决策点”走的。需求拆解和脚本生成必须分开是因为“理解业务”和“写工程代码”是两种完全不同的模型能力。如果你让模型在同一个 Prompt 里既做业务分析又写 Selenium 代码它往往会在写断言时忘了业务语义或者在分析场景时过度设计技术方案。分开之后RequirementSkill 可以专注生成“能立案”的测试用例ScriptSkill 只需要照着用例翻译成代码互不干扰。ScriptSkill 和 ExecSkill 分开则是出于“稳定运行”的考虑。脚本生成属于“生成”任务重在格式正确执行调度属于“运维”任务重在环境配置、超时控制、重试策略。把这两者混在一起模型在排障时容易被环境变量带偏。实际工作中环境问题占了 UI 自动化失败原因的一半以上把执行单独拆出来做精细控制收益非常直接。DiagnoserSkill 和 ReporterSkill 的存在则是因为失败诊断和报告生成是“最容易出彩也最容易被忽视”的环节。很多团队把自动化跑完就完事了结果一大堆失败用例堆在那儿没人看。有了专岗 Skill 之后失败原因有人分析报告有人提炼整个流程的价值才能真正体现出来。3. 五个 Skill 的核心细节与实操要点3.1 RequirementSkill用例拆解怎么做到“能立案”RequirementSkill 是整个流水线的第一棒。它的输入通常是一段产品需求描述有时候还会附带 PRD 链接、原型图、历史缺陷记录。输出是结构化的测试场景和用例。我在实践里要求 RequirementSkill 必须遵循“先场景、后用例、再断言”的三段式产出。第一步先列出从需求中可以推导出的测试场景包括主流程、边界场景、异常场景和兼容性场景。第二步才是把每个场景细化成用例每个用例必须有前置条件、操作步骤、预期结果和优先级。第三步补充断言建议这步特别重要因为后续 ScriptSkill 写代码时依赖的就是断言建议。这里有一个很关键的实践细节你必须给 RequirementSkill 提供“需求上下文”而不是“一句话需求”。我通常会让它先阅读 PRD 链接或需求文档再要求它提出“需求不明确点”。如果它列出的疑问超过 3 个我会要求它先不要生成用例先向用户澄清需求。这个设计看起来多了一道交流实际上能省出后面脚本调试的大量时间。这里贴一个我常用的 RequirementSkill Prompt 要点供参考你是资深测试分析师。你的任务是基于需求描述输出测试场景和用例。 第一步列出测试场景主流程/边界/异常/兼容覆盖产品逻辑而非技术逻辑。 第二步将场景细化为用例格式为用例编号、前置条件、操作步骤、预期结果、优先级。 第三步为每个用例给出1-3条可落地的断言建议侧重业务规则而非页面文案。 输入需求若不足以支撑用例设计时必须输出“需求疑问”停止生成用例。多说一句这个 Skill 的产出质量直接决定后面所有环节的天花板。用例设计得扎实脚本生成才有章可循用例设计得空洞后面跑得再热闹也只是在走形式。3.2 ScriptSkill从描述、录制到可执行脚本ScriptSkill 负责把用例“翻译”成真正的自动化脚本。它本身要兼容两类输入一类是从 RequirementSkill 过来的结构化用例另一类是录制生成后的中间格式比如 Playwright 的 codegen 输出、Selenium IDE 的 .side 文件。在 Web 端我推荐优先考虑 Playwright 和 Selenium。Playwright 的 codegen 功能很强录制一次就能生成可运行的测试脚本Selenium 则是生态成熟缺什么资料都能搜到适合团队整体迁移成本较低的情况。在 App 端Android 通常用 UIAutomator2 驱动iOS 用 XCUITest 驱动中间层可以通过 Appium 统一接入。这里必须单独说一句“录制的脚本不能直接当交付物”。录制脚本最大的问题在于定位策略太“脆”。你录制的时候点的那个按钮系统生成的可能是一串绝对 XPath只要页面布局稍微调整脚本立刻挂掉。所以 ScriptSkill 的一个重要职责是“脚本清洗”把绝对定位改成相对稳定的定位优先使用 id、data-testid、name 等属性其次是稳定的文本和层级关系绝对 XPath 要尽量避免。元素定位策略按优先级排序我在团队里已经固定成了标准优先 id /> 从万能Skill到五段式流水线：AI Agent UI自动化测试的工程化实践
实不相瞒我自己最早做 Agent 测试助手的时候也干过“一把梭”的事把需求解析、用例设计、脚本生成、执行调度、报告输出全塞进一个 Skill 里。Prompt 写到三千字看起来无所不能真正跑起来处处碰壁。后来痛定思痛把整套能力拆成了 5 个垂直 Skill串成一条从“UI 自动化执行”到“报告生成”的流水线才算是把 AI 测试提效这件事真正落地了。这篇文章就围绕这个思路展开为什么我强烈建议“别搞万能 Skill”5 个 Skill 各自怎么设计、边界画在哪、参数怎么配、坑在哪里以及它们在一次真实回归测试里是怎么串联起来的。如果你正在用 Agent 做 UI 自动化测试或者正准备拿 AI 提效测试流程这篇文章应该能给你一套拿来就能用的方案。1. 为什么“别搞万能 Skill”一次踩坑后的思路转变1.1 万能 Skill 的典型症状我最早做的“万能测试助手”把所有测试能力塞进一个 Skill 里Prompt 里既有用例分析方法论又有脚本编写规范还有报告模板说明。表面上看功能很全实际用起来问题一个接一个。最典型的症状是上下文窗口被严重浪费。每次调用这个 Skill 时系统都要把三千字的 Prompt 加上历史对话一起塞给模型。轮到真正执行任务时可用上下文已经少了一大截复杂项目里经常出现“前半段记得需求后半段忘了格式”的情况。更难受的是角色混乱。同一个 Skill 里模型有时候把自己当测试分析师输出用例写得头头是道等下一轮让它写脚本时它又把断言规则和报告模板混在一起生成的代码里全是跑不通的“缝合怪”。改 A 坏 B 是家常便饭调试一次往往要花比手写脚本更长的时间。这种“样样通、样样松”的体验其实触及了一个核心问题Agent Skill 不是一个“百科全书”而是一个“岗位角色”。你让一个人同时做需求分析师、脚本工程师、执行调度员、故障诊断专家、报告编辑他一定会手忙脚乱。正确的做法是把岗位拆开让每个角色专注一件事。1.2 “小步快跑”的垂直分解思路后来我换了个思路不再追求一个大而全的 Skill而是把测试流程拆成 5 个职责单一、输入输出明确的垂直 Skill。每个 Skill 只做一件事但把这件事做到位。这样做有几个立竿见影的好处。第一Prompt 对上下文窗口的压力指数级下降模型能够把全部精力放在当前环节第二每个 Skill 可以独立调试、独立测试出问题的时候你很清楚该改哪里第三Skill 之间通过明确的输入输出衔接可以灵活替换比如今天用 A 家的脚本生成模型明天换成 B 家的只改一个模块就行。我拿这个思路跟团队里的同事聊有人问“拆成 5 个 Skill 是不是太重了直接写一个工作流脚本里面 call 不同的函数不就行了”我的回答是如果每个环节的职责很简单纯函数调用确实够了但测试这个场景里需求理解、脚本生成、失败诊断的节点都涉及“生成式判断”不是固定逻辑能覆盖的。把这些判断逻辑放进带 Prompt 的 Skill 里再交给 Agent 编排才有足够的灵活度去处理真实世界的各种异常情况。打个比方。一条手工流水线上你不会让一个工人既负责切菜又负责掌勺又负责摆盘。AI 测试也一样把复杂任务切分成有边界的子任务每个子任务用专门的 Skill 处理整体效率和稳定性都会好很多。这也是我认为“万能 Skill”这条路从一开始就走歪的原因。2. 五个 Skill 的整体设计与拆解2.1 从需求到报告的完整流水线先说整体流程方便大家有个全局印象。整套流水线的输入是一段需求描述或者产品需求文档链接、页面截图输出是一份可以直接分享给团队的测试报告。中间经过 5 个 Skill分别是Skill 名称核心职责主要输入主要输出RequirementSkill需求解析、场景梳理、用例生成需求描述、PRD 链接、页面截图测试场景列表、测试用例、优先级、断言建议ScriptSkill测试脚本的生成、录制转换与修复建议测试用例、页面 DOM 结构、录制数据可直接运行的自动化测试脚本ExecSkill执行调度、环境配置、结果采集测试脚本、运行环境、测试素材执行结果、日志、截图、视频DiagnoserSkill失败原因分析与修复建议截图、日志、网络请求、断言数据失败原因分类、置信度、修复建议ReporterSkill数据聚合、报告生成、要点提炼各 Skill 输出、执行结果汇总结构化测试报告Markdown/HTML为了让大家好记我习惯把这 5 个 Skill 叫成“需求拆解—脚本生成—执行调度—失败诊断—报告输出”。它们之间有一条默认数据流同时也有条件分支只有执行结果异常时才会触发 DiagnoserSkillDiagnoserSkill 的修复建议会回传给 ScriptSkill 做脚本修复形成一个闭环。2.2 为什么是这 5 个边界划分逻辑有人可能会问为什么不是 3 个也不是 7 个这个数量其实是跟着“决策点”走的。需求拆解和脚本生成必须分开是因为“理解业务”和“写工程代码”是两种完全不同的模型能力。如果你让模型在同一个 Prompt 里既做业务分析又写 Selenium 代码它往往会在写断言时忘了业务语义或者在分析场景时过度设计技术方案。分开之后RequirementSkill 可以专注生成“能立案”的测试用例ScriptSkill 只需要照着用例翻译成代码互不干扰。ScriptSkill 和 ExecSkill 分开则是出于“稳定运行”的考虑。脚本生成属于“生成”任务重在格式正确执行调度属于“运维”任务重在环境配置、超时控制、重试策略。把这两者混在一起模型在排障时容易被环境变量带偏。实际工作中环境问题占了 UI 自动化失败原因的一半以上把执行单独拆出来做精细控制收益非常直接。DiagnoserSkill 和 ReporterSkill 的存在则是因为失败诊断和报告生成是“最容易出彩也最容易被忽视”的环节。很多团队把自动化跑完就完事了结果一大堆失败用例堆在那儿没人看。有了专岗 Skill 之后失败原因有人分析报告有人提炼整个流程的价值才能真正体现出来。3. 五个 Skill 的核心细节与实操要点3.1 RequirementSkill用例拆解怎么做到“能立案”RequirementSkill 是整个流水线的第一棒。它的输入通常是一段产品需求描述有时候还会附带 PRD 链接、原型图、历史缺陷记录。输出是结构化的测试场景和用例。我在实践里要求 RequirementSkill 必须遵循“先场景、后用例、再断言”的三段式产出。第一步先列出从需求中可以推导出的测试场景包括主流程、边界场景、异常场景和兼容性场景。第二步才是把每个场景细化成用例每个用例必须有前置条件、操作步骤、预期结果和优先级。第三步补充断言建议这步特别重要因为后续 ScriptSkill 写代码时依赖的就是断言建议。这里有一个很关键的实践细节你必须给 RequirementSkill 提供“需求上下文”而不是“一句话需求”。我通常会让它先阅读 PRD 链接或需求文档再要求它提出“需求不明确点”。如果它列出的疑问超过 3 个我会要求它先不要生成用例先向用户澄清需求。这个设计看起来多了一道交流实际上能省出后面脚本调试的大量时间。这里贴一个我常用的 RequirementSkill Prompt 要点供参考你是资深测试分析师。你的任务是基于需求描述输出测试场景和用例。 第一步列出测试场景主流程/边界/异常/兼容覆盖产品逻辑而非技术逻辑。 第二步将场景细化为用例格式为用例编号、前置条件、操作步骤、预期结果、优先级。 第三步为每个用例给出1-3条可落地的断言建议侧重业务规则而非页面文案。 输入需求若不足以支撑用例设计时必须输出“需求疑问”停止生成用例。多说一句这个 Skill 的产出质量直接决定后面所有环节的天花板。用例设计得扎实脚本生成才有章可循用例设计得空洞后面跑得再热闹也只是在走形式。3.2 ScriptSkill从描述、录制到可执行脚本ScriptSkill 负责把用例“翻译”成真正的自动化脚本。它本身要兼容两类输入一类是从 RequirementSkill 过来的结构化用例另一类是录制生成后的中间格式比如 Playwright 的 codegen 输出、Selenium IDE 的 .side 文件。在 Web 端我推荐优先考虑 Playwright 和 Selenium。Playwright 的 codegen 功能很强录制一次就能生成可运行的测试脚本Selenium 则是生态成熟缺什么资料都能搜到适合团队整体迁移成本较低的情况。在 App 端Android 通常用 UIAutomator2 驱动iOS 用 XCUITest 驱动中间层可以通过 Appium 统一接入。这里必须单独说一句“录制的脚本不能直接当交付物”。录制脚本最大的问题在于定位策略太“脆”。你录制的时候点的那个按钮系统生成的可能是一串绝对 XPath只要页面布局稍微调整脚本立刻挂掉。所以 ScriptSkill 的一个重要职责是“脚本清洗”把绝对定位改成相对稳定的定位优先使用 id、data-testid、name 等属性其次是稳定的文本和层级关系绝对 XPath 要尽量避免。元素定位策略按优先级排序我在团队里已经固定成了标准优先 id />