这个方向我们最近也做了不少尝试。我的感觉是，你现在的流程里其实混在了一起三件事：根据需求设计测试场景、理解页面并找到操作路径、把路径变成可以重复执行的自动化用例。
PRD 比较适合解决第一件事，但单靠 PRD 很难直接解决后两件事。因为需求文档里通常不会写清楚当前账号是什么权限、页面初始状态、测试数据怎么准备、某个下拉框具体怎么操作，以及操作成功后页面上应该出现什么。这些信息缺失时，大模型只能猜，模型越弱或者上下文越少，失败率就越高。
Cursor 效果好一些，我觉得不只是模型能力的问题。它同时拥有代码检索、文件上下文、工具调用和失败后继续修改的循环。换成平台接口以后，如果只是把 PRD、部分页面代码一次性交给 LLM，实际丢失了很多上下文和反馈能力。
可以考虑把流程拆开：

1. AI 根据 PRD 生成候选测试场景，先不要直接生成最终 UI 步骤。
2. 人工确认哪些是核心流程，补充账号、数据、前置条件和预期结果。
3. 在真实页面执行或录制一次，把确认过的路径沉淀成结构化步骤。
4. 后续回归直接执行这些步骤，不要每次都让 AI 重新理解页面。
5. 只有步骤定位失败、页面发生变化或者需要分析失败原因时，再调用 AI。 另外建议把成功率也拆开统计：场景生成采纳率、首次执行成功率、重复执行成功率、页面变化后的恢复率。只看一个 “生成成功率”，很容易不知道问题到底出在需求理解、页面定位，还是测试数据上。 说明一下，我们在做一个叫回演 CueCast 的零代码 Web 自动化测试产品，目前也是采用 “真实页面录制沉淀为主，AI 补强意图和失败分析” 的路线。并不是觉得 AI 不能生成用例，而是现阶段让 AI 每次从 PRD 重新规划整个回归流程，成本和不确定性都比较高。

是这个道理。AI 测试是为了验证 AI Coding 的准确性，那么又怎么来验证 AI 测试的准确性呢

直接用 AI 产出银行复杂业务的用例不太现实吧，我最近是尝试了一款新的 ui 自动化测试工具，感觉还不错，只要在真实系统中点击一遍就可以把用例录制下来，然后可以进行回放。虽然跟比之前产出用例比还是麻烦了一些，但感觉更方便更精准。这个工具叫 Cuecast，才刚上线没多久，是我朋友的公司做的