本集简介
双语字幕
仅展示文本字幕，不包含中文音频；想边听边看，请使用 Bayt 播客 App。
让我感到有趣的是，在过去二十年里，我们在编程范式上的实验其实并不多。
It's interesting to me that we haven't experimented in some sense that much with the paradigm of programming over the past twenty years.
是的。
Yes.
把它们结合起来，你现在就能在单个细胞的层面上实现读取、思考和写入的能力。
You put those together, you now have the ability to, again, at the kind of level of the individual cell, to read, think, and to write.
这开始真正像一种新的图灵循环，并具有自身的某种完备性。
And this starts to really feel like a new kind of Turing loop and to have its own sort of completeness.
我认为，正是正确的API设计和抽象设计，最终带来了显著的商业影响。
I think that's a case where the right API design, the right abstraction design ended up having just quite significant business ramifications.
我认为，将开发环境视为一个整体而非仅仅是一个文本编辑器，这个基本理念是正确的，这也是我希望回归的方向。
I think the basic idea of as development environment and not just text editor is really the right idea, and that's the thing I want to see a return to.
帕特里克·科利森用Smalltalk编写了他的第一个创业项目。
Patrick Collison wrote his first startup in Smalltalk.
它的开发环境让他能够在处理请求的过程中修复错误、检查堆栈帧并恢复执行。
Its development environment let him fix errors mid request, inspect stack frames, and resume execution.
他更看重这一点，而不是选择一种主流语言。
And he wanted that more than he wanted a mainstream language.
他和兄弟俩为Stripe选择了Ruby和MongoDB。
He and his brother chose Ruby and MongoDB for Stripe instead.
这些决策至今仍定义着这家公司，即使在十五年零四十四秒的年停机时间之后。
Those decisions still define the company fifteen years and forty four seconds of annual downtime later.
现在，Stripe正在推出第二代API，重新编写2010年设计的核心抽象。
Now Stripe is shipping v two APIs, rewriting core abstractions first designed in 2010.
这花了好几年时间。
It's taken years.
定义新API是相对简单的部分。
Defining the new APIs is the easy part.
让它们与所有基于旧系统的现有内容协同工作，正如科利森所说，更像是一次指令集迁移，而不是产品发布。
Making them work alongside everything already built on the old ones is, as Colson put it, more like an instruction set migration than a product launch.
这场对话此前曾在Cursor的播客中播出，还探讨了为什么AI尚未推动产品TV数据、当今的开发环境可以从Lisp机器中学到什么，以及科利森在ARC关于生物学基础模型方面的工作。
This conversation previously aired on Cursor's podcast also gets into why AI hasn't moved product TV numbers, what today's dev environment could steal from Lisp machines, and Collison's work at ARC on foundational models for biology.
Cursor的首席执行官迈克尔·特鲁尔与Stripe的首席执行官帕特里克·科利森进行了对话。
Michael Truel, CEO of Cursor, sits down with Patrick Collison, CEO of Stripe.
很高兴你能来。
Well, it's great to have you.
谢谢你的谢谢
Thanks for Thank
感谢你莅临。
you for being here.
谢谢你们邀请我。
Thanks for having me.
很高兴
Great to
在这里。
be here.
是的。
Yes.
我听说你第一家初创公司是用Smalltalk写的。
I've heard that your first startup was written in small talk.
请解释一下。
Please explain.
我不知道有什么好解释的。
I don't know what there is to explain.
它是最棒的编程语言。
It's the best programming language.
嗯，在那之前我一直在用Lisp和Lisp的衍生语言工作。
Well, I had I'd worked on Lisp and Lisp dialect before that.
实际上，我还开发过Lisp的Web框架。
And actually, I'd worked on Lisp web frameworks.
当我们打算打造第一家初创公司时，我们最初是用Rails来实现的。
And when we went to build our first startup, we first wrote it in first implemented it in Rails.
但后来我发现，相比Lisp，这个开发过程相当令人沮丧。
And then I found, compared to Lisp, that development process kind of frustrating.
而且，我的意思是，我们不需要深入所有细节，但我认为基于延续的Web框架才是实现Web应用的正确方式。
And, I mean, we don't need get into full details, but I thought that continuation based web frameworks were really the right way to implement web applications.
Ruby中根本没有延续，也没有基于延续的框架。
There were no continuations in there's no continuation based framework in Ruby.
于是我开始四处寻找。
And I was kind of searching around.
我发现刚有人用Smalltalk写了一个不错的框架。
I found that there was a good one that had just been written in Smalltalk.
所以我决定稍微玩一玩。
And so I decided to play with it a little bit.
然后我发现，Smalltalk实际上是一个极其有趣的开发环境，它具备了我非常欣赏的Lisp的许多特性，比如一个完全交互式的环境，带有专业的调试器，让你可以在处理某个Web请求、甚至深入某个堆栈跟踪时，直接编辑代码。
And then I found that Smalltalk is actually this extremely interesting development environment that had a lot of the aspects of Lisp that I'd really appreciated there, like, you know, a fully interactive environment with a proper debugger so that you can edit the code while, you know, in the middle of some web request or, you know, deep in some stack trace or something.
比如，当你遇到某个Web请求的错误时，可以修改代码修复错误，然后从堆栈的更高层继续执行，让整个Web请求顺利完成。
And, you know, you could, for example, encounter an error with some web request, edit the code to fix the error, and then resume higher up in the stack such that the entire web request would just complete.
因此，你不需要经历那种令人烦恼的反馈循环——添加日志语句、进行二分搜索、找到问题，最终部署修复版本，这个过程可能要花上一个小时；相反，你可以直接检查堆栈帧，看到哪个变量的值错了，修正它，跳回上层，点击继续，整个过程就顺利运行了。
And so rather than this kind of annoying feedback loop of having to add some log statements and, like, do this binary search, like, find the problem and eventually, like, deploy, you know, a fixed version, you know, a process that could take an hour, you could just, like, literally inspect the stack frame, see which variable has the wrong value, fix it, like, you know, jump back up, hit proceed, and have the whole thing work.
总之，关键是，在寻找这种基于延续的Web框架时，我意识到Smalltalk整体上拥有比Ruby、比几乎所有其他主流编程语言更强大的开发环境。
Anyway, the point is, in the hunt for this continuation based web framework, realized that Smalltalk, in general, had just a much more powerful development environment as compared to Ruby slash as compared to basically every other mainstream programming language.
因此我们决定使用它来开发公司项目，回头来看，我不确定这是否是个糟糕的决定。
And so we we decided to, yeah, use it for the company, which in hindsight was I mean, I don't know if it was a terrible decision or not.
我认为有人会觉得这是个糟糕的决定，是因为可能很难招聘到人，也很难扩展，等等。
The reason I think one would think it would be terrible is that it would be, you know, hard to hire people and hard to scale and, you know, whatever.
但招聘其实并不难，或者说，根本没人懂它，但教他们却很容易。
It wasn't hard to hire people or rather nobody knew it, it was easy to teach them.
公司里的人在加入之前就知道吗？
The company Did they know before they joined?
不知道。
No.
不知道。
No.
但他们学得非常快。
But they learned really quickly.
然后你有聪明人去学习语言，所以我真的不认为这是不使用非主流语言的理由。
And then you have smart people learn languages So really I don't I don't think that's really a reason not to use a non mainstream language.
公司没有成功，我认为是出于无关的原因。
The company didn't work, I think, for unrelated reasons.
我觉得只是这个想法不够强大。
I think just the idea wasn't that strong.
但我们为Stripe选择了Ruby。
But we also chose Ruby for Stripe.
所以我不确定。
So I don't know.
我觉得可能实际获得的收益没有我预期的那么大。
I think maybe the gains were not quite as large as I'd hoped.
你们对Smalltalk的热情，收购这家初创公司的团队也认同吗？
And was your small talk enthusiasm shared by the acquirers of the startup?
当时的状况是怎样的？有没有一种情况，管理层一无所知，却把一套Smalltalk代码库强加给一群毫不知情的开发者，然后他们只好硬着头皮上？
And what was the dynamic or, you know, was there, like, this blissfully ignorant management that foisted this Smalltalk codebase on a bunch of unsuspecting developers that were then kind of, like, piling over, you know?
或者，是的，程序员和管理层之间的关系是怎样的？那个Smalltalk代码库后来怎么样了？
Or, yeah, what was the dynamic between the programmers' management sort of What happened to that small talk codebase?
是的，对。
Yeah, yeah.
它还在某个地方保留着吗？
Does it still live on somewhere?
我希望不是，而且我有99%的把握答案是否定的。
I wish, and I'm 99% sure the answer to that is no.
收购我们的公司主要看重的是人才，所以代码库本身并不重要。
The company that acquired us was mainly a talent acquisition, so, yeah, the codebase itself was less relevant.
好的。
Okay.
然后它就立刻被彻底删除了吗？
And it was immediately sort of just gone?
是的。
Yeah.
好的。
Okay.
明白了。
Gotcha.
我也听说你最早的一个编程项目是用Lisp编写的一个AI机器人。
I've also heard that one of your earliest programming projects was working on an AI bot written in Lisp.
没错。
True.
它是一个MSN的客户端。
And it was something like a It was a client for MSN.
嗯，是的。
Uh-huh.
是的。
Yeah.
我知道你从哪儿听说的，但确实如此。
I know where you found that, but that is true.
我还听说，你当时因为想让这个AI通过图灵测试而变得特别着迷。
And I heard that you got kind of nerds tonight by the idea of trying to get it to pass the Turing test.
是的。
Yes.
我很好奇，你错过了什么？
And I'm curious, what did you miss?
你知道吗，为什么你没有做出ChatGPT？
You know, why didn't you make ChatGPT?
也许更认真地说一点，当时它是怎么运作的？使用的神经网络是什么样的？有没有考虑过采用我们今天技术的前身？
And, well, maybe a little bit more seriously, how did it work, what was seeded neural networks at the time, and did consider using any antecedents to the technology we use today?
对。
Yeah.
所以，那就是那个项目。
So so that was the project.
它是一个小玩意，使用了当时非常流行的MSN Messenger。
It was a little critter that used MSN Messenger, which was, you know, all the rage at the time.
我想这表明了某种特定类型的沉积层，存在于即时通讯解决方案的发展历程中，可能也暴露了我的年龄。
I guess that puts that that's, like, maybe a specific kind of, you know, sedimentary layer in the, you know, chronology of different instant messaging solutions and probably dates me quite precisely.
它只是一个非常简单的贝叶斯下一个词预测器。
And it was a really simple Bayesian next word predictor.
其实那里并没有什么特别复杂的东西。
Like, there was nothing really that sophisticated there.
如果说有什么稍微复杂一点的地方，那就是它的训练数据来自它自己在MSN Messenger中的对话，而不是一般的文本语料库。
To the extent there was anything sophisticated, it was maybe that it used Like, the the training data was the conversations itch itself had in MSN Messenger rather than kind of general text corpora.
而且，它运行得还算不错。
And, you know, it it it worked reasonably well.
而且，更高级的版本会往前看几个词，诸如此类。
And, you know, it better versions looked a couple of words ahead and and, you know, what have you.
我的意思是，它从未真正通过图灵测试，也就是说，人们并没有真正产生怀疑。
And a I mean, it never really passed the Turing test where, you know, people have actual suspicion.
他们试图运用这种辨别能力。
They're trying to, you exercise this this discernment.
但它确实通过了某种较弱版本的图灵测试，当时人们根本没有察觉。
But it certainly passed some weaker version of Turing test where, you know, they they were unsuspecting.
而且，人们最终和它进行了相当长的对话。
And, you know, people ended up having quite quite lengthy conversations with it.
而这也正是我接触到 Lisp 的方式。
It and that was part of how I discovered Lisp.
我记得彼得·诺维格的《人工智能编程范式》是一本对我影响深远的书，里面有许多有趣的方法。
I remember Paradigms of AI Programming by Peter Norvig being a really formative book and had, you know, all sorts of interesting approaches there.
我几乎可以肯定，书中没有涉及神经网络的内容。
It didn't have anything on neural networks, I'm almost sure.
我确实读过一些马文·明斯基的东西，比如《心智社会》之类的，是的。
And I never I mean, I'd read some Marvin Minsky stuff, Society of the Mind or whatever Yeah.
关于神经网络，但我从未认真研究过它们。
On neural nets, but I never really seriously looked at them.
我实际上对遗传算法做了大量实验。
I actually experimented a lot with genetic algorithms.
它们更实用，毕竟可以在你自己的电脑上运行。
They were, I guess, more practical on, you know, your own computer.
像训练神经网络这样的事情需要大量的计算资源。
Like, takes a lot of computer training neural nets.
所以我大量地实验了遗传算法。
So I experimented lot with genetic algorithms.
实际上，我使用Vorzhak键盘布局，因为相比QWERTY，它打字更舒服。
And actually, I use Vorzhak at the keyboard layout because it's more comfortable to type on than QWERTY.
我哥哥约翰也用，所以没人能用我们的电脑。
As does John, my brother, so no one can ever use our computers.
但我写了一个遗传算法优化器，来找出最优的键盘布局。
But I wrote a genetic, I don't know, optimizer to to figure out what the optimal keyboard layout was.
结果发现，用遗传方法得出的布局基本上就是Vorzac。
And it turns out it is in fact basically Vorzac using a a genetic approach.
所以，是的，我深入探索了这个方向，但从未真正玩过神经网络。
So, yeah, I went deep down that rabbit hole, but I never really played with neural networks.
我想这就是为什么，你知道，还有另外大概七十个原因，让我没有创造出ChatGPT。
And I guess that's why, you know, that, but probably seven other 70 other reasons is why, you know, I did not create ChatGPT.
有一段你接受采访时的旧视频，我想是在你出售Automatic公司之后。
There is an old video of you being interviewed, I think, after selling Automatic
嗯。
Mhmm.
在那段视频里，有人问你关于Smalltalk的问题。
Where you're asked about Smalltalk.
正是在那里，我发现了那种奇怪的、当时人们问你为什么喜欢它的情况，而你提到的一点是，你喜欢Smalltalk这类语言的一些特性。
That's where I found kind of that weird weird I think at the time people asked you why, and one of the things you said was, I mean, you liked some features about Smalltalk, style languages.
你还预测过——我想那大概是2008年左右——主流的C风格编程语言会越来越多地借鉴这些旧式编程语言的设计理念。
And you predicted, and I think that this was circa maybe 2008 or something like that, that the mainline C style programming languages would increasingly borrow ideas from these older programming languages.
而事实确实如此，JavaScript和Python生态系统就是这样发展的。
And that kind of has been the case in the JavaScript Python ecosystems.
是的。
Yeah.
你认为在一些更古老、更小众的编程语言中，是否隐藏着一些被低估的想法，值得主流语言借鉴？
Do you think that there are any underrated ideas buried away in kind of older, more esoteric programming languages that should be borrowed by the mainline?
是的。
Yeah.
它一直
It's been
有趣的是，很多想法已经被JavaScript生态系统借鉴了，而且是以一种奇怪的方式，比如Web Inspector，是的。
it's been interesting how a lot of the ideas have been kind of have been borrowed by the JavaScript ecosystem and in a strange way, like, the Web Inspector Yeah.
你拥有这样一个在我看来是某种意义上最丰富的运行时环境，人们普遍都能接触到。
Where you have this I mean, that that's one of the richest run times in some sense that people have, you know, general general exposure to.
我认为JavaScript没有第一类的栈帧。
I don't think JavaScript has first class stack frames.
嗯。
Mhmm.
也许有一些奇怪的扩展可以实现这一点，但ECMAScript肯定没有，我很确定。
Maybe there's some weird extension or something where you can get that, but it but, you know, ECMAScript doesn't have that, I'm pretty sure.
第一类栈帧实际上能让你因为一些显而易见的原因做很多其他事情。
First class stack frames actually let you do a lot of other things for kind of obvious reasons.
所以也许这个想法太具体了。
So maybe that's very that's kind of too specific.
我的意思是，我认为这个理念——也许这就是光标所要成为的东西。
I mean, I think the idea of and and maybe this is what cursor becomes.
我认为将开发环境视为一个整体，而不仅仅是一个文本编辑器，这个想法才是正确的。
I think the basic idea of as development environment and not just text editor is really the right idea.
这正是我想看到回归的东西。
That's the thing I want to see a return to.
这正是Lisp机器和这一类系统所具备的。
That's the thing that the Lisp machines had and the genre.
这正是Mathematica在某种程度上所具备的。
That's the thing that, to some extent, Mathematica has.
这正是Smalltalk所具备的。
That's the thing that Smalltalk has.
我认为，我们最终拥有了运行时、文本编辑和代码环境之间存在如此巨大分离的开发环境，这真是一个巨大的错误。
And I think it's just such a mistake that we have ended up with development environments where there is such a separation between the runtime and the text editing and the environment in which the code Mhmm.
我的意思是，确实如此。
I mean Yep.
运行时和代码运行的地方可以相同，也可以不同。
Well, the runtime and the place where the code runs can be the same or different.
但这里可能涉及三种稍微不同的概念。
But there are kind of three maybe slightly conceptually different things.
在这三种环境中，它们都可以共存于同一个地方。
And in those three environments, they can all coexist in the same place.
我喜欢——直到今天，我仍然大量使用Mathematica，并不是因为我正在做某种特别深奥的符号数学，而是因为它是一个更高效的开发环境。
And I like, I mean, still to this day, I use Mathematica a lot, not because I'm doing some particularly arcane, you know, symbolic mathematics, but because it's just a more efficient development environment.
现在，有了大语言模型，这一点可能没那么明显了，因为Mathematica并不支持类似Cursor的提示式开发。
Now, that's maybe a bit less true with LLMs because the Mathematica, you know, the Mathematica does not support cursor style prompted development.
但我认为，这才是我希望其他人能借鉴的核心理念。
But that, I think, is the core idea that I wish others would borrow.
而 VS Code 在某种程度上已经朝这个方向迈出了一步，但我认为我们还能走得更远，我真的希望看到的是，当我把鼠标悬停在一行代码上时，能看到关于这段代码、这个函数或任何相关内容的运行时性能分析信息。
And Versus Code has been a step to some extent slightly in that direction, but I think we could take it way further and it'd be really I mean, what I'd love to see, for example, is when I hover over a line of code, I would like to see, you know, profiling information about, you know, just the runtime characteristics of that code or that function or whatever.
我希望看到日志和错误信息直接叠加显示出来。
I would like to see logging and error information overlaid.
当我把鼠标悬停在一个变量上时，我想看到它在生产环境中最常见的取值。
When I hover over a variable, I would like to see how like, the most common values that it takes on in production.
这些类型的深度、丰富的集成。
These kinds of, like, just rich, deep integrations.
你是不是也喜欢《基于原则的创新》这类内容？
Are you a fan of Inventing on Principle and those
是的，没错。
Yes, yes.
我觉得布雷特有点过于偏向了。
I think Brett leans too much.
我的意思是，我非常欣赏布雷特。
I mean, a huge fan of Brett.
他实在是太核心了，你有没有
Just he's such an integral Have you
去过Dynamic Land吗？
been to Dynamic Land?
是的。
Yes.
好的。
Okay.
对。
Yep.
而且支持过它。
And supported it.
所以她也是Brett的粉丝。
So she's a fan of Brett.
我有所不同的地方，或者说，不太能引起我共鸣的是，Brett非常推崇用图形和视觉方式来表现各种现象。
The place that I've, I mean, differed or at least that just resonates with me, you know, somewhat less is Brett is really into this idea of, obviously, of graphical and visual representations for phenomena.
我认为这种做法在某些领域非常有效，比如他所展示的一些动态系统，但对于像Stripe的各个部分这样的任意系统，通常很难找到如此有用的、连续的空间表示。
And I think that works very well in certain domains, like the kind of dynamical systems that, you know, he has demonstrated some of the ideas with, I think it's often very hard to find such useful spatial, continuous representations for arbitrary systems, like for various parts of Stripe.
我不太确定那会是什么，即使我们能找到，也不确定它到底会有多大的用处。
I'm not quite sure what that would be, and I'm not sure, even if we could find it, you know, exactly how useful it would be.
也许只是我个人的问题。
Maybe it's just me.
我更倾向于以符号化和词汇化的方式进行推理，而不是视觉化和图形化的方式。
I reason much more kind of symbolically and sort of lexically than I do visually and graphically.
这可能只是个人偏好，但我也不确定。
It might just be personal preference, but I don't know.
他所参与的这种范式突破，我认为非常令人钦佩。
The kind of paradigm breaking that he's been engaged in, I think, is hugely admirable.
你打算打造一个真正一体化的集成开发环境吗？
Are you going to make a truly integrated development environment?
所以我们是
So we are
正在探索一些想法，让AI逐渐将时间作为后台来运行代码并响应输出。
playing with ideas around letting the AI increasingly take time into the background to run its code and react to the output.
嗯哼。
Mhmm.
我们认为这一切应该能很好地协同工作。
And we think that this should all work well together.
比如，我们非常关注输入、速度和控制，我们认为这对AI来说至关重要，要让程序员对一切拥有控制权，理解AI生成的所有内容，同时提供极快的迭代循环。
Like, you know, we focused a ton on inflow, speed, and control, and we think that that's really, really important for AI is, you know, to give programmers the control over everything, have them understand everything the AI is producing, also to give them really, really fast iteration loops.
程序员讨厌等待。
Programmers hate waiting for things.
但在某些情况下，我们现在似乎可以告诉AI稍作思考，然后回来告诉你，让API更像与另一个人交互的API。
But in some cases, we think it's now becoming possible to go tell the AI to think for a bit and then come back to you and have the API be a little bit more like the API with another human being.
是的。
Yep.
我们认为这一切都应该很好地协同工作。
And we think you want that all to work well together.
所以，AI 可以回来时带着 70% 的成果，你可以快速把它调到前台，进行处理，然后再把它放回后台。
So, you know, the AI can come back to you with 70% of something, and then you can bring it into the foreground really quickly, work with it, and then spin it back off to the background.
而且，为了让 AI 在后台长时间思考变得有意义，你必须运行代码并根据结果做出反应。
And, you know, as part of having the AI spend a bunch of time thinking in the background, to make that thinking useful, you kind of needed to run the code and then react to it.
否则，你只是盯着一个逐渐停滞的东西，继续空想。
Or else you're just kind of staring at the thing that eroded and thinking more.
也许我应该成为那个回答问题的人，而不是一直提问的人。
Maybe I'm I'm to be the one answering the questions rather than asking them.
但你觉得五年后，我在 Cursor 里主要看的会是代码，还是别的东西？
But do you think in five years, the main thing that I'm looking at in cursor will be code or something else?
我觉得可能会是别的东西。
I think it might be something else.
我认为，现在正发生巨大的简化，但当你定义软件是什么时，其中包含逻辑部分，这是工程师花大量时间设计软件具体运作方式的部分。
I think that, there are, big, big, big simplification, but kind of when you're defining what a piece of software is, there's, like, the, logic component, which is what engineers spend a lot of time on, designing exactly how the software works.
此外，对于终端用户应用和带有图形界面的东西，还存在一个视觉组件。
There's also, for end user applications and things that have GUIs, there's, like, this visual component.
我认为，也许会是我们，也许会是其他人。
And I think that there is, you know, maybe it's going be us, maybe it's going be someone else.
未来会有一种情况，你与AI的互动方式不再那么像有一个人类助手在替你分派任务，或在你身后预测你接下来要做的事。
There is a future version of the world where the way you interact with AI is a little bit less like, you know, it's a human helper that you're delegating work to or looking over your shoulder predicting the next set of things you're going do.
而更像是编译器或解释器技术的一种进步。
And instead, it's a little bit more of an advance in compiler or interpreter technology.
这可能会引领我们进入一个编程语言真正发生变化的世界。
And it could lead you to a world where programming languages actually change.
编程语言可能会变得不那么正式。
And they can start to get a little bit less formal.
编程语言可能会变得更加抽象。
They can start to get a little bit higher level.
编程语言会更关注你想要什么，而不是你如何实现它。
They can start to be a little bit more about, what you want and a little bit less about how you do it.
我认为，这看起来未必会像一个Google文档。
And I think that it won't look like a Google Doc necessarily.
我认为编程中有些东西值得保留，比如将逻辑命名后在多个地方复用。
Think that there are things you want to keep around from programming, like the, you know, the naming of logic somewhere and then using that in a bunch of other places.
我认为还有另一个方面，就是软件外观的视觉呈现。
I think that there's also this other element, too, of the visuals of, you what a piece of software looks like.
我觉得，无论是我们还是其他工具，未来直接操作界面可能会在其中发挥更大的作用。
And I think, you know, maybe us, maybe some other tool, but I think there's a world where kind of direct manipulation of the UI starts to play a little bit more into it.
是的。
Yeah.
但这些都是一些比较遥远的实验性想法。
But these are kind of far flung experimental ideas.
而且
And
总的来说，我想说，虽然这并不糟糕，但让我觉得有趣的是，过去二十年我们对编程范式的探索其实并不多。
In general, I will say, and, yeah, it's not terrible, but I feel like there it's interesting to me that we haven't experimented in some sense that much with the paradigm of programming over the past twenty years.
对。
Yes.
我们在这里讨论的许多东西都源自七八十年代。
And many of things we're discussing here are from the 80s or the 70s.
当然，如今的开发者数量比以往任何时候都要多得多。
And, you know, there are way more developers, obviously, now than there ever have been in the past.
但在某种意义上，这种实验的范围似乎并没有那么广泛。
But in some sense, the sort of the aperture of experimentation there feels like it's really not that wide.
JavaScript 生态系统以及其他几个生态系统确实做了一些很酷的事情。
And, again, the JavaScript ecosystem and a couple of others have done some cool things.
在语言层面，Rust、Go 等语言也进行了大量实验。
And there's been a lot of, you know, experimentation at the language level with Rust and Go and everything else.
但在开发环境层面，我不知道为什么，也许是因为现在太难太复杂了，但实际进展比我预期的要少。
But at the kind of the development environment level, I don't I don't know why it is, but maybe it's just too hard and complicated now, but there's been less than I would have expected.
是的。
Yeah.
我同意。
I agree.
而且我认为
And I think
也许这有助于某事
Maybe this is this helps Something
我们正在做的东西。
we're working on.
是的。
Yeah.
也许这在某种程度上解释了 Cursor 的成功，因为你们是最近一段时间以来真正认真对待这一点的首批人。
Maybe this explains Cursor's success to some extent where, you know, you guys are the first people to really take it seriously in quite a while.
嗯，我的意思是，是的，我认为我们也受益于‘为什么是现在’这一点，比如现在有了这套全新的、很棒的颜料可以用来创作。
Well, I I mean, yeah, I think we also benefit a lot from the why now of, like, there's now this, you know, great new color to paint with or set of colors to paint with.
我认为，围绕编程语言还存在大量的锁定效应，因为编程语言本质上是程序员用来精确定义计算机如何运行的复杂用户界面。
I think also there's just a ton of lock in with programming languages around both the neurons in your head of, like, programming languages are kind of complex UI for programmers to define exactly how the computer should function.
所以，人们学习这些语言，而这些语言确实如此。
And so, you know, people learn languages and those yeah.
人们不喜欢学习那么多东西。
People don't like to learn that many things.
此外，你还有一大堆逻辑代码被困在某种语言中，需要持续维护。
And then there's also the lock in of you have a lot a lot of logic sitting around in one language and you need to maintain that.
我实际上认为，这相当有趣；我们的一个期望是，随着AI编程变得越来越好，处理由数百人参与、涉及数百万行代码的专业应用时，代码库的负担会越来越重。
And I actually think that that's a pretty interesting or one of our hopes is that as AI programming gets better and better and better, one of the downsides of working on professional applications with hundreds of people dealing with many millions of lines of logic is the weight of the code base really starts to weigh on you.
是的。
Yeah.
因此，当你进入一个全新的代码库时，那种一切都很轻松的感觉就消失了，每件事都变得像是一种负担。
And so the feeling of being in a net new code base where it's just everything feels effortless goes away, everything's, you know, a chore.
你不得不在这里改一点东西，结果又在那里破坏了某些功能，最终整个系统变成了一团乱麻。
You have to, you know, change one thing here, break, you know, something else here, and it becomes kind of this big ball of mud.
让这一切变得轻松，减轻现有代码逻辑的负担，我认为是AI能够改善编程的一个重要领域。
Making that effortless, reducing the kind of weight of an existing set of logic, think is, you know, one of the areas in which AI can, you know, make programming better.
今天有人在Twitter上说，可能是安德烈·卡帕西，但我可能记错了，把太多与氛围编程相关的事情都归功于安德烈了，就像把功劳归于丘吉尔或爱因斯坦那样。
Someone said on Twitter today, maybe it was Andre Carpathi, but maybe I'm misattributing that and, you know, made too many things to do with vibe coding get attributed to Andre, like, you know, to Churchill or Einstein or something.
我会想到他。
I think about him.
但这位人士，不管是谁，提出了一个观点：让AI生成代码是一回事，而AI真正能大有作为的另一个领域是代码的美化与重构。
But this person, whoever was, was with the observation that, you know, it's one thing to be prompting the creation of code, but another place where AI could conceivably do a lot to help is in the beautification and the refactoring of code bases.
你可以想象，你在前端产生了很多略显笨拙、结构不够清晰的代码碎片，而夜深人静时，有个东西悄悄跟在你身后，把一切都变得优美整洁。我上过的唯一一门计算机科学课，是杰里·萨斯曼教授的课，他称之为大规模符号系统。
And you can imagine that, you know, you're producing all this, you know, a little bit ungainly, not quite correctly factored, you know, detritus at the front, and you have this, you know And then nocturnally, this thing comes up behind you and makes it all, you beautifully And the only CS class I ever took was this from this class from Jerry Sussman on on was It basically focused on I mean, he he called it large scale symbolic systems.
是的。
Yes.
但他真正想强调的是，创建易于修改的代码库、环境和抽象结构。
But really, what he was trying to focus on was the idea of creating code bases and environments and abstractions that were easy to modify.
这门课根本没有要求你从零开始写代码的作业。
And, like, there were no assignments in the class where you'd write something from scratch.
每个作业都是关于修改现有系统，并思考如何设计系统，使得这些修改——即使是很深层的修改——也能变得简单明了。
Every assignment was about modifying an existing system and thinking about how could you design things in such a way that those modifications become And, you know, there might be quite deep modifications become straightforward.
我觉得这是一个很棒的理念。
And I think that's a lovely idea.
显然，在实践中，由于你今天和下周需要交付的各种紧迫需求和压力，要做到这一点通常非常困难。
Obviously, in practice, it's often very difficult to do that given all the exigencies and pressures of the things you want to ship, you know, today and next week and so forth.
但如果你能有一个AI，在你编写代码时提醒你：我其实应该以更优雅的方式来做，但我没有。
But if you could have an AI like, when you're writing this stuff, you realize, I really should be doing it the beautiful way, but I'm not.
是的。
Yes.
也许我们也可以在Ginny's有个AI在我们身后帮忙。
Maybe we could have an AI coming up behind us too at Ginny's.
对。
Yes.
也许很快就能实现。
Maybe soon.
很多重视开发的开发者，或者很多因为热衷于构建东西而进入开发领域的人，都会遇到这种情况。
One thing that happens to a lot of developers that care Or a lot of people come to development because they care about building things.
他们希望在电脑屏幕上看到事物成真，因此这才引导他们去编程。
They want to make things happen on the computer screen, and so then that leads them to coding.
然后，很多开发者都会遇到一种情况：他们最终意识到自己想开发的软件规模太大，无法独自编写所有代码，必须寻求他人的帮助来共同完成。
And then something that happens to, you know, a big group of developers is they eventually realize the software they want to create is is too big that they can't write, you know, all of the code themselves, and they have to go to humans to help them write the code.
所以他们可能会成为一名工程经理、总监，或者类似的角色。
So maybe they then become an engineering manager or director or whatever it is.
也许他们会创办一家公司，对吧？
Maybe they start a company, right?
于是，大部分工作就不再是敲代码了。
And then most of the work becomes not typing code.
而是变成协调人与人之间的合作。
It becomes, you know, coordinating amongst people.
你认为编程中有哪些理念，可以应用于组织内部的协作，帮助一群人共同构建软件？
Do you think that there are any ideas from programming that are helpful for the act of kind of programming amongst the organization to get a group of people to build software together?
有意思。
Interesting.
我认为可以借鉴API和数据模型
I think taking APIs and data models
嗯嗯。
Mhmm.
认真的。
Really seriously.
如果我要再从头做一遍Stripe的所有事情，那肯定有一百万件小事我会做得不一样。
If I was to do everything at Stripe again, I mean, there's a million small things that you would do differently.
甚至还有一些大事。
And even some kind of big things.
但我认为，我们本可以比实际做得更多、更有益的一件事，就是花更多时间在API和数据模型上。
But the thing that I think we could maybe foreseeably and beneficially done differently would be to have spent even more time than we did on APIs and data models.
而部分原因在于，这两者最终会通过康威定律的效应来塑造整个组织。
And, you know, part of the reason is is the the, I guess, Conway's Law effect of how both of those things end up shaping organization.
所以，如果你没有深刻理解这一点，那么你对组织动态的掌控力可能就会比你希望的更弱。
So, I guess, if you don't deeply internalize that, then maybe you've less control over the organizational dynamics than you might otherwise like to have.
但我也认为，它塑造的不仅是——康威定律的弱化版本是说，它塑造了你的组织。
But also, I think it ends up shaping not only I mean, weak version of Conway's Law is that it shapes your organization.
我认为更强的版本是，它极大地塑造了你的战略乃至你的商业成果。
I think the strong version is that it substantially shapes your strategy and just your business outcomes.
这或许不完全属于上述情况，但我经常反思，为什么长期以来，甚至可能直到今天，iOS软件生态系统比Android应用生态系统更加活跃、充满活力且成功。
And this isn't exactly maybe a version of that, but I often reflect on how the iOS software ecosystem for a very long time and, you know, plausibly still today was so much more vibrant and kind of vital and successful than the Android app ecosystem.
当然，这两个生态系统之间存在许多不同之处。
And, you know, there's a lot of things that are different across those two ecosystems.
我相信，目前使用的Android设备数量远多于iOS设备。
There are now way more Android devices in use, I believe, than iOS devices.
但我认为，应用开发者倾向于优先为iOS开发应用、首先在iOS上发布应用，甚至iOS版本通常比Android版本更好，这其中很大一部分原因在于，iOS的框架和抽象层从一开始就比Android的更优秀。
But I think much of the the fact that app developers tended to prefer building their apps on iOS and releasing their apps first on iOS and maybe the iOS version being better than the Android version or, you know, whatever is because the the frameworks and the abstractions for iOS were just originally better than the than the Android ones.
因此，我认为这是一个典型案例，说明正确的API设计和正确的抽象设计最终会产生非常显著的商业影响。
And so but I I think that's a case where the right API design, the right abstraction design ended up having just quite significant business ramifications.
而且，人们或许会觉得，这些事情不值得过多关注，因为技术领域的一切变化都如此迅速，你所做的任何假设，可能两年后就过时了。
And, you know, I think there's kind of a sense that maybe it's not worth dwelling on these things because, you know, everything in technology changes so rapidly and, you know, whatever assumptions you make, they'll be, you know, obsolete in two years or something.
但我认为，实际情况并非如此。
I think in practice, that's not true.
正确的 API 设计、恰当的抽象和数据模型真的能够经久不衰。
And that's like the right API design and the right abstraction to the right data models can really endure.
在 iOS 的早期版本中，许多使用的类都以 NS 开头。
And, you know, for the first versions of iOS, many of the classes that one used were prefixed with NS.
NS，当然代表 Next Step。
NS, of course, standing for next step.
对吧？
Right?
这就是一个 API 设计持续了二十年甚至更久的例子。
And so that's a case where the API design survived for, you know, two decades or more.
以 Stripe 为例，Stripe 现在已经十五年了，我们十五年前设计的很多东西至今仍在使用，这既好又不好——好在它们经受住了时间的考验，但坏处是我们仍然在
And in the case of Stripe, you know, Stripe is now fifteen years old, and, you know, there are lots of things we designed fifteen years ago that are still, you know, in use today, which is kind of good and bad in the sense that they endured, but also we are still, you know, we are still under the
承受着它们的缺陷。
Living with their faults.
没错。
Exactly.
是的。
Yes.
所以，不管怎样，这可能是我首先想到的事情。
And so, anyway, that's maybe the thing that I would that's the first thing that comes to mind.
事实上，关于这一点，我最近和一家领先的、成功的硅谷私营公司的工程负责人聊过，他们提到他们的代码库主要是用Scala写的。
In fact, on that final note, I was talking with an engineering leader at, you know, kind of a preeminent, successful Silicon Valley private company, and they were talking about how their code base is largely in Scala.
他们说，他们喜欢把初创公司的初期看作一个大爆炸时刻，那时那些疲惫、过度劳累、可能咖啡因过量的创始团队成员随意做出了这些初始技术决策，而这些决策随后决定了未来数百名专业工程师的命运。
And they said that they like to think of kind of the beginnings of the startup as this big bang moment where these, you know, tired, overworked, maybe over caffeinated founding team members are willy nilly making these initial technical decisions that then dictate the lives of hundreds of professional engineers in the future.
那个选择Scala就是其中之一，他们现在不得不承受这个选择带来的问题。
That scholar choice was one of them, and they sort of live with the faults of that now.
但那些对Stripe的大爆炸时刻来说具有重大影响的初始条件——无论是好是坏——你们现在还在承受哪些呢？
But what are those kind of what were the consequential, it could be good or bad, initial conditions of the the Stripe big bang that you guys still live with right now?
我的意思是，我觉得这个比喻很贴切，听起来确实有道理，这是我首先想到的。
I mean, I think that metaphor is is well, it it sounds true to me, is is the first thing I'd say.
我的意思是，也许这里面有一点幸存者偏差，实际上真正要说的是，我们早期做出的那些决策，嗯。
I mean, maybe there's a little bit of kind of survivorship bias where, like, the actual statement is the the early decisions that we made Mhmm.
我们从未改变过那些我们一直沿用的决定。
That we never changed are decisions that we lived with.
但你知道，这中间有种同义反复之类的东西。
But, you know, there's a kind of tautology there or something.
当然，我们早期做了一些设计决策，而这些决策如今已不再适用。
There are certainly design decisions we made pretty early on that, you know, are are not true today.
比如，Stripe 仪表板的早期版本与今天的仪表板在构建方式上截然不同。
So, you know, early versions of the Stripe dashboard or something were built extraordinarily differently to, you know, the dashboard today.
相反的情况也同样成立。
And the converse is also true.
最初，我们决定在 Stripe 使用 MongoDB，并决定使用 Ruby。
So, you know, initially, we decided to use MongoDB at Stripe, and we decided to use Ruby at Stripe.
这些至今仍然是 Stripe 的核心基础技术。
And those are still quite foundational technologies at Stripe.
而且，我们必须构建大量基础设施，才能让 MongoDB 达到我们所需的容错性、分布式能力、持久性和可靠性，就像它现在这样。
And, you know, we had to build a lot of, you know, infrastructure in order to make MongoDB as fault tolerant and as distributed and as durable and as reliable and everything as we needed it to be and as it now is.
比如，我们去年Stripe关键API的可用性达到了99.99986%，全年仅停机44秒，这让我们感到非常自豪。
Like, we had Stripe's critical API availability last year was 99.99986%, which is forty four seconds of unavailability through the whole year, which is we we thin.
其他公司虽然不公布如此细致的统计数据，但我们相信这在行业内是最好的。
And others don't publish statistics that are kind of as granular, but we believe that is the best in the industry.
因此，你们知道，我们的存储团队和其他许多团队所构建的一切，最终都取得了很好的成效。
And so so, you know, that everything that our storage team has built and many other teams, you know, it ended up really working there.
但那确实是一个非常重要且关键的初始决策。
But that that that was a quite important critical decision, initial decision.
还有，Ruby也是类似的情况。
And, you know, Ruby, similarly.
我猜公司有时会在发展过程中更换编程语言。
I guess companies sometimes change languages, you know, along the way.
但我觉得最初选择的语言往往会根深蒂固。
But feel like the initial language chosen tends to have heard
Stripe内部曾经有过一些争论，实际上，我们的一位联合创始人早期曾在Stripe实习。
there were debates in Stripe about or one of, actually, one of our cofounders interned at Stripe early on.
或者不是在Stripe早期，而是在我们个人发展历程的早期。
Or not early on in Stripe's history, early on in kind of our collective personal history.
他记得当时有大量文档讨论潜在的Java迁移方案。
And he remembers there being documents upon documents about a potential Java migration.
是的。
Yeah.
所以，部分实现了。
So, partly happened.
也就是说，我们已经用Java重写了大量关键服务。
As in, we have rewritten a bunch of key services on Java.
比如，某些对吞吐量特别重要的服务。
So, some services for which, I don't know, throughput throughput in particular is really important.
如果你足够折腾Ruby，再重写一些关键路径的代码，比如用C语言，也能让它变得很快。
And if you torture Ruby enough and, you know, maybe rewrite parts of it, you know, parts of some hot paths in C or something, you can get it to be pretty fast.
但你常常要与内存分配器作斗争，甚至Ruby字符串本身效率就不高，诸如此类的问题。
But you're often fighting against the allocator and, you know, various parts of even just, like, Ruby strings are not that efficient and stuff.
所以我们用Java写了某些服务，现在两者都在用。
So we've written certain services in Java, and now we use both.
你们有没有考虑过Mongo以外的其他选项？为什么早期选择了Mongo？
Did you consider anything other than Mongo, and why did you pick Mongo early on?
当时做这个决定的RFC流程、RFP流程或决策过程是怎样的？
What was the what was the RFC process, RFP process, decision making process Well for that?
当时就我和约翰。
It was just me and John.
是的。
Yes.
好的。
Okay.
我们当时坐在沙发上。
You know, we were sitting on the couch.
就决定选Mongo了。
Were like, choose Mongo.
是的。
Yeah.
还好。
Fine.
他们是通过博客联系你的吗？还是当时只是因为Mongo的声誉和开源社区，或者其他原因？
Did they did they get through to you with, like, a a blog or was it just the reputation of Mongo at the time and open source communities, something else?
我想是因为我之前在上一家公司写过一个基于对象的数据存储系统。
I think it was So I wrote a data store for our prior company, an object based data store.
我不太喜欢SQL。
And I didn't really like SQL.
我觉得应用领域和SQL原生能表达的内容之间存在很大的转换不匹配。
I thought it was There was too much of a translational kind of mismatch between the domain of the application and, you know, that which SQL natively makes expressible.
所以，使用SQL时，显然你需要将数据压缩成一组相对受限的原始形式。
And so, you know, with SQL, obviously, you have to collapse down into, you know, a relatively restricted set of primitive forms.
而在你的应用程序中，比如Stripe这样的场景，你可能会有一个关于‘金钱’的概念，但它并不完全契合你所使用的特定SQL数据库如何表示金钱，或者其他类似的情况。
Whereas in your application, you know, you might have a concept of, I don't know, let's say in the case of Stripe, of money that doesn't, like, exactly comport with how the particular SQL database you're using happens to represent money or, you know, whatever the case might be.
所以，是的，我就是对 SQL 有这种原则性的反对。
And so, yeah, I just had this, like, principled objection to to to SQL.
我并不是在推崇这种做法，或者说它很好，但正如这个访谈所显示的，我确实有很多关于技术的奇怪想法。
And I'm not endorsing this or saying it was good, but I as as this interview shows, I suppose, I had all sorts of, you know, strange notions about technology.
在 Stripe，我们希望比之前的公司更主流一些，技术选型上没那么异端。
With Stripe, we wanted to be more mainstream than and a little bit more you know, a little bit less heterodox in our technology choices than our prior company.
所以，我们没有用 Smalltalk，当然也不会选 Java，而是用了 Ruby，至少在相对意义上，它看起来更主流。
And so instead of using Smalltalk, you know, okay, we aren't gonna go to Java, but we went to Ruby, which at least on a relative basis seemed more mainstream.
同样地，我们没有自己写对象数据库，而是选择了更主流的 MongoDB，它作为一种对象型数据存储，依然提供了很大的灵活性。
And similarly, rather than write our own object database, we went relatively more mainstream and used Mongo, which still gave a lot of flexibility, you know, by virtue of being a kind of a kind of object data store.
这就是原因。
So that was why.
我刚才说的这一切，可能让我再也不适合为另一家公司做技术选型了。
Everything I've said might disqualify me from, you know, ever making technology choices for another company.
但你会
But Would you
展开剩余字幕（还有 238 条）
关于 Stripe v2，你们会有什么不同的做法吗？
do anything differently about Stripe v two?
我们还没怎么谈过这个话题。
We haven't talked
到目前为止，我们还没有公开过多讨论它。
that much about it publicly yet.
答案可能有点像徐来关于法国大革命的那句引言，或者邓小平的那句话。
And the answer might be a bit like, you know, there's the Xuanlai quote about the or Deng Xiaoping, about the the French Revolution.
现在评判还为时过早。
Know, it's too soon to judge.
嗯。
Mhmm.
所以，我记得在2022年，我们意识到Stripe的几个核心抽象概念根本不是长期合适的方案，必须加以修正。
And so back in 2022, I believe, we I mean, to this discussion about data models and abstractions, we realized that a couple of the core abstractions in Stripe were just not the right long term abstractions, and we we had to fix that.
因此，我们设计了一整套v2 API。
So we designed a bunch of v two APIs.
幸运的是，我们在Stripe早期就考虑过这种可能性。
Fortunately, we had contemplated the possibility of this early at Stripe.
所以，你知道，人们熟悉的Stripe大多数REST URI都以/v1开头。
So, you know, most of the the, you know, REST URIs that people are familiar with in Stripe are prefixed with slash v one.
它们从2010年起就一直以/v1开头。
They've been prefixed with slash v one from, you know, twenty ten.
于是在2022年，我们决定，好吧，也许可以升级命名空间。
And so then in 2022, we decided, okay, we might use the, you know, we might increment the namespace.
于是我们设计了这些新的API。
So we designed those new APIs.
它们今年已经开始上线了。
They've started to ship this year.
恭喜。
And Congratulations.
谢谢。
Thank you.
我们对它将实现的功能感到非常兴奋。
And we're extremely excited about the functionality that it's going to enable.
而且，不深入那些复杂的细节，它将能够实现一些过去我们区分并分别表示的功能，比如最终客户、子账户、不同支付类型的收款方等。
And, you know, without getting into the arcana of it, you know, will enable things like, historically, we have drawn distinctions and represented separately things like end customers, things like subaccounts, things like recipients for different kinds of payments.
我们现在正将所有这些统一为同一种实体表示，这在某种程度上无疑是正确的做法，它带来了诸多便利，已经改变了部分客户的业务模式，因为他们可以让用户无需重复输入信息，或在不同国家之间共享同一账户等。
And we're unifying all of those into being, you know, into the same kind of entity representation, which is some level, surely the right answer and, you know, makes a lot of will and is already changing the businesses of some of our customers because they can, you know, enable their users to do various things without having to reenter details or maybe to bring the same account across different countries or whatever the case might be.
所以，这是一段漫长的旅程。
So anyway, it's been a long journey.
而之所以这么漫长，是因为仅仅孤立地定义这些API并没有太大用处。
And the reason it was a long journey is, I guess, because it's not that useful to just define these APIs in isolation.
如果我们只是想孤立地定义它们，那其实很容易做到。
If we just wanted to define them in isolation, that's a pretty easy thing to do.
困难的部分在于让它们与Stripe现有的所有系统兼容，并构建翻译层等组件。
The thing that's difficult is to make them interoperable with all the existing things at Stripe and to build translation layers and so forth.
然后还要和我们的客户一起探讨，什么样的升级路径才是合理的，毕竟我们掌控着自己的代码库。
And and then to figure out with our customers what a sensible upgrade path, you know, might look like because we control our code base.
我们无法控制他们的。
We don't control theirs.
所以，我不想夸大其词，但在某种程度上，这感觉更像是芯片架构的指令集迁移——指令集本身很简单，但所有共存问题才真正棘手。
And so it can be a I don't want to exaggerate it, but in a certain respect, at least, it feels a bit more like an instruction set migration for a chip architecture or something where the instruction set by itself is easy, but it's all the kind of coexistence questions that become hard.
但不管怎样，今年能上线已经很难得了，我们对此感到兴奋。
But, hey, it's hard to ship this year, and we're excited about it.
我的意思是，也许你的问题是，我们从中学到了什么经验。
I mean, I guess your question was maybe what lessons we've learned from it.
你认为在重写项目或思考这种长达数十年的抽象概念时，有什么更深层的启示吗？
Do you think there's anything bigger to draw out of that on either projects that are rewrites or thinking about these kind of decades long abstractions and how
我的老生常谈答案是：尽可能统一所有可以合理统一的东西，
to My do that trite answer to that is to unify everything you can plausibly unify and
你们如何测试第二版的设计理念？
How do you test design ideas for v two?
嗯，设计它的人……我先给你另一个经验，然后再回答你这个问题。
Well, the people designing it Well, I'll give you one other lesson, and then I'll answer that question.
所以，另一个教训，也许有点转向核心。
So And then just the other lesson, just maybe a bit turn in chief.
而且，有没有一位首席API设计师，是整个设计的总策划，而且是单个人？
And also, is there some chief API designer who's kind of the mastermind of and it's one person.
这不是某种工作组吗？
It's not some sort of working group?
确实有一个工作组。
There is a working group.
存在多个工作组。
There are working groups.
但同时也有一位唯一的人，他全面理解并比任何人都更负主要责任，我认为这是必要的。
But there is also a singular person who understands and is, more than anyone else, responsible for And the I think that's necessary.
我另一个陈词滥调的建议是：只要有可能形成N对M关系的，就要支持它，因为如果你只支持一对一、一对多或其它形式，最终你还是会需要N对M的关系。
And my other kind of trite exhortation would be to make anything that plausibly could be an N by M relationship to support that because, you know, if you only support one to N or N to one or, you know, whatever, you'll and even if it's non obvious how it could possibly be N to M, just inevitably, you'll end up needing that.
你会想，怎么可能出现一家公司由两家公司共同拥有之类的情况呢。
And, you know, you'll think, well, you could never have, you know, a company that's owned by two different companies or something.
但你知道，结果发现空间中的每一种可能性最终都会出现。
But, you know, it turns out that sort of every permutation in the space in fact eventually a sport.
至于如何做好这一点，我真的觉得这些新API，我们以为它们是正确的——你问了这个问题，我们怎么知道它们是正确的API呢？
As to, you know, how to to do that well, I really feel like it's, like, these new APIs, we think they're the Well, you asked the question, how do we know they're the right APIs?
一部分是通过向客户展示它们的早期版本，另一部分是因为设计这些API的人已经多年亲历并深受前代版本缺陷的困扰。
Partly from showing early versions of them to customers, partly because the people who designed them had spent many, many years in the, you know, witnessing and living with the shortcomings of the prior versions.
所以，我们带着非常强烈的观点而来。
So, you know, we were kind of coming with strong opinions.
即使有强烈的观点，有时你还是可能预测错误、过度推断，或者过度设计某些东西。
Even the strong opinions, I mean, one can sometimes, you know, predict wrongly or extrapolate wrongly or overengineer something or whatever.
因此，我认为迭代验证和客户反馈极其重要。
So I think the cycles validation and customer feedback are extremely important.
我认为同样重要的是，我们做了大量工作，真正编写出新世界中将存在的集成代码，因为说实话，我认为Java就是一个例子：它确实解决了C或C++及其前身在内存管理等方面的一些问题，但代价是大量的冗长和开销。
I think it's also very important, we did a lot of this, to literally write the integrations that would exist in the new world because, I mean, you really I mean, I think Java is maybe an example of, yes, it fixes a bunch of problems, you know, with memory management or whatever that existed with C or C plus plus and antecedents, but at the cost of a lot of prolixity and overhead.
为了防止我们无意中过度设计，我们强迫自己编写了大量的API代码，专门描述我们如何实现各种业务模型和流程，以确保当你看到它时，感觉是正确的。
And in order to kind of safeguard ourselves against, you know, inadvertently overengineering things, we forced ourselves to write a lot of API code specifically describing how we would implement various business models and flows and so forth just to make sure that when you look at it, it feels right.
但我还不想过早地大力推崇我们的方法。
But I don't want to endorse our approaches too strongly just yet.
我的意思是，我非常乐观，但你知道，我们完成了大约60%、70%左右，但还没到100%。
I mean, I'm feeling very optimistic, but, you know, it's we're I don't know what fraction, but 60%, 70% done or something, but not like 100%.
所以我不想过早地宣布胜利。
And so I don't want to prematurely declare any victory.
帕特里克·科利森，你是如何使用人工智能的？
How do you, Patrick Collison, use AI?
嗯，
Well,
主要方式就是那些可预见的，我经常使用大语言模型聊天工具。
the main ways are the predictable ones where I use LLM chat tools a lot.
你用它来做什么？
I What are using for?
主要是用来回答我感兴趣的一些事实性或实证性问题。
Mainly for answering for kind of factual or empirical questions I'm curious about.
所以对于深度研究类型的问题。
So for for deep research style questions.
我并不总是使用深度研究。
I don't always use deep research.
现在大型语言模型在工具使用和自主浏览网页方面越来越强，你不需要那么依赖深度研究了。
And now that the LNs are getting better at tool use and just navigating the web themselves, you know, you don't need deep research as much.
但对于回答实证性或事实性问题。
But for answering empirical or factual questions.
我希望它们能帮上写作的忙，但我通常对它们生成的文本都不太满意。
I wish they were useful for writing, but I usually end up dissatisfied with the writing that they produce.
所以我很少再用它们来做写作。
So I don't reuse them very much for that.
即使是在修改或评估我自己的写作时，我的意思是
And even for editing or grading my own writing, I mean
随着模型的进步，你在写作方面有看到任何改进吗？
Have you seen any improvements as the models have progressed in the writing?
我也同意。
And I agree also.
它出乎意料地泛泛而谈。
It's surprisingly generic.
是的。
Yes.
我正试图把它推给
I'm trying to punt it to,
比如，不那么泛泛而谈并且
like, not generic and
去做吧。
do that.
插入‘是的’。
Inserting Yes.
某些人的名字
Names of people whose
是的，是的
Yeah, yeah,
但它就是不管用。
And it just doesn't work.
因此，当我使用它时，我感到很失望。
And so I've been disappointed at the times when I've given it.
你知道，人们告诉我基础模型在这方面表现更好，这其实是口头HF的规范化过程，使它落入某种吸引子盆地。
Know, people tell me that the base models are better at this, and it's the sort of normification of oral HF that, you know, puts it some kind of, you know, attractor basin.
是的，我在那里没能有效使用它们。
Yeah, I have not succeeded in using them effectively there.
人们说Claude更好，O3比早期的OpenAI模型更强。
People say that Claude is better and O3 is better than earlier OpenAI models.
从相对角度来看，这可能是真的。
And on a relative basis, that might be true.
但我不想听起来像是在自我吹嘘，暗示我是个特别有才华的作家。
But I don't want to sound, you know, self laudatory here in suggesting that I'm, you know, some particularly talented writer.
我不认为我是。
I don't think I am.
只是我的个人风格与这些模型的个人风格有所不同。
It's just like, my personal style differs from the personal style, so to speak, of the models.
而且，某种程度上自我中心地讲，我写作时希望使用自己的风格。
And, you know, in some self centered way, I when I write, I want to use my personal style.
所以我经常用它们来处理事实性内容，我觉得它们在这方面非常出色。
So I use them for for the the factual stuff a lot, and and I find them, like, terrific for that.
而且，即使我在读书时，我最近也会启用Grok的语音模式，一边阅读一边被动地提问。
And, you know, even when I'm reading a book, I'll sometimes activate I've been recently using Grock's voice mode, and I'll just passively ask questions while I'm reading.
Grok就在后台听着，它的回答非常有帮助。
And, you know, Grocky's just listening in the background, and, you know, the answers are are are very helpful.
我当然也会用语言模型来写代码，通常是通过Critter来中介。
And then I obviously use LMs for writing code and, you know, typically mediated through Critter.
所以我们现在正在采访你，帕特里克·科利森，如果你要选一个软件工业家的架构师原型，我觉得你完全符合这个形象，原因有很多。
So we are interviewing you, Patrick Collison, as kind of the most if you had to pick the architect archetype of a software industrialist, I feel like you would be kind of straight out of central casting for a number of reasons.
首先，你正在经营一家大型软件公司，一家成功的大型软件公司。
One is that you are running a large software company, a successful large software company.
其次，你最初是一名程序员，然后转向了公司管理。
Two is you started as a programmer and then, you know, moved to running the company.
第三，这家公司还为开发者构建产品。
And then three is the company also builds things for developers.
因此，这可以说是多个圆圈在维恩图中的交集。
And so it's kind of the intersection of, you know, many circles in the Venn diagram.
所以，听你谈谈与Stripe相关的经验很有帮助。
And so it's helpful to hear about, you know, discussing kind of experiences with Stripe.
我们还在采访帕特里克·科利森，这位兼职经济学家和世界观察者。
We are also interviewing Patrick Collison, the moonlighting economist and student of the world.
那么，随着人工智能的到来，进步研究是否已经注定失败？
And so are progress studies doomed now that AI is here?
它们还有存在的必要吗？
Is there any need for them?
我想说，我认为对进步研究的需求增加了。
Well, I was going to say I think the need for progress studies has increased.
但同样，我并不是想暗示‘进步研究’这个专有名词本身需求增加了。
But again, I don't mean to suggest that proper noun progress studies sees increased need.
但我认为，进步研究试图回答的那些问题现在变得更加紧迫和重要，因为我认为我们的选择空间正在扩大。
But I think the kinds of questions that progress studies tries to answer are now more pressing and urgent because I think the degrees of freedom are increasing.
而且，我认为存在一种过于乐观的观点，认为人工智能会神奇地解决所有问题。
And I think there's some pan glossian view that AI will just magically solve all the problems.
当然，预测未来很难，但首先，我认为这种观点并不成立。
And, you know, predictions of the future are hard, but one, I don't think that's true.
其次，就迄今为止的证据来看，情况也并非如此。
And, two, in as much as we have, you know, evidence to date, I don't think that's been the track record.
因此，我认为我们如何使用这些技术、做出什么样的决策、考虑哪些因素，以及我们希望推动哪些人类福祉的边界，
So I think that, you know, how we use these things, what kind of decisions we make, what kind of, you know, considerations and, you know, margins of human welfare we seek to further.
这些判断都将至关重要。
You know, I think all those judgments are going to really matter.
五年前，你可能会对进步研究或进步研究式的思维方式提出批评，认为这些问题虽然不错，但世界正沿着一条预定的上升路径，走向某种目的论的结果。
And maybe a critique you could have leveled at progress studies or progress studies style thinking five years ago is these are all nice questions, but the world is on a kind of foreordained escalator path to, you know, some kind of teleological outcome.
但我不认为今天的世界是这样看待的，或者至少今天的世界远没有以前那样这么认为。
And I don't think the world feels that way today, or certainly feels much less that way today than it did.
所以
So
是因为国际事务或其他原因吗？
Because of global affairs or something else?
不是。
No.
我的意思是，或许部分是因为国际事务，但更准确地说，是三大因素的结合，即大规模的国际事务。
I mean, maybe somewhat global affairs, but maybe the trifecta of, yeah, global affairs writ large.
其次，我认为抱负和理想正变得更加有争议。
Second, I think that aspirations and ideals are becoming contested more actively.
如今在美国，左右派究竟代表什么，存在着一种模糊性。
And there's an ambiguity these days in The US as to what the left and the right even stand for.
而且，我想我们现在看到的是，一个政党支持关税，另一个政党反对关税，但这种立场的倾向与历史上人们预期的恰恰相反。
And, you know, I guess we currently have one party endorsing tariffs and another party opposing them, but with the valences kind of shift flipped from what one might have expected historically.
第三，当然，技术，尤其是人工智能。
And then third, yeah, obviously technology and first and foremost AI.
但在我们的行业里，稳定币、中国在许多未来技术（如无人机、机器人、电池和太阳能等）上成为主导制造强国，等等。
But, you know, in our industry, stablecoins, the rise of China as the preeminent manufacturing power in many technologies of the future, like drones and robots and batteries and solar, you know, etc.
所以，从很多方面来看，我觉得未来正如彼得·施瓦茨提出的概念——‘施瓦茨窗口’，即未来若干年里可设想的前景范围。
So, yeah, in many different ways, I feel like the future is, you know Peter Schwartz has this concept of, you know, the Schwartz window as the window of, you know, contemplatable futures in, you know, whatever number of years hence.
我认为，以2005年的眼光展望2015年的世界，当时的施瓦茨窗口相当狭窄，而且这种狭窄是正确的。
And I feel like that Schwartz window, you know, as of, say, 2005, as we contemplate the world of 2015, was fairly narrow and was correctly fairly narrow.
2015年的世界确实大致按照2005年我们预期的方式发展了。
Think the world of 2015 did, in fact, unfold largely the way we would have expected in 2005.
而我觉得，今天是2025年，展望2035年的这个窗口，变得异常宽广。
And I feel like today in 2025, that window for 2035, like, feels extremely broad.
因此，我认为进步研究的问题变得更加紧迫。
So, I think the progress studies questions are more pressing.
你曾公开表示，人们应该更多地关注这样一个问题：为什么随着信息技术的发展、越来越多的人投身科技研究、以及投入的资金不断增加，生产率数据却没有显示出改善。
So you were on the record saying that people should focus more on the question of why we don't see improvements in productivity numbers as information technology increases and also as more people have started working on science and technology and more money has gone into it.
那么，现在的数据是什么样的？
And what do the numbers look like now?
我们在数据中看到人工智能的影响了吗？
Do we see AI in the numbers?
最近几天刚发表了一篇关于这个问题的新论文，令人兴奋。
There was a new paper published on this very recently, like the past couple of days Exciting.
我还没来得及看。
That I've not had a chance to.
我今天才刚拿到这篇论文。
I just cutest today to read.
所以目前我只读了摘要。
So I've, at this moment, only read the abstract.
论文的主张是，实际上并没有观察到使用语言模型带来了生产率的提升。
Its claim is that one does not, in fact, observe productivity improvements stemming from use of language models.
现在，我当然不能
Now, I certainly can't
你知道他们在看什么吗？
Do you know what they're looking at?
他们似乎正在进行某种自然实验，基于个体层面的语言模型使用强度。
They appear to be undertaking some kind of natural experiment looking at the individual level based intensity of LLN usage.
但我绝对无法认可他们的方法论严谨性。
But I certainly cannot endorse their methodological rigor.
等我更好地理解后，可能会非常印象深刻并觉得它非常可信，也可能会感到震惊。
Upon understanding it better, you know, I might be I might be either really impressed and find it very credible or horrified.
我不确定。
I don't know.
但这是我今天偶然发现的发现。
But that was just the finding I happened to to to stumble upon today.
我的意思是，总的来说，过去两年美国的GDP增长情况比我们预期的要好一些。
I mean, look, overall, GDP growth in The US looks well, over the last two years, it's been somewhat better than we expected.
嗯哼。
Mhmm.
显然，我们现在正处于一个相当动荡的时期。
Obviously, you know, we're we're speaking right now at a a kind of volatile time.
我们确实没有看到任何指数级起飞的迹象。
We certainly don't see any evidence for exponential takeoff.
如果我们认为过去两年美国看到的令人鼓舞的GDP数据部分归因于这些新技术，
And if we, you know, in as much as we thought that the encouraging GDP figures we have seen in The U.
那么，
S.
你也会预期这些技术在其他国家也能看到，对吧？因为这些技术属于准公共产品。
For the last two years are attributable to some of these new technologies, I think you would also expect to see them in other countries, right, because these technologies are quasi public good.
任何人都可以使用这些大语言模型。
Anybody can, you know, can use these LLMs.
美国以外的GPU增长
GPU growth outside of The U.
并没有那么令人鼓舞。
Has not been that encouraging.
我们并没有生活在一个全球范围内急剧加速的纯电子增长时代。
We're not living in some, you know, massively accelerated pure electronic growth for the world writ large.
所以，显然，现在还处于早期阶段，但我认为，我们正看到这些技术在经济中的扩散确实需要时间，并且涉及相当大的复杂性。
And so, you know, obviously, it's early days, but I think, you know, I think we're seeing that the diffusion of these technologies through the economy really takes time and involves substantial complexity.
也许最后一点是，我相信杰克·克拉克在与泰勒·科恩的采访中提到过，他是Anthropic的联合创始人之一。
And maybe just last point of that is, I believe Jack Clark said in an interview with Tyler Cohen, one of the cofounders of Anthropic.
而Anthropic在某种程度上一直非常认真地对待AGI乃至ASI这一概念。
And, you know, Anthropic, to some extent, has well Anthropic has always taken the concept of AGI and even ASII, I feel, extremely seriously.
而且，达里奥经常公开谈论这个问题。
And, you know, Dario speaks about this publicly.
他写过相关文章，等等。
He's written about it, you know, etcetera.
同样，杰克·克拉克作为联合创始人之一，他表示，他预计AI每年将使GDP增长提升百分之零点五。
And, again, Jack Clark, one of the cofounders, and he said that he expects AI to increase GDP growth by half a percent a year.
我觉得，我的理解是，杰克其实是个乐观主义者。
And I thought that I mean, I interpret Jack as really an optimist.
而且，你知道，每年增长百分之零点五，如果复利计算的话，其实也是相当可观的GDP增量。
And, you know, half a point a year is, in fact, a lot of incremental GDP when compounded.
所以，我不是说这个数字小，但我觉得有趣的是，这竟然是他的预测。
So, I'm not saying that that's small, but I think it's interesting that that was his figure.
是的。
Yes.
你觉得，就目前AI在经济中所采取的形式而言，如果我们把趋势线向外推演，你认为我们是否需要新的经济生产力衡量指标？
Do you think that with the form factor that AI is taking in the economy right now, if we just kind of stretch the line forward, do you think we're going to need new measures in economic productivity than we have right now?
比如，假设真实生产力确实提升了，假设AI持续进步，并以你预期的方式被广泛应用。
So, like, assume real productivity goes up, assume that AI keeps getting better, it gets kind of deployed in the ways you would expect.
你
Do you
觉得我们需要新的衡量标准吗？还是应该
think we'll need new measures or it should
不。
No.
出现在‘不’里。
Show up in the No.
我不这么认为。
I don't think so.
就像，我不觉得GDP是完美的。
Like, like, I don't I don't think the GDP is perfect.
我认为GDP可以改进，但在任何我们所认为的经济得到极大提升的世界里，我相信这会使得GDP更加精准。
I think GDP can be improved, but but I in in any world where what we, you know, think of as the economy is massively enhanced, it'll sharpen GDP, I believe.
是的。
Yep.
是的。
Yep.
我们什么时候能编程人类的生物学？
When will we be able to program human biology?
我对这件事非常兴奋。
I'm very excited about this.
在ARC，这是一个我参与创立的生物医学研究机构，我们正在利用DNA等数据训练生物学的基础模型。
At ARC, which is this biomedical research organization which I was involved in founding, we are working on training foundation models for biology using DNA and things like that.
我们正在开发一个虚拟细胞。
We're working on a virtual cell.
总的来说，我们试图说明的是，我直到真正深入生物学后才意识到：人类从未治愈过任何一种复杂疾病。
And generally, we're trying mean, the thing that I think is that I didn't appreciate until really spending more time in biology is we've never, like we humanity, have never cured a complex disease.
所以，你知道，疾病的某种分类体系或框架是这样的：你有传染性疾病，比如流感、感冒、新冠，或者结核病，这些都属于高致死率的疾病。
So, you know, one ontology or scheme or something of diseases would be, you you have infectious diseases, the flu, the cold, COVID, whatever, and, you know, tuberculosis and, you know, very diseases with high mortality rates.
然后你有单基因疾病，也就是仅由一个基因突变引起的疾病，比如亨廷顿病。
Then you have monogenic diseases where, you know, there's just sort of one genetic mutation that is responsible for the disease like Huntington's.
然后你有复杂疾病。
And then you have complex diseases.
复杂疾病是那些在我们治愈了大多数有威胁的传染性疾病之后，尤其是在西方世界，所剩下的残余疾病。
And the complex diseases are kind of the residual that are now left after we've cured most of the problematic infectious diseases, at least in the Western world.
大多数心血管疾病、大多数癌症、大多数自身免疫疾病、大多数神经退行性疾病等等。
Most cardiovascular disease, most cancers, most autoimmune disease, most neurodegenerative disease, etc.
对于其中某些疾病，我们或许有一些能缓解症状的治疗方法，比如他汀类药物用于心血管疾病，但没有任何一种疾病我们能真正说已经治愈了，也就是说，我们并未在有意义的细节层面理解其因果通路，也无法像疫苗那样直接预防。
For certain of these conditions, we have maybe treatments that help, like statins with cardiovascular disease, but for none of them can we really say that we've cured us, that we, like, understand the causal pathways in, you know, meaningful detail and that, you know, it's just, you know, we can vaccinate against it or something.
我认为我们的假设——当然这可能是错误的——是，部分原因在于我们缺乏能够应对这一挑战的实验技术，也许‘认知技术’这个词太夸张了，但基因的多效性，即它们影响身体各个部分、系统和细胞内机制的方式，带来了巨大的组合复杂性。
And I think this is our hypothesis, you know, could be wrong, is that this is in part because we don't have experimental and kind of maybe epistemic is too grandiose a word, but kind of epistemic technology that's up to the task, like the pleiotropy of the genes in terms of all the different parts of the body and the systems and the mechanisms inside the cell that they affect is so, you know, there's so much combinatoric complexity there.
此外，环境是一个极其广阔且难以量化的因素，使得我们很难理解这些疾病的病因、动态机制等等。
And then, you know, the environment is such a vast and, you know, difficult to quantify thing that just it's really hard to understand for any of these conditions, you know, the etiology and the dynamics and so forth.
好的。
Okay.
在过去大约十年里——虽然更早之前就开始了，但大部分发展是在最近十年内发生的——我们在生物学领域获得了三种新技术。
Then over the last ish years, I mean, bit longer, but a lot of the development has happened in the last ten years, we've gotten three new classes of technology in biology.
在读取方面，我们获得了更先进的测序技术，比如单细胞测序，能够对单细胞的RNA进行测序，以及这些方面的改进。
For reading, we've gotten much better sequencing technology, single cell sequencing, the ability to sequence, you know, single cell sequencing of RNA, and those improvements.
在智能层面，我们获得了神经网络、深度学习、Transformer模型等一切相关技术。
At the kind of think level, we've gotten neural networks and deep learning and transformers and everything there.
意思是，这些技术早已存在，只是我们最近在它们身上取得了进展，尤其是Transformer。
Mean, they've existed for a long time, we've gotten the recent improvements in them, and the transformer in particular.
而在另一方面，我们在功能基因组学、CRISPR和基因编辑技术上看到了巨大的进步，这种技术能够对细胞进行非常精准的定向干预。
And then on the right side, we've seen obviously huge improvements in functional genomics and CRISPR and, you know, bridge editing, which is a technology that kind of arc, but the ability to kind of make very specific directed perturbations in cells.
但如果你把这些技术结合起来，现在你就能够在单个细胞的层面上实现读取、思考和编写。
But if you put those together, you now have the ability to, again, at the kind of level of the individual cell, to read, think, and to write.
这开始真正像一种新的图灵循环，并展现出自身的完备性。
And this starts to really feel like a new kind of Turing loop and to have its own sort of completeness.
我们会看到，这种系统性方法在应对这些复杂疾病方面能走多远，是否足以揭示它们的动态机制，但我们充满希望和兴奋。
And, you know, we will see how much this can do against these complex diseases and whether sort of this systematic approach is up to the task of shedding new light on their dynamics, but we are hopeful and excited.
如果我们在这里的Kershur以及行业内的其他人都成功实现了对当今大量编程工作的自动化，并用一种更高层次、更高效、更专注于定义软件应有功能的软件构建方式取而代之。
If we here at Kershur and also others in the industry are successful in automating lots of programming as we know it today and, you know, replacing it with a form of software building that's much higher level and more productive, and it's much more just focused on defining what you would like the software to look like.
如果我们真的成功了，那谁会是最终的赢家呢？
If we, you know, succeed in that, who are you long?
人们常谈论设计师，说这将为他们带来一场文艺复兴，但你看好的是那些研究生吗？
You know, people talk about the designers and how, you know, this will be like a renaissance for them, but, you know, are you long, the grad students?
我的意思是，有很多非常出色的研究生，他们能力很强，但在计算机上实现东西方面可能不太擅长。
I mean, there are lots of really, really amazing grad students who are awesome and then maybe are less skilled at making things happen on computers.
但你觉得，在一个越来越多的人能够用计算机创造东西的世界里，尤其是当这演变为一种远离编程的模式时，谁会是最大的受益者？那些已经能用计算机创造东西的人，效率已经提高了很多、很多、很多。
But who do you think, you know, is the most unexpected beneficiary of a world where both many more people can make things on computers and then also, you know, especially if it's an evolution away from programming, you know, the people who are already making things on computers are much, much, much more productive?
我对这个问题没有太高的把握。
I don't have a high confidence answer to that.
你知道，有很多老生常谈的套话，比如实物资产，尤其是稀缺的实物资产。
You know, there's all sorts of trite stock answers like real assets, especially constrained real assets.
也许我们应该做多旧金山的房地产，因为它是世界上最美丽的城市之一，并且将长期如此。
You know, maybe we should be long SF real estate or something because, you know, it is one of the most beautiful cities in the world and will be enduringly so.
也许我们应该投资这些系统的输入和原料，因为对它们的需求将会呈爆炸式增长，所以也许我们应该做多铜。
Maybe we should be allowing the inputs and the ingredients to these systems because, you know, demand for them will go parabolic, and so maybe we should be allowing copper.
也许我们应该做多地位性商品、名人，以及泰勒·斯威夫特的音乐版权。
Maybe we should be long positional goods and celebrities and, you know, Taylor Swift's music catalog.
这里有很多看似有说服力的理论，但我觉得，在当前这个经济时刻，有趣的一点是它的不可预测性、偶然性，以及对技术路径中具体假设的高度敏感性。
There's a lot of, I think, compelling theories here, but part of what I think is interesting at this economic moment is the unpredictability and the contingency and kind of sensitivity to the precise assumptions in the technology trajectory itself.
它在五年或十年后会呈现出什么形态，这将很大程度上决定这个问题的答案。
The shape that it takes in five or ten years or whatever, think, is going to do a lot to determine the answer to that.
回顾过去几年，我惊讶地发现，即使是一些表面上信息极为灵通的人，他们的许多预测也表现得相当糟糕。
And as I look backward the last couple of years, I'm struck by how many predictions have held up, you know, reasonably poorly, you know, even from people who are, on the face of it, you know, extremely well informed.
所以我问过很多人这个问题，但还没有听到任何让我感到有足够信心的答案。
And so I've asked a lot of people this question, and I have not heard any answers that are so compelling that I feel like I have conviction.
我们非常高兴能为Stripe以及你们的使命提供服务。
So we are very happy to be serving Stripe and your guys' mission.
你们希望我们构建什么？
What would you like us to build?
我们怎样才能让Cursor对你们、帕特里克·科利森或Stripe变得更好？
How can we make Cursor better for you, either you, Patrick Collison, or you, Stripe?
你们已经让Stripe变得更好了，所以从我们的角度看，继续你们现在所做的事情，已经是一个不错的结果了。
Well, you guys are already making Stripe better, so, you know, keep doing what you're doing would not be a bad outcome from our vantage point.
目前，Cursor拥有数百名，很快将达到数千名极其热情的短期员工，他们每天都在使用Cursor，并反馈说它极大地提升了生产力。
Cursor has today hundreds, and soon thousands, of extremely enthusiastic short employees who are daily users of Cursor, and they report that it's a very significant productivity enhancement.
那我们等着吧
So We'll wait
等经济数据出来。
for the economic numbers.
你知道，经济规模很大，这些影响需要时间才能显现。
Well, you know, the economy is pretty big and these diffusions take time.
是的，是的。
Yes, yes.
所以，如果你已经在做得很好了，那再要求更多似乎有点贪心，毕竟Stripe在研发和软件创造上的投入，比我们任何单一项目投入的都要多。
So, you know, it seems kind of greedy to want more if you're already making, you know, Stripe spends more on r and d and software creation than we spend on, you know, any single undertaking.
因此，如果你们正在让这个过程变得更高效、更有生产力，那再要求更多，或许确实显得贪心。
And so if you're making that process more efficient and more productive, then, you know, maybe it seems greedy to want anything more.
如果我有点自私的话，好吧。
If I'm being selfish okay.
三件事。
Three things.
对。
Correct.
我们刚才讨论的运行时特性和集成方面，我认为会非常有价值。
The runtime characteristics and integration stuff that we just discussed, I think, would be really valuable.
我认为，我们之前也提到过的重构和美化工作，将会极其有帮助。
I think the the refactoring and the beautification stuff that, again, we also talked about, I think would be extremely helpful.
而且这真的会扩大我们的选择空间，比如如果你能降低Stripe未来变更的成本，并提升架构的质量。
And and and I think really change our degrees of freedom, as in if you could lower the cost of future changes to Stripe and improve the quality of the architecture.
第三，我们在Stripe非常重视所谓的‘工艺与美感’，我们希望我们的软件不仅设计优良、易于使用，而且这种‘易用’不仅体现在表面的像素层面，更体现在深层的高效运行上——你可以轻松配置，然后基本不用再操心，完全信任它，或者随你意愿忽略它。
And then third, we really care about what we call at Stripe Craft and Beauty, and we want our we want our software to be well designed and pleasant to use, and pleasant to use not only in the superficial, you know, pixel sense, but also in the deep it works very well sense and is something you can set up and, you know, largely forget about and just trust or forget about it in as much as you want to.
当然，人们担心AI会导致更多低质量、粗糙的东西产生，而不是更多顶尖的作品。
You know, there's obviously a concern with AI that it leads to the creation of more slop and more kind of crappy things, but not more of the best things.
我不知道Cursor具体能做什么来确保世界创造的是更多顶尖软件，而不仅仅是更多软件，但我觉得这是一个有趣且重要的维度。
I don't know what it would be that Cursor would do to ensure that the world is creating more of the best software and not just more software, but I think that's an interesting and important dimension.
所以，除了所有显而易见该做的事之外，这些就是我的三点建议。
So those would be my I mean, besides all the obvious things to do, those would be three suggestions.
太棒了。
Amazing.
谢谢你，帕特里克。
Thank you, Patrick.
好的。
Alright.
谢谢你的邀请。
Thank you for having me.
是的。
Yes.
感谢您收听本期《A60Z》播客。
Thanks for listening to this episode of the a 60 z podcast.
如果您喜欢本期节目，请务必点赞、评论、订阅，给我们打分或留下评价，并分享给您的朋友和家人。
If you like this episode, be sure to like, comment, subscribe, leave us a rating or a review, and share it with your friends and family.
如需收听更多节目，请前往YouTube、Apple Podcasts和Spotify。
For more episodes, go to YouTube, Apple Podcasts, and Spotify.
在 X 上关注我们，账号为 a16z，并在 a16z.substack.com 订阅我们的 Substack。
Follow us on x at a sixteen z, and subscribe to our Substack at a16z.substack.com.
再次感谢收听，我们下一期再见。
Thanks again for listening, and I'll see you in the next episode.
本信息仅用于教育目的，不构成购买、持有或出售任何投资或金融产品的建议。
This information is for educational purposes only and is not a recommendation to buy, hold, or sell any investment or financial product.
本播客由第三方制作，可能包含付费推广广告、其他公司提及以及与 a16z 无关的个人。
This podcast has been produced by a third party and may include paid promotional advertisements, other company references, and individuals unaffiliated with a 16.
此类广告、公司和个人均未经 Ah Capital Management LLC、a16z 或其任何关联方认可。
Such advertisements, companies, and individuals are not endorsed by Ah Capital Management LLC, a sixteen z, or any of its affiliates.
信息基于发布当日的可靠来源，但 a16z 不保证其准确性。
Information is from sources deemed reliable on the date of publication, but A16Z does not guarantee its accuracy.
关于 Bayt 播客
Bayt 提供中文+原文双语音频和字幕，帮助你打破语言障碍，轻松听懂全球优质播客。