Z Potentials｜专访TestSprite创始人，前AWS&Google工程师，打造全球4万开发者的测试Agent

这两年，写代码这件事变了。GitHub Copilot、Cursor、Devin 一路登场，工程师开始习惯“打一段话，几千行代码自己长出来”。写得出东西，变得前所未有地容易。但很快大家发现，真正拖住上线节奏的，不再是「能不能写出来」，而是「敢不敢放上生产环境」——代码量指数级增长，验证、回归、极端场景覆盖反而被彻底压缩，测试成了 AI 时代新的“硬瓶颈”。

TestSprite 瞄准的，就是这一条被快速放大的断层：让 AI 不只负责写代码，还要负责“审代码”。它把测试这一步从「工程师下班前随手点两下」升级为「贯穿开发全链路的自动化基础设施」——既可以通过一个链接，自动帮你把线上产品“从头到尾撸一遍”，也可以通过 MCP 深度嵌入 Cursor、Trae 等 AI IDE，让 Testing Agent 和 Coding Agent 在幕后互相“过招”，自动生成测试计划、用例、代码、报告和自愈（auto-healing）修正，把验证这件事做成一个真正可编排、可复用的底层能力。

这套产品背后，是一对典型又不那么“典型”的技术创始人组合。CEO 焦云皓，从杭州竞赛少年，一路保送重点高中、考入浙大竺可桢学院，本科阶段在吴飞老师团队做 AI 研究，去密歇根大学交换、在梅俏竹老师团队发 NLP 论文，再到耶鲁读计算机硕士，最后进入 Amazon AWS CloudFormation 团队，在全球级云基础设施的一线做测试框架和开发，亲历“一行没被覆盖的代码拖垮全球客户”的事故现场，把对软件质量的认知刻进了职业 DNA。CTO 李睿，则是“跨学科玩家”：六年斩获四个学位的努力的天才，浙大光电＋工业设计起步，宾大计算机与数据科学收口，在 Google Cloud 做漏洞检测与自动修复（vulnerability patching），从安全视角盯系统稳定性，同样长期站在“怎么把线上问题变少”这条链路的核心位置。

也正因为这一路累积，TestSprite 从第一天起就长在工程师的工作流里：一端是复制网址就能直接开跑的 Web 测试入口；一端是与 Cursor、Trae 等工具深度打通的 MCP Server，让开发过程中的每一次改动，都可以被 Agent 自动拉通“生成 → 验证 →修复”的闭环。在客户侧，他们既服务年收入近千万美金、面向罕见病患者的医疗供应商 Princeton Pharmatech，也服务用 Lovable＋TestSprite＋Cursor 做出第一版产品的网站创业者，更覆盖了全球数万名 Vibe Coder、产品经理和个人开发者——从个人小项目到企业级应用，都在用这一套测试 Agent 把“能跑起来”升级为“跑得稳”。

更有意思的是，这家公司并没有把自己做成一个“只给大厂用的昂贵 QA 系统”，而是刻意走了一条 Z 世代开发者更买单的路：订阅价做到 Cursor 同一档，让还在做 side project 的个人、只有一两个工程师的初创团队，同样可以把测试当作基础设施来用，而不是“等有钱再说的奢侈品”。这些差异化，也让他们成功快速完成了融资额达670 万美元的种子轮融资，由位于华盛顿州贝尔维尤的Trilogy Equity Partners领投，Techstars、锦秋资本、MiraclePlus、Hat-trick Capital、BV百度风投和EdgeCase Capital Partners跟投。截至目前，该公司累计融资约810万美元。

也正因为两位创始人全程高能、金句频发，这次我们在整理访谈时几乎每一段都不舍得删——于是你现在看到的是一篇接近 2 万字的超长对话。诚邀你一起读完这篇内容量超标的访谈，走进一对硅谷早期华人创业者的脑内世界。

• 传统 testing 的效率瓶颈已经难以支撑现代软件的复杂度。软件质保的问题从根本上不是“工具不够”，而是“人力结构性不足”。这个领域需要的是一种能替代人力、并且不受时间精力限制的智能系统。

• 大模型应用于传统软件测试将带来结构性改变...AI Agent 能主动规划和执行任务的形态，让我意识到 SaaS 产品将被重新定义。

• 但从大厂出来创业之后完全不同。没有人帮你定义问题，也没人告诉你有哪些路径。你得自己先去判断“什么才是最值得解决的问题”，然后带着团队去解决它。这意味着我的角色从“问题的解决和执行者”变成了“问题的提出和定义者”。

• 我们希望用户不必关注AI背后具体做了哪些事，也不必一直盯着屏幕。理想状态是它像Auto-Pilot一样，在后台安静运行。等用户遛狗、慢跑回来，发现一切功能都正常了，这正是我们想实现的体验。

• 这也是现在很多AI coding应用型公司竞争的焦点：不仅是谁的模型更强，而是谁能提供更顺畅的交互体验...决定这一点的，其实是context engineering。

• Testsprite不仅是一个自动化测试工具，更是一个企业级测试管理、运行与维护平台。我们的目标，是让测试自动化从“工具”变成“生态”，让开发者和AI之间形成真正的闭环协作。

• TestSprite希望帮助开发者、创业者、学生，哪怕是没有技术背景的小白，都能把“做软件”这件事做得更好、更可靠。

01 竞赛保送少年，从耶鲁和宾大起步，在AWS与Google积累，在AI Native时代爆发

ZP：请您们从自己的成长经历谈起，包括教育背景、研究经历、到大厂工程师身份（如亚马逊）这一阶段。是什么让您走上“AI＋软件质保”这一技术路径？

CEO焦云皓：我是杭州人，从小所处的环境对计算机教育比较重视。中学时期我进入了计算机竞赛班，那几年出了不少后来在计算机和AI领域发展杰出的同学，比如现在Pika的CEO郭文景、后来去UCB的大神陈立杰。那段经历让我第一次系统接触计算机编程，并坚定了继续往技术方向深入的兴趣。

凭借竞赛经历，我被保送进入重点高中继续学习计算机，随后考入浙江大学计算机系，并在竺可桢学院跟随吴飞老师做 AI 方向研究。2015 年深度学习刚刚兴起，我在老师的指导下开始阅读LeCun的《Deep Learning》，正式进入了人工智能研究体系。

本科期间我曾赴密歇根大学安娜堡分校交换，在梅俏竹老师团队做 NLP 研究，并合作发表论文，这是我第一次产出真正影响产品体验的 AI 研究成果。那时我开始意识到：自己更希望做“被用户实际使用的产品”。

本科毕业后，我选择去耶鲁攻读计算机硕士，进一步扩展技术和创业视野。毕业后加入 Amazon AWS CloudFormation 团队，从事测试框架与开发者工具链的建设，深入理解了开发者在云平台、软件质保和测试体系中的真实痛点。

真正促使我们走向创业的转折，是 GPT-3.5 和 GPT-4 的发布。我和李睿当时都迅速意识到，大模型应用于传统软件测试将在未来带来结构性改变。那天我们讨论到深夜，并决定正式启动TestSprite的方向。

CTO李睿：我和云皓是浙大本科同学，本科我读光电和工业设计，研究生在宾大转向计算机与数据科学，路径看似跨界，但核心一直围绕“构建系统、解决问题”展开。

毕业后我加入 Google Cloud，主要负责漏洞检测与自动修复（vulnerability patching）。这项工作让我深刻理解开发者在质量保障中的痛点，也与云皓在 AWS 做测试框架的经验形成补充。我们都清楚看到：传统testing的效率瓶颈已经难以支撑现代软件的复杂度。

当时Cognition发布Devin，我也直观看到 AI 作为“软件构建主体”参与完整开发流程会变得越来越可行。AI Agent能主动规划和执行任务的形态，让我意识到 SaaS 产品将被重新定义。

这个判断与我们多年积累的开发者生态理解强烈共鸣。因此我们决定创业，用AI重塑软件质保流程，让测试从“人工密集的必做环节”演进为“智能化、自动化、可扩展的质量系统”。

ZP：在您们过去加入大厂期间，您遇到过哪些让您印象深刻的软件测试／质量保障痛点？这些经历是如何促使您创立TestSprite的？

CEO焦云皓：有的。在 Amazon AWS 时，我所在的 CloudFormation 团队Oncall压力非常大。每周都会收到来自全球用户的大量工单，必须及时响应和修复问题。虽然AWS的测试体系十分完备——单元测试、集成测试、前端UI测试、后端测试都覆盖，一个小功能往往需要维护上百个测试——但即便是在这样的体系下，问题仍然频繁发生，Rollback几乎成了常态。

其中有一次经历让我印象特别深刻。某天深夜Oncall，手机整晚不断报警，来自不同区域的客户都在汇报他们的 CloudFormation Stack崩溃。虽然问题不属于我负责的模块，但我仍需要立刻叫上相关工程师一起排查。由于系统庞大复杂，短时间内很难定位根本原因，我们最终只能先将整套系统回退到上一版本以止损，然后花了近一个月的时间才最终确认问题来源。

结果证明，事故的根因只是“一行代码在一个极端场景下没有被测试覆盖”。但这一行代码造成的连锁影响非常严重：包括摩根大通、迪士尼在内的一些客户系统都受到了影响。比如，迪士尼有部分过山车的运营系统当天直接停摆，因为票务调度系统依赖的资源在CloudFormation层面出现了异常。

最后公司不得不承担巨大损失，我并不知道确切数字，但内部传达的信息是“至少百万美元级别”。这次事件对我触动极大。它让我真正意识到：在现代软件体系里，一行未被覆盖的代码，就可能产生全球性的现实影响。

而更深层的原因也变得非常清晰：即便在亚马逊这种工程体系极其严谨的公司，人力依然无法彻底避免遗漏。测试本质上依赖工程师的时间和精力，而工程师的绩效指标往往聚焦于功能交付，而不是测试质量。久而久之，测试覆盖率不断下降，风险不断累积。

我也深知工程师的行为模式——如果写两个测试能交差，没人愿意花一天去写二十个测试。测试不是升职指标，但交付功能是。这导致了测试天然被弱化，变成了“必须做但永远做不够”的环节。

这些经历让我第一次意识到：软件质保的问题从根本上不是“工具不够”，而是“人力结构性不足”。这个领域需要的是一种能替代人力、并且不受时间精力限制的智能系统。

当 GPT-3.5 和 GPT-4 出现后，我立刻意识到 AI 可以补上这块长期存在的缺口，从根本上改变软件测试的方式。也正是这段在 AWS 的经历，让我在看到大模型能力后非常坚定地走向“AI + 软件质保”这条路径。

ZP：作为技术创始人兼CEO和CTO，从研究／工程师角色转向创业者角色，对您们而言最大的身份变化是什么？您们认为自己在哪些能力上必须提升？

CEO焦云皓：最大的转变，就是我要开始亲自面对客户，去理解他们的真实需求，去做市场上真正需要的工具，而不是闭门造车。我们得知道客户为什么会为某个功能付费，他们真正想解决的问题是什么，而不是我们自己想做什么。在这个过程中，对应的市场和产品的能力也就被培养上来了。

幸运的是，我的父母本身也是科技创业者，他们俩都是浙江大学的校友，父亲也是计算机系出身。从小在家里耳濡目染，我对创业、storytelling、市场营销都有一些潜意识的理解。虽然在学校里没有系统性的学习，但后来我通过各种渠道自学，比如看YC（Y Combinator）的tutorial、看Z Potentials上的创业分享、刷TikTok或小红书的创始人经验分享，这些都能让我们这些非科班出身的人员补足早期的基础商业能力。

当然，这些只是理论知识的补充。真正的实践是，我们后来同时加入了两个孵化器，美国的Techstars和国内的奇绩创坛。我发现每到一个新的阶段对我都会有不同的要求。其实刚开始很多事我们都不会，比如怎么融资、怎么跟投资人pitch、怎么讲产品、怎么谈估值等等，但这些都可以边学边做。我们发现，只要敢开口问、敢尝试，其实没有想象中那么可怕。而且网上有很多资源可参考，实在不行还可以问ChatGPT。

当然，startup和在北美大厂工作的节奏完全不同。很多事情没人教、也没有模板，必须自己摸索。我们过去两年也犯了不少错误，就是无论是管理、市场、还是产品方向。但还好我们的团队规模小，决策周期短，迭代速度很快。很多错误犯了当场就能改，这其实是startup的一大优势。而且在初创公司，试错不仅被容忍，反而被鼓励。这种文化让我们即使面对不确定，也不会焦虑。哪怕不懂，也能现学现用、边做边修。我们现在的心态也越来越稳了，所谓“兵来将挡，水来土掩”，一关关地过，反而越过越从容。

另外我想特别说一句，李睿是一个“学习专家”，就是学习能力超强的人，算是我们的秘密武器。他在六年时间内拿了四个学位，他的学习速度和理解能力真的非常强，很多新的领域他能在短时间内上手、拆解并应用到产品设计里。

CTO李睿：是的，我刚才提到过，我在短时间内确实学了很多不同领域的知识，光电、工业设计、计算机、数据科学，看起来跨度很大没什么联系，但每个学科都让我获得了不同的思维方式。它们共同的价值是让我在面对新问题时，能从多个角度、技能去协助我思考和解决很多问题。

我自己的兴趣是用自己的一套方法解决一个特定的问题，而在大厂工作时，我的角色更像是一个执行者。每天解决的问题都是别人定义和设计好的：在给定的一个框架内，上级告诉你目标是什么、方向是什么、方案有哪些，你只需要从中选择一个最合适的去执行，不需要思考，只要完成即可。

但从大厂出来创业之后完全不同。没有人帮你定义问题，也没人告诉你有哪些路径。你得自己先去判断“什么才是最值得解决的问题”，然后带着团队去解决它。这意味着我的角色从“问题的解决和执行者”变成了“问题的提出和定义者”。我需要思考的是：我们希望达成怎样的目标？要解决哪些痛点？为了实现这些目标，我们在产品、技术、资源上要做哪些准备？团队当前的能力缺口在哪？我需要怎样去引导大家达成共识？这其实是一种思维模式的根本转变。

以前只要动手“做对事”，现在则要学会“想对问题”。这让我在过去两年最大的成长，就是从一个优秀的执行者，变成一个能够设定方向、构建框架的人。同时，我也更深刻地体会到领导力不是发号施令，而是“如何帮助团队看清问题、聚焦目标、找到路径”。这也是我作为CTO在创业中最大的变化。

02 AI 生成代码成标配，TestSprite 把“验证”变成自动化基础设施

ZP：我们来聊一聊关于TestSprite的产品本身。能否请您先简单介绍一下TestSprite这个产品的主要功能？

CEO焦云皓：TestSprite其实是一个相对简单的工具，我们的目标是让它像Cursor一样，让所有人都能轻松上手。它设计得非常简洁易用，核心上有两种触发模式，也可以理解为两个入口。

第一种是网页端入口。如果用户要测试一个已经发布或上线的产品，比如阿里巴巴或亚马逊，只需要复制它们的网址链接，打开我们的官网，注册登录后点击“开始测试”，将网址贴进去就能测试了。基本上不需要额外准备任何东西。如果用户手里有应用文档、产品说明书或需求文档，也可以上传作为辅助材料，这能帮助我们的AI更好地理解产品。除此之外不需要任何其他步骤。接下来，AI会自动分析网站。我们的AI是一个全自动智能体（fully automated agent），它会像一个真实用户一样去操作网站、探索产品。

比如说测试淘宝网，AI会自动点击、浏览不同区域，分析页面结构、登录模块、搜索功能、推荐系统、购物车等，会花时间逐步了解整个产品。它还会阅读用户提供的文字材料或设计稿（如Figma文件），在理解完所有材料后生成一个“测试计划”（test plan），并据计划去构建多个测试用例（可能几十个，复杂网站甚至上百个，简单网站十几个）。

每个测试用例我们都会生成对应代码并运行测试，分析是否通过。如果不通过，系统会指出失败的原因、可能的bug，以及修复建议。最后AI会将所有结果汇总，生成完整测试报告。报告会列出通过与失败的测试项及改进方向，用户可直接看到修复路径。整个过程十几到二十分钟即可完成。我们常说，用户可以“解放双手”，去上厕所、喝咖啡，回来时测试报告已经生成。这就是我们的第一个使用场景。

第二种入口是针对那些尚未发布、仍在本地开发中的产品。很多初创公司在测试阶段并没有上线产品，因此我们设计了另一套机制，通过MCP（Model Context Protocol）实现相同的流程。

不同之处在于，我们的MCP可以直接安装在用户的Vibe Coding工具中，比如Cursor或国内常用的Trae。我们已经在Trae的MCP Marketplace中上线，用户只需点击启用即可。安装好TestSprite MCP后，只需几个简单的提示词，系统同样会自动生成测试计划、测试用例、测试代码、运行，最终给出分析报告。

由于我们嵌入了IDE环境，所以一个增益是还能帮助用户直接修复代码。比如我们已经知道有这五项测试不通过，AI会根据测试报告中识别的问题，将修复建议反馈回Cursor或Trae，并生成具体提示词，引导IDE自动生成一系列的修复方案，针对性地优化代码。这样用户不仅完成测试，还能自动修正bug。很多人体验时都觉得很神奇，半小时后软件就“自己修好了”。

我们希望用户不必关注AI背后具体做了哪些事，也不必一直盯着屏幕。理想状态是它像Auto-Pilot一样，在后台安静运行。等用户遛狗、慢跑回来，发现一切功能都正常了，这正是我们想实现的体验。

总体来说，TestSprite和市面上多数测试工具最大的区别在于：我们完全不需要用户编写测试代码，也不需要复杂配置。只需上传文档或安装插件，或者直接在我们的网页端注册并输入链接，就能够完成整个测试流程。对于企业或初创公司的客户，如果他们需要持续的测试管理或定期自动运行，我们也提供简单配置和auto-healing（自动恢复）功能。

ZP：随着AI代码生成工具越来越多被工程师采用，“验证”成为新的瓶颈。您能否从TestSprite视角讲讲如何看待这一趋势？

CEO焦云皓：确实如此。过去两年多，我们是亲眼见证了这个市场的巨大变化。两年多前Cursor还没有火，那时最流行的是GitHub Copilot。Cursor的几位创始人当初也是被GitHub Copilot深深吸引的。当时我们已经开始做TestSprite了，在向用户销售产品时，首先要说服他们相信未来用AI工具写代码是不可避免的趋势。可那时许多用户都坚决反对，他们觉得用AI写代码太不安全、不可靠，而且AI太笨，他们对AI不放心，认为不可能替代人工。

两年多以前我们非常难与客户达成共识，就是人工写代码会逐步被AI取代，或者至少部分被取代，但用户不接受。然而到2024年，情况彻底变了。现在你能看到Cursor、Windsurf、Devin等coding agent已经非常流行。这些工具在市场上帮我们做了非常好的“用户心智教育”。如果没有它们，TestSprite的销售会困难得多。

我们作为下游，就是工程师写完代码找我们做测试，而我们上游的这些代码工具，它们向开发者证明了一个事实：自动化（automation）已成为企业不可避免的现实。无论是中小企业还是大公司，自动化都在不断深入各个环节。比如Coding的自动化由Cursor、GitHub Copilot引领，市场营销自动化则由AI营销工具推动，整个行业的心态是变得更加开放。

但与此同时，工程师的日常工作也发生了很大变化。以前一个开发团队里，工程师的主要任务是写代码。老板或产品经理给出需求，写代码本身是一件很花时间的事，工程师可能要写一周才能完成。因为赶着deadline，他们常常把测试工作交给QA团队，然后紧接着进入下一阶段的开发，来确保整个项目是不会delay的。

而现在，Cursor把工程师的“写代码”这件事接管了，GitHub Copilot也一样。结果是工程师的职责彻底变了。在我们和用户、同行之间交流时，很多人现在都在问：那工程师每天在干嘛？我们发现，他们并没有因此少上班，甚至依然在加班。有人调侃他们在“划水”或者“装忙”，因为Cursor十分钟能写几千行代码，他们怎么还在工位上“肉搏”？但事实是，工程师的工作方式变了。现在的典型流程是：老板/产品经理提出需求→工程师用Cursor或其他工具生成代码→然后立刻进入校验（validation）阶段。

只是大家还没意识到，这个“校验过程”，其实本质上就是一种测试。大部分工程师现在做的“手动测试”，是让Cursor写完代码后运行程序，肉眼检查功能是否正常，自己点点看、玩一玩、输入数据看看程序的反应。但是这其实和传统的manual testing没区别。所以今天大量的程序员，实际上已经在做测试工程师过去做的事。在他们发现问题后，要么用自然语言（中文或英文）描述问题，提示Cursor修改代码，要么基于vibe coding给的草稿代码干脆自己上手修改，直到这个问题被解决。

很多人形容这过程像“我在和Cursor肉搏”，英文里他们叫“wrestling with Cursor”。网上甚至有段子：一个程序员让Cursor修一个bug，结果Cursor直接删掉了整个功能。因为它觉得删掉bug的那段代码就“没有bug了”。但显然这不行，程序员还得让它重新加回来。

现在程序员花大量时间在和AI工具反复沟通、prompt、调整同一个问题，比如“你没修好，再修一遍”；“又不对，再来一次”。这非常耗时、也让人心累。我们当时做MCP的初衷，就是希望让AI来和AI“博弈”。让机器去push、去压力另一台机器，而不是人类在中间生气。

此外，还有一个现实问题：今天的coding agent的能力越来越强，生成速度太快了。比如，一个AI十分钟就能生成几万行代码，到最后一步人工code review时，根本看不过来。这也是为什么近几年code review（代码审查）工具（比如CodeRabbit）这么火。因为没人能人工审完AI生成的大量代码。

还有一个关键点是，当前coding agent的准确率依然不高。虽然各大公司都在“卷”，但在公开的SWE数据集上，最好的模型（比如Claude 4.5）的准确率也只有70%，Claude 4大约67%。这意味着30%的代码仍然是错的。对于工程师来说，这几乎是不可接受的。因为只要有bug，整段代码就没有价值。所以现在工程师的工作变成了“找出那30%的错误”，要么手动修复，要么重新生成。

现在的工程师阵营里也出现了分化：有的坚持“古法编程”（手写代码），认为手动写并不比AI慢；另一派则拥抱vibe coding，认为用自然语言写代码更高效。甚至美国YouTuber MrBeast做过实验：让一群程序员不用Cursor，结果很多人居然完全写不出代码。这说明AI coding工具已经深度融入了开发者的工作方式，都是行业内正在发生的一些变化。

ZP：请CTO来分享一下TestSprite在“AI＋测试自动化”领域具备哪些护城河？例如其 Model Context Protocol (MCP) Server如何做到与AI编码代理协作、实时验证、反馈循环？ 

CTO李睿：从技术角度来看，我们的解决方案其实与Cursor的设计逻辑有一些相似。为什么可以用Cursor写任何代码，是因为它有两个关键指令是Command + K和Command + L。Command + L用于根据一个宽泛的描述自动生成代码，如果代码有问题，可以用Command + K让用户指定特定代码片段并修改它。这种循环交互机制让用户可以逐步refine代码，直到生成符合预期的版本。

我们在testing环节做的是类似的循环。TestSprite会先自动生成测试方案和测试代码，如果用户觉得某些部分不理想或需要调整，我们提供一种 “modify & refine” 的机制，让用户能重新定义目标或条件。AI会根据反馈重新生成测试内容。通过这种iterative循环，用户最终可以在TestSprite平台上构建出任何他们想要的testing workflow，无论是针对特定功能、平台，还是特殊场景的复杂测试，我们都能自动适配。

这套机制的核心价值在于灵活性与一致性：无论用户在测什么类型的产品，我们都能让测试的精度、结构和输出结果保持稳定，并快速满足客户需求。从更底层的角度说，这涉及到我们的一些“护城河”式的技术能力，比如测试代码生成的准确度、执行速度，以及整个AI应用层的workflow用户体验。

这也是现在很多AI coding应用型公司竞争的焦点：不仅是谁的模型更强，而是谁能提供更顺畅的交互体验。我们没有简单地走fine-tuning的路线。Fine-tuning主要提升模型在某一领域的知识掌握或偏好，但它不能决定模型在具体场景下“怎样才能产生最好的效果”。

决定这一点的，其实是context engineering。这与prompt engineering不同。Prompt engineering关注“我该怎么说”；而context engineering关注“我该喂给模型什么”。举个例子，就像你要让一个人帮你解决问题，你得告诉他任务背景、现有工具选择、实现目标、验证标准等等。对于AI也是一样，我们要定义一个正确的上下文环境（context），让模型能在合适的前提下启动工作。

TestSprite的很多效果提升，正是来自这种context engineering的经验积累。除了以上的生成逻辑外，我们在企业级功能（enterprise level）上也有一系列技术优势。比如我们提供auto-healing（自愈测试）功能。

这在大型系统里非常有用。举个例子：当开发者新增一个功能A，它可能在底层调用了一些你意料之外的组件B，结果导致功能B的测试失败。然后测试B发现，实际上B并不是坏掉了，只是调用方式或界面发生了变化。例如按钮位置移动了，或者响应路径调整了。在这种情况下，我们的系统不会简单地报告“测试失败”，而是能自动识别变化类型，并调整测试逻辑，确保验证仍然有效。

这就是我们所谓的auto-healing流程。除了自愈机制外，我们还在测试管理层面提供多种能力，比如测试生成后的版本管理与复用；历史测试的检测与回归；与第三方平台（如CI/CD系统或企业内部工具）的联动和深度集成的能力（integration）；还有我们最核心的测试代码的导入导出与统一管理。

通过这些功能，TestSprite不仅是一个自动化测试工具，更是一个企业级测试管理、运行与维护平台。我们的目标，是让测试自动化从“工具”变成“生态”，让开发者和AI之间形成真正的闭环协作。

03 从小网站到千万美金医疗客户，测试 Agent 跑通从想法到上线

ZP：能否分享一个典型案例，说明TestSprite帮助某团队／公司大幅提升测试效率、缩短上线周期、降低缺陷率？

CEO焦云皓：没问题。我觉得比较有意思的一个案例是我们身边的一个真实用户。那是我们一起健身时认识的一位健身教练。这个背景我补充一下，他其实是一个创业者，同时也是一位在美国开设个人工作室的健身教练，主要服务于一些大型科技公司的码农和工程师，提供一对一健身培训。我和李睿也在他那边训练过。他原本完全不会编程，也没有找到合适的软件，就一直用iPhone的备忘录来追踪客户的每日体重和训练计划。所有内容都是手动记录的，非常原始。

当时他还说自己没有更好的工具，所以只能这样手动记录。于是我就建议他试试看TestSprite，或者结合Trae、Cursor这样的Vibe Coding工具，看看能不能几天之内就把这些信息从备忘录迁移到一个简单的网站上。后来这个尝试的过程非常有意思，李睿可以具体讲讲。

CTO李睿：他后来就来找我们，想试着用AI Coding工具做出一个线上预约系统。虽然没有技术背景，但他很好奇，也想挑战自己。于是他用Lovable生成了一个初版界面，看上去差不多成型了，但他并不确定功能是否完整。

毕竟这是要让客户通过这个页面预约课程的，他自己既没有时间也没有UX经验，不知道最终是否能真正满足需求。

这时我们就建议他把这个项目接入TestSprite来测试。他照做之后，用我们的MCP功能跑了一轮测试。结果确实发现了几个问题，比如：他的网站中有一个管理员页面（Admin Panel），按理说应该被登录保护机制（Login Protected Route）限制访问，但因为逻辑设置问题，普通用户也能通过两次跳转进入。我们帮他捕捉到类似这样的问题有两三个。

他看了之后非常惊讶，因为自己完全没意识到这些漏洞的存在。后来Cursor还帮他修复了问题。最终系统运行得非常好，他也特别开心。这个案例对我们来说很有意义，因为这是一个发生在身边的真实案例，用我们的产品解决了问题，也让我们看到TestSprite在非技术用户群体中的价值。

CEO焦云皓：我想补充一点。李睿刚才分享的其实不是典型的企业级案例，而是一个我们发布MCP之后意外出现的个人级案例。我们原本的定位是传统B2B QA工具，主要服务企业客户，但我们发现越来越多Vibe Coder开始使用 TestSprite。

起初我们也很疑惑：这些Vibe Coders也需要测试工具吗？后来发现，他们中很多人其实不会编程，往往是产品经理、设计师或创业者。他们用AI工具生成代码，但当AI写出的代码出错、修复不了时，他们就完全被卡住了。这时他们要么只能找第三方测试工具帮忙捕捉和定位、修复问题，要么只能花钱请工程师来解决。于是TestSprite就成为他们的“救命稻草”，帮助他们系统化地捕捉并修复bug。

很多Vibe Coding工具用户其实并不了解背后的运行逻辑。他们只看到“一个网站被生成出来”，却不知道AI实际做了什么。所以一旦想修改某个功能，就会感到非常痛苦。当无法再用自然语言修复错误时，他们就会转而使用TestSprite，希望我们的系统能自动帮他们找出剩余的问题，甚至一次性解决掉，从而节省时间、提高效率。所以从这一角度看，我们也在为Vibe Coders群体提供了专业的AI测试支持。

从企业的角度来说，目前使用TestSprite的客户大部分还是企业级客户，类型很多。刚才提到的健身教练也算一个创业型business owner，而在企业端，我们的主流客户更多是科技公司。尤其是近两年，AI热潮带动了全球范围内的创业浪潮。湾区也好，国内也好，全球各地的初创公司都多了很多。无论是为了融资，还是为了快速上线产品，大家都在做开发。因为今天开发门槛的降低，使得任何一个小团队都能做出自己的应用。在这样的环境下，产品上线的难度大大降低，但竞争反而变得更激烈。

举个例子，Product Hunt是美国一个很火的产品发布平台。三四年前，每天在上面发布的新产品大概只有几十个，每天会评选一个“当日最佳”，所以大家都很重视。但今天的情况完全不同了。现在Product Hunt每天发布上百个新产品，竞争异常激烈，发产品的门槛越来越低。与此同时，抄袭、克隆、山寨也变得非常快，很多时候一个产品今天爆红，明天就会出现开源山寨版。在这样的环境里，“好点子”已经不值钱了，竞争的核心回到了质量和用户体验。

像我们一样的同类测试产品越来越多，功能上大家相似，界面也不是加分点，所以拼的就是：功能的准确度；上线速度；可靠性与稳定性；极端场景下是否会出错或宕机，让用户体验变差。测试的重要性因此被重新凸显。能否把软件产品质量做到极致，将成为初创公司能否在竞争中脱颖而出的关键。我们相信未来想在市场上占据一席之地的公司，必须重视质量控制，而质量把关离不开测试。TestSprite希望成为帮助这些公司跨过“质量门槛”的伙伴。

举个企业级的例子。旧金山这边有一家名为Jinix（原Princeton Pharmatech）的医疗供应商，他们是我们合作已久的客户。这家公司在旧金山已经做了很多年，年收入接近千万美金，原本主要专注于医疗与健康领域，并不擅长软件开发。

AI热潮兴起后，他们也希望推出自己的AI工具，用来帮助病人及合作医院。但是因为缺乏开发经验，他们很依赖Cursor这类Vibe Coding工具进行快速开发，因为就算招聘软件工程师也不懂得如何去管理他们。而我们这样的Vibe Testing工具对他们来说也非常有用，帮助他们在每次代码生成后进行自动化测试。他们的开发模式非常快。每当通过Vibe Coding工具生成代码后，就立刻用我们的系统测试，确认没问题后就上线Beta版本给部分病人试用。

他们的核心用户是罕见病患者，比如渐冻症群体。通过这样的快速开发和测试流程，他们能在一两周内把一个新功从管理层的一个概念变成可用的产品，推送给测试用户。用户反馈后，他们再立刻修改功能、重新测试、再次上线。这样一来，整个研发和上线的闭环非常高效。事实上，他们的迭代速度甚至超过一些专业的软件外包公司。

有时出现一种非常有趣的情况，就是他们的工程师开发进度太快，以至于老板还没来得及想好接下来的功能方向。我们遇到过几次这样的情况：所有既定功能都已实现上线，但新的需求还没被提出来。这说明，他们在我们的帮助下，第一次实现了“工程师比决策层更快”的开发节奏。对我们来说，这是一个非常积极的信号，也让我们坚信未来会有越来越多公司采用这种从想法到落地“一两周完成闭环”的高效开发模式。

如今我们常听到一句话：“Vibe coding一下很快。”但实际上，一个完整的流程不止于coding，还包括vibe testing、deploy、上线、市场验证、用户反馈。整个周期相比三五年前已经快了太多。我们希望TestSprite能在其中发挥关键作用，真正帮助更多人把一个想法在两周内变成能交付给用户的产品，而不是花两周时间还在和Cursor“博弈”代码是否能跑通。我们想帮助他们走完整个闭环，从构想到交付，真正实现“想法落地化”。

ZP： 能否请您再分享一下TestSprite在商业化和产品迭代上的具体进展？看到最近刚发布2.0版本，能具体讲讲当前的商业化情况和新版产品的亮点吗？

CEO焦云皓：我们目前的进展可以分为两部分来看。上一轮融资是在去年，完成了约150万美元的Pre-seed轮；今年又完成了新的Seed轮融资，累计融资额已超过800万美元。这笔资金大部分都投入到了产品研发上，因为我们是一家deep tech的Developer Tool公司。我们的客户是全球最挑剔的一群人，也就是开发者。要为他们做出一款真正好用的工具，难度是非常高的。

李睿刚才也提到了我们的护城河和差异化思考。很多人问我：“现在能做测试的工具已经很多了，比如ChatGPT也能帮你生成单元测试，那你们的独特之处是什么？”确实，市面上有不少工具能生成或管理测试用例，但我们要做的，是在自动化和商业化体验上做到极致，让用户使用时感觉：上手简单；Onboarding流程顺畅；价格足够亲民。

目前大多数测试类产品的定价区间在1000美金到几千美金。有些甚至按“单个测试”收费，一个或一次测试就要40美金。而我们采取了更轻量、更普惠的定价模式，像Cursor一样，按月订阅，每月19美金。价格低到有竞争对手反而向他们的客户推荐我们（笑）。比如有一位客户告诉我们，他们原本和另一家AI测试公司谈合作，但对方报价太高，对方干脆建议他们“可以试试TestSprite，他们的价格很便宜、效果也不错”。这种市场口碑式传播其实让我们在同类产品中脱颖而出。

我们在今年发布的2.0版本（MCP版本） 是一个重要节点。它让开发者可以直接在Cursor、Trae等主流AI编程工具中一键调用TestSprite。这一功能极大提升了使用便捷性，也让我们的用户量出现了爆发式增长：三四个月前，我们的注册用户大约只有5000个，而现在已经接近4万，几乎增长了十倍。这波增长基本上都发生在过去几个月里。

回顾最初的一年，其实我们走得很艰难。要打磨出一款真正被开发者认可的工具，需要非常长的前期准备。我们花了大量时间理解用户需求、优化产品细节。但一旦产品体验到位，市场反馈就非常迅速。现在我们的用户评价也越来越正向和积极。有时我们在Intercom（在线客服系统）上会收到一些让人很感动的反馈，比如有用户不是来报bug，也不是提功能需求，而是专门写长文来感谢我们团队。我记得有一天我第一个看到这样一封“感谢信”，感到非常感动，我立刻转发给李瑞和整个团队。那位用户甚至花了十分钟时间，只为表达“谢谢你们做出这样好用的工具”。对我们来说，那一刻就代表成功。我们希望未来有更多这样的时刻。

在衡量公司是否成功时，我们并不只看融资额、用户量或市场份额。我们更关注的是每一个用户是否用得开心、真正能被帮助到。我们定价低、功能强，就是希望让更多人能承担得起测试。过去很多初创公司不用测试，其中一个重要原因是太贵了。这是一项传统上被认为“只有有钱公司才能负担”的服务。过去三五年，即使不雇人，只用SaaS工具，也要很高的成本。通常只有完成A轮融资、大的种子轮之后或资金充裕的公司才会考虑测试。

而我们想改变这个现状：哪怕你只有一个人，也能测。如今做软件变得这么容易，那为什么不做一个“好”的软件？我们相信“能做软件”和“能做出好软件”是两件事。在竞争如此激烈、用户选择如此多的时代，只有质量好的产品才能留下来。虽然还有很长的路要走，但是TestSprite希望帮助开发者、创业者、学生，哪怕是没有技术背景的小白，都能把“做软件”这件事做得更好、更可靠。

所以我们决定在相当长一段时间内不提高定价。无论竞争对手怎么看，我们都希望TestSprite成为市场上最亲民、最普惠的测试工具。就像Cursor一样，把“人人可用”的理念做到极致。我们的目标不仅是让中大型企业能用上 TestSprite，也让早期创业团队、小公司、甚至个人开发者都能负担得起。我们常说，我们服务的对象是从SMB（中小企业）到SME（成长型企业），甚至包括一个在做副业产品的个人创作者和开发者，或者写课程项目的学生。

当然，从市场角度来看，目前我们的主要客户仍然以中小企业为主。未来我们会在两端同时探索：一方面继续开发更多企业级功能，满足大客户在数据安全、集成、权限管理等方面的大量需求，提高我们产品的上限；另一方面，也要保持产品的简洁和易用，让没有任何技术背景的用户也能顺畅使用。我们不希望TestSprite变得复杂，而是要让它既能服务大公司，也能服务个人开发者，兼顾两端，这也是我们从创立以来始终坚持的初心。

本质上，我们希望做成“测试领域的Cursor”。就像Cursor今天既被工程师使用，也被学习编程的新手使用一样，我们希望TestSprite也能让不同层级的用户都从中受益。虽然Lovable这类工具对零基础用户更友好，但Cursor同样吸引了大量正在学习编程、或具备部分技术背景的用户。我们认为这正是它的成功之处：它既能服务专业开发者，也能帮助入门者。

亚马逊最近刚刚购买了Cursor的企业版License。虽然他们自己也有内部的代码工具，但仍然选择采购Cursor的授权来推广内部使用。这说明即使是顶级科技公司，也认可这类AI编程工具的价值。其实亚马逊的员工早就在非正式地使用Cursor，只是最近公司正式购入了企业版License，从组织层面上鼓励大家使用。

我们也认为这是一件非常积极的事情。一方面，Cursor与我们并不存在竞争关系，它主要聚焦在AI代码生成，而我们聚焦在AI测试自动化。另一方面，他们比我们早大概一到两年启动，所以某种意义上也成为我们很好的学习样本。更巧的是，我们公司的融资节奏和产品迭代节奏，与Cursor发展路径非常契合。两年前，Cursor融了大约800万美元的种子轮；去年（2024年）他们又完成了6000万美元的A轮融资，由a16z领投。从用户增长来看，他们在2023年时大概也只有几万个用户，到年底就突破了十万。

这个阶段性的增长曲线和我们现在的状态非常相似。我们也发现，这种“巧合”可能是因为我们服务的用户群体非常接近，都是AI开发者和Vibe Coders。这让我们在产品方向、市场节奏、用户增长上都有相似的路径可参考。

所以我们经常说，Cursor是我们非常尊敬、也持续学习的一个对象。他们证明了一个理念：当开发门槛降低，创造者会成倍增加；而当创造变得容易，测试与质量就成为新的刚需。

04 全球化团队重塑工程师角色，用 Agent 解决全球企业的代码质量短板

ZP：面向中国市场：您认为中国工程师／产品经理群体在软件测试／AI生成代码验证上面临哪些特定挑战？TestSprite如何定位以服务这类客户？

CEO焦云皓：我们的团队主要成员中，主要我和李睿是中国人，其他成员的招聘都在美国西雅图，所以团队的多元性很高。美国本地的开发者、市场人员都在我们的团队中，当然也有不少华人。公司从Day One就注册在美国特拉华州，从技术层面上讲是从美国起步，再向全球拓展的。

选择欧美市场作为切入点有几个原因。首先是劳动力成本，美国和欧洲这几年通货膨胀严重，人力成本不断上升。传统的软件测试仍然依赖大量人力，开发工作也是如此。虽然市面上有很多像Cursor这样的工具，但这些工具的出现并没有让工程师的工资降低，招聘成本依然在增加。因此，我们当时从欧美市场出发的最大动机，是希望帮助企业更好地利用工程师资源，让他们的效率更高。

中国和印度等亚洲地区也有非常优秀的工程师，但相对来说人力成本会便宜一些。不过这并不意味着这些市场不重要，它们仍然是非常好的市场。比如Cursor在印度和中国都有很高的占有率，我们现在也有相当一部分用户来自中国和印度。

但是即便中国人力成本相对低，仅靠人工做测试也是不现实的。像回归测试、并发测试这类场景，一秒钟可能要执行上千次甚至上万次，这些必须依靠程序实现，人工测试无法覆盖。所以仅靠人力去补足测试缺口是不可行的，还是要依赖工具和自动化手段。

目前国内最大的挑战之一是模型层面的问题。有些模型不够通用，也有不便之处。另一个挑战是语言差异。很多中国工程师习惯用中文写提示词，但大多数主流模型是基于英文数据训练的，对中文prompt的理解效果相对差一些。如果能用英文写prompt，效果会更好。所以总体来说，这些挑战不是根本性的阻碍，更多是一些细节层面的摩擦。

此外，国内工程师在英文表达上可能没有那么自然，这会影响他们在写prompt时的清晰度，从而使得代码工具如Cursor或TestSprite在效果上略打折扣。但我认为这不是大的阻碍。因为在产品集成方面，我们现在和国内的生态也打通得不错。例如在Trae的marketplace中，TestSprite已经可以直接加载使用，用户只需点击加载、填写API key即可。

从全球范围来看，除了中国市场，我们现在在全世界几乎每个大洲都有用户。前段时间我们看公司内部数据图，除了格陵兰岛没有人居住的岛屿外，几乎所有地区都有TestSprite的用户。我们几万个用户分布在世界各地，主要集中在美国、加拿大、法国、德国、意大利等国家。

ZP：人才招募视角：对于希望加入TestSprite的工程师和产品经理，您期待他们拥有哪些背景／能力？公司在团队文化、全球化协作、技术成长路径方面提供怎样的机会？

CTO李睿：我们现在偏向寻找有AI agent系统开发经验的工程师。不过，比经验更重要的是快速学习的能力。虽然AI时代已经发展了两三年，但对于一个新技术平台来说，这仍是非常短的时间。一切都在快速变化，新的思维方式和范式不断出现，很多旧有的做法被打破，新的能力又被创造出来。

因此，我们会更看重候选人对新环境的适应能力，以及主动思考、主动学习的能力。这类人能够快速理解变化，并在新环境中找到方向，这是我们非常看重的特质。

ZP：如果用一句话描述您本人和TestSprite当前阶段最核心的使命，您会怎么说？

CEO焦云皓：一句话来形容的话，那就是我们希望让用户对AI生成的代码有信心，放心地将它上线并交付给最终用户。现在很多人对AI生成的代码仍然存疑，他们不知道这些代码是否可靠、安全。因此他们需要一个第三方的验证机制，让他们获得信心。

我们的使命就是提供这种信心层面的支撑，告诉用户不用害怕，我们已经帮你验证过代码，可以上线问题不大。如果真的有问题，那是我们没捕捉到或测试量还不够，我们可以继续补充。我们要让用户不再对AI生成的代码充满恐惧或怀疑、不信任，这就是我们的核心使命。

ZP：现在很多工程师和产品经理因为AI正在逐渐取代他们的部分工作而感到焦虑。您认为，面对“AI-生成代码”的崛起，工程师与产品经理应该具备哪些关键能力？

CEO焦云皓：我理解这种焦虑，但我们在过去的招聘过程中发现一个很有意思的现象。虽然AI的发展很快，但我们对人才的需求并没有减少。我们最近刚完成融资，仍然在持续扩张团队。我们依然非常需要工程师、产品经理、设计师，以及前后端的开发人员。原因很简单，那就是对高水平工程师或顶级人才的需求一直存在，AI并没有替代他们，我们需要的也不只是AI能写几行代码的能力。

以我在亚马逊的经验为例，解决一个问题通常分四个步骤。第一步，产品经理或上层管理提出需求，这个需求可能来自用户反馈，也可能是管理层基于市场分析得出的。第二步，工程师需要做一个high-level design，也就是高层设计，确定解决问题的大致方向，要用哪些工具、平台或算法。这个阶段是一个概念性的设计。第三步，在高层设计达成共识后，工程师再做low-level design，也就是更具体的实现方案，包括要写哪些函数、哪些模块、每个模块要实现什么功能等。最后一步，才是交给初级工程师去实现，或者现在可以交给像Cursor、Claude Code这样的工具去执行代码实现。

从这个流程可以看出，写代码其实是最后一步，并不是最关键的一步。最重要的是前期的思考与设计，也就是对需求的准确把握和解决方案的规划。无论是在大公司还是初创企业，最怕的就是浪费时间，比如花了几个月做出一个没人用的功能，这种错误在当下快节奏的市场环境里是致命的。因此，产品经理最核心的能力始终是：能否迅速抓住用户真正需要的、最有价值的需求。

从工程师的角度来看，提出解决方案的能力同样至关重要。正如李睿刚刚提到的，AI可以帮助实现方案，但人仍然需要去提出方案。比如我们选择哪种架构、哪种算法，这些都是工程师必须去判断的。一般来说，同一个问题往往有多个解决方案，每种方案都有优缺点，工程师的职责是权衡这些利弊，做出最合理的选择。这是高级工程师的重要价值所在。

对于初级工程师来说，重点则在于如何做好low-level design，即把既定架构细化成可执行的模块和逻辑。同时，他们需要学会使用好各种工具，比如Cursor怎么用、怎么写规则、如何写有效的提示词、怎样进行context engineering等。这些技能在当下仍然重要，但我认为从长远来看，它们不是最核心的能力。也许两三年后，AI自己就能理解需求，不再需要人类编写复杂的提示词。

最后，我想强调一个常被忽视但非常关键的能力，那就是沟通。无论是和同事还是客户，很多问题的解决都依赖于沟通。如何清晰表达你的想法，如何协调团队意见，如何说明你需要什么支持，这些都是落地的关键。我们在招聘时会非常看重候选人的沟通能力、问题解决能力以及提出方案的能力。

ZP：您觉得相比美国公司，中国公司的主要挑战是什么？

CEO焦云皓：这个问题我刚才其实想到一个挺明显的差别，就是中国公司相比美国公司，在自动化程度上略有不足。过去中国劳动力资源丰富且相对便宜，所以很多企业宁愿多招人，也不太重视自动化系统的建设。比如在美国，几乎每家公司都有一套完善的GitHub CI/CD流程，但在国内，很多公司要么没有完整的pipeline，要么只搭建了其中一部分。

我们观察到，这正是国内企业当前的一个短板。很多公司还没有把自动化体系完全搭建起来。过去他们可能觉得“我招个人干这件事”和“我去搞自动化工具”成本差不多，但现在情况变了，那就是人越来越贵，工具越来越便宜。这个平衡点正在被打破。

所以我们现在经常在和国内客户交流时，建议他们第一步就是先把自己的pipeline搭建起来，把自动化系统建立起来。其实这并不难，可能只是把几个AI工具拼在一起，或者装一个插件到Cursor里，十几分钟就能搞定。这一点对中国公司未来的效率提升非常关键。

文章来自于“Z Potentials”，作者“Z Potentials”。