Shanea Leven，Empromptu AI 的创始人和 CEO – 采访系列

Shanea Leven，Empromptu AI 的创始人和 CEO，是一位具有丰富经验的产品领导者，曾在主要技术公司从事开发者平台和 AI 驱动产品的建设。在 2025 年创立 Empromptu 之前，她创立了 CodeSee，一款帮助团队可视化和理解复杂代码库的 AI 开发者平台，该平台于 2024 年被 GitKraken 收购。早期，她曾在包括 Docker、Cloudflare、eBay 和 Google (GOOGL ) 在内的公司担任高级产品领导职务，在那里她曾参与过从 Google Assistant 支付 API 到开发者教育计划等多个项目，这些项目被数十万名学习者使用过。

Empromptu AI 是一款为企业设计的平台，旨在帮助组织更容易地构建和部署集成的 AI 应用程序。该平台将应用程序开发、数据集成、治理、评估、内存和模型编排合并到一个环境中，使公司能够从快速的 AI 实验到具有企业使用所需的控制和可靠性的生产级系统进行转变。

您在像 Google、eBay、Cloudflare 和 Docker 这样的公司度过了 15 年以上的时间，建设开发者平台，然后创立了 CodeSee，最终被 GitKraken 收购，现在您领导 Empromptu AI。这些经历如何塑造您对为什么这么多 AI 工具在离开演示阶段后会失败的看法，您在创立 Empromptu 时试图解决什么具体问题？

建设开发者平台时学到的东西之一是，最难的问题永远不是演示中的问题。演示总是有效。真正的考验是当成千上万的开发者使用系统时，数据是混乱的，集成断开，真正的企业依赖于它时会发生什么。

在 Google、Cloudflare、Docker 和 eBay，我花了多年时间从事需要在全球范围内运行的平台。这些环境很快就教会了你一件事：可靠性、治理和可观察性不是你以后添加的功能。它们是架构的一部分。

当我开始构建 AI 应用程序时，模型很糟糕，当它们开始变得更好时，我注意到该行业正在重复我们在软件早期浪潮中看到的相同错误。在开发工具中，有一个似乎被遗忘的概念。您可以多快地到达“Hello World”？今天，生成式的“Hello World”是一个完整的工作 SaaS 原型。但是，我们现在不仅仅是使用 AI 构建 SaaS 应用程序；我们使用 AI 构建整个 AI 应用程序。构建 AI 的 AI 需要其他系统将该 AI 投入生产。

您可以快速生成一个工作的 AI 应用程序或功能，这既令人兴奋又真正有用。但是，主导系统仍然缺乏生产环境所需的基础设施。诸如结构化数据管道、评估框架、治理控制、监控和长期上下文管理等东西被忽略了，但我们已经将它们纳入其中，同时保留了所有令人惊叹的编码部分。

当我的联合创始人和我创立 Empromptu 时，我们想要解决的一个问题很简单：如何从一开始就使 AI 应用程序生产就绪？

与其将治理、数据准备、评估和优化视为单独的工具或事后过程，我们将它们直接构建到平台中。这个想法是，团队应该能够快速构建 AI 应用程序，但具有与企业软件系统相同的可靠性、质量和控制力。

您一直在谈论令人印象深刻的 AI 演示和生产就绪系统之间的差距。从您的角度来看，团队在尝试将 AI 原型转变为可靠产品时最常犯的架构错误是什么？

团队犯的最常见的错误是假设模型就是产品。

在早期的原型中，模型执行大部分可见的工作。你提示它，它产生一个答案，如果答案看起来很好，那么系统似乎可以工作。这就产生了这样的幻觉，即提高模型是主要的挑战。

但是，在生产系统中，模型只是一个更大架构中的一个组件。

第一个错误是将数据视为事后思考。在原型中，团队经常使用小型、干净的数据集进行测试。一旦系统连接到真正的操作数据，事情就会迅速改变。数据以不完整、不一致、重复或意外格式到达。没有结构化的数据管道来规范化和验证输入，系统变得不可靠，无论模型有多好。

第二个错误是缺乏评估框架。许多团队在没有定义什么是“好”的情况下推出 AI 功能。他们可能会在开发过程中手动检查输出，但他们不会构建自动评估管道来持续衡量准确性、漂移和边缘情况，一旦系统上线就会出现这些问题。没有这些防护措施，故障往往是由客户而不是工程师发现的。

第三个问题是缺乏治理和控制机制。AI 系统是概率性的，这意味着它们可以在稍微不同的条件下表现出不同的行为。在受监管或高风险环境中，这种不可预测性必须通过确定性策略、审批工作流和审计日志来约束，这些日志记录了决策的过程。

这实际上归结为生产 AI 系统不仅仅是模型。它们是操作系统。

今天成功的公司是那些将数据管道、评估、治理和监控视为核心基础设施，而不是可选附加组件的公司。

许多 AI 编码平台承诺任何人都可以使用简单的提示构建应用程序。为什么这些工具通常在演示中效果良好，但在公司试图在真正的生产环境中部署它们时却会遇到困难？

许多这些平台之所以在演示中效果良好，是因为它们针对创建时刻进行了优化，而不是整个系统的生命周期。

但是，有一个根本的区别在于使用 AI 生成一个登陆页面和使用 AI 构建一个 AI 应用程序之间。

一个登陆页面基本上是静态软件。一旦它正确渲染，工作基本上就完成了。该系统不需要做出概率决策，不需要摄取不断变化的数据，也不需要适应不可预测的用户行为。

AI 应用程序完全不同。它们是依赖于数据管道、模型行为、评估框架和持续监控的动态系统。该应用程序必须管理上下文，检测输出漂移，处理边缘情况，并在模型遇到以前未见过的情况时安全运行。

大多数基于提示的编码工具不解决这些层，因为它们旨在快速产生结果。这对于演示环境是完美的。但是，生产系统需要一套更广泛的功能：结构化数据处理、治理控制、评估管道、可观察性和安全更新行为的机制。

因此，当公司试图在真正的环境中部署这些系统时，差距变得明显。原型之所以有效，是因为环境是受控的。生产是混乱的。

Empromptu 专注于将现有的软件转变为 AI 本地系统，而不是强迫公司从头开始重建一切。这种转变在基础设施和产品层面上实际上涉及什么？

在产品层面，每个应用程序都是完全自包含和容器化的。我们为前端、后端、数据库、模型、评估、LLM OPPS 规则等创建所有必要的内容，一切都非常灵活，取决于企业的需求。

我们有多个选项用于 AI 应用程序：

“无头”- 如果客户已经有一个前端，我们可以将其连接到我们的系统并将数据发送回去

完全容器化 – 它们可以部署在我们的基础设施上或在客户的基础设施内，因此默认情况下它们是本地的。

或者我们可以直接生成它们并将它们部署到云端，以获得最方便的选项。

如果他们有任何代码，我们都可以直接将其导入到我们的系统中，并使其成为代理，如果它还没有成为代理。例如，我们看到许多客户尝试在流行平台如 Lovable、Replit、Bolt 或 Base44 上构建他们的应用程序。通常，它们不起作用。但是，客户已经投入了大量时间、精力和积分到这个应用程序中，因此我们会将其导入、重写并使所有 AI 工作正常。

我们可以做到这一点，因为我们拥有多项自定义的专有技术，例如：

• 自适应上下文引擎，用于管理上下文
• 无限内存，用于摄取长时间运行的代码应用程序
• 自定义数据模型和黄金数据管道，确保我们可以处理任何所需的数据清理和合成标记

您的平台强调上下文、评估、治理和结构化数据作为 AI 系统的核心组件。为什么这些元素在团队匆忙添加 AI 功能到产品时经常被忽略？

因为它们很难做到！我的联合创始人 Sean Robinson 博士领导我们的研究实验室，他是一位计算天体物理学家，发明了多项受我疯狂想法启发的技术，也受到了客户需求和市场趋势的影响。我们在构建许多代理应用程序、将卫星送入太空以及在世界上最大的科技公司工作的经验为我们提供了洞察力，使我们能够比其他人更好地解决复杂问题。

您与许多从未编写过代码的创始人合作。他们第一次尝试构建 AI 应用程序时，通常会有哪些最大误解？

我认为有两个大误解：

第一个是，AI 是魔术。AI 不是魔术。它只是良好的工程。最终，你会遇到这些平台的限制，而没有真正的工程师，你就无法超越这些限制。

第二个是，他们拥有很好的技术产品管理技能。我拥有技术产品管理的背景，能够将愿景，通常是一个非常大的愿景，转化为带有正确的技术规格的小型可交付块，以准确表达您想要的内容。这是一项需要时间来培养的技能。

例如，假设您正在构建一个应用程序，上传一个 PDF 并将其保存以便稍后查看。这是一个叫做持久性的概念。如果您不知道持久性被称为持久性，您如何能够输入“确保此数据持久化”？技术词汇选择就像说一种不同的语言。自然语言和技术语言之间是有区别的。

许多初创公司认为构建 AI 产品的解决方案就是雇用更多的工程师。您为什么认为这种方法通常会失败，创始人在构建 AI 驱动的产品时应该思考什么？

雇用更多的工程师有时是正确的答案。如果您正在构建一个深度技术产品或从事模型研究的前沿，您绝对需要强大的工程团队。没有好的工程师，很难解决棘手的问题。

但是，许多初创公司犯的错误是，认为更多的工程师可以自动解决构建 AI 产品的挑战。

实际上，AI 产品中最难的问题往往不是纯粹的工程问题。它们是系统问题，就像其他工程问题一样。工程师被特意教导去思考系统。但是，生成式开发与确定性开发不同。我们中的很多人在从面向对象编程转向函数式编程时都经历过这种转变。它们都是编程？是的，绝对的。但是，它们是不同的？它们是一种不同的思考方式？是的，当然如此。

AI 应用程序位于数据、产品设计、操作工作流和模型行为的交叉点。您可以雇用一支不可思议的工程团队，但如果数据管道不可靠，评估标准不明确，或者系统缺乏治理和监控，产品仍将在面对真正的用户时挣扎。

另一个问题是，许多团队在定义了如何在生产中行为之前就开始构建。诸如如何评估系统、如何处理边缘情况、如何记录决策以及如何在不破坏下游工作流的情况下安全更新模型等问题通常在架构已经很难改变之后才会出现。

创始人应该真正思考的是他们的 AI 系统的运营模型。

谁拥有数据管道？

如何在开发过程之外持续衡量模型性能？

当系统遇到以前未见过的情况时会发生什么？

如何在不破坏下游工作流的情况下安全更新行为？

有时，解决这些问题的方法确实是雇用更多的工程师。但是，它也可能意味着选择合适的基础设施，定义强大的产品约束，并构建允许小团队可靠地扩展的系统。

今天成功的公司不一定是拥有最大的工程团队的公司。它们是那些从一开始就将 AI 视为需要数据纪律、评估、治理和持续改进的长期运行系统的公司。

您认为当前 AI 开发工具的商业模式中存在哪些激励因素不利于构建耐用产品？

目前最大的激励不匹配是，许多 AI 开发工具针对增长指标进行了优化，而不是产品耐用性。

该领域的许多公司因其能够快速创建令人印象深刻的东西而受到奖励。如果一个工具可以在几分钟内生成一个工作应用程序、一个功能或一个演示，那么这会推动注册、社交分享和投资者兴奋。在产品采用方面，这是有道理的。

但是，这些激励措施通常在创建时刻就停止了。

在 AI 软件中，艰难的工作发生在那之后。这是信任建立的时候。质量可靠的时候。用户想要再次回来，没有 AI 的挫败感，需要良好的响应，甚至面对人类的无知或恶意行为。

另一个问题是，许多工具针对代码生成进行了优化，而不是系统设计。快速生成代码是有帮助的，但构建 AI 产品涉及的不仅仅是产生代码。它需要定义系统如何管理上下文，如何评估决策，如何处理故障，以及如何在不破坏下游工作流的情况下安全地随时间演化行为。

那些将激励措施与帮助客户可靠地运行 AI 系统相一致的公司，而不是仅仅快速构建它们，才是那些将在这个生态系统中创造持久价值的公司。

您的客户中包括一些创业者，他们正在构建非常特定的产品，例如专门的健康工具或可持续发展业务，通常没有传统的工程团队。您在成功将这些想法转化为工作 AI 产品的创始人中看到了一些什么模式？

我们看到的最有趣的模式之一是，成功的创始人并不一定是最有技术专长的。他们是那些对自己要解决的问题有极其深刻的理解的人。

使用 Empromptu 的许多创业者都是领域专家。他们可能来自医疗保健、金融、可持续发展或其他专门行业。他们带来的东西是对该环境中的工作流、法规和决策的深入了解。这种背景在设计 AI 产品时非常有价值，因为它定义了系统实际上需要做什么。

成功的创始人倾向于将 AI 更多地视为产品系统，而不是技术实验。他们从提出非常具体的问题开始。AI 应该帮助用户做出什么决定？它需要访问什么数据源？在这个领域，什么是正确答案的样子？什么样的防护措施需要存在，以便系统能够负责任地运行？

另一个模式是，他们会仔细思考结构。成功的团队很快意识到，AI 输出的质量只与输入的上下文和数据一样好。他们会在定义数据管道、组织知识源和创建评估标准时投入时间，以确定“好”的标准是什么。

我们还看到成功的创始人接受人机协作，而不是试图立即自动化一切。他们设计工作流程，使 AI 处理重复分析或数据综合，而人类仍然负责判断和最终决策。这种平衡使系统更加可靠，尤其是在医疗保健或金融等领域。

在很多方面，最大的转变是心态。成功的创始人不认为 AI 是他们要添加的功能。他们认为它是产品工作的新操作层。

随着 AI 系统变得越来越集成到核心业务运营中，哪些功能将定义下一代 AI 应用程序平台？

我知道这听起来很疯狂，我可能说了一些亵渎的话，但人们将能够使用自己的自定义模型进行编码。我们研究实验室称之为专家纳米模型的东西将有助于控制成本。

感谢您这次精彩的采访，希望您能通过访问 Empromptu AI 了解更多信息。