AI 初创公司最危险的做法：就是为其他 AI 初创公司构建产品 [译]
Codeium 如何在十个月内从 0 增长到超过 1000 万美元？enterpriseready.io 的盲区在哪？一次关于“企业级基础设施原生”（Enterprise Infra Native）的全面思维导图！
来自 swyx：很高兴再次欢迎 Anshul 成为我们首位“三度回归”的客座作者！他之前在 Latent Space 发的两篇文章关于 AI 产品思维都十分受欢迎，而自那之后，Codeium 的装机量已经增长了超过 10 倍（参见 VS Code 插件市场数据），并且完成了 6500 万美元的 B 轮融资 与 1.5 亿美元的 C 轮融资。现在，他们推出了 Windsurf（他们自己的 Agentic IDE） —— 乍一看好像又是一个 VS Code 分叉版本，但我可以作证，今天的文章并不是为了营销 Windsurf 而写的。只不过作为一个旁观者，很明显地能看出，文中的思路与 Windsurf 的发布方向何其契合——从第一天开始就带着“企业级 AI”基因来更慎重地前进。不过，目前市面上很多“企业级 AI”产品也确实显得空洞又模糊，因为要兼顾“既有看点又足够安全”是非常困难的。
在一众长得都差不多的 AI 产品（他们最初就是从另一个 Copilot 的思路起步），Codeium 真的走出了一条与众不同的路，我们非常有幸能在他们构建产品的过程中就能学到他们的思考方式。
我们仍在收集对下一期回顾节目的问题和留言，也在筹备在 OpenAI DevDay（新加坡）、NeurIPS（温哥华）等线下活动及其他线上聚会进行交流，可以在我们的日程上找到更多信息。欢迎加入我们！
以下内容全部来自 Anshul，所有插图都是我（swyx）拙劣的尝试。
2022 年 11 月，我为 Latent Space 撰写了第一篇客座文章，并且（或许过于乐观地）希望它能成为一系列三篇博文的起点：
第 1 部分：如何选择一个长期的 AI 产品策略
第 2 部分：如何让你的 AI 产品脱颖而出
**第 3 部分：**如何通过你的 AI 产品赚钱 —— ← 我们现在就来讲这个！
好消息是，我们的企业级产品在不到一年的时间里从 0 做到了超 1000 万美元的年度经常性收入（ARR），所以是时候来聊聊第三部分了。但或许有点出人意料的是，要想达成这一目标，绝不只是依赖 enterpriseready.io 等网站上那种清单式的方法。
我在 2022 年 11 月写第一篇文章时，已经对这三部分都形成了自己的观点。但当时 Codeium 刚刚上线，所以虽然我可以论证第一个观点——深刻理解经济性和用例细节能构建强大的产品策略，但我们当时并没有在同类 AI 代码助手中完全脱颖而出（记得那时还只有智能补全的功能吗），更谈不上盈利。如今时过境迁，越来越多的公司意识到，不能只是做一个“调用模型 API”式的拼装产品，既要保证质量，也要兼顾成本。他们也开始聚焦更深入的技术，比如针对特定任务的模型、自主部署开源模型、RAG（检索增强生成）等等。
到了 2023 年夏季，我们已经正式推出了 IDE 中的聊天式体验（GA 版本），并带来类似 code lens 以及将代码直接插入到开发环境等一系列在当时看来非常创新的功能（试着回想一下没有这些功能的日子吧）。GitHub Copilot 直到数月之后才正式推出 Chat 功能。彼时，我已经相当肯定第二个观点——UX 设计对于构建差异化护城河至关重要，而且不论是短期还是长期都如此。一年多之后的今天，这一点似乎更加明显，人们开始真正理解：要打造一个直观而强大的用户体验，去尽量“隐藏”底层模型和推理的复杂度是何其重要。比如说 Perplexity 或 Glean，甚至我们所在的代码领域，也有 Zed 或 Cursor。它们的核心技术当然很棒，但用户体验才是真正关键。
然而，在那时，我对第三个观点（如何通过 AI 产品赚钱）仍然有些底气不足。因为 Codeium 面向个人开发者的版本依然免费，企业付费产品也才刚刚推出，还没有形成规模化的收入。没有实践成果的支撑，仅仅是空想也无法让人信服。
但现在不同了，我们的企业级产品在不到一年内就超过了一千万美元 ARR。对 B2B 软件来说，这已经是非常快的增长速度。所以，现在正是时候写下我的第三个观点。希望能像之前的前两篇文章一样，再次帮助大家！
那么第三个观点到底是什么？如果想在生成式 AI 领域实现持续盈利，你的公司就必须是“企业级基础设施原生”（enterprise infrastructure native）。
Latent Space 是由“AI 工程师”社群支持的出版物。如需获取更多最新文章并支持我们的工作，欢迎订阅（免费或付费都可以）。谢谢！
什么是“企业级基础设施原生”？
“企业级基础设施原生”意味着：从公司创立之初，就要锻炼好让产品能够在那些最严苛的企业环境中部署和运行的能力。
也就是面向《财富》500 强、强监管行业，以及一些历史百年的老牌公司等。
在旧金山和硅谷，大家通常都活在一个小小的“科技泡泡”里。比如，如果要做一个面向企业的代码助手，只考虑硅谷的企业就会错过真正“有钱途”的市场。美国前 10 大银行的开发者数量，比全部 FAANG 公司加起来都要多，而这还只是美国的银行业而已。摩根大通（JPMorgan Chase）单单就拥有超过 4 万名技术人员，而谷歌一下子搜到的Meta也大约有三万多工程师。
而这些非纯粹的“科技企业”往往会遇到很多和个人用户或“数字原生”硅谷公司完全不同的约束。如果仅仅为了尽快推 MVP、快速迭代，让产品跑通，就会自然选择忽视那些复杂的安全、合规、数据管理等企业级需求。
**“企业级基础设施原生”公司的秘密在于，它们从一开始就没有向这种“只管快速出功能，不管复杂约束”的冲动妥协。**为什么？因为以后补上会更加困难。
当然，最直观的原因在于：你可能做出了错误的架构决策。例如，如果前期完全依赖 SaaS，那么后面想要让客户自托管就会非常麻烦（典型的从纯 SaaS 转向本地部署的难题）。又或者，你可能从未考虑基于角色的访问控制（RBAC），或者为了图省事而使用了一些在 HIPAA 等严苛法规下无法通过的服务。再比如，一开始没有考虑到审计系统或者深入的监控追踪需求等等。这些都会让之后改造的成本无限放大。
但还有更深层次的原因：如果你从未与企业的全部现实场景接轨，你在迭代时就会忽视那些和个人用户截然不同的需求。以我们所做的 AI 代码助手为例，如果只服务那些个人开发者，就不会意识到在一个庞大又老旧的代码库中，AI 对深层逻辑和大规模协同编程的能力要求有多高。而这正是许多传统大公司实际的研发场景。
再者，你在早期如果只为“小而快”的场景构建，就会招来一批以产品为中心的人才，而缺乏对企业基础设施有深度经验的工程师。例如，在客户本地部署 GPU 环境时，由于算力受限，往往不能像云端那样“无限扩展”，这对基础设施优化能力就提出了极高要求。如果你的团队没有 GPU 优化、分布式系统等领域的专家，后期去补齐这块能力就会非常被动。同理，很多在“前生成式 AI 时代”崛起的公司，现在转型做生成式 AI 也很困难，因为他们团队里根本没有把生成式 AI 作为核心来思考和构建产品的人。
有些产品类型一出生就带有“企业基础设施原生”属性，因为它们只在这些场景下才有用，比如法律 AI（Harvey 之类）就不适合个人用户。可绝大多数产品并非如此，创业者有机会在初期选择是否面向这些苛刻的企业。那些选择了直面企业需求、接受所有复杂约束的公司，就是真正的“企业级基础设施原生”公司。
需要再次强调的是，“企业级基础设施原生”会增加迭代的难度——因为要应对的约束更多。但如果把这种思路在公司创立之初就融入到文化里，它就会成为一种自然而然的工作方式，你会从一开始就搭建好能适应这些复杂约束的系统，也就能避免后面出现大规模的文化与技术挑战。当然，这不意味着每个新功能都要等到在每个企业环境下都能跑通才上线。我们自己就提供了 SaaS 的企业版本，可以更快地更新功能、获取反馈。但“企业级基础设施原生”的关键点在于，在做任何重大功能时，团队里的部分人应该已经在思考“如何让这项功能最终能兼容各种企业环境”。
我之所以称之为“企业级基础设施原生”而不是“企业原生”，是想突出“基础设施”的重要性。在大多数情况下，这些额外的企业级需求其实都体现为对软件底层架构的要求，因此要在这部分加倍投入，才能真的把企业市场拿下。
这也就是为什么我觉得 enterpriseready.io 那种针对“企业就绪度”的思路其实有点问题。它给人的感觉更多是“把已经做好的产品如何补丁式地包装成企业版”，而不是“从一开始就搭好适合企业的底层架构”。有时候在传统 SaaS 领域，这种做法还能用，但在生成式 AI 时代，这种差距会被无限放大——很多企业对数据合规、隐私保护、可控性等方面的需求更加“变态”，而且整个市场发展速度快得惊人。如果产品一开始就没有纳入这些视角，你可能根本没机会再补救，因为另一个真正“从底层为企业做起”的竞争对手会迅速占领市场。
（摘自 EnterpriseReady。能看出什么明显问题吗？）
为什么要选择“非科技”企业？
说到这儿，可能有人会问：你一直在讲传统或非互联网原生的企业，可是 B2C 和那些“数字原生”科技企业难道就不能赚钱了吗？为什么你好像完全忽视了这些市场？答案是，对于近几年想在生成式 AI 领域盈利的初创公司来说，最大的收入来源短期内确实还是那些“非互联网原生”的大型企业。
首先，对比个人消费者，企业向来更愿意在软件上花钱。
微软当然有非常大的 B2B 业务，Google 和 Facebook 也有很大一部分收入来自企业广告主。如果你的 AI 产品主打的是提升工作效率或创造力的价值命题，企业会出得起更大预算。而且只要谈成少数几家大型企业，收入就能抵得上成千上万的个人付费用户。
其次，这些传统的、非互联网原生的行业往往更倾向于“买”而不是“自己做”，而科技企业则可能直接把 AI 当做核心战略自己研发。
想想看，如果你去跟微软推销一款 Codeium 一样的代码助手，对方可能会自己有 Copilot，不会采购你的产品。更何况大厂们实力雄厚，自己做也能做得不错。
而在 B2C 市场，更是直接面对大厂们现有的巨大用户基数和分发渠道，竞争异常激烈。
早期大家看到 Perplexity 要挑战 Google，就很难，不得不在后端调用 Google 本身。相对而言，Glean 针对 B2B 搜索市场，发展就相对顺畅得多，因为大厂们在 B2B 搜索上还没怎么发力。
大厂的这种“自研倾向”还会影响到跟科技企业合作的可行性，因为后者更少那些“非互联网原生”企业面临的限制。例如，数据怎么传输、安全怎么保证等，对科技公司来说都不是大问题，可传统大型企业却必须非常谨慎。所以，在这个过程中，初创公司其实更能靠快速迭代和灵活应对拿下那些大厂暂时顾不到的、更加复杂的传统企业需求。我们在 Codeium 深有体会：那些大厂自己做了类似的代码助手，但我们并没有跟他们在多数“老企业”身上直接竞争，因为我们能解决他们最在意的合规与安全问题，而大厂的方案没法完全满足。
或许有人会举 OpenAI 的例子。他们在 B2C 层面的成功真的非常特殊：毕竟他们在这个领域耕耘已久（不是创业者从零开始就能复制的），而且很多人也在讨论 OpenAI 在未来是否能持续保持市场地位，毕竟竞争对手不断涌现（例如 Anthropic 的 Claude 3.5 Sonnet 在开发者群体里也获得不少好评），以及其他基于聊天方式的产品（如 Perplexity）的崛起。B2C 市场向来残酷。
如何成为“企业级基础设施原生”？
好了，如果我已经说服你必须做一家“企业级基础设施原生”公司，那么具体要怎么做呢？需要在一开始就注意哪些问题？
幸运的是，我可以基于我们在 Codeium 的实践经验来分享一些思路。
在企业环境中，数据往往是决定绝大多数“基础设施原生”需求的核心原因。与传统 SaaS 相比，生成式 AI 对数据的使用和追踪更加复杂——既要训练大模型，又难以追溯模型输出的精确来源，这就带来了额外的合规与隐私担忧。
安全（Security）
要想让生成式 AI 工具真正好用，就一定会处理企业的某些私有数据，而企业对于这些数据的安全与隐私有着十分严格的内控流程。比如说，我们 Codeium 要处理代码，如果对方公司自建了 SCM 系统，往往说明他们默认就不愿意把代码上传到第三方的云端。
在底层上，最关键的是要想清楚部署方式的问题。很多时候，客户需要一个完全隔离的自托管（air-gapped on-premise）版本，或者至少是混合方式（私有数据只存储在客户自己服务器上，模型推断可由服务端托管）。因此，你要从一开始就需要考虑如何把服务器端容器化（比如单节点用 Docker Compose，多节点集群用 Kubernetes/Helm），以及客户端如何配置才能安全地访问这些自托管节点。
自托管部署非常不易，主要包括：
必须做自己的镜像安全扫描，确保没有漏洞（如用 Google Artifact Registry 之类）。客户自己也会用各种扫描工具，你要能配合他们的流程。
要有一套持续更新和发布的机制（通常客户更希望“拉取新镜像”而不是由你直接“推送更新”）。具体更新频率看你产品迭代速度，UX 改动多的话或许要每两周发一次，不然可能一个月或更久发一次也行。但更新太慢也不好，因为万一版本出现严重 BUG，修复周期就会拉长。
要能适配客户不同云和本地 GPU 环境，有时候政治或供应链原因导致 GPU 资源格局混乱，比如在 Azure、GCP 上常见 1×A100 或 2×A100，但是在 AWS 上普遍是 8×A100。而这些 GPU 都非常昂贵，所以在给客户讲 TCO（总体拥有成本）时，需要在性能和成本之间找到平衡。
很多时候，你还需要“手把手”帮客户做第一次 GPU 部署，因为这可能是他们第一次在本地搭 GPU 环境。
即使你不打算做完全自托管或混合部署，你的SaaS 方案也必须满足一系列安全合规要求。SOC2 Type 2 认证几乎是入门级标配——它需要公司建立相应的内部管控并在一段时间内持续执行，才能通过审计。所以可能得花上几个月的时间才能拿到证书。ISO 27001 相当于更高一级，通常欧洲公司会更关注；你可能还需要在欧盟数据中心来部署以满足 GDPR 要求。再者，如果你的目标客户包括美国政府部门，就得考虑 FedRAMP（针对联邦文职机构）或 Impact Level（针对国防部）的合规要求。
这些认证其实也要求你具备和自托管类似的容器化与安全管控能力，只是以不同的形式体现而已。如果你一开始就只把产品做成一个“云端大杂烩”，后面要再改造去满足这些合规要求会相当痛苦。
最后，最基本但又最重要的一点：如果你的系统会处理客户的私有数据，一定不要拿这些数据去训练通用模型。这看似很明显，但很多公司确实会忽视这一点，而“AI 工具滥用客户数据”也正是目前媒体报道最多、最让企业紧张的。大部分企业在合同里都会明确提出“不得用客户数据训练模型”的条款。我们自己从来没有想过要“打折换取客户数据授权”这种事情，因为几乎没有企业会愿意做这种交换——尤其在法律风险尚不明朗的当下。
另外还有一点残酷的现实：跟大厂相比，企业对创业公司的信任度往往更低，会要求更严格的安全保障。这就导致一个悖论：如果客户测试了你本地部署的版本（功能相对有限）却又拿大厂的 SaaS 做对比（功能丰富），你其实会处于劣势。
合规（Compliance）
只要搜索一下“生成式 AI 诉讼”就知道，现在对大模型的法律质疑非常多。大模型在训练中使用了海量数据，包括大量可能带有版权的图片、代码、文本，而且模型输出也难以追溯具体来源。对企业来说，万一踩到版权或机密的雷区，就会很麻烦。
举个例子，在我们代码领域，许多模型是基于含非开源许可的代码库训练的。企业法务部门很担心这些模型输出的内容有版权风险，将来可能被起诉。因为这是一个新领域，相关案例法并不明确。所以如果想做“企业级基础设施原生”，你就得确保对训练数据有完全可控和可追溯的能力。比如说，如果你自己或基于开源模型做特定任务的微调，就要确保数据源是合规的。
在 Codeium，我们会清洗数据，比如在训练过程中去掉所有版权不明或不允许商业使用的代码片段，并且在此基础上再把和这些违规片段“编辑距离”过近的代码也一并剔除，以防有人复制粘贴未经授权的内容。这种对细节的谨慎投入很能给客户留下好印象，让他们觉得你在尽力降低潜在诉讼风险。
另外，别违反别人的服务条款。OpenAI 的服务条款就明确禁止你用它们模型的输出去训练新模型，可你会惊讶地发现其实很多公司就这么做了。
尽管做了种种预防措施，很多企业还是会要求你对模型输出带来的潜在版权问题提供某种形式的“担保”或“免责条款”。因此，就需要构建归因系统（比如用编辑距离、相似度匹配等手段）来识别哪些生成内容可能与已有版权内容过于相似。我们做了比简单字符串匹配更深入的“归因筛查”，还为特定行业（如医疗）做了审计日志，也能给客户签 BAA（商业伙伴协议）等等。这些对用户端而言都不算“新功能”，但在企业评估中非常重要。
作为一家初创公司，如果你要跟大厂同场竞技，往往会被要求提供至少与大厂同级的侵权赔付或免责条款（indemnity），若你没有在模型和数据流程上做好足够功课，贸然承诺就有极大风险。
个性化（Personalization）
很多人以为：只要有个通用大模型，能处理大量公开数据就够了。实际上，大多数企业都觉得自己的情况“很特殊”，而且的确拥有很多私有数据，可帮助模型更好地产生贴合实际业务需求的输出。以我们的代码助手为例，若能学习企业现有的庞大内部代码库（包含私有函数库、定制化语法和最佳实践等），那生成的代码会更精准且更少胡编。
但又回到安全：你不可能每次推理都把企业全部代码打包发到云端吧，这会面临安全风险、网络延迟等问题。通常要先在本地做一些数据预处理并缓存结果，然后只在推理时发送必要的向量或摘要。这样一来，又涉及到私有数据如何存储、如何划分权限等问题，特别是传统大企业常常需要非常复杂的 RBAC 机制。生成式 AI 最大的“危险”之一是，它可能无意中把只有小范围人能访问的数据在企业内大范围传播。甚至还有些政府或国防项目要求：有的非敏感数据一旦组合在一起就变敏感。AI 恰恰最擅长信息整合，因此一定要谨慎对待。
对老牌企业来说，底层数据质量和分布也非常复杂。越大的组织，代码和文档越庞杂，你要考虑它们的时效性、相关度、更新频率，甚至还要考虑哪些仓库才值得去“学习”，哪些代码早就废弃了。如何对这些私有数据进行个性化索引和更新，既保证推理效果又不拖慢系统？ 这些都需要强大的“企业级基础设施”能力。
在我看来，个性化是所有初创公司的一个绝佳差异化机会，因为那些大厂如果做不好隔离和安全，一旦出问题就会是爆炸性的负面新闻，所以它们会谨慎推进。但话说回来，这条路并不好走，需要付出大量底层架构工作。
分析与投资回报（Analytics & ROI Reporting）
分析功能对企业软件来说并不新鲜，但对于生成式 AI 来说，格外重要。原因就在于目前市场对 AI 的期待被媒体和各种炒作推到一个相当高的水平，客户自己也常常搞不清怎么衡量 ROI（投资回报率）。
衡量生产力提升其实并不容易。即使像代码生成这样的场景，结果看似容易验证（代码能不能编译、能不能运行），但真正要衡量开发者生产力还有很多干扰因素。是看 PR 的迭代周期吗？那会受团队协作、项目管理等各种因素影响。是看 AI 生成的代码量占比吗？也不一定能代表生产力翻倍。所以我承认，这本身就是一个困难且没有完美答案的课题。
不过，好在大部分企业领导层对生成式 AI 还是抱有一定的信心，所以只要员工主观上感觉生产力提升，通常领导也会认可。但你最好能提供分角色、分团队的使用数据，这样管理者能发现哪些团队用得好，为其他团队提供最佳实践，哪些团队用得少，就针对性地做培训或动员。
时延（Latency）
我们在 Codeium 的博客常常谈时延问题。时延在生成式 AI 中真的太关键了，因为它直接决定能否支撑某些使用场景。仍以代码助手为例，自动补全需要在几百毫秒内完成推理，否则开发者根本看不到结果。大模型自回归（autoregressive）生成的特性决定了如果模型规模过大，时延就会无法接受，无论你做多少量化或推测式解码（speculative decoding）都没用。
而推理又只是时延的一部分，任何个性化检索或外部调用都要算在整体延迟里。推理结束后还要做相似度筛查或版权过滤吗？那也要时间。总之，从端到端的系统设计上看，一旦其中某个环节的延迟高，就会把整个用户体验拉跨。
扩展性（Scale）
最后，“可扩展性”是一条贯穿所有环节的主线。企业部署意味着用户量大、数据海量、内部结构复杂。我们有客户有成千上万的代码仓库、数亿行代码和上万名开发者，这对任何环节都是极大的压力测试。
比如说，你在自托管环境里做代码索引来提升个性化效果，这没问题。但要是客户有几万库，这些库里可能有不少陈旧或无关的代码，用户角色又各不相同，该如何优先索引？如何把垃圾信息过滤？如何在规模化的同时保持推理的低时延？如何处理成千上万的用户组和访问控制？……
这些问题我没法在这里一一详解，但创业者在设计产品架构时，应该要对这些问题“有所准备”，而不是等到客户谈了一半才发现方案落地不了。
结语
在某种程度上，这篇文章也是对 Codeium 目前 B2B 成功的一次复盘，展示了我们思考并打磨产品的方式。不过，有点意外的是，我个人其实希望我的这条“第三观点”是错的。
我真心想看到有创业公司能在 B2C 和互联网原生企业市场里也能打败大厂。我也希望更多传统企业能够拥抱 AI 而逐渐变得更“数字原生”。从 Codeium 的角度来说，我也希望我们这种面向 B2B 的企业级 AI 公司，既能拥有“企业就绪度”，也能被视为真正的技术创新者。
但如果你问现在的初创公司要“最快”或“最稳妥”地靠生成式 AI 来赚钱，我的建议仍然是：让自己成为“企业级基础设施原生”的公司。 这要求你对企业的苛刻需求保持敬畏和耐心——但只要能做到，就会有非常可观的回报。
Codeium 的小彩蛋
（swyx 插话）和上次文章一样，你可以看看 Codeium 的企业版，或观看 Codeium 最新产品 Windsurf 的发布视频。是的，这又是一个 VS Code 分叉，但它实际上是一个 Agentic IDE，完全贯彻了 Anshul 和 Varun 在这段时间里所坚持的原则。我们会之后录一期播客做进一步讨论，欢迎大家提问或留言！
1
swyx 注：在金融投资领域，这也被称为 mosaic theory（拼图理论），不过在法律层面中，它意味着把原本分散的“非敏感”信息组合起来，就可能变得敏感。