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

Z Potentials｜专访TestSprite创始人，前AWS&Google工程师，打造全球4万开发者的测试Agent Z Potentials｜专访TestSprite创始人，前AWS&Google工程师，打造全球4万开发者的测试Agent Modified November 25, 2025 No access 0bc35ebssaadyiaai3q72zuvh2odfhuqgkia.f10002 (1) 00:00 很多人形容这过程像 “ 我在和 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 如何定位以服务这类客户？ No access 0bc35ebssaadyiaai3q72zuvh2odfhuqgkia.f10002 (1) 00:00 No access 0bc35ebssaadyiaai3q72zuvh2odfhuqgkia.f10002 (1) 00:00 很多人形容这过程像 “ 我在和 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 公司。我们的客户是