AI 时代的产品领导力：设计阶段已死、故事为王 (Noam Lovinsky)

▍嘉宾：诺姆·洛文斯基 (Noam Lovinsky)

诺姆·洛文斯基是硅谷资深产品领导者，现任 Superhuman 首席产品官，掌管产品、设计、数据科学与增长团队。

• 谷歌与 YouTube：早年以产品管理总监身份在 Google 工作五年，负责 YouTube 的全部应用，是 YouTube 消费端体验的早期产品负责人之一。
• Thumbtack 与 Meta：曾任本地服务市场 Thumbtack 首席产品官；后在 Facebook/Meta 任高级产品管理总监，参与创建新产品实验（New Product Experimentation, NPE）孵化器团队，专做从零到一的产品开发。
• Grammarly/Superhuman 时代：2023 年起出任 Grammarly 首席产品官，随公司更名与并购扩张，现任 Superhuman 首席产品官。更早的职业生涯中，他还曾在企业门户软件公司 Plumtree 与格伦·凯尔曼（Glenn Kelman）共事——这段经历在本期快问快答中被他亲自点名。

▍关于 Superhuman

Superhuman 前身是 2009 年创立于基辅的写作助手 Grammarly，经两轮并购与一次更名，转型为多产品 AI 生产力平台。

• 并购与更名：2024 年 12 月收购协作文档平台 Coda，Coda 创始人沙希尔·梅赫罗特拉（Shishir Mehrotra）出任 CEO；2025 年 7 月收购 AI 邮件客户端 Superhuman（收购时估值约 8.25 亿美元）；2025 年 10 月母公司正式更名为 Superhuman。
• 产品组合：Superhuman 套件包含四个产品——Grammarly 写作助手、Superhuman Docs（原 Coda）、Superhuman Mail 邮件应用，以及 2025 年 10 月随更名发布的 AI 助手 Superhuman Go。
• 资本与规模：2021 年融资时估值 130 亿美元；2025 年 5 月获 General Catalyst 10 亿美元非稀释融资用于并购扩张；年化收入超过 7 亿美元。本期对话正是发生在更名后三个月，洛文斯基在快问快答中复盘了这场"产品扩张"的来龙去脉。

Harry： 这里是 20Product，我是哈里·斯泰宾斯。20Product 是一档月度节目，我们每期请来最顶尖的产品领导者，请他们分享在 AI 时代打造优秀产品和产品团队的技巧、战术与策略。

今天我非常高兴地请到诺姆·洛文斯基，Superhuman（前身 Grammarly）的首席产品官（CPO）。加入 Superhuman 之前，诺姆是 Facebook 的高级产品管理总监；更早之前，他担任过 Thumbtack 的首席产品官，还在 Google 做了五年产品管理总监——听好了，YouTube 的全部应用都归他负责。

诺姆，兄弟，我太期待这场对话了，我听到的全是关于你的好评。刚才我还当面把你夸得坐立不安。通常你对风险投资人说"你背景调查的口碑特别好"，他们会说"别停，再多说点"；但你是真的会说"别说了，这让我很不舒服"——足见你的谦逊。非常感谢你今天来上节目，兄弟。

Noam： 是我的荣幸。谢谢邀请。

伟大的产品领导者是讲故事的人

Harry： 不客气。但我想先讲个小故事。我之前采访过 Redfin 的格伦（Glenn），他说你加入 Redfin 的时候（译者注：后文显示二人共事于 Plumtree，此处疑为口误或误听），公司已经换过好几任产品负责人，而你回答了一个让他至今难忘的问题。那个问题是：什么是产品领导者？他说你给出的描述非常简单，但极其精彩。那么当我也问你——什么是产品领导者、什么是伟大的产品领导者——那个描述是什么？

Noam： 我认为，从根本上说，伟大的产品领导者是伟大的讲故事的人（storyteller）：他能理解客户真正需要什么、真正需要解决的问题是什么，并把它编织成一个故事——不仅与市场、与客户充分契合、易于理解，还能让公司内部每个人都朝同一个方向使劲。

眼下有很多有趣的争论，说什么角色正在合并、产品和营销的边界在消失之类。我根本不认为这些东西是分开的，我看产品和营销就是同一件事，也许我这个观点正是由此而来。归根结底，好的产品领导者就是出色的讲故事的人，而最好的公司、最好的品牌，也都是出色的讲故事的人。

Harry： 顺便说一句，我们这节目从不提前发提纲——因为你一张嘴，我对提纲就瞬间失去兴趣了。我们团队老抱怨："哈里，我们花了好几个小时做调研，结果你直接脱稿跑题。"你刚才说到讲故事的人，我懂。但挑战在于：做横向产品（horizontal product）时，不同客户会被不同的故事打动。面对这么广的客户群，你怎么思考"讲好故事"这件事？

Noam： 问得太好了。说回你刚才的夸奖——你对这个问题的理解深度，在这个圈子里并不常见，我很欣赏。

我的答案是：你要去触及别的东西。你想营造的感觉是什么？在功能交付之后、在一个个小问题被解决之后，你留给客户的整体感受是什么？他们如何感到被支持？如何感到更沉浸于心流（flow）？取决于你追求的是什么。

Instagram 就是个好例子。Instagram 关乎的是具体功能、具体问题吗？还是说它更多是在迎合一种感觉——人们对虚荣的需求？我认为它的产品洞察在于：虚荣是一个比我们之前意识到的大得多的市场，是一种被点燃的潜在需求。这才是你真正要去回应的那种感觉。

Harry： 那你觉得产品领导者常讲的"烂故事"是什么？你实际观察到的是什么？

Noam： 可能因为我眼下对这事特别有感触——我已经很厌倦"这能让你更高效""这能让你更快"这类故事了。当我们不知道真正的价值是什么时，就会拿时间和效率这类东西来兜底："它能帮你省时间，人人都想省时间，那就看看'省时'这个说法能不能打动人吧。"

这是个万金油，却不够深。你本该再往深处挖一层：除了"想更快、想进入心流"这种感觉之外，你究竟在解决什么问题？而那是一个焦虑问题。

设计阶段会消失吗

Harry： 很多人觉得，在氛围编程（vibe coding）和原型制作变得又快又真实的世界里，设计阶段会消失。你同意吗？

Noam： 不同意。有意思的是，我们把这些事当成新东西来谈，可我不认为它们有多新。真正变化的是：工具集正在加速一些早已存在很久的趋势。

看看你投过的所有公司——最好的团队，都是人才被压缩到更少数人身上的团队，一个人戴很多顶帽子。"你是设计师，所以你就待在自己的赛道里，做这些任务，不碰工程、不碰产品"——这种想法根本说不通，现实从来不是这样运转的。我理解，随着规模扩大，人们会觉得每个人都要专业化、在自己的赛道里越钻越深，但我从来不认为那是真的。

而现在，工具让这件事变得更加不成立。过去，要在这些领域专精、要成为什么都能做的"独角兽"，你得学会某一门工作的语法、工具和技法；现在不需要了。所以，设计阶段会消失吗？不会。那种思考你仍然要做，只是做这种思考的工具变多了。有时候——

Harry： 但作为今天的设计师——我请过 Duolingo 的首席产品官上节目，他非常棒，他们聊到国际象棋功能的引入：两位设计师用氛围编程捣鼓了几天，就做出了一个所有人都能上手玩的可运行原型。当你能用同样的时间把想法直接氛围编程成现实时，设计师还有什么理由只交一份"设计稿"？

Noam： 有意思——"同样的时间、同样的效率"。我不确定，当你还处在设计思考（design thinking）阶段时，直接做原型是否同样高效。

如果你问的是：当你想让别人共情、理解并"感受到"你的想法，想用信号最强的方式传达时，是否该尽快给出这个想法最高保真的近似物——那我的回答是：是，这很必要。作为设计师，只要你有时间和条件，就应该能做出那个原型、那个可运行的产品，去让别人共情你的想法。

但这并不意味着，当你刚开始思考的时候，一块白板、一张白纸，或者一块按"老掉牙"方式工作的 Figma 画布，就不是最好的起点。我仍然认为，设计思考能从这些不同的媒介、不同的思考方式中获益——因为它们施加的约束，因为它们创造的空间。

这跟另一回事是两码事：当你已经到了想分享想法、想让别人尽可能深地共情它的阶段，最好的做法是什么？是让人去用、去感受它——用你认为它应有的最高保真近似物。那可能是一个可运行的产品或原型。但我不认为这意味着所有设计思考都应该从氛围编程平台开始。

从 Cursor 到终端：工具栈的迁移路径

Harry： 现在你们产品团队里最常用的工具是什么？Cursor？Claude Code？Cognition？你在内部看到了什么有意思或出人意料的东西？

Noam： 说到 AI 编程，Claude Code 绝对是遥遥领先的那个。我看到很多人的路径是：从 Cursor 这种交互界面更熟悉的工具起步，然后转向终端（terminal）。转向终端会带来很大的自由——抽象层几乎不再可见，你不再纠结它创建了哪些文件、也不去逐个检查文件，慢慢建立起那种信心。这是我看到最多的。

再往下，是用更熟悉的应用做原型，比如 Lovable 或 Figma Make。我看到的典型迁移路径是：从 Lovable 这类工具起步——更熟悉、没那么吓人、不那么像在"写代码"；然后转到 Cursor 这样的工具；最终走进终端。

给人写规格文档的时代结束了

Harry： 今天的产品开发里，有哪些事是我们三年后不会再做的？

Noam： 给人写规格文档（spec）。我希望大多数人已经不再给人写规格文档了。给智能体（agent）写规格文档才是真正有用且聪明的做法，而且它的形式也不一样，写法也会随之改变。就是这样。

Harry： 当规格文档是写给智能体而不是人时，世界会发生什么变化？需要改变什么？

Noam： 有些东西还是值得保留的。比如：我在为谁做产品？我要解决什么问题？这些根本性的问题不变。但当你写文档的对象是真正去干活的那一个时，你最终会写出不同类型的细节，连文档的组织结构都会不一样。

多举例子是有好处的。建一个上下文资料库：过去哪些做法有效、值得效仿，哪些没效、要避开。写给人看的时候，你会默认对方有这些隐性知识——毕竟你们一直并肩做事，他们懂——所以你不觉得需要把那么多东西嵌进文档里。但当有个东西要直接基于这份规格文档和计划文件来自举、来写代码时，你实际上得把上下文工程（context engineering）做进文档里，这就改变了你该往里放什么。

我还认为写法也该变：你应该让那个将要写代码的东西来帮你写文档，因为它产出的版本会更兼容它自己对这项工作的理解。

Harry： 我有一堆问题，这话题我太喜欢了。如果我们都给智能体写规格文档，那产品会不会趋于同质化，创造力会不会见顶走平？给人写文档的美妙之处在于，人会带来自己的经历——比如在以色列的基布兹（kibbutz）长大，以非常不同、非常酷的方式思考问题，这会影响他对协作功能的设计，把这种独一无二的异常体验带进产品流程。而给智能体写文档、由它去执行时，你就失去了这种灵光乍现的元素。我们会看到这种情况吗？

Noam： 我觉得两种都会看到一点。实际上我认为这反而会让创造力——当然还有品味——比以往任何时候都更突出。因为会出现一种「压平」：大量东西变成「又来了，还是那套对话、那套流程，这就是被验证有效的做法」。这些模型学到了什么有效，就输出什么。但这恰恰给那些真正出众的、有品味有创造力的东西留出了更大的发光空间。说到底，想清楚这件事仍然是人的工作。

打个比方来说这种「压平」，回到 Instagram 对照片做的事。我们经历过一个阶段：每张照片都好看得不行，加了滤镜、精修过，「看看我光鲜亮丽的生活」。这是对「什么是好照片」的一次创造力压平。然后慢慢地、自然而然地，人们觉得更有趣、更打动人的，反而是那些看起来有点乱、有点原生感的东西——压平期过后，流行的风向变了。我认为应用也会经历类似的过程。

氛围编程不是炒作，价值捕获另说

Harry： 容我问一句。干我这行的好处是，我可以向真正聪明的人请教智慧，用在另一份工作上——不得不承认，那份工作比做媒体赚钱多了，毕竟用的是别人的钱。孩子们，记住这条金句：OPM，别人的钱（other people's money）。瞧，这节目尽输出这种智慧。说回正题：氛围编程，我作为投资人一直纠结这个赛道。你认为它会是一个持久的赛道吗——让非技术职能的人也能快速搭起开发站点之类的？Lovable、Replit、Bolt、Base44 这些会不会进驻每个销售和市场团队？还是说这只是一时的炒作周期？

Noam： 「人人都能构建」这个理念绝不是一时的炒作。我们一次次见证过：你可以把创造这件事民主化。想要且能够创造的人远比我们以为的、比目前观察到的多得多，而且这个群体会不断扩大。所以这一点不会消失。

至于价值捕获会落在这个技术栈的哪一环，那是另一个问题。是在部署、托管和分发环节吗？你会为工具本身付费吗？这是另一回事。但我从根本上认为，这些氛围编程工具会不断向技术栈上游走——它们构建的不是集成开发环境（IDE），而是一种服务，一种替你做事的思考型服务。

Harry： 朋友，哪条路更容易？是 Claude Code 和 Cursor 向下走、吃掉消费端更容易，还是消费端的 Lovable、Base44、Replit 们向上攀登技术栈、吃掉开发者端更容易？

Noam： 我认为当下最难的是找到一种能扩展到最广大普通用户群体的用户体验。我们已经明显处在大家所说的「能力过剩」（capability overhang）阶段：这些模型能做的事，和人们实际能用它们做成的事之间，存在巨大鸿沟。

所以问题变成：是 Claude Code 更容易找准正确的用户体验，还是像 Manus、Lovable 这样更活跃在 UX 应用层的公司更容易解锁用户体验？我大概会押注已经在 UX 应用层深耕的人，但那些基础模型实验室也在做这件事，也在努力学习这一层的东西。

一半代码由 AI 编写：配比、测试与探索速度

Harry： 在 Superhuman 内部、在你们旗下各个产品里，如今新增代码有多大比例是 AI 写的、多大比例是工程师写的？

Noam： 我认为我们基本已经到了接近一半的水平。而且这个比例还能高得多。

Harry： 你觉得 24 个月后会是多少？

Noam： 24 个月后，我希望是 90% 左右。

Harry： 到了 90% 的时候，我们怎么办？工程师会变少吗？还是说我们做出多得多的产品？多出来的这 40 多个百分点被 AI 接走后，世界会变成什么样？

Noam： 我认为答案绝对是后者：我们会做更多的东西。我从没待过哪家公司的路线图是有尽头的——没有哪家会说「我们这就算做完了，只需要这么多人」。我确实认为我们正在经历、也必将经历一个阶段：我们需要多少人、产品团队的理想配比是什么样，这些都在发生根本性转变，这显然会带来一些让人不好受的动荡。

但一旦这一切回归常态、我们有了更清晰的认识，我们想做得更多的欲望不会消退。我们会继续扩张，只是换了一种方式切分工作。

Harry： 你刚才说产品团队的配比在变。你觉得它是从什么变成什么？你怎么看这个变化？

Noam： 想想几年前，你要从零到一组建一个团队，像样的配置是什么样？视问题而定，上限大概是五到十个工程师，配一名产品经理（PM）、一名设计师。而现在，更多时候你需要的是一名产品经理、一名设计师、两名工程师。

而且每个人的分工也大不一样了：人人都在写代码，人人在做产品，少数人就能覆盖产品流水线宽得多的环节。我认为这会做出更好的产品。

Harry： 完全同意。团队更小了，人人都还在写代码。那再往后看，在 AI 的世界里，测试和部署发生了什么变化？还是从根本上说没变？

Noam： 首先，AI 能做大量测试工作，至少第一轮排查能把所有明显的问题都抓住。甚至值班事故——坏事发生的时候——AI 也能做大量分诊（triage）和初步排查。等事情转到值班工程师手里时，它直接给出：我认为问题出在这儿；修复方案有三个，你要走哪条路？随着上下文和记忆不断积累，它问你的会越来越少。所以我认为，整条栈最终都会以同样的方式被自动化。

Harry： AI 到底让你们的团队快了多少？能交付两倍的东西？三倍？四倍？我知道这很难量化，就当是帮一个不身处产品一线的人理解一下。

Noam： 对我们团队来说，真正能压缩的是探索阶段，以及探索阶段的迭代速率——你能多快走到「这才是我们真正要构建的东西」。我们试过、测过、迭代过，这个阶段确实显著缩短了。我说不好是 2 倍还是 3 倍，但推到极限，它带来的加速非常可观，因为通常——

Harry： 「探索阶段缩短了」具体是什么意思？

Noam： 就是我们观察到一个问题，怎么为它构建一个解决方案？好，试着迭代一下方案可能长什么样，拿去找一些客户测试——哦，这个不对，换一个再试。这个循环你能压缩多少？能并行跑几条？谁能独立跑完这条完整的探索流水线？需要多少人参与？本质上，它大幅提升了学习速度，进而缩短了整个产品开发生命周期。如果一家企业的学习速度从根本上快了很多，整个业务都会获得巨大的加速。

当然，想到这件事时，大家的第一反应是：以前这些东西都是我亲手敲出来的，现在它替我敲了。是的，这显然也是一种提速，也确实省下不少时间。但结果是你会做更多别的事：你更多地在审代码，我们还得让审查流程变得可扩展，然后你只是并行地做更多事。总之，探索阶段的压缩和学习速度的提升，至少眼下对我们来说，是最大的加速器之一。

AI 的价值定价：从软件预算到人力预算

Harry： 说到工程效率的提升：假设一个工程师年薪 25 万美元——数字是我随口编的——AI 让他效率提高了 30% 或变得更强了 30%，那为他每年付 7.5 万美元的工具费就讲得通了。

Noam： 这说法有意思，但我不认为事情根本上是这样运转的。实际发生的是：工程师能把更多时间花在产品开发流程的其他环节上。他们能更多地施展产品能力，更多地施展数据分析能力。所以最有价值的人仍然是那些能身兼多职的人——技能组合更全面、并且能施展出来的人。以前这些技能更难施展，一是因为时间不得不花在别处，二是因为当时的工具要求你投入大量时间，才能发挥出这些技能。

Harry： 不，我是风投。我们很简单，投币式驱动，脑子里只有美元——在英国就是英镑。如果我们要从 AI 里赚到钱，就必须从根本上看到支出从软件预算转向人力预算——就像我说的，AI 干了一个工程师 30% 的活，那好，我们付它 30% 的薪水。否则我们就还停留在每席位每月 25 美元的老路上，潜在市场规模（TAM）就不会扩大。你帮我理解一下：随着软件支出转向人力支出，TAM 会扩张吗？还是我们都在嗑自家的产品嗑上头了，会一直停留在一个软件支出的世界里？

Noam： 我看到的 TAM 扩张是这样的：你能用软件解决的问题数量、能为人们做到的事情数量，会不断扩大。所以是的，团队会更小、更高效、做得更多——这会改变运营支出（OPEX）的会计基本面吗？会的。但我认为接下来发生的是：你通过提供更多服务、解决更多问题来实现扩张。这会不会导致更少、更大的公司？不好说，也许会。也许供应商太多了，真正需要的是更少的供应商，做更多的事、覆盖更全的技术栈。

只做产品不够了：平台思维的衡量与代价

Harry： 今天你必须成为平台吗？看 Superhuman，你们旗下有 Coda、Superhuman、Grammarly 这些产品；再看 Notion——我知道它是竞争对手，原谅我提竞品——他们现在集成了日历，开始做一些很酷的录制功能，当然还有他们那套很酷的知识管理系统。再看 Otter、Fireflies 这类公司，都意识到需要从产品走向平台。在一个必须做平台的世界里，只做产品是不是不够了？

Noam： 取决于你怎么定义平台。有一种定义是：别人能在你的产品之上建立自己的生意。这个定义未必适用于所有人。但「你的客户能在你的产品之上做构建」这一条，对每一家认真做产品的公司都是必选项，因为客户的需求总是有细微差别的。我们正快速进入一个定制软件大量涌现的世界，所以你必须具备平台思路，想清楚客户如何在你的平台和产品之上做构建和扩展，以满足他们的需求。

Harry： 那对天下的产品负责人来说，什么变了？当你身处一个客户需要在你的产品上构建有细微差别的、个性化、定制化功能和元素的世界？

Noam： 当你知道有别人在你的平台上做开发时，你思考问题、衡量影响的方式就完全不同了：怎么发布变更、怎么考虑向后兼容（backwards compatibility）、甚至怎么做实验、怎么衡量实验——谁在用你的产品做什么、你把什么改好了、又把什么弄坏了。

我最喜欢举的例子来自 YouTube——按「别人能在 YouTube 之上建立生意」这个定义，它就是平台。我们做实验、观察观看时长（watch time）的时候：嘿，观看时长涨了，大胜，全量发布——结果整个社区炸了。为什么？因为收益不是均匀分布的。你得按发布者和创作者的一个个群体去看：我伤害了谁的生意？帮了谁的生意？怎么在整个盘子上把它拉平？我的意思就是：你必须用不同的方式去观察事物。

AI 的隐忧与 2026 年的预测

Harry： 我能问个有点怪的问题吗？现在人人都兴奋得上头，觉得我们能建得更多、更快。在 AI 改变我们做产品的方式这件事上，有没有什么让你紧张或担忧的？

Noam： 也许我只是太看得起我们这个行业了。我愿意相信，在安全、敏感数据这些领域，大家仍在加上可观测性和控制机制，确保这类决策有合适的人在环（human in the loop）。

我想我们会经历一些糟糕的阶段：有人不负责任地使用这些东西，出现数据泄露、提示注入（prompt injection）之类的攻击。但那只是我们必须走过的学习曲线，不是什么从根本上让软件变差的东西。代码质量也不是我长远担心的。我更担心的是：我们是否真的用这些工具让生活和工作变得更轻松、更好，还是沿着一条我觉得我们已经在走的路继续走下去——我不确定我们用的很多工作工具、很多工作方式真的让我们变好了。我们确实能工作得更多、无时无刻不在工作，这有好处，对一些人来说也有坏处。

举个例子：创业阶段、十来个人挤一间屋的时候，我特别爱 Slack，它是我见过最好的产品之一。但说实话，在我现在的角色里，我不确定 Slack 真的让我把活干得更好、让我的一天更高效。我确实担心，我们正在构建的有些东西会滑向那个趋势，而不是真正帮我们做得更好、替我们卸下担子、去掉工作里的苦差事。

Harry： 我认为 2026 年会发生一件没人在谈论的事：7×24 小时的推理（inference）。每个人的推理会一直跑着，不只是你往 ChatGPT 里输入内容的那一刻；对大多数人——尤其是知识工作者——它会持续不断地运行。你同意吗？这会影响你做产品的思路吗？

Noam： 这个观察很好。到 2026 年它会不会在知识工作里普及，我愿跟你打个赌。至少在编程上，很多地方已经这样了——假期里冒出来的「拉尔夫·维古姆」（Ralph Wiggum）那套玩法，现在人们已经在 7×24 小时地为编程任务跑推理了。至于我们大多数人日常做的那种知识工作，到 2026 年底能不能走到那一步？我在时间上可能跟你意见不同，但这个判断的方向是对的。

Harry： 为什么不同意？我特别乐意被证明是错的——作为风险投资人，我大多数时候都是错的。时间上你为什么不认同？

Noam： 因为我认为我们仍处在这样一个阶段：从根本上说，还没有合适的用户体验（UX）。很多人还停在「除了搜索和聊天，我不知道拿这东西干嘛」的状态。我仍觉得，人们使用这些工具的许多方式，并没有真的让他们变好，产出也没有超过他们自己动手做的。多数情况下，这不是模型的问题，也不是技术的问题，而是用户体验的问题——我是说：怎么给它注入有效的上下文、怎么正确地提示它、该拿它做什么、该怎么调整自己的工作流去适配它。对于我们做的很多工作，我们仍处在这个阶段。

Harry： 你认为 AI 对财富不平等，更多是伤害还是帮助？

Noam： 天哪。我认为我们一定会经历一段痛苦期。美国的财富不平等是我真正担忧的事——现在比历史上任何时候都高，比镀金时代（Gilded Age）还高，这会带来很多潜在的危险后果。但我不认为答案是限制 AI 这类技术。我仍然站在这一边：它最终会创造更多的富足，这不是零和博弈，它是一项能托起所有船的技术。只是从这里走到那里的路，不会像我们希望的那么平顺。

Harry： 我对 2026 年的另一个预测是：我们将看到对科技行业和科技领袖前所未有的妖魔化。当失业和岗位替代第一次在经济的大片领域真实上演时——比如初级法律岗位、客服、记账——

Noam： 对，这个预测我今年不跟你唱反调，我认为今年确实更有可能看到它发生。

快问快答：Opus 4.5、Anthropic 还是 OpenAI

Harry： 我们来一轮快问快答：我说一句简短的话，你给我最直接的反应。过去 12 个月里，你在哪件事上改变看法最大？

Noam： 是我们离我心目中的通用人工智能（AGI）有多近这件事。具体说，Claude Opus 4.5 让我的判断发生了相当大的变化。Claude Code 在编程和知识工作上能做到的事简直不可思议，Opus 4.5 是一次巨大的飞跃。我觉得我们已经跨过了一条看不见的能力线——它现在的能力、能产出的成果，无论代码还是别的，都已经到位，只是我们还没找到办法，给大多数人包装出合适的用户体验。

Harry： Anthropic 按 3600 亿美元估值、OpenAI 按 5000 亿美元估值，你更愿意买哪家？

Noam： 在这个价位，我会买 Anthropic。

Harry： 你对 2026 年最大的预测是什么？就像我之前说的推理成本、或者科技领袖被妖魔化那类，你的版本是什么？

Noam： 我认为我们会攻克持续学习（continuous learning）和自我改进这一环。这些智能体可以被直接放到一个任务上，给它上下文、让它建立记忆，然后它就会自己变得越来越好——在你交给它的大多数任务上都是如此。这事很可能已经被攻克了，我们现在要面对的只是它带来的影响，以及如何安全地把它落地推广。

Harry： 你在 Meta 最大的收获是什么？我们还没聊过这段，Meta 是个了不起的地方，你最大的收获是什么？

Noam： 先说明，这只适用于我在 Meta 所在的那部分团队——公平起见，我并没有体验过 Meta 的主线业务，我所在的是一个孵化器（incubator）团队，出于正当理由被刻意与组织其他部分隔离开。我最大的体会是关于从零到一（zero to one）的产品开发：这个心得本身并不新鲜，但亲眼如此真切地看到、并理解它背后的所有原因，是另一回事——在规模化的大公司里做从零到一的产品开发，真的非常非常难。Meta 有很多很多强项，但和许多同等规模的公司一样，这从根本上就是一件极难做到的事。

最好的领导、最后悔的事与重新动手的快乐

Harry： 完全理解。回顾你这些年共事过的领导——从 YouTube 到 Google、Meta，再到 Thumbtack——顺便说一句，你不能选沙希尔。你曾在其麾下共事过的最好的领导是谁？为什么？

Noam： 这么问可要得罪其他几位了——你不是在问谁不好，只是让我选一个。这就像你有六个孩子——好吧，五个——你总得说最喜欢哪一个。这就回到我先前说的——什么样的产品领导者才算优秀。

我确实认为，我遇到过最好的公司领导者是格伦·凯尔曼。不仅因为他对市场有极强的同理心和理解力，更因为他能把我们该做什么、为什么重要讲得极其透彻。他有一种本事，能让人愿意为一些看似无足轻重的事赴汤蹈火。我觉得他独一档。

回想在 Plumtree 的日子——那基本就是做企业门户，相当于"企业版我的雅虎"——我们却觉得自己肩负一种近乎救世主的使命。为什么？我们不过是在做企业门户而已。但格伦就能把它讲得意义非凡。所以他会排在我名单的首位。

Harry： 你刚和沙希尔搭档、加入 Grammarly 的第一天——以你今天的认知，有什么是你希望当时能告诉自己的？

Noam： 我觉得我当时推动产品扩张的力度远远不够、也不够快。我早有直觉，也跟人聊过：从根本上说，我们必须拥有自己的界面（surface）——如果想成为一款有留存的产品，你得有一个对用户有意义的、属于自己的目的地。但当时这些只是顺带的闲聊，每次我都被"不行，这风险太大"之类的理由挡回来，理由倒是都很充分。后来我们确实走到了这一步，现在正在经历一轮相当大的产品扩张。但我真希望当时推得更狠一些，让这一切提前一年发生。

Harry： 最后一个问题。展望未来 12 到 24 个月，你个人最期待的是什么？

Noam： 我最期待的是用 AI 去构建东西——我觉得它会改变一切，甚至包括我的工作本身。

Harry： 它会怎样最显著地改变你的工作？

Noam： 最显著的一点：身处我这类职位的人，通常很难挤出时间亲手去做东西，而我入行最根本的原因就是我喜欢做东西。随着职位升迁，你亲手做的东西越来越少，我觉得这是真正的遗憾。AI 会给我重新动手的机会——因为它大幅降低了所需的时间和精力，我不必再在日程里、周末里硬挤出那么大一块空间。我未来动手做的东西会比过去很长一段时间多得多；换作以前，我得指望每周硬挤出一小块时间才能做到。

我希望借此也能推动团队工作方式的改变：我们的节奏、各角色的预期分工和问责方式都要变，好让更多产品经理、更多设计师和团队也能这样工作。因为现在挡在他们面前的最大障碍，我认为不是工具、不是意愿、也不是知识，而是围绕"我们到底怎么工作"的变革管理——一周该怎么安排、谁对什么负责、会议用来干什么，这些都得改。只有改了，才能给大家腾出空间和许可，让他们把一天里的大部分时间用来做一件完全不同的事。