我们如何在十个月内将 ARR 从 0 增长到 1000 万美元以上？

2022 年 11 月，我为 Latent Space 撰写了第一篇客座博客文章，并且（乐观地）希望它能成为三部分系列中的第一篇：如何选择长期 AI 产品战略（https://www.latent.space/p/what-building-copilot-for-x-really）；第二篇：如何让你的 AI 产品有区分度（https://www.latent.space/p/ai-ux-moat）

我们的企业产品在不到一年的时间内从零增长到了超过 1000 万美元的 ARR，所以是时候发布第 3 篇了。也许令人惊讶的是，我们要做的事情不像 enterpriseready.io 等网站所说的那么简单。

早在 2022 年 11 月，我就为这三个主题写好了论文，但当我写第一篇文章时遇到了一个小问题。那时我们刚刚发布了 Codeium，因此虽然我可以谈谈第一个论点（强大的产品策略来自对经济学和用例细节的深刻理解），但我们当时并不一定与其他 AI 代码助手有所区别（每个工具都只是自动完成而已），而且我们肯定没有在赚钱。两年后，越来越明显的是，出于质量和成本的原因，公司需要大大超越单纯的模型 API 调用方法，而任务特定模型、托管开源模型、RAG 等主题都已开始流行。

2023 年夏天到来了，我们已经对 IDE 内聊天体验做了 GA，其中包括代码镜头和直接插入代码等特性，这些功能在当时是非常新颖的。那时 GitHub Copilot 还要几个月才会 GA 他们的聊天功能。到那时，我有了足够的信心认定我在第二篇论文中的论点是正确的——用户体验将是创造差异化护城河的关键，无论是在短期还是长期皆是如此。一年多之后，我认为这一论点比以往任何时候都更正确，人们真正意识到拥有非常直观和强大的用户体验是多么重要，这种体验在某种程度上隐藏了底层模型和推理的复杂性。看看 Perplexity 或 Glean，甚至在我们这个领域，看看 Zed 或 Cursor。他们的技术不错，用户体验也很棒。

不过，当时在写我的第三篇论文时仍然存在一个小问题。个人版 Codeium 过去是免费的，现在仍然是免费的，我们刚刚推出了付费企业产品，所以我们还不一定能赚钱。所以我还不能写关于如何用人工智能产品赚钱的文章。没有证据的观点就是猜测。

好吧，正如前面提到的，我们的企业产品在不到一年的时间内就达到了八位数的 ARR。在 B2B 软件世界中，这可算是很快了。所以在过了一年后，我希望在关于生成式人工智能产品的见解上取得三连胜。

那么第三篇论文的论点是什么？如果你想在生成式人工智能领域持续赚钱，你必须是“企业基础设施原住民”。

什么是企业基础设施原住民？

成为企业基础设施原住民意味着公司从一开始就有实力让其产品用于最艰难的企业环境，例如财富 500 强、受监管的行业、百年老店。

在旧金山和硅谷，我们经常被困在泡沫中。例如，如果我们要为企业开发代码助手，考虑客户时却只想到了硅谷的公司，我们就会错过真正的市场机会。美国前十大银行雇用的软件开发人员比 FAANG 全员都多，而这只是少数几家银行，而且只是美国而已。仅摩根大通一家就有超过 4 万名技术人员。简单的谷歌搜索结果显示，Meta 的员工中有大约 3.2 万名软件工程师。

而且现实情况是，这些非科技企业有很多约束，而这些约束不会出现在个人用户或“数字原住民”硅谷科技公司身上。为了推出 MVP，尽快迭代产品，同时还能获得用户，企业自然会选择消除这些约束，只关注硅谷用户。

“企业基础设施原住民”公司的秘诀在于，他们不会屈服于这种属性，不会在一开始就忽略这些约束。为什么？因为以后再引入这些约束要困难得多。

这当然会更难，因为你可能会做出很多错误的设计决策。例如，你构建系统时可能选择了一种难以容器化的方式，部署到一个自托管系统上（典型的 SaaS 到本地问题），而这正是许多大型受监管公司想要的。或者你忘了基于规则的访问控制和其他安全考虑，因为你只是假设每个员工都可以看到所有数据。或者使用了不符合 HIPAA 合规性的系统，忘记添加审计系统，或者忽略了构建深度遥测的需求。

但还有其他一些本质因素会导致企业在之后很难纠正错误。首先，你可能不会针对现实的完整状态进行迭代，而且企业与消费者其实完全是两码事。例如，在我们的 AI 编程领域，如果你只为单个开发人员进行迭代，你将永远不会意识到一个非常先进的，可以处理庞大、杂乱且通常过时的代码库的推理系统的重要性。这不是你的业余爱好者和硅谷开发人员客户在构建从 0 到 1 的项目时所要做的事情。

另一方面，你的团队可能会发展得太快，以至于你没有合适的专业知识来对这些约束做迭代。例如，为了满足安全约束，客户要在本地运行生成式 AI，所以我们需要本地 GPU，但这意味着我们的计算能力是有限的（大多数应用程序都不会让人们为其购买一个机架的 H100）。这意味着我们需要实施很多非常重要的基础设施优化技巧，以弥补我们无法在后台“扩展算力”的劣势。如果整个团队此时更像是一个产品团队，而不是一个在 GPU 基础设施方面具有专业知识的垂直团队，那么你就无法取得成功。如果你在早期由于忽略了许多约束而加快了步伐，那么当将来不可避免的企业转型到来时，你会发现自己构建了错误的架构和团队。这也能解释为什么生成式 AI 流行之前成长起来的公司通常难以适应这种新模式——他们没有一支将生成式 AI 视为自身 DNA 核心部分的员工队伍。

有些产品必须要有“企业基础设施原住民”团队才行，因为从定义上讲，它们只适用于这类企业。例如，Harvey 对个人用户来说就不合适。但绝大多数问题域都可以选择是否在一开始就考虑这些约束。企业基础设施原住民公司会有意选择克服所有这些约束的障碍。

我想明确一点——“企业基础设施原住民”确实意味着需要付出更多努力来迭代产品。简单来说就是约束更多了。话虽如此，如果这种本能从一开始就融入公司的 DNA，它就会成为一种做事方式。结果你在构建系统时，从一开始就会让系统更容易在这些约束下进行迭代，你还会解决一个巨大而急迫的企业文化挑战。同时，这并不意味着你必须等到某个特性适用于每家企业后才发布它。例如，我们有一些 SaaS 企业层可以更快地部署特性并获得反馈。成为“企业基础设施原住民”意味着，公司中至少有一些人应该积极思考如何让该特性最终能适用于所有企业。

我之所以称之为企业基础设施原住民，而不仅仅是企业原住民，是为了强调基础设施这个部分，这并不奇怪。绝大多数额外的约束都表现为技术软件基础设施问题的形式，因此这凸显了你要在技术栈中特别关注才能做好工作的那些部分，下面很快会具体展开。

这就是为什么我一直认为 enterpriseready.io 等网站上的建议没有切中要害。虽然你确实需要考虑变更管理、基于规则的访问控制、SLA 和支持等问题，才能让你的 SaaS 工具为企业做好准备，但这些指南给人的感觉是“如何修补已构建好的产品”，而不是“如何从一开始就构建正确的产品”。现实情况是，有时过早优化确实会带来回报。我认为在生成式 AI 时代，采用“修补你的产品以备企业使用”的方法比传统的 SaaS 产品更危险，因为引入的约束会更棘手，而且局势变化如此之快，以至于你可能没时间修补你的工具，因为总会有人一直在思考产品方向，并正确地抓住了市场机遇。

来自 EnterpriseReady。发现什么明显错误的地方了吗？

为什么是“非科技”企业？

如果你看到了这里，你可能会纠结于一个核心问题——所有这些都是在谈论向非科技原住民企业销售产品，但 B2C 市场或更多数字原住民科技公司呢？为什么不考虑在这些市场中赚钱？这里的重点是要理解为什么在可预见的未来，生成式人工智能初创公司的收入将来自非科技企业。

选择企业而非个人市场的第一个论点是，企业一直有钱购买软件。微软显然拥有庞大的 B2B 部门，谷歌和 Facebook 也从企业广告商那里获得了巨额收入。如果你今天正在用生成式人工智能构建产品，那么今天的价值主张就是完成更多工作或做更多创造性工作。企业愿意为这一价值主张投入巨额资金，说服几家大企业就相当于说服成千上万的个人。

非科技企业优于科技企业的第一个理由是，所有大型科技公司都非常重视人工智能，并且拥有大量资金来尝试自行开发。这里指的不仅仅是 FAANG 公司——开源 LLM 和易用的 LLM 相关框架的可用性使拥有开发 DNA 的公司更愿意自行开发而不是购买服务。所有大型科技公司都在尝试自己抓住市场机会。想象一下我们试图将 Codeium 卖给微软，这可不是什么好事。

大型科技公司对构建生成式 AI 产品的兴趣也应该会让任何从事 B2C 业务的人们感到害怕，因为大型科技公司已经拥有庞大的 B2C 基础资源与巨大的分销渠道。我们已经看到了这一点。Perplexity 正试图在 B2C 搜索市场与谷歌竞争，他们还必须做一些备受质疑的事情，比如在后端使用谷歌。另一方面，Glean 正在进军 B2B 搜索市场，并且在这个领域做得很好，而大型科技公司目前还没有太多动作。

大型科技公司的兴趣也让其他人更难争夺科技原住民企业的业务机会，因为这些企业通常比非科技原住民公司受到的约束更少。大型科技公司的速度足够快，可以解决那些较容易克服的约束，但初创公司可以利用他们的速度来解决非科技原住民企业可能遇到的更复杂的约束，从而脱颖而出。我们在 Codeium 经常看到这种情况。尽管几乎每家大型科技公司都有代码助手产品，但对于许多非科技原住民公司来说，我们到头来并没有与它们中的任何一家竞争，因为我们的产品以独特的方式应对了这些公司所面临的约束。我们将在下一节中详细说明这些约束都有哪些，以及如何解决它们。

我知道大家现在可能在想什么。但是 OpenAI 呢？他们凭借 ChatGPT 在 B2C 领域取得了巨大成功。我首先承认，考虑到 OpenAI 已经研究这项技术很长时间，这是一个很大的例外。如果你现在开始构建产品，你并不会有他们这样的技术。实际上，随着用户开始尝试其他模型（例如 Anthropic 的 Claude 3.5 Sonnet 似乎备受开发人员的欢迎），以及用户尝试 ChatGPT 以外的基于聊天的产品（例如 Perplexity），人们现在想知道 OpenAI 是否真的能长期留住客户。B2C 市场是无情的。

如何成为企业基础设施原住民企业

好的，希望到现在为止我已经让你理解了应该成为企业基础设施原住民企业背后的逻辑。但在实践中到底意味着什么？我们从一开始需要注意哪些事项？

还好，我可以回来讲讲我们在 Codeium 积累的经验。

数据是许多企业基础设施原住民考虑的根本原因之一。与现有的 SaaS 解决方案不同的是，在现有 SaaS 解决方案中，数据虽然可能很敏感，但可以通过系统来跟踪它们，而 LLM 的大黑匣子属性则增加了很多不确定性。无论是用于训练的大量数据，还是对所生成数据的可追溯性缺乏透明度，都是这种不确定性的体现。

安全性

要使生成式 AI 工具发挥作用，你需要处理一些隐私数据。可以确认的是每家企业都有针对你的工具要处理的那些数据的，关于隐私和安全性的现行政策。例如，我们在 Codeium 处理代码，如果公司使用 SCM 的自托管版本，那么他们已经证明他们的代码默认策略是不将其发送到第三方服务器，即使第三方拥有所有认证，例如 SOC2 合规性，也不行。

在基础设施方面需要考虑的最重要的一点是你应该提供的部署选项集合。一般来说，你要么需要一个完全离线部署的自托管部署选项，要么至少需要一个混合版本，其中所有的持久隐私数据（或从隐私数据派生的信息）都保留在客户的租户内。你应该考虑将解决方案的服务端容器化，以便简单地部署它（单节点系统使用 Docker compose，多节点系统使用 Kubernetes/Helm），并确保客户端具有安全指向客户服务器实例的功能。这些部署面临许多挑战，尤其是自托管部署。其中一些包括：

• 确保你设置了自己的镜像扫描，这样就不会出现安全漏洞，像 Google Artifact Registry 这样简单的扫描程序都可以。客户也会使用自己的扫描工具，而且有很多不同的扫描工具，所以要做好准备。

• 建立持续更新和发布的系统（大多数客户更喜欢“拉取镜像”更新解决方案，而不是供应商提供的“推送镜像”方法）。实际的更新频率取决于你期望的产品发展速度——如果用户体验变化很大，也许最好每隔几周发布一次，但如果用户体验相对稳定，而且更新主要是研究性开放式推理改进，那么每月或更短一些的发布时间应该没问题。更快的发布周期的一个普遍好处是，如果发布版本中存在错误，那么在稳定版本中修复它们所需的时间会更少（如果问题严重，则需要单独的补丁）。

• 确保你的方案既能跑在超大规模集群，也能在本地 OEM 可以提供的机器上运行。我可以写一整篇文章来讨论谁能获得哪些 GPU 和背后的政治，但你经常会看到各种差异，例如 Azure 和 GCP 上提供 1xA100 和 2xA100 实例，但 AWS 上只有 8xA100 实例可用。正确调整昂贵的 GPU 硬件规模以尽可能降低解决方案的 TCO，是创建更好的 ROI 故事的关键所在。

• 一定要帮助客户在他们的第一批 GPU 部署中跑通一个部署流程。

另外，即使你认为自托管或混合部署过于复杂，你仍需要考虑为你的 SaaS 解决方案提供许多证明和认证。SOC2 Type 2 是基本要求，这要求在一段时间内设置控制措施并接受对这些控制措施的遵守情况的审核，因此需要数月的准备时间才能获得此认证。ISO 27001 更进一步，欧洲公司经常询问这一条（尽管由于 GDPR 的要求，即使有此认证，你可能仍需要考虑在位于欧盟的服务器托管你的解决方案）。最后，如果美国联邦政府是潜在客户（这里有很多利润空间），你将需要考虑 Fedramp（针对民间机构）和 Impact Levels（针对国防部）认证。要获得这些认证，你需要做很多事情，例如容器化你的应用程序，这是你在自托管部署中必须做的事情。如果你在构建 SaaS 应用程序时没有考虑到这一点，做起来就会困难很多。

最后一点比较明显，如果你最后是在自己公司这边处理客户数据，就不要用这些数据来训练。听起来很简单，但这仍是客户最大的担忧，因为这种风险依旧占据着媒体头条。每一份合同都会要求写明这一点（如果不写明，则会在红线中添加进去）。我们从未尝试过以折扣换取使用客户隐私数据训练通用模型的权利，因为从未有任何迹象表明人们会接受这种做法。这种软件并不昂贵，公司甚至不会考虑折扣和 IP 隐私之间的权衡，尤其是在判例法尚未建立的地区。

有些人可能认为现实并不公平。虽然很多公司确实在使用大型科技公司的云服务，但潜在客户对初创公司的安全性的信任度要低得多，因此他们可能对安全性的要求比对大型科技公司的要求更高。这就要求你诚实地说明你的解决方案在各种部署选项中都有哪些功能。你的自托管选项通常不会像 SaaS 托管选项那样有着丰富的功能，因此，如果你用的是自托管版本，而不像大型科技公司对手可以使用 SaaS 版本，你是否会让自己陷入困境？

合规性

只需搜索“生成式 AI 诉讼”，你就会明白我的意思。由于这些 LLM 是用大量数据训练的，并且不可能将这些概率系统的输出追溯到特定的训练数据示例，因此这里存在大量之前没遇到过的全新合规性问题。

首先，许多模型都是使用它们可能不应该使用的数据来训练的，例如受版权保护的图像或非授权代码。许多企业法律团队担心使用这样的系统会导致他们在未来卷入诉讼（就判例法而言，这个领域非常落后）。因此，如果你是企业基础设施原住民，你需要控制用于训练模型的数据，无论你是在训练自己的小型模型，还是在开源模型上执行其他任何针对任务的预训练过程。可以考虑实施数据清理措施，这样你就可以自信地向企业声明，你不使用受版权保护的材料进行训练。还可以多做一点，例如我们从训练数据中删除了所有非许可代码，也删除了所有与明确的非许可代码具有相似编辑距离的那些代码（以防其他人复制粘贴了那些非许可代码却没被发现）。即使模型本质上是概率性的，主动充分展示你们的做法也会增加最终客户的可信度，毕竟他们的法律团队可能会在你提供任何价值之前就把你拒了。

哦，关于这个话题，不要违反其他服务条款。OpenAI 的服务条款规定，你不能使用他们的模型的输出作为训练材料。所以不要这样做，你会惊讶地发现有多少人忽略了这一点。

你可以主动做很多工作，但有眼光的企业会发现这些模型是概率性的，并希望模型生成的数据能有某种保证。这里你就必须巧妙地构建一个归因系统，可能基于编辑距离和相似度分数的一些启发式方法。例如，我们构建了更高级的归因过滤器，而不仅仅是其他工具采用的简单字符串匹配方法。这往往还不够。我们为所有被允许的代码匹配构建了 归因日志，为特定受监管行业构建了 审计日志，内置了为医疗保健公司提供 BAA 的支持，等等。所有这些很快就会变成基础设施问题。

你确实需要非常认真地对待这一点，因为作为一家初创公司，与安全性的主题类似，你需要有行业领先的赔偿条款，或者至少与大型科技公司提供的条款相匹配，才能在风险角度上获得客户的认可。你要对解决方案的这一方面有真正的信心，否则这种条款会有很大的危险。

这些工作流都不一定“令人兴奋”，因为从最终用户的角度来看，产品并没什么变化，但它们依旧是必要的。

个性化

你认为一个通用系统经过大量公开数据的训练就能为企业解决问题吗？

大多数企业认为他们的工作很特别，而事实是，即使他们的技术栈不是那么独特，他们也确实有大量隐私数据，这些数据与想要生成更多隐私数据的人工智能系统高度相关。对我们来说，现有的私有代码库是创建高质量结果的最相关信息，同时它们能尽可能减少幻觉，因为它们包含现有的库、语义、最佳实践等知识。

又要提到安全性了，你可能也习惯了。你无法在每次推理时都处理所有原始私有数据，因此你可能需要对数据做一些预处理，并且必须将这些信息保存在某个地方。这就是纯 SaaS 解决方案的问题所在。即使你能做到，也要付出更多努力才能说服企业客户允许初创公司拥有这种访问和控制他们数据的权限，这就对你能做到的个性化程度带来了很大约束。

问题还不仅限于他们的 IP 与外部来源通信时的安全性考虑。基于角色的访问控制（RBAC）对于 AI 应用程序是非常重要的，因为 AI 工具本身就能提供一种途径，将只有某些员工才能访问的数据广泛泄露给其他员工。同样，这种问题也是新出现的，因为生成式 AI 是第一批可以创建出和已有数据很像的新内容的技术之一。一个极端的例子是，事实证明，对于政府项目来说，一堆数据单独存放时可能不是问题，但组合在一起时就会变成机密数据。个性化和人工智能技术具有整合信息的能力，但应谨慎对待。

每当你计划使用隐私数据时，都需要考虑许多因素，尤其是对于较老的企业更是如此。使用 AI 技术时更要注意，因为输入数据的质量在很大程度上决定了生成数据的质量。现有数据的年限是多少？数据与当前手头的任务有多相关？哪些数据源更重要？如何平衡来自多个数据源的信息？

个性化是每家初创公司都应该利用的一个轴心，因为它增加了差异化价值，而大多数大型竞争对手推出这些价值的速度会更慢——这些系统具有很大挑战性，这里的错误很容易导致他们陷入巨大的公关噩梦。不过我们应该知道有很多基础设施可以做好这件事情。

分析和投资回报率报告

分析对于企业软件工具来说不是什么新鲜事物，但鉴于市场对 AI 技术的期望过高，AI 非常需要分析技术。我们可能很快就会摆脱这种过高的期望，但这并不能改变这样一个事实：大多数潜在客户并不完全清楚他们对生成式人工智能的期望是什么，也不知道如何量化其价值。

证明投资回报率可能是最难的问题。即使对于像代码生成这样具体的事情，其中生成式人工智能工具的输出是可以验证的（代码必须编译、运行并执行预期的任务），所谓“开发人员生产力”的含义也非常模糊。它指的是拉取请求周期时长吗？也许吧，但那里有太多混杂变量，很难真正评估单个工具是否对这个值的任何变化负责。是接受的代码量吗？也许这是一个很好的价值代表，但很明显，一半的代码来自人工智能并不意味着开发人员的生产力提高了一倍。我可以想象，对于营销文案等应用来说这更加困难，因为这些应用的输出结果首先就不一定是可验证的。我首先承认我在这里真的没有答案。证明投资回报率是一个非常困难、难以捉摸的问题。

话虽如此，生成式人工智能确实受益于这样一个事实：大多数领导者确实相信这项技术会增加价值，并且当员工说他们使用此类工具感觉效率更高时，领导会信任他们。因此，作为供应商，你应该考虑如何让你的企业客户逐步实现更多价值。例如，一个好的开始是按团队来统计使用率数据。这样，管理员就可以了解哪些组别获得了更多价值，从他们那里收集最佳实践，哪些组获得的价值较少，可能需要更多支持。

延迟

我们在 Codeium 博客中经常讨论延迟。延迟约束对生成式人工智能应用非常重要，因为它们直接影响模型选择等事项。例如，代码生成的自动完成任务需要在数百毫秒内运行完毕，开发人员才能及时看到建议。但由于 LLM 的自回归性质，这就意味着所有的大规模基础模型都用不了了。不管是量化还是推测解码之类的方法都没法解决超大模型的延迟问题。

模型推理并不是延迟的唯一来源。所有个性化工作也可能带来延迟。推理之前的任何检索都需要符合延迟预算。将数据发送到单独的服务器？你要考虑网络延迟，特别是在处理视频等密集数据时。对模型输出进行后处理工作，例如对照归因过滤器来做检查？那就意味着这些过滤器也得是低延迟的。

不出所料，这些都是软件基础设施问题。你可以构建世界上最智能的系统，但如果它的运行速度不足以满足负载和用户的需求，它也就没什么用了。

规模

这一点更本质一些，它涉及上述所有挑战。当你意识到这些企业的用户 / 员工规模、他们拥有的数据规模以及私有基础设施的复杂性时，所有这些挑战都变得更困难了。我们的客户拥有数万个存储库、数亿行代码和数万名开发人员。这些数字将扩展你的系统的所有方面。

你是否创建了一个自托管系统来索引代码库以实现个性化？但如果现在客户有数万个存储库怎么办，它们真的都对个性化有所帮助吗？客户如何指定哪些是好代码，坏代码？你如何在这种规模下管理对这个索引的更新工作？如何在不影响延迟的情况下将其扩展到数万名开发人员？你如何管理数千个用户组和访问控制任务？

不幸的是，我没有时间或空间来一个个回答这些问题，但如果你不想在以后感到惊讶和手忙脚乱，那么在设计和构建解决方案时，你应该问自己这些问题。

总   结

从许多方面来看，这篇文章解释了 Codeium 迄今为止在 B2B 领域的成功，让我们深入了解了如何思考和合理化这个领域。与此同时，我希望我的这个论点是错的，这可能会出乎你的意料。

我希望看到初创公司即使在 B2C 和技术原住民的 B2B 市场中也能成功与大型科技公司竞争。我希望看到各种形式的企业最终将人工智能视为自己更向技术原住民靠拢的原因。自私地说，我希望看到像 Codeium 这样的 B2B 成功企业被视为拥有最佳人工智能产品的创新型人工智能公司，而不仅仅是“企业级解决方案”供应商。

但如果你是一家新创业公司，今天想通过生成式人工智能获得可持续收入，我希望这篇文章能对你有所帮助！作为一家企业基础设施原住民公司，你要习惯这种不舒服的感觉。

原文链接：

https://www.latent.space/p/enterprise?utm_campaign=post&utm_medium=web