Vibe Coding 改变了很多团队的开发节奏。把需求拆解之后交给 AI，几分钟出一个可以跑通的版本，再迭代几轮就能上线。
但在真实研发流程里，代码写完并不等于功能可以交付。一个页面生成出来之后，还需要验证交互是否正确，表单是否能提交，权限是否生效，异常提示是否符合预期，历史流程是否被影响。这种细粒度的变化靠 Code Review 很难覆盖，靠单元测试也只能验证逻辑层，最终还是需要测试和回归。
这就带来了一个新的矛盾：AI 让代码生成速度变快了，但测试的速度并没有同步变快。Vibe Coding 的节奏越快，这个矛盾越明显。
传统 UI 自动化为什么一直推不动？
加快测试速度的主流解决方案是 UI 自动化测试，针对 Web 应用的自动化测试方案大致有两类。
第一类是脚本化方案，例如 Selenium、Playwright、Cypress。
这类工具可以精确控制浏览器行为，支持复杂的等待策略、断言逻辑、CI 集成。但前置成本很高，需要有测试开发能力的工程师来搭建框架、维护定位器、处理异常。维护成本则更高，页面结构一改，XPath 就可能失效，CSS 选择器找不到元素，需要工程师回到代码里逐项修补。
第二类是轻量录制回放工具，例如 Chrome DevTools Recorder 以及一些浏览器插件式工具。
这类产品录制门槛低，在页面上操作一遍就能生成用例，但普遍无法稳定回放。多数工具依赖单一选择器策略，页面结构一变，很容易找不到元素，失败了也缺少足够的现场信息，难以快速判断问题根源。
Vibe Coding 场景下，这两类问题都被放大了。
一方面，脚本方案的工程化成本更明显，因为代码和页面变化更频繁，脚本需要更快跟上。另一方面，轻量录制工具也难以长期使用，因为 AI 辅助开发往往会带来高频的 UI 结构调整。过去一周变一次的页面，现在可能一天变几次。如果回放机制不够稳定，录制出来的用例很快就会失效。
从真实操作到可维护的测试资产
Vibe Coding 时代需要的不是简单地在传统方案里二选一，而是一种更贴近真实工作流的 UI 自动化方式，既降低用例创建门槛，又尽可能提升回放稳定性，既能让非测试人员参与，又能支撑长期维护。
新的 UI 自动化工具设计至少需要覆盖几个方面。
第一，操作足够简单，不需要维护脚本工程。第二，测试用例可稳定复用、可长期维护。第三，用例执行失败后可以快速定位问题。
以 回演 CueCast 为例，它的设计思路是把真实操作、结构化步骤、稳定回放和失败诊断放在同一条链路中处理，在录制的同时把业务路径转化为可编辑、可回放、可维护、可追踪的测试资产。
和轻量录制工具的区别在于，它不只是把操作录下来，还着力解决了稳定回放和长期维护这两个更难的问题。
回放为什么能跑稳
录制回放期间，元素定位不准是最常见的问题。
XPath 表达能力强，但对 DOM 结构变化敏感；CSS 选择器效率高，但 class 名不稳定时容易失效；文本内容更贴近用户语义，但相同文案容易产生歧义。
为了提高回放稳定性，CueCast 不依赖单一选择器，而是同时保存多种定位线索，并在回放时根据当前页面状态按优先级匹配，从而提升对页面变化的容错能力。
在执行层面，CueCast 优先通过 Chrome DevTools Protocol（CDP）在浏览器协议层分发输入事件，模拟更接近真实用户路径的鼠标点击和键盘输入。相比直接操作 DOM，CDP 更接近浏览器层面的真实交互，对下拉框、搜索框、联动表单、富交互组件等场景更可靠。
对于结构特殊或事件链复杂的页面，CueCast 会自动降级到 DOM 操作作为兜底。两层机制结合，可以提高复杂场景下的回放成功率。
如果最后回放失败，系统会保留失败步骤的截图、错误信息和执行上下文。排查时直接在报告里定位，不需要复现问题。
用例如何长期维护
很多录制工具会把一次操作保存成线性轨迹，可以回放，但不容易编辑。中间某一步变了，用户往往只能重新录一遍。当团队积累了几十条核心路径后，任何一次流程调整都可能变成批量维护工作。
CueCast 的思路是把用例拆解为结构化的步骤，每个步骤都能单独查看或修改。
当页面变化时，只需要对关键步骤进行局部修复。例如，按钮文案或位置变了，或者等待时间不够，可以只修改某一个步骤的输入值、等待时间、XPath、CSS 选择器等信息，不需要重新生成整条用例。
如果流程只是中间某几步发生变化，可以从指定步骤继续录制，录制的步骤自动插入原流程之间。这样可以保留原有路径中已经稳定的部分，只更新真正变化的部分。
此外，CueCast 目前正在推进 AI 用例自愈能力，目标是在页面结构发生变化、定位失效时，由 AI 自动识别上下文并修复受影响的步骤，进一步降低人工维护介入的频率。
AI 在哪里发挥作用
在 UI 自动化里，AI 不适合替代所有确定性逻辑，更适合处理需要结合上下文判断的环节。
一个是失败诊断。用例失败后，系统可以结合失败步骤、截图和错误信息，辅助判断问题可能在哪里。对没有专职自动化测试工程师的团队来说，这能降低排查门槛。
还有一类是智能步骤。有些测试场景不适合录成完全固定路径，比如随机选择一个可用选项，或者根据当前列表数据决定下一步操作。这类步骤可以用自然语言描述意图，再由系统在回放时结合当前 DOM 状态执行。
在 CueCast 里，AI 主要放在以上这些辅助环节，而不是替代整个测试执行链路。这样既能利用 AI 的上下文理解能力，也能保留自动化测试对稳定性和可复现性的要求。
嵌入 Vibe Coding 的工作流
想象一下，在一个使用 AI 工具快速迭代的团队，你用 AI 辅助完成了一个后台配置页面。它包括列表、新建、编辑、删除、状态筛选和导出。代码生成很快，组件也能正常显示。但在提测之前，你仍然需要确认主流程能不能跑通。
这时候，你可以先不急着写完整的 Playwright 脚本，而是用 CueCast 在测试环境中操作一遍从登录、新建配置到导出配置的核心路径。
第一次操作完成后，这条路径就可以被沉淀成自动化用例。之后每次页面改动、样式调整、字段新增或交互优化后，都可以重新运行这条用例，快速确认主路径是否仍然可用。
如果团队每天都会用 AI 改几轮页面，CueCast 这类自动化工具可以承担自动化回归测试的工作。它不一定覆盖所有边界条件，但可以覆盖需要反复验证的核心路径。这样，开发者在提测前可以先跑一遍主流程，测试人员在版本发布前也可以跑一遍核心回归，确保产品核心功能没有问题。
Vibe Coding 时代，测试范式也需要变化
Vibe Coding 改变了代码生产方式，但它无法解决软件质量问题。
恰恰相反，当代码生成变得更快，测试需要更早介入，也需要更低成本地执行。过去测试可能更多集中在提测之后，现在测试能力需要前移到开发自测、功能联调和发布前检查中。
自动化工具要做的就是降低参与门槛，把一次次手动操作转化为团队可持续维护的测试资产。对于正在采用 Vibe Coding 的团队来说，这可能是开发提速之后，质量保障链路需要补上的关键一环。