产品经理不是产品的 CEO (Aatish Nayak)

▍嘉宾：阿蒂什·纳亚克（Aatish Nayak）

阿蒂什·纳亚克是 Harvey 的产品负责人（Head of Product），统筹产品愿景、战略、设计、数据分析、市场与支持。他的职业轨迹贯穿三家高增长 AI 独角兽：

• CMU 与早期起点：卡内基梅隆大学（CMU）计算机专业，2016 年在 Uber 实习；毕业时放弃微软、Palantir、Stripe 的录用通知，加入朋友在洛杉矶的创业公司（一年后倒闭），随后在创业公司之间辗转。
• Shield AI 与 Scale AI：在 Shield AI 担任产品负责人，亲历团队从 20 人到 100 人；随后在 Scale AI 四年半，见证公司从 40 人扩张到 800 人，从零组建电商数据标注团队，并参与过 Scale 与 OpenAI 极早期的 RLHF 合作。
• Harvey 时代：加入 Harvey 任产品负责人，这是他效力的第三家高增长 AI 独角兽。

▍关于 Harvey

Harvey 是面向法律行业的 AI 公司，2022 年由温斯顿·温伯格（Winston Weinberg）与加布·佩雷拉（Gabe Pereyra）创立，早期即获 OpenAI 创业基金投资，红杉资本、凯鹏华盈等跟投。

• 核心模式：为大型律所与企业法务提供 AI 生产力套件（问答、起草、文档大规模抽取），并从大型律所招募律师团队与工程师并肩工作，自建法律评测基准 BigLaw Bench。
• 增长与估值：本期录制时（2025 年 4 月）Harvey 刚完成约 30 亿美元估值的一轮融资；随后一年内连续加注——2025 年 12 月估值 80 亿美元，2026 年 2 月再融 2 亿美元、估值达 110 亿美元，年化收入（ARR）于 2025 年中突破 1 亿美元。

开场

Harry： 这里是「20 Product」，我是哈里·斯泰宾斯。「20 Product」是一档月度节目，我们每期邀请一位最顶尖的产品负责人，聊聊他们如何从零起步、扩张并管理最好的产品团队。今天做客的是阿蒂什·纳亚克，硅谷最炙手可热的创业公司之一 Harvey 的产品负责人，他统筹产品愿景、战略、设计、数据分析、市场与支持。

这还是他效力的第三家超高速增长（hypergrowth）的 AI 独角兽——此前他曾在 Scale AI 担任产品负责人，亲历公司从 40 人扩张到 800 人；也曾在 Shield AI 把团队从 20 人带到 100 人。

从工程转产品：为技能集成长而优化

Harry： 你已到达目的地。阿蒂什，我太期待这期了，听到的全是好评。我们刚才还在聊 HubSpot，我事先也和凯蒂聊过。非常感谢你能来。

Aatish： 我也很兴奋能来。今天伦敦天气很好，正适合录这期播客。

Harry： 兄弟，能当面坐下来录，太棒了。我想从头说起。和咱们共同的朋友聊天时我听说，你很早就做了从工程转向产品的决定。我想就从这儿开始：你为什么做这个决定？这个决定又如何影响了你给那些可能面临同样选择的人的建议？

Aatish： 我一直着力优化的一件大事是技能集的成长：你需要掌握哪些技能？我擅长哪些？我还想精进哪些？而不是纠结我的头衔是产品经理（product manager）还是软件工程师。技能集的成长极其重要。我觉得那个年代，人被框进不同角色的程度比现在厉害得多，所以更要盯住技能成长。

我很早就读过萨姆·奥尔特曼（Sam Altman）那篇《如何成功》——那时奥尔特曼还不是今天这个奥尔特曼。其中让我印象最深的一点是：努力工作，专注在你擅长且愿意持续精进的事情上，长期会产生巨大的复利。他在文中说，要力争做到自己所做之事的前 1%。当然不是人人都能做到，但有了这种心态，你就会到那儿。

于是我审视自己：我到底想做什么？我擅长什么？我真正感兴趣的是什么？软件工程嘛，我在卡内基梅隆大学读的是计算机学位，写代码大概算中上水平。但我意识到，我并不真的想在这条路上继续精进。

我真正想精进的是商业嗅觉、领导力、产品感、激励他人、用户洞察这些更传统意义上的产品经理技能。所以我最终加入了 Shield，在那里我可以把自己放进能锻炼这些技能的机会里，不断精进，而不必背负「我是软件工程师还是产品经理」这种头衔压力。

Harry： 太有意思了。这让我想起斯科特·加洛韦（Scott Galloway）。他说：别做你热爱的事。听到这话你会愣一下：什么？大家都是反着教的。不不不——做你擅长的事。

Aatish： 对。

Harry： 然后复利就来了。

Aatish： 对。

Harry： 而且多数时候，你擅长的事，做着做着你就爱上了。因为你擅长它。

Aatish： 对，完全正确。

Harry： 所以我一直认为，父母早期的鼓励太重要了。你告诉孩子他们某件事做得好，他们往往会因此爱上它，投入更多时间，做得越来越好。我觉得这是一个非常重要的起点。

Scale AI 的产品课：贴着前沿客户走

Harry： 我必须得问。Scale 在很多方面都是定义这一代人的公司。刚以 250 亿美元估值完成融资，今年收入要冲到 20 亿美元。太疯狂了，亚历山大·王（Alexandr Wang）干得好。你在那儿待了四年半左右。Scale 的这段经历如何塑造了你对产品的思考？

Aatish： 好，我想谈几点。第一，过去五六年间，Scale 一直站在许多场 AI 浪潮的最前沿。我们做得特别好的一件事，是倾听前沿客户——那些身处我们所开拓领域最前沿的客户。

因为每一次我们都恰好站在新市场的临界点上，和这些客户深度绑定收益巨大：你可以确信，他们基本上就是在定义市场，他们要的东西，其他所有人迟早也会跟着要。早年的自动驾驶就是如此：Nuro（译者注：自动驾驶配送公司）在激光雷达（LiDAR）和大量极难的「行人」标注工作上起步得超级早。

于是我们为 Nuro 做了大量定制，和他们扎得非常深。结果你猜怎么着，其他所有人也开始要同样的东西。我的体会是：只要你身处前沿市场——今天的世界绝对就是这样——就去找那些在自己领域最出色的客户，然后追着他们做，哪怕一度过度贴合（overfit）他们的需求也没关系。只要你有把握，其他人终将跟上。

Harry： 我能追问一下吗？创始人经常被告知：千万别做任何定制，因为那样无法迁移到更大的客户群，你就只是在为一家客户造东西。

Aatish： 嗯。

Harry： 以你的经历，你在多大程度上认同这句话？

Aatish： 嗯。确实有一类「难缠客户」：他们狮子大开口，什么都想要，全是新的定制需求。我觉得这需要极强的纪律性去分辨：他们要的东西里，哪些是你认为极度专属于他们的；哪些是其他人也会想要的。

你必须把这两者剥离开，把这些客户当成倒逼机制（forcing function），用来推动你本来就想推进的方向，同时对那些可能过度定制的需求说不。再举个例子：Scale 很早就和 OpenAI 合作了，远早于 ChatGPT 发布。那还是基于人类反馈的强化学习（RLHF）的极早期，他们想基于 Reddit 段落把模型调成能更好地做摘要。

那是在 GPT-2 上做的，也是我在 Scale 最早参与的项目之一。我们最终做了一个高度定制的产品，专门用来标注 Reddit 段落。当时也许是 OpenAI 领先太多，也许是我们起步太早——但两年后，所有人都开始提出大量类似的需求。

于是当年那套东西又被大量复用，等整个行业都认识到 RLHF 的好处时，我们已经准备好了。所以这件事比一句「不做定制」要微妙得多，你得把它拆开看。

Harry： 好，如果说与客户的极致贴近、真正倾听是第一条，还有别的吗？

Aatish： 有。第二条是：你必须缩短「客户需求」与「写下的代码」之间的距离。什么意思？随着公司变大，客户和写代码的工程师之间会塞进很多层：产品经理、销售、创始人、设计师，一路都是人。

等客户需求最终传到工程师那儿，大量微妙的信息可能已经丢了——因为人与人之间的信息传递损耗极大。你跟我转述一件事，你不可能完整保留客户说的一切：他们的情绪、他们的措辞语气。所以对我们来说，缩短这个距离至关重要。

具体做法就是让工程师直接站到客户面前——无论是 Nuro 这样的客户，还是真正在干活的贡献者、众包标注人员。我们甚至会把工程师空降到世界各地的培训中心，让他们实地观察人们如何使用标注产品和 Scale 的其他产品，然后当场做原型、当场开发。

产品经理不是产品的 CEO

Harry： 恕我直言，既然要弥合客户与工程师之间的鸿沟，那在这样的世界里，产品经理的角色是什么？

Aatish： 好问题。经常有人来问我产品经理的建议。他们说：我在组织里当「胶水」，我要干这个、我们要干那个；从创始人、客户、工程师那儿，我收到一大堆信号。我觉得你该有的自我定位是：你不是胶水，你是 WD-40。（译者注：WD-40 是美国常见的万能润滑除锈剂，此处比喻「润滑剂」角色。）

Harry： 知道，就是那种工业润滑剂吧？

Aatish： 在公司这台引擎里、在一家超高速增长的创业公司里，如果你是胶水，那很糟——因为东西会散架，你会成为单点故障，你的团队也是单点故障。相反，你要确保其他每个人都能发光、把各自擅长的事做好，给滑道抹油，怎么叫都行。

具体意味着什么？比如把工程师推到客户面前——因为客户想和工程师聊，工程师也想和客户聊，这会给他们信心。

Harry： 如果我是个产品经理，现在自认是胶水，听你说完想当 WD-40。我具体该怎么做，才能从胶水变成 WD-40？

Aatish： 我觉得这始于接受一个事实：你不必是全场的主角。我犯过这个错误，也许偶尔还在犯。产品经理有时会有主角综合征（main character syndrome），觉得自己必须是产品的 CEO、必须是产品的门面。

你要问自己的第一件事是：我做的所有事，真的是对公司最好的安排吗？就从这个问题开始。听起来也许很简单、很基础。

其实就是给别人发光的机会，让他们施展自己的技能。然后是前面说的：把设计师、工程师推到客户面前，给他们提出想法的空间，和屋子里所有人一起头脑风暴，再加上大量执行层面的具体动作。但这一切都始于那句话：我不必当主角，我只要让产品和公司成功。

Harry： 太逗了。你提到主角。我在节目里老听到一句话：产品经理就是产品的 CEO。

Aatish： 对。

Harry： 我每次都觉得好笑。

Aatish： 你知道我觉得什么好笑吗？CEO 才是产品的 CEO。

Harry： 没错。说到这个，我请过 Shopify 的首席产品官上过节目。

Aatish： 嗯。

Harry： 他说：我不是 CPO，托比·吕特克（Tobi Lütke）才是。名义上我是，但实际上不是。

Aatish： 嗯。

Harry： 我觉得这太妙了。好，这些就算是我们这一段的要点。

市场是唯一重要的东西

Harry： 如果我们拆解一下，打造一家像 Scale 这样了不起的公司，需要哪些核心要素。你之前跟我说过：市场是唯一重要的东西。作为风险投资人，我日常思考的是市场、团队、增长势头和价格——说实话，我骨子里是欧洲人，恕我直言，美国人在价格上毫无纪律性，一点都没有。

Aatish： 这个话题可以展开聊。确实一点都没有——所以找你们融资才这么有意思。

Harry： 但「市场是唯一重要的东西」这个说法很有意思。为什么？能给我展开讲讲吗？

Aatish： 我觉得，没找到好市场，你会死得很惨，这样的例子到处都是。自动驾驶就是典型：五六七年前，你可以说，天哪，多好的市场，以后人人都有自动驾驶出租车（robo-taxi）坐。但这个市场资金效率极低——前期必须砸进巨额资金，还有一大堆监管障碍。

再看真正跑出来的公司，基本就是特斯拉（Tesla）和 Waymo，它们手握近乎无限的数据和近乎无限的资本。而它们身后是一整片公司坟场——那些倒掉的公司，你不能说创始人不行。恰恰相反，创始人们个个才华横溢，如今不是在搞语言模型，就是去了 Waymo 或特斯拉。

所以我认为关键的一条是：一定要在为时已晚之前，找到一个足够大的市场。

Harry： 你觉得 Scale 的市场算好吗？数据标注（data labeling）这个市场，是个好市场吗？

Aatish： 我认为数据标注——或者说 AI 领域任何类型的数据供给——都是好市场。亚历山大·王（Alexandr Wang，Scale AI CEO）和我们做对的一点是：总能在某个领域的数据需求爆发时，及时转向那个领域。外界一直批评 Scale 只是一家自动驾驶数据标注服务商，而我们做得好的地方在于：最早当然是自动驾驶——准确说，是从 3D 自动驾驶起步的。

然后我们转向 2D 自动驾驶，图像、视频全都做。接着延伸到机器人，比如仓储机器人和其他类型的机器人。再往后又转向政府业务——如果你还记得，2019 年那会儿 Maven 计划（译者注：美国国防部 2017 年启动的 AI 项目）正是热点，国防部（DoD）开始大举加码 AI 投资。所以核心命题始终是：如何不断找到这些对数据和数据标注需求巨大的新市场。

Harry： 从一个领域切换到另一个领域时，产品需求在多大程度上是共通的？作为产品负责人，要在多个截然不同的垂直领域之间灵活转身，难度有多大？

Aatish： 说实话，挺难的。视觉类的 3D 和 2D 业务相对顺畅，因为 Scale 的运营属性很强，你只需要调整运营流程来保证质量——当然，仓储机器人和自动驾驶的质量要求差别也不小。但一旦走出视觉领域，我们就得从零打造全新的产品。

比如我在 Scale 从零组建了电商团队，给 Meta、Instacart、DoorDash 这些客户做电商数据标注。那是一套和核心 2D、3D 业务完全不同的产品。所以确实得不断造新产品。这里得归功于亚历山大的韧劲——他会跟大家拍板：我们必须做，没问题，过程会很折腾，但外面是一个个巨大的市场。

回到市场这个话题，我还要补一句：反过来讲，大市场也会掩盖执行上的问题。Uber 就是例子。当年闹过 #DeleteUber 运动（译者注：2017 年抵制 Uber 的社交媒体运动），公司内部也乱成一团。我 2016 年在 Uber 实习过，很早以前了，亲眼目睹那些乱象特别开眼界。那时正是特拉维斯·卡兰尼克（Travis Kalanick）时代的巅峰期，所有人都在猛冲，后来又出了 Delete Uber 那档子事。

虽然乱，但 Uber 今天还站着，而且盈利了。这当然离不开达拉·科斯罗萨西（Dara Khosrowshahi，Uber CEO）的功劳，但根本原因是那个市场实在太疯狂了——随叫随到的打车服务，谁不想要？一旦大家发现这事可行，需求就彻底挡不住了。所以我确实认为，大市场能掩盖很多问题。

如果分发是国王，产品就是总统

Harry： 你之前说过一句特别棒的话。我非常非常信奉专注做分发（distribution），觉得重视分发的人实在太少了——这也是首次创业者和二次创业者的一大区别。而你说的是：如果分发是国王，产品就是总统。

Aatish： 对。

Harry： 我当时就想：得请这哥们儿上播客。你给我讲讲——如果分发是国王……

Aatish： 嗯。

Harry： 那产品就是总统，这话怎么讲？

Aatish： 我认为，分发可以靠纯粹的蛮力带来大量早期增长。你看那些贵族制、国王和王国：他们靠的是士兵、军队和财富去占领和征服土地——纯粹是蛮力，没多少外交手腕。创业也可以这么干。

你可以做创始人主导式销售（founder-led sales），可以做品牌、做营销，拉起一整支销售团队，确实能冲得很远很远。但问题是：它能带你走很远，却撑不到最后。如果没有实质的东西跟上，人们迟早会发现皇帝没穿衣服——大家会看穿这个假象。

所以你必须用产品跟上。为什么说产品是总统？因为民主制度里的总统是民有、民治、民享的。做产品也一样：你最终要倾听用户，我们许下过的所有承诺，都得确保兑现。而民主制度——但愿如此——往往能延续很久，通常也更稳定、创造更多财富。产品也一样，能延续很久很久。分发能让你飞速抵达目的地。

Harry： 但在 AI 时代，产品还能长久吗？我们眼见着产品和代码库以惊人的速度被商品化——大模型的蒸馏（distillation）几周就能完成，而这些模型原本是最难被直白照抄的东西。产品真的还存在这种持久性和长寿性吗？

Aatish： 这取决于你怎么定义产品、把重点放在哪一层。我不认为基础模型（foundation model）是产品。OpenAI 现在就是这个趋势——他们正在向产品公司转型。萨提亚·纳德拉（Satya Nadella，微软 CEO）也说过：吉卜力工作室（Studio Ghibli）风格的图像之所以能爆火，是因为他们已经有一款装在人人手机里的移动应用——那才叫产品。所以我觉得取决于你在产品的哪个层面下功夫。说到底，尤其对我们而言，更长期的护城河是围绕产品建立起来的用户体验（UX）。

Harry： ChatGPT 某种程度上已经把聊天框塑造成了消费者的默认预期。你觉得聊天是对的产品界面吗？

Aatish： 绝对不是。聊天界面只是这片新疆域的命令行起点，就像当年的 MS-DOS。我的思考有几个层面。第一，聊天是高度线性、一轮一问的：你输入一个东西，得到一个回答。当然，你可以继续追问，但真正的工作不是这样——你要先汇集大量信息，才能产出一份像样的工作成果。

你可能得从一些人手里拿数据，而你甚至不知道他们手里有这些数据或背景。所以我们做产品时遵循一个原则，叫宜家效应（IKEA effect，译者注：用户对自己参与组装的产品估值更高的心理效应）。宜家当年爆红，就是因为它把组装家具这件事做得极其简单、顺手甚至有乐趣，由此建立起品牌好感：「这是我亲手拼的，我为此负责。」

当然，现在人们都花钱请人装了，但宜家效应确实造就了一种近乎邪教般的品牌追随。所以对我们来说，改变聊天式 UX 的思路是：AI 能不能主动索取更多信息？能不能说「嘿，我先写了一版初稿，你先给我反馈，我再往下写」？就像一个真正优秀的同事会做的那样。总之，聊天界面只是非常、非常早期的形态。

我认为，要搞清楚什么才是对的界面，需要我们这些人、Harvey、应用层公司和 OpenAI 一起做大量试验。

超高速增长中最先崩掉的东西

Harry： 我问你一个问题：当分发在手、产品为总统，你就会进入超高速增长，优质客户开始采用你，在某些圈子里形成口碑裂变。这也是我很喜欢垂直软件（vertical software）的原因——那些行业里的品牌效应让口碑传播容易得多。那么，产品团队进入超高速增长后，最先崩掉的是什么？

Aatish： 会崩的东西很多。先定义一下超高速增长：假设你的收入每三到六个月就翻 1.5 到 2 倍，员工数也同步增长 1.5 到 2 倍——可以说每个季度、甚至每半年，公司就变成一家完全不同的公司。

最先崩的几件事里，第一件是：你很难搞清楚到底该优先做什么。按照定义，你会涌来大量客户和大量需求，大家要求的东西五花八门，你不知道该往哪个方向走。工程师、创始人、产品经理，全都一样迷茫。如果没人提供这种清晰度，你就会做大量错误的事情。

第二，通常还会出现两种极端：要么太多人参与决策，要么没几个人拍板。你会遇到大量公地悲剧（tragedy of the commons）式的问题——事情出了岔子，没人知道该谁负责。比如面向销售团队的产品赋能（product enablement），这归谁管？当销售团队和产品团队同步扩张时，很少有人认真想过这个问题。

温斯顿·温伯格现在把这事交给了我，我正在摸索。总之，会崩掉的东西太多，而且往往没有明确的负责人。所以创始人必须提供清晰度：什么重要、优先做什么、为什么在这个时间点做这件事。然后由产品经理和工程团队把这种清晰度转化为行动方案和执行。

向创始人说「不」与开明专制

Harry： 那你会在多大程度上顶回创始人？

Aatish： 我认为向创始人提出异议非常重要，哪怕只是为了辩论本身。当然，要看创始人是谁。对早期的产品负责人来说，和创始人建立非常非常好的关系至关重要——这也许是废话，但你必须问清楚：你为什么招我、你想招我做什么？你究竟希望我干什么？产品型的创始人可能会说：我只要你执行。

战略我懂，你负责执行，确保一切落地。这没问题，你也能从中学到很多。但一定要进行那场对话：这个角色到底定位成什么？我见过一些产品负责人、产品经理处境很糟，就是因为没做这场对话——而创始人又不肯放权，局面就会非常难看。

Harry： Spotify 的首席产品官之前在节目里说过：空谈是廉价的——所以我们更要多谈。但我不认同。坦率说，我信奉独裁，我认为独裁效率高得多。

Aatish： 嗯。

Harry： 在一个速度就是一切的世界里，独裁能带来高效得多、快得多的决策流程。对产品决策的独裁属性，你认同到什么程度？还是说，你觉得头脑风暴和讨论其实很重要？

Aatish： 我信奉开明专制（benevolent dictatorship）。新加坡就是例子，我完全同意。我认为自上而下的清晰愿景和执行力极其重要，否则你最终会陷入公地悲剧。创始人说「我们落后于这个竞争对手，去做 X」「我们需要拿下这类客户，去做 Y」——这种来自创始人的方向感极其有帮助。

但我认为，尤其在超高速增长中，如果不带着团队一起走这段路，你会制造大量混乱，或者细节最终走样、不是你想要的样子。在 Scale 的见闻让我学到很多教训；而在 Harvey，我们肯定也还没做好。

Harry： 那你们做错了什么？

Aatish： 我认为，尤其在 Harvey 早期，我们搞的就是专制。我和温斯顿就是一副「我们要做 X、Y、Z，冲冲冲」的架势。还是那句话，在超高速增长中，你会想当然地以为每个人掌握的信息都和你一样——但事实根本不是这样。他们不在那些对话里，不在投资人会议里，看不到模型六个月后会走到哪一步。于是造成了大量折腾。

团队里看到这段的人估计会点头同意。我认为，解释清楚你为什么做某些事极其重要——哪怕最后你还是得说「请听我的，请相信我」。因为你需要和团队、和公司里的每个人建立相互尊重。如果你招对了人，优秀的人才希望被告知「我们为什么做这件事」。

99% 的情况下，只要你的推理是对的——如果不对，就该拿出来辩论——只要推理站得住，他们就会认同你。但前提是分享上下文、写备忘录、开头脑风暴讨论、欢迎辩论，这些都极其关键。当然，前提是不能拖慢节奏，一件事辩上七个星期可不行。

产品备忘录、原型与 PRD

Harry： 当你动手写这些产品备忘录（product memo）时，流程是什么样的、具体怎么落地？

Aatish： 产品备忘录其实分不同的层级。

Harry： 好，能展开给我讲讲吗？

Aatish： 最顶层是：作为一家公司，我们要聚焦什么？什么才是真正重要的？这不是功能层面的事。我们在 Harvey 有一个框架叫「落地、扩张、锁定」（land, expand, lock in）：我们能建什么、做什么来赢得新客户？我们能做什么来扩大使用、推动增长？第三，我们如何构筑护城河、让客户离不开我们？这是温斯顿·温伯格（Winston Weinberg，Harvey CEO）提出并定义的，位于整个备忘录体系的最顶层。

Harry： 那你们怎么决定——比如说，我们确实需要聚焦「锁定」——又怎么决定具体建什么？运营节奏又该怎么定？

Aatish： 这类备忘录通常由我或工程负责人来写：应该怎么思考决策？我们为什么做这些决策？既有流程层面的元思考——比如要极快推进、快速迭代、快速做原型，以及附着其上的方法论；也有很具体的问题——用户体验应该是什么样？该投入多少清理技术债、多少不投？这是两类不同的备忘录、两种不同的思考方式。但我认为这里面有多个层级，有点分形的味道。

Harry： 说到写作这项能力对产品人的意义——会写作是产品人最重要的能力吗？

Aatish： 我认为最重要的能力是清晰传达你的想法——不管是用文字，还是用幻灯片（很多人爱用幻灯片），还是像如今这样可以很快做出原型来传达想法。我团队里的产品经理就经常随时用 Cursor 或 Claude 做原型来展示想法。所以我认为关键是传达想法：把你为什么想做某件事讲得非常干脆利落，并且传达出去，这一点极其重要。

Harry： 在一个原型制作无缝衔接的世界里，任何有点本事的人都能很快搭出原型，不再需要在设计阶段磨很久——我们会因此失去设计环节吗？

Aatish： 简短回答：不会。我不认为你会失去设计职能或者设计师。恰恰相反，你会得到更好的设计，因为原型能做得快得多，尤其有了 AI。我一直说：原型要走在产品需求文档（PRD）前面。不管是工程师、设计师还是产品经理，只要你有想法，就应该先做原型，因为在真正动手之前，你不会知道产品该怎么建、确切的用户体验该是什么样。

尤其还是那句，有了 AI，我们可以先确立一些新范式——自己玩一玩，让内部客户玩一玩——然后再走正式的 PRD 和设计流程，写正式的 PRD、做正式的设计。

但因为你已经做完了这些前置工作和原型验证，你实际上能省下大量来回折腾，最终推进得更快，得到更好的结果。

Harry： 什么样的 PRD 才算牛逼？

Aatish： 好问题。我把 PRD 看作对齐文档。它不是规定某件事必须怎么做的圣经，而是一份对齐和启动文档。我认为一份真正好的 PRD 要解释你为什么做这些事——动机是什么，最好有数据、客户原话或某种证据，说明我们为什么这样做。

它还应该包含一段稻草人用户旅程（抛砖引玉的初稿）：用户一步步应该怎么操作、整个流程怎么走，最好覆盖不同角色。另一个极其重要的点是：把最尖锐、争议最大的问题全部列出来。好的产品经理应该有一种「看到拐角后面」的直觉：工程团队会说什么？这件事为什么复杂？

客户会对这个小功能说什么？你要把房间里所有的大象（译者注：英语谚语，指显而易见却被集体回避的问题）和所有争议都写在 PRD 末尾，这样开启动会时你就能非常早地开始建立对齐。还要往前看——这也靠在组织里不断练习——当你真正开始开发、开始发布时，会有哪些坑？会有哪些陷阱？在 PRD 结尾把这些明确点出来，非常非常关键。

Harry： 我想尽可能细地钻进你们今天的流程。假设我现在写好了一份 PRD——别笑，我就是个干风险投资的——接下来我干什么？是提交给你吗？然后我们开会讨论？谁来参加？具体怎么运作？

Aatish： 先说一个通用原则——这其实来自我在 Scale 的很多经验——你要避免「功能工厂」（feature factory）。想象一个工厂、一条传送带：客户提了个需求，产品经理写 PRD，设计师画设计稿，设计稿交给工程师，工程师再交给测试，测试交回给产品经理……

然后产品经理再去找赋能团队，再到销售。这是一条高度线性的流程，而这就是做出烂产品的方式，也是让全队士气崩塌的方式——没人愿意只被钉死在自己的那一小段里。所以写完 PRD 之后最重要的事，是把所有会参与其中的人聚到一个房间里——哪怕只是会碰一下这个产品的人——一起讨论、一起辩论。

这就是为什么前面说的「问题清单」如此重要：你要问，我哪里错了？你担心什么？什么会出问题？什么会让用户惊喜？我们怎么把它做得令人惊喜？我们每周都有一小时左右的 PRD 评审、工程设计文档（ERD）评审，任何人都可以带任何文档来，我们当场辩论。

在场的是每一个会碰到这个产品、或会被咨询到的人。这件事绝不应该是产品经理躲在后屋关起门来定个一二三、然后甩给工程团队。把所有人压缩到一起，极其重要。

新功能与技术债的取舍

Harry： 全新功能和技术债之间，你的优先级排序框架是什么？我采访过微软的首席技术官，他说今天乃至未来最让他兴奋的 AI 应用，就是用 AI 来基本铲平技术债。你怎么看这个平衡：一边是新功能带来的收入、产品或使用量上行空间，另一边是减少技术债？

Aatish： 你可以想象，工程候选人老问我这个问题，因为他们想知道产品负责人怎么看代码清理。先说个好消息……代码库能有多脏？真有多少债？如果你在高速增长，东西就是会坏，工程师只能接受这一点。

重要的是，如果某个东西坏了、出了问题，或者因为你要重构某块东西导致它比应有的慢，就必须为此做事后复盘（postmortem）：我们本可以做什么来避免它？如果答案是「哦，我们本可以在两个冲刺之前花一周，先做清理再做这件事」……

那就很好，因为这样你就有了技术债影响收入、影响客户结果的证据。你要把这些证据攒起来——否则，如果没有证据，只是泛泛地说「技术债」，说实话，清理技术债这件事可以永远干下去。所以我认为，找出「如果当初清理了某处、后面的问题本可以避免」的具体例子，极其重要。

当你说「我们要因为 X、Y、Z 做技术债」时，你必须把结果说得非常、非常清楚：是补齐一批测试？还是花两周重构某个模块？你要像对待任何功能一样给它限定时间，否则工程师会乐意永远清理代码下去——能清的东西永远多得多。

Harry： 工程师是不是比起写新代码，其实更爱清理代码？

Aatish： 我的看法是：在创业公司里，工程师确实更愿意清理代码，而不是写全新的东西。

Harry： 哇哦。

复盘会、事后复盘与事前验尸

Harry： 说到事后复盘，我想问一下：你们每周有固定的复盘时间吗？比如周一下午五点做事后复盘？还是临时安排？具体什么样？

Aatish： 这要分复盘会（retro）和事后复盘两种。

Harry： 复盘会和事后复盘分别是什么？

Aatish： 复盘会是回顾某一段时间：我们哪里做得好、哪里做得不好。复盘会通常更规律，比如每月一次：月底大家坐下来，这个月完成了什么？哪些本可以做得更好？下个月该做什么？事后复盘则是在出了事故、出了问题，或者我们做错了决策的时候。

你要评估的是那个具体的决策或事件。比如应用宕机了若干分钟，你就要确保做一次事后复盘：为什么会发生？怎么解决的？本可以如何预防？所以事后复盘更偏临时触发。我们最近开始做得更多的——这也是我在 Harvey 当产品负责人在学的东西——是事前验尸会（pre-mortem，事前推演失败）。

事前验尸会是在启动大项目、大行动之前，和团队坐下来问：成功长什么样？什么会阻止我们达成？什么会出问题？把你们的担忧全说出来。我在工作时本来就是个非常焦虑、偏执的人，默认一切都会出错，所以这对我可能有点自我治疗的效果——「伙计们，我觉得这事会发生，它会发生……」

「……它会出错的。」但我们做过几次之后，我觉得它确实缓解焦虑，也确实帮助对齐，让大家不再对「成功是什么」感到困惑。而且很多时候，被指认出来的风险恰恰就是真正出问题的那个——就像迈克·泰森（Mike Tyson）说的那种脸上挨一拳的事（译者注：泰森名言「人人都有计划，直到脸上挨了一拳」），你永远预料不到。那句原话到底是什么，我肯定要因为引错被人骂了。

Harry： 但你们真正预测中问题所在的频率有多高？对比那些完全没预料到的？

Aatish： 实际上，被点过名的问题往往就是最后出问题的地方。如果你说「我们测试推进得不够快」，然后又不指定一个负责人去盯「让测试更快」这件事，那它就会失败——因为根本没人在想这件事。我不认为会有太多完全不可想象的意外。当然也有「未知的未知」，比如 COVID 这种。

Harry： 嗯。

Aatish： 或者客户就是不喜欢这个功能，又或者突然出了个新模型，把我们所有计划都打翻。这种情况时有发生。

用户测试的同心圆与 Vault 的教训

Harry： 接着事后复盘说：一个新产品或新功能到底是不行、还是只是需要时间渗透进客户的使用习惯和采用度——你们多快能分辨？

Aatish： 这是我经常思考的问题，尤其考虑到我们的用户群：律所不喜欢快速行动或反复改动——至少是那些行政和 IT 团队不喜欢。所以我们可能发布了一个产品，几个月都不会正式发布（GA）给百分之百的用户，因为大家就是在慢慢采用。我认为要根据客户群的不同，给它足够的时间去沉淀。

理想的做法——也是我们的做法——是把用户测试按同心圆式扩散（concentric circles）一圈圈放大。我们做出新东西的第一站，是内部一大批担任不同角色的律师：交给他们测试、收反馈、迭代。然后是外部一批固定的设计共创伙伴（design partner），覆盖大多数功能：交给他们。

他们有参与感，这很好，也会给反馈。再往外是更大的 beta 测试客户名单：交给他们、继续迭代。最后才是整个大众市场。我想这对大多数产品、大多数企业级团队都适用：你要确保用这种不断扩大的圈层，高频地做测试。

Harry： 你在用户测试上犯过最大的错误是什么？或者你看到别人犯的最大错误是什么？

Aatish： 其中之一是诱导用户往你希望的方向去想。举个例子最清楚。去年六月前后我们做了一款叫 Vault 的产品，核心能力是对文档做大规模信息抽取：比如你有一批租约、信贷协议，想从每份里抽出 10、20、50 个交易要点，它会为你生成一整张表格。

我们当时的做法是：你上传一批文件，说「我要这 10 项」，Harvey 会拆解你的初始指令，给出建议「这是那 10 项，我理解对了吗？」你逐项打勾确认，然后启动。演示效果极佳——它接住你的指令、转换、展示出来。我们给人演示时，所有人都惊呼「天哪，太神了」。

但我们并没有真正把它交到用户手里跑真实案件、真实场景。我们只是演示，大家惊呼「好酷，它在理解我的意图」。我们做错的地方在于：用户其实只想在表格里直接建那些字段——「面对这一万份协议，我就要这一项，我在表格里自己建就行」——不想让 AI 替他们转换。

他们希望对每个字段的含义做精细定制，而不是让 AI 去猜全部 10 个字段。你有时会陷进自己的思维定式，进而带偏用户。你没有把它交给用户跑真实场景，最后就掉进了这类陷阱。

最大的产品错误：该用哪个模式，别问用户

Harry： 你犯过最大的产品错误是什么？你从中学到了什么？

Aatish： 有几个。挑一个说，就是我刚讲的 Vault 做信息抽取那个。还有一个也是在 Harvey，因为就发生在最近。去年第四季度，我们在改造核心的助手产品，在助手里引入了两个模式：一个是辅助模式（assist），做问答和分析……

另一个是起草模式（draft），帮你起草合同、条款、邮件——律师日常要写的那些东西。当时的想法是给律师一些选择权：「我现在要干什么？」然后为这项任务挑对的用户界面和模型，因为这两个模式背后是两套不同的模型和界面。再说一次，这就是用户测试的「乐趣」：这个改动我们没怎么做用户测试，本该多测一些……

我们当时只想快速推进、尽快上线。做好、发布、推出去之后，几乎所有人都完全搞不清什么时候该用哪个——不知道什么时候用辅助、什么时候用起草。也许是律师这个群体的特点，也许是别的原因，反正他们就是不知道「我在写应诉答辩的时候，该用起草还是辅助？」几乎人人都有这个抱怨。

然后我们开始靠赋能团队来解决：告诉大家这个模型适合什么、那套交互适合什么，这种场景应该这样做。部分抱怨平息了，但多半是因为大家抱怨累了。当然，后来他们真正用起来之后发现：起草模式的输出更「法律腔」，跟辅助模式确实不一样。

但这个例子说明：正确的用户体验应该是 AI 直接替你做选择。AI 应该自己判断用户的查询和意图，或者通过追问来更好地理解，然后把你路由到最适合这项任务的系统，而不是让用户自己琢磨该用哪个。

让用户选模型是个陷阱

Harry： 我觉得让用户自己选模型这件事很荒唐。每次我用 Anthropic 的产品都想说：什么鬼？而且那些模型名字起得莫名其妙。

Aatish： 是啊。

Harry： 我压根分不清它们谁是谁。Grok 也是这么干的。我就觉得，这太离谱了。但以后不会这样了。五年之内，用户不会再有模型可选。对吧？

Aatish： 对，没错。

Harry： 再说，给用户选择真的是好事吗？想想选择悖论——选择太多用户反而犯晕。依我看，人就是懒，直接告诉他们用哪个就行。

Aatish： 平均来看，人确实是懒的，需要你直接告诉他们什么最好。模型选择这套东西——再说一次，我们自己也掉进过这个坑。我认为这整个范式是为硅谷、为科技圈受众设计的，因为大家都喜欢拿 o1 和 GPT-4o 这些模型来回对比着玩。我们当时——其实到现在——都没真正搞清楚每个模型擅长什么，所以也就谈不上按任务路由。

这些模型最大的问题是——我们也有这个问题——能力边界只能靠评测（evals）来框定。你并不确切知道哪个模型更适合哪项任务。有时纯靠用户偏好。我们做了大量并排对比测试，有时结果还是不够清晰。所以我认为整个行业都掉进了这个坑：把所有东西塞进一个下拉菜单，给用户一堆选择。

评测与 BigLaw Bench：公开基准为什么没用

Harry： 你们的评测和公开基准测试（benchmark）上的评测有多大程度重合？我最近请了 Glean 的总裁兼首席产品官塔玛·耶霍舒亚（Tamar Yehoshua）上节目。

Aatish： 嗯。

Harry： 她说他们的内部评测和公开基准评测的结果非常不一样。你们的评测是和公开基准相关，还是大相径庭？

Aatish： 很不一样。很多公开的法律基准，甚至像 Scale 的「人类最后的考试」（Humanity's Last Exam）这类，全是选择题。我倒是希望法律工作是选择题，但任何律师都会告诉你，实际工作中可选项有一百万种。所以第一，选择题不是正确的评测方式。于是我们做了一个叫 BigLaw Bench 的基准。

它由真实的可计费工作任务组成，都是我们最大的客户、那些大型律所（Big Law）里的律师每天在做的事。这些任务的共同特点是高度开放。开放式任务的难点在于：如何跨任务一致地评估？

比如你说「Harvey，生成一份事件时间线（chronology）」，这和「帮我起草一份即决判决动议」完全不同——后者是另一类诉讼任务。所以我们必须为每类任务制定评分细则（rubric），而且非常具体。我们现在有几百种不同的任务，每个任务都有自己的评分细则。

我们的一个优势是——这也是从一开始就设计好的架构——我们从大型律所招了很多律师，让他们和 AI 团队、工程和产品团队坐在一起，告诉他们：真实的法律工作是这样运转的。因为我不是律师，我是做 AI 出身的，往往不知道「好」长什么样。

为一个你不知道「好」是什么的东西做产品管理，有时候真的很难。所以依赖这种领域专长非常重要。

Harry： 另外，你们目前的主力模型是 OpenAI，对吧？这有变化吗？

Aatish： 他们从最开始就是我们的投资方，我们很早就能提前拿到 OpenAI 的模型，也和他们共建了一些定制方案。大体上还是这样。但我们现在看到 Claude 等其他模型在某些任务上能力更强，所以我们在探索。

Harry： 我能问下，Claude 在哪些地方比 OpenAI 强？

Aatish： 我们最近做过一轮评测。特别是 Claude 3.7，在法律推理方面，它更擅长长篇法律推理和长文本起草。比如写并购协议（merger agreement）的一整个章节，并保持高度一致，它做得非常好。还有信息抽取类任务，比如从股权购买协议（SPA）里抽取条款，非常讲究细节，因为答案往往不是协议里的原文。

这里有点钻到法律细节里了。比如你要从股权购买协议里找赔偿上限，得跨四五个条款去推理，因为这个上限在交易里不是一个直接写出来的数字。你得理清协议里四个条款之间的依赖关系，才能把它抽出来。在这类抽取任务上，Claude 3.7 开始做得更好了。

OpenAI 和其他竞争对手每发布一个模型，我们从 Harvey 成立第一天起都会做基准测试。Claude 3.7 是我们第一次看到有模型在部分表现上超过 OpenAI。

模型公司必须成为产品公司

Harry： 你觉得三到五年后，模型市场的价值和用量分布会是什么样？

Aatish： 我觉得模型公司必须更多地转型成产品公司。

Harry： 你不觉得它们已经是了吗？你看 OpenAI——这是它自己有意选择的路线。它现在明显是一家消费产品公司，收入 129 亿美元，这点很清楚。

Aatish： 嗯。

Harry： 但 Anthropic 离它该有的程度还差得远，真见鬼。

Aatish： 是的。

Harry： 它很明确选择了开发者优先、API 公司的路线。

Aatish： 是的。但我认为更多实验室应该开始想清楚：你要交付的产品到底是什么。云厂商会跑最好的软件，把利润率压到地板。长期来看，靠推理（inference）和云厂商竞争非常难。如果你的收入全部来自推理和开发者，这不是个理想的位置。你真正想做的是打造产品——也许是和 Harvey 这样的应用层公司合作，端到端地交付你的产品。

Cursor 与 Codeium：AI 编程工具有锁定吗

Harry： 你们在做的是硅谷眼下最火的 AI 产品之一，我很想听听你的看法。Cursor 是当红炸子鸡，还有 Codeium（Windsurf 母公司）。Cursor 的锁定效应有多强？这两家在你心里怎么比？

Aatish： 我觉得用户体验极其重要。我听到一些工程师说，比起 Windsurf，他们更喜欢 Cursor 的智能体模式（agent mode）；也有人说反过来更好。所以问题是：什么样的体验最让人愉悦？当然，体验也许能抄，但我认为事情更微妙。然后是数据和治理，尤其在企业场景。模型的好坏取决于你喂给它的上下文。

这些产品里，谁能真正接入企业关于其代码、产品、架构的知识，并用这些知识把工程师产出的结果调校得更有用。我知道 Codeium 在获取企业数据、理解企业现有代码库上投入很大，确保知识架构做得足够好。

Harry： 作为用户，你更喜欢哪个？

Aatish： 我现在做原型其实用 Codeium，因为我不想折腾 Windsurf 或 Cursor 那些很细的设置，所以最后用 Codeium。然后我还在用 Replit 的智能体模式，因为 Replit 帮你搞定部署。我不想碰部署、前端、后端服务器那一堆东西。

它的界面也做得很好。你可以给它一个任务，比如「给我做一个法律聊天机器人应用」，它会说「这是我的计划，这些是我认为有用的附加功能」，你勾勾勾选完，它就开始搭建。你能看着它一步步搭，当然也能看代码、改代码。

所以，就我的使用场景来说，Replit 的智能体模式、Lovable、Bolt 这类工具比那些 IDE 更有吸引力。

Harry： 你们团队更喜欢 Codeium 还是 Cursor？

Aatish： 据我所知他们更喜欢 Cursor，最新的情况是这样。我觉得主要是因为我们还没采购 Windsurf，而且 Cursor 的开发者品牌更强。

Harry： 确实。

Aatish： 确实。硅谷这地方，人人都互相聊天。Cursor 那边很多人是我们团队成员的好朋友和人脉，所以他们自然偏向 Cursor。但还是那句话，时间会给出答案。

AI 时代产品管理的未来：想法与领域专家升值

Harry： 快问快答之前最后一个问题。AI 改变了产品领导和产品管理角色的太多东西。站在你今天的领导岗位上，关于产品的未来，有什么是我们还不知道、但你一直在思考的？

Aatish： 在一个原型设计和想法落地执行都便宜得多的世界里，想法本身会重要得多。如何融入独特的知识——比如领域专长——也会更重要。

也许未来是律师、医生、领域专家来驱动更多的产品决策，因为你需要弥合模型和用户体验与某个职业实际应用之间的鸿沟。在这类想法上，领域专家的作用会比现在大得多。我们已经尝到了内部配律师的甜头——他们真的就坐在工程师旁边。

人类才是 AGI 的瓶颈

Harry： 最后一个问题，关于 AGI 的未来。不过你刚才有些说法很有意思，快问快答里我必须追问一下。你说人类是 AGI 的瓶颈，为什么？

Aatish： 对。硅谷每个人都觉得 AGI 会自然而然发生：GDP 大涨，人人从此幸福生活，全民基本收入（UBI），诸如此类。但我认为现实中，AI 的大规模落地会撞上文化、法律和监管层面的壁垒。逐条拆开说：假设真的实现了 AGI，它能做非常高级的任务——为并购提供咨询、以董事会成员身份提供建议，甚至当 CEO。

那么，治理一个正在运营公司的 AGI，该用什么治理框架？现在没人知道答案，而这需要时间。我一直站在法律的角度追问这个问题，因为我确实经常向我们的合作伙伴和客户请教：到底会发生什么？

每个人的反应都是：我们需要某种对责任的认定——一旦 AI 自主地在世界上采取行动，会发生什么、谁来负责。文化层面则是：在哪些最后的领域，人类真的愿意让 AI 介入？

举个例子，在硅谷，我和我很多朋友真的会跟 Claude 或 ChatGPT 做类似心理咨询的倾诉——「我在想这个问题，真的好难。」

Harry： 你真这么干？

Aatish： 对，没错。我家乡的朋友听到也是你这个反应。

Harry： 那是因为我是欧洲人，我们更擅长跟真人聊天，不像你们这些硅谷野兽那么交易化。所以你连情绪话题也跟它们聊？

Aatish： 对。

Harry： 它们的回答质量好吗？

Aatish： Claude 不错。ChatGPT 不行，没那么有共情力。

Harry： 这很有意思。

Aatish： 其实 Grok 也可以，Grok 给出的建议相当好。

Harry： 我也许试试。

Aatish： 你真该试试。还有一点：我认为每个人都应该有一个 AI 心理咨询师，这事迟早会发生。最近还真有一项研究：研究者让一批参与者跟一个基于 OpenAI 之类技术的机器人对话、寻求建议。

大概有 60% 到 70% 的人报告说，这样做了四五个月之后，情绪状态更好、更快乐，而对照组主要是跟真人交流。原因在于，人们不想被其他人评判——哪怕你的心理咨询师处在一个安全的空间里也一样。

Harry： 对，我觉得你跟大语言模型说话时，敞开心扉的意愿大概会强得多。最后一个问题：为什么智能体对人类的需要，超过人类对智能体的需要？

Aatish： 生成式 AI 有个很有意思的问题：被创造出来的产品、服务或工作成果，消费者是谁、生产者又是谁？举几个例子：建筑领域，是客户对建筑师（出设计的人）；内容领域，是营销人员对品牌方；法律领域，是客户对律师。那你最终采用什么模式？

是让生产者的产出放大 10 倍、让他们更高效，还是直接面向消费者？很多人以为可以直接面向消费者——「给你一堆线索」或者「给你一堆法律文书」之类。但归根结底，人类并不总是信任 AI，他们信任的是使用 AI 的其他人类。

我认为——当然要看具体领域——更可能的正确答案是：智能体与工作成果的生产者合作，共同为消费者交付。总不会真有人认为我们会取消律所、让消费者直接享受直连式法律服务吧？

Harry： 这根本算不上个想法，就像说「我们要取消会计师，因为 AI 会帮你记账」一样。

Aatish： 不然。你会惊讶的，真有不少人持这种观点。

Harry： 哇。

Aatish： 都是些不懂技术的人。

Harry： 营销领域也一样。也许是非常非常低端的需求可以：我需要一份一居室公寓的租约，地址在这儿，一页纸，搞定。你懂我意思吧？

Aatish： 懂，懂。还有一点：订机票这种事，当然可以交给智能体，很简单；点个晚餐也行。但如果是复杂得多的事——建筑图纸、法律工作、税务工作——智能体需要大量人类提供的上下文才能真正完成，无论这些上下文来自消费者还是生产者。

所以它得问你一大堆问题，尤其是那些企业里更复杂的知识工作。人们就是有一种想当然的假设：智能体会自动把一切做完，黑箱运行也没问题。但人们不信任黑箱。有些独属于人类的元素——上下文、情绪——你必须考虑进去。所以我思考的不只是订机票那类智能体。

我想的更多是能做非常复杂工作的智能体。

快问快答

Harry： 兄弟，我想跟你来个快问快答，因为我能跟你聊一整天。

Aatish： 好啊。

Harry： 你持有的最有争议、很多人不同意的观点是什么？

Aatish： 嗯，我的观点是：我认为应该撤销美国教育部（Department of Education）。

Harry： 这事好像正在发生，对吧？

Aatish： 呃，在英国可不是。

Harry： 对，英国没有。英国有的是文化部和体育部。什么鬼？

Aatish： 对对。

Harry： 简直离谱。

Aatish： 对。我其实有一份清单，里面有些观点我都不知道能不能说出口。

Harry： 等等，你有一份自己争议观点的清单？

Aatish： 有啊。

Harry： 哇。

Aatish： 嗯。

Harry： 记在备忘录里那种？

Aatish： 对对，记在备忘录里。你要是有空，我可以当场翻出来。

Harry： 好啊，我太好奇了，这太酷了，我从来没听说过有人这么干。

Aatish： 因为我一有观点就记下来——我大脑的回忆能力不太好，什么都得写下来。

Harry： 我不这么干。我的做法是床头放纸笔，因为躺在床上时经常冒出点子，就随手涂下来。或者把想法写在邮件主题行里发给我的执行助理（EA），凌晨两点那种：「新节目，这样这样这样。」就这样。

Aatish： 对，我有一个能讲的，还有一个就不在录音里说了。

Harry： 好。那最能讲的那个争议观点是什么？

Aatish： 人们普遍欢迎稳定，但我认为，要真正快乐、真正充实，你需要拥抱混乱、拥抱不稳定，因为那会让生活有趣得多。人们总想着「我要安定下来，舒舒服服退休」。你可以这么过。

但在通往那里的路上，你应该主动拥抱冲突，主动拥抱不适——这样无论生活扔给你什么，你都会越来越有韧性。

Harry： 你拥抱过的最让你不舒服的事是什么？

Aatish： 我人生不同阶段有那么几件。大学时候，我主动修了卡内基梅隆大学最难的课程之一——操作系统，要从零开始造一个操作系统（译者注：原文此处音频含糊）。

那门课我不是非修不可，不修也能拿学位。我只是听说了各种疯狂的传闻，什么连着熬两个通宵赶作业之类的。我就想：干就完了，为什么不呢？

还有一件：大学毕业时，和很多 CMU 毕业生一样，我拿到了微软、Palantir、Stripe 这些大公司的录用通知。我决定都不去，搬到洛杉矶，加入了朋友的公司——结果一年就倒了。

但那是条少有人走的路，而且除了那时候，我还能什么时候去洛杉矶生活呢？所以我就这么干了，之后在创业公司之间辗转，而不是去大公司。

Harry： 对今天即将进入 AI 职场新世界的毕业生，你最大的建议是什么？

Aatish： 这回到我开头说的：专注于你想学的技能组合。我到现在还常遇到工程师说「我想当产品经理」。但如果你是个工程师，你最有价值的东西之一就是写代码的能力。我真希望自己当年把编码坚持得更久一点。至少要坚持下去，这点非常重要——现在有了氛围编程（vibe coding），这条路好走多了。

然后，别怕多尝试。人们总觉得必须在二十出头就把一切想明白，根本不是这么回事，尤其在 AI 时代。你 22 岁的时候，不知道什么东西到你 26 岁时会变得值钱。所以多试、多实验，看看自己喜欢什么、不喜欢什么。

Harry： Harvey 的代码里有多少是 AI 写的？

Aatish： 好问题。其实没那么多，大概 20%。

Harry： 20%。这在今天算正常水平吗？

Aatish： 我猜算。我觉得我们其实还可以用得更多。

Harry： 你们可以怎样用现在还没用到的 AI？

Aatish： 单元测试（unit testing）这一块，我认为可以用 AI 自动化得多。工程师个人已经在一定程度上用 AI 写自己的单元测试了，但整个单元测试层就应该全部交给 AI。

Harry： 在你的岗位上，你最想做、但因为决策或资源所限做不了的事是什么？

Aatish： 上播客。开个玩笑，我已经在上了。认真说，我想做的是：Harvey 有两条线，一条是今天这个生产力套件，是我们的核心产品；另一条是和律所、企业协作做大量端到端工作的 Harvey，就是那种企业愿意花数百万美元去买的工作。

我很想直接去啃那块，但那条路还很长，需要做研究、做用户体验实验。我们迟早会走到那一步，但现在必须聚焦在生产力套件上——律师用的那个软件，而不是端到端干活的 Harvey。

Harry： 我有个观点：在伦敦建 AI 公司比在旧金山容易。所有人听了都「哇哇哇」。我的理由是：我们有顶尖机构和大学输送的 AI 人才供给，但关键是，我们没有那么高的人才流失。从外面看，旧金山 AI 圈的人才流失有那么惨烈吗？

Aatish： 你说的流失是指员工跳槽？

Harry： 就是人被别的当红公司挖走——OpenAI 甩 200 万美元挖你最好的工程师，或者 Codeium、Windsurf 之类。

Aatish： 对，没错，流失非常真实。所谓的人才「争夺战」，我认为非常真实。而且不只是 AI 行业——全世界最顶尖的高管就住在湾区那一条狭长的半岛上。

尤其当你是成长期公司，需要引入有经验的人、有经验的高管，他们全都集中在那儿，拖家带口，只想留在那儿。当然，你可以在其他地方找到很多早期人才。但你在那儿获得的思想碰撞和经验积累，我认为无可替代。

Harry： 你觉得现在对顶尖人才来说，最热的公司是哪家？

Aatish： OpenAI 和 Anthropic。六个月前我大概只会说 OpenAI，但我觉得 Anthropic 现在开始吸引越来越多的人了。

Harry： 好。最后一个问题：最近 12 个月里，除了 Harvey，哪家公司的产品策略最让你印象深刻？

Aatish： 当然有。我本来在下面还备了一个答案……对我来说其实是 Canva。我觉得 Canva 在模板这件事上做得非常聪明，而且打开了一种类似市场（marketplace）的动态——说白了，你可以借用、叠加、嫁接任何人的创意点子，方式特别酷。对，它真正解决了冷启动问题（cold start problem）。

Harry： 嗯。

Aatish： 另外我得说，Perplexity 是真的强。我非常尊重那个团队和他们推进的速度。当然你可以说他们现在摊子铺得大，但我认为，他们聚焦于核心体验——把给出答案这件事做得飞快、其他一切让路——这一点无人能及。这是一个产品为王的案例。

当然，他们有分发渠道之类的优势，但人们采用它不是因为渠道，而是因为产品实在太好了。而且我觉得他们现在开始聚焦某些垂直领域——购物、旅行、金融——这些领域需要大量互联网知识。我认为这个策略非常聪明。

Harry： 作为 Perplexity 的投资人，听到这个我很高兴。我觉得阿拉文德·斯里尼瓦斯（Aravind Srinivas）非常了不起。说真的，这期我录得太开心了。非常感谢你包容我们时间安排上的一点点跑偏，你表现得太棒了。

Aatish： 谢谢，很高兴这期内容有用。

结语

Harry： 天啊，这期节目我太享受了。如果你也喜欢，欢迎留下评论或点个赞——这对节目的被发现度影响巨大，真的非常感谢。

一如既往，非常感谢大家的支持。下周一请锁定我们与 Benchmark 合伙人维克多·拉萨特（Victor Lazarte）的精彩对谈。