问答 ai 根据 prd 生成 UI 自动化用例遇到一些问题希望大佬们帮忙看看
背景
领导希望通过 ai 做一个生成 UI 自动化的工具，可以在开发提测后能后直接生成 UI 用例并运行后整合测试报告出来
已实现的逻辑
目前通过 cursor+midscene 有实现解析需求文档，然后生成 UI 自动化用例去运行收集报告，做的是一个 skill 工具
遇到的问题
因为是 skill 工具依赖 cursor 的代码分析能力，加上要配置 midscene 的 apikey 和大模型解析的 apik,还要配置飞书的 mcp 等，使用的人比较少
我打算做成平台，但是平台的话做了几天发现 llm 解析代码的能力跟 cursor 差别好大，失败率很高，大家有什么好的办法吗？
目前实现的方法是根据用户输入的需求文档 + 测试地址这一页的前端代码交给大模型去分析需求 + 扫描前端语义 + 转换为 midscene 格式的 yml 用例，测试数据是通过表单的形式，大概这个样子
求助的方向
1.在生成 UI 自动化的这个方向怎么让大模型能够更好的解析代码，达到 cursor 的标准就可以，cursor 目前生成 + 成功运行率在 80% 左右
2.这个工具核心目的是在提测后能够通过 ui 快速发现一些问题，并且可以快速录入 UI 自动化用例到平台，那么是否有更好的方法
3.大家在这个方向有什么新的思路吗
“可以在开发提测后能后直接生成 UI 用例并运行后整合测试报告出来”， 这个说明你是要测试前端是吧，我觉得前端的东西更多的是 dom 渲染，还有组件是否封装过（自研组件，原生组件）。你想让 AI 帮你生成脚本然后根据你的用例执行？像人一样操作页面上的那些表单啥的？ 还是其他的？ 我也做过类似的 skill ,让 AI 根据测试用例帮你测反正挺耗费 token 的，还有你的用例要写的详细一点，还有定位仍然是一个大问题
自己实现的 agent 怎么和商业/开源 agent(cursor/codex/chatgpt/hermes) 打, 核心能力差异太大了
你自己折腾出来的马鞍，不如 codex，Claude 一根毛。除非你们下定决心要持续维护了，反正舍本逐末你们老大怎么说就怎么搞吧。听老板就行
我们也想让搞这个，根本没思路，公司掏钱买的 dp 的服务，业务逻辑很复杂，没办法通过需求直接串到 ui 用例这个级别
我觉得有 2 个主要因素：
1.前置数据怎么准备
- 页面元素最好加上唯一属性例如 testId
- 直接用 hermes，不要自己写 agent
我吃香菜了
回复
codex claude 这些 agent 都很好，不是要实现这种 agent,可能是我表述问题，是实现一个生成 UI 用例的接口，利用大模型的文本分析和代码分析能力 ，当前模型你可以是任何一个具备代码分析和生成能力的模型不限于 claude 的 sonet
现在还在搞这个，不如让开发在开发阶段 AI 规避所有问题；
浪费人力
就是就换模型了，换好的模型成功就容易了
正在做同样的尝试，只是我是先将需求生成测试用例，再从测试用例生成 UI 自动化代码。
xi
回复
需求生成用例我也在做，但是存在几个问题
1.需求多次人工修改才能满足当前 midscene 识别并执行
2.有些用例无法用自动化执行，无法快速筛选出来完全无法用的用例
想问下有没有遇到过类似 2 个问题
还不如个AI
回复
第一个是生成用例质量的问题：1. 使用更好的大模型 + 不断完善自己的生成 SKILL。2. 输入的需求文档和开发文档也要求更严格一些，最好也能提供给模型历史文档、Bug 和用例。3. 目前大模型还做不到 100% 无需人工修正
第二个本质还是用例质量，如果生成的 UI 测试用例的四大要素比较完善且准确，我想也很难有不能实现自动化的情况，剩下无非是技术实现的问题。我见到的无法执行的用例，大多都是 “一句话用例”，不能自动化也正常。
这个方向我们最近也做了不少尝试。我的感觉是，你现在的流程里其实混在了一起三件事：根据需求设计测试场景、理解页面并找到操作路径、把路径变成可以重复执行的自动化用例。
PRD 比较适合解决第一件事，但单靠 PRD 很难直接解决后两件事。因为需求文档里通常不会写清楚当前账号是什么权限、页面初始状态、测试数据怎么准备、某个下拉框具体怎么操作，以及操作成功后页面上应该出现什么。这些信息缺失时，大模型只能猜，模型越弱或者上下文越少，失败率就越高。
Cursor 效果好一些，我觉得不只是模型能力的问题。它同时拥有代码检索、文件上下文、工具调用和失败后继续修改的循环。换成平台接口以后，如果只是把 PRD、部分页面代码一次性交给 LLM，实际丢失了很多上下文和反馈能力。
可以考虑把流程拆开：
- AI 根据 PRD 生成候选测试场景，先不要直接生成最终 UI 步骤。
- 人工确认哪些是核心流程，补充账号、数据、前置条件和预期结果。
- 在真实页面执行或录制一次，把确认过的路径沉淀成结构化步骤。
- 后续回归直接执行这些步骤，不要每次都让 AI 重新理解页面。
- 只有步骤定位失败、页面发生变化或者需要分析失败原因时，再调用 AI。 另外建议把成功率也拆开统计：场景生成采纳率、首次执行成功率、重复执行成功率、页面变化后的恢复率。只看一个 “生成成功率”，很容易不知道问题到底出在需求理解、页面定位，还是测试数据上。 说明一下，我们在做一个叫回演 CueCast 的零代码 Web 自动化测试产品，目前也是采用 “真实页面录制沉淀为主，AI 补强意图和失败分析” 的路线。并不是觉得 AI 不能生成用例，而是现阶段让 AI 每次从 PRD 重新规划整个回归流程，成本和不确定性都比较高。