Shanea Leven，Empromptu AI 创始人兼首席执行官 – 专访系列

Shanea Leven 是 Empromptu AI 的创始人兼首席执行官，她是一位资深的产品领导者，在大型科技公司拥有构建开发者平台和人工智能驱动产品的丰富经验。在 2025 年创立 Empromptu 之前，她创立了 CodeSee，这是一个帮助团队可视化和理解复杂代码库的人工智能开发者平台，该平台于 2024 年被 GitKraken 收购。在其职业生涯早期，她曾在 Docker、Cloudflare、eBay 和 Google 等公司担任高级产品领导职务，参与的项目范围广泛，从 Google Assistant 支付 API 到被数十万学习者使用的开发者教育项目。 Empromptu AI 是一个企业平台，旨在帮助组织更轻松地构建和部署集成式人工智能应用。该平台将应用开发、数据集成、治理、评估、记忆和模型编排结合到一个统一的环境中，使企业能够从快速的人工智能实验转向生产级系统，并具备企业使用所需的控制和可靠性。 您在 Google、eBay、Cloudflare 和 Docker 等公司构建开发者平台超过 15 年，之后创立了后来被 GitKraken 收购的 CodeSee，现在领导着 Empromptu AI。这些经历如何塑造了您对为何如此多人工智能工具在离开演示阶段后失败的看法？您在创立 Empromptu 时决心要解决的具体问题是什么？ 在构建开发者平台时，你学到的一点是：最难的问题从来不在演示中。演示总是能成功。真正的考验在于，当数千名开发者使用系统时、当数据混乱时、当集成中断时、以及当真实业务依赖它时会发生什么。 在 Google、Cloudflare、Docker 和 eBay，我花了数年时间构建必须在全球范围内运行的平台。这些环境让你很快明白：可靠性、治理和可观测性不是后期添加的功能。它们就是架构本身。 当我开始构建人工智能应用时，模型还很糟糕。随着模型开始变得更好，我注意到行业正在重复我们在早期软件浪潮中看到的相同错误。在开发工具领域，有一个似乎已被遗忘的概念：你能多快实现“Hello World”？如今，生成式版本的“Hello World”是一个完整可用的 SaaS 原型。但现在我们不只是“氛围编码”SaaS 应用；我们“氛围编码”整个 AI 应用。一个能构建 AI 的 AI 需要其他系统来将该 AI 投入生产。 你可以快速生成一个可工作的 AI 应用或功能，这令人兴奋且确实有用。但主流系统仍然缺乏生产环境所需的基础设施。诸如结构化数据管道、评估框架、治理控制、监控和长期上下文管理等功能被遗漏了，但我们在保留氛围编码所有优点的同时，将这些功能都整合了进来。 当我和联合创始人创立 Empromptu 时，我们想要解决的问题很简单：如何让人工智能应用从一开始就具备生产就绪性？ 我们没有将治理、数据就绪性、评估和优化视为独立的工具或事后流程，而是将它们直接构建到平台中。我们的理念是，团队应该能够快速构建人工智能应用，但同时具备企业软件系统所期望的相同可靠性、质量和控制力。 您一直直言不讳地指出令人印象深刻的人工智能演示与生产就绪系统之间存在差距。从您的角度来看，团队在尝试将人工智能原型转变为真实客户使用的可靠产品时，最常犯的架构错误是什么？ 团队最常犯的错误是假设模型就是产品。 在早期原型中，模型完成了大部分可见的工作。你给出提示，它产生答案，如果答案看起来不错，系统就显得能工作。这造成了一种错觉，即改进模型是主要挑战。 但在生产系统中，模型只是更大架构中的一个组件。 第一个错误是将数据视为事后考虑。在原型阶段，团队通常使用小型、干净的数据集进行测试。一旦系统连接到真实的运营数据，情况就会迅速改变。数据可能不完整、不一致、重复或格式意外。如果没有结构化的数据管道来规范化和验证输入，无论模型有多好，系统都会变得不可靠。 第二个错误是缺乏评估框架。许多团队在没有定义“好”的实际含义的情况下就发布了人工智能功能。他们可能在开发过程中手动抽查输出，但没有构建自动化的评估管道，在系统上线后持续测量准确性、漂移和边缘情况。没有这些护栏，故障往往是由客户而非工程师发现的。 第三个问题是缺乏治理和控制机制。人工智能系统是概率性的，这意味着它们在略有不同的条件下可能表现不同。在受监管或高风险的环境中，这种不可预测性必须通过确定性策略、审批工作流以及记录决策过程的审计日志来加以约束。 这归根结底在于，生产型人工智能系统不仅仅是模型。它们是运营系统。 如今在人工智能方面取得成功的公司，是那些将数据管道、评估、治理和监控视为核心基础设施，而非可选附加组件的公司。 许多人工智能编码平台承诺任何人都可以使用简单的提示构建应用程序。为什么这些工具通常在演示时效果良好，但一旦公司尝试在真实生产环境中部署它们时就会遇到困难？ 许多这类平台在演示时效果良好，是因为它们针对创建时刻进行了优化，而不是针对真实系统的生命周期。 但是，使用人工智能生成一个落地页与使用人工智能构建一个人工智能应用，存在着根本性的区别。 落地页大多是静态软件。一旦它正确渲染，工作就基本完成了。系统不必做出概率性决策、摄取不断变化的数据或适应不可预测的用户行为。 人工智能应用则完全不同。它们是动态系统，依赖于数据管道、模型行为、评估框架和持续监控。应用必须管理上下文、检测输出何时漂移、处理边缘情况，并在模型遇到前所未见的情况时安全运行。 大多数提示驱动的编码工具没有解决这些层面，因为它们旨在快速让某些东西运行起来。它们生成能产生可见结果的代码，这对于演示环境来说是完美的。但生产系统需要更广泛的能力：结构化数据处理、治理控制、评估管道、可观测性以及随时间安全更新行为的机制。 因此，当公司尝试在真实环境中部署这些系统时，差距就变得显而易见。原型之所以能工作，是因为环境是受控的。而生产环境是混乱的。 Empromptu 专注于将现有软件转变为人工智能原生系统，而不是强迫公司从头开始重建一切。这种转变在基础设施和产品层面实际上涉及什么？ 在产品层面，每个应用都是完全自包含和容器化的。我们创建您所需的一切，包括前端、后端、数据库、模型、评估、LLM Ops 规则等，并且所有内容都根据企业的需求高度灵活。 我们为 AI 应用提供了多种不同的选项： “无头”模式：如果客户已有前端，我们可以将其连接到我们的系统并传回数据。 完全容器化：它们可以部署在我们的基础设施上，也可以部署在客户的基础设施内，因此默认是本地部署的。 或者，我们也可以直接生成它们并部署到云端，这是最便捷的选项。 对于他们拥有的任何代码，我们都可以直接导入到我们的系统中，如果尚未实现代理化，我们会将其代理化。例如，我们看到许多客户尝试在 Lovable、Replit、Bolt 或 Base44 等流行平台上构建他们的应用。这些应用通常无法正常工作。但客户已经在这个应用上投入了大量时间、精力和积分，因此我们将其导入、重写，并让所有 AI 功能正常工作。 我们能做到这一点，是因为我们拥有多项自定义的专有技术，例如：

• 自适应上下文引擎来管理上下文
• 无限记忆以摄取长期运行的代码应用
• 自定义数据模型和黄金数据管道，以确保我们能够处理任何所需的数据清理和合成标签

您的平台强调上下文、评估、治理和结构化数据是人工智能系统的核心组件。为什么团队在急于为产品添加人工智能功能时，这些元素经常被忽视？ 因为它们很难做！我的联合创始人 Sean Robinson 博士领导我们的研究实验室，他是一位计算天体物理学家，发明了许多受我疯狂想法启发、同时也基于客户需求和市场走向的技术。我们在构建众多代理应用、将卫星送入太空以及在世界上最大的科技公司工作的综合经验，使我们能够比其他人更好地解决复杂问题。 您与许多从未写过代码的创始人合作。非技术创始人在首次尝试构建人工智能应用时，最大的误解是什么？ 我认为有两个很大的误解： 第一个误解是 AI 是魔法。AI 不是魔法。它只是优秀的工程实践。最终，在没有真正工程师的情况下，你在这些平台上能做的事情会达到极限。 第二个误解是他们拥有出色的技术产品管理技能。我拥有技术产品管理的背景，这项技能在于将愿景（有时是非常宏大的愿景）分解成可交付的小块，并配以正确的技术规格来准确表达你想要什么。这实际上是一项非常困难的技能，需要时间积累。 例如，假设你正在构建一个上传 PDF 并保存该 PDF 以便稍后查看的应用。这个概念称为持久化。该 PDF 被编码为代码并保存到数据库中。 但是，如果你不知道那叫做持久化，你怎么能输入“确保这些数据持久化”呢？技术词汇的选择就像说不同的语言。用自然语言写作和用技术语言写作是有区别的。 许多初创公司认为，构建人工智能产品的解决方案就是简单地雇佣更多工程师。为什么您认为这种方法常常失败？创始人在构建人工智能驱动的产品时应该考虑什么？ 雇佣更多工程师有时是正确的答案。如果你正在构建一个技术深度很高的产品，或者在模型研究的前沿工作，你绝对需要强大的工程团队。在解决难题方面，优秀的工程师是不可替代的。 但许多初创公司犯的错误是，认为更多的工程师会自动解决构建人工智能产品的挑战。 实际上，人工智能产品中最难的问题往往不纯粹是工程问题。它们就像所有其他工程问题一样，是系统问题。工程师被专门教导用系统思维思考。但生成式开发不同于确定性开发。我们许多人在从面向对象编程转向函数式编程时都经历过这种转变。它们都是编程吗？是的，绝对是，但它们不同吗？它们是不同的思维方式吗？是的，当然是。 人工智能应用位于数据、产品设计、运营工作流和模型行为的交叉点。你可以雇佣一支优秀的工程师团队，但如果数据管道不可靠、评估标准不明确，或者系统缺乏治理和监控，产品在接触到真实用户时仍然会举步维艰。 另一个问题是，许多团队在定义人工智能系统在生产环境中的行为方式之前，就直接开始构建。诸如系统将如何被评估、如何处理边缘情况、如何记录决策以及模型将如何随时间安全更新等问题，往往到很晚才被考虑。到那时，架构已经很难更改了。 创始人真正应该思考的是他们人工智能系统的运营模型。 谁负责数据管道？ 如何持续测量模型性能，而不仅仅是在开发期间？ 当系统遇到前所未见的情况时会发生什么？ 如何在不破坏下游工作流的情况下安全地更新行为？ 有时，解决这些问题确实意味着雇佣更多工程师。但也可能意味着选择正确的基础设施、定义强大的产品约束，以及构建能让小团队可靠地大规模运营的系统。 如今在人工智能方面取得成功的公司，不一定是那些拥有最大工程团队的公司。它们是那些将人工智能视为一个需要从一开始就内置数据纪律、评估、治理和持续改进的长期运行系统的公司。 您曾指出，当前人工智能开发者工具中的一些商业模式与构建持久产品不一致。您认为当前人工智能工具生态系统中的哪些激励措施正在将公司引向错误的方向？ 当前最大的激励错配之一是，许多人工智能开发者工具是针对增长指标而非产品持久性进行优化的。 这个领域的许多公司因用户能多快创造出令人印象深刻的东西而获得回报。如果一个工具能在几分钟内生成一个可工作的应用、功能或演示，那就会推动注册、社交分享和投资者的兴奋。从产品采用的角度来看，这是有道理的。 但这些激励措施往往在创建时刻就停止了。 人工智能软件中更艰巨的工作发生在那一刻之后。那才是建立信任的时候。当你可以依赖质量时。当用户希望一次又一次地回来，而不会因为糟糕的输出而对 AI 感到沮丧。即使在面对人类的无知或恶意时，也需要给出良好的回应。 另一个问题是，许多工具是针对代码生成而非系统设计进行优化的。快速生成代码是有帮助的，但构建人工智能产品涉及的不仅仅是生成代码。它需要定义系统如何管理上下文、如何评估决策、如何处理故障以及行为如何随时间安全演进。 那些将激励措施围绕帮助客户可靠地运行人工智能系统（而不仅仅是快速构建它们）的公司，将在这个生态系统中创造持久的价值。 您的一些客户包括构建非常具体产品的企业家，例如专业健康工具或专注于可持续发展的企业，他们通常没有传统的工程团队。在那些成功将这些想法转化为可工作人工智能产品的创始人中，您看到了哪些共同模式？ 我们看到的最有趣的模式之一是，成功的创始人未必是最懂技术的。他们是那些对自己正在解决的问题有极其深刻理解的人。 许多使用 Empromptu 的企业家都是领域专家。他们可能来自医疗保健、金融、可持续发展或其他专业行业。他们带来的是对该环境中工作流程、法规和决策的深入了解。在设计人工智能产品时，这种背景非常宝贵，因为它定义了系统实际需要做什么。 成功的创始人倾向于将人工智能更多地视为一个产品系统，而非技术实验。他们从提出非常具体的问题开始：人工智能应该帮助用户做出哪些决策？它需要访问哪些数据源？在这个领域中，正确的答案实际上是什么样的？需要存在哪些护栏以确保系统行为负责？ 另一个模式是他们仔细思考结构。成功的团队很快意识到，人工智能的输出质量取决于输入其中的上下文和数据。他们提前投入时间定义数据管道、组织知识来源，并为“好”的样子创建清晰的评估标准。 我们还看到成功的创始人拥抱人机协作，而不是试图立即自动化一切。他们设计工作流程，让 AI 处理重复性分析或数据合成，而人类则负责判断和最终决策。这种平衡使系统更加可靠，尤其是在医疗保健或金融等领域。 在许多方面，最大的转变是心态。成功的创始人并不将 AI 视为他们正在添加的一个功能。他们将其视为产品如何运作的一个新的操作层。 随着人工智能系统越来越深入地集成到核心业务运营中，哪些能力将定义下一代人工智能应用平台？ 我知道这听起来可能很疯狂，我可能说了些亵渎神明的话，但人们将能够“氛围编码”他们自己的定制模型。我们研究实验室称之为“专家纳米模型”的东西将有助于控制成本。 感谢您精彩的采访，希望了解更多信息的读者请访问 Empromptu AI。