智能产品三层模型：自建还是购买？

在最近一期的All-In播客节目中，David Friedberg讲述了他的团队在植物育种公司Ohalo Genetics如何用一个周末的时间，利用Claude Code、Cursor以及几种其他AI编程工具搭建了一个内部CRM。他们把它立起来，开始使用，而且确实能用。

然后请求就来了。

能加上这个功能吗？能和我们已经在用的工具同步吗？访问控制和数据安全怎么办？每个问题单独看都合情合理，但合在一起，它们就累加成了一个没人规划过的路线图、对有限工程资源的相互竞争的需求，以及一个公司根本不在其业务范围内的产品。

Ohalo的优势不在它的CRM。而在植物育种。让它们与众不同的是它们的植物育种技术平台，以及那些把真正能力交到实验室、温室和工作台前的人手中的工具。那项工作是Ohalo独有的；没有别人能做，因为没有别人知道他们所知道的东西。

所以Friedberg的团队问了一个比"我们该不该做这个？"更细致的问题。他们问的是，在哪里投入时间和金钱能获得最高回报。答案不在重建CRM、消息工具、分析平台，或任何其他有能力的公司已经花十年时间做对的解决方案里。

这个故事没有任何地方要求你必须身处农业。把植物育种换成你的公司比任何人都更了解的东西，这就是一个关于你的路线图、关于把团队的时间、才智和token集中用于打造让你与众不同的东西的故事。

自建与购买是个过时的框架

直到最近，像Ohalo这样的决策都是使用传统的自建与购买框架做出的。其逻辑很清晰：自建慢、昂贵且有风险。购买更快、更便宜、更可预测。这个比较本身就替你做了决定。

AI编程工具至少从表面上看瓦解了这套逻辑。演示很有说服力，估算看起来合理，工程师们也真心想尝试新东西。当一个过去要花一个季度的原型现在只需一个周末，"直接做出来"就不再听起来鲁莽，而开始听起来理所当然。

所以旧问题不再有用。而且直到现在，没人替换它。2026年，每个产品团队都在构建。所以问题不再是是否要构建，而是构建什么。

无意间成为分析公司是如何发生的

构建嵌入式分析起初似乎从来都不是坏选择。有人看到一个text-to-SQL演示，"效果不错！"于是另一个人说，"我们也能做。"他们说对了，确实能做。

但他们没有考虑到的是，每个智能产品表面之下都潜伏着另外两层。六个月后，团队发现自己要维护一个语义层、应付数字对不上的投诉，还要搭建多租户架构。

TL;DR：没人计划去经营一家分析公司，但现在这就是工作。

Thrive Learning的首席产品与技术官Frankie Woodhead完美地描述了这个问题：“作为CPTO或CTO，你总会经历这种两难：'我该自建还是购买？'很多很多年里，我们一直在自建、自建、自建……我们的团队在优化分析，而不是优化产品。工程时间是个限制。”

大多数团队都误判了你打算交付的功能与你最终不得不拥有的基础设施之间的差距。每个智能产品都由三层组成，而把它们当作一个单一的构建决策，是领导者可能犯的最大的产品战略错误。

第1层：你的竞争优势

第1层包含你的核心产品路线图，这是你绝对应该自建的一层。你的业务逻辑就在这一层，还有你的行业专长、只有你才会想到去追求的AI用例，以及你的客户无法从别处获得的工作流。正是这一切让你的产品在其市场中不可替代。

这也是唯一一层能让工程杠杆产生复利的地方。在这里花的每个冲刺都会创造出竞争对手无法通过购买你购买的同样供应商来复制的东西，因为你构建的其实并不是技术。它是领域专长，被编码进软件。

没有人能构建你的第1层，这就是为什么它永久属于你的产品团队。这个决策没有任何一种版本是把它交给别人是对的。唯一真正的风险是让它饿着：在下面两层上耗费了太多产能，以至于那层让你与众不同的东西始终得不到它应得的工程关注。

第2层：智能体验

第2层是客户实际看到和触及的AI原生分析。在这一层，他们希望用平实的语言提问并得到可信的答案，自行探索而不必提交工单，并基于洞察采取个性化行动而无须离开你的产品。

第2层是三层中最危险的，因为现在一个浅层版本一周就能做出原型。但一个用演示数据在真实场景中正确回答的对话式界面，和一个每次都能用客户的实时、复杂schema和独特边缘情况正确回答的界面，并不是一回事。前者一个周末就能搞定，后者需要数年。

这就是为什么第2层是你该做白标的一层。你的客户不在乎是谁构建的。他们在乎它能用、够快，而且看起来就像属于你的产品。有了合适的合作伙伴，这三者都能实现，而你的公司一行代码都不必拥有。

第3层：分析基础

第3层包含没人看得到、但人人都依赖的基础设施。它是保护客户数据的治理、身份认证和多租户安全。它是让事物在大规模下保持快速的查询优化，以及显示谁在何时访问了什么的监控和审计日志。还有太多太多。

从来没有用户打开一个产品后会去赞赏它的权限模型。但只要它出问题，所有人都会离开。第 3 层在正常工作时是隐形的，出问题时却是灾难性的：安全漏洞、合规事故，或者客户发现了他人的数据。

这也是一个没有终点的层级。每一个新租户、每一次架构变更、每一轮 SOC 2 周期、每一次 LLM 版本升级，都会落到你的团队头上，而且规模越大，难度越高。正因如此，第 3 层是你绝不该自己拥有的东西。不是因为你的团队建不出来，而是因为一旦建出来，你就永远拥有它了。

哪些层级正在消耗你的路线图？

由于团队常常把智能产品当作一个单一的构建决策，大多数路线图都包含全部三个层级的工作。问这三个问题来区分它们，并确保你没有把基础设施当作差异化优势：

1. 如果竞争对手买了和你完全相同的工具，他们能复制这个吗？如果能，那它就不是第 1 层。它只是恰好躺在你待办事项里的基础设施。

2. 这个功能是否编码了只有你才知道的、关于你的客户或你所在行业的某些信息？如果不能，那它也不是第 1 层，无论它目前占据了你路线图的多大比例。

3. 如果你的版本比所有人的都做得更好，你的客户会注意到并在意吗？如果能，并且它也通过了前两个问题，那它就是第 1 层。构建它，并保护好把它做好的能力。

任何不能通过全部三个问题的东西都属于第 2 层或第 3 层，而它们之间的区分很简单。如果你的客户能看到它，它就是第 2 层，你应该对它进行白标。如果他们永远看不到它，它就是第 3 层，你绝不该自己拥有它。

接下来，做真正让人心痛的部分。算一算你的工程能力目前在这三个桶里是如何分布的。对大多数团队来说，第 2 层和第 3 层占用了大量资源，却提供零差异化。

现在计算一下，把这些交给可信赖的合作伙伴，能让你重新分配到第 1 层多少时间和资金。我们的构建计算器只需几分钟就能告诉你。

构建能让你脱颖而出的东西

下一代获胜的产品团队不会是构建最多的团队，而是构建正确东西的团队。

在 ThoughtSpot，我们热爱构建者，也热爱让他们更强大的工具。用今天的解决方案，几乎什么都能构建出来，这正是为什么你选择构建什么，现在比以前更重要，而不是更不重要。

这也是为什么旧的“构建还是购买”框架不再成立，问题不再是你是否要构建，而是你是否在构建只有你才能构建的东西。使用 ThoughtSpot Embedded 构建就是买回专注力、去做这件事的方式。

构建竞争对手无法复制的东西

下载信息图，看看工程在哪里创造持久的差异化。

获取信息图