来源Source

  围绕 AI 来做产品升级和组织转型是大家最感兴趣的话题，前几天我们也发了一篇《别谈“全面 AI 转型，要搞”单点 AI 爆破”》分享我们自己的实践经验和原则。落地时确实有一个非常经典的辩论，就是到底应该独立快速跑 AI 新业务，还是应该全面组织升级。

  我们自己其实是选择“独立小组织创新拉动”的（从“单点 AI 爆破”这个名字里也能看出来），但这个做法确实会像 Lauryn 所说导致组织割裂。尤其是在创新短期内没有得到增量收益情况下，一方面很容易引发组织内其他部门的反弹，另一方面新的小团队也会觉得得不到足够的理解和支持。

  Airtable 这个做法很有启发，他们逐渐把独立的 AI 探索部门做成了 AI 中台——把深度的业务探索和产品创新还是留在了业务部门，但把基建（比如数据、API、Finetune、Prompting……）这些放在了中台。对 AI 中台的考评也变成了采用率、开发效率和满意度，激励中台去给前台赋能，避免技术上的重复造轮子。

  技术之外，业务上也会做一个 AI Council，让业务部门连接成组织的 AI 神经中枢，定期分享各自的 demo、经验和难题，促进知识的流动和最佳实践的沉淀。

  非常实战啊。

要点Key Takeaways

• AI 转型最大的挑战不是技术，而是组织结构

• 独立 AI 团队能快速启动，但长期会造成业务脱节

• 最理想的组织模式是“中心化 + 嵌入式”的混合体

• 成立 AI 平台团队 (Hub) 赋能所有业务团队 (Spokes)

• AI 产品经理 (PM) 需要更强的技术理解力和用户洞察

• 别让不懂 AI 的人，用 KPI 来管理 AI 团队

• 数据策略与组织结构需要同步进化，互相匹配

两种模式的艰难抉择：

中心化 vs. 嵌入式

为了快速行动，Airtable 采用了当时硅谷最流行的模式：组建一个完全独立的 AI 团队。这个团队被赋予了极大的自由度，可以直接向高层汇报，不受现有产品路线图和技术债务的束缚。他们的使命，就是在最短时间内，向外界证明 Airtable 的 AI 实力。

这个策略在短期内取得了显著成功。团队夜以继日地工作，快速将 OpenAI 的 API 集成到产品中，推出了字段自动生成、内容改写等一系列功能。Airtable AI 的发布，在当时确实引起了不小的轰动，也稳住了市场和用户的信心。

然而，成功的喜悦并没有持续太久。这个“特种部队”与负责核心产品功能（例如 Interface、Automations）的“常规军”之间，开始出现巨大的裂痕。AI 团队不了解核心业务的复杂性和用户场景，而核心业务团队则抱怨 AI 团队做的东西华而不实，无法与现有功能深度整合。两个团队之间甚至出现了“我们”和“他们”的说法，文化隔阂越来越深。

“特种部队”模式的弊端日益明显，公司内部开始了长达数周的激烈辩论。辩论的核心在于两种截然不同的组织模式：中心化（Centralized）和嵌入式（Embedded）。

中心化模式的支持者认为，AI 是一项需要长期投入和深厚积累的技术。必须有一个统一的团队来负责底层模型的研究、核心算法的优化和前沿技术的探索。如果将这些宝贵的专家资源分散到各个业务线，他们很快会陷入日常的业务需求中，从而失去技术上的领先优势。

嵌入式模式的支持者则反驳说，AI 的价值最终要通过解决用户问题来体现。如果 AI 专家不深入理解业务，不和产品经理、设计师坐在一起，他们做出来的东西就永远是“玩具”而非“工具”。让每个业务团队都拥有自己的 AI 力量，才能让 AI 与业务场景发生真正的化学反应。

这场辩论没有绝对的对错，它反映了所有公司在 AI 转型中都会遇到的核心矛盾：技术深度与业务落地之间的平衡。Airtable 的管理层意识到，简单的二选一，可能都不是最佳答案。

Airtable 的最终解法：

Hub and Spoke 混合模型

经过反复权衡，Airtable 决定融合两种模式的优点，创造出一种新的混合结构。这个结构的核心，就是 AI 平台团队（Hub）。

这个 Hub 团队大约有 10-15 人，由公司最顶尖的 AI 专家组成。他们的工作成果不是直接面向用户的产品功能，而是面向内部开发者的“AI 工具箱”。这个工具箱里包含了：

• 统一的 API 接口：无论底层用的是 OpenAI、Anthropic 还是其他模型，对于业务团队来说，调用的接口都是统一的。

• 模型评估与路由系统：Hub 负责评估不同模型的性能和成本，并建立智能路由，根据不同的任务自动选择最合适的模型。

• 通用的 Prompt 模板和管理工具：提供最佳实践，帮助业务团队写出更高质量的 Prompt。

• 数据标注与 fine-tuning 平台：为需要更高准确度的特定场景，提供模型微调的能力。

而 Spoke 团队，也就是原有的核心功能团队，则被赋予了端到端的 AI 功能开发责任。他们有了自己的 AI 工程师，可以直接利用 Hub 提供的平台能力，设计和开发最贴近自己业务场景的 AI 功能。这种模式，既保证了技术标准的统一和基础设施的效率，又释放了业务团队的创新活力。

重新定义产品经理：

AI PM 的新角色

组织结构的变革，也带来了对人才能力模型的重新定义。尤其对于产品经理这个角色，挑战是巨大的。

在新的 Hub and Spoke 模型下，Spoke 团队中的 AI PM 必须成为一个“多面手”。他们不仅要像传统的 PM 那样，深刻理解用户需求，挖掘痛点，设计解决方案；还必须具备相当的技术知识储备。

例如，当需要开发一个基于用户自有数据进行问答的功能时，这位 PM 需要知道什么是检索增强生成（RAG, Retrieval-Augmented Generation），它的原理是什么，有什么优缺点。他还需要和工程师一起评估，是采用 RAG，还是对模型进行微调（Fine-tuning）效果更好，成本更低。

此外，AI 产品的用户体验设计也是一个全新的领域。由于大语言模型（LLM）的输出具有不确定性，PM 需要设计巧妙的交互方式来引导用户，管理用户的预期，并提供有效的反馈和修正机制。一个只会画线框图的 PM，在 AI 时代将寸步难行。

与 CEO 的艰难对话：

如何衡量 AI 团队的 KPI

如何设定考核目标，是所有组织变革中最棘手的问题之一。对于 Airtable 新成立的 AI 平台团队（Hub）来说，这个问题尤其突出。如果用传统的指标，比如直接带来的收入或者功能使用率来考核他们，那无疑会引导他们去和 Spoke 团队“抢活干”，从而违背了设立 Hub 的初衷。

Lauryn Isford 成功地说服了 CEO，为 Hub 团队建立了一套全新的、基于平台思维的考核体系。这套体系的核心是衡量 Hub 对 Spoke 的“服务质量”和“赋能力度”。

具体的衡量指标包括：

• 平台采用率：有多少个 Spoke 团队在他们的功能中使用了 Hub 提供的服务。

• 开发效率提升：Spoke 团队从产生一个 AI 功能的想法，到最终上线，所花费的时间是否因为 Hub 的存在而缩短。

• 平台满意度：通过内部调研，了解 Spoke 团队的工程师和 PM 对 Hub 提供的工具和服务的满意度。

这种考核方式，确保了 Hub 团队的目标和 Spoke 团队的目标是完全一致的——那就是让整个公司的 AI 功能开发变得更快、更好、成本更低。

数据策略：

从“孤岛”到“统一数据视图”

当新的组织结构开始顺畅运转后，Airtable 遇到了所有公司在深入 AI 应用时都会遇到的问题：数据。

Airtable 的核心是数据库，用户在里面存储了项目、客户、任务等各种各样的数据。但在过去，这些数据在不同功能模块（Base、Interface、Automations）之间是相对隔离的。比如，一个 AI 功能如果只能理解 Base 里的表格数据，却不理解这些数据是如何在 Interface 中被展示和交互的，那么它能提供的价值就非常有限。

为了解决这个问题，Airtable 启动了一个并行的、同样重要的项目：构建统一数据视图。这个项目的目标是打破不同功能模块之间的数据壁垒，让 AI 模型能够全面地、上下文感知地理解一个用户的整个工作空间。

这是一个巨大的工程，涉及到后端架构的重构和数据模型的重新设计。但 Airtable 坚信，这是让 AI 从“功能点”走向“智能助手”的必经之路。只有当 AI 能够看到用户工作的全局，它才能真正理解用户的意图，并提供超越简单问答的、更深层次的帮助。

“AI Council”：

跨团队协作的神经中枢

“中心辐射型”模型虽然解决了专业分工和业务结合的问题，但它也带来了新的挑战：如何保证分布在各个 Spoke 团队中的 AI 人员，不会因为离 Hub 太远而感到孤立？如何将一个团队踩过的坑，快速同步给其他团队？

Airtable 的答案是成立 AI Council。这是一个轻量级的虚拟组织，扮演着整个公司 AI 创新的“神经中枢”的角色。

在每周的例会上，议题非常务实：

• Demo 演示：某个 Spoke 团队会演示他们最近在开发的新 AI 功能，并分享他们的设计思路和技术选型。

• 经验分享：一个团队可能会分享他们最近在 Prompt Engineering 上的一个新发现，或者他们如何将某个功能的延迟降低了 50%。

• 难题共解：Hub 团队可能会提出一个技术难题，比如“如何更低成本地评估模型输出的质量”，并征求各个业务团队的输入。

AI Council 的存在，极大地促进了知识的流动和最佳实践的沉淀。它让身处不同业务线的 AI 从业者有了一个共同的“家”，建立了一个学习型社区，从而加速了整个公司的 AI 能力进化。

给所有 CEO 和 PM 的建议

回顾 Airtable 的整个转型历程，Lauryn Isford 认为，有几个关键原则对于任何希望拥抱 AI 的公司都至关重要。

对 CEO 而言：

• 亲自挂帅：AI 转型是一场“CEO 工程”，它涉及到底层的战略、组织和文化，不能把它简单地丢给技术部门。

• 明确目标：必须向整个公司传递一个清晰、统一的信号——为什么我们必须做 AI，我们希望通过 AI 实现什么。

• 投资于人与组织：技术可以买到，但能够驾驭技术的组织能力，需要时间和耐心去构建。要舍得为组织升级投入资源。

对产品经理而言：

• 拥抱技术：你不需要成为算法专家，但你必须理解 AI 的能力边界、成本结构和实现原理，否则你无法做出正确的产品决策。

• 回归用户：不要为了用 AI 而用 AI。从你最熟悉的用户痛点出发，思考 AI 能带来哪些“10 倍好”的体验，而不是仅仅做一些锦上添花的微小改进。

• 学会与不确定性共舞：AI 的结果并非 100% 可控。要学会设计容错性更好、引导性更强的产品体验，让用户感觉 AI 是一个得力助手，而非一个捉摸不定的“黑盒子”。

Airtable 的故事，是一个关于技术、组织和人的故事。它证明了在 AI 时代，一家公司最大的壁垒，可能不再是代码或数据，而是其适应和进化的能力。

结语Closing Thoughts

就好像我在《别谈“全面 AI 转型，要搞”单点 AI 爆破”》表达的，我们其实是 Airtable 一开始就选择的“特种部队”流派的：）。但特种部队做好了之后，打下来小县城之后，怎么把经验复制到全军，怎么提升整体的力量去打大城市，Airtable 分享的实战思路和设计就很有价值了。