(来自YC)软件验证层:AI代码生成时代的最后一道防线–Momentic的深度分析

对话者Weiwei Wu : Momentic 联合创始人Jeff An : Momentic 联合创始人Harj Taggar : Y Combinator 管理合伙人

Momentic公司简介

Momentic 是一家AI原生软件测试平台，旨在为现代开发团队简化并自动化端到端（E2E）验证。该公司成立于 2023 年，总部位于旧金山，目标是通过让开发人员使用自然语言（而非编写脆弱的代码脚本）来描述测试步骤，从而消除“QA瓶颈”。

产品与目标市场

• AI 原生测试平台：一个低代码编辑器，用户可以用平实的英语定义关键业务流。AI 会自动执行这些步骤、判断正确性并进行视觉对比。
• 自愈测试：与      Selenium 或 Playwright 等传统框架不同，Momentic     的 AI 能在 UI 发生变化时通过理解用户意图自动更新测试，而不依赖于固定的 HTML 选择器。
• 多平台覆盖：最初仅支持 Web 端，现已扩展到iOS 和 Android移动端测试，桌面端支持正在开发中。
• 目标市场：主要是追求快速交付的科技公司的工程团队（而非独立的 QA 部门）。
• 知名客户：服务超过 2,600 名用户，包括 Notion、Xero、Webflow、Retool、Bilt 和Quora。

创始人简介

• Wei-Wei Wu (CEO)：曾任 Nashi（被 Density 收购）的创始工程师以及 Assembled     的基础架构工程师。他是Node.js和 Storybook 等著名开源项目的核心贡献者。
• Jeff An (CTO)：滑铁卢大学校友，曾在Qualtrics和WeWork拥有丰富的开发工具开发经验。

融资历史与投资者

Momentic 通过多轮融资共筹集了1,920万美元。

• 个人投资者：知名天使投资人包括Aaron      Levie (Box CEO) 和Kulveer Taggar (Zeus      CEO)。

估值与财务状况

• 估值：虽然 A 轮融资后的具体估值尚未公开，但该公司处于高速增长阶段。据报道，自参加 Y Combinator 以来，某些关键指标增长了40 倍。
• 营收模式：采用B2B      SaaS模式，具有基于使用量的定价机制；客户根据测试执行量付费，而非按账号数量付费。
• 表现数据：客户报告称调试时间减少了 60%，测试执行时间减少了 30%。该平台据称在近期内成功阻止了超过 390,000 个 Bug 流入生产环境。

概要在AI代码生成工具爆发式增长的背景下，软件质量保障正面临前所未有的挑战。本期对话中，Y Combinator管理合伙人Harj Taggar与Momentic联合创始人Weiwei Wu和Jeff An深入探讨了AI时代软件开发流程的根本性变革。Momentic作为一家AI测试平台，定位为“软件的验证层”，通过模拟真实用户行为来验证应用程序的功能正确性，每天处理超过一百万次测试运行，客户包括Notion、Quora等知名企业。

对话的核心洞察在于，随着Cursor、Claude Code等AI编程工具的普及，代码输出量呈指数级增长，但验证环节却成为新的瓶颈。传统测试方式面临三重困境：工程师普遍厌恶编写测试（因为这不是“可见”的生产性工作）、手动测试无法规模化、传统自动化工具（如Selenium）维护成本高且极易出现“脆性”。Momentic通过多智能体架构，将测试从“代码维护”转变为“规范维护”，使工程师能够用自然语言描述用户旅程，由AI自动完成测试编写、执行和持续维护。

更深层次地，对话揭示了一个范式转移：从“代码即真理”到“规范即真理”。在这种“规范驱动开发”模式下，工程师的核心工作不再是编写和审查代码细节，而是定义产品应该满足的用户成功标准。代码降格为“实现细节”，而验证层成为连接规范与实现的闭环反馈机制。这种转变不仅重新定义了软件工程师的角色，也为AI时代的生产力提升提供了新的思考框架。Momentic的技术架构、市场策略和创始人洞见，为理解AI如何重塑整个软件开发生命周期提供了极具价值的样本。

主题分析

一、AI代码生成与验证瓶颈的悖论当前软件开发领域正经历一场由AI驱动的生产革命。Cursor、Claude Code、Codex等工具使开发者能够以自然语言指令生成大量代码，单日代码产出量呈指数级增长。然而，对话揭示了一个关键悖论：代码生成的效率提升并未带来相应的验证能力提升，反而使验证环节成为新的瓶颈。当AI可以瞬间生成数百行代码时，人类工程师无法以同样速度检查这些代码的正确性。

这种瓶颈的形成源于验证环节的本质。代码审查（code review）和静态分析工具（linters）虽然能够检查代码是否符合语法规范和最佳实践，却无法回答一个根本问题：这段代码在真实用户场景下能否正常工作？传统解决方式是手动测试（即“bug bash”）或编写自动化测试脚本。手动测试无法随代码增长而规模化，而自动化测试工具如Selenium虽能部分解决问题，但维护成本极高。Jeff在Robinhood的经历生动说明了这一点：当工程团队从300人增长到1000人时，他管理的8人团队需要说服其他1000名工程师编写和维护测试，目标是覆盖80%的代码并保持90%的通过率，但这“基本上不可能”。

AI生成代码的爆发使这一问题从“挑战”升级为“危机”。模型不仅生成更多代码，而且会“自信地走向错误方向”，生成看似合理但功能错误的代码。在这种情况下，验证层不再是开发流程中的一个环节，而是决定代码能否安全进入生产环境的“最后一道防线”。这解释了Momentic为何将自身定位为“软件的验证层”——不是测试工具，而是确保AI生成的代码确实实现了预期功能的独立验证机制。

二、测试的“动机问题”：为何工程师不愿编写测试对话中揭示了软件开发中的一个长期存在的“动机问题”：工程师普遍不愿意编写测试。Weiwei和Jeff将这一现象归结为测试工作缺乏“可见性”。编写测试不会产生用户可见的功能，无法在演示中展示，通常也不会出现在绩效评估的关键指标中。从心理学角度看，这是一种“负向激励”的典型场景——测试的价值体现在“避免坏事发生”（阻止bug进入生产），而非“创造新价值”。这种价值形态使测试工作容易被视为“拖累”而非“生产性工作”。

在AI代码生成时代，这一动机问题变得更加突出。当AI可以瞬间生成功能代码时，要求工程师花时间编写和维护测试脚本，在心理上更加难以接受。工程师会本能地倾向于让AI完成全部工作，包括测试，但这种做法存在根本性缺陷。Jeff指出，AI模型“通常认为自己不需要测试”或“认为自己做的是正确的”。更重要的是，即使AI能够生成测试脚本，这些脚本也面临维护难题：当应用功能变更时，由AI生成的数千行测试代码需要人工定位和修改，其工作量可能超过从零编写。

Momentic解决这一动机问题的方式是“封装复杂性”。用户不再需要编写和维护测试代码，只需用自然语言描述用户旅程，由Momentic的AI智能体负责生成、执行和维护测试。这种设计将测试从“额外工作”转化为“规范定义”，使工程师能够聚焦于“产品应该做什么”，而非“如何验证它做了什么”。当测试的维护成本趋近于零时，工程师的动机障碍被从根本上消除。

三、Momentic的技术定位：从测试工具到验证层理解Momentic的价值需要将其置于软件开发工具栈的完整图谱中。对话清晰区分了不同工具在开发流程中的角色：

• 静态分析工具（Linters）：检查代码是否符合语法规范和最佳实践，如变量命名、缩进风格等，但不涉及运行时行为。

• 代码审查（Code Review）：无论是人工还是AI辅助（如Cursor BugBot），主要关注代码逻辑、架构和可读性，但仍难以验证复杂用户场景下的实际表现。

• 单元测试与集成测试：验证代码单元和模块间的交互，但通常由开发者编写，维护成本高，且难以覆盖端到端的用户旅程。

• 功能测试（Functional Testing）：这是Momentic的专注领域。它模拟真实用户行为，在浏览器环境中实际执行点击、输入、拖拽等操作，验证整个用户流程是否按预期工作。

Momentic与传统功能测试工具（如Selenium、Cypress、Playwright）的本质区别在于其“智能体架构”。传统工具需要工程师使用代码（如XPath、CSS选择器）精确定位页面元素，编写测试脚本，并处理异步加载、动态内容等复杂场景。当应用UI发生变化时，这些脚本极易“脆性”断裂，需要大量维护工作。Momentic则采用自然语言描述测试意图，由底层多智能体系统自动完成元素识别、操作执行和结果断言。

更关键的是，Momentic的智能体针对速度和调试体验进行了优化。平均每个测试步骤的执行时间低于300毫秒，远快于通用浏览器智能体。当测试失败时，系统自动捕获页面状态、元素交互轨迹，并提供智能诊断，而非仅返回模糊的错误信息。这种“为测试而设计”的智能体架构，使其能够处理传统工具难以应对的复杂交互场景，如富文本编辑器、拖拽界面、Canvas元素等。

四、规范驱动开发：代码降级为“实现细节”对话中最具颠覆性的观点是关于软件开发范式的根本转变。Jeff提出了“规范驱动开发”（Spec-Driven Development）或“真理驱动开发”（Truth-Driven Development）的概念，其核心是将“规范”而非“代码”视为系统行为的源头真理。

在传统范式（“代码即真理”）下，生产环境中运行的代码被视为系统行为的最终定义。这种观点的缺陷在于：代码包含bug，bug也成为“真理”的一部分；当代码与实际需求不符时，问题往往在用户反馈后才被发现。更重要的是，在这种范式下，工程师的核心工作是理解、修改和维护代码本身。

在规范驱动开发范式中，规范成为真理。规范以结构化、可读的形式定义用户旅程、成功标准、边界条件和期望行为。代码只是规范的实现，是“实现细节”。这意味着：• 工程师的主要工作从“编写代码”转变为“编写规范”• AI负责将规范转换为代码• 验证层（如Momentic）负责确保实现符合规范• 当规范变更时，验证层自动更新测试，代码层通过AI重新生成

这一范式对软件工程职业的影响是深远的。Harj提出一个问题：未来工程师是否还需要理解代码？Jeff的回答是肯定的，但理解的层次会发生变化。工程师仍然需要掌握技术判断力，如系统集成、可扩展性、技术品味等，但代码本身不再是工作的核心对象。工程师的角色更像“产品架构师”或“技术PM”——理解用户需求，定义规范，协调AI智能体完成实现，并基于验证反馈进行调整。

这一转变已经在发生。Momentic的客户开始将测试用例（即规范）作为开发和验证的共同参考点。当AI生成代码后，Momentic自动运行测试；如果测试失败，AI可以根据失败信息修正代码；如果测试通过且规范已实现，代码即可部署。这形成了一个闭环反馈系统，其中规范是唯一需要人类维护的资产。

五、与传统测试工具的竞争格局：Selenium、Cypress与Playwright对话中，Weiwei以Notion为例，展示了Momentic与传统工具在实际场景中的差异。Notion之前的测试体系是Selenium脚本与手动测试的混合。Selenium作为老牌功能测试框架，面临两个核心问题：

元素定位脆弱：Selenium依赖XPath或CSS选择器定位页面元素。Notion作为高度动态的富文本应用，UI结构频繁变化，导致测试脚本持续断裂。

维护成本高：当测试脚本规模达到数万行时，每次UI重构都意味着数周甚至数月的测试维护工作。

Momentic通过“规范即代码”的方法解决了这两个问题。用户不再编写元素选择器，而是描述意图，如“在Notion数据库中创建一个新页面，标题为‘会议记录’，并添加一个待办事项”。底层AI智能体动态识别页面状态并执行操作，即使UI发生变化，只要意图不变，测试自动适应。这使测试从“维护代码”变为“维护规范”，维护成本从数周降至几乎为零。

Notion的案例也展示了Momentic的可扩展性。从最初Simon Last在Twitter上表达需求，到Weiwei当晚通过DM联系并完成自助上线，再到正式POC，整个过程反映了产品设计的核心原则：低摩擦。Notion现在每天执行近50万次测试运行，Momentic测试成为工程师合并PR前的必须通过的检查项。这种深度集成将测试从“可选环节”提升为“发布闸门”。

从ROI角度看，Momentic的价值体现在两个维度：• 直接维度：节省开发者时间。相比维护Selenium脚本，Momentic减少的工程师时间可量化。• 战略维度：防止的回归错误数量。这是更重要的指标，因为一个生产事故可能带来用户流失、品牌损害和修复成本。

六、开发流程中的集成：MCP、Cursor与闭环反馈Momentic的增长策略与其技术定位高度一致：它不是替代现有工具，而是填补开发流程中的关键空白。对话中提到了两个关键的集成方向：

第一个是开发者环内的集成。通过MCP（Model Context Protocol）服务器，Momentic能够与Cursor或Claude Code等AI编程工具深度集成。当开发者（或AI智能体）在编写代码时，可以主动调用Momentic在真实浏览器环境中验证当前变更。这种“开发中验证”模式将测试从“发布前阶段”拉入“开发阶段”，实现即时反馈。Jeff指出，AI智能体通常不会主动验证自己的代码，或认为自己的代码就是正确的。通过MCP集成，验证成为AI工作流的一个显式步骤。

第二个是代码生成与验证的闭环。理想状态下，代码生成器（如Cursor）与验证器（Momentic）之间形成反馈循环：

1.规范定义：人类定义用户旅程和成功标准

2.代码生成：AI根据规范生成代码

3.自动验证：Momentic运行测试，验证代码是否符合规范

4.反馈修正：如果测试失败，失败信息被反馈给代码生成器，AI根据失败原因修正代码

5.循环迭代：重复步骤3-4直至测试通过

这种闭环将验证从“一次性检查”转变为“持续优化”，使AI能够通过失败案例学习并改进。这也是Jeff强调的“外部真理源”的价值——不能信任代码生成器自我验证，需要一个独立的第三方验证系统作为仲裁者。

七、工程角色的演变：从代码维护者到规范定义者对话中关于工程师角色变化的讨论，触及了AI对知识工作影响的核心。Weiwei分享了自己从药学到计算机科学的职业转变，Jeff则从化学研究转向创业，两人的路径反映了对“解决问题”的渴望超越了对特定技术栈的执着。这种背景或许使他们更能接受工程师角色的根本性转变。

未来的工程师需要具备哪些能力？对话中提炼出几个核心维度：• 适应性与学习能力：AI工具栈以月为单位变化，工程师必须持续学习新工具和范式。• 产品直觉与品味：AI目前不擅长判断“什么是好的用户体验”，这种判断力仍是人类的优势。• 系统思维：理解代码如何与其他系统、第三方服务、数据流交互，这部分仍需要技术深度。• 规范定义能力：将模糊的需求转化为精确、可测试的成功标准。

Jeff指出一个关键点：“Claude Code只会让你成为10倍工程师，如果你本来不是10倍工程师的话。”这意味着AI工具放大了已有能力的差异，而非消除差异。优秀的工程师仍然优秀，但平庸工程师与优秀工程师之间的差距可能更大。

在招聘和团队建设上，Momentic强调“激进坦诚”的文化。在13人的小团队中，直接、清晰的反馈被视为基础，同时强调“不要做混蛋”。更重要的是，每个团队成员对产品路线图都有发言权。这种文化设计旨在最大化集体智慧，在快速变化的技术环境中保持敏捷和适应性。

八、产品市场契合的早期信号：从Twitter互动到生产级部署Momentic找到产品市场契合的过程，展现了现代B2B SaaS产品增长的新模式。关键转折点来自于Notion工程经理Simon Last在Twitter上的一条推文，表达了对“自然语言测试”的渴望。当其他人在评论中推荐Momentic时，Weiwei当晚就在San Francisco时间晚上10点通过DM联系Simon，发送了一个演示视频，并在当晚完成了初步接入。

这个案例揭示了几个重要洞察：• 开发者社区作为发现渠道：对于开发者工具类产品，Twitter、Hacker News等技术社区是高效的早期用户获取渠道。• 低摩擦的初次体验：能够“当晚完成接入”意味着产品设计极度简化了启动步骤。如果用户需要复杂的配置、审批或培训，这个机会就会流失。• 从个人使用到组织采购：Simon的个人体验足够好，促使他在Notion内部推动正式的POC流程。这反映了“自下而上”的增长模式——工程师个人发现价值，然后向上推动采购。

Momentic从“一个工程师在Twitter上的抱怨”到“Notion每日50万次测试运行”的过程，展示了优秀产品如何通过解决具体痛点而自然扩散。这也印证了创始人坚持的信念：降低门槛到“零或负数”，让用户“自然落入成功的陷阱”。

九、创始人背景与团队文化：技术深度与创业韧性的结合Momentic两位创始人的背景为理解其产品哲学提供了线索。Weiwei从药学转向计算机科学，Jeff从化学研究转向创业。两人都经历了“从实验室到产品”的转变，对“代码产生实际影响”的渴望驱动了他们的创业路径。这种背景使他们更容易接受“规范驱动开发”的范式，因为他们对“结果”的关注超过了对“实现细节”的关注。

两人通过共同朋友Dan Robinson（Heap前CTO）相识，当时两人都在同一领域构建原型。从初次通话到Weiwei飞到San Francisco住Jeff沙发，再到决定联合创业，整个过程反映了早期创始人寻找合伙人的典型路径：技术兴趣重合、对问题有共同认知、愿意进行快速深入的磨合。

对话中关于“最困难的时刻”的分享尤为真实。Weiwei提到种子阶段招聘的挑战——在AI热潮中，大量初创公司争夺人才，候选人对初创公司的信任成本高。解决方案是“加倍投入招聘过程”，包括多次面试前沟通、独特的一日工作试验、以及团队反思和团建。这反映了一个核心信念：在快速变化的领域，团队文化是应对不确定性的核心资产。

Jeff则提到“适应变化”的挑战——如何在不断演进的AI工具和模型生态中保持方向清晰，同时不让团队陷入“追逐新工具”的陷阱。他的答案是“始终聚焦要解决的最终问题”，而非被新技术本身吸引。

十、未来展望：从代码验证到软件生产的全面重构对话的最后部分探讨了Momentic的长期愿景和行业影响。Jeff提出一个激进的观点：“未来3-6个月后，如果我还在审查TypeScript或React代码，我会感到失望。”这意味着代码审查作为一种人类活动，可能在未来几个季度内被AI主导或完全替代。但这不意味着工程师失业，而是工程师的工作内容从“审查代码细节”转向“定义规范”和“验证结果”。

Momentic的路线图反映了对这一趋势的判断。短期重点包括：移动端（Android/iOS）和桌面应用支持、进一步降低使用门槛、深度集成到开发工作流。长期愿景是成为“所有软件验证的标准层”，这包括：• 覆盖所有软件类型：Web、移动端、桌面应用、API• 与所有代码生成工具集成：Cursor、Claude Code、Codex等• 成为规范驱动的核心平台：人类定义规范，AI生成代码，Momentic验证结果

Jeff对竞争的态度极为直接：“我们不仅要赢，我们要摧毁所有竞争对手。”这种态度反映了对市场空间和自身技术优势的信心。他认为Momentic不是在竞争“测试工具市场”，而是在定义“验证层”这个全新类别。任何软件，无论现在还是未来，都需要验证。如果Momentic成为验证的标准基础设施，其市场空间将远超传统QA工具市场。

从宏观层面看，Momentic的愿景触及了AI时代知识工作的本质。当AI可以完成越来越多的“实现”工作时，人类的核心价值将转向“定义”和“验证”。这种分工在软件开发中率先体现，但可能很快扩展到其他领域。软件验证层，将成为AI时代的基础设施之一。

总结与展望Momentic的崛起标志着一个重要趋势：在AI代码生成能力飞速发展的今天，验证环节正在成为决定软件开发生产力的核心变量。从“测试工具”到“验证层”的定位转变，反映了对AI时代软件生产范式的深刻理解。当代码生成成本趋近于零时，验证成本成为新的约束条件。能够将验证成本降至接近于零的平台，将成为下一代软件开发基础设施。

展望未来，软件开发将经历以下重构：

1.工作流重构：开发流程从“编写–测试–修复”转变为“规范定义–自动生成–自动验证–反馈迭代”。人类工程师的时间将集中在规范定义和结果判断上。

2.工具栈融合：代码生成工具（Cursor等）、验证工具（Momentic等）、部署工具将深度集成，形成统一的AI驱动开发平台。MCP等协议将成为这一生态的连接标准。

3.角色重构：软件工程师的职责从“编写代码”转向“定义系统行为”。对技术细节的掌握仍然是基础，但核心价值将体现在产品直觉、系统思维和规范定义能力上。

4.质量观念转变：从“代码质量”（风格、结构）转向“行为质量”（功能正确性、用户体验）。验证层将成为质量保障的核心，而非代码审查。

5.市场格局演变：传统测试工具厂商（Selenium、Cypress、Playwright）将面临转型压力，而AI原生验证平台可能成为新的市场主导者。开源与商业化的平衡将决定最终格局。

对投资人和行业观察者而言，Momentic案例提供了几个关键洞见：在AI时代，基础设施层的投资机会不仅存在于基础模型（如OpenAI、Anthropic），还存在于填补模型与具体应用之间空白的“中间层”。验证层正是这种中间层的典型代表——它既不是模型本身，也不是最终应用，而是使模型能够安全、可靠地服务于应用的关键桥梁。

免责声明

本报告基于有关对话，不构成任何投资建议，亦不代表任何机构的正式立场。本报告仅用于研究与教育目的。