本文深度解析了 LinkedIn 首席产品官 Tomer Cohen 在 AI 时代对产品构建方式的设想与实践。文章核心理念是“Full Stack Builder Model”（全栈构建者模式），旨在赋能个体和小型团队，使其能端到端地将产品想法变为现实。Cohen 强调，在 AI 快速变化的时代，组织和个人都需要重新思考工作方式，提升愿景、同理心、沟通、创造力和判断力这五项 Builder 核心能力。LinkedIn 为此重构平台，构建定制化 AI Agents，并在组织文化、人才培养、绩效评估等层面进行变革管理。文章指出，变革管理和文化投入是成功的关键，并强调了前期投入、持续迭代和高层推动的重要性。
到 2030 年，70% 都将发生变化。
👦🏻 编译: Bella
🥷 编辑: Koji
🧑🎨 排版: NCon
Lenny's Podcast 是十字路口团队最喜欢的硅谷播客之一，我们几乎每期必听（没时间时也至少会看摘要）。它最有价值的地方不在于采访创业者，而在于深度对话那些「双手沾泥」的产品经理和工程师。
在最新一期 Lenny’s Podcast，他们邀请到 LinkedIn CPO（首席产品官）Tomer Cohen，又贡献了一期精彩内容。
Tomer 首先抛出了一个令人不安却无法忽视的数据：
到 2030 年，完成一份工作所需的技能中，70% 都将发生变化。
当我们第一次看到这个数据时，有点被震住了。这是来自 LinkedIn 对真实岗位与技能变化的长期观察。
问题已经不再是你是否打算换工作，而是——你现在所做的一切，还是否具备未来的竞争力？
这个数字让我们意识到，问题已经不再是“要不要学习 AI”，而是我们究竟该如何重新理解工作本身，以及构建产品、组织和个人能力的方式。
也正因为如此，我们决定对这期 Lenny Rachitsky 的播客与 Tomer Cohen 的这期对话进行完整的中文编译与整理。
在 AI 成为默认能力的时代，人应该如何构建产品？Tomer 对这个问题给出了一个答案：
“Full Stack Builder Model（全栈构建者模式）”。
它的目标是赋能真正优秀的 builders：无论身处哪个团队、使用哪一层技术栈，都能将自己的想法快速推向现实。
🚥🚥🚥
以下内容，是在尽量忠实原意的前提下，对这期播客的完整翻译与结构化改写。我们希望，这不仅是一篇“观点整理”，而是一次对未来工作方式的认真对照与思考。
Part I: 当工作的技能比职位本身变化得更快
👦🏻 Lenny Rachitsky
今天我的嘉宾是 Tomer Cohen，LinkedIn 的长期首席产品官。他正在 LinkedIn 发起一种全新的产品构建方式，我认为这种方式将成为未来公司运营的范本。
这一模式被称为“Full Stack Builder”（全栈构建者）计划。其核心理念是让任何人，都有能力将产品从想法推进到上线。
他们甚至取消了传统的 Associate Product Manager（初级产品经理) 计划，取而代之的是“初级全栈构建者”计划。他们引入了一条新的职业路径，任何职能的人都可以成为 Full Stack Builder。
他们围绕这一目标构建了一整套内部工具、Agent 和工作流程，几乎打造出一个“人类 + AI”协作的产品团队。这种团队行动更快、适应变化的能力更强，也能用更少的资源产出更高质量的结果。
如果你正在寻找灵感，想重新思考团队该如何运作，或者想理解 AI 如何真正释放团队和组织的潜力，那么这一期节目非常值得一听。
Tomer，非常感谢你的到来，欢迎回到播客。
🧙🏻 Tomer Cohen
谢谢，回来很高兴。
👦🏻 Lenny Rachitsky
你在 LinkedIn 正在尝试一种新的产品构建方式，完全拥抱了 AI 带来的可能性。对我来说，这感觉像是未来许多公司运营和产品构建的典范。
我想先从一个最根本的问题开始：为什么 LinkedIn 有必要这样做？为什么要重新思考构建产品的一整套方式？为什么这件事值得所有人认真对待？
🧙🏻Tomer Cohen
对我来说，技术始终关乎“赋能”。重点不在于技术为我们做了什么，而在于它使我们能够做什么。
现在我们有一个惊人的机会，让一切重新回到‘凭真本事说话’。我们正在进入一个变革速度远超反应速度的阶段。
从 LinkedIn 看到的数据让我非常震撼：到 2030 年，也就是仅仅四年后，各类岗位所需的技能中将有 70% 发生变化。
这意味着，无论你是否打算换工作，你的工作本身都在发生改变。真正的问题是，你还能保住这份工作吗？
在组织层面也是如此。当前增长最快、需求最大的岗位，其增速已经远高于过去一年的热门职位。这些变化都指向同一个结论：如果想保持竞争力，我们必须回到第一性原理，重新理解“如何构建产品”。
Builder 的目标其实很简单：从一个想法出发，把它变成现实。
但在大型组织里，这个过程被不断拆解、叠加，最终变得极其复杂。研究、设计、评审、安全、隐私……
每一步都有合理性，但叠加在一起，一个很小的功能往往需要多个团队、多个代码库、多个 Sprint 才能上线。
流程的复杂，最终演变成了组织的复杂：一个 Builder 被拆分成工程、产品、设计等职能，而每个职能内部又继续细分。
现在，AI 给了我们一次真正的机会，把这套技术和流程简化，回到更接近工匠精神的构建方式，重新思考产品的完整生命周期——这正是 Full Stack Builder 模式诞生的背景。
👦🏻 Lenny Rachitsky
哇，关于你分享的那个数据：到 2030 年，人们当前工作所需的技能将改变 70%。 这个数据是基于什么得出的？
🧙🏻 Tomer Cohen
客观来说，变化其实一直存在，但我们从未见过如此剧烈的变化。无论你是营销人员、销售、招聘人员还是工程师，你的工作都将发生巨大变化。尤其是工程领域，现在大量关于 Agent 的投资都在往这里涌，这些工作形态会发生根本性的变化。
并非所有工作的变化幅度都一样。护士这类工作受到的影响较小，但有些工作可能会受到 90% 甚至 95% 的影响。
👦🏻 Lenny Rachitsky
我还看到一个数据：今天增长最快的 70% 的工作岗位，在一年前甚至都不在榜单上。
🧙🏻 Tomer Cohen
没错。不仅一年前不存在，很多甚至在一二十年前都不存在。
Part II: 什么是全栈 Builder 模式？Builder 的核心能力是什么？
👦🏻 Lenny Rachitsky
好吧，那让我们来谈谈你创建的计划。请介绍下它名称、核心内容以及未来的愿景。
🧙🏻Tomer Cohen
这个计划叫 Full Stack Builder Model（全栈 Builder 模式）。
一切始终要从目标出发。这个目标只有一个：赋能优秀的 Builder。不论他们扮演什么角色、使用什么技术栈、身处怎样的团队，都能够把自己的想法真正推向市场。核心理念在于，让 Builder 具备端到端构建体验的能力，把不同技能与专长融合在一起。
我始终认为，Builder 最宝贵的时间，应该花在那些只有他们自己才能真正做好的事情上。
首先是愿景，也就是对未来提出一个足够清晰、足够有说服力的构想，让人愿意相信这个方向值得被实现。
接下来是同理心，真正理解那些尚未被满足的需求。
然后是沟通能力。能够围绕一个想法，把不同的人连接起来，让更多人愿意为同一个目标投入精力。
还有创造力。我认为 AI 在这一点上目前仍然有限，它更擅长整合已有的信息，而在更高层次的创造性突破上，人类依然占据优势。
最后，也是我认为对 Builder 来说最重要的一点，是判断力。也可以理解为决策能力 —— 在高度复杂、充满不确定性的环境中，依然能够做出高质量决策的能力。
除了这五点之外，我也在极力推动自动化。
这不仅仅是为了增加尝试次数（虽然迭代速度会变快），更重要的是让一个规模化的组织变得更敏捷、更具适应性和韧性。
我的类比是美国海豹突击队：他们接受交叉训练，专注于任务，以小分队形式运作，非常敏捷且可以快速集结。我认为这才是未来能获胜的组织形态。
👦🏻 Lenny Rachitsky
所以简单来说，这个理念就是一个 Builder 基本上独自完成整个产品开发过程：想法、研究、数据、原型设计、发布？
🧙🏻Tomer Cohen
是的，但不一定非要独自一人。我仍然相信团队的力量。
👦🏻 Lenny Rachitsky
明白了，所以是更小的团队。
🧙🏻 Tomer Cohen
是的，更专注于任务的小团队。例如，我们开始采用 Pod（小分队） 模式。不再是大团队，而是集结一个理想情况下由 Full Stack Builder 组成的小分队。重点不再是凑齐工程师、设计师和产品经理 这种“铁三角”，而是寻找能够跨职能发挥作用的人，让他们在一个季度内解决某个问题，然后重新集结。我们在这种模式下看到了巨大成功，无论是在速度，还是在团队的专注度和灵活性方面。
👦🏻 Lenny Rachitsky
感觉你想改变的是，随着团队臃肿而失去的速度、适应性和灵活性。因为回到您最初的观点，即变化发生得太快了，以至于那些以传统方式构建的公司根本无法竞争。
🧙🏻 Tomer Cohen
是的。不是说您必须打破这个模式。我认为这个模式已经破碎了。只是这种变化的速度正在帮助我们意识到这一点。
Part III：AI Agents 不是关键，变革管理才是
👦🏻 Lenny Rachitsky
那么关于自动化的部分，你们在哪些领域看到了成功？
🧙🏻Tomer Cohen
如果你是一家初创公司，你可能天生就是这样运作的。但对于像我们这样规模的公司，这几乎是一种全新的生产和思维方式。
我们主要在三个部分进行投入：平台 、工具与 Agent 、文化 。
关于平台： 我们正在重新架构核心平台，以便 AI 能够理解和推理。我们构建了服务端组件化的 UI，基本上是为 AI 的接入做好准备。你不能直接引入第三方工具并期望它在 LinkedIn 的技术栈上运行——这是我们最大的教训之一，直接拿来用从来行不通。你需要做大量的定制化工作。
👦🏻 Lenny Rachitsky
这本质上是为了让 AI 更有效地工作而重构代码库，对吗？
🧙🏻Tomer Cohen
是的。无论是 Copilot、Cursor 还是 Windsurf，我们需要构建一个层，让 AI 能够有效地推理我们的代码。设计系统也是如此，Figma 等工具需要知道如何与我们的设计系统配合。
👦🏻 Lenny Rachitsky
这就是平台层面的投入。那工具方面呢？
🧙🏻Tomer Cohen
工具方面就是我们构建 Agent 的地方。正如我提到的，我们的目标，是把 Builder 那五项核心能力之外的工作尽可能自动化。这也意味着，这里几乎不可能直接使用现成工具，所有 Agent 都必须高度定制。
拿 信任 Agent举例：在产品仍停留在想法或 spec 阶段时，它就能基于历史经验和专业知识，提前识别潜在风险。以 “Open to Work” 为例，信任 Agent 在回溯当年的产品方案时，不仅找出了我们当初已意识到的问题，还发现了一些后来才暴露的漏洞，大幅降低了上线后的风险成本。
另一个是增长 Agent。我们将过去所有增长循环、漏斗和实验经验注入其中，让它既能执行增长想法，也能评估想法本身的潜力。如今，它的使用已经超出了增长团队，甚至 UXR 团队也会用它来判断哪些方案最可能带来实质性影响。
还有调研 Agent。它结合多年用户研究和支持数据，从特定用户画像（比如小型企业主）的视角审视产品方案，常常能直接改变团队的决策方向，弥补大型组织中信息难以集中掌握的缺口。
此外，我们还有一个 分析 Agent，可以直接查询整个 LinkedIn 的复杂图谱，而无需依赖 SQL 或数据科学团队。
目前，这些 Agent 大多仍处在 MVP 阶段，我们的目标是在未来几个月内在 LinkedIn 内部逐步推广。
👦🏻 Lenny Rachitsky
有很多问题。一个是，你们是如何构建它的？你们使用了哪个平台？在 LinkedIn 构建一个 agent 需要什么？都是内部工具还是使用了第三方？
🧙🏻Tomer Cohen
我们确实在尝试很多工具。
对于这类基于知识体系的 Agent，我们用过从Copilot Enterprise到 ChatGPT Enterprise 的各种方案，但真正带来最大提升的，是内部的深度定制。
我们甚至专门构建了一个 Orchestrator，让信任 Agent 和增长 Agent 之间能够来回协作，而不是简单地顺序执行。这一层几乎完全是内部完成的，也正因为如此，这件事本身需要相当大的投入。
在设计 Agent 上，我们也在同时与多家公司合作，寻找最适合 LinkedIn 的产品。一个很现实的发现是，不同团队会自然偏好不同的工具。
而我们接下来需要解决的，正是如何在这种差异中尽可能的简化流程——包括选哪些工具，以及如何把它们整合在一起。
👦🏻 Lenny Rachitsky
比如说你可能有一个很棒的 Figma agent，但有些团队想使用别的的设计工具？
🧙🏻Tomer Cohen
是的。我们尝试了 Figma、Subframe 和 Magic Patterns 等等，我们看到人们根据职能、他们对工具的熟悉程度等，倾向于不同的工具。
最终，我不想在公司里有八个设计 agents，所以我们必须简化到几个。
我认为这在很多领域都是相似的，因为很多 agents 的吸引力在于它们试图解决相似的最终目标，但它们做的方式非常不同。
最终，我不认为会有一个赢者通吃的情况，因为客户或用户的起点将在很大程度上决定这些工具在特定用例中的简易程度。
👦🏻 Lenny Rachitsky
另一个有趣的发现是，您正在设计非常具体的、用于完成单一任务的 agents。这是一个非常刻意的决定吗？你是否尝试过那种通用型 agent？
🧙🏻Tomer Cohen
从长期来看，我们一定会有一个 orchestrator，把这些 Agent 统一编排起来。但在早期，我们更希望先把每一个 Agent 的能力做好、做清楚，能够清晰地评估和衡量它们各自的表现。
这里面其实是有“专业分工”的。与此同时，我们在架构上也在刻意屏蔽这些复杂性——最终用户不需要知道背后具体有哪些 Agent 在协作。
比如，你可能并不知道自己在用一个信任 Agent。你真正接触到的，可能是我们内部称为 Product Jam Agent 的东西，它负责执行我们内部的 product jam 流程。对使用者来说，你只是用了一个 product jam 引擎，而这个 Agent 会在背后和其他 Agent 协同工作。
所以现在，我们是从这些基础构建模块开始，一步步往上搭，直到最终构建出完整的 orchestrating layer。
👦🏻 Lenny Rachitsky
听你分享下来，一个很明显的感觉是：你们把大量精力放在了产品开发的前半段，像是如何定义正确的需求、如何处理信任问题，以及 product jam 和用户研究这些环节。
我猜你们之所以这样做，很大程度上是因为写代码本身，已经被 AI 工具显著加速了。
能不能谈谈，为什么你们认为这是最值得投入的地方？
🧙🏻Tomer Cohen
是的，毫无疑问，我们在编程上的投入其实很早就开始了，现在这些工作也逐渐进入正轨。我们已经有了自己的 coding agent，并且把相关工作拆成了两个阶段。一个是偏向 “想法到设计” 的阶段，另一个是我们称为“代码到发布” 的阶段。
其中，“代码到发布” 这一段已经投入了大量精力，也取得了非常明显的进展。从编程 agent，到我们称为维护 agent 的系统，当 building 出现问题时，它可以自动处理相关工作，这一整条链路都在持续优化。
目前，已经有接近 50% 的构建和相关质量保障工作，是由维护 agent 和 QA agent 完成的。
👦🏻 Lenny Rachitsky
这太酷了。
🧙🏻Tomer Cohen
但在我们推出这个计划之前，我们在“想法到设计”领域并没有投入太多资源。而这恰恰是非常关键的一部分工作，至少在进入 coding 阶段之前。
我们的想法是赋能所有人。如果你是一名工程师，你基本上可以在流程的前端使用所有这些工具，并成为一名 full stack builder。
👦🏻 Lenny Rachitsky
从你提出这个想法，到真正把第一支团队组起来、开始构建这些初代的 agents，以及重做底层代码架构，大概花了多长时间？
🧙🏻Tomer Cohen
我是在去年年底向公司内部正式宣布这件事的。之后先画了一段时间搭建团队、设定内部流程。
我们最早的一批 agent 的 MVP，大概是在模型训练完成后的四到五个月左右做出来的。
但如果只算投入在构建上的时间，其实就是几个月。大量的工作是在把所有数据语料集中起来、清洗干净。你不能简单地把所有云端文档全都丢给模型，让它自己理随便推理。这样做效果非常差，因为它无法判断历史内容的重要性，也不知道哪些信息该被赋予更高权重。
你必须先想清楚：在什么情境下让它看到什么信息、它该专注哪些知识范围；同时还要整理出一批高质量的黄金案例（golden examples）。
简单地让模型遍历整个知识库并推理，是行不通的。
👦🏻 Lenny Rachitsky
这很合理。比如说，有个研究员可能对某件事有强烈观点，而你并不同意，但模型不知道这一点。它会直接把那些观点当成数据、当成事实。
🧙🏻Tomer Cohen
完全正确。而且模型经常无法理解：哪些内容与原始规格、与最终的成功指标相关。
所以，当你把这些工具引入团队时，不能只是“把它们接进来”。更关键的是，你必须想清楚到底要喂给它什么。所谓喂数据，绝不只是开放访问权限这么简单。
我看到很多团队把重点放在工具的连接和集成上，这让我想到十多年前——我在领英 共同重建信息流的时候，我们是从零开始的。当时我必须亲自坐下来，一条条筛选哪些是好内容。
为了整理出一整套高质量的“黄金样例”，我花了好几周时间。但最关键的并不是把所有数据塞进去，而是确保模型吃到的是对的那部分数据。这确实需要投入。
所以我会对现在正在考虑进入这个阶段的公司说：你必须在前期投入这些基础工作，之后才能收获效率和质量的提升。
我觉得这里有个关于 AI 的普遍启示：无论你是不是第一次接触 AI，无论你用的是 Cursor、做设计用的是 Figma 或其他工具，你都必须准备好投入那些前置时间，之后你才会真正看到速度和质量的增长。它们一定会到来，但前期投入无法跳过。
👦🏻 Lenny Rachitsky
那团队规模现在有多大？有多少团队在使用？你们已经上线了哪些东西？能不能帮我们描述一下目前的状况？
🧙🏻Tomer Cohen
当然。我们已经有相当一部分团队在用这些工具，并且持续给我们反馈，也已经出现了不少成功案例。
我通常用一个简单的公式来衡量它的价值：实验量 × 实验质量 ÷ 从想法到上线所需的时间。
从时间上看，无论是 PM、设计师还是工程师，现在每周都能节省几个小时：分析 Agent、快速原型工具和 product jamming 体验都发挥了很大作用。
在质量方面，我们看到洞察和讨论的深度变得显著更好。而且质量和时间有时候是互相促进的：质量越高，就越不需要花那么多时间返工或验证。
至于使用规模，我不会说已经达到组织的大部分比例，因为我们还没在内部正式“全员发布”。预计未来几个月、所有条件成熟后就会进行。
现在很明显的信号是：所有人都想要权限。都希望参与进来。
👦🏻 Lenny Rachitsky
那你们目前是怎么试点的？是某一部分人先拿到这些 agent 的使用权限，然后继续按他们原本的工作方式，只是多了这些工具？
还是说你们专门组了一支团队——规定“从现在起你就要按照这种方式工作”，然后观察会发生什么？
🧙🏻Tomer Cohen
基本上，我们确实有一支核心团队，负责在整个研发体系内构建 full-stack builder 的轨道和工具。
然后在各个领域内，我们有一些小团队在使用它。也就是说，我们会选择特定领域，把工具给到那里的团队使用。唯一的条件就是：他们必须持续给我们反馈。
这样工具才能不断变得更好，而不是单纯给你一个权限就结束。我们希望这些团队是真正会使用它、会推动它演进的人。所以目前我们采用的是一种 pod 模式 来试点。
👦🏻 Lenny Rachitsky
所以这些 pod 就像是大团队里的一个小单元？比如由设计师、PM、工程师组成的一组？能举个例子吗？现在 LinkedIn 的哪些团队在试行这个模式？
🧙🏻Tomer Cohen
我们最近刚上线了「语义人物搜索」和「语义职位搜索」。这些项目在构建过程中就使用了部分新工具。
在这个项目中，PM 可以直接自己搭 dashboard，不需要等设计资源排期。
然后有一个设计团队——最早是从他们的经理开始推动这件事的。我常跟他们说的一句话是：“不要等内部正式 GA，先用起来。”结果现在，这些设计师开始自己提交 PR，这在过去几乎不会发生。
这种变化很快开始向其他团队扩散，越来越多的人主动想加入，有点从基层自发扩散的感觉.
不过，最早正式推动还是来自高层，
我们把产品领导层从过去的职能线结构（Design、PM、BD 等）转为按产品领域组织，让他们真正能跨完整产品栈来负责。他们完成“360 度能力评估”，确保他们具备 full-stack building 的方式。
同时，在人才培养上，我们也会从明年开始用 Associate Product Builder（APB） 项目，取代原有的 APM。新人加入 LinkedIn 后，会经历严格的训练流程，加入这些 Pods，并在未来逐步成为核心人才来源。
👦🏻 Lenny Rachitsky：
所以未来的 APM 项目，可能就是你们现在说的这种 full-stack builder 方向的 APM 项目了？
🧙🏻Tomer Cohen：
某种意义上确实是这样。我们为这批新人准备的训练真的非常棒，我真希望我自己当年也能加入（笑）。
我们为他们设计了一套非常系统、非常先进的训练体系，这套体系未来也会成为我们推广全公司训练方式的基础。
我们看这些人才的方式是这样的：
你可能有很强的技术能力，但还不是一家公司的工程师；
或者你有很好的设计品味，但还没有在大规模产品环境中设计过。
我们会在 LinkedIn 教你如何真正把这些能力用在公司里、用在产品上。而这些训练内容未来也会扩展到整个组织。
👦🏻 Lenny Rachitsky：
明白。虽然现在还比较早期，但你之前说团队目前每周大概能节省好几个小时，是这样吗？
🧙🏻Tomer Cohen：
是的。而且我觉得最关键的其实是反馈。我们把这件事当成一款在 LinkedIn 内部打磨的产品，早期使用者不断给我们反馈，而这些反馈目前都非常正向。
有趣的是，使用得最积极的反而是 LinkedIn 里最顶尖的人才。他们的产出质量明显变高，也更愿意投入时间参与共建，推动这套体系继续扩展。
这也是我们对未来充满信心的原因。我预计在接下来的 6 个月左右，会有更多团队开始采用，到那时，更宏观的效果也会逐步显现出来。
👦🏻 Lenny Rachitsky
这个洞察真的很有意思：顶尖人才反而从这些工具里获益最多。因为一直有个争论——AI 会让普通人变得更强，还是会让已经很优秀的人变得更强？听起来更可能是后者
🧙🏻Tomer Cohen
是的。某种程度上这既让人意外，也不算意外。你当然希望所有人都能从中受益，但现实是，最先、也是用得最好的人，往往是组织里最顶尖的那一小撮。他们本身就有持续精进的动力，也更愿意尝试用前沿的方式 build。
这也是为什么我经常问团队一句话：如果我们把这些工具全部做出来，他们真的会用吗？而我现在非常清楚答案：不会。光有新工具是不够的。最先行动的，通常只是组织里大约 5% 的人，他们天然偏好变化、乐于尝新。
你必须建立激励机制、示范案例、清晰的使用方式。人们需要看到成功案例，才会改变。
我在 LinkedIn 推动从桌面时代转向移动时代时，也经历过同样的挑战。变革管理和文化投入，才是决定成败的关键。绝大多数人需要被带着进入变化，而这，反而是目前最重要的工作。
👦🏻 Lenny Rachitsky
对，而且也很容易理解为什么很多人不愿意投入时间——他们已经很忙了，却要额外去学一个短期内看不到回报的新工具。你之前提到，成功有三个关键部分：平台、工具，以及文化。那在文化层面，你们真正做过、而且确实有效的事情是什么？比如制造一点 FOMO，这类方式真的有用吗？
🧙🏻Tomer Cohen
是的，我必须强调：平台和工具只是必要条件，但远远不够。真正决定能否成功的，是你是否愿意在文化层面持续投入。而文化转变在一开始一定是慢的——我在从桌面转向移动的过程中已经验证过这一点。但一旦启动，它的推进速度会非常快。
人们的行为非常受预期驱动。换句话说，你必须明确告诉他们，在某个角色里我们期待他具备什么、做到什么。
👦🏻 Lenny Rachitsky
比如改变绩效评估的标准吗？
🧙🏻Tomer Cohen
完全没错。从招聘、能力校准到绩效评估，都需要重新设计。我们在早期最看重两点：主动把 AI 纳入工作的意识和 AI 素养（AI Agency & AI Fluency）。关键不在工具本身，而在于员工是否愿意用、愿意一起把它打磨得更好。
另一个关键是跑出真实的成功案例，这也是 pod 模式的意义所在。不是证明“工具能用”，而是展示“它真的带来了成果”。我们甚至看到合作团队和 BD 团队加入进来——过去需要工程师支持的工作，现在有人直接自己完成，用行动告诉别人：“我能做到，你也可以。”
在人才培养上，APB 项目本身也是一种强烈的文化信号。新人能被系统性地训练成多栈能力者，这会在组织里形成示范效应。与此同时，在全员场合公开展示和庆祝这些成功，也非常重要。
最近就有一个很典型的例子：一位用户研究员看到增长 PM 的空缺，主动站出来，用 AI 工具补齐能力，从 UXR 转型为增长 PM。这不是传统路径，但却真实发生了。像这样的跃迁案例，对文化的推动作用非常大。
归根结底，这一切不能靠命令推动。工具要足够好用，反馈要足够顺畅，人们要看到真实的成功，感受到投入是值得的，最终在自己的工作中看到质变——文化才会真正发生。
👦🏻 Lenny Rachitsky
你刚才提到的几个点——像展示成功案例、让大家看到同事如何实际用 AI 工具、打造一个带点“准入门槛”的项目让人报名加入，还有绩效调整——这些都很关键。因为一旦晋升和评价标准变了，人的行为自然就会跟着变。
所以我很好奇：你们现在已经在 PM，或者更广泛的岗位体系中，把这些能力正式纳入绩效考核了吗？还是仍然处在逐步推进的阶段？
🧙🏻Tomer Cohen
我们是在两个层面同时推进的。首先是在我自己的直属团队，我们做了 360 度评估，结果会直接反馈给个人，这本身就形成了很强的激励。
之后我们把这个机制推广到更大范围。现在招聘中已经明确在寻找具备这些能力的人，接下来也会正式纳入绩效评估，并已对全员公开。大家的反馈其实很积极，因为标准清楚了，也有真实案例可以参考。
但这类机制不适合一刀切地快速铺开。我关心的是你是否真的具备端到端的思维方式，是否主动利用工具把事情从头做到尾。
所以我一直强调，不要等公司正式通知才开始以新的方式 build。不管你手上有没有“官方的工具包”，你都可以先自己构建、先用起来，用结果证明自己。先在心态上成为一个 full-stack builder，而不是等别人给你一个头衔。
只要这样做，变化自然会发生。而我们最优秀的一些人才已经这么做了，也因此走得更快。
👦🏻 Lenny Rachitsky
那你们是怎么鼓励大家自己去用这些工具的？有没有什么方法，让人们在不加入正式项目的情况下，也愿意自己去尝试？
🧙🏻Tomer Cohen
我们做的很多工具都会定期分享。我好几次全员会都拿来讲“怎么使用这些工具”。 我们会在全员会上持续分享这些工具的用法，同时也鼓励大家主动展示自己发现、用得顺手的新工具，不论是在 Slack、消息群还是其他地方，形式并不重要。
老实说，现在大家确实容易被各种工具、教程、prompt 案例搞得有点不知所措。 但真正重要的是：找到一个你觉得特别好用、特别能提升效率的点，然后把它用深、用透，再带着别人一起体验，这样影响力才不会只停留在少数人身上。
👦🏻 Lenny Rachitsky
有没有什么让你意外的负面结果？比如 PRD 变得太 AI 驱动、反而让人变慢？
🧙🏻Tomer Cohen
有的。一个出乎我意料的地方是，很多工具并不能真正做到即插即用。我们一开始也尝试过直接给 AI 打开对所有历史文档和上下文的访问权限，但效果非常差，出现了大量幻觉。这迫使我们投入大量精力去清洗、结构化数据。原因之一是我们有非常多的历史信息、遗留代码、旧知识库、旧设计等等。
另一个挑战是工具分散。我们希望收敛到一套统一工具，但现实是，人们会自然选择自己熟悉的工具，这让统一变得很难。
在质量上，我们目前确实看到明显提升，但这很大程度上是因为还处在早期阶段，使用者本身就更愿意反复试验、快速迭代。整体来看，工具的普及速度依然是个难题。
还有一点很重要：不是所有人都需要、也不应该成为 full stack builder。专业化依然有价值。我并不期待组织里的每个人都转向这一模式。
我认为未来会有两类角色并存：一类是系统构建者，负责为全栈构建者提供基础能力；另一类是继续保持专业化的人。只是相比过去，对纯专业角色的需求可能会减少一些。
👦🏻 Lenny Rachitsky
所以 Full Stack Builder 已经是正式职称了吗？他们不再叫产品经理或工程师？
🧙🏻Tomer Cohen
我们在公司内部确实设立了一个正式的 Full Stack Builder 职称，我们正在逐步把符合条件的人归入这个序列。
👦🏻 Lenny Rachitsky
那等于是在形成一条全新的职业路径了。你们现在主要从哪些职能里找到这样的人？产品、工程、设计，还是混合的？
🧙🏻Tomer Cohen
是混合的。我给大家的建议是，先看看自己组织里有哪些人已经在跨职能工作——不论是工程、设计、产品，甚至 BD。你会发现，其实已经有不少人具备这种跨界能力了。
👦🏻 Lenny Rachitsky
那有没有哪个职能在这方面表现得特别突出？
🧙🏻Tomer Cohen
我觉得关键不在职能，而在心态。如果非要说哪项技能最难学，我会说是设计——要把“设计类 agent”做到很好，需要额外投入很多精力。所以相比之下，让设计师学习其他技能，反而更容易一些。
但说到底还是心态问题。我见过设计师写代码，也见过 PM 做设计，而且都做得很好。真正能跨职能的人，分布在各个团队：他们有主动性，愿意尝试新工具，已经在构建新体验，也有很强的成长心态。到这个阶段，他们最初的背景和头衔，其实已经不那么重要了。
👦🏻 Lenny Rachitsky
我很喜欢你们正在做的一点：现在是历史上最容易在不同产品角色之间转换的时代。设计师转做 PM，或者转向这种全新的角色，都比过去容易得多。
🧙🏻Tomer Cohen
这是我最常对团队强调、也最能激励他们的一点。因为归根到底，现在个人和组织的激励都是一致的。
组织需要改变，需要变得更敏捷、更有韧性；而个人在职业发展上，也希望站在前沿、掌握新的构建方式。你为了自己职业成长想做的事，恰好也是组织最需要你去做的事。
所以我能给他们的“许可”，更多只是顺势而为。不是要求他们改变，而是支持他们去做本来就想做的事情。
👦🏻 Lenny Rachitsky
最后一个问题：如果有人听完觉得他们公司也该开始干这件事，你会给他们什么建议？该怎么在公司里顺利启动这样的转型？
🧙🏻Tomer Cohen
我会先想清楚整个体系该怎么搭建，基本分成三层：平台、工具和文化。平台和工具是必要条件，但远远不够，真正决定成败的是文化。你要认真思考，如何把人带上这趟旅程。
如果重来一次，我会更早把正在做的事情展示给整个组织，而不是一开始只和核心团队深度合作。事后看，如果更早让大家看到工具、理解方向，效果会更好。
耐心和投入也很重要。现在从零做一个产品，一周内确实能做出来；但推动一家大型组织转型完全不同。你需要对目标保持紧迫感和雄心，同时在执行上足够谨慎、有耐心，并清楚哪些地方必须持续投入。
如果你不愿意投资平台、不愿意为自己定制工具，最终得到的只会是并不适合你的通用 agent。
归根结底，还是那句话：前期投入是绕不开的。不要期待一周内效率翻倍。个体层面也许会很快见效，但真正重要的，是持续跑出成功案例，并从组织层面推进这场转型。
👦🏻 Lenny Rachitsky
太酷了。我知道现在已经有很多产品负责人和领导在向你取经。很高兴我们今天把这些话题系统地聊了一遍。最后一个问题：还有没有什么我们没提到、但你觉得对听众特别有帮助的？？
🧙🏻Tomer Cohen
无论你是在组织里等着领导去推动这件事，还是你自己就是那个想推动的人，我的建议都是：别等了。
我当时做的第一件关键事情，就是尽早向全公司明确方向：我们从小范围试点、用 pod 的方式推进、打造工具，但这是一段大家要一起走的长期旅程，而不是一个终点状态。我们不会“到达”某个完成态，只会持续变得更好。
在今天的竞争环境下，你只需要在“ build ”这件事上比别人更好就行了。而 build 的方式本身未来几年会不断重塑，所以千万不要等。
真正重要的是持续推进、不断复盘，并和团队保持透明沟通——不仅讲愿景，也要展示阶段性成果。如果你是领导者，就给自己设定可以公开的 KPI 或 OKR，为这件事负责。
如果你是个体贡献者，那更不用等。不管你的 CPO 或 CEO 有没有正式宣布，都可以先开始行动；要么推动改变，要么加入一个已经在这样做的组织，让自己站在未来产品构建方式的前沿。
Part IV 快问快答：
👦🏻 Lenny Rachitsky
说到这里，我们要进入令人兴奋的快问快答了。
第一个问题：有哪些书是你最常推荐给别人的？两到三本都可以。
🧙🏻Tomer Cohen
我通常喜欢成套推荐三本书，它们的主题非常不同。
第一本是《国家为什么会失败》。它对国家成功的解释从制度入手，区分了“掠夺型制度”和“包容型制度”，讨论一个系统是否真正让更多人参与、共享机会。这本书对我理解产品如何构建公平的机会系统，理解产品和制度设计，都很有启发。
第二本是《超预期寿命》，这本书围绕“医学 3.0”，也就是个性化医疗，系统地讨论了长期健康该如何被真正优化。在 AI 时代，这种思路会变得越来越重要。
第三本是《无穷的开始》。这本书读起来不算轻松，但它深刻影响了我对“因果”和进步的理解。它的核心观点是：只有当我们对世界运行机制有了清晰、正确的解释，真正的突破才会发生，而一旦发生，进步几乎是无限的。
👦🏻 Lenny Rachitsky
那最近有没有你特别喜欢的电影或电视剧？
🧙🏻Tomer Cohen
有一个我很喜欢的希伯来语的播客，叫 「One Song 」。每一集都会选一首相对知名的歌，然后深入讲这首歌的起源和历史。我非常喜欢音乐，而他们分析一首歌的方式真的很精彩，也特别擅长把这首歌背后的故事呈现出来。
👦🏻 Lenny Rachitsky
你最近有没有特别喜欢的新产品？可以是一个 app、衣服，或者小工具之类的。
🧙🏻Tomer Cohen
我倒是有一个我特别想要的产品，而且我觉得做出来其实一点都不难。
现在我的车里内置了 Alexa，孩子们可以一路点歌，车里像个小型演唱会。我最喜欢做的一件事就是用语音模式去和 ChatGPT 对话，不过这样做还是有些摩擦。我真正想要的是方向盘上有一个按钮，一按就能唤出我的 AI 伙伴，就像坐在副驾驶一样。我觉得那会完全改变人们的行车体验。
👦🏻 Lenny Rachitsky
你有没有一个人生座右铭，在工作或生活中对你很有帮助？
🧙🏻Tomer Cohen
我之前提到过一句我很认同的话：“I might be wrong, but I’m not confused.”（我可能会错，但我不迷茫）。
不过真正影响我的，是“成长型心态”。我特别喜欢这句话
“Becoming is better than being.”
我觉得它和 full-stacker builder 的理念也很契合。
重点从来不是“达到某个状态”，而是你始终处在演进、迭代、前进的过程中。你应该爱上的是过程，而不是结果——不断成长，不断进化，不需要焦虑，也不必 FOMO。
我常常问自己：如果我回头看一年前的我——我成长了多少？我学到了什么？我又掌握了哪些新技能？我是不是已经成为“更新版本”的自己？这个差值，就是我喜欢的那种思考方式。
👦🏻 Lenny Rachitsky
顺着这个话题来到最后一个问题。这期节目上线时，大家已经会知道你在 LinkedIn 14 年的旅程即将告一段落——这是一段非常传奇的经历。你加入得很早，也亲历了公司巨大的变化。所以我想问的是：你现在的心情如何？接下来有什么打算？
🧙🏻Tomer Cohen
我更多感受到的是一种自豪。
我第一次真正了解 LinkedIn，是刚搬到硅谷的时候。那是在斯坦福听的一场 2008 年关于社交网络的讲座，Reid Hoffman 讲到“线上职业社区”的力量，当时我就觉得这是一个非常有前景的愿景。后来机缘巧合，我加入了 LinkedIn，很快就发现这家公司的使命和我的价值观高度一致。
回头看，我在 LinkedIn 学到的很多东西，其实都来自那些艰难的时刻。正是这些困难让人成长，对此我非常感恩。
同时，我也对未来感到兴奋。我一直喜欢变化，喜欢把自己放在能学到最多、成长最快的位置。现在是一个非常适合 building 的时代，我很期待去探索新的问题和新的领域。
👦🏻 Lenny Rachitsky
我觉得你可能需要很长一段时间，才不会再觉得自己还在 LinkedIn 工作，也才能慢慢放下那些这些年来一直让你操心的事情。
🧙🏻Tomer Cohen
当你花那么多年去打造一件东西，一个 builder 最重要的特质之一，就是会对自己正在构建的东西投入强烈的热情。不是在乎这份工作本身，而是发自内心地在乎产品。
当有人抱怨时你会感到痛，那种持续的“不满足感”就像在养育一个孩子。所以这很难，也永远都会很难。我会一直把 LinkedIn 视为我曾经帮助养大的“孩子”之一。
👦🏻 Lenny Rachitsky
我很期待未来某一天你回来，告诉我们你接下来想做什么，或者开始了什么新的项目。我很高兴借这个机会真正认识你。Tomer，非常感谢你来参加节目。
🧙🏻Tomer Cohen
谢谢 Lenny。