我在 B2B 软件公司中反复看到一种模式。董事会层的某个人说：“我们需要 AI。”于是创建了一个路线图项目。开发人员将一个 API 调用连接到了 LLM。产品页面新增了一个版块。销售演示文稿多了一张幻灯片。六个月后，使用量微乎其微，却没有人能解释为什么。
答案几乎总是一样的：他们推出的是一个 AI 功能，而不是一个 AI 产品。
功能与产品的区别
AI 功能可以改善现有的工作流——在边缘上略有改进，即便没有它用户也能照常工作。例如为他们已经读过的报告生成 AI 摘要。在他们已经搜索过的文档上提供聊天界面。为他们已经填写的字段提供 Autocomplete。这些东西可能很有用。但它们不是一种战略。
AI 产品改变的是工作流本身——可能实现什么，谁来执行，需要多长时间。它不是辅助现有任务；它是用以前不可能实现的方式替代了该任务。判断门槛很简单：这东西是让用户能够做出他们以前无法做出的决定，还是仅仅让他们更快地做出他们已经做出的决定？
大多数“AI 战略”实际上只是功能清单。它们属于路线图。真正的 AI 战略始于一个不同的问题：我们用户工作流中的哪些部分目前正受到人类推理速度的瓶颈限制？
无人谈论的 go-to-market 问题
在 B2B 软件中，购买产品的人和每天使用产品的人往往不是同一批人。CTO 可能会被 demo 所打动。采购经理可以用 AI 的故事来证明成本的合理性。但是，如果日常使用该软件的人没有发现他们的生活发生了改变，那么续约谈判将会非常痛苦。
AI 功能能让你获得更多的销售对话机会。但它们未必能让你获得续约。
在 B2B 领域借助 AI 取胜的公司，是那些其 AI 改变了日常用户切实关注到的东西的公司。他们的报告会自动编写。他们的队列会自动路由。他们的 anomaly 会自动标记。而不是：“这里有一个闪闪发光的小按钮，可以总结你刚刚读过的内容。”
go-to-market 方面的影响被低估了。如果你的 AI 功能没有改变你的客户是谁，也没有改变他们在续约时评估你的方式，那么它就不是一项战略资产。它只是一个顺便生成营销文案的成本中心。
data model 就是产品
真正的 AI 集成——那种能改变工作流的集成——最困难的地方在于，它几乎总是需要首先修复底层的 data model。
我们花了好几年时间将 Response365 构建为一个统一的 multi-tenant 平台：计费、库存、生产、HR、合规等每个模块都被输入到一个单一互联的 schema 中。我们这样做并不是为了“启用 AI”。我们这样做是因为，如果一个业务管理平台无法回答跨模块的问题，那就失去了它存在的全部意义。
但结果是，当我们构建 business intelligence 层——即用户用通俗语言询问关于他们业务的问题时——它确实奏效了。系统知道什么是发票，它与采购订单有何关联，这对现金流意味着什么，以及它来自哪个生产批次。AI 能够发挥作用，是因为底层的数据是互连的。你无法生硬地把这些拼凑上去。
大多数公司试图反其道而行之：现在就推出 AI 功能，以后再清理 data model。但以后永远不会到来。于是 AI 建立在碎片化的 schema 之上，生成看似合理却不可信的答案，这比没有答案更糟糕。
比“我们应该加入 AI 吗？”更有用的三个问题
当前工作流中的哪些决策需要人们同时跨两个以上的系统维持 context？ 这就是 AI 能够改变结果，而不仅仅是改变速度的地方。如果答案是“没有”，说明你的工作流已经结构良好，AI 能带来的机会微乎其微。
如果 AI 出错了，会发生什么？ 如果答案是“用户没有注意到”，说明你的 AI 没有在做任何有意义的事情。如果答案是“造成重大伤害”，你就需要一个 human in the loop。真正有趣的产品介于两者之间——AI 偶尔会出错，用户能够分辨出来，而修正循环会让系统随着时间的推移变得更加智能。
谁会因为这个而改变他们的行为？ 不是“谁使用了这个功能”——而是谁因为它的存在而表现出不同的行为？如果没有人的工作因为 AI 而产生实质性的不同，那它只是一个功能。如果某个人的工作流发生了根本性的改变，那它就是一个产品。
B2B 软件领域的 AI 时代是真实存在的。但大多数公司在错误的层面上竞争——试图在哪个产品拥有更多 AI 功能上取胜，而那些在五年后依然能够屹立不倒的公司，是那些利用 AI 改变了产品根本作用的公司。
这两者之间的区别不是一个工程问题。它是一个产品战略问题。而且它早在第一次 API 调用之前就已经开始了。