在 AI 时代，产品经理如何活下来？| LinkedIn CPO 访谈

在 AI 时代，产品经理如何活下来？| LinkedIn CPO 访谈 在 AI 时代，产品经理如何活下来？| LinkedIn CPO 访谈 Modified January 18 👦🏻 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 你刚才提到的几个点——像展示成功案例、让大家看到同事如何实际用 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。 🔗 原文链接： https://mp.weixin.qq.com/s/Yaj e1XE... https://mp.weixin.qq.com/s/Yaj e1XE... 原创 十字路口 十字路口 十字路口Crossing2026年1月17日 12:37 上海 到 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 的能力做好、做清楚，能够清晰地评估和衡量它们各自的表现。 这里面其实是有“专业分工”的。与此同时，我