AI coding 把写代码的流速拉满之后，留下来一个没人愿意直视的瓶颈：验证。Claude Code、Cursor、Copilot 几小时就能吐出一堆新功能，可谁来保证这些代码真能在终端用户那里跑通？传统端到端测试要写脚本、养脚本、随界面一变就修脚本，维护成本随功能数量线性上涨。Momentic 9 月 28 日推出的 Mo，直接把脚本这层抽掉：你给一个网址、一组测试凭证，再讲清楚要测什么，剩下的交给一群智能体。
Mo 的工作方式很直白。一个探索智能体先把应用的用户流摸一遍、映射出该测的用例；随后一群 bug-bash 智能体并发去点按钮、填字段、试着跑成千上万种排列与边界情况；任何疑似缺陷先经过一个复现智能体确认，确认不了的就不进报告。最终交付的不是一堆要维护的用例，而是一份报告：测了什么、哪些挂了、怎么复现、以及每个问题的录屏证据。官方口径里，一次 bug bash 可以并发上百个智能体，各自拿着独立的浏览器或模拟器，从给 URL 到出报告大约二十分钟。
这套打法的核心论点，是「覆盖度随智能体算力放大，而不是随人力工时」。当一个 coding 智能体能几小时生成新功能，再让人花几天写测试脚本、还只能盖住一半边界情况，这笔账本来就拧巴。Mo 的思路是把验证也交给智能体：你的智能体写代码，Mo 负责把软件暴打一遍，你（或你的 coding 智能体）再拿着报告去修。官方披露的 beta 数据称累计跑过一千一百多次 bug bash、抓到三千五百多个已确认缺陷，早期客户里点名了 Notion、Superpower、Iris、Committee for Children、Boundless。
Mo 也不是完全不留痕迹。它支持把覆盖过的流程导成纯英文步骤、存成仓库里的 YAML 文件，coding 智能体可以经 MCP 服务写这份文件、CLI 在 CI 里跑——等于给「还想保留套件」的团队留了后路。它还接 PRD、Jira、Linear、Confluence 这类文档当上下文，需要更深理解某个功能时就喂进去；装了 GitHub App 后，能把一个 PR 圈定范围跑一遍，把结果作为评论贴回、还能挂一个合并前要求的 status check。
对已经重度使用 AI coding 的团队，Mo 的价值还在于把「验证」从一道被忽略的工序重新拉回主流程。代码生成越来越快，测试却常被当作上线前的附属，结果缺陷在交付后才暴露、回修更贵。把验证交给一群智能体持续跑，等于用算力把这道工序常态化——代价是团队要重新定义「什么叫测够了」，以及当报告里全是录屏与复现步骤时，人怎么快速裁定优先级。
但要冷静看这套叙事。所有亮眼数字都来自厂商自己的 beta，缺少独立对照基准；一个 bug 是不是真 bug、误报率多少、跑一次成本和可复现性如何，公开材料里没有给出横向比较。更现实的顾虑是审计：当测试不再以脚本形式存在于代码库，监管或安全审查要怎么证明「你测过」？无脚本固然省了维护税，却也拿走了可留痕、可复盘的那份工件。对工程团队，Mo 一类的工具能压掉大量探索性测试的人力，但覆盖率、误报、权限与复现这几项评估，不能因为它「不用写脚本」就免掉。
放到更大的走势里看，Mo 是「智能体往专用企业工作流深处走」的又一例。测试这件事重复、受规则约束、做好了价值又高，天然适合被智能体接管；HappyRobot、InstaLILY 等同期的融资也指向同一方向。对已经在用 AI coding 工具、又被测试套件拖慢的团队，值得认真评估的，不是「要不要用智能体测」，而是「把哪一段验证交给智能体、留哪一段给人复核」，以及当脚本不再是默认工件时，审计口径怎么补上。