面试
Empromptu AI 创始人兼首席执行官 Shanea Leven – 访谈系列
莎妮娅·莱文Empromptu AI 的创始人兼首席执行官是一位资深产品领导者，在大型科技公司拥有丰富的开发者平台和人工智能驱动型产品开发经验。在 2025 年创立 Empromptu 之前，她创立了 CodeSee，这是一个人工智能开发者平台，旨在帮助团队可视化和理解复杂的代码库，并于 2024 年被 GitKraken 收购。在其职业生涯早期，她曾在 Docker、Cloudflare、eBay 和 Google 等公司担任高级产品领导职务，参与的项目涵盖了从 Google Assistant 支付 API 到数十万学员使用的开发者教育项目等各个方面。
即兴人工智能 是一个企业级平台，旨在帮助企业更轻松地构建和部署集成式人工智能应用。该平台将应用开发、数据集成、治理、评估、内存和模型编排整合到一个统一的环境中，使企业能够从快速的人工智能实验过渡到具备企业级应用所需控制和可靠性的生产级系统。
在创立 CodeSee（后被 GitKraken 收购）之前，您曾在 Google、eBay、Cloudflare 和 Docker 等公司从事开发者平台建设超过 15 年，现在领导着 Empromptu AI。这些经历如何影响了您对众多 AI 工具在离开演示阶段后为何会失败的看法？您在创立 Empromptu 时决心解决的具体问题是什么？
构建开发者平台的过程中，你会学到的一点是，最棘手的问题永远不是演示版本中出现的问题。演示版本总是能正常运行。真正的考验在于，当成千上万的开发者使用系统、数据混乱、集成出现故障，以及真正的企业依赖该系统时，会发生什么。
在谷歌、Cloudflare、Docker 和 eBay，我花了数年时间开发需要在全球范围内运行的平台。这些环境让我很快明白一个道理：可靠性、治理和可观测性不是后期添加的功能，而是架构本身。
当我开始构建人工智能应用时，模型非常糟糕。随着模型逐渐改进，我发现整个行业正在重蹈覆辙，犯着我们在早期软件浪潮中也曾犯过的错误。在开发工具领域，有一个概念似乎被遗忘了：你能多快实现“Hello World”？如今，生成式的“Hello World”已经是一个完整的、可运行的SaaS原型。但我们现在不再仅仅用Vibe代码编写SaaS应用，而是用Vibe代码编写整个人工智能应用。一个能够构建人工智能的AI，需要其他系统才能将其投入生产。
您可以快速生成可用的 AI 应用或功能，这令人兴奋且确实实用。但主流系统仍然缺乏生产环境所需的基础设施。例如结构化数据管道、评估框架、治理控制、监控和长期上下文管理等功能都存在缺失，但我们已将其添加进去，同时保留了 vibe coding 的所有出色特性。
我和我的联合创始人创立 Empromptu 时，我们想要解决的问题很简单：如何让 AI 应用从一开始就具备生产就绪状态？
我们没有将治理、数据准备、评估和优化视为独立的工具或事后流程，而是将它们直接构建到平台中。这样做的目的是让团队能够快速构建人工智能应用，同时获得与企业软件系统相同的可靠性、质量和可控性。
您曾多次直言不讳地指出，令人印象深刻的人工智能演示与可用于生产环境的系统之间存在差距。从您的角度来看，团队在尝试将人工智能原型转化为可供真实客户使用的可靠产品时，最常犯的架构错误是什么？
团队最常犯的错误是假设模型就是产品。
在早期原型中，模型承担了大部分可见的工作。你向它发出指令，它给出答案，如果答案看起来不错，系统就显得运行正常。这造成了一种错觉，即改进模型才是主要挑战。
但在生产系统中，该模型只是一个更大架构中的一个组件。
第一个错误是将数据视为事后考虑因素。在原型开发阶段，团队通常使用小型、干净的数据集进行测试。一旦系统连接到实际运行数据，情况就会迅速变化。数据可能不完整、不一致、重复，或者格式出乎意料。如果没有结构化的数据管道来规范化和验证输入，无论模型多么出色，系统都会变得不可靠。
第二个错误是缺乏评估框架。许多团队在发布人工智能功能时，并没有明确定义“好”的标准。他们或许会在开发过程中手动抽查输出结果，但却没有构建自动化的评估流程，在系统上线后持续监测其准确性、偏差以及各种极端情况。如果没有这些保障措施，故障往往是由客户而非工程师发现的。
第三个问题是缺乏治理和控制机制。人工智能系统具有概率性，这意味着它们在略微不同的条件下可能会表现出不同的行为。在受监管或高风险的环境中，这种不可预测性必须通过确定性策略、审批流程和记录决策过程的审计日志来加以约束。
归根结底，生产环境中的人工智能系统不仅仅是模型，它们是可运行的系统。
如今在人工智能领域取得成功的公司，都将数据管道、评估、治理和监控视为核心基础设施，而不是可有可无的附加功能。
许多人工智能编程平台声称任何人都可以通过简单的提示构建应用程序。为什么这些工具在演示中通常效果很好，但一旦企业尝试将其部署到实际生产环境中，就会遇到困难？
这些平台大多适用于演示，因为它们针对的是创建时的即时效果，而不是真实系统的生命周期。
但是，使用人工智能生成落地页和使用人工智能构建人工智能应用程序之间存在着根本区别。
落地页主要由静态软件构成。一旦正确渲染，大部分工作就完成了。系统无需进行概率性决策、处理不断变化的数据或适应不可预测的用户行为。
人工智能应用截然不同。它们是动态系统，依赖于数据管道、模型行为、评估框架和持续监控。应用必须管理上下文，检测输出偏差，处理极端情况，并在模型遇到从未见过的情况时安全运行。
大多数基于提示的编码工具并不关注这些层面，因为它们旨在快速实现某些功能。它们生成的代码能够产生可见的结果，这非常适合演示环境。但生产系统需要更强大的功能：结构化数据处理、治理控制、评估流程、可观测性以及安全更新行为的机制。
因此，当企业尝试在实际环境中部署这些系统时，差距就显而易见了。原型之所以能成功，是因为环境可控。而生产环境则纷繁复杂。
Empromptu专注于将现有软件改造为原生AI系统，而不是强迫企业从头开始重建一切。这种改造在基础设施和产品层面究竟包含哪些内容？
在产品层面，每个应用程序都是完全独立且容器化的。我们创建您所需的一切，包括前端、后端、数据库、模型、评估、LLMS 操作规则等等，而且一切都根据企业需求高度灵活。
我们有多种不同的AI应用可供选择：
“无头”设计使得如果客户已有前端，我们可以将其连接到我们的系统并将数据发送回客户。
完全容器化，因此可以部署在我们的基础设施上或客户的基础设施内，默认情况下是本地部署。
或者，我们可以直接生成它们并部署到云端，这是最方便的选择。
无论他们拥有什么代码，我们都可以将其直接导入我们的系统，如果尚未实现智能化，我们还可以将其智能化。例如，我们经常遇到这样的客户：他们尝试在 Lovable、Replit、Bolt 或 Base44 等热门平台上构建应用程序。这些应用程序通常无法正常运行。但客户已经投入了大量的时间、精力和资金，因此我们会将其导入、重写，并使其所有 AI 功能正常运行。
我们之所以能够做到这一点，是因为我们拥有多项定制的专有技术，例如：
- 用于管理上下文的自适应上下文引擎
- 无限内存，用于加载长时间运行的代码应用程序
- 定制数据模型和黄金数据管道，以确保我们能够处理所需的任何数据清洗和合成标注工作。
您的平台强调上下文、评估、治理和结构化数据是人工智能系统的核心组成部分。为什么团队在急于将人工智能功能添加到产品中时，这些要素却经常被忽视？
因为它们很难做到！我的联合创始人肖恩·罗宾逊博士领导着我们的研究实验室，他是一位计算天体物理学家，他发明了许多技术，这些技术不仅源于我的奇思妙想，也源于我们客户的需求和市场发展趋势。我们两人在构建众多智能体应用、将卫星送入太空以及在全球最大的科技公司工作的经验，让我们拥有了独特的洞察力，能够比其他人更好地解决复杂问题。
你接触过很多从未写过代码的创始人。非技术出身的创始人在首次尝试构建人工智能应用程序时，最大的误解是什么？
我认为存在两大误解：
第一种误解是人工智能是魔法。人工智能并非魔法，它只是优秀的工程技术。而且，如果没有真正的工程师，你最终会发现这些平台的功能是有限的。
第二点是，他们拥有出色的技术产品管理能力。我本人也拥有技术产品管理背景，擅长将愿景（有时是非常宏大的愿景）分解成可交付的小模块，并配以恰当的技术规范，从而清晰地表达你的需求。这实际上是一项非常难得的技能，需要时间去磨练。
例如，假设你正在开发一个应用程序，它可以上传 PDF 文件并保存该 PDF 文件以便你稍后查看。这就是所谓的持久化。该 PDF 文件会被编码成代码并保存到数据库中。
但如果你不知道这叫做持久化，你怎么能打字呢？确保这些数据能够持久保存。技术术语的选择就像说一门不同的语言。自然语言写作和技术语言写作之间存在着差异。
许多初创公司认为，构建人工智能产品的解决方案就是简单地雇佣更多工程师。您认为这种方法为何常常失败？创始人构建人工智能产品时应该考虑哪些方面？
有时候，增加工程师人数是正确的做法。如果你正在开发一款技术含量极高的产品，或者从事模型研究的前沿工作，那么你绝对需要强大的工程团队。在解决难题方面，优秀的工程师是无可替代的。
但许多创业公司犯的错误是，他们认为增加工程师数量就能自动解决构建人工智能产品的难题。
实际上，人工智能产品中最棘手的问题往往并非纯粹的工程问题，而是系统问题，就像其他所有工程问题一样。工程师接受的训练就是系统性思考。但生成式开发与确定性开发截然不同。我们很多人在从面向对象编程转向函数式编程时都经历了这种转变。它们都是编程吗？当然是，但它们有区别吗？它们是不同的思维方式吗？当然是。
人工智能应用涉及数据、产品设计、运营流程和模型行为的交汇点。即使你组建了一支顶尖的工程师团队，但如果数据管道不可靠、评估标准不明确，或者系统缺乏治理和监控，产品一旦面向真实用户，仍然会面临诸多挑战。
另一个问题是，许多团队在定义人工智能系统在生产环境中的运行方式之前，就直接开始构建。诸如如何评估系统、如何处理极端情况、如何记录决策以及如何随时间更新模型等问题，往往要到很久以后才会被考虑。到那时，架构已经很难更改了。
创始人真正应该考虑的是他们的人工智能系统的运营模式。
数据管道的所有权归谁？
如何持续衡量模型性能，而不仅仅是在开发过程中？
当系统遇到从未遇到过的情况时会发生什么？
如何在不破坏下游工作流程的情况下安全地更新行为？
有时，解决这些问题确实意味着要招聘更多工程师。但也可能意味着选择合适的基础设施，制定严格的产品约束，并构建能够让小型团队可靠地大规模运行的系统。
如今在人工智能领域取得成功的公司，未必拥有规模最大的工程团队。它们是那些将人工智能视为一个长期运行的系统，从一开始就需要建立数据规范、评估、治理和持续改进机制的公司。
您曾指出，目前人工智能开发者工具领域的一些商业模式与打造持久耐用的产品并不相符。您认为当前人工智能工具生态系统中的哪些激励机制正在将企业引向错误的方向？
目前最大的激励机制错配之一是，许多人工智能开发工具针对的是增长指标，而不是产品的持久性。
在这个领域，很多公司都因为用户能够快速创造出令人印象深刻的作品而获得成功。如果一款工具能在几分钟内生成一个可用的应用程序、一个功能或一个演示，就能有效提升用户注册量、促进社交分享，并激发投资者的兴趣。从产品推广的角度来看，这完全合情合理。
但这些激励措施往往止步于创作的那一刻。
人工智能软件的真正挑战在于此之后。信任的建立始于此，在于能否信赖其质量，从而让用户愿意一次又一次地使用，而不会因为人工智能糟糕的输出而感到沮丧。即使面对人类的无知或恶意，人工智能也需要给出良好的响应。
另一个问题是，许多工具针对代码生成而非系统设计进行了优化。快速生成代码固然有用，但构建人工智能产品远不止于此。它还需要定义系统如何管理上下文、如何评估决策、如何处理故障以及如何随着时间的推移安全地演化行为。
在这个生态系统中，那些致力于帮助客户可靠地运行人工智能系统，而不仅仅是快速构建人工智能系统的公司，才能创造持久的价值。
您的部分客户是一些正在打造非常特定产品的创业者，例如专业的健康工具或以可持续发展为重点的企业，他们通常没有传统的工程团队。您在那些成功将这些想法转化为实际人工智能产品的创始人身上观察到了哪些共同点？
我们发现最有趣的模式之一是，成功的创始人未必是技术最精湛的，而是那些对他们所要解决的问题理解得极其透彻的人。
许多使用 Empromptu 的企业家都是领域专家。他们可能来自医疗保健、金融、可持续发展或其他专业行业。他们带来的是对该领域现有工作流程、法规和决策的深刻理解。这种背景知识在设计人工智能产品时极其宝贵，因为它定义了系统实际需要完成的任务。
成功的创始人往往不把人工智能当作技术实验，而是当作产品系统来对待。他们首先会提出非常具体的问题：人工智能应该帮助用户做出哪些决策？它需要访问哪些数据源？在这个领域，正确的答案究竟是什么样的？需要设置哪些安全机制才能确保系统负责任地运行？
另一个特点是他们会认真考虑架构。成功的团队很快就会意识到，人工智能的输出质量取决于其所处的环境和输入数据的质量。他们会在前期投入时间来定义数据管道、组织知识库，并制定清晰的评估标准来定义“好”的结果。
我们还看到，成功的创始人会拥抱人机协作，而不是试图立即实现一切自动化。他们设计的工作流程中，人工智能负责处理重复性分析或数据综合，而人类则负责判断和最终决策。这种平衡使得系统更加可靠，尤其是在医疗保健或金融等领域。
在很多方面，最大的转变在于思维方式。成功的创始人并不把人工智能视为一项新增功能，而是将其视为产品运行方式的全新底层架构。
随着人工智能系统与核心业务运营的融合日益加深，下一代人工智能应用平台将具备哪些功能？
我知道这听起来很疯狂，我可能要说些亵渎神明的话了，但人们将能够根据自己的喜好定制专属模型。我们研究实验室称之为“专家纳米模型”的技术将有助于控制成本。
感谢您的精彩采访，想要了解更多信息的读者可以访问 即兴人工智能.
