20 产品：深入 Legora 技术栈：为何代币最大化正让企业初创企业陷入困境——与 Legora CTO Jacob Lauritzen 对话

一直都在。

Constantly.

这是企业的未来，还是说Legora已经站在了创新的最前沿？

Is that the future of enterprises or is that bluntly Legora at the very precipice of innovation?

这一定会成为未来。

It will be the future.

我不确定具体什么时候，但迟早会是。

I don't know when, but it will be the future.

我觉得其实可以这样理解，

I think there's like

为了让我们更清楚，这到底意味着什么？

And just so we understand, like, what does that mean?

你们会为Slaughter MA和Clifford Chance这样的客户开发网站，好去向他们做演示吗？

Do you build sites for Slaughter MA so you can pitch to them and Clifford Chance so you can pitch to them?

不会。

No.

但这比那要广泛得多。

But it's it's way broader than that.

我们现在有个内部的AI赋能团队，重新思考所有现有工具的基本原则——比如，如果你想从200人快速扩张到1000人，最高效的公司该是什么样子？

It's like we have a a team now that's internally AI enablement, which is just like reimagining, you know, again, first principles, with all the stuff that we have today, if you're building the most efficient company to go from, let's say, 200 to 1,000 employees, what does that look like?

这当然包括像Cloud Cowork这样的工具，但更重要的是，我们能不能自己动手开发所需的各种工具？

And that means, obviously, know, Cloud Cowork and similar things for everyone, but it's also like, can we just build a bunch of the tools that we need ourselves?

我们能不能直接用‘ vibe coding ’写出一堆工具？

Can we just vibe code a bunch of the tools?

我们能不能用‘ vibe coding ’开发出人力资源系统？

Can we vibe code our HR system?

我们能不能用‘ vibe coding ’搭建人才招聘系统？

Can we vibe code our talent acquisition system?

我们能不能用‘ vibe coding ’做出薪酬系统？

Can we vibe code our payroll system?

现在市面上很多工具看似存在，但总得大改特改，最后还是用不顺手。我们干脆自己动手做了，因为现在开发成本低得离谱。

There's like so many things where tools exist out there, but you always need to customize them so much, and they always basically never really work, and we just built them now because it's so cheap to build.

你们已经用‘振动编码’解决了哪些问题？

What have you been able to vibe code away?

我们其实还加了不少东西，算是对‘振动编码’的扩展。

Well, we've added a bunch of things that are additional or additions to vibe coding.

举个很傻但特别典型的例子，有个叫瑞安的，是从加拿大来的。

So a great, really stupid example is Ryan, who joined from Canada.

我们有一群人是从加拿大过来的。

We have a team of people joining from Canada.

他们都要搬去瑞典，瑞安就写了个小程序帮大家搞定搬迁流程。

They're all moving to Sweden, and he Vibe Coded an app to help everyone migrate.

具体来说，如果你是加拿大人，它会告诉你所有相关的法律和步骤，还是交互式的，能显示你进度到哪儿了，特别实用。

So very specifically, if you're Canadian, these are all the laws and all the steps you take, and it's interactive, and you can see how far you've made it, and it's awesome.

这玩意儿估计就花了一天时间写，却省了整个团队好多时间。

And it took, I don't know, a day to vibe code, and it saves so much time for an entire team.

所以你看，大系统可以做，但那些小工具积少成多，效果真的惊人。

So it was like, you can build the big systems, but even just all the small ones that you can build really add up.

前几天我跟一位上市公司的CEO朋友聊天，他说他助理休了三周假，回来就用Vibe Coding搞了个叫Cooper的系统，直接把原来的Cooper给替换了。

I was with a a friend who's a public company CEO the other day, and he was like, you know, my chief of staff took three weeks off and basically vibe coded Cooper, and we replaced Cooper.

而且真能用，特别厉害。

And it works, and it's brilliant.

那你怎么回应那些说‘这太荒唐了’的人呢？

What do you say to people who are like, that's ridiculous.

明明可以直接买现成的HR系统，干嘛还要花几个月去Vibe Coding？

Why would you ever bother vibe coding and taking months to do an HR system when you could just buy it off the shelf?

这得看具体是什么系统。

It really depends on the system.

我们可以从两个维度来看。

Let's say there's two axis systems.

一个是横向的，也就是你的产品覆盖范围有多大；另一个是纵向的，也就是它的复杂程度有多高。

There's there's the the horizontal one, which is like how big is your product surface area, and there's the vertical one, like how complex is it.

如果你的系统非常深入，那它的外在表现其实跟别的系统差别不大。

So if you're deep, essentially your surface area, it looks quite similar.

这个应用看起来很简单，但背后其实特别复杂。

It's a simple app, it's just a lot of complex stuff.

它把很多复杂的东西都藏在了用户看不见的地方。

It hides away a lot of complexity to the user.

还有一种是特别浅的应用，功能多得不得了，但每一块都不复杂。

And there's the other one, which is your very shallow app, which is like tons of things you can do, but there's not that much complexity.

如果是个浅层应用，还得你大量自定义，那还不如自己动手做。

If it's a shallow app and it requires a lot of customization from you, maybe you just build it.

这种情况下，自己做反而是对的。

That's probably actually the right thing to do.

如果是特别深层的应用，要做的东西太多，自己根本搞不定。

If it's a very deep one, there's just too much stuff for you to build and it's not viable for you to do.

我们之前提到产品经理离客户近，再把反馈传给工程团队，这本来就是产品经理最擅长的事。

We mentioned PMs and their proximity to customers, and then that delivery mechanism back to engineering, which is kind of always what PMs did and did best.

未来几年，产品经理的角色会变吗？

Does the role of the PM change in the next few years?

说是，也说不是。

Yes and no.

我觉得有些人，或者说很多人认为产品和工程正在融合。

I think there are certain people that are, or a lot of people are saying that product and engineering are converging.

它们正变成同一件事。

It's becoming one thing.

一个人就能同时做产品工作，还能开发系统、上线，什么都自己搞定。

It's like one person can do the product work and build the engine, like build the system and ship it and everything.

对一些公司来说，确实如此。

And I think for some companies, that's true.

但对那些真正需要产品经理的公司来说，就不成立了。

I think for companies where you really need PMs, it's not true.

或者理论上可以，但效率很低，我来告诉你为什么。

Or it can be true, but it's inefficient, and I'll tell you why.

我们刚才在聊产品。

So we were talking about product.

你先做产品方面的工作，比如定范围，然后开发，上线，再复盘。

You know, you do the product work first, the scoping, and then you build it, and then you ship it, and you review it.

像Legora这样的公司，我们一直盯着瓶颈，而现在的瓶颈已经不是写代码了，而是产品工作本身。

And then a company like Legora, we're always focused on the bottleneck, and 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, like, the opportunity cost of that is really high because what you really want them to do is the product work.

比如跟客户聊天、分析需求、做信息整合，这些才是真正的瓶颈。

Like, talking to customers, figuring out, doing the synthesis, that's the bottleneck.

如果产品经理大量写代码，花一半时间在编码上，那我们就会错过太多本该做的产品工作。

So if your PMs are coding a lot, if they're spending 50% of their time coding, we're missing out on so much product work.

所以我的看法是，对于某些公司，比如做开发者工具的，或者做消费级产品的，工程师本身对用户需求就有很好的直觉，这种情况下，你可能根本不需要产品经理——其实早在AI出现之前，这些公司就不需要。

So that's how I think about it right now, and for certain companies, if you're doing developer tooling or doing consumer where engineers intrinsically have a good sense for their own or their other own clients, you maybe don't need a PM at all because you haven't needed a PM before AI either there.

所以我觉得，有没有AI，这一点都没变。

So I don't think that changes with and without AI.

现在的产品经理确实能做工程了。

PMs can now do engineering.

AI确实改变了这一点，但这么做并不总是最高效的。

That changes with AI, but it's not always efficient to do it.

这本质上是个机会成本的问题。

It's like a matter of opportunity cost.

还有交接成本——如果我把所有产品工作都做了，然后交一份PRD给工程师，效率就会打折扣。

And there's handover cost, which is if I do all the product work and then I give a PRD and I give it to an engineer, then you lose efficiency there.

PM适当写点代码挺好的，能做出高保真的原型，让别人一看就明白最终效果长什么样。

It's good if PMs do some amount of bype coding to show very high fidelity, Here's a prototype, this is exactly what it looks like.

我再重复一下交接成本的问题。

To repeat just the handover cost.

没错，完全正确。

Exactly, yeah, exactly.

但他们不该花太多时间做工程，如果只埋头写代码，产品工作就会被耽误。

But they shouldn't spend a lot of their time engineering, because if they just focus on actual engineering, we lose out on the product work.

我刚从大学计算机系毕业，是你弟弟。

I'm your little brother coming out of CS at university.

在未来三到十年，你建议我该怎么定位自己才最好？

What would you advise me to be best placed in the next three to ten years?

如果我要给社交媒体营销的人提建议，我会说：你得成为全栈型人才。

So if I were to advise someone on social media marketing, I'd say, Hey, you need to be full stack.

你要能自己做图、发布内容，还能把它推火。

You need to be able to create the image, get it out, and amplify.

没错。

Yep.

同样的道理，我觉得最重要的是学会怎么学习。

Similar thing, I think actually the most important thing is you need to learn how to learn.

你要搞清楚怎么不断重塑自己，持续学习和进步，因为现在变化实在太快了。

You need to figure out how you constantly reinvent yourself and keep learning and improve Because the things change all the time right now.

每周都有新东西冒出来，你得调整工作方式，或者做点别的改变。

It's every week there's something you should be doing, need to change your way of working or whatever.

对你自己来说，最重要的就是时刻保持对最新趋势的敏感，紧跟前沿。

The most important thing that you can do for yourself is figure out how you keep at the forefront of what's happening all the time.

如果你能做到这一点，足够灵活又有野心，其他事情自然就水到渠成了。

And if you can do that, if you're adaptable enough and you are ambitious enough, then the rest kind of works out.

因为只要你学得比别人快，时间一长，你就能赢。

Because if you can just learn faster than everyone else, then, you know, over time, you win.

Legora这个产品的质量，在多大程度上依赖于底层模型的水平？

To what extent does the quality of Legora as a product depend on the quality of the underlying models?

远没有大多数人想的那么重要。

Much less than most people think.

Legora的价值在于它周边的很多东西，比如专门为法律场景设计的高效AI操作组件，或者企业级功能，还有模型之间的最优衔接。

The value of Legora is there's so much more around it, whether it's like the primitives that make sense for legal that make it more efficient to work with AI, or it's all the enterprise y features or the optimal rounding between models.

没有这些模型，我们根本不可能存在。

We wouldn't exist without the models.

每次模型升级，我们的产品和智能代理都会跟着变强。

And every time the models become better, our product becomes better, our agent becomes better.

但就算你把模型从Legora里拿走，人们还是会选它。

But let's say you took away a model from Legora, people would still pick Legora.

所以他们并不是因为模型本身而选择它。

So they don't buy it based on the model.

随着时间推移，你们对模型的使用方式有什么变化？

How has model usage changed for you over time?

变化挺大的。

It changes a lot.

说实话，最好的模型每两周就换一回。

I mean, the best model changes biweekly.

我们一直在OpenAI和Anthropic之间切换。

We've been between OpenAI and Anthropic.

我们一直在评估各种不同的模型。

We keep evaluating all the different models.

你们会同时用十五个模型来处理不同任务吗？

Do you use like 15 at the same time for different tasks?

没到十五个，但大概有十个左右。

Not 15, but yeah, maybe 10.

是的

Yeah.

对，每个任务我们都会评估哪个模型最适合。

Yeah, so for each task, we will evaluate what model is best at this.

延迟和性能最重要，成本倒不是现在最关心的，虽然以后肯定会考虑成本。

Latency, performance, not so much cost, eventually it will be cost, but latency and performance is most important.

你看，性能必须得跟上。

You know, performance needs to be here.

我们能在不牺牲性能的前提下，把延迟增加到什么程度？

How much can we increase latency without dropping in performance?

通过把我们的智能体和其他AI功能设计得模块化，就能把问题拆解开来，用上特别高效的

By building our agent and our other AI features in a way that you can decompose the problem, you can use really efficient

模型。

models.

你可以追求最低延迟或最高性能，但输出效果可能不是最好的。

You can have latency or performance at the fastest, but it may not be the best output.

或者慢一点，但效果简直棒极了。

Or slower, but fucking great output.

对。

Yes.

没错。

Yep.

选哪一个？

Which one?

我得做个决定。

I have to choose.

是的。

Yeah.

绝大多数情况下，性能更重要。

Almost always performance.

性能才是最关键的。

Performance is more important.

几乎是这样。

Almost always.

如果你是律师，为了更好的结果，多等两秒也没关系。

If you're a lawyer, you can wait two seconds more for the output if it's better.

如果效果更好，你甚至可能愿意多等一小时。

You can probably wait an hour more for

来等这个输出结果。

the output if it's better.

我刚才只是觉得特别有意思。

What do you I'm just fascinated now.

随着我们越来越关注成本，你对开源的未来怎么看？

What do you think about the future of open source as we do move more and more to a focus on cost?

你是怎么想的？

How do you think about that?

我觉得开源现在正处在最好的时候。

I think open source is having a great moment.

确实，真的没错。

It really, really is.

现在有太多优秀的开源模型了，而且运行起来特别简单。

There's so many great open source models now, and they're really easy to run.

还有很多优秀的推理服务，能让你高效地运行这些模型。

There's great inference providers that let you run really efficiently.

我们正越来越接近在设备上直接运行这些功能。

We are moving very close to being able to do things on device.

我的意思是，语音转文字现在都能在设备上跑了，连我的iPhone都能跑。

Mean, I transcription can run on device, can run on my iPhone.

我的Mac上就已经装了本地的语音转文字工具。

I have local transcription on my Mac.

坐飞机没网络的时候，我照样能用本地模型继续写代码。

When I do flights and there's no WiFi, I have local models running, I can keep coding.

它就像一个帮我写代码的GWEN模型，就在本地跑着。

But it's just like a GWEN model that runs and helps me code.

我觉得开源将会发挥巨大的作用。

So I think open source is gonna play a huge role.

我希望它能继续保持现在的发展趋势，毕竟拥有开源模型对保障技术自主和安全都非常重要。

I hope it continues to to evolve the way that it currently is, and I think it's an important thing that we have open source model for sovereignty reasons and for, like, security reasons.

我们应该拥有出色的开源模型。

We should have great open source models.

我能问一下，你今天最担心的是什么？

Can I ask what worries you today?

很多人担心中国的开源模型，我其实也一直在想这个问题。

A lot of people worried about the open source Chinese models, which I was kind of thinking about it.

更广泛地说，回顾我们刚才讨论的这些，你最担心的是什么？

More broadly, what worries you when you look at the landscape that we've discussed?

我特别希望看到欧洲和美国的开源模型。

I really hope to see European and American open source models.

它们一直比较欠缺，如果能有一些，那真的会非常好。

They've been lacking, and I think it would be really, really good to have some.

从博弈论的角度看，如果模型市场被少数几家公司垄断，结果肯定不会好，这很明显。

Game theoretically, we won't end up in a great place if there's a duopoly or monopoly on the models for obvious reasons.

你当然希望有竞争存在。

You know, you do wanna have some competition.

欧洲有没有机会参与这场模型竞赛？

You wanna Does Europe

现在有吗？

have any place to play in the model race today?

应该有，但目前还没有。

It should, but it doesn't yet.

你觉得我们在训练效率的前沿上走到哪一步了？

How far do you think are we in the efficiency frontier on training?

我们才走了1%吗？

Are we, like, 1% of the way there?

还是说我们已经走了90%，剩下的只是稍微再提升一点？

Or is it, like, we're 90% and, like, we might eke out some little bit more?

这是个好问题。

That's a great question.

一方面，是现在的架构问题。

One thing is just, the current architecture.

这种架构的性能能维持多久？

How long does that does that plateau?

我们需要全新的设计吗？

Do we need something new?

就在两天前，有个新模型发布了，复杂度低于二次方，支持超长上下文，这意义重大。

I mean, there's one model released two days ago that's subquadratic, which is huge context length.

这真的让人振奋。

That's super exciting.

我还不能完全相信那些评测数据。

I don't know if I trust the benchmarks yet.

得验证一下才行，但确实还在不断出现架构上的创新，说不定现在的大型语言模型架构，并不能一路带我们走到终点。

We to validate that, but there's architecturally innovations going on still, and I don't know, maybe the current LLM architecture is not the one to take us all the way.

现在还没有、但五年后可能会很普遍的职业是什么？

What role does not exist today that you think will be very common in five years' time?

我觉得企业里会冒出一种专门负责内部AI系统的岗位，IT部门可能会迎来一个爆发期，不再只是帮人装电脑、搞设备，而是组建专门的团队。

I think the internal AI systems role thingy for enterprises, I think IT will, can have like a flowering moment here, and, you know, go from being internal IT that's like setting up your computers and whatever to maybe have a system team.

这个团队会开发大量内部工具，让工作变得轻松很多。

That's building tons of internal tools that just make your life so much easier.

如果企业不设立这样的岗位，我真会气疯，因为这里面能提升的效率实在太多了。

If enterprises don't create that role, I will get really annoyed, because there's so much efficiency to gain there.

真正深入企业，为它们提供全套解决方案。

Really getting into the enterprise and having all of that for them.

企业要用这些技术，非得雇全职员工不可吗？

Do you have to have FTEs to have usage in enterprise?

你打交道的都是那种很难改变的律师。

You work with relatively sticky lawyers.

是的。

Yeah.

对。

Yeah.

没错。

Yeah.

你得亲自演示给他们看，喏，就这样用。

Do you have to have people show them, here you go.

喏，就这样用。

Here you go.

我们现在确实需要。

We currently do.

对。

Yeah.

但我觉得这主要是教育和认知的问题。

But I think that's just that's an education thing.

五年后，也许就完全不需要了。

In five years, maybe we don't at all.

这就是走在前沿要付出的代价。

That's the price you pay for being for being, you know, on the forefront.

你得去教育别人，还得帮他们。

You you have to educate and you have to help.

这也是为什么大家都愿意跟我们合作。

And that's why people wanna work with us also.

准备好接受一个不公平的问题了吗？

Are you ready for an unfair one?

准备好了。

Yes.

从产品或工程的角度来看，你哪些方面比以前做得更好了？

What have you done better than you from a product perspective or an engineering perspective?

我在招聘上更积极了。

I've been more aggressive with hiring.

但我其实还没在招聘上够积极。

I have not been aggressive enough with hiring.

我一直想保持一个非常小、非常精干的团队，对此我深信不疑。

Because I've always tried to have a very, very small, very lean team, which I believed a lot in.

我总是低估了我们需要多少人。

I consistently underestimated how many people we need to be.

一年半前我做过一张幻灯片，给全公司展示过，讲的是三百斯巴达人对抗波斯大军，我还说我们工程师最多就到二十人左右，结果远远低估了。

I had this slide that I drew up a year and a half ago that I showed the entire company, and it was, you know, the 300 Spartans versus the Persians, and it was like Legora and the 300 Spartans, and I said, I'm pretty sure I said, we will cap out at 20 engineers or something like that, which is like way undershooting it.

你们现在有多少工程师？

How many engineers do you have today?

现在大概有八十人。

Today, we are about 80.

是的。

Yeah.

你当初猜二十人，完全猜错了，对吧？

You got that wrong on 20, didn't you?

对。

Yeah.

我这次真的严重估错了，我们到现在还是人手太少了。

I got that really wrong, and we're way too we're way too small still.

因为人手不足，你们是不是进展太慢，或者没法做出想做的功能？

As a result of being too small, you are too slow or you're not able to build what you want to build?

其次，

Second,

有很多功能，其实完全可以组个团队专门去做。

there's loads of features that you can basically staff a team to build that

你们没法快速扩招，还保证质量，是吗？

we Can you can't ramp as quickly as you need to and retain quality?

没错。

Yes.

我们在这一点上做得非常好。

We're really good at this.

首先，我们在招聘上非常挑剔。

First, we're extremely selective with hiring.

也许这就是我们招聘速度慢的原因。

Maybe that's also why we're slower at hiring.

所以我们招的人都很优秀，上手速度特别快。

So we hire really great people and the ramp up time is extremely fast.

怎么

How do

你们具体是怎么做到让新人快速上手的？

you make ramp really fast as specifically as possible, anything that you do?

我可以告诉你们我们其实应该怎么做。

I can tell you what we probably should do.

当然可以。

Sure.

因为现实是，事情变得太快了。

Because like the reality is things move really fast.

所以我们要有一个专门负责开发者体验的团队，这个团队还比较新。

You need to have so we have a developer experience team relatively new.

这又是我犯的一个错。

Again, a mistake I made.

我早该把人招进来的。

I should have staffed that earlier.

他们让每个人的工作都轻松多了。

And they are making everyone's life so good.

他们具体做些什么？

What do they do?

他们确保我们的本地开发环境运行得特别顺畅。

So they make sure that our local development setup works really, really well.

速度超快，启动起来特别快。

It's super fast, it spins up really quickly.

他们开发了一个我们自己的后台编码助手，让每个工程师都能同时运行十几个助手，覆盖所有本地开发流程、浏览器操作和迭代任务。

We have our own background coding agent that they built that allows each engineer to have like 10 different agents running concurrently with like all of our local development, a browser, all the iteration stuff.

他们还在打造自定义的代码审查助手，能自动等待、观察，直到所有测试都通过、评审都合格，再交给人工处理。

They're building custom review agents, they're building features so that it can wait and see and wait until everything looks green and all the reviews are good, and then raise it to a human.

那里的效率提升非常大，他们还会开发一些工具，帮助新人快速上手。

The efficiency gains there are huge, and they will then also build tooling that helps onboard people.

所以只需要确保你的代码库里有清晰的README文件，新来的工程师有什么问题，直接问云代码或者Cursor就行了。

And so it can just be like, make sure that you have really good README files in your repository so that a new engineer will just ask their cloud code or their cursor about all their questions.

这真的特别有效。

Like, that's remarkably effective.

所以说，哪怕只是用上AI工具，也能大大加快新人的适应速度。

So it's just like, even just AI tooling makes it faster to ramp.

你们团队里有多少人负责开发者体验？你觉得什么时候该做这件事才对？

How many do you have in developer experience, and when do you think you should have done it?

现在有三个人，但还是太少了。

We have three people now, which is too few.

我觉得我应该在Opus 4.5发布的时候就做这件事。

I should have done it when Opus 4.5 came out, I think.

因为那时候才是该动手的时机，但后来呢，每个工程师的产出效率也跟着提升了。

Because that's when I should have done it before that, but then, you know, the the productivity of each engineer to next, let's say.

如果你能让每个人效率提升20%，那收益就更大了。

And so if you can make everyone 20% more efficient, it's it's even more gains.

在欧洲招聘工程师和在美国有什么不同？

How does hiring engineers in Europe differ to hiring in The US?

有几个方面的区别。

There's a few different ways.

在美国，人们没那么怕冒险。

In The US, people are less risk averse.

他们往往愿意马上去尝试各种新东西。

So, like, they'll they'll be ready to jump on a lot of things to to to test.

我觉得欧洲人普遍更谨慎保守。

I think in Europe, people are more risk averse.

欧洲人可能不算特别有使命感或者特别忠诚，但他们真的会认同自己所在的公司，愿意长期投入。

People in Europe generally are more I don't wanna call them mission driven or loyal, but they're like they really buy into the company that they work for and work with.

说服他们需要花很多时间，但一旦他们决定加入，就会一直留下来。

So it takes a lot of time to convince them, but once they're convinced, they really stay.

这很好。

That's great.

那美国这边更偏向交易性质？

And US is more transactional?

我觉得是的。

I think so.

没错。

Yeah.

你觉得人们对股权的重视程度有区别吗？

Do you find the attachment to equity different?

我们在瑞典其实得花时间向大家解释这一点。

It's actually something that we had to sort of educate people on in Sweden.

在欧洲，人们普遍对风险投资这一套不太熟悉。

And in Europe, I think it's it's people are just not used to the venture thing.

他们也不知道该怎么评估股权的价值。

They don't know how to value equity the same way.

你得明白，事情就是这么运作的。

Like, you have to really This is how it works.

这代表的意思是这样的。

This is what it means.

比如说，如果发生这种情况，你就拿到这么多钱。

Like, these are the If this happens, then you get this much money.

但你拿不到现金。

But you don't get it in cash.

这不像……

It's not like

对，就是这样。

Yeah, exactly.

然后呢

And then

还要缴税，还有我们团队里有人会说：等等，你给我一半一百万美元？

there's tax and then there's I do it with our team, they're Wait a minute, you're giving me half $1,000,000?

没错。

Exactly.

不是字面意思，但以后会这样。

Not literally, but in the future

从某种意义上说，对，确实如此。

In a way, yeah, exactly.

所以这对我们来说有点难，对吧？

So that's been a little bit difficult for us, right?

不过我觉得这也是构建生态系统的一部分。

But I think that's part of just creating the ecosystem.

十年之后，从斯德哥尔摩诞生的下一个初创公司

In ten years, the next startup that comes

希望就不会再遇到这个问题了。

out of Stockholm hopefully won't have this problem.

大家都被鼓励尽可能多地使用代币。

Everyone is encouraged to use as many tokens as possible.

我担任几家上市公司的董事，他们常问：听说你们在拼命用令牌，那你们会建议CEO怎么明智地使用AI？是不是该尽可能多地消耗令牌？

I'm on the board of public companies, and they're like, Oh, hearing about token maxing and doing What do you advise a CEO in terms of intelligent usage of AI, and should we just be pushing tokens as much as fucking possible?

关于这个问题，我有几个不同的看法。

So a few different things on that.

我觉得首先可以搞个排行榜。

I think one, having a leaderboard.

很多人都提过这个建议。

A lot of people say this.

在绩效考核里把使用令牌的数量列进去，结果大家为了表现好看，就纯粹刷令牌，根本不管实际效果。

Get to get a leaderboard, bring up token users at performance reviews, and that leads to token maxing, which is people just burn tokens just to look good.

这种做法简直太蠢了。

That's a really stupid way to do anything.

不如搞黑客松、做成果展示，让大家互相分享自己是怎么高效使用AI的，具体提升了多少效率。

Do hack days, do demos, have people show everyone else how efficient they are and, like, how much better they're doing.

应该奖励那些真正产出多、效率高的，而不是单纯看谁用的AI多——当然，AI会是实现这些目标的工具。

Reward them for being effective and efficient and having more output, not for necessarily using AI, but, like, AI will be the way there.

这一点也很重要。

That's one of the points.

我还有个针对企业的观点。

I had another point for enterprises.

我觉得Cursor之所以有存在的价值，就在于此：如果你的选项是Codex、ClotCode，再加上一个中立的第三方，而你们都是按使用量付费，那Cursor就能帮你大幅优化token开支，因为它能调整你的使用方式，对吧？

This is actually where I think Cursor has a reason to live, a reason to exist, which is if your options are Codex and ClotCode and a neutral third party, and you all pay, you know, you pay consumption based, Cursor can help you optimize your token spend a lot because they can optimize your usage, right?

它可以把请求导向更便宜的开源模型，或者帮你为想用的模型设置使用上限。

They can route them to the cheap open source model or help you set limits for whatever models you want

针对不同的任务来设定。

to use for what thing.

不过，被Grok收购之后，他们现在还能做到吗？

Well, can they now post acquisition by Grok?

这得看他们会不会强行把Grok整合进去，

Well, we'll have to see if they force I Grok and

我反而觉得Cognition和Factory会表现得很好，因为它们不依赖特定模型。

actually disagree, and that's why I actually think both Cognition and Factory will do very well, because they're model independent.

如果你

If you

明白了。

Okay.

因为你现在觉得

Because you think now

他们跟X绑定在一起了？

that they're tied to X?

百分之百。

A 100%.

对。

Yep.

看到这个收购，我其实有点意外，也挺遗憾的。

I was a bit surprised and sad to see the acquisition.

为什么？

Why?

因为我原本觉得，如果他们保持独立，会有一个特别棒的故事。

Because I thought that they could, if they stayed independent, they had a really cool story.

不过说实话，我也看得出其中的协同效应。

But I mean, I see the synergies.

很明显，他们算力不够，没法自己训练模型，大概率得靠别人来训练。

Obviously, they don't have enough compute, they can't train their own models, they probably have to train their own models.

我只是觉得，这个行业这样完全垂直整合，实在有点可惜。

I just think it's a shame that the industry is vertically integrated in that way.

你觉得集成开发环境已经过时了吗？

Do you think IDEs are dead?

我觉得现在这种形态的IDE确实会消失。

I think the current shape of an IDE will die, yes.

我不知道下一代会是什么样子，但肯定不是让人一行行看代码。

I don't know what the new, the next IDE is, but it's not reading lines of code.

也许是图形化的，说实话，我觉得有可能。

It's Maybe it's graphical, honestly.

可能是那种系统架构，你先在那儿设计、审查、规划，然后让智能代理去执行，确保你规划的东西真的被实现出来。

Like, maybe it's the systems, the architecture that you look at and you review and you plan it there, and then, like, agents run off and make sure that whatever you're planning actually is what's being made.

我觉得关键不是代码行数。

I don't think it's lines of code.

你愿意为每个开发者的人工成本花多少百分比在AI工具上？

What percent of developer salary would you be willing to spend on AI tooling for them?

我不想说无限多，但对我来说，这其实是机会成本的问题。

I don't want to say infinite, but for me, it's a question of opportunity cost.

我们现在处在竞争激烈的环境里，你知道的。

We're in a competitive environment, You know?

你也是吗？

Are you?

是的。

Yeah.

你要是不这么做，根本没戏。

You wouldn't be no way.

我还不知道这一点。

I didn't know that.

这真的很有趣。

There's like Fascinating.

我知道。

I know.

我们可以做的事情太多了。

There's so much so many things that we can do.

不做的代价非常高，几乎超过任何其他成本。

The cost of not doing it is extremely high, and it almost outweighs any sort of token cost.

任何效率上的提升对我们来说都价值巨大。

Like, any efficiency gain is worth so much to us.

对我们是这样，但对某些公司来说，情况可能不一样。

That's for us, but for certain companies, that will look different.

对吧？

Right?

关于令牌的预算，本质上是个机会成本的问题。

The budget on on tokens is mostly a question of opportunity cost.

花大量令牌去试错，只为可能提升20%的效率，这值得吗？

Is it worth us spending a ton of tokens to learn if it maybe gives us 20% efficiency?

对我们来说，值得。

For us, yes.

我们的机会成本非常高。

We have a really high opportunity cost.

你做过哪些事后后悔的事？

What did you do that you wish you hadn't done?

没及时投入改善开发体验，这确实是个失误。

You know, not investing in developer experience fast enough, definitely a problem.

低估了我们的增长速度，这也是个问题。

Underestimating our growth, also a problem.

现在我确保我们做的每一件事，都能支撑起百倍的使用量。

And now I make sure everything we build will scale to 100x the usage.

我以前常说十倍，但后来发现这还不够。

I used to say 10x, then that was not enough.

所以现在我们做的一切都得能支撑百倍的用量。

So now everything needs to scale to 100x.

当你为百倍规模而不是十倍规模做设计时，有什么不同？

What changes when you're building for 100x versus 10x?

不好意思，我可能有点天真。

I'm sorry, I'm very naive.

不，这完全不天真。

No, that's not naive at all.

不一定非得改，但你通常会设定一些限制条件。

It doesn't always have to change, but there are certain limits that you often will put in place.

你就想，嗯，这个方案接下来三个月应该够用了。

Just be like, Yeah, this probably is good enough for the next three months.

比如，嗯，我们先把问题范围限定在十倍左右，然后就能做 X、Y、Z 了。

Like, Yeah, okay, we bound the problem in this way, which is maybe 10x, then we can do x, y, z.

但如果你要面对的是100倍的规模，这种做法可能就不适用了。

But maybe that doesn't hold if you're 100x.

所以有时候你得考虑，尤其是在那些需求波动剧烈的问题上。

And so sometimes you need to think about, I think particularly in problems where there's burstiness to it.

我们的一个产品是表格视图，可以一次性从大量文档和多个单元格中批量提取数据。

So a tabular view is one of our products, you can bulk extract from many documents and many cells.

一万行数据和十万行数据之间的差别非常大，因为系统负载会瞬间飙升。

And there's a very big difference between 10,000 cells and 100,000 cells, just like on the load of the system, because it spikes immediately.

所以这正是那种真正存在差异的系统之一。

And so that's one of those systems where there's actually a difference.

那在这种情况下，当负载差异如此巨大时，你们会怎么做？

And so what do you do in that case, where the spike is so immensely different?

这意味着你们后续需要做出哪些不同的调整？

What does that mean you subsequently do differently?

我们必须从用户体验的角度来思考。

We have to think about the experience.

如果十个人同时做这种疯狂的操作，而我们还想让其他用户有良好的体验。

If 10 people do that crazy thing at the same time, and we still have a bunch of other users that we want to have a good experience.

所以我们得考虑公平排队，也就是说，如果你要处理十万行数据，稍微等一会儿也无妨。

So we need to think about fair queuing basically, which is like, okay, if you're running a 100,000 cells, you're probably okay waiting a bit.

你可以去喝杯咖啡，完全没问题。

You can go grab a coffee and that's fine.

但如果你只处理十行数据，那就得立刻响应，不能拖。

But if you run 10 cells at the same time, those should be really fast.

如果我给你一个特别不公平的条件，比如让你比别人早六个月用上更强大的模型，

If I ask you a really unfair one, if I gave you access to a superior model for six months ahead of anyone else

对。

Mhmm.

或者让你比别人早六个月拥有更优秀的工程师，你更想要哪一个？

Or superior engineers for six months ahead of anyone else, which would you rather have?

当然是工程师。

Engineers, for sure.

因为模型一直在变，一直在进步。

Because the models, they change all the time, they get better all the time.

但如果你有特别出色的工程师，就能打造出一个飞速迭代的系统，那价值可大了。

But if you have really good engineers, you can build a system that exponentially improves, and that's worth a lot more.

你现在知道了哪些事，是希望刚起步时就能明白的？

What do you know now that you wish you'd known when you started day one?

说实话，我要是早知道我们会这么快就扩张就好了，这事儿我当初完全没料到。

Honestly wish I'd known how quickly we were gonna scale because that was the thing that I underestimated all the time.

我真没准备好走这条路。

I don't think I was ready for this journey.

但我很快就适应了，因为每三个月就给我当头一棒。

I became ready really quickly because I got slapped in the face every three months.

你相信人天生就适合公司发展的某个阶段吗？

Do you buy that people are destined for certain stages of companies?

我一直在想，要是我处在你现在的位置，会不会琢磨：我是不是那个能把公司带上市的CTO？

I'm getting very perhaps if I was you now, I'd have in my mind, like, am I the CTO that takes this to public company?

这个问题问得很中肯。

It's a very fair question.

不，我不这么认为。

No, I don't buy that.

对我来说，关键在于我能多快解决这些问题。

I think, to me, it's a question of how quickly can I solve problems?

我是不是那个能最快解决眼下问题的人？

Am I the person that can solve the problems that we have right now the fastest?

还是别人能比我更快地解决？

Or can someone else solve them faster than me?

在Legora，我们有个很好的文化，没人有架子。

We have a great culture in Legora in that no one has any ego.

我跟目前的两位工程总监都说过这话。

I've told this to I currently have two engineering directors.

我当初雇用他们的时候就讲了，如果哪天你觉得你比我更合适，我们就换位，或者我去做别的。

I've told both of them when I hired, if there comes a day when you when I think you'll do better than I will, then we swap or I do something else.

我自己的东西很少，他们也一样，跟头衔或职位没什么挂钩。

I have very little, and they also have very little tied into their title or their role.

我们在这儿是为了做一件大事，这才是最重要的。

We are here to build something huge, and that's the most important thing.

我一直在评估自己的工作表现。

I continuously evaluate myself on my job performance.

如果做得不够好，我会立刻想办法改进。

If I don't do well, I try to rectify that really, really quickly.

到目前为止，我还没错过改进的机会，但也许将来会有那一天。

And I haven't been able to not rectify it yet, but maybe there comes a day.

招聘没有 ego 的顶尖工程师，秘诀是什么？

What's the secret to hiring the best engineers with no ego?

他们好认吗？

And how obvious are they?

如果有 ego，那反而一眼就能看出来。

They're obvious if they have ego.

就连谈薪资和头衔的时候也能看出来。

Even just when you negotiate salaries and titles.

你就能分辨出来。

You you can tell.

我不太了解你的情况。

I don't know about you.

我总是说，优秀的人更在意薪资。

I always say great people want more money.

是的。

Yeah.

他们对头衔没那么在意。

They don't mind so much about the title.

我觉得说得对。

I think that's right.

完全正确。

Absolutely right.

我们招聘的大多数人，连头衔都不怎么提。

Most of the people that we hire, we don't even talk about their title.

我们主要聊的是他们将要攻克的那些难题。

We talk about the the difficult problems that they're gonna work on.

你们在斯德哥尔摩一起工作

How important is it

这件事有多重要？

that you're together in Stockholm?

这对快速推进项目非常重要。

It's been very important for running really fast.

我是说，我们之前聊过交接成本的问题。

I mean, this is we talked about the handover cost.

对。

Yeah.

如果你安排产品经理、设计师和工程师坐在一起办公，几乎可以省去交接环节。

If you have a PM and a designer and an engineer and they just sit together, you can almost not even have the handover.

你可以

You can

直接一起扑在问题上，三个人一块儿干，很快就解决了。

just be like, run at this problem and and and do it together, the three of you, then it's done.

但如果把他们隔开，中间还要交接，效率就大打折扣了。

But if you have them siloed and there's handover in between, you lose so much efficiency.

开个Zoom会议，但根本说不清楚。

Jump on a Zoom call, lacking clarity.

对。

Yeah.

这份文档写得不够清楚。

This doc is not well written enough.

你得再开一次会，然后还要改三轮文档，接着别人在别处看到后随便留个评论，你又得专门讨论这个评论。

You have to do another meeting, and then you have to do three reviews of the document, and then someone else has an opinion that sees it somewhere and writes a comment somewhere, and then you have to talk about that.

那你怎么平衡这一点？毕竟顶尖工程师都喜欢远程工作。

How do you factor that into, well, how the best engineers like to be remote?

我们对自己是谁、不是谁有很明确的立场。

Well, we're very opinionated about who we are and who we aren't.

如果你是个优秀的工程师，又想远程工作，那你很可能也喜欢处理那些高度独立的问题。

If you're a great engineer and you want to be remote, then you probably also want to work on very isolated problems.

这本身没问题。

That can be fine.

我们也许会有这样的人，也可能会有，但眼下我们并不需要他们。

We'll we'll we probably have those, and we probably will have those, but they're not for us right now.

我们更想找那些愿意和别人一起解决同样问题的人。

We'd rather find the people that wanna solve the same problems with other people.

到两年后，或者2027年底，你们会有多少工程师？

How many engineers will you have in two years or by the end of twenty twenty seven?

你们现在有80人了。

You're 80 today.

是的。

Yeah.

我说个数字，可能偏低了。

I'm gonna say a number that's too low.

我会在2027年12月31日发个WhatsApp给你。

I'm gonna WhatsApp it to you on the 12/31/2027.

你猜错了？

Were you wrong?

答案肯定是‘对’。

Answer will be yes.

我不确定。

I don't know.

三百？

300?

两百？

200?

我这边是203人。

I 203 different.

你得在上面写上你的名字。

You gotta put your name on one.

如果非得我选，我想选个更低的数。

If I have to put my I want to say the lower number.

那就定270吧。

Let's say 270.

270。

270.

好。

Okay.

那我们还得再加190。

So we're gonna have a 190 more.

对。

Yeah.

你能只靠再多190就留住顶尖人才吗？

Can you retain a only talent with a 190 more?

这相当于每周多加了两个半。

That's essentially adding two and a half a week.

这能做到吗？

Is that possible?

如果这是线性增长的话。

If it's if it's linear.

我觉得可以。

I think so.

我宁愿少报一点数字，但凑齐八个高手，也不愿凑够数字却全是凑数的。

I'd rather miss my number and have eight players than hit it with b players.

一旦你用了别人不信任的人，或者团队不信任的人，那些顶尖人才就不会留下来。

As soon as you have people that you don't trust or that the team doesn't trust, the a players won't stick around.

你现在买公司比我还做播客多。

You're buying more companies than I'm doing podcasts these days.

你笑是因为我说的是实话。

And you're laughing because it's true.

这不对。

It's not true.

这不对。

It's not true.

我这个人比较敏感。

I'm a sensitive

投资者。我的

investor My

我想问你，在现在这种情况里，你是不是非得收购公司，才能真正吸引顶尖人才？

question to you is, do you have to buy companies to get the truly, truly a talent in a lot of cases today?

我不觉得。

I don't

我觉得不用，但收购更快。

think so, but it's faster.

因为如果你找到一个特别优秀的创始人，他本身就能吸引来顶尖的人才。

Cause if you find a really good person who a really good founder, they're able to attract really good talent.

所以你有一小群五个人，都是顶尖人才，如果你每周得招两个，那一周内凑齐五个就快多了。

And so you have a small group of five people that are just a talent, and then you get five in one week, you know, if you have to get two every week.

这比去大公司，甚至初创公司，一个个说服他们跳槽要快得多。

And that's much faster than going to all the big companies or even the startups and trying to convince them to lure come over.

而且，如果是一家只有五到八人的小公司，大家更愿意彼此共事。

People also want like, if if you have a small startup of five, eight people, they want to work with each other.

那你们是直接放弃他们的代码库吗？还是说大多数情况下都是完全收购？

Do you just shed their code bases then, or is it like pure aqua hives in a lot of cases?

两种情况都有。

It it can be both.

如果他们之前做过相关领域的东西，或者技术方向相近，哪怕不相关但技术相似，我们也会吸收他们的经验，重新整合到Legora里。

If they've worked on adjacent things or things in a similar field or even unrelated but similar technology, we'll take all their learnings and we might rebuild it into Legora.

我觉得大多数情况都是这样。

I think that's what happens in most cases.

但他们最终会完全融入我们的团队。

But they become fully embedded into the team.

他们都是Legora的员工，专注在Legora的代码库上工作，同时也会带入一些之前的经验。

They're all Legorians working on their Legora code base, and then they might bring some learnings.

整合起来难吗？

Is integration hard?

如果你招的是没什么架子的人，其实整合起来意外地简单。

It's surprisingly easy if you hire people with low ego.

如果你招到五个能力出众、不在乎头衔和职位高低、只想解决问题的工程师，整合起来就特别顺。

If you if you get five great engineers that don't care about their titles or where they sit in the org chart, that just wanna solve problems, it's surprisingly easy to integrate.

当你在招聘工程师时犯了错，当时没注意到哪些信号，现在回想起来希望当时能看清？

When you've got engineering hires wrong, what did you not see that you wish you had seen?

如果出了问题，其实得从我自身找原因，我这里稍微反思一下。

When this goes wrong, it's actually because of my I'm going be a little bit introspective here.

可能是因为我之前没带过这么大的工程团队，经验还不够。

It's probably because of my own I don't have I've not run an engineering team this big before.

所以我有时候不敢坚定地指出，那些比我资历深的人，他们的看法未必是对的。

And so I start downing, I'm not confident enough in saying this person who's more senior than me has seen more than me is wrong.

确实发生过一两次，遇到特别资深的人。

It's happened once or twice when there's a very, very senior person.

我们聊的时候，他们总是讲组织建设、架构设计，还有他们对这些事的思考方式。

We talk, and they talk about all this sort of org building and org design and, like, how they think about all this stuff.

但我感觉哪里不太对劲。

And I sense that something's wrong.

其实我平时心里都有数，可最后还是说服自己，人家可能确实比我懂。

And I kinda know that all the time, but I in the end, I end up convincing myself that, no, they probably know more than me.

或者觉得人家已经摸清门道了，诸如此类。

Or, like, they they figured it out or whatever.

两周、四周、六周过去，你慢慢就发现，人家其实并没有。

Two weeks in, four weeks in, six weeks in, you start to figure out they didn't.

你一般多久能判断出招错人了？

How fast do you know if you've made a miss hire?

一个月内。

A month.

那时候你就明白了。

Then you know.

然后你会给他们非常直接的反馈。

And then you give them really strong feedback.

我一般两周后就会给出非常直接的反馈。

I give really strong feedback after two weeks.

你说的‘非常直接的反馈’具体是什么意思，杰克？

What does really strong feedback mean, Jake?

意思就是：如果你不改，你就留不下来。

Really strong means you're not gonna stay if you don't change this.

有人从‘你不改就留不下来’这种反馈里翻身过来吗？

Has anyone ever recovered from a you're not gonna stay if you don't change this?

没有。

No.

但他们得有这个机会。

But they need to get the chance.

如果他们改了，就会留下来。

And if they do, they stay.

现在最难招聘的职位是什么？

What is the hardest role to hire for today?

这是个好问题。

This is a great question.

全都很难。

All of them.

不是。

No.

我觉得招聘高级管理层特别困难。

I think senior management is extremely difficult to hire for.

高级管理层，是指横向的高级管理层吗？

Senior management, a horizontal senior management?

工程总监。

Engineering directors.

也许这一直都不容易。

Maybe that's always been difficult.

我们现在的管理者几乎都是纯技术背景的人。

We only have really technical people also being managers.

但凡见过大规模运作的人，通常早就不再写代码了。

And so anyone who's seen scale typically also is no longer technical.

我们还留着经理这个职位吗？

Do we still have managers?

我的意思是，我有个好朋友杰森，他在Sachi's工作，LinkedIn上经常提到他们的团队，直接把经理裁了。

And what I mean by that is one of my dear friends, Jason, I'm here from Sachi's, on LinkedIn who talks about their team, fire them.

一上来就裁掉。

Fire them straight away.

我们不需要那种管经理、经理再管经理的层级结构。

We don't want managers who manage other managers who manage other managers.

如果你不能全栈开发，那就别留下了，拿上遣散费走人吧。

If you can't do full stack, get out, pick up your severance and go away.

我们还需要高级经理吗？

Do we still want senior managers?

你可以组建一支顶级工程师团队，他们什么都能做，根本不需要人管，尤其是当他们很清楚自己要达成什么目标的时候，比如Codex团队就是这样。

Well, you can build a company of super senior engineers that can do everything, and you probably don't need to manage them at all, especially if there's really strong if they know what they're trying to achieve, the Codex team, for example.

他们都知道自己在做什么产品。

Like, they all know what they're building.

他们直接冲上去干就行，根本不需要别人来夸他们做得好。

They can just, like, run at it, and they don't need anyone to tell them that they're doing well.

但如果你的产品更复杂，发展方向很多，得不断做优先级排序，而且有一整支工程师团队，那我们现在的工程团队结构是相对小的，比如六个人，一个产品经理加一个工程经理。

But if you have a more complex product that can go in many directions and you have to do constant prioritization and you have a suite of engineers and a team of engineers so the way that we have engineering teams is relatively small teams, let's say six people, PM and an engineering manager.

这个工程经理技术非常强，大部分时间都在写代码。

The engineering manager is super technical, spends most of their time coding.

他们可不是那种互相搀扶、唱歌跳舞的类型。

And they're not like people hold each other's hands and sing songs.

但还是需要有个人对团队的整体健康负责。

But it's still important that I have someone that's accountable to the team health.

大家的工作表现都不错吧？

Are people doing good jobs?

大家干得开心吗？

Are people having fun?

我没法挨个去评判每个人。

I can't walk around and judge everyone.

你知道的，他们是不是干得还行？

You know, are they are they doing well?

所以我觉得必须有个人对团队负责，我们就是这样运作的。

And so I think it's important to have someone who's accountable, and that's how we run it.

对吧？

Right?

他们自己定路线图。

They decide their own road map.

他们就像一个小创业团队，但总有一个人担责。

They're their own little startup, but someone is one person is accountable.

每个新功能都有Max参与吗？

Is Max on every new product feature?

大的功能，有他参与。

On big ones, yes.

小的功能，就没有。

On small ones, no.

是这样吗？

Is that right?

我们这么操作效果不错。

It's worked for us.

Max的时间很宝贵，他是个出色的销售，这点你应该也知道。

His time Max is an amazing salesman, as you probably know.

所以他把时间花在销售上，还有产品愿景和关键的产品事务上。

And so I think Max spends his time on that, and he spends his time on product vision and the important product things.

所以主要是重大发布和重要事项他才会参与。

So big launches, big things here.