这两年，大家对 AI Coding 的体感很明显：写代码越来越快了。
尤其是从 2026 年初开始，AI Coding 的发展像开火箭一样，从 Cursor 到 Claude Code 到 Codex...工具越来越多，模型也越来越厉害。人人都开始 Vibe Coding 了。这不，最近连胡彦斌都因为 Vibe Coding 火了一把。
但 coding 得越多，另一个问题也越明显：
代码出来得越快，团队越需要确认它到底有没有真的符合我们的需求。
AI 可以加快编码，但它不会自动理解所有业务细节，也不会天然保证旧流程不被影响。尤其是前端和 Web 产品，AI 让页面和交互变得更容易改，UI 变化也会更频繁。
这时候，测试反而会变得更重要。
AI Coding 有个问题，由于大家都没有深度参与到这个项目，导致团队对代码细节的掌控会变弱。而且随着 AI 越来越强，大家会越来越依赖 AI Coding，人对代码的掌控会越来越弱，到最后，就变成了完全黑盒的存在。
我觉得 AI Coding 真正进入工程化之后，团队至少要补两件事。
第一件是事前计划。
让 AI 写代码之前，最好先把需求、边界、交互、数据状态、异常场景、验收标准拆清楚。你可以和 AI 先把方案聊通聊透了，等你完全确认了，再让它开始执行后。
清晰的 plan，不是流程负担，而是给 AI 加约束。约束越清楚，AI 越不容易自由发挥。
第二件是事后测试。
再好的 plan，也不能代替真实验证。代码有没有满足业务预期，旧流程有没有被破坏，UI 改动后关键路径还能不能跑通，最后都要靠测试体系兜住。
然而人工的测试在当今的开发速度下显得有点太慢了，所以测试也应该是自动化测试。
简单说就是：事前靠 plan 降低偏航，事后靠自动化测试确认结果。
接下来聊一聊 UI 自动化测试。
AI 会放大变更速度。
过去改一个页面可能要排期，现在一个组件、一个表单、一个交互逻辑，很快就能生成新版本。按钮位置、DOM 结构、表单层级、下拉组件实现、列表渲染方式，都可能在更短周期内变化。
对 UI 自动化来说，这很要命。
传统脚本很多依赖固定选择器、固定 DOM 层级或固定文案。UI 稍微一动，脚本就可能找不到元素。最后团队不是在验证业务，而是在修脚本、改定位、重新确认用例还能不能跑。
天呐，想想就很难维护，工作量巨大。
说到 UI 自动化，很多人会想到 Selenium、Playwright。
这些工具很成熟，也适合有测试开发能力的团队。但在很多业务团队里，UI 自动化迟迟做不起来，不是因为大家不知道这些工具，而是维护成本太高：要搭框架、写脚本、处理定位和等待；页面一改，脚本又可能失效；失败后还要翻日志、看截图、查 Trace。
轻量录制工具也有，比如 Selenium IDE、Chrome DevTools Recorder、Katalon Recorder。它们适合快速记录操作、调试流程或导出脚本。
但如果要把 UI 自动化变成团队长期使用的测试资产，光 “能录” 还不够。更关键的是：
这才是 AI Coding 之后，UI 自动化真正要解决的问题。
最近看到一款比较适合这个场景的工具：回演 CueCast。
它是一款面向 Web 应用的 AI 驱动、零代码自动化测试工具。核心思路很直接：不用先写 Selenium 或 Playwright 脚本，而是在真实产品页面上操作一遍，把这条路径录制成可维护、可回放、可追溯的自动化测试用例。
我比较关注的一点是，它不是只解决 “录”，而是关注 “长期跑”。
录制时，CueCast 会结合语义属性、稳定结构、文本信息和组件上下文保存多种定位候选；遇到下拉框、组合选择器这类复杂组件，也会优先识别组件根节点和真实可点击区域。
回放时，它通过多定位器选择真正适合的元素，然后使用 CDP 技术以及 DOM 降级技术来实现稳定回放。另外还支持使用 AI 智能步骤，文字描述即可自动实现一些步骤，以超级容易变化的元素或者各种复杂场景。
页面小改版时，团队不一定要整条用例重写，可以先定位到失败步骤，调整局部步骤、断言、等待策略，或者从某一步之后追加录制。
这类工具的价值，不在于替代测试人员，而在于让关键路径能稳定、持续、可追溯地跑起来。
AI Coding 会继续加速开发，这件事大概率不可逆。
但写代码更快，不代表交付风险自动降低。相反，代码越快、UI 变化越快、系统越黑盒，团队越需要稳定的测试体系。
事前，把 plan 拆清楚，让 AI 少偏航。
事后，把关键路径自动化跑起来，确认最终结果。
UI 自动化不一定非要从写脚本开始，也可以从一次真实页面操作开始。感兴趣的可以试试看回演 CueCast 这个工具哈~
