Momentic 实战：把 AI 探索式测试转成可审阅的 PR 回归门禁
AI 编码助手能很快改代码，却不一定知道改动是否真的符合用户预期。单元测试能覆盖函数边界，但登录、结账、移动端键盘等跨页面流程，最终仍要在真实运行的应用里验证。Momentic 把这类端到端验证拆成两条互补路径：让 Mo 探索正在运行的应用并提交带复现步骤的发现；或把可重复的用户流程写成仓库中的 YAML 测试，在本地和 CI 中反复执行。它不是“让模型读代码后猜有没有 bug”，而是把判断落到实际应用行为和可检查证据上。
两种验证，不要混为一谈
Mo 面向探索式检查。按官方文档，给它目标应用（网页 URL 或移动端构建）、要检查的行为说明，以及必要的测试账号，它会探索应用并生成会话报告，报告包括测试用例、判断、覆盖缺口和带复现步骤的发现。对功能性 bug，另一个 Agent 会尝试复现；静态问题则以截图作为证据。探索适合“我刚改完这个流程，帮我找意料之外的问题”，但一次探索报告并不自动等于稳定的回归测试。
回归测试则由团队维护。Momentic 的测试文件使用 YAML，可以把预设步骤、AI 动作和可复用模块组合起来，并提交到 Git。首页展示的示例将登录步骤抽为模块，再执行“把商品加入购物车并前往结账”，最后断言商品总额与逐项金额一致。这里的关键不是 YAML 比代码更聪明，而是步骤和断言可以被人审阅、版本化，并在每次 PR 上重跑。
从一次试跑到 PR 门禁
官方快速开始推荐运行向导，按 Web、iOS 或 Android 选择目标。向导会完成浏览器登录、安装对应 CLI、写入 momentic.config.yaml 与样例测试，并尝试运行样例；文档给出的启动命令是：
npx @momentic/wizard@latest
先让样例在自己的应用上跑通，再把核心用户路径写成测试，例如登录后修改资料、购物车结账或移动端创建内容。断言要描述用户能观察到的结果，而不是重复实现细节：检查最终订单总额、页面出现的确认状态，或关键控件是否可用。测试数据、账号权限和环境配置也应与代码分离，避免把真实凭据提交进仓库。
接入编码 Agent 时，官方提供两种入口：可以按文档用 npx momentic skills --yes 将 Momentic 的技能文件安装到项目，让 Agent 知道如何编写和运行测试；也可以使用本地 stdio MCP server，为 Agent 提供实时浏览器或设备，以及编写、运行、分诊测试的工具。两者都不意味着应让 Agent 无审核地改动测试：测试断言本身也是代码，必须检查它是否覆盖真实需求，而不是为了“变绿”把断言改弱。
稳定后，将相同测试放进 CI，作为合并或部署前的检查。失败时先查看具体步骤、截图和 trace，再区分应用缺陷、测试不稳定还是环境问题。Momentic 还描述了 UI 变化后的自动恢复与永久修复提案；更稳妥的团队策略是把建议当作 diff 审阅、确认后再合并，而非把自愈等同于测试通过。这样，探索式检查负责发现未知问题，可重复测试负责守住已知关键路径。
适用边界与落地建议
Momentic 官方文档列出 Web（基于 Chromium 的浏览器）、iOS 模拟器和 Android 模拟器/仿真器等路径；这不等于任意设备或任意环境都无需配置。先确认目标平台、构建产物、测试账号和 CI 运行环境，再评估接入成本。AI 探索可能漏掉边界条件，生成的报告也需要工程师判断；自动恢复若改变了测试文件，更需要代码审查。复杂业务规则应保留明确、确定性的断言，不要把关键验收完全交给自然语言判断。
一个务实的起点是只选一条高价值流程：先由 Mo 探索并记录风险，再把修复后的稳定路径固化成 YAML 测试，最后让它在 PR 预览环境运行。若测试经常因环境或数据问题失败，先治理测试夹具、等待条件和隔离策略，而不是不断增加 Agent 的探索轮次。衡量价值也别只看“创建了多少测试”，应看关键路径是否被覆盖、失败是否能复现，以及团队能否理解并维护这些检查。
对开发者而言，Momentic 的价值在于缩短“改代码”与“确认用户流程仍然可用”之间的反馈环。它补充而非取代单元测试、静态检查和人工验收：让 AI 帮忙探索、执行和归纳证据，再由团队掌握断言与合并门槛，才是更可控的自动化测试流程。