拒绝 AI 拼凑外挂
解决什么问题
公司决定"all in AI"之后，组织上该怎么落地：是设一个专职 AI 团队去给各个产品"加 AI"，还是让 AI 能力散布到每个产品团队里。
核心内容
Paul Adams 明确反对把 AI 做成一个"焊接"在旁边的独立团队（"don't bolt it on"）——不要搞成"我们有一个 AI 特性团队，只有他们负责做 AI 相关的东西"，而应该让所有团队都去学习和理解 AI，把它变成每个产品团队的基本素养,而不是外包给一个专门小组。
他用移动化浪潮做类比：他在 Google 时曾在"移动团队"工作，物理上被隔在伦敦一个独立小组里，而 Mountain View 总部完全不在意移动端（"20 个人 vs 200 个人，没人用手机做这些事"）。这种"把新技术圈起来给专职团队做"的组织模式，本质上意味着大多数人可以继续无视这个变化，这正是导致公司对新范式反应迟钝的组织根因。
具体到 Intercom 的落地方式：机器学习本身仍需要专职的深度专家（機器学习工程师供给稀缺，需要专门投入建设这个职能），但产品团队（PM+设计师+几名工程师）应该直接和机器学习团队协作构建产品，而不是把"AI 功能"整体外包给一个孤立的 AI 团队来做。他也强调自己一贯偏好通才（generalist）文化——他形容自己是"样样通、样样松"（jack of all trades, master of none），Intercom 的工程文化也更偏好"愿意学习新语言/新框架/新的 AI 交互设计方式"的人，而不是画地为牢的专才。
适用边界
这不代表完全没有专才——机器学习工程本身仍然是一项需要深度专业积累的稀缺技能，需要专门投入建设。"不要焊接"针对的是产品团队层面是否要把"AI 相关工作"整体隔离出去，而不是否定底层技术团队需要专业分工。他也承认 Intercom 自己"还早"（still early），这个理念仍在落地过程中。
关键引述 · 原话
"don't be like, 'Oh, we'll have a bunch of AI people...' ... generally speaking, we're trying to have everyone learn about it." — Paul Adams
关联卡片
与 ai-meteor-product-mapping--paul-adams 是同一战略判断（AI 是否会颠覆你的产品）之后的组织执行层落地方式；也呼应 rag-data-preparation 等具体技术卡片背后"每个团队都该懂 AI 基本原理"的前提。
被这些卡引用
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast（2019–2026）。本站为个人学习用途的二次创作，与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2