Prince Kohli，Sauce Labs 总裁兼首席执行官 – 访谈系列

Prince Kohli，Sauce Labs 的总裁兼首席执行官，是一位拥有丰富经验的技术高管，涉猎人工智能、企业软件、云计算、自动化、网络和网络安全等领域。在 2025 年 2 月加入 Sauce Labs 之前，他在 Automation Anywhere 担任首席技术官超过六年，推动了面向大型企业的 AI 驱动自动化技术。此前，Kohli 曾担任 ThoughtSpot 的高级副总裁（工程），并在 Ericsson 担任高级领导职务，负责管理包括 10,000 多名工程师的全球研发组织。他还在 Citrix 工作近十年，领导平台、云网络、工程和运营项目。早期职业生涯中，他共同创立了应用安全公司 Teros，并在 SGI 担任技术负责人。除了高管职责外，Kohli 还通过 Ethical AI Governance Group 参与技术治理工作，并曾参加世界经济论坛的安全系统与技术工作组。

Sauce Labs 是一家软件质量与持续测试公司，为企业提供跨浏览器、操作系统、虚拟环境和真实设备的 Web 与移动应用测试基础设施和工具。其平台支持自动化与手动测试、视觉测试、移动应用分发、错误报告以及 AI 驱动的测试编写与分析，并可与常见的持续集成与交付工作流集成。Sauce Labs 正在围绕 AURA（AI‑Unified Release Assurance）平台进行技术布局，利用 AI 代理帮助生成、执行和分析测试，同时在整个软件发布过程中保持人工监督。公司称其基础设施已支持超过 87 亿次测试执行，拥有超过 30 万企业用户，基于近二十年的跨平台测试数据。

在 加入 Sauce Labs 之前，您在 Automation Anywhere 负责 AI 驱动的自动化，并在 Ericsson 和 Citrix 等公司管理大型云和工程组织。这些经历如何塑造了您对软件质量问题的看法？是什么让您决定将 AI 原生的发布保障作为 Sauce Labs 的核心优先事项？

在 Ericsson 和 Citrix，我看到软件缺陷可以迅速蔓延并影响全球基础设施，导致安全、客户运营、信任和收入方面的重大冲击。Automation Anywhere 让我认识到 AI 正在改变工作速度和结构，测试必须为 AI 生成的软件的节奏重新构建。Sauce Labs 率先实现了测试自动化，AI 原生的发布保障是我们下一步要解决的重大问题。

Sauce Labs 的 研究 发现，80% 的组织将生产事故、宕机或影响客户的缺陷追溯到 AI 生成的代码。这主要是因为 AI 生成的代码本身存在弱点，还是因为企业在采用 AI 编码工具时未同步更新测试和治理流程？

80% 的数据指向整个软件交付体系存在问题。AI 行业吸引了超过一万亿美元的私募资本，很多投资假设 AI 能显著提升业务生产力。但仅生成更多代码并不能创造价值，除非企业能够在代码投入生产前确信其质量和安全性。

AI 生成的代码可能引入细微的缺陷和安全风险，企业被迫将这些代码推入已经难以跟上节奏的测试和治理流程。这导致了万亿美元级的执行难题：AI 能加速软件创建，但如果没有现代化的发布保障，同样会加速缺陷的出现。每一个缺陷最终都会被发现，企业必须在客户或攻击者之前捕获它们。

报告指出，开发者的代码产出增长了 741%，而发布速度仅提升不到 20%。是什么阻碍了验证系统跟上节奏？在软件开发生命周期中，最大的瓶颈通常出现在何处？

代码生成远远超前于测试的创建、维护和分析。最大的瓶颈通常出现在代码编写完成后，需要在用户旅程的上下文中进行验证。这往往非常复杂，甚至比代码本身更复杂，因为必须考虑跨代码函数和对象的端到端路径，微小的语义变化可能导致巨大的下游影响。以能够完整捕捉应用意图的方式编写测试传统上几乎是不可能的，而且需要大量手工工作和维护。此外，测试运行失败后，团队必须理解并诊断问题，判断是产品本身出错还是测试过时。这仍然高度依赖人工审查和工程上下文。

超过半数受访企业承认会有意发布带有关键缺陷的软件，66% 的企业表示为赶期限而妥协了质量或测试标准。为什么组织会接受如此高的风险？要让软件质量上升为业务层面的优先事项，而不是最终的工程检查点，需要哪些改变？

组织接受风险是因为发布目标直接关联到客户、收入和产品承诺，缺陷成本往往在后期才在多个团队间显现。只有当领导层将生产事故、客户影响、安全暴露、返工成本和收入延迟等指标与发布速度一起衡量时，质量才会成为业务优先事项。

Sauce Labs 正将 AURA 定位为一个闭环平台，能够编写、执行并分析测试，同时从每次发布中学习。它在技术和运营层面上与 AI 辅助的测试生成、自愈测试脚本或其他工程团队已使用的自动化工具有何区别？

大多数 AI 测试工具只解决单一任务，例如生成测试或修复破损的定位器。AURA 通过理解应用意图、编写并执行测试、分析失败并将生产行为反馈给开发，连接了完整的流程。它能够自动处理大量变更，并在应用意义或预期行为改变时让人工介入。此外，AURA 生成的测试具有稳定性，即在不影响语义的应用、浏览器、设备等变化时无需修改。最后，AURA 内置测试执行云，可将整个过程从开发者或质量工程团队中卸载。

AURA 旨在依据“业务意图”验证软件。该意图如何定义并转化为可测试的需求？谁负责批准？平台如何处理模糊、不完整或可解释性强的需求？

业务意图来源于产品需求、验收标准、业务规则、用户旅程以及客户实际使用方式。产品负责人定义预期结果，工程和质量团队将该结果转化为系统可验证的行为。当需求不完整或模糊时，AURA 会显式标示不确定性，并在更改预期结果前请求人工批准。

Sauce Labs 报告称，使用 AURA 的企业生产事故减少了 90%，发布周期加快了 47%，工程产能回收了 38%。这些结果是如何衡量的？覆盖了多长的部署周期？采用了何种独立验证来区分 AURA 的影响与其他组织或工程变更？

在企业级部署中，我们在团队实施 AURA 后测量了生产事故、发布周期速度和工程产能的变化。这些部署显示生产事故下降超过 90%，发布周期加快 47%，工程产能回收 38%，并已通过独立方式验证。Walmart、Keller Williams 等客户也报告了发布频率、测试覆盖率和周期时间的显著提升。

研究发现，尽管事故仍在上升，64% 的组织仍增加了质量保证人员。为什么仅靠招聘更多测试人员无法解决验证缺口？随着测试变得更自动化，您预期开发人员、质量工程师和站点可靠性团队的职责将如何变化？

AI 可以以远快于测试人员增长的速度提升代码量，增加人手也会带来更多交接和协作成本。开发人员需要更清晰地定义意图，质量工程师将更多关注风险、覆盖率和治理，站点可靠性团队则把生产行为反馈到发布流程。代理可以在新开发模型所需的规模上处理重复的执行和分析任务。

随着 AI 代理承担起编写、运行和解释测试的职责，人类在哪些方面必须保留决策权？哪些不确定性、安全风险或潜在的客户影响应自动阻止发布或触发人工审查？

在人类判断、客户影响或业务风险涉及时，最终的发布决策必须由人类保留。AI 代理可以自动化繁琐、可重复且定义明确的测试任务，但当代码或测试结果无法被完全理解、解释或复现时，必须由人工批准生产发布。当需求不明确、可能存在安全漏洞、第三方组件未充分验证，或失败可能影响收入、敏感数据、客户体验或关键业务时，也必须强制进行人工审查。

在这些情况下，未解释的行为、测试结果不一致或缺乏足够的发布准备证据应自动阻止发布。

我们曾看到客户的一个“间歇性”测试在没有明显失败模式的情况下被忽视。但在这些客户的严格治理流程中，借助我们的平台，他们能够追溯到一个细微但关键的时序缺陷，如果发布将导致重大影响，成本极高。

您还曾参与 Ethical AI Governance Group 和世界经济论坛的安全系统与技术工作组。随着 AI 生成代码和自主测试的深度融合，企业需要哪些治理标准，以确保更快的软件创建不会引入新的系统性、安全或问责风险？

AI 创造软件的速度越快，验证与治理层就必须越强大。该层面包括多个方面。企业必须明确哪些决策可以由代理自主完成，何时需要在人类审查下进行，尤其是涉及业务意图、安全、合规或重要语义变更时。还需要对代理所做的更改、原因以及支撑发布决策的证据实现可追溯性。最终，治理应通过生产质量和可预测性来衡量，例如专门追踪生成代码在发布后 90 天内导致事故的频率，而不是仅仅看 AI 生成代码的速度有多快。

感谢这次精彩的访谈，想了解更多的读者请访问 Sauce Labs。