围绕 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 团队
数据策略与组织结构需要同步进化，互相匹配
1
两种模式的艰难抉择：
中心化 vs. 嵌入式
Lauryn Isford:
"我们最初成立了一个独立的 AI 团队，我们称之为‘AI 特种部队’。这个团队拥有最优秀的人才，最高的优先级和最充分的授权，目标只有一个：尽快做出能让市场惊艳的 AI 功能。"
"这个模式在初期非常有效，我们迅速推出了 Airtable AI 的第一个版本。但很快，问题就暴露出来了。这个独立团队，就像一个大陆隔绝的孤岛。"
"我们面临一个十字路口：是继续加强那个中心化的 AI ‘象牙塔’，还是干脆把它打散，将 AI 人才分散到各个业务团队中去？"
"这两种模式都有明显的优缺点。中心化团队能保证技术深度和前瞻性，但容易脱离业务。嵌入式能让 AI 快速落地，但容易造成重复建设和标准不一。"
为了快速行动，Airtable 采用了当时硅谷最流行的模式：组建一个完全独立的 AI 团队。这个团队被赋予了极大的自由度，可以直接向高层汇报，不受现有产品路线图和技术债务的束缚。他们的使命，就是在最短时间内，向外界证明 Airtable 的 AI 实力。
这个策略在短期内取得了显著成功。团队夜以继日地工作，快速将 OpenAI 的 API 集成到产品中，推出了字段自动生成、内容改写等一系列功能。Airtable AI 的发布，在当时确实引起了不小的轰动，也稳住了市场和用户的信心。
然而，成功的喜悦并没有持续太久。这个“特种部队”与负责核心产品功能（例如 Interface、Automations）的“常规军”之间，开始出现巨大的裂痕。AI 团队不了解核心业务的复杂性和用户场景，而核心业务团队则抱怨 AI 团队做的东西华而不实，无法与现有功能深度整合。两个团队之间甚至出现了“我们”和“他们”的说法，文化隔阂越来越深。
“特种部队”模式的弊端日益明显，公司内部开始了长达数周的激烈辩论。辩论的核心在于两种截然不同的组织模式：中心化（Centralized）和嵌入式（Embedded）。
中心化模式的支持者认为，AI 是一项需要长期投入和深厚积累的技术。必须有一个统一的团队来负责底层模型的研究、核心算法的优化和前沿技术的探索。如果将这些宝贵的专家资源分散到各个业务线，他们很快会陷入日常的业务需求中，从而失去技术上的领先优势。
嵌入式模式的支持者则反驳说，AI 的价值最终要通过解决用户问题来体现。如果 AI 专家不深入理解业务，不和产品经理、设计师坐在一起，他们做出来的东西就永远是“玩具”而非“工具”。让每个业务团队都拥有自己的 AI 力量，才能让 AI 与业务场景发生真正的化学反应。
这场辩论没有绝对的对错，它反映了所有公司在 AI 转型中都会遇到的核心矛盾：技术深度与业务落地之间的平衡。Airtable 的管理层意识到，简单的二选一，可能都不是最佳答案。
2
Airtable 的最终解法：
Hub and Spoke 混合模型
Lauryn Isford: "我们最终选择了一条中间道路，我们称之为‘中心辐射型’（Hub and Spoke）模型。我们保留了一个小而精的中央 AI 平台团队（Hub），同时将大部分 AI 工程师和产品经理分配到各个业务团队（Spokes）中去。"
Lauryn Isford: "Hub 的职责不是做功能，而是赋能。他们负责打造通用的 AI 基础设施、服务和最佳实践，让 Spoke 团队可以像搭乐高一样，快速构建自己的 AI 功能。"
经过反复权衡，Airtable 决定融合两种模式的优点，创造出一种新的混合结构。这个结构的核心，就是 AI 平台团队（Hub）。
这个 Hub 团队大约有 10-15 人，由公司最顶尖的 AI 专家组成。他们的工作成果不是直接面向用户的产品功能，而是面向内部开发者的“AI 工具箱”。这个工具箱里包含了：
统一的 API 接口：无论底层用的是 OpenAI、Anthropic 还是其他模型，对于业务团队来说，调用的接口都是统一的。
模型评估与路由系统：Hub 负责评估不同模型的性能和成本，并建立智能路由，根据不同的任务自动选择最合适的模型。
通用的 Prompt 模板和管理工具：提供最佳实践，帮助业务团队写出更高质量的 Prompt。
数据标注与 fine-tuning 平台：为需要更高准确度的特定场景，提供模型微调的能力。
而 Spoke 团队，也就是原有的核心功能团队，则被赋予了端到端的 AI 功能开发责任。他们有了自己的 AI 工程师，可以直接利用 Hub 提供的平台能力，设计和开发最贴近自己业务场景的 AI 功能。这种模式，既保证了技术标准的统一和基础设施的效率，又释放了业务团队的创新活力。
3
重新定义产品经理：
AI PM 的新角色
Lauryn Isford: "这次重组对产品经理（PM）的要求发生了根本性的变化。过去，PM 可能更关注用户流程和界面设计。现在，AI PM 必须对技术栈有更深入的理解。"
Lauryn Isford: "一个优秀的 AI PM，需要能和工程师讨论‘应该用 RAG 还是 fine-tuning’，需要能评估不同模型的成本和延迟，还需要能设计出好的用户体验，来弥补 AI 的不确定性。"
组织结构的变革，也带来了对人才能力模型的重新定义。尤其对于产品经理这个角色，挑战是巨大的。
在新的 Hub and Spoke 模型下，Spoke 团队中的 AI PM 必须成为一个“多面手”。他们不仅要像传统的 PM 那样，深刻理解用户需求，挖掘痛点，设计解决方案；还必须具备相当的技术知识储备。
例如，当需要开发一个基于用户自有数据进行问答的功能时，这位 PM 需要知道什么是检索增强生成（RAG, Retrieval-Augmented Generation），它的原理是什么，有什么优缺点。他还需要和工程师一起评估，是采用 RAG，还是对模型进行微调（Fine-tuning）效果更好，成本更低。
此外，AI 产品的用户体验设计也是一个全新的领域。由于大语言模型（LLM）的输出具有不确定性，PM 需要设计巧妙的交互方式来引导用户，管理用户的预期，并提供有效的反馈和修正机制。一个只会画线框图的 PM，在 AI 时代将寸步难行。
4
与 CEO 的艰难对话：
如何衡量 AI 团队的 KPI
Lauryn Isford: "重组过程中，我和 CEO 有过一次非常艰难但关键的对话。他问我，‘我该如何衡量 Hub 团队的成功？’ 我告诉他，‘你不应该用传统的业务指标去衡量他们。’"
Lauryn Isford: "Hub 团队的 KPI 不应该是收入，甚至不应该是用户活跃度。他们的核心指标应该是‘赋能效率’，比如‘让 Spoke 团队上线一个 AI 功能的平均时间’，或者‘被多少个 Spoke 团队调用了他们的服务’。"
如何设定考核目标，是所有组织变革中最棘手的问题之一。对于 Airtable 新成立的 AI 平台团队（Hub）来说，这个问题尤其突出。如果用传统的指标，比如直接带来的收入或者功能使用率来考核他们，那无疑会引导他们去和 Spoke 团队“抢活干”，从而违背了设立 Hub 的初衷。
Lauryn Isford 成功地说服了 CEO，为 Hub 团队建立了一套全新的、基于平台思维的考核体系。这套体系的核心是衡量 Hub 对 Spoke 的“服务质量”和“赋能力度”。
具体的衡量指标包括：
平台采用率：有多少个 Spoke 团队在他们的功能中使用了 Hub 提供的服务。
开发效率提升：Spoke 团队从产生一个 AI 功能的想法，到最终上线，所花费的时间是否因为 Hub 的存在而缩短。
平台满意度：通过内部调研，了解 Spoke 团队的工程师和 PM 对 Hub 提供的工具和服务的满意度。
这种考核方式，确保了 Hub 团队的目标和 Spoke 团队的目标是完全一致的——那就是让整个公司的 AI 功能开发变得更快、更好、成本更低。
5
数据策略：
从“孤岛”到“统一数据视图”
Lauryn Isford: "我们很快发现，组织结构调整后，下一个瓶颈是数据。每个团队都有自己的数据，但这些数据是割裂的，无法被 AI 模型有效利用。"
Lauryn Isford: "我们意识到，必须建立一个统一的数据视图。AI 想要变得更智能，就必须能够理解用户在 Airtable 中存储的所有数据之间的关联。"
当新的组织结构开始顺畅运转后，Airtable 遇到了所有公司在深入 AI 应用时都会遇到的问题：数据。
Airtable 的核心是数据库，用户在里面存储了项目、客户、任务等各种各样的数据。但在过去，这些数据在不同功能模块（Base、Interface、Automations）之间是相对隔离的。比如，一个 AI 功能如果只能理解 Base 里的表格数据，却不理解这些数据是如何在 Interface 中被展示和交互的，那么它能提供的价值就非常有限。
为了解决这个问题，Airtable 启动了一个并行的、同样重要的项目：构建统一数据视图。这个项目的目标是打破不同功能模块之间的数据壁垒，让 AI 模型能够全面地、上下文感知地理解一个用户的整个工作空间。
这是一个巨大的工程，涉及到后端架构的重构和数据模型的重新设计。但 Airtable 坚信，这是让 AI 从“功能点”走向“智能助手”的必经之路。只有当 AI 能够看到用户工作的全局，它才能真正理解用户的意图，并提供超越简单问答的、更深层次的帮助。
6
“AI Council”：
跨团队协作的神经中枢
Lauryn Isford: "为了确保 Hub 和所有的 Spoke 能够同频共振，我们成立了一个虚拟组织，叫做‘AI 理事会’（AI Council）。"
Lauryn Isford: "这个理事会每周开一次会，成员包括所有 Spoke 团队的 AI PM、Hub 团队的负责人，以及一些关键的工程师。大家在这里同步进展、分享经验、讨论遇到的难题。"
“中心辐射型”模型虽然解决了专业分工和业务结合的问题，但它也带来了新的挑战：如何保证分布在各个 Spoke 团队中的 AI 人员，不会因为离 Hub 太远而感到孤立？如何将一个团队踩过的坑，快速同步给其他团队？
Airtable 的答案是成立 AI Council。这是一个轻量级的虚拟组织，扮演着整个公司 AI 创新的“神经中枢”的角色。
在每周的例会上，议题非常务实：
Demo 演示：某个 Spoke 团队会演示他们最近在开发的新 AI 功能，并分享他们的设计思路和技术选型。
经验分享：一个团队可能会分享他们最近在 Prompt Engineering 上的一个新发现，或者他们如何将某个功能的延迟降低了 50%。
难题共解：Hub 团队可能会提出一个技术难题，比如“如何更低成本地评估模型输出的质量”，并征求各个业务团队的输入。
AI Council 的存在，极大地促进了知识的流动和最佳实践的沉淀。它让身处不同业务线的 AI 从业者有了一个共同的“家”，建立了一个学习型社区，从而加速了整个公司的 AI 能力进化。
7
给所有 CEO 和 PM 的建议
Lauryn Isford: "对于 CEO 来说，我的建议是：AI 转型必须是你亲自推动的头等大事。你必须提供清晰的愿景、充足的资源，以及最重要的——拥抱变革的决心和耐心。"
Lauryn Isford: "对于产品经理，我的建议是：现在就开始学习。去了解 LLM 的基本原理，去尝试各种 AI 工具，去思考 AI 如何能从根本上改变你的产品。未来，不懂 AI 的产品经理，将没有未来。"
回顾 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 分享的实战思路和设计就很有价值了。
