撰文：Techub News 整理
在 Y Combinator 的最新访谈中，AI 软件测试平台 Mnemonic 的两位联合创始人 Weiwei 和 Jeff 分享了他们2026 年 3 月完成 5000 万美元 A 轮融资后的思考。在 AI 编程工具（如 Cursor、Claude Code）极大提升代码产出速度的今天，他们指出，软件开发的瓶颈已从「编写」转向「验证」。这场对话深入探讨了 AI 时代软件工程范式的根本性转变，以及 Mnemonic 作为「验证层」所扮演的关键角色。
从「代码即真理」到「真相驱动开发」
当被问及工程师为何历来厌恶编写测试时，Jeff 结合其在 Robinhood 的经历给出了直白的答案：测试工作缺乏「可见性」。它既不是客户能直接感知的功能，也难以在闪亮的演示中展示，更少直接体现在绩效考核中。因此，测试往往被视为一种拖累和次要工作。然而，随着 AI 编码工具使代码产出呈指数级增长，如何验证这些代码的正确性，成为了比编写代码本身更严峻的挑战。
Weiwei 和 Jeff 观察到，传统的代码审查（Code Review）和静态分析（Linting）工具，虽然能检查代码风格和模式，但无法回答一个根本问题：当这段代码部署到生产环境后，它真的能按预期工作吗？ 目前，许多团队仍然依赖人工在发布前进行「Bug Bash」（缺陷大扫除）——手动登录、点击、操作，这种方式在产品和团队规模扩大时完全不可扩展。
Mnemonic 所做的，正是填补这一关键空白：功能性测试。其平台模拟真实用户行为，在浏览器中自动运行，遍历应用程序的各个用户流程，确保从最终用户视角看，一切功能正常。每当工程师提交代码变更，Mnemonic 就会自动验证这些变更是否破坏了任何既定的用户流程。
这引出了一个更具前瞻性的观点：真相驱动开发。Jeff 阐述了两种思维模式：一种是「代码即真理」，即生产环境中的代码就是产品行为的最终定义；另一种则是「真相（或规格）驱动开发」。在后一种模式中，产品经理或工程师（通常与 AI 协作）详细定义的用户旅程、成功标准和边缘用例，构成了产品应如何工作的「唯一真相源」。代码，无论是由人类还是 AI 编写，都只是这个「真相」的一种实现方式，并且可能存在错误。
「既然工程师会犯错，AI 也会犯错，」Jeff 说，「让代码库本身作为产品应如何工作的真相源，这本身就不合理。」他们的核心论断是：在 AI 编程时代，代码正逐渐「商品化」。未来，工程师的核心工作将不再是编写或审查 TypeScript、React 代码，而是用自然语言撰写详细的产品规格（Spec），然后交由 AI 智能体去实现。工程师将转型为「需求收集者」和「真相发现者」，专注于决定「应该构建什么」，而代码只是实现这一目标的、可随时被更好模型替换的「实现细节」。
AI 编程智能体需要独立的「验证层」
随着 Claude Code、Cursor 等 AI 编程助手日益普及，一个自然的问题是：为什么不让这些智能体自己编写测试？Mnemonic 的创始人从几个层面给出了解释。
首先，可靠性问题。AI 智能体常常自信地认为其生成的代码是正确的，但事实可能并非如此。用户无法完全信任智能体自己的判断，需要一个独立的第三方来验证其产出是否符合规格。这就像传统开发中，开发者不会仅凭自己说代码没问题就部署，而是需要单元测试、集成测试等外部验证。
其次，复杂交互的测试能力。许多现代 Web 应用拥有极其复杂的交互界面，如富文本编辑器、拖放画布等。通用的 AI 浏览器代理并未针对此类复杂场景的测试进行优化，而 Mnemonic 则专门训练了其智能体来处理这些难题。
再者，速度与可调试性。使用通用的 AI 浏览器代理进行测试非常缓慢，且当测试失败时，很难诊断问题所在——是哪个元素未被正确交互？页面当时处于什么状态？Mnemonic 将平均操作步骤时间优化到 300 毫秒以内，并围绕可调试性构建了整个平台，其智能体能够自动诊断问题。
最后，也是至关重要的一点：「真相」的持续维护。即使今天让 Cursor 生成了 10 万行 Playwright 测试代码，明天当产品功能发生重大变更时，谁来更新这 10 万行代码？Mnemonic 的解决方案是将整个测试系统封装起来，构建了一个能够自动随时间维护这份「真相源」的机制。其系统甚至可以主动建议更新测试——例如，当发现 UI 中新增了一个组件时，会询问这是否是预期改动，并可以自动更新相关测试，而无需用户消耗大量 Token 或会话去手动调整。
「我们本质上为 AI 编程智能体『闭环』了反馈循环，」Weiwei 总结道。规格（Spec）定义了要构建什么以及如何验证，而 Mnemonic 则确保 AI 智能体的输出符合这个规格。
客户实践与文化构建
Mnemonic 的客户名单包括 Notion、Built、Quora 等知名公司，日处理测试运行超过百万次。与 Notion 的合作始于一个有趣的契机：Notion 的工程师 Simon Last 在 Twitter 上发帖，希望能简单地描述一个功能并自动测试。众多网友在回复中推荐了 Mnemonic。当时身在旧金山的 Weiwei 在晚上 10 点直接私信 Simon，并录制了一段在自己 Notion 工作区进行测试的演示视频，当晚就完成了初步接入。
Notion 之前的测试方案混合了人工测试和庞大的 Selenium 自动化测试套件。Selenium 因其脆弱性（如依赖易变的 XPath 或选择器）而闻名，维护成本高昂，尤其对于 Notion 这样拥有灵活富文本编辑器、一切皆数据库的复杂产品来说，挑战巨大。Mnemonic 通过简单的自然语言指令，便能处理这些复杂场景。如今，Notion 每天执行近 50 万次 Mnemonic 测试，并且工程师的代码合并请求必须通过 Mnemonic 测试才能被批准。
在衡量价值时，Mnemonic 认为最直接的 ROI 是节省的工程师时间（尤其是对比 Selenium、Cypress 等传统工具）。但其真正的「北极星」指标是：预防了多少可能影响最终用户的回归错误或严重事故。测试的终极目的正是保障产品质量和可靠性。
作为一家快速成长的初创公司（团队仅 13 人），Mnemonic 非常注重早期文化的塑造。Jeff 将其文化概括为「坦诚相待」——直接、清晰的反馈，同时尊重同事。他们希望每个人都能发出自己的声音，所有人都能参与产品路线图的讨论。在人才招聘上，尽管身处 AI 热潮中，他们依然相信优秀工程师的本质未变：适应性、在模糊性中导航的能力、好奇心与热情。AI 工具只会让本就优秀的工程师如虎添翼。
两位创始人的背景也颇为有趣：Weiwei 高中毕业后原本计划成为一名药剂师，但在参加了一次药学夏令营后觉得无比枯燥，遂在大学转为计算机科学专业。Jeff 则原本计划在剑桥攻读化学，但意识到日复一日的实验室工作虽然解决着世界级难题，却缺乏与人协作、打造产品的挑战，从而转向科技创业。他们于 2023 年底通过一位共同朋友介绍相识，在 Jeff 的沙发上同住一周深入探讨后，决定联手创立 Mnemonic。
未来展望与创始人心态
对于未来路线图，Mnemonic 的关注点反而在收窄。他们亲眼目睹了工程师工作流的快速演变，因此今年的重点将放在极致优化开发者体验和生产力上，目标是让使用门槛降至零甚至为负，让工程师「跌入成功的陷阱」。具体的技术扩展包括对 Android、iOS 和桌面应用程序的测试支持。
回顾创业历程，早期招聘是最大的挑战之一。在 AI 初创公司如雨后春笋般涌现、而大型基础模型公司又极具吸引力的环境下，说服顶尖人才加入需要加倍努力。他们优化了面试流程，甚至引入了独特的「一日工作试用」环节，并高度重视团队入职后的文化建设，如深度复盘、讨论和团队 retreat。
对于工程师出身的创始人，学习销售是一项关键技能。Jeff 的体会是：「你必须亲自去做。」他认为销售能力无法仅通过观察他人学会，每个人都有自己的沟通和销售方式，必须通过大量实践（积累「经验值」）来学习和进化。
是什么驱动他们持续攻克「代码验证」这一难题？Weiwei 从效用角度出发，认为当前产品开发和功能迭代的速度，很大程度上受限于代码验证的速度。解决这个根本性问题，有望带来全球性的生产力提升。Jeff 的动机则混合了雄心与市场洞察：软件测试（QA）是一个巨大的市场，但 Mnemonic 的愿景更宏大——目标是成为所有现在及未来软件验证的基石。「我们不仅要赢，」他直言不讳地补充道，「还要消灭所有竞争对手。这是必然会发生的事。」
在 AI 重塑软件开发流程的十字路口，Mnemonic 的定位清晰而坚定：当代码的生成变得越来越廉价和自动化时，确保代码正确反映人类意图的「验证层」，其价值将愈发凸显。这不仅是工具的更迭，更是一场关于软件工程核心价值转移的深刻变革。
