Legora 的技术栈内幕 (Jacob Lauritzen)
Legora CTO Jacob Lauritzen 拆解这家 18 个月做到 1 亿美元 ARR 的法律 AI 公司的技术栈与工程组织：AI 代码生成占比、开发者体验团队、token maxing 为何失效，以及用 vibe coding 自建内部工具的实践。
本文译自The Twenty Minute VC (20VC) YouTube 频道，发布于 2026 年 6 月 6 日；主持人哈里·斯特宾斯 (Harry Stebbings)，对话 Legora 联合创始人兼 CTO 雅各布·劳里岑 (Jacob Lauritzen)。
劳里岑拆开了一家“提交量榜首是 AI”的公司：瓶颈如何从写代码迁到评审与产品工作，为什么每个 PR 仍要人工过目，token maxing 为什么是“蠢到家”的考核方式。他给工程师职业开的药方是往上走一层，给 PM 开的药方却是别去碰工程——两个方向相反的判断，背后是同一条约束理论。至于那场与主持人定下的年底营收对赌，开牌时间在 2027 年初。
▍嘉宾：雅各布·劳里岑 (Jacob Lauritzen)
雅各布·劳里岑是 Legora 的联合创始人兼 CTO，常驻斯德哥尔摩。Legora 是他工作过的第一家“大公司”——他带着一张白纸进场搭工程组织，恰好赶上 AI 工具重塑软件开发的窗口期。
- 管理风格：本期节目中他罕见坦率——公开承认“工程师上限 20 人”的误判（实际已 80 人）、面对比自己资深的候选人时自我怀疑导致招错人的教训，以及“两周内给出最强反馈”的纠正机制。
- 组织观：不设 ego 的文化，他告诉自己的两位工程总监“如果你哪天比我做得更好，我们就换位置”；工程团队按 6 人小队编组，配 PM 与技术型工程经理，各自像小创业公司一样自定 roadmap。
▍关于 Legora
Legora（前身 Leya，YC W24 批次）2023 年创立于斯德哥尔摩，是协作式法律 AI 平台，客户覆盖 White & Case、Linklaters、Dentons 等顶级律所，被视为史上增长最快的企业级公司之一。
- 增长与估值：18 个月做到 1 亿美元 ARR；2026 年 4 月官宣约 5.5 亿至 6 亿美元 D 轮融资，估值约 56 亿美元（Accel 领投，英伟达 NVentures 与 Atlassian 跟投），累计融资约 8.7 亿美元，全公司约 400 人。
- 扩张方式：2026 年内已完成 5 笔收购，用“整组买人”补招聘速度；品牌上以裘德·洛 (Jude Law) 主演的全球 campaign「Law just got more attractive」破圈。
引言
Harry： 今天我非常激动地欢迎 Legora 的 CTO 雅各布·劳里岑（Jacob Lauritzen）来到节目。Legora 是史上增长最快的企业级公司，仅用 18 个月就做到了 1 亿美元的年度经常性收入（ARR）。Jacob 是我请上过节目的最出色的产品人之一，尤其是最近这一波 AI 浪潮里涌现出的那批产品领袖。
Harry： Jake，兄弟，我为这期节目太激动了。我觉得 Max（Max Junestrand，Legora 联合创始人兼 CEO）是那种……你知道吗，我觉得能干成这种事的人都得有点“疯子”特质。（笑）他估计已经在骂“去你的 Harry”了。但他真的出类拔萃，我知道他对人才的标准有多高，所以我知道这期节目一定会非常精彩。首先，太感谢你来上节目了。
Jacob： 当然，谢谢邀请。
2026 年搭工程组织：一张白纸反而是优势
Harry： 刚才我们聊到，你说 Legora 是你工作过的第一家大公司，或者说是第一家这种规模的公司。我在想，这到底是好事还是坏事？你怎么看？
Jacob： 我愿意相信这是好事，只是我得对此保持非常谦卑。（笑）说到底，在“怎么搭工程组织”这件事上，我没有任何先入为主的成见。而 2026 年搭工程组织，和 2024 年比都已经大不一样了。所以从这个意义上讲，我带着一张白纸进场反而是好事：就按这个思路试，不行就继续迭代——就像我们迭代产品一样，我们也在不断迭代组织和流程。我就是和团队一起打磨：什么做得好、什么做得不好、怎么解决，这和解决任何其他问题是同一个套路。
Harry： 2026 年搭团队、做产品，和 2024 年及更早相比，到底有什么不同？
Jacob： 现在一切都在不停地变。生产率涨上了天，流程都还悬在半空。团队可以很大，也可以很小。
Harry： 生产率涨上了天。
Jacob： 对。
Harry： 拆开讲讲，为什么涨上了天？
Jacob： 就是 AI 工具。
写代码不再是瓶颈：瓶颈迁移到评审与产品工作
Harry： 你们内部具体用什么？
Jacob： Claude Code，还有 Cursor。
Harry： 这两家可是在直接竞争。哇——我每次访谈，人人都说要逃离 Cursor。所以你们现在还有 Cursor 用户？
Jacob： 还有人在用 Cursor。Cursor 的 harness（智能体外壳）做得相当不错。我们团队里各有各的偏好，但很多人仍然在用 Cursor。有些人用 Claude Code，有些人用 Pi——因为 Claude Code 的 harness 有时候挺烦人的。我们允许大家混着用。
Harness（智能体外壳）指包裹在大模型之外、让模型真正能“干活”的那层脚手架：工具调用、文件读写权限、上下文管理、循环控制与错误恢复。同一批底层模型，配上不同的 harness，产出差距可能非常大——这也是 Claude Code、Cursor、Pi 等工具真正的竞争层面：大家调的是同一批模型，拼的是外壳的工程细节。当 Jacob 抱怨“Claude Code 的 harness 有时候挺烦人”时，他吐槽的不是模型能力，而是这层脚手架的交互设计。
效率的提升就体现在这里：我们交付得更多、更快，调试更快，迭代更快，一切都更快了。每个工程师的产出都比以前高得多。这对整个组织的结构方式产生了大量连锁反应。
我喜欢这样想这件事：做软件大体有三个阶段。第一阶段是产品工作——我们到底要做什么？把用户的痛点、梦想和噩梦，翻译成看得见摸得着的东西，拿去试、去迭代、去验证它是否成立。然后，一旦你知道要做什么了，第二阶段就是把它做出来：写代码、评审、合并、上线。过去将近一百年里，第二阶段一直是主要瓶颈——速度限制器就是“你写代码能有多快”。
Harry： 嗯。
Jacob： 现在写代码这件事变得极其便宜，这个环节被压缩掉了。瓶颈挪到了另外两头：一头是评审（review）——我们怎么把它做得高效得多？另一头是产品环节——我们怎么把产品工作做得高效得多？因为只要你相信写代码变便宜了，另外两头自然就成了瓶颈。这就意味着，我们的一个重点课题是：如何把产品工作的效率做到极致。
Harry： 那你具体是怎么想的？
Jacob： 问得好。其中一部分是：怎么让我们的产品经理（PM）尽可能高效？怎么把他们与客户的沟通、对客户想法的提炼、我们自己的战略优先级、我们自己对产品走向的品味和判断，全部高效地整合起来，再尽可能高效地交到工程师手里？我不敢说我已经解决了这个问题。但我的思考方式就是这样：时刻追问“我们交付速度的瓶颈在哪里”，然后去解决它。
Harry： 你刚才提到，评审是可能成为瓶颈的环节之一。AI 代码评审会不会成为主流的评审方式，从而把这个瓶颈消除掉？
Jacob： 我觉得会，这是解决方案之一。我们今天已经在用 AI 代码评审了，不过它还处在萌芽阶段。（笑）该怎么说呢——
Harry： 就像我小时候胖的时候，我妈总说我是“骨架大”。
Jacob： 行吧。
Jacob： （笑）Harry，明明是你把麦提莎（Maltesers）全吃光了。
Harry： “还在萌芽阶段”——这措辞可真够温柔的。
Jacob： 是，这是比较体面的说法，毛边还多着呢。不过你说得完全对，解决方案的一部分就在这里：我们有 AI 评审机器人，可以做安全评审，可以有各种不同专长的评审器。它们做大量的评审，还跟写代码的 AI 来回交锋。你会看到一种挺诡异的模式：智能体之间互相“打架”，直到收敛出一个结果。
但即便如此，我认为现在的评审工具还是不够好，我们需要新东西。我在各种活动上逢人就说：如果你要创业，求求你做一个解决评审问题的产品。没有人想逐行去看那些代码。真正重要的是：这次改动对系统架构有什么影响？对系统设计的稳定性、安全边界有什么影响？它有没有把我们的系统往正确的方向推？这才是你想评审的东西。如果这些都没变，那也许你根本不用评审，直接放飞智能体就行。但如果变了，如果涉及战略层面的取舍，你就需要一个人来判断：没错，这是该走的方向。
工程师的未来：系统设计、“元工程”与护栏机制
Harry： 那工程师的未来，是不是就是做系统设计、系统架构，而代码编写、代码维护——说白了——完全由 AI 搞定？
Jacob： 我觉得是。工程师的工作正在从“敲一大堆代码”变成往上走一层：这个系统应该长什么样？AI 可以在系统的每个模块里跑来跑去，而工程师要思考更高一层的抽象：系统长什么样？我们在哪些地方下了什么注？某个地方值不值得投入，做一个能在很多地方复用、让一切都更稳定的东西？这是其一。
其二，工程师越来越多在做的另一件事——很快会在我们这儿成为一个明确岗位——是一种“元工程”：让智能体真正高效运转。就像你会设开发者体验（developer experience）团队，帮你写定制的 lint 规则、定制开发环境，让开发者更高效。
我们也需要为智能体配一个同样的团队：怎么让智能体发挥最大效力？怎么让智能体能独立地自我改进系统？我们能不能用足够好的方式采集数据，然后直接放飞智能体，对它说：“去，把我电商店的转化率提上去”，它就能自己跑实验？把这个闭环搭好，让智能体自己跑、自己优化——我认为这会是很多工程师未来的真正工作。
Harry： 你觉得我们怎么做到？我跟 Jason Amin 和 Anne Midher 聊过很多，Anne 特别厉害。他们俩都跟我说过同一个观点：本质上，在一个由智能体来挑选软件的世界里，API 质量就是智能体选择软件的核心决定因素。你怎么看“让智能体更高效”这件事？它就是个简单的数据问题、只要我们做到数据最强就行，还是你另有看法？
Jacob： 我们必须把护栏（guardrails）架设得非常有效。这其实是我眼下正在琢磨的事。我们的代码库开始变大了（笑）——这是好事，是幸福的烦恼。我们的工程师开始变多，一起在代码库上干活的智能体也开始变多。于是你开始想：我怎么用机制化的方式，强制系统按某种方式运转？
举个例子：你可以设定制规则——智能体想做某个操作，我们告诉它：“不行，你不能这么做。不管出于什么原因，我们希望系统保持这个样子。”我认为这类护栏设置会无处不在。如果你是一家大企业，正在铺开 AI 工具，让智能体去搭你们的内部软件——用 AI 工具去搭你们的 HRIS（人力资源信息系统）、ATS（招聘管理系统）等等——那你多半会有一些工程师专门负责设定规则：数据从这里取、这个可以做、那个不能做，然后你就可以让智能体在这个系统里放开跑。
过半代码出自 AI：安全焦虑与事故复盘自动化
Harry： 你刚才提到 Legora 代码库的扩张。今天产生的代码里，百分之多少是 AI 写的，多少是人写的？
Jacob： 我前阵子正好看过：提交量榜首是 Claude 和 Cursor，它们俩之间大概只差 2%，咬得非常紧。再往下，比第二名的人类工程师高出一大截——它们俩远超 50%。
“提交量榜首是 Claude 和 Cursor，它们俩之间大概只差 2%，咬得非常紧。再往下，比第二名的人类工程师高出一大截——它们俩远超 50%。” "It's Claude and Cursor on the top, and there's like 2% between them... and then it's miles above the next engineer, so they're way above 50%."
▍点拨：当代码仓库的贡献榜第一、第二名都是 AI 工具，“工程团队产出”的度量口径本身就被改写了。这意味着管理动作必须围绕“人机混合团队”重新设计：评审流程要默认面对的是 AI 写的代码，招聘要看“驾驭智能体的能力”，而绩效评估如果还在数代码行数，奖励的其实是 prompt 的勤奋程度。Legora 没有掩饰这个数字，反而把它当作组织设计的起点——这是它比大多数“悄悄用 AI”的公司领先半个身位的地方。
Harry： 你担不担心我们会迎来下一代安全威胁——这么多 AI 生成的代码，会不会稀里糊涂地打开一些我们根本不知道自己有的漏洞？
Jacob： 绝对担心。这是我的头等大事之一。这也是为什么在 Legora——可能很多其他企业软件公司也一样——我们仍然对每一个 PR 都保留人工评审，一个都不漏，因为我们必须确定无疑。我觉得这效率很低，我想引入风险评分之类的机制来改变现状，好让我们跑得更快。但根本上你说得对：威胁行为者（threat actors）现在效率高得吓人，他们可以尝试无数种手法、持续不断地攻。所以我们需要同样强的防御，而我不确定我们已经有了。
Harry： 我反正觉得肯定还没有，不然也不会有这么多黑客事件了。（笑）所以每次我在 Twitter 上看到谁又被黑了，我就想：唉，可怜的工程师，这个周末彻底泡汤了。
Jacob： 是是是。我自己就碰上——哦不是我，是我们的一家供应商，昨天刚出了安全事件，我们轮换了一大批密钥。说清楚，这是我们内部的事，完全不影响任何客户。但我觉得这类事只会越来越多。
“提交量榜首是 AI”的另一面值得冷看：代码库正以史无前例的速度膨胀，而每一行 AI 生成的代码，都是未来某个凌晨需要人类去理解的维护债。更棘手的是攻守的不对称——威胁行为者用 AI 可以无限次、零成本地尝试，防御方却必须对每个 PR 保持“确定无疑”，错一次就出局。Jacob 想用“风险评分”替代人工全审，本质上是拿概率换速度；但在客户数据即身家性命的法律行业，一次误判的赔率是公司存亡。这场交换的定价，恐怕比账面上贵得多。
Harry： 完全理解。刚才聊 AI 带来的效率提升时，我打断过你。你说第二点是流程的变化。流程具体怎么变？PR 也好，事故复盘（postmortem）也好。
Jacob： 事故复盘就是个绝佳的例子，我们现在把它跑得极其高效。现在如果出了事故，你直接放出一个 SRE（站点可靠性工程）智能体、一个事故智能体，它会飞快地搞清楚状况：翻遍所有日志、所有指标、所有遥测数据。它好得出人意料，是真的非常好。以前得让一群工程师半夜爬起来，现在虽然还是得有人半夜起来，但他们装备精良得多。而且复盘报告基本自己就能写出来。这是我们能把效率跑到极致的好例子。
再放大到整个 AI 时代的软件开发生命周期：PM 现在可以超快地做原型，这太棒了，因为这意味着你可以把大量工作前置。一个 PM 脑子里刚冒出一点点“我们是不是该做这个”的念头，他就可以提前很久动手：做个原型，直接拿给用户测，自己迭代。在东西还没被证明“明显超级有价值”之前，根本不用惊动工程团队。到那时候我们再切换过来：好，现在把这个原型改造成真正融进系统、超级可靠的东西。
原型前置、设计存废与“品味”之争
Harry： 既然做原型、做到 V1 变得这么容易，我们是不是直接把设计阶段跳过了？
Jacob： 有些公司大概会跳过设计阶段。我认为在功能层面，我们确实可以跳过：没必要再找十个人开很长的会，讨论按钮该放哪儿。但我确实认为设计仍然有它的位置，只是它比具体功能、具体要做的那些小东西高了一层：是我们选择的设计语言，是品味，是我们对“我们是谁”所持的鲜明主张——Legora 应该长什么样？导航是什么样？层级是什么样？它更多是为了 UX/UI 的一致性和品味，而不是为了功能。
Harry： 完全理解。你们今天还在用 Figma 吗？
Jacob： 还在用。对，我知道你想说什么。（笑）只要你做的系统稍微大一点，你就想要一致性，想要一套设计语言之类的东西。你就需要有个地方存“我们的按钮长什么样、页面长什么样、这是什么、那是什么”。对我们来说这个地方就是 Figma，它干得挺好。至于它能不能——
Harry： 你觉得以后还会是这样吗？我对 Figma 没有任何不敬，但说白了，这不就是个存储功能吗？
Jacob： 没错，完全正确。它完全可以是别的东西。你说得对。
Harry： 那问题就变成：设计师把一个原型在 Figma 里打磨得足够精致，和直接做原型，哪个更快？我们刚才提到了那个美妙的词——眼下最时髦的那个词——品味（taste）。哦不不不，品味是把我们和别人区分开的东西。你怎么看“品味将成为护城河”这个说法？这是真知灼见，还是直白点说，就是硅谷那帮人用来自我保护的科技圈屁话？（笑）
Jacob： 呃——我觉得品味很重要。品味有不同的风味。（笑）双关语，故意的。这取决于你怎么定义品味。我觉得在科技圈，品味就是“我们对某件事持有鲜明的立场”。如果你没有品味，你就会任由 AI 泔水（AI slop）收敛成一片灰色，所有东西长得都一样，全都差不多。你需要有品味，才能对世界持有一个观点、一个立场：这就是我们，这就是我们做的东西，那些别的东西我们不做，我们也不伺候所有人。对我来说这就是品味的含义：我就是我，我们就是我们，你们有些人会讨厌它，没关系。因为你总得有点棱角。你要是放任 AI 撒开了跑，你做出来的东西就会和其他所有人一模一样。
“如果你没有品味，你就会任由 AI 泔水（AI slop）收敛成一片灰色，所有东西长得都一样。” "If you don't have taste, then you let AI slop converge to sort of grayness and everything looks the same."
▍点拨：大模型的输出本质上是训练分布的均值回归——你给 AI 完全自由，它还给你的就是“所有网站的平均长相”。所以 Jacob 把品味定义为“持有鲜明立场”：我们是谁、不做什么、不伺候谁。这不是审美洁癖，而是定位问题：当生成成本趋零，供给无限泛滥，唯一稀缺的反而是“敢于不一样”。注意这与巴菲特部落的“差异化定价权”是同构的——同质化的尽头是价格战，而棱角才是溢价的来源。
抄袭成本趋零：90% 很快，剩下 90% 很难
Harry： 现在抄袭的成本比任何时候都低、速度比任何时候都快，这改变了你对产品的思考吗？你身处一个竞争极度激烈的赛道，别人可以非常快地抄你。这改变你的想法吗？
Jacob： 没怎么改变。对我们来说，重要的是我们在做客户能真正获得巨大价值的东西，我们尽全力快做，但也不追求比这更快。现在有无数人在 vibe coding（凭感觉编程）：有人在 vibe coding 一个 Legora，有人在 vibe coding Salesforce、DocuSign 和其他公司。做到“看起来一模一样”的 90% 是很快的，80% 的情况下功能也差不多能用。难的是剩下那 90%：确保所有边缘情况都能用、所有不愉快的路径、所有审计日志、所有 RBAC（基于角色的访问控制）、所有规模上去之后才会撞见的诡异场景。难的在这儿。所以我们就是继续专注：怎么为客户创造最大的价值，然后以人类能做到的最快速度朝那个方向冲刺。
从巴菲特部落的视角看，vibe coding 把“做出 90% 的形似”打成免费，恰恰抬高了剩下那 90% 的相对价值：边缘情况、审计日志、RBAC、规模化之后才会撞见的诡异场景——这些是数年生产环境磨合沉淀下来的隐性知识，构成企业软件最扎实的转换成本。每个“三天 vibe code 一个 Legora 平替”的复制品，其实都在为在位者的壁垒做免费广告：企业客户真正付费购买的，从来不是功能列表，而是“不愉快的路径也被妥善处理”的确定性。供给端越通缩，可信交付越稀缺——这是 AI 时代护城河少有的变宽而非变窄的环节。
我女朋友是名律师，她特别好，但律师这个群体在采用和使用新东西上真的不是最快的。我说这话要倒大霉了。我不是说她，我是说律师整个行业。
Harry： 你们做产品的速度，已经远远快过客户消化它的速度了。
Jacob： 是的。
Harry： 这个你怎么看？
Jacob： 问得好。我们内部有个说法：这里有三种速度——AI 的速度、我们产品的速度、人类的速度。（笑）它们不一定同步。说实话，我觉得这正是我们在做的事情的美妙之处：我们把 AI 惊人的发展速度，翻译给一个历史上一直被服务不足的用户群体，带着他们一起上路。有时确实会沮丧，但也特别有成就感——我们真的能带着这么庞大的一个人群，切实改变他们的工作方式、效率和生产力，把他们从成堆的烂工作里解放出来，让他们专注在更战略、更重要的事情上。
Harry： 有什么是你没做、但希望自己做了的？
Jacob： 做个邮件客户端应该会很酷，我很想做。我纯为好玩 vibe code 过一个。我们离真正动手做它还有一段距离，因为有其他更高优先级的事。但邮件客户端确实是律师待的地方——
Vibe Coding 自建内部工具：浅应用自己造，深系统不要碰
Harry： 你们在 Legora 内部会做 vibe coding 吗？给客户演示用的、各种用途的？
Jacob： 一直在做。
Harry： 这是企业的未来，还是说直白点，这只是 Legora 站在创新最前沿才有的玩法？
Jacob： 它会成为未来。我不知道什么时候，但它会的。我觉得——
Harry： 我们先把这事说具体：什么意思？是你们给司力达（Slaughter and May）建个网站好去 pitch 他们，给高伟绅（Clifford Chance）建一个好去 pitch 他们？
Jacob： 不是，比这宽得多。我们现在内部有个团队叫内部赋能（internal enablement），做的事情就是：用今天手里所有的工具，从第一性原理重新想象——如果你要打造一家从 200 人扩张到 1000 人的最高效的公司，它应该长什么样？这显然包括给每个人配 Claude Cowork（团队协作版）之类的工具，但也包括：我们能不能自己动手做一大批需要的工具？我们能不能 vibe code 出我们的 HR 系统、招聘系统、薪酬系统？市面上确实都有现成的工具，但你永远得深度定制，而且它们基本从来都不好使。我们现在干脆自己做了，因为做的成本太低了。
Harry： 你们已经把什么东西 vibe code 掉了？
Jacob： 我想想。我们主要做的……嗯，准确说是基于 vibe coding 新增了不少东西。举个特别蠢但特别好的例子：Ryan 是从加拿大过来的，我们有一整个团队从加拿大搬来瑞典，他 vibe code 了一个帮大家搬家落户的 App。特别具体：如果你是加拿大人，这里有哪些法律流程、要办哪些手续；它是交互式的，你能看到自己办到哪一步了，特别棒。做这个大概就花了一天，却给整个团队省了海量时间。所以你看，大系统可以做，但这些小东西全部加起来也很可观。
对了，前两天我跟一个上市公司 CEO 朋友吃饭，他说他的幕僚长请了三周假，基本上 vibe code 出了一个 Kooper，然后他们就把 Kooper 换掉了。而且能用，还特别出色。
Harry： 有人会说：“这也太扯了。HR 系统明明可以直接买现成的，你为什么还要花好几个月去 vibe code 一个？”你怎么回应？
Jacob： 真的要看具体系统。我觉得基本上可以这么分：系统有两个轴，横轴是你的产品表面积有多大，纵轴是它有多复杂。如果一个系统很“深”——表面上看起来挺简单，是个简单的 App，但它做了大量复杂的事，把大量复杂度对用户隐藏了起来；另一种是很“浅”的 App——能做的事一大堆，但没多少复杂度。如果是个浅 App，又需要你做大量定制，那也许你就该自己做，这多半才是正确的选择。如果是个很深的系统，那你要做的东西实在太多，自己做不现实。我大致就是这么判断的。
“幕僚长三周 vibe code 掉一个 Kooper”的故事很诱人，但反向看：买 SaaS 你买的不只是功能，还有持续的合规更新、安全补丁、审计认证，以及“出问题时有个可以问责的供应商”。自建 HR 与薪酬系统，意味着工资数据、个人隐私（在欧洲还有 GDPR 合规）的保管责任全部内化；而写出系统的那个人离职之后，谁来维护？“做的成本太低”只算了诞生成本，没算持有成本——内部工具的持有成本通常以十年计。Jacob 的“深浅两轴”框架本身是对的，但它成立有个隐藏前提：组织愿意为不断累积的“长尾系统墓地”持续缴纳维护税。大多数公司在第三年就会开始后悔。
PM 的未来：能做工程，不等于该做工程
Harry： 我们之前聊到了 PM，聊到他们与客户的贴近，以及把信息传回工程团队的那个机制——这一直是 PM 的本职和强项。未来几年，PM 这个角色会变吗？
Jacob： 会，也不会。（笑）很多人说产品和工程正在融合，正在变成一件事：一个人既做产品工作，又能把系统做出来、交付出去，全都包了。对某些公司来说这是对的。但对真正需要 PM 的公司来说，这不对——或者说可以成立，但效率很低。我告诉你为什么。
我们说过的流程是：先做产品工作、做范围界定，然后做开发，然后交付、评审。在 Legora 这样的公司，我们永远盯着瓶颈，而瓶颈已经不是写代码了，瓶颈是产品工作。所以你不会想让你做产品的人去做工程。
因为那件事的机会成本太高了。你真正想让他们做的是产品工作：和客户聊、做调研、做综合提炼——这才是瓶颈。如果你的 PM 花大量时间写代码，比如 50% 的时间在写代码，我们得损失多少产品工作啊。
这就是我目前的想法。对某些公司——比如做开发者工具的、做消费级产品的——工程师天生就是自己的用户、自己就有很好的体感，那你可能压根不需要 PM。但那种公司在 AI 出现之前本来也不需要 PM，所以这一点并没有因为 AI 而改变。AI 改变的是：PM 现在也能做工程了。但能做不等于划算，这是个机会成本问题。还有交接成本（handover cost）：如果我把产品工作全做完了，写个 PRD（产品需求文档）甩给工程师，中间是有效率损耗的。所以 PM 做一定量的 vibe coding 是好的——做出高保真的东西：“这是原型，它就该长这样”——这样交接成本就低了。
“瓶颈已经不是写代码了，瓶颈是产品工作。所以你不会想让你做产品的人去做工程——因为那件事的机会成本太高了。” "The bottleneck is no longer coding, which means the bottleneck is the product work. And so you don't want your product people to do engineering, because the opportunity cost of that is really high."
▍点拨：这是本期与“全栈一人公司”叙事最锋利的一次对撞。当所有人都在说“产品和工程正在融合”，Jacob 用约束理论（Theory of Constraints）给出了反命题：资源永远应该向瓶颈环节倾斜，瓶颈在产品工作，就不该让最懂客户的人去写代码。“能做”与“该做”是两回事——能力通缩的时代，机会成本反而成了最硬的通货。PM 用 vibe coding 降低交接成本是对的，但那是为了压缩损耗，不是为了转岗。
Harry： 没错，完全对。
Jacob： 但他们不该把大量时间花在工程上。如果他们一头扎进真正的工程实现里，我们在产品工作上就亏大了。
Harry： 假如我是你弟弟，大学 CS 专业刚毕业，你会给我什么建议，让我在未来 3 到 10 年里站在最好的位置？打个类比：如果要我给一个做社交媒体营销的人提建议，我会说：你得做全栈——图要会做、内容要发得出去、还要会放大传播。
Jacob： 类似。我觉得对工程师来说，最重要的是学会“如何学习”。你得搞清楚怎么不断重塑自己、持续学习、持续精进，因为现在一切都在不停地变。每周都有新东西出现——新的你该做的事、新的你该改变的工作方式。你能为自己做的最重要的事，就是搞清楚怎么让自己始终站在正在发生的事情的最前沿。如果你能做到这点，如果你适应能力够强、野心够大，剩下的自然会水到渠成——因为你只要学得比别人都快，时间拉长，你就赢。
模型策略：十个模型分工、性能优先与开源高光时刻
Harry： Legora 作为一个产品，它的质量在多大程度上取决于底层模型的质量？
Jacob： 比大多数人以为的要小得多。Legora 的价值里，模型之外的东西多得多：有那些真正贴合法律场景、让跟 AI 协作更高效的原语（primitives），有那一整套企业级功能，还有模型之间的最优路由。没有模型我们当然不存在，每次模型变好，我们的产品、我们的智能体也会跟着变好。但这么说吧：就算你从 Legora 里抽走一个模型，人们还是会选 Legora。
Harry： 所以他们不是冲着模型买的。完全理解。你们的模型使用方式随时间发生了什么变化？
Jacob： 变化很大。最好的模型几乎每周都在换。我们在 OpenAI 和 Anthropic 之间来回切换过，也一直在评估所有不同的模型。
Harry： 你们会同时用大概 15 个模型、分别干不同的活吗？
Jacob： 没有 15 个，但大概有 10 个。
Harry： 嗯。
Jacob： 对。对每个任务，我们会评估哪个模型最合适：延迟、性能——成本反而不是重点。总有一天成本会成为重点，但眼下最重要的是延迟和性能。性能必须守在这条线上，然后我们看：在性能不掉的前提下，延迟还能放多少。把智能体和其他 AI 功能搭成“可以拆解问题”的结构，你就能用得非常高效。
Harry： 因为你可以选延迟或性能：最快的那个，输出不一定最好；慢一点的那个，输出可能炸裂般好。你只能二选一。
Jacob： 对。几乎永远选性能。性能更重要，几乎永远如此。如果你是律师，输出更好，你多等两秒完全没问题。输出更好，你多等一小时大概都行。
Harry： 纯粹出于好奇：随着行业越来越关注成本，你怎么看开源的未来？
Jacob： 我觉得开源正在经历一个高光时刻，真的是。现在有那么多优秀的开源模型，而且跑起来特别容易，有很多很棒的推理服务商让你能非常高效地跑。我们正在非常接近“在设备端跑模型”这件事：转写已经可以跑在设备端，可以跑在我的 iPhone 上，我的 Mac 上有本地转写。坐飞机没 Wi-Fi 的时候，我有本地模型在跑，可以继续写代码——就是一个通义千问（Qwen）模型在那儿跑、帮我写代码。所以我认为开源会扮演巨大的角色。我希望它按现在这个样子继续演进。而且出于主权原因、出于安全原因，我们本来就应该拥有优秀的开源模型。
Harry： 能说说你今天在担心什么吗？很多人担心中国的开源模型——我刚才也在想这个。放大一点：看着我们聊的这整个格局，什么让你担忧？
Jacob： 我真心希望能看到欧洲和美国的开源模型，这块一直是缺位的，如果能补上就太好了。从博弈论的角度看，如果模型形成双头垄断或者一家独大，结局不会好——原因显而易见。你希望有竞争，希望——
Harry： 欧洲今天在模型竞赛里还有位置吗？
Jacob： 应该有，但现在还没有。
Harry： 训练的效率前沿，你觉得我们走到哪了？是才走了 1%，还是已经走了 90%、只能再挤出来一点点？
Jacob： 问得好。一个问题是：现在的架构还能走多远？它会不会触顶？我们是不是需要新东西？前两天刚发布了一个亚二次方复杂度（sub-quadratic）的模型，支持超长上下文，这特别让人兴奋。不过我还不敢信它的基准测试成绩，得先验证。架构层面的创新还在继续。说不定，现在这套大模型架构并不是能把我们一路带到底的那个。
标准 Transformer 的自注意力机制，计算量随上下文长度呈平方级增长（O(n²)）：上下文翻倍，计算开销变成四倍——这就是“长上下文又贵又慢”的数学根源。所谓亚二次方（sub-quadratic）架构，是把复杂度压到 O(n log n) 甚至接近线性的技术路线，代表方向包括线性注意力、状态空间模型（如 Mamba）以及各种混合架构。一旦成熟，百万级 token 的整卷文档分析（恰恰是法律 AI 的核心场景）成本将数量级下降。Jacob“不敢信基准测试成绩”的谨慎也很典型：新架构发布时往往精心挑选评测子集，真实负载下的表现才是试金石。
五年后的新岗位与 FDE 的“教育学费”
Harry： 有什么今天还不存在的岗位，你觉得 5 年后会非常普遍？
Jacob： 我觉得是企业内部的“AI 系统岗”。它会迎来绽放的时刻：从过去那种帮你装电脑的内部 IT，变成一个帮你搭建海量内部工具、让你的工作轻松得多的辅助团队。如果企业不设立这个角色，我会很生气，因为这里面的效率提升空间太大了——真正深入企业，把这一切都给他们做出来。
Harry： 要在企业里用起来，你们必须配前沿部署工程师（FDE）吗？你们打交道的可是相当“粘”的律师群体。你们必须得派人手把手教他们“来，这样用”吗？
Jacob： 目前是，是的。但这只是个教育问题。说实话，5 年后可能完全不需要了。这是站在前沿要付的学费：你必须教育市场、必须搭把手。这也是人们愿意跟我们合作的原因——我们带着他们一起上路。
前沿部署工程师（Forward Deployed Engineer，FDE）这一岗位由 Palantir 开创：把工程师直接派驻到客户现场，深入理解客户的业务流程，用自家平台快速搭建贴合现场的解决方案。它兼具销售、咨询与产品开发三重属性，是把“平台能力”翻译成“客户工作方式”的转换层。对采用迟缓的传统行业（法律、政府、医疗），FDE 几乎是必需品——Jacob 称之为“站在前沿要付的学费”。值得注意的是，2026 年这一模式正在 AI 行业复兴：OpenAI、Anthropic 等前沿实验室都在组建自己的部署团队，Sierra 更是把 FDE 写进了核心交付机制。
招聘复盘：从“20 人上限”的误判说起
Harry： 准备好回答一个不太公平的问题了吗？
Jacob： 来吧。
Harry： 从产品或者工程的角度看，Harvey 有哪件事做得比你们好？
Jacob： 我知道答案。他们在招聘上更激进。而我觉得我的招聘一直不够激进——我一直想保持一个特别小、特别精干的团队，我曾经对此深信不疑。
但我一直低估了我们需要多少人。大概一年半前，我画过一页幻灯片给全公司看：300 斯巴达勇士大战波斯大军，Legora 就是那 300 勇士。我说——我很确定我说的是——我们的工程师上限就 20 个人。（笑）结果差得不是一星半点。
Harry： 你们今天有多少工程师？
Jacob： 今天大概 80 个。
Jacob 自嘲的“20 人上限”幻灯片，只是 Legora 增长持续击穿预测的缩影。对照公开信息：2026 年 4 月，Legora ARR 突破 1 亿美元、客户超过 1000 家，并官宣约 5.5 亿至 6 亿美元 D 轮融资，估值约 56 亿美元（Accel 领投，英伟达 NVentures 与 Atlassian 跟投），累计融资约 8.7 亿美元（TechCrunch）；全公司员工已达约 400 人，2026 年内已完成 5 笔收购（7 月底的 Wexler 是第 5 笔）。Jacob 在本期押注“2027 年底 270 名工程师”——相当于每周净增 2.5 人。以 Legora 过去两年“每次都低估”的记录看，这个数字大概率还会被再次击穿；而 Harry 押的年底 2.72 亿美元营收对赌，要到 2027 年初才能开牌。
Harry： 你当时可在 Twitter 上把话放出去了，错得离谱吧？
Jacob： 错得离谱。而且我们现在还是太小，太小了。
Harry： 因为太小了，所以你们是动作变慢了，还是做不出想做的东西？
Jacob： 后者。有一大堆功能，其实只要配上一个团队就能做。
Harry： 你们能在保证质量的前提下，以需要的速度扩张吗？
Jacob： 能，这点我们其实特别强。首先，我们招聘极其挑剔——可能这也是我们招聘慢的原因。（笑）我们招进来的人都非常优秀，上手速度快得惊人。
开发者体验团队：被低估的杠杆
Harry： 你们怎么把上手做得这么快？越具体越好，有什么具体做法吗？
Jacob： 我可以告诉你我们大概应该做什么。（笑）现实是，一切都变化得太快，你必须有——我们有一个开发者体验团队，成立得相当晚。对，又是我犯的一个错，我应该更早把这个团队配起来。他们现在把每个人的工作体验做得太好了。
他们做什么？确保本地开发环境特别好用：速度超快，一键就能拉起来。我们自己有一个后台编码智能体，是他们做的，能让每个工程师同时跑 10 个智能体，配齐本地开发环境、浏览器、所有迭代要用的东西。他们在做定制的评审智能体，还在做这样的功能：智能体在 CI 里等着，等一切全绿、所有评审都通过，再把它提交给人看。这里的效率提升是巨大的。他们还会做帮助新人上手的工具：你只要保证仓库里有写得很好的 README 文件，新工程师直接问他的 Claude Code 或 Cursor 就行了。这有效得出奇。所以哪怕是上手这件事，AI 工具也让它变快了。
Harry： 开发者体验团队现在几个人？你觉得你本应该什么时候把它建起来？
Jacob： 现在 3 个人，太少了。我本应该……Opus 4.5 发布的时候就该建。不对，那之前就该建。因为假设每个工程师的生产率翻了 10 倍，那你能让每个人再提效 20%，乘出来的收益就更大了。
欧洲招人、股权教育与 Token Maxing 之争
Harry： 在欧洲招工程师和在美国招，有什么不同？
Jacob： 有几个不同。在美国，人们普遍没那么厌恶风险，很多事情他们都愿意跳上来试。在欧洲，人们更厌恶风险一些。我现在是在高度概括啊——欧洲人整体上更……我不想用“使命驱动”或“忠诚”这种词，但他们是真的会全身心认同自己效力的公司。所以你得花很长时间去说服他们，可一旦被说服了，他们是真的会留下来。这点特别好。（笑）
Harry： 美国这边就更偏交易型。
Jacob： 我觉得是。
Harry： 你发现大家对待期权股权的态度也不一样吗？
Jacob： 这其实是我们在瑞典、在欧洲不得不专门给大家“上课”的一件事。人们就是不熟悉风险投资这套玩法，不知道怎么给股权估值。你得真的去讲：它是这么运作的，它意味着什么，如果发生了这种情况你能拿到这么多钱——但你拿到的不是现金，不是——
Harry： 对，没错。然后还有税——
Jacob： 我跟团队算这个账的时候，他们会说：等等，你这是要给我 50 万？（笑）不是字面意义的现在就给，是未来——
Harry： 某种意义上是。
Jacob： 没错。所以这块对我们来说一直有点难。但这也是建设生态的一部分。10 年后，下一个从斯德哥尔摩冒出来的创业公司，希望不会再有这个问题。
Harry： 完全理解。现在人人都在被鼓励尽可能多地烧 token。我在几家上市公司当董事，他们跟我说：“我老听到'刷 token'（token maxing）这个词。关于怎么聪明地用 AI，你会给 CEO 什么建议？我们到底该不该拼命把 token 用到极限，还是得稍微踩踩刹车？”
Jacob： 这事我有几点要说。第一，搞排行榜。很多人都说：搞个 token 用量排行榜，还在绩效评估里谈 token 用量。这就会导致 token maxing——大家纯粹为了好看而烧 token。这是蠢到家的做法。要搞就搞黑客日、搞 demo 日：让大家展示自己效率有多高、做得有多好；奖励的是“高效、有产出”，而不是“用了 AI”——反正 AI 自然是通往那里的路。
对企业来说，还有一点：这其实是 Cursor 存在的理由。如果你的选项是 Codex、Claude Code，外加一个中立的第三方，而你本来又是按用量付费的——那 Cursor 能帮你大幅优化 token 开销，因为他们可以优化你的用量：把请求路由到便宜的开源模型，或者帮你给不同任务设定用什么模型、设什么限额。
Harry： 可它现在被 xAI（Grok）收购了，还能保持中立吗？
Jacob： 这个我们只能走着瞧，看他们——
Harry： 我其实不同意。这也是为什么我觉得 Cognition 和 Factory 都会发展得很好，因为它们模型中立。但如果你——
Jacob： 懂了，因为你觉得 Cursor 现在跟 X 绑死了。
Harry： 百分之百。
Jacob： 说实话，这起收购让我有点意外，也有点难过。
Harry： 为什么？
Jacob： 因为我觉得如果他们保持独立，本来能讲一个很酷的故事。当然，协同效应我也看得到：他们没有足够的算力，训练不了自己的模型——而他们大概必须得训自己的模型。我只是觉得，行业这样垂直整合，挺可惜的。
这期节目上线仅 10 天后（2026 年 6 月 16 日），SpaceX 官宣以 600 亿美元全股票收购 Cursor 母公司 Anysphere，交易预计 2026 年三季度完成交割，成为史上最大规模的 VC 支持企业收购案（developersdigest.tech）。Jacob 在节目中点出的动因——“他们没有足够算力，训练不了自己的模型”——正是交易的官方逻辑：此前 4 月起，SpaceX 与 xAI 已向 Cursor 开放 Colossus 数据中心用于模型训练。Harry 担忧的“中立性丧失”也迅速兑现为行业议题：模型中立的 Cognition（Devin）与 Factory 被普遍视为直接受益者。Jacob 那句“行业这样垂直整合，挺可惜的”，基本成了开发者社区对这笔交易的普遍情绪注脚。
IDE 之死与 Token 预算的机会成本
Harry： 你觉得 IDE 死了吗？
Jacob： 现在这种形态的 IDE 会死，是的。我不知道下一代 IDE 长什么样，但它肯定不是“读一行行代码”。说实话它可能是图形化的：你看着系统架构图，在那里评审、做规划，然后智能体跑出去，确保你规划的东西真的被做了出来。我不知道它具体长什么样，但肯定不是一行行代码。
Harry： 开发者薪资的百分之多少，你愿意花在给他们的 AI 工具上？
Jacob： 我不想说“无限”，但对我来说这是个机会成本问题。我们身处一个竞争环境里。
Harry： 是吗？
Jacob： 是啊。（笑）
Harry： 不可能吧。我都不知道呢。
Jacob： 是啦是啦。（笑）我们能做的事情太多了，而不做它们的成本高得吓人，高到几乎压过任何 token 成本。任何一点效率提升，对我们而言都价值巨大。当然这是对我们而言，某些公司账算出来会不一样。所以我认为 token 预算本质上是个机会成本问题：值不值得烧一大堆 token 去学习，万一它能给我们带来 20% 的效率提升呢？对我们来说，值——我们的机会成本非常高。
Jacob 把“愿意花开发者薪资的百分之多少买 AI 工具”改写成了机会成本问题：不做的代价，几乎压过任何 token 账单。这与 Clay Bavor 的“每个工程师每年 10 万美元 token 预算”异曲同工——当 AI 杠杆能把工程师产出放大一个数量级，工具预算的本质就是“用百分之几的人力成本，买两位数的产出弹性”，资本回报率极高。但要给这个框架加上边界条件：它只在机会成本足够高、且组织能把 token 转化为交付的团队里成立。对产出平庸的团队，烧 token 只是换一种方式烧钱——这也是为什么 Jacob 同时痛斥 token 排行榜：度量什么就得到什么，考核用量得到的就是浪费。
按 100 倍用量造系统
Harry： 你做过什么、希望自己没做过的？
Jacob： 没有足够早地投入开发者体验，绝对是个问题。低估我们的增长速度，也是个问题。（笑）所以现在我确保我们做的一切都能撑到 100 倍的用量。我以前说 10 倍，后来发现不够。现在所有东西都得按 100 倍来。
Harry： 按 100 倍做和按 10 倍做，到底有什么差别？抱歉，我这个问法很外行。
Jacob： 一点都不外行。不一定所有东西都得变，但你通常会给自己设一些限制，比如：“这个大概够未来 3 个月用了”，或者“好，如果我们把问题框在这个边界内——大概 10 倍——那我们就可以做 X、Y、Z”。但 100 倍的时候，这些假设可能就不成立了。所以有些时候你得专门去想，尤其是那些带突发性的场景。我们的表格视图（Tabular View）产品就是个例子：你可以从大量文档里批量抽取，填到许许多多的单元格里。1 万个单元格和 10 万个单元格，对系统负载来说是天差地别，因为负载是瞬间飙上去的。这类系统里，10 倍和 100 倍就是不一样。
Harry： 那遇到峰值差这么多的情况，你们怎么办？这对你们的实际做法意味着什么？
Jacob： 我们得琢磨体验。如果 10 个人同时干这种疯狂的事，我们还有一大堆其他用户想要好体验。所以本质上我们得做公平排队（fair queuing）：如果你在跑 10 万个单元格，你大概不介意等一会儿，你去泡杯咖啡就行。但如果你只跑 10 个单元格，那就应该飞快返回。
更强的模型还是更强的工程师：没有 Ego 的文化
Harry： 完全明白。再来个不太公平的：如果我能让你比所有人提前 6 个月用上一个更强的模型，或者比所有人提前 6 个月拥有一批更强的工程师，你选哪个？
Jacob： 工程师，毫不犹豫。模型一直在变、一直在变好。但如果你有真正优秀的工程师，你可以搭一个能指数级自我改进的系统，这值钱得多。
Harry： 有什么事是你现在知道、但希望自己第一天就知道的？
Jacob： 说实话，希望我当时就知道我们会增长得多快。这是我一直低估的事。我觉得自己并没有为这段旅程做好准备——我是被打准备好的，因为每 3 个月就被现实抽一巴掌。（笑）
Harry： 你信不信“人天生只适合公司的某个阶段”这种说法？我问得私人一点：如果我是你，我现在脑子里会想——我是不是那个把这家公司一路带到上市的 CTO？
Jacob： 这问题很公平。我信不信？不，我不信。对我来说这是个“我能多快解决问题”的问题：眼下这些问题，我是解决得最快的那个人吗？还是有别人能比我解决得更快？Legora 有个很好的文化：没有人带 ego（自我包袱）工作。我现在有两位工程总监，我招他们的时候就跟两人都说过：如果有一天我认为你会比我做得更好，那我们就换位置，或者我去做别的。我对头衔没什么执念，他们也一样。我们聚在这里是为了做成一件巨大的事，这才是最重要的。我持续评估自己的履职表现，做得不好就尽快纠正。到目前为止还没有纠正不过来的，但也许会有那么一天。
Harry： 招到“最强又没有 ego”的工程师，秘诀是什么？这种人明显吗？
Jacob： 有 ego 的人一眼就能看出来。甚至只要谈薪资和头衔的时候，你就看得出来。
Harry： 我不知道你怎么看，我常说：厉害的人想要的是更多的钱，他们对头衔没那么在意。
Jacob： 我觉得这话完全对。我们招进来的大多数人，根本连头衔都不谈，我们谈的是他们要去攻坚的那些难题。
Harry： 全员聚在斯德哥尔摩，对你们有多重要？
Jacob： 非常重要，是为了跑得足够快。我们刚才聊过交接成本：如果一个 PM、一个设计师、一个工程师就坐在一起，你几乎都可以没有“交接”这回事——三个人下周一起扑上去把这个问题做了，做完了。但如果他们被隔离在不同的筒仓里，中间隔着交接，你会损失巨大的效率：跳上 Zoom 会，信息又不清楚——
Harry： 对，“这个文档写得不够好”，那就再开一个会，文档来回评三轮，然后不知道谁在什么地方看到了、留了条评论，还得专门聊那条评论。不过——最优秀的工程师往往喜欢远程，这个你怎么平衡？
Jacob： 我们对“我们是谁、我们不是谁”有非常鲜明的主张。如果你是个很强的工程师，又想远程，那你大概率也想做非常孤立的问题。这也没问题——我们大概也有这类问题，以后也会有。但眼下那不适合我们。我们宁愿去找那些想和别人一起解决同一批问题的人。
2027 年底 270 人：每周进两个半人的赌约
Harry： 两年后，或者说 2027 年底，你们会有多少工程师？现在是 80。
Jacob： 我反正会说一个偏低的数字。（笑）
Harry： 我会在 2027 年 12 月 31 日 WhatsApp 问你：“说错了吧？”
Jacob： 答案肯定是“错了”。我不知道……300？也许 200。
Harry： 200 和 300 可差远了，你必须押一个。
Jacob： 非押不可的话，我想押小的那个。那就 270 吧。
Harry： 270。好，那还要再招 190 个。
Jacob： 对。
Harry： 再进 190 个人，你还能保持“只要 A 级人才”吗？这相当于每周进两个半人。
Jacob： 如果是线性的，那做得到。我觉得行。我宁可完不成数字、但团队全是 A 级选手，也不愿意用 B 级选手凑数。因为只要你引进了你不信任的人、团队不信任的人，A 级选手就不会留下来了。
“我宁可完不成数字、但团队全是 A 级选手，也不愿意用 B 级选手凑数。因为只要你引进了你不信任的人、团队不信任的人，A 级选手就不会留下来了。” "I'd rather miss my number and have A players than hit it with B players, because as soon as you introduce people that the team doesn't trust, the A players won't stick around."
▍点拨：这是乔布斯“A 级选手只想和 A 级选手共事”定律的招聘版，但 Jacob 给出了它的博弈论内核：人才密度是一条单向门——稀释一旦发生，流失的不是 B 级选手，而是对平庸最敏感的 A 级选手。在“每周必须进 2.5 人”的扩张压力下还能说出“宁可完不成数字”，恰恰说明 Legora 把人才密度当作资产负债表上的核心资产来守护，而不是当作可以融资摊薄的股份。
收购式招聘：一次进一个精锐小组
Harry： 你最近买公司的频率，比我做播客还勤。（笑）
Jacob： （倒吸一口气）才没有。
Harry： 你笑是因为这是真的。我都快成个投资人了。我的问题是：在很多情况下，要拿到真正的 A 级人才，是不是非得靠买公司？
Jacob： 我觉得不是，但这样更快。本质原因就是：如果你找到一个很厉害的人、一个很厉害的创始人，他是能吸引来优秀人才的。于是你一下就得到一个 5 个人的精锐小组，一周进 5 个——如果你得每周都完成进人指标的话。这比挨个去大公司、甚至创业公司里说服人跳槽快多了。而且，一个五六个人的小创业公司，那些人本来就是想一起共事的。
Harry： 那他们的代码库你们就直接扔掉？还是说这纯粹是人才收购（acqui-hire）？
Jacob： 很多时候两种都有。如果他们做的东西跟我们相邻、领域相近，甚至哪怕方向不相关但技术栈相似，我们会吸收他们所有的经验，并且可能会在 Legora 里把它重做一遍——大部分情况是这样。但他们会完全融进团队：他们都是 Legora 人，在 Legora 的代码库上干活，顺便带来一些经验。
Harry： 整合难吗？
Jacob： 不难，容易得出人意料——前提是你招的是低 ego 的人。如果你招来的 5 个优秀工程师都不在乎头衔、不在乎自己在组织架构图里的位置，只想解决问题，那整合起来容易得出奇。
招错的复盘与“非常强”的反馈
Harry： 工程师招错的时候，你回头看，什么是你当时没看见、希望自己看见了的？
Jacob： 一般来说，招错人的时候——我得自我剖析一下——多半是我自己的原因。我没带过这么大的工程团队，所以我会自我怀疑：面对一个比我资深、比我见得多的人，我不够自信去说“你错了”。发生过一两次：一个很资深的人，我们聊，他讲系统搭建、讲设计、讲他对这一切的思考。我隐隐觉得哪里不对，其实我一直都感觉得到，但最后我总能说服自己：“算了，人家大概比我懂得多，人家肯定想清楚了。”结果两周、四周、六周之后，你开始发现：他并没有。
Harry： 你多快能发现自己招错了？
Jacob： 一个月。到那时候你就知道了，然后你会给非常强的反馈。我两周的时候就会给非常强的反馈。
Harry： “非常强的反馈”是什么意思，Jake？
Jacob： 非常强就是：“你不改掉这个，你就待不下去。”反馈就是反馈。
Harry： 有人在听到“你不改就待不下去”之后，还真的缓过来的吗？
Jacob： 没有。但他们必须得到这个机会——如果做到了，他们就留下。
最难招的岗位：还需要管理者吗
Harry： 今天最难招的岗位是什么？
Jacob： 高级管理层，极其难招。
Harry： 高级管理层——横向职能的高管？
Jacob： 不是。是产品和工程体系内的工程总监、工程经理。也许这一直都难，但我觉得难在我们只想要“既真正懂技术、又能做管理”的人。而见过大场面（经历过规模化）的人，通常也已经不碰技术了。
Harry： 那我们今天还需要管理者吗？我的好朋友、SaaStr 的 Jason Lemkin 就说过：LinkedIn 上凡是晒自己团队的人，开除，立刻开除。我们不要“管着经理的经理的经理”。做不了全栈，就滚蛋，拿上遣散费走人。我们真的还需要高级管理人员吗？
Jacob： 真的要看情况。你完全可以搭一家全是资深大牛工程师、什么都能做的公司，那你大概根本不需要管他们——尤其当目标感足够强、每个人都知道自己在奔什么的时候。比如 Codex 团队：他们都知道自己在做什么，直接扑上去干就行，不需要任何人告诉他们干得不错。但如果你的产品更复杂、可以往很多方向走，需要不停地做优先级排序，而且你有一组工程师、一个工程师团队——我们的工程团队是这么搭的：相对小的团队，比如 6 个人，配一个 PM 和一个工程经理。这个工程经理技术极强，大部分时间还在写代码，不是那种“大家手拉手唱歌”型的人。（笑）但重要的是，得有人对团队的健康状况负责：大家干得怎么样？大家开不开心？我不可能到处转着去判断每个人行不行。所以我认为有个明确担责的人很重要。我们就是这么运转的：团队自己定 roadmap，他们就是自己的小创业公司，但有一个人对结果负责。
Max、Sifted 风波与裘德·洛的品牌战役
Harry： 每个新产品功能 Max 都亲自盯吗？
Jacob： 大功能，是的；小功能，不盯。
Harry： 这样行吗？
Jacob： 对我们一直行得通，目前效果非常好。Max 的时间花在他最牛的地方——他是个顶尖的销售，你大概也知道。（笑）所以 Max 的时间花在销售上，花在产品愿景和重要的产品决策上。大的发布、大的项目，他很早就介入，并且全程参与。但小功能——你招优秀的人，就是为了能放手让他们去做。就是这样。
Harry： Max 这个人特别的地方在于：他对自己说的话深信不疑。很多时候别人跟你推销，你心里知道“他在向我推销”。
Jacob： 对对对。
Harry： 而他骨子里就不可能觉得自己会错。
Jacob： 绝对如此。
Harry： 另外还有件特别妙的事——我们天然跟 Sifted 不对付，因为他们就是一帮混蛋，但他们那篇《Taste of Blood》的报道写得真不错。Legora 内部是不是所有人都炸锅了：“我的天”？
Jacob： 对，那篇太好笑了。我们现在连屏保都换成“Blmuck”了……（笑）已经成了内部梗。
Harry： 你们喜欢裘德·洛（Jude Law）那条广告吗？
Jacob： 我超爱。你知道吗，这个秘密我憋了大概 9 个月。
Harry： 你觉得做得好吗？
Jacob： 我觉得好。
Harry： 嗯——你这么反问，我猜你是觉得做得不好？我觉得裘德·洛那个创意特别棒。它给你们的实际效果怎么样？
Jacob： 效果好得惊人，疯了一样。到处都有人看到它，这很好。大家都在谈论它——这就是这场 campaign 的目标：我们需要所有人都在谈论我们。
Jacob“憋了 9 个月的秘密”，在 2026 年 4 月 13 日揭晓：Legora 发布首个全球品牌 campaign「Law just got more attractive」，由裘德·洛（Jude Law）出任主角，创意方为斯德哥尔摩的 NoA Åkestam Holst，SNL 资深导演 Rhys Thomas 执导、奥斯卡获奖摄影师 Hoyte van Hoytema 掌镜，投放纽约、伦敦与斯堪的纳维亚市场（Legora Newsroom）。选角逻辑一半是名字双关（Law），一半是用电影明星把法律 AI 从“生产力工具”重新定位为现代法律工作的核心组件。campaign 紧随 56 亿美元估值的 D 轮官宣，成为 2026 年法律科技领域讨论度最高的营销事件之一——Jacob 口中“效果好得惊人”，与公开报道完全吻合。
快问快答：最大的威胁是停止自我重塑
Harry： 好，我们来个快问快答。我说一句短的陈述，你给我第一反应。行吗？
Jacob： 来。
Harry： 过去 12 个月，你在哪件事上改变想法最大？
Jacob： 招聘。（笑）我们得招更多人。只要多一个人是净正贡献，我们就应该加人。
Harry： 你觉得今天最被低估的 AI 公司是哪家？
Jacob： Legora。
Harry： 哥们儿，我可是 Legora 的大使，连我都想说：你认真的？（笑）再给我一个答案。
Jacob： 我必须得说嘛。真的有好多——
Harry： 让我说一个：Wispr Flow。让我卸掉 Wispr Flow 的痛苦是难以想象的。
Jacob： Wispr Flow 确实好。不过我觉得本地模型会越来越多，Wispr Flow 不是本地的。
Harry： 所以你大概会换一个类似的本地替代品……或者他们干脆转本地？但工具本身确实好。
Jacob： 工具本身确实好。
Harry： 补全这句话：Legora 最大的威胁不是 Harvey，而是……
Jacob： 会杀死我们的，是我们停止自我重塑。这话说起来很无趣，但我们经常讲“守在自己的泳道里”：专注我们的产品、我们的用户。可整个环境变动太剧烈了。如果你一年前请我来做这期播客，内容会完全不一样。所以我认为，真正会杀死我们的，是失去持续反应、持续调整、持续重塑自己的能力。
“会杀死我们的，是我们停止自我重塑。” "The thing that's going to kill us is if we don't keep reinventing ourselves."
▍点拨：在模型能力每季度洗牌一次的行业里，“护城河”的定义被悄悄改写了：它不再是任何一项存量优势——不是数据、不是客户数、甚至不是那 80 个工程师——而是组织自我变革的速率。Jacob 说“一年前这期播客的内容会完全不一样”，等于承认所有当期答案都有保质期。这对投资者是个重要的尽调提示：评估 AI 应用层公司时，“它今天做对了什么”远不如“它推翻过自己几次”有预测力。
Harry： 你们刚靠裘德·洛在品牌营销上赢了一局。下一个，你最希望 Legora 的 logo 出现在哪支运动队身上？F1、足球、NBA 都行。
Jacob： F1 会很棒。我是 F1 铁粉——F1 一定会很炸。
Harry： 战略上真的划算吗？你们做高尔夫就很有战略眼光。
Jacob： 我们是做高尔夫。我们还赞助了纽约的洋基队（Yankees），也很不错。
Harry： 你们赞助了洋基队？
Jacob： 对啊，你不知道？阿隆·贾奇（Aaron Judge）啊。
Harry： 我靠。这得花多少钱？
Jacob： 这我不能告诉你。（笑）但我真正想让我们赞助的球队，是我家乡的哥本哈根足球俱乐部（FC Copenhagen）。那是儿时的梦想。不过他们现在踢得挺烂，所以现在赞助估计还挺便宜。
Harry： 这就是传说中的“曝光量”啊。
Jacob： 哈哈，你还能蹭到——联赛冠军？没戏。
Harry： 欧战也没戏，他们连丹麦联赛榜首都不是。
Jacob： 是是是。
Harry： 行吧。（笑）说一个你对法律行业未来的看法，一个大多数人会觉得疯狂的看法。
Jacob： 要疯狂一点的话——我觉得可以跟写代码做很多类比。法律这个行当高度依赖文本，智能体类 AI 功能的路子也相似。如果我相信：写代码这件事，我们会越来越少地盯着源代码、更多地站在上面一层看——那我对法律也得说同样的话：律师终将不再逐字逐句抠合同的语言，他们会站高一层工作：我们的谈判立场是什么？哪些风险我们能接受、哪些不能？而不是坐在那儿往 Word 里敲字。我不确定这是不是对的，但这是我的直觉，事情在往这个方向走。要疯狂的话，那就是——律师以后……
Harry： 律师的流程也是。我现在看 NDA 就是：大哥，你们明明已经签过上百份 NDA 了，为什么每份还要从头写？（笑）这感觉是个已经被解决的问题了。
Jacob： 这期播客播出去我麻烦大了。（笑）
收尾：比 800 磅大猩猩更拼命
Harry： 靠。（笑）最后一个正经问题：在一个存在“800 磅大猩猩”（800-pound gorilla，指行业巨头）的行业里竞争的创始人，你给他最大的建议是什么？
Jacob： 说实话，就是比那只 800 磅大猩猩更拼命。人们低估了这一点。大猩猩内部，没有谁是真心热爱自己待在那里的。如果你在和 Google 竞争，Google 里那个跟你对位的 PM，他根本不在乎这事成不成。也许她确实很努力，但……我不觉得。如果你是一支精干的小团队，玩儿命干，你是可以做出真正了不起的东西的。
Harry： 准备好跟我打个赌了吗？
Jacob： 来。
Harry： 今年年底，营收会落在什么数字？
Jacob： （叹气）（笑）会超过 2.5 亿。
Harry： 我押 2.72 亿。
Jacob： 2.72 亿？嗯，我觉得也会比那个高。但我不想——我不想因为数字惹麻烦。（笑）当我没说，Max、Patrick，你们听到了啊，我什么都没说。David 估计很快就要气冲冲地给我打电话了。
Harry： 哥们儿，今天聊得太开心了。谢谢你做客，你聊得棒极了。
Jacob： 谢谢。
- 瓶颈已经从“写代码”迁移到“产品工作”与“评审”——组织设计的起点是重新定位瓶颈：把 PM 的时间还给客户沟通与综合提炼，把评审从“逐行看代码”升级为“架构影响与安全边界判断”。凡是不触碰系统架构的改动，就放飞智能体；凡是触碰战略取舍的改动，才值得人类出场。
- 为智能体建一支“开发者体验团队”，而且越早越好——当 AI 贡献过半代码，护栏规则、定制评审智能体、一键开发环境与高质量 README 就是新的生产工具。杠杆是乘法：工程师产出放大 10 倍之后，DevEx 再提效 20% 的绝对收益更大。Jacob 最后悔的两件事（DevEx 建晚了、增长估小了）指向同一个教训：效率基础设施要按 100 倍用量提前下注。
- Token 预算是机会成本问题，不是成本控制问题——别搞 token 用量排行榜，更别把用量写进绩效：度量用量得到的就是浪费。用黑客日与 demo 日奖励“高效与产出”，而不是“用了 AI”；对高机会成本的团队，烧 token 学习的期望回报几乎总是正的。
- 品味与“剩下的 90%”是通缩时代的定价权——当复制成本趋零，vibe coding 出 90% 的形似只需几天；但边缘情况、审计日志、权限体系这些枯燥工程，以及“我们是谁、不伺候所有人”的鲜明主张，构成了别人拿不走的部分。放任 AI 撒开跑，产品就会收敛成与所有人一样的灰色。
- 人才密度是单向门，宁缺毋滥——A 级选手对平庸最敏感，引进一个团队不信任的人，流失的是最好的人。扩张可以靠收购式招聘整组进人，整合的难易与 ego 成反比；招错人时，两周内给出最强反馈，然后把决定权交给对方。