OpenAI 工程与开发工具创始人：软件工程如何变革 | Charlie Marsh

确实是这样。

Like that is true.

但更多是为了，我们怎么在过滤掉那些对仓库有负面影响的互动的同时，保留有用的贡献？

But it's more intended to be like, how do we like retain like useful contributions while filtering out like net negative interactions from the repo?

因为比如有贡献者进来，你知道，发一条他们代理写的评论。

Because like a contributor coming in and, you know, posting a comment that their agent wrote.

然后我们问他们一个问题，他们就直接把代理的回答粘贴回来。

And then we like ask them a question and then they just paste like the agent response back.

这其实没什么价值，对吧？

Like there's like very little value in that, right?

我们直接问代理就行了。

Like we could just like ask the question to the agent.

对吧？

Right?

所以我们想保留的是人类贡献者带来的有用的东西，比如见解、复现方法，还有我们需要的信息，好把它输入到我们的代理里，因为在GitHub问题上跟LLM聊天没什么意义。

And so the things like we wanna retain the things that are useful from like human contributors, which is like, you know, like insight, like ways to reproduce, like the information we would need to like plug it into our agent because there's no point in just like having a conversation with an LLM on a GitHub issue.

对吧？

Right?

其实这对我们来说没什么用。

Like it doesn't really do anything for us.

所以我们的政策大致是，你得明白你在提交什么内容。

And so our policy is roughly, like, you need to like understand like what you're pacing in or what you are submitting.

对。

Right.

听起来门槛很低，但其实不是。

Which sounds like a low bar, but it's not.

那你怎么监督这一点呢？

How do you police that?

如果我们分辨不出来，而且它确实是代理写的，那我觉得也没问题。

If we can't tell and it is agent written, then I guess that's fine.

对吧？

Right?

至少现在有很多迹象，比如，你知道的，比人类会做的要细致得多，包含太多细节，格式也更多，使用人类不会用的术语，比如编造随机的行话，还有大量的链接。

At least right now there are just lots of tells and like, you know, being way more thorough than a human would ever be including way too much detail, way more formatting, using terminology that a human wouldn't use, like inventing random jargon, tons of links.

我觉得一个普遍的迹象就是，投入了比必要更多的精力，这种方式人类不会做，几乎总是由代理生成的，但确实，这挺有挑战性的。

Like I guess the broad sign would be like putting in way more effort in ways that aren't necessary in a way that a human wouldn't is like almost always agent authored, but it's been, yeah, it's been challenging.

我觉得难的地方在于，Zig 有更严格的 LLM 政策，就是项目里完全不允许 LLM 写的代码或者 LLM 辅助的代码，这和我们很不一样。

I mean, I think the hard thing, Zig has a much more strict LLM policy, which is like no LLM written code or no LLM assisted code at all in the project, which is very different than us.

我的意思是，我现在所有的 PR 都是 LLM 写的，对吧？

Mean, like all of my PRs now are LLM written, right?

LLM 写的。

LLM written.

他们有一篇博客文章，讲的是这个想法，他们称之为类似“贡献者扑克”的东西，就是有点像你在对贡献者下注。

And they had a blog post about this idea of like, they called it something along the lines of like contributor poker, where it's like, you're kind of trying to place like bets on contributors.

在开源历史上，当一个贡献者出现时，他们可能是项目的新手，但他们能显示出有潜力的迹象，或者他们真的很投入、很感兴趣。

Like historically in open source, when a contributor came around, they might be like new to the project, but they could show like signs of promise or like, they're really engaged or really interested.

然后你给他们反馈，他们接受反馈，然后修改他们的 PR。

And like you give them feedback, they take the feedback and they fix up their PR.

然后下次他们再提交PR的时候，就已经从上次的反馈里学到了。

And then the next time they put up a PR, they've learned from that feedback.

对吧？

Right?

这就像带一个刚加入团队的新工程师一样。

It's the same way as like mentoring a new engineer who joins your team.

就是他们会从反馈中学习。

It's like, they learn from feedback.

这种进步会累积，他们变得更好，将来还能去指导别人。

It compounds they get better and then they can actually mentor someone else in the future.

对吧？

Right?

所以某种程度上，你是在对人进行投资。

And so you're making investments in people in a way.

开源项目也是一样的道理。

And it's the same for open source.

就像你想，我历史上想过这个规律。

It's like you wanna, I thought about this law historically.

就是说，你想投资那些好的贡献者，他们会成长起来帮助别人，并且自己也能成为维护者。

It's like, you wanna like invest in good contributors who are gonna grow to help others and be maintainers in their own right.

这种想法有点过时了。

That's kind of gone.

特别是对于由代理写的PR，因为人们其实学不到什么东西。

If for PRS, especially that are written by agents, because people don't really learn anything.

比如有人提交一个由代理写的PR，你留下评论，然后他们把你的评论输入代理，更新PR，然后合并。

Like someone can put up a PR that's written by an agent and you leave comments and then they take your comments and put them into the agent and then update the PR and then merge it.

这就像没有累积的反馈。

And it's like there's no compounding feedback.

所以我确实理解那种观点，维护者和贡献者之间的契约现在真的很不一样了。

And so I actually do like understand that perspective a lot of like the contract between like maintainers and contributors is like pretty different now.

而且，你知道，相关地，虽然不是新见解，但提交一个像样的PR的成本已经降到了零。

And, you know, relatedly, again, not a novel insight, but the cost of putting up a plausible PR has gone to zero.

而审查和验证一个看似合理的PR的成本却保持不变，而且非常高。

While the cost to like review and vet a plausible PR has remained the same and is very high.

特别是对于我们参与的那些项目，我不是想夸大其词。

Like especially for the projects that we work on where, you know, I'm not trying to like overstate it.

这些项目本身就很难。

They're just like hard projects.

比如TY是我们的类型检查器。

Like TY is our type checker.

从技术上讲，这可能是我参与过的最难的项目，因为架构复杂，问题领域也复杂，要合并一个改动非常难。

Probably hardest project I've worked on technically to like get a change merged because of the like complexity in the architecture, but also like the problem space.

就是非常非常难。

Like it's just very, very hard.

所以如果有人花两分钟提交一个看似合理的TY的PR，我们可能需要一个小时才能理解它。

And so if someone puts up a plausible PR to TY, it might take them two minutes and then it could take us, you know, an hour to understand it.

这就导致开源社区里出现了一些非常不好的互动模式。

And so it's created like very poor dynamics in open source.

我也不知道我们是怎么解决这个问题的。

And I don't know how we've solved that.

我觉得这个问题会一直恶化下去，直到某天以某种方式好转。

I think it will like continue to get worse until hopefully it gets better in some way.

我们确实在想办法解决，但这肯定是我们项目里遇到过的实际情况。

Like we find ways to solve this, but it's certainly something we've experienced in our projects.

对。

Right.

听起来代码审查越来越成为瓶颈了。

It sounds like review is becoming more and more of a bottleneck.

关于那个Bun重写，你知道是人工读的代码，还是只是……

Is for that bun rewrite, do you know if it was human, like humans read that code or that was just kinda

不，我觉得不是人工审查的。

No, I don't think it was human reviewed.

所以就是直接放手一搏，整个重写了。

So it's just YOLO rewrite the whole thing.

我是说，从某种程度上讲，我觉得他们确实有，而且我很期待，至少在我录制这段的时候，你知道，Jared 还没发那篇博客文章，这就像，我是说，他一直在开玩笑说那篇博客文章花的时间比重写还长，但我其实对那篇博客文章很感兴趣，因为我觉得他们确实对重写的方式有一套相当复杂的方案，读起来应该会很有意思。

I mean, in a way, I think it's like, I think they did have, and I'm excited for like, at least that time of, at time of recording quote unquote, you know, Jared hasn't published the blog post yet, which is like, I mean, he keeps making jokes about how like the blog post taking way longer than the rewrite, but I'm actually really interested in the blog post because I think they did have a pretty like sophisticated approach to like how the rewrite worked, which will be interesting to read about.

就像，他们并不是只有一个提示词，说“用 Rust 重写这个”。

Like, it wasn't just like they had one prompt that was like rewrite this in Rust.

就像，他们试图——至少我从看那个 PR 得到的印象是——实际上重写分了好几个阶段，每个文件都要经过几个不同的阶段，每个阶段都有办法验证它是否正确。

It was like, they tried to have at least my impression from looking at the PR is like, there were actually like different phases of the rewrite and like each file had to go through like a couple of different phases that had like ways to validate whether it was correct or not.

所以答案是否定的。

So the answer is no, though.

我觉得，我不认为有人类读了那代码的很大一部分。

I like, I don't think a human was reading like significant amounts of that code.

基本上就是不可能。

Like it's just not possible basically.

如果我们俩今天都同意 Zig 客观上比 Rust 好，那会怎么样？

What if we, we both agreed today that Zig was objectively better than Rust.

然后你团队里有人说，你知道，我可以把这个重写成 Zig。

And then someone on your team said, you know, I can do this rewrite into Zig.

你会阻止吗？

Would you block it

如果是我，我想我会阻止。

if I think I would block it.

我觉得，我不知道这样做对不对，但我想我们团队还没到那个程度。

I think, I don't know whether I'd be right to do so, but I think like we as a team, like aren't there yet.

也许我们最终会到那一步，到时候我们可能就会这么想了。

And maybe we will like get there and that's how we will feel eventually.

但现在，我觉得我们还是觉得深入理解我们的代码、工具链和生态系统仍然很有价值。

But like right now, I think we just feel like right now there's still a lot of value in like deeply understanding like our code and our tool chain and like the ecosystem.

所以我会说我们不想这么做，但这可能取决于项目。

And so I would say we don't wanna do that, but it might depend on the project.

我不知道。

I don't know.

你做的那些东西，比当时可用的要快一个数量级。

All the things that you've built, they're like an order of magnitude faster than what was available at the time.

Rust在那个图表上带来了多大的差异？

How much of a difference did Rust make on that graph?

我觉得这有点取决于项目。

I think it So it depends a bit on the project.

我觉得粗略来说，大部分功劳要归功于Rust。

I think in a rough, a lot of it was just Rust.

然后随着时间的推移，我们在这方面改进了很多，因为你可以看看项目的历史，希望这仍然是事实。

And then over time, I think we've improved on that a lot because you can even look at the history of the project, like the project, I mean, hopefully no one like, hopefully this is still true.

基本上，随着时间推移，项目变得更快了。

But like basically over time the project gets faster.

有时候会倒退，但基本上，换个说法吧。

And sometimes that regresses, but like, you basically maybe to put it differently.

你可以用几种不同的方式写Rust代码，它们的性能表现可能会非常不同。

You could write rough, you know, in like a couple of different ways, all in Rust and they could have really different performance characteristics.

所以这也就是说，我通常认为Rust就像是一个底线，或者说你得到的基础性能会显著更好。

So that's just to say that like, I generally think of Rust is like the floor or sort of like the baseline performance that you get is gonna be significantly better.

但是你还是得，你仍然能从深入思考性能和设计中获得更多。

But you still have to, you still get a lot more out of like thinking deeply about performance and design.

比如，如果你用Rust和Python写同一个程序，尽可能做到完全相同的实现。

Like if you take the same program in Rust and Python, like exact same implementation to the closest approximation you can get.

Rust版本会更快，但你可以进一步优化那个程序，可能再提升10倍。

Like the Rust one will be faster, but you can then take that program and you can probably optimize it another like 10X.

我不确定是不是10倍，但我的意思是，即使是用Rust写的，在如何提高性能、如何编写高性能软件方面，仍然有很大的空间。

I don't know about 10X, but my point is even within being written in Rust, there's like a ton of room for how to make things more performant, how to write really performance software.

而且，当我开始做Ruff的时候，我的部分目标就是学习Rust。

And like, again, when I started working on Ruff, part of my goal was to learn Rust.

所以我确实写了很多糟糕的代码，这没关系。

And so I wrote, I did write a lot of like bad code, which is fine.

我推出了一些对人们非常有用的东西，但我觉得随着时间的推移，它变得好多了。

Like I shift something out that was really helpful to people, but it's gotten a lot better I think over time.

而且我们让它越来越高效。

And like we've made it more and more performant.

我觉得在UV里，除了用Rust之外，还有更多架构上的创新，尤其是因为UV作为一个包管理器，要做大量的IO操作，比如从网络下载文件、解压、写到磁盘、移动文件等等。

I think in UV, there was more sort of like architectural innovation beyond just being in Rust, especially because UV, like, so as a package manager, you're doing a ton of IO, like downloading files over the network, unzipping things, like writing them to disk, moving them around.

而linter就不需要做那么多这些操作。

The linter doesn't have to do as much of that.

意思是，它需要读取你所有的文件，但不会有大量的IO。

Mean, it has to read all your files, but there's not like a huge amount of IO.

包管理器基本上就是IO密集型的。

The package manager is like mostly IO.

然后你还要想办法做得非常高效。

It's like, and then you're trying to do things like very efficiently.

所以在那里面，Rust很重要，但我觉得在UV里，我们做了更多架构上的事情，或者说是我们深入思考性能的方式。

So there it was more, I mean, Rust was important, but I do think that in UV there's more, you know, architectural things that we did or like ways that we thought a lot about performance.

比如缓存的设计非常非常用心，这样你在同一台机器上重复安装同一个包时，几乎是瞬间完成的，这得益于我们缓存布局的方式以及从缓存安装到项目的方式。

Like the design of the cache is like very, very intentional and makes it so that like repeated installs of the same package on your machine are like near instant because of the way that we like lay out the cache and the way that we install from the cache into your projects.

基本上就是说，如果你之前装过某个包，再装一次会非常便宜。

It basically means that if you've installed a package before, installing it again is extremely cheap.

而且在磁盘空间和时间上都是这样。

And both in terms of disk space and time.

所以这跟其他任何Python包管理器相比，设计上是非常不同的。

And so that was like, that's like a very different design than any of the other like Python package managers had.

所以再说一次，这要看具体项目。

So again, it kind of depends on the project.

我确实倾向于认为，不管你是用Rust还是Python写代码，总是有空间去思考性能问题。

I do tend to think that like, whether you're writing code in Rust or in Python, there's like always room to like be thinking about performance.

你总是可以让事情变得更快或更慢。

Like you can always make things faster or slower.

即使你用Python写，你也可以通过更深入地思考性能和设计，让事情变得快很多很多。

Like even if you're writing in Python, like you can still make things like much, much faster by like thinking harder about performance and design.

所以是两者的结合，但取决于项目。

So it's some mix, but it depends on the project.

OpenAI、Anthropic、Cursor和Vercel都在用这个产品来改善他们的工作。

OpenAI, Anthropic, Cursor, and Vercel all use this product to make their lives better.

它解决的问题是，当你在做SaaS或AI产品，想卖给其他公司时，你需要满足很多要求。

And the problem it solves is when you're building SaaS or an AI product and you wanna sell to other companies, there's all these requirements you need to meet.

比如SSO、SCIM、RBAC、审计日志这些。

There's SSO, there's SCIM, there's RBAC, there's audit logs.

这些东西集成起来很花时间，但不是你应用的主要焦点。

These are all things that take time to integrate but aren't the main focus of your app.

WorkOS是一个API层，让你只需几行代码就能满足所有这些要求。

WorkOS is an API layer that lets you meet all of these requirements in just a few lines of code.

比如说你有一个新的SaaS产品，想卖给其他公司，WorkOS会帮你解决所有这些关键的功能缺口。

So let's say you have a new SaaS product and you wanna sell to other companies, WorkOS will solve all of these critical feature gaps for you.

你可以去workos.com看看，了解更多并开始使用。我很感谢他们支持我的工作并赞助这个播客。

You can check them out at workos.com to learn more and get started, And I appreciate them for supporting my work and sponsoring this podcast.

在整个项目过程中，你有没有几个你觉得技术上最有挑战性或最感兴趣的实现？

Over the course of the project, do you have a, you know, top few things that were implemented in the project that were technically challenging or most interesting to you?

我真的很喜欢我们团队里Andrew做的一个优化，他的网名是burnt sushi。

I really like this optimization that Andrew on our team who goes by burnt sushi.

他是rip crap的作者，还做了很多其他东西。

He's the author of rip crap and a bunch of other things.

他真的是个非常出色的工程师。

He's like really amazing engineer.

他在我们如何表示版本方面做了一个很酷的优化。

He did this really cool optimization around how we represent versions.

挺棒的。

It's pretty cool.

我的意思是，基本上如果你考虑解析和安装一个非常复杂的Python项目，我们会发现需要解析和创建很多版本，比如1.0.1、1.0.2，就是程序里的版本对象。

I mean, basically like if you think about resolving and installing like a very complex Python project, it turns out that we have to like parse and create lots of versions, like as in 1.0.1, 1.0.2, like we just like version objects within the program.

我们最终会解析和创建很多这样的版本。

Like we end up parsing and creating a lot of those.

而且事实证明，考虑到我们做的次数和规模，分配这些内存其实很昂贵。

And it turns out that actually like allocating that memory was expensive given like the scale, like the number of times we were doing it.

他想出了一种表示方法，可以用一个64位整数来表示大约百分之九十多的版本。

And he came up with a representation where we can represent like 90 something percent of versions with a single use 64 integer.

所以这样效率就高多了。

So it's just like way more efficient.

而且相关的基准测试和实现都特别酷。

And the benchmarks around that and the implementation were very cool.

我觉得这是我读过的最棒的PR之一。

It's like one of the coolest PRs I've read, I think.

在TY，也就是我们的类型检查器里，有很多非常有趣的性能优化工作，尤其是为了让它支持增量检查。

In TY, which our type checker, there's a lot of like very interesting performance work that's happening, especially to make it incremental.

TY的设计目标就是既做类型检查器，又做语言服务器。

So like TY is designed to be a type checker and a language server.

整个系统都是高度增量的。

And the whole system is like highly incremental.

它的思路是，如果你在文本编辑器里打开一个文件，你肯定不想为了分析这个文件，就把整个项目都检查一遍。

So the idea there is like, if you're in a text editor and you open up like one file, you don't necessarily wanna like have to type check your entire project.

包括所有依赖、项目里的每个文件，都检查一遍，那太麻烦了。

Like all your dependencies, every file in the project, just to get analysis for that file.

因为没必要嘛。

Like, because you don't need to.

那怎么做到这一点呢？

So how do you make that work?

这有点像，就是那种懒加载。

That's sort of like, that would be like lazy.

你得懒一点。

You want to be lazy.

但另一方面，如果你打开一个文件并编辑它，或者打开两个文件，你编辑其中一个。

But the other piece to that is like, if you have a file open and you edit it, or you have like two files open, you edit one of them.

你只想重新计算那些必须重新计算的部分。

You only want to recompute like exactly what you need to recompute.

你不想再去重新检查整个代码库。

Like you don't wanna have to go and retype check like the entire code base again.

特别是如果你在一个大项目里工作，比如 PyTorch，你打开两个文件，编辑其中一个。

Especially because maybe you're working in a big project like PyTorch and it's like, you have two files open, you edit one of them.

你不想它那样，然后你保存。

You don't want it to like, and then you save.

你不想它花两秒钟重新检查整个项目，然后给你一个新的分析结果。

You don't want it to take like two seconds to like retype check the project and like give you a new analysis.

所以整个系统都是围绕查询构建的，这挺有意思的。

So the whole system is built around queries, which is pretty interesting.

这更多是宏观设计层面的东西，但我们是在一个叫Salsa的框架上构建的，Rust分析器也用它，就是那个很流行的Rust语言服务器。

This is more of like a macro design thing, but we built it on top of a framework called Salsa, which is also what Rust analyzer uses, which is like the popular Rust language server.

现在我们有意识或无意识地成了Salsa的主要贡献者。

And now we've intentionally or inadvertently become like very large contributors to Salsa.

整个系统都是围绕这个构建的，从架构上看非常有意思。

But the whole system is built around that, which has been like very interesting architecturally.

有意思。

Interesting.

所以它是惰性的。

So it's lazy.

所以它不会对整个代码库进行类型检查，而且是增量式的。

So it doesn't type check the whole code base and it's incremental.

增量部分是最难的，因为你基本上需要一种方式来建模代码中所有事情的依赖图。

The incremental part is the thing that's hard because you kind of need a way to basically like, it needs to be able to model kind of like a dependency graph of like everything that's happening in the code.

所以当你改变某些东西时，我们只想让数据流经所有不同的部分。

And so then when you change something, we wanna just like flow the data back through all the different pieces.

只影响那些需要影响的部分。

Like only the pieces that you Only to pieces that you to.

这花了很多功夫，但现在已经整合好了。

That took a lot of work, but it has come together.

我最近用Codex做了很多优化，因为它特别擅长微优化。

And I've been doing a lot of optimization lately with Codex because it tends to be very good at, especially at like micro optimizations.

比如，在TY中，我们还需要多考虑内存，不仅仅是速度。

Like if I'm like, and in TY in particular, we also need to think a lot about memory, not just speed.

因为如果你在一个非常大的项目上工作，你不想让语言服务器占用很多很多GB的内存。

Because if you work on a very large project, like you don't want it to take like many, many, many gigabytes of, just to like run your language server.

理想情况下，你希望它相对高效。

Like ideally you want it to be like relatively efficient.

所以我现在花很多时间持续优化内存使用和性能。

So like I spend a lot of time now kind of like continuously optimizing like memory usage and performance.

我可以设定一个目标，比如在这个项目上把Salsa的内存占用减少1%。

And I can just set a goal that's like try to reduce memory, like Salsa memory by like 1% on this project.

而且，你不能做那些你可能想尝试的事情。

And like, you can't do like these things that you might like try to do.

它非常擅长提出非常合理的方案。

And it's very good at just like coming up with like very reasonable things.

所以，我也不知道。

And so, I don't know.

我觉得这很酷，因为它几乎可以持续……我不会说自我优化。

I find that very cool because it's kind of like, can almost have like continuously op I won't say self optimizing.

这听起来有点夸张，但你可以持续地优化你的软件。

That's like a built grandiose, but you can kind of be like continuously, like just like optimizing your software.

所以我一直很喜欢这个，但大多数这些优化都是，想办法用更少的内存来表示东西，或者有时候是尝试进行更广泛的重新设计，比如修复病态性能问题。

So I've been enjoying that a lot, but most of those are like, Trying to find ways to like represent things that take up less memory or trying to come up with like, sometimes it's like trying to come up with a broader redesigns, like fixed pathological performance.

那个关于版本编号的优化，看到你可以把它限制在一个 u64 里。

That one optimization where with the version numbering and seeing that you can limit it just to, like, a u 64.

如果你回想一下那些更有创意的优化，那是在人类时代完成的。

If you think back to some of these more creative optimizations that were done, that was in the human era.

你觉得如果你，我不知道，运行 Codex，然后说，嘿，别搞坏东西，但降低内存。

Do you think if you just, I don't know, ran Codex and you're like, Hey, just don't break things, but lower.

你相信它能想出那个方案吗？

Do you have faith that it would come up with that?

还是说那有点超出它的能力范围？

Or is that kind of a step above what

这是个很有意思的问题。

That's a very interesting question.

至少以我的经验，如果你只是让这些工具把内存或性能优化几个百分点，它们通常会在边缘做些小改动，而不是进行更大的重新设计或重新思考。

If you just, at least in my experience, like if you just ask these things to reduce memory or improve performance by some moderate percentage, it will typically come up with things around the edges as opposed to like larger redesigns or reconsiderations.

但如果你提示并和智能体协作，你就能达到那些更大的重新设计。

But you can get to those larger redesigns if you prompt and collaborate with the agent.

所以如果你问，比如，我们是不是应该从更大的角度思考，为什么我们必须用这种方式表示数据？

And so if you sort of ask like, well, like, should we be thinking of it bigger about like why we have to represent the data this way?

这样你就能得到更大的想法。

Like you can get to like bigger ideas.

所以这可能是一个你可以通过提示达到的想法，如果你说，你知道，好吧，让我们从性能分析开始，找出我们在哪里花费了大量时间。

And so that might be an idea that you could have gotten to with prompting if you were like, you know, okay, let's start by like profiling and figuring out where we're spending a lot of time.

然后也许，你知道，它最终会回来告诉你，我们在版本解析、版本丢弃和版本分配上花费了大量时间，等等等等。

And then maybe the, you know, it would eventually come back to you and say like, we're spending a lot of time in like version parsing and like version drop and version allocation and like blah, blah.

然后我们会说，好吧，那我们怎么才能更紧凑地表示这些呢？

And we'd be like, okay, well like how could we represent these like more compactly?

我们可能会先找到表示上的微优化，比如，这个字段，你把这两个字段合并起来，节省几个字节，等等等等。

And we'll probably start by finding like micro optimizations in the representation of like, well, this field, like you combine these two fields to like save a few bytes, blah, blah, blah.

但我认为如果你继续推动它，它有可能达到那个目标。

But I think if you kept pushing it, like it's possible it would get there.

但这并不是默认就能想到的东西。

But that's not the thing that's gonna come up with by default.

Mitchell Hashimoto，HashiCorp的创始人之一，现在在做Ghosty。

Mitchell Hashimoto, who was like one of the HashiCorp founders works on Ghosty.

他发了一篇很有见地的帖子。

He had a post that was insightful.

我上周或者这个周末想到他写的一个渲染器，那个渲染器真的很糟糕。

I thought last week or this weekend about a renderer he wrote, where it was like a really terrible renderer.

我可能会把那条推文说错，但大概就是，那个渲染器真的很糟糕。

I'll probably butcher the tweet, but it was like, was it a really terrible renderer.

然后他不是故意的，后来他让一个LLM去优化它，结果速度快了十倍。

And then he hadn't like intentionally, and then he had an LLM like optimize it and it made it like 10 times faster.

他就说，太好了。

And he's like, great.

对吧？

Right?

其实，我手写的版本要快上一百倍。

Actually, like my handwritten version was like a 100 times faster.

就是说，如果你不靠脑子从基本原理出发去想，它应该有多快？

And it's like, you know, like you lose, if you're not like using your brain to like think about from first principles, like how fast should it be?

还有系统应该怎么运作？

And like, how should the system work?

然后你就把这些积累的东西一股脑发出去，我不一定说那是垃圾，但你就是把这些东西发出去，然后说，天哪，我让它快了十倍，但实际上它应该快一百倍才对。

Like, then you just like ship all this, these like accumulated, like, I mean, I won't necessarily call it slop, but it's like, you just ship these like things and you're like, yeah, oh my God, I made it 10 times faster, but really it should be like a 100 times faster.

所以我觉得，这不应该有什么争议。

And so I think, I don't know, it shouldn't be controversial.

现在还是有很多地方需要动脑子的。

There's still a lot of room for like using your brain.

对吧？

Right?

我确实觉得，我在这方面经常纠结。

I'm like, but I do think it's like, I struggle with this stuff a lot.

其实，我写软件的方式变化很大，而且你知道，我团队里也有人，因为我大量使用智能体，而且某种程度上也是在推动团队更多地使用智能体。

I mean, like I'm changing how I write software a lot and, you know, I've had people on my team, like, cause I'm using agents a lot and also it was, you know, to some degree trying to like push our team to like use agents more.

对我来说，其中一部分原因是，我们为软件工程师开发工具，而现在很多用户都在用智能体。

I mean, some of that for me came from a place of like, build tools for software engineers and a lot of our users are now using agents.

所以，如果我们做得好的一切，虽然有点夸张，但如果我们做得好的一切都源于对用户及其工作方式的深刻理解，那么我们也应该使用智能体，了解用它们开发软件是什么感觉，这样才能为用户打造更好的工具。

And so if we like, if everything good that we do, that's an exaggeration, but if everything good that we do comes from like understanding our users very well and like how they work, then like we should probably be like using agents that we understand like what it's like to build software with them so that we can build better tools for our users.

这是我的一部分动机。

That was part of my motivation.

另一部分就是看到它如何改变你的工作方式。

And part of it was just kind of seeing how it can change, like how you work.

我不知道，我觉得我发布的东西多了很多，但这个过程确实很艰难。

And I don't know, I think I'm shipping a lot more, but it has been like, it has been like a difficult process.

比如，团队里有人告诉我，我觉得他们能告诉我这些很好，但他们会说，以前你每次提交PR，我基本不用怎么审查。

Like I've had people on the team tell me, which I think is great that they tell me this, but they're like, oh, it used to be the case that like, whenever you put up a PR, could like review it pretty minimally.

因为我对你的工作很有信心。

Cause I had a lot of confidence in it and like your work.

现在呢，你一发PR，我还真得仔细看，因为你都不自己写了。

And now it's like, when you put up a PR, I actually have to review it really closely because you're not like writing anymore.

都是那个智能体在写。

It's like the agent.

我当时就想，哇，这对我来说真的很有意思。

And I was like, wow, that's like very interesting to me.

他们说得完全对。

They're completely right.

我自己也是这样。

And the same thing happens to me.

比如我要是去睡觉，早上醒来看到自己发的PR，就会想，等等，这写得也太烂了。

It's like, if I go to sleep and then wake up in the morning and look at one of the PRs I put up and I'm like, wait, this is terrible.

你懂我的意思吧？

You know what I mean?

就是说，你很容易骗自己，觉得那些活儿干得还行，但其实根本达不到你以前的标准。

It's like, can, it's just, it is easy to trick yourself into like basically believing work that isn't at the same standard as what you would do before.

而且我觉得，我们其实不太知道该怎么处理这件事。

And I don't think, I think we have, we don't really know what to do with that.

我也在慢慢学习，慢慢进步。

And I'm kind of learning and getting better.

我的意思是，我觉得我现在做得比二月份那会儿好多了，那时候我基本上全是靠AI代理在写。

And like, I mean, this was, I think I'm doing a lot better job now than I was in like probably, you know, like February or something where I was like, I was just like, you know, fully agent filled.

所以我的重点是，当团队里有人说出那句话的时候，对我来说真的是一个很有力的时刻。

And I'm like, now I'm like a little bit more like, but so my point is like, that was like a pair of powerful kind of like moment for me when someone on the team said that.

我当时就想，哇，你说得对。

And I was like, wow, like you're right.

而且我在团队其他人的工作里也看到了同样的问题。

And I see that in other people on the team's work too.

这不只是我一个人的问题，但确实，它真的让很多事情都颠覆了。

Like it's not just limited to me, but it's like, you know, it really does throw a lot of things on their head.

如果你生成的全是垃圾，那倒是容易。

If you generate pure slop, that's easy.

但我觉得中间有个灰色地带，你生成的东西部分是AI垃圾，或者说，你知道，它勉强能接受，但没达到你以前的标准。

But I think there's this gray area where you generate partially AI slop or it's, you know, it's acceptable, but it's not at the bar that you used to have.

你在团队里用过哪些办法来对付这种灰色地带的AI垃圾？

Do you, what are the tactics that you've used on the team that have worked for combating this kind of gray area AI slop?

我希望有一天能到那种境界，我们现在还没到。

I'd like to get to a world, we're not here.

而且我不知道我们能不能达到。

And I don't know if we'll ever get there.

我希望有一天，如果你提交一个PR，所有检查都通过，那它被合并的概率就非常高。

I'd like to get to a world where if you put up a PR and it's all green, then the odds of it getting merged are like extremely high.

对吧？

Right?

因为那意味着你大部分关键的东西都有自动化验证了。

Because that would mean that like you have automated verification for like most of what matters.

我们的项目里已经有很多这样的验证了，而且我们一直在努力增加更多。

And we have a lot of that in our projects and we've tried to add more over time.

我觉得这挺有帮助的。

And I think it's helpful.

比如在TY项目里，我们有很多基准测试，每次提交PR都会在Valgrind下运行，比如Cod speed之类的。

Like we have, like in TY especially we have tons of like benchmarks like that run under Valgrind, like Cod speed, like on every PR.

所以我们会得到这些结果，而且包括内存使用情况。

So we get like, and that includes memory.

所以我们每次提交PR都会基准测试内存使用、模拟时间和墙钟时间。

So we benchmark like memory usage and simulation time and wall time, like on on every PR.

然后我们还有一大套生态系统测试。

And then we also have a really big suite of ecosystem tests.

基本上每次你提交PR，我们都会在生态系统中的一堆项目上运行前后对比。

So basically every time you put up a PR, we run before and after on like a bunch of projects in the ecosystem.

然后我们会生成一份报告，列出所有诊断的差异，比如新增和移除的错误等等。

And then we create this report of the diff of all the diagnostics, like the errors that got removed and added and everything.

所以随着时间的推移，我们一直在努力增加更多的测试。

So we have like, over time we've tried to do like more and more.

说实话，这些都很重要，甚至在我们有代理之前，基本上没有这些东西我们就没法干活。

These are important, honestly, even before we had agents, like these were like, we basically couldn't build without these things.

但重点是，我想有更多自动化的验证，并且在这方面做得更好。

But the point is like, I wanna have like more automated verification and try to get better at that.

这也包括一些别的事情。

And that includes things too.

我们现在基本上默认，团队里任何人提交PR之前，都已经用Codex review跑过好几遍了。

Like we basically assume now that anyone on the team that puts up a PR has already run that through Codex review, like probably several times.

这基本上就是一个默认的假设。

And that's basically an assumption.

我是说，我们可以把这个过程自动化。

I mean, we could automate that process.

Codex review就是让一个代理去审查代码，再检查一遍。

Codex review is just an agent reviewing the code and double checking.

其实就是运行Codex，然后执行斜杠review命令。

It's just running Codex and then just doing slash review.

明白了。

I see.

就是这样。

That's it.

没什么特别的。

It's not that fancy.

我的意思是，不是，抱歉，它没那么复杂，但就是因为现在，贡献者一提交PR，我们第一件事就是做这个。

Mean, not, sorry, it's not that sophisticated, but it's just like, because now it's like, a contributor puts up a PR, that's the first thing that we do.

对。

Right.

因为它往往能发现好东西。

Because it tends to find good things.

你知道，我觉得我经历过的那些事情……所以基本上我觉得一个方向是，怎么创建更多自动化系统，帮助确保事情做对。

You know, I think the things that I've So like basically I think one bucket is like, how do you create more like automated systems that just help get things, make sure things are right.

这也包括改进你的代理之类的事情。

And that also includes things like trying to improve your like agents.

随着时间的推移，更新那个 Markdown 文件。

Md file over time.

比如，如果在评审中你给出的反馈，代理没有遵守，那就想办法帮助代理学习，甚至学习新技能。

Like if there are things, if there's feedback you're giving in a review that the agent's not respecting, try to find a way to help the agent learn that even learn skills.

比如我们团队有一些共享的技能，类似这样的东西。

Like we have some shared skills on the team, stuff like that.

顺便说一句，这些都不是什么高深的东西。

And so I like, none of this stuff is very sophisticated by the way.

其实挺简单的。

It's like pretty simple.

另一部分就是，我如何确保自己花功夫去创建一个好的 PR？

The other piece is like, how do I make sure that I put in the work to ensure that I'm creating a good PR?

对我来说，这意味着我真的需要理解。

And so for me, that's like, I really should understand.

再说一次，这听起来门槛很低，但我确实应该理解 PR 中的每一行。

It's again, it sounds like a not, it really sounds like a low bar, but I should understand like each line in the PR.

我知道这听起来很疯狂。

I know it's crazy.

但我也确实会在GitHub界面上自己审查每个PR。

But also I do try to review each PR myself in the GitHub UI.

这一直让我觉得特别有用。

This is something I've always found really helpful.

比如你真的打开你的PR，点击文件，像审查者一样通读一遍，你往往会发现那些你平时会忽略的问题。

Like if you actually just like open up your PR and click files and read through it as if you were a reviewer, you tend to find things that you would miss.

如果你只是看本地的diff，我觉得那样特别有帮助。

If you were just looking at your local diff, I find that very useful.

然后另外一点就是尝试把技能编码进去。

And then the other is trying to like encode skill.

我觉得这更偏向第一类，但就是尝试把技能编码进去，或者把那些我和代理都持续犯的错误编码进技能里。

I guess this is a little bit more in the first category, but trying to encode skills or trying to encode in skills, things I can continue consistently getting wrong that the agent is getting wrong.

比如我最近有个例子，我发现自己经常收到关于NPR的反馈，形式是这样的。

Like I had, like a recent example would be, I found that I was often getting feedback on NPRs that was of the form.

你说，这个条件，这个if语句，它到底是想捕获什么情况？

What, you know, this condition here, this like if statement, what case is this intended to catch?

因为如果我把它注释掉，所有测试都能通过。

Because if I commented out all the tests pass.

所以我就想，好吧，我应该在提交任何PR之前，先让agent去检查一下，这些条件是不是还有用，还是说它们是从某个属性工厂或者其他地方遗留下来的。

And so I was like, okay, I should probably have a pass before I put up any PR where I have the agent like go through and check like, are these conditions still relevant or are they left over from a property factor or something else?

所以我也说不好，我还在学习，但这就是我一直在做的一些事情。

So I don't know, I'm not, I'm still learning, but those are some of the things I've been doing.

再说一次，我觉得现在做软件开发确实挺难的，但很长一段时间里，我一直担心AI会让我们更高效，但编程会变得没那么有趣，因为我真的很喜欢编程。

It's again, I think it's like a, it's a pretty hard time to be like building software, but I felt for a long time, or I had a fear that AI was going to make us more productive, but that programming would be like a lot less fun because I just like love programming.

我当时就想，哦，现在我得把所有时间都花在审查代码上，还得给这个笨agent下指令，它老是出错。

And I was like, oh, now I'm gonna have to spend all my time like reviewing code and like prompting this like idiot agent to like, that's like, he's getting things wrong.

但最终，这可能是更高效的。

And like, but ultimately like is probably more productive.

实际上，我现在对这件事的感觉比几个月前好多了。

I actually feel way better about that right now than I did like a few months ago.

我也不太清楚为什么。

And I don't exactly know why.

我觉得可能是因为，嗯，代理在变好，工具也在变好，我自己也更熟悉了，这是一个因素。

Like, think it's because, well, I think the agent's getting better and the tooling getting better and me getting more comfortable with it is one factor.

另一个原因是我越来越欣赏和代理合作带来的各种可能性。

I think the other is, I've grown to appreciate more of the kinds of things that like working with agents has unlocked.

比如做实验的成本变得非常低。

Like the cost of running an experiment is incredibly low.

有很多我一直想尝试的事情，或者想解答的问题，现在几乎可以立刻得到答案。

There's so many things I've wanted to try or like questions I've wanted to answer that I can now answer like almost instantly.

举个简单的例子。

I, a sort of a dumb example.

在UV里，所有东西都有快照测试。

In UV, everything is snapshot tested.

所以基本上我们的所有测试实际上就是运行UV，然后验证输出结果。

So like basically all of our testing is effectively running UV and verifying the output.

基本上整个程序都是这样测试的。

That's how we test like basically the entire program.

所以这意味着，我们有很多测试。

And so that means, and we have a lot of tests.

也就是说，我们有很多测试输出。

That means we have a lot of tests output.

而这些测试输出，实际上最终会出现在测试文件里。

And the test output is, it actually ends up in the test files.

所以我们有Rust文件。

So we have Rust files.

比如我们有一个叫lock的文件。

Like we have a file called like lock.

Rs文件，用来测试我们所有的UV锁。

Rs that tests all our UV lock.

这就是我们所有的UV锁测试。

It's all our UV lock tests.

而且它非常非常长，部分原因是测试里把所有锁的输出都做了快照。

And it's very, very long in part because it has all the lock output snapshotted in the test.

我当时就想，要是把快照存到单独的文件里会怎么样？

And I was like, like what if we stored the snapshots in separate files?

那样会不会让编译更快，因为从技术上讲，那些就不是Rust代码了。

Like would that somehow make our like compiles faster because then you don't have technically that's like Rust code.

所以就想，那样是不是就全都消失了？

And so it's like, would that all disappear?

然后就想，那样会不会让构建更快之类的。

And like, would that make like our builds faster or blah, blah, blah.

我一直想这么做，但听起来，作为人类去做那个实验会非常痛苦。

And I'd always want to do that, but it sounded like, like to do that, to do that experiment as a human would be like extremely painful.

因为你得转换所有那些测试。

Cause you have to convert all of those tests.

然后我就让一个智能体在后台做这件事，同时我去做其他一堆事情。

And I just had an agent do it in the background while I did a bunch of other things.

我收集了不少相关数据。

I got a bunch of data on it.

答案是：不会。

And the answer is no.

但你懂我的意思吧？

But it's like, you know what I mean?

我是说，抱歉。

Like, mean, sorry.

答案其实要更复杂一些。

The answer is a little bit more nuanced.

它确实有积极的影响。

It actually does have a good impact.

如果你只是在调整快照输出，你根本不需要重新编译程序。

If you're just iterating on the snapshot outputs, you no longer have to recompile your program at all.

因为这些输出被存储在其他地方。

Because this outputs are stored somewhere else.

总之，这就是对你产生影响的关键。

Anyway, that's the thing that makes a difference on you.

但我的意思是，我整天都在做这样的实验，尝试那些以前很难、成本很高才能回答的事情。

But my point is I'm just like running experiments like that, like all day, like trying things that were used to be hard, like used to cost a lot to answer.

从实验到真正投入生产，中间还是有不少实际工作要做。

The work of then going from that to like production, there's still like real work there.

所以，你知道，我觉得一方面工具和智能体在变得越来越好。

But so, you know, I think one piece is the tools and the agents getting better.

另一方面，有些我以前根本做不到的事情，现在可以非常轻松地完成。

The other is things that I just wouldn't have been able to do before that I can now do like incredibly easily.

然后第三点，我越来越意识到，我从开发软件中获得的很多价值是保留的。

And then the third is, I think I'm more and more realizing that like a lot of the value I get from building software is retained.

因为其中一部分是深入思考，比如不一定非要写代码，而是仔细考虑数据结构的设计。

Because some of it is like thinking hard about like the, doesn't have to be typing out the code, but it's like thinking hard about like the layout of a data structure.

很多工作就是合并一个能解决用户问题的拉取请求。

A lot of it is merging a PR that closes a user issue.

我其实从修复和改进东西中获得了很大的满足感。

I get a lot of satisfaction from actually like fixing and improving something.

不仅仅是写代码本身。

It's not necessarily just from typing out the code.

所以我真的很理解那些觉得和智能体一起工作会失去什么的人，因为我也有同样的感觉。

So I do feel for people a lot who feel like they're losing something by like working with agents, because I do feel that myself.

但和几个月前相比，我现在对作为软件工程师和智能体一起工作的感觉好多了。

But I feel better now than I did a few months ago about my, like what it's like to work as a software engineer with agents.

你之前提到，在性能优化的例子里，你说如果直接放开Codex，它会做局部优化，而且很擅长，但在系统级优化上，它不太行，这更多需要人类的智慧。

You mentioned in the, like one of the performance optimization examples, you said if you just unleash codex, it kind of does this local optimizations and it's very good at that, but it's not great at kind of like some of the, I mean, today, it's more human ingenuity of, system level optimizations.

这让我想起你发过的一条推文。

And it kind of reminded me of this tweet that you had.

你说，如果没有丰富的软件工程经验，用这些工具会产出大量垃圾，这让我有点担心。

You said it says, I'm slightly concerned by how much garbage I would be churning out if I was trying to use these tools without significant software engineering experience.

我仍然担心这一点。

I remain I remain concerned about that.

这让我想起了你提到的Mitchell Hashimoto的那条推文。

It it reminds me and similar to what the Mitchell Hashimoto tweet that you said.

就是说，让Codex直接去做某件事，和你把它当作工具来用，引导它往正确的方向走，这两者之间差别很大。

It was like, there's a very big difference between Codex go and do this versus, you know, you are, like, wielding it like this tool, and you're kinda, like, prodding in the right direction.

我很好奇你怎么看这个，因为那条推文好像挺火的。

I was curious of your thoughts on that because it seemed like it went pretty viral.

我觉得很多人都在思考这个问题。

And I think a lot of people are thinking about that.

成为一名优秀的软件工程师比以往任何时候都更有用。

Like being a great software engineer is like more useful than ever.

我还是觉得，我们团队里那些工程能力最强的人，即使在使用智能体方面也是最有效的。

Like, I don't like, it's, you know, it's still the case that I think that the people on our team who are like the strongest, like software have the strongest engineering skills are like the most effective, like even at using agents.

而且，有意思的是，现在有很多关于“token最大化”的讨论，你听说过这个吧？

And, you know, it's funny because there's a lot of talk about like token maxing, if you're familiar with this, right?

就是说，比如要不要搞个排行榜，很多公司都在搞token排行榜，这个话题被讨论得很多。

The idea of like, should you have a leaderboard, for example, this is getting tweeted about a lot companies that have token leaderboards.

这就像，你怎么制造一些糟糕的激励，让大家尽可能多地用token呢？

And it's like, how do you like create some terrible incentives to just like use as much tokens as possible?

有意思的是，我们确实有追踪这个，或者说，抱歉。

And it's funny because we do, that does get tracked or sorry.

虽然没有排行榜，但token使用量是可以查的，比如在公司内部。

There's not a leaderboard, but like token usage is something you can like look up for example, you know, internally, I mean.

看这个挺有意思的，因为我不在乎团队里谁用的token最多。

And it's interesting to look at because I don't care like who on the team is using the most tokens.

而且团队里有些人，我其实在刻意不去关心这个。

Like, and there are people on the team who are like, I'm like actively trying not to care about that.

比如我在token排行榜上的位置，我觉得这挺好的。

Like being where I am on the token leaderboard, which I think is like, great.

我真的不在乎。

Like, I don't care.

他们不需要，他们只需要把工作做好就行了。

Like they don't have, like they should just do like, do a great job.

而且，这没什么问题。

And like, that's fine.

我不在乎他们用多少token。

I don't care if they use a lot of tokens or not.

但看看token排行榜确实挺有意思的，因为团队里一些最高效的人，用的token也挺多的。

But it is interesting to look at the token leaderboard because some of the people on the team who are most productive are like using like a lot of tokens.

对吧？

Right?

感觉就是，这两者之间好像有点关联。

It's like, there is like a correlation.

我不是说这是因果关系，但我觉得很多优秀的工程师确实能很有效地使用agent，希望能借此放大他们的技能。

I'm not saying it's causal, but I'm saying like, I do think that a lot of great engineers like are able to like use agents very effectively and like to hopefully to like multiply their skills.

所以我觉得现在对于刚入行的软件工程师来说，真的挺难的。

So I do think it would be like really hard to be an early career software engineer right now.

而且我现在也没花太多时间跟刚入行的工程师打交道。

And I'm not spending that much time with early career engineers right now.

就拿 Astral 来说，我们团队很小，而且倾向于招资深的人。

Just based on like at Astral, we're just a very small team and we tended to hire very senior.

但对我来说，很难想象，基本上，我会怎么学呢？

But it is sort of hard for me to think about like, would we, like, how would I learn basically?

迭代循环会是什么样的？

Like what would the iteration loop be?

我想我大概会从 Codex 那里学习，而不是反过来。

I would be like learning from Codex, I guess, as opposed to like the other way around, basically.

我的意思是，很多时候其实是我在指导 Codex，对吧？

I mean, like a lot of the times I'm actually like instructing Codex, right?

然后试着纠正它，给它加个保护措施，不管是 Opus 还是你用的其他工具。

And like trying to correct it and priding a safeguard on it or Opus or whatever you're using.

所以，是的，我觉得我真的不知道你会从哪里得到这些，太容易陷入使用代理时发生的那些坏事了。

And so, yeah, I think I just don't know like where you would get, it would just be way too easy to fall prey to like a lot of the bad things that happen when you use agents.

你用 Rust 做了这个概念验证，反响很好，但你为什么围绕它成立了一家公司？融资过程怎么样？

You built this proof of concept in Rust and it was really well received, but why did you start a company around it and how did the, like the raising go and all of that?

那当时的动机是什么呢？

What was the motivation there?

所以我离开了Spring。

So I left spring.

其实是一个朋友说服我离开的，他是我很亲密的朋友，差不多同一时间离开了Meta。

I was actually convinced to leave by a friend who, a very close friend who left meta around the same time.

他说，我们应该一起创业。

And he was like, we should start a company together.

我就说，好吧，行。

And I was like, okay, fine.

其实也没那么简单。

I mean, it wasn't quite that simple.

但我确实离开了，然后我们就进入了所谓的“想法迷宫”，想我们到底要做什么。

But I did, I left and then we kind of went into the quote unquote idea maze of like, what do we wanna build?

我们开始的时候并不知道要做什么。

We went into it not knowing what we wanted to build.

我们花了很多时间探索各种想法的交集，比如他感兴趣的东西我觉得没意思，反之亦然。

And we spent a bunch of time exploring the Venn diagram of ideas of like, there were things he was interested in that I thought were not interesting and vice versa.

然后中间有一些共同感兴趣的东西，我们就花时间去研究那些。

And then there was some stuff in the middle and we spent time exploring the stuff in the middle.

但在所有空闲时间里，我都在搞开发者工具。

But then in all my spare time, was working on like developer tools.

因为那才是我真正觉得有意思的。

Because that's what I thought was really interesting.

而他呢，基本上不太适合这个。

And he, it wasn't quite like a fit for him basically.

但那时候我在做Ruff。

But around then I was working on Ruff.

我还做了其他几个项目，你可以在我的GitHub上看到，可能没那么有意思，但当时我就是在尝试各种不同的东西。

I was working on a couple other projects that you can see in my GitHub that are like, I don't know, probably not as interesting, but they were like, I was like experimenting with like lots of different things at the time.

比如我对WebAssembly特别感兴趣。

Like I was pretty interested in WebAssembly.

我用TypeScript写了一个类似CI/CD的工具包。

I wrote a sort of like a CICD toolkit in TypeScript.

差不多就是你在TypeScript里写流水线，然后它会转译成Docker。

It's sort of like you wrote pipelines in TypeScript and it transpiled them to Docker.

我当时就想，哦，这个可能挺酷的。

And I was like, Oh, this could be cool.

就像保罗，我也不太清楚。

Like Paul, I don't know.

我当时就在搞这些东西。

I was like building all this stuff.

那时候，我决定开始跟投资人建立关系，但还没准备好去融资。

And at that point in time, decided I wanted to start developing relationships with investors, but that I wasn't ready to raise money.

因为我还不知道我到底要做什么。

Cause I didn't know what I was actually gonna build.

所以我的想法是，先试着联系一些喜欢投资这类东西的人，打算过三到六个月再回头找他们，说，嘿，我们之前聊得挺好的。

And so my thinking was, I'm gonna try to like get connected to some people who like to invest in this kind of stuff with an eye towards reaching back out to them in like three to six months and being like, Hey, we had a great conversation.

现在我正在做X。

Now I'm working on X.

所以当时我就是这么想的。

So that was my thinking.

所以我联系了一些投资软件基础设施和开发者工具的投资人。

So I got connected to a couple of investors who invest in like software infrastructure and developer tools.

我们聊得还不错。

And I had some good conversations.

但问题是，事情变化得太快了。

And then like the problem is things just can move really quickly.

我本来没打算这么快就开始融资，但基本上被说服了。

And so I didn't actually expect to like start raising so soon, but I effectively got convinced.

与此同时，Ruff也在快速发展。

And at the same time, Ruff was growing a lot.

所以我基本上被说服了，觉得有足够的基础去创办一家公司，这个过程非常有意思。

And so I effectively got convinced that there was enough there to start a company, which is a very interesting process.

我当时想，我不太清楚这怎么变成一家公司。

I was like, I don't quite know how this becomes a company.

但我确实被说服了，觉得有足够的东西可以建一家公司，这挺有意思的。

But I was effectively convinced that there was enough there to build a company, which is interesting.

是被投资者说服的吗？

By the investors?

对此我很感激。

Which I'm grateful for.

另一件我被说服的事情是，挺搞笑的，就是如果我讨厌它，我可以在六个月内停下来。

The other thing I was convinced of was, which is funny is if I hated it, I could stop in like six months.

就是说，如果你觉得不适合你，你可以把钱退回去。

It's like, if you decide it's not for you, you could like give the money back.

这是投资者说的。

The investor said that.

是的。

Yes.

我觉得这其实挺高明的。

Which I actually think was brilliant.

因为我可能根本不会那么做，但确实让我觉得压力小了很多。

Cause like I was probably never gonna do that, but it did make me feel like there was less pressure.

抱歉，讲得有点绕，细节比较乱。

So sorry, very like weird roundabout details.

但基本上，我后来就差不多全职在做Ruff了。

But basically like I was like working on Ruff more like full time eventually.

然后有点像和潜在早期投资人合作的感觉，我们会就我的想法进行很长的对话。

And then it was kind of like, I would say collaborative with like the potential early investors where it was like, we would just have like long conversations about like my ideas.

后来就变得很清楚了，就是这里面的东西足够多。

And then it basically become clear that it was like, there's enough here.

就像你和我一起弄出了一个产品路线图，说实话，很多内容和我们最终做出来的东西，以及到目前为止我们做出来的东西，都还挺一致的。

Like you and I like brought out kind of like a product roadmap, which honestly like a lot of it stayed true to like what we ended up building and what we've ended up building so far at least.

从那时起，基本上就变成了，是的，我们想投资你。

And from there basically became like, yeah, we wanna fund you.

比如他们会给出一些条款。

Like here are the terms that we would do.

我当时就想，哇。

And I was like, oh wow.

好吧。

Okay.

所以我想这就要开始了。

So I guess this is happening.

这挺有意思的，我以前从来没做过这种事。

So it was just an interesting and I had never done anything like this before.

我的意思是，我整个职业生涯就是个普通的软件工程师。

I mean, I was just, you know, IC software engineer my whole career.

然后突然之间我就开始创业了。

And then I suddenly I was like starting a company.

有趣的是，我觉得全身心投入去创业这个决定其实没那么大压力。

And it's funny because I actually think like the decision to like go all in and like start the company wasn't that stressful.

其实我觉得很多压力是后来公司开始成功时才出现的。

I actually think a lot of the stress came later as the company started to succeed.

因为一开始我没什么可失去的，但后来公司开始走上正轨，我就想，哇，公司好像真的做起来了。

Because at the beginning I had, I kind of had nothing to lose, But then as the company started to succeed, you know, I was like, oh wow, like the company's kind of working.

接下来会发生什么呢？

Like what's gonna happen from here?

而且我有一个二十人的团队，他们都指望着我。

And I had a team of 20 people who were depending on me.

所以对我来说，作为创始人，我其实挺保守的，但我觉得创业这个决定反而比后来要应对的那些压力大的事情更容易做。

And so I don't know, just for me as a founder, it was like, I'm pretty like risk averse, but I actually found that starting the company was an easier, it was an easier decision than maybe some of the stressful things that came later to navigate.

但这一切发生得很快，而且有点无意中，和投资者形成了一种共生关系，这是我之前没想到的。

But it happened very quickly and sort of unintentionally and in a symbiotic way with investors, which I hadn't really anticipated.

我没想到会有投资者。

I didn't expect the investors.

我以为创始人会急着去融资，求着别人投资呢。

I mean, cause I thought the founders hungry for the fundraising and go, please fund me.

但投资者们是……

But the investors were

我觉得这事儿可以有无数种不同的发生方式。

I think please it can do happen a million different ways.

而且，实际上，我做了三轮融资。

And like, actually, I mean, did three fundraises.

我们做了A轮和B轮融资。

We did a series A and a series B.

我们其实从没公开过A轮或B轮融资的消息。

We actually never even announced the series A or the series B.

它们是在收购的博客文章里被提到的，但我们有点复杂化了。

They were, I mean, they were announced in the acquisition blog posts, but we sort of complicated.

基本上就是我们一直没来得及去公布。

It's like, we basically just never got around to it.

你们为什么不公布呢？

Why don't you guys publish it?

因为这对人才招聘来说不是好的宣传。

Because this is not good marketing for talent.

其实宣传效果挺好的，但基本上我们总是有各种理由想再等等。

It's good marketing, but basically like we, there kept being like reasons that we like wanted to wait a little bit.

而且对我来说，这总感觉是件很麻烦的事。

And it's also like, to me, it always felt like a lot of work.

然后我就觉得，说实话，这从来都不是最重要的事。

And then I was like, it just never, honestly, it's never felt like the most important thing.

因为我们一直在做很多事情，公司也发展得不错。

Because we were like building a lot of stuff and like the company was going well.

我就觉得，我们不需要这种宣传。

And I was like, I don't, we don't need the marketing.

我们最后确实计划要宣布了，但后来公司被收购了。

We did finally plan to announce it, but then we got bought.

所以就没做成。

So it didn't happen.

但每次融资基本上都是投资者主动找上门的，这算是很幸运，因为公司发展得好，大家都想投，但对我来说，这个处境也挺有意思的。

But each of those fundraisers was like preemptive basically like initiated by investors, which was, which is like, I mean, it's like fortunate because like the company was like going well and people wanted to invest, but it was also just like a funny position to, for me to be in, I guess.

我觉得我一直有点保守，不太积极去主动找钱。

I think I, I think I was just always a little bit conservative and I wasn't super aggressive about trying to go out and raise money.

不过我们很幸运，做的东西大家都很有信心，也很看好。

And, but we were lucky enough to be building things that people really had a lot of confidence in or had a lot of belief in.

这大概给了你很多谈判筹码，因为最好的位置之一就是你可以随时走人。

That probably gave you a lot of negotiating leverage because like one of the best position you'd be in is that you you're willing to walk away.

你不需要这笔钱。

You don't need it.

而且你本来就没主动去找他们。

And by definition, you didn't even come there to begin with.

是他们来找你，说请收下这笔钱。

They came to you and said, please take the money.

这倒是真的。

That's true.

我不敢说自己是个谈判高手，但至少我手里有牌，而且我们运气很好，遇到了好的投资人。

I wouldn't say I'm a great negotiator, but yeah, I guess at least I had a strong hand, but we were very lucky with investors.

我们的投资人非常棒，特别支持我们，而且和我想打造公司的方向非常一致。

We had amazing investors, like super supportive and really like aligned with how I wanted to build the company.

从来没有过冲突，也没有任何压力要求我们做特定的事情，就是纯粹的支持。

Like never any conflict, never any like pressure to do anything specific, like just support.

可能唯一的反馈就是，我可以更激进一些。

And maybe the only thing, maybe the only piece of consistent feedback is that I could have been more aggressive.

但我也说不准。

And, but I don't know.

就是在扩大规模、增长和做更多事情方面，但我喜欢我们的运营方式，而且我们和投资人的合作经历也非常愉快。

Was like just in terms of like scaling and growing and doing more, but I liked the way that we operated and yeah, we just had such good, we had such good experiences with our investors too.

所以我觉得很幸运，因为这种情况很容易变成另一种局面。

So I felt lucky about that because it can easily go the other way.

我猜如果有人投资，那肯定是对未来收入有预期，但这家公司是怎么赚钱的呢？

I imagine if someone invests, there's a promise of future revenue, but how's this company make money?

因为你们把软件免费送出去了，对吧？

Because you guys give away your software for free, right?

去年八月左右我们推出了一个商业产品。

Launched a commercial product in like August of last year.

它叫PYX。

And it was sort of, it was called PYX.

有点像UV的托管版本。

It was kind of like a hosted counterpart to UV.

所以很多UV用户会购买私有注册表软件，而不是用公共注册表，可能是出于安全考虑，或者他们需要发布自己的私有构件之类的。

So like a lot UV users will purchase like a private registry software instead of using the public registries, either for like security or maybe they need to publish their own private artifacts, things like that.

我们基本上建了自己的私有注册表，并且对uv有一流的支持。

And we basically built our own private registry that had some first class support for uv.

这让我们解决了很多在问题追踪器里看到的用户使用其他解决方案时遇到的问题。

And it let us solve a bunch of problems that we saw, you know, in our issue tracker around users using other solutions.

也让我们能很快地构建东西，因为我们把客户端和服务器垂直整合了。

Also let us build something really fast because we like vertically integrated the client and the server.

他们有一些特别的功能，用起来特别快，特别方便。

There were like special things they could do to be like really fast and really easy to use and all that.

我们花了一段时间推广这个产品，收入增长得还挺不错的。

And we spent a while selling that and our revenue actually grew like pretty well.

我是说，虽然不像现在AI时代那样，老是听说哪家公司最快做到一亿收入什么的。

I mean, it wasn't like, I think in this era of AI, you're constantly hearing about fastest company to go to a 100,000,000 in revenue and things like that.

虽然没那么夸张，但我们确实能卖给一些大企业。

It wasn't, it didn't look like that, but we were definitely able to sell this to like some big enterprises.

而且最棒的是，因为我们做了开源，大家都在用我们的开源产品。

And I mean, the cool thing was we had very good, because we built the open source and everyone was using our open source.

所以我们的销售漏斗特别好。

We had a really good funnel.

我们有一批数量不多但质量极高的客户。

Like we had a small number of extremely high quality customers

是

is

我是这么看的。

the way I would put it.

所以我们赚钱的大致思路就是，继续做开源，做工具。

So the general idea for like how we wanted to make money was keep like build open source and like the tooling.

工具本身保持完全免费开源，完全不商业化。

The tooling remains like free open source, like entirely non commercial.

然后我们再做软件。

And then we build software.

就是你在用我们的工具时，自然而然会需要的下一步。

That's kind of like the natural next thing you need when you're using our tooling.

比如你用UV的话，我们可能能帮你解决一些私有仓库的问题。

So if you're using UV, there are likely problems we can solve for you with like a private registry.

然后流程就是，用UV的人遇到这些问题，我们就卖给他们仓库服务。

And then the funnel is like people using UV, they have these problems and then we sell them the registry.

这个仓库服务本来只是我们整个平台的一部分，我们还会卖很多别的东西，比如Python云服务。

And the registry was meant to be like one piece of a platform of like a bunch of different things we sell, like a Python cloud.

所以我们当时就是朝着这个方向努力的。

So that's what we were like building towards.

我觉得这次收购的一个好处就是，我们可以把那个平台的一部分拿出来，基本上免费提供给用户。

I mean, part of the cool thing about the acquisition is we'll be able to take parts of that platform and make it basically freely available.

举个例子，我们做了很多关于Python的工作，你知道，社区里有很多人用Python配合GPU，比如PyTorch。

Like we did just as an example, a big part of that was, we did a lot of like in Python, know, there's a big part of the community that uses Python with GPU's like PyTorch.

然后围绕PyTorch有一个完整的生态系统，有很多软件都是基于PyTorch构建的。

And then there's like a whole ecosystem around PyTorch of like software that kinda like builds against PyTorch.

而且我们，由于各种原因，这方面的用户体验并不好。

And we, that's for a variety of reasons, the ergonomics around that are not great.

比如用起来可能比较麻烦，安装困难，获取困难，安装正确的版本也不容易。

Like it can be kind of hard to work with, hard to install, hard to get, hard to install the right version.

这取决于你用的GPU，还有你安装的CUDA版本，以及各种其他因素。

Depends on the GPU that you have and like what version of CUDA you have installed and like all this stuff.

所以我们尝试用一种特定的方式来解决这个问题，我们构建了自己的发行版。

And so we kind of tried to solve that in a certain way where we built our own distribution.