每月交付 2500 个 PR：Lauren 谈智能体信任阶梯

大家好。今天我又给大家带来了一份惊喜。上次在这个播客节目里，我们请到了 Uncle Bob，聊了软件质量、智能体，还有很多很酷的东西。今天，我们请到了一位非常棒的嘉宾，我非常高兴能欢迎他。他最近在 Twitter 上爆火，聊软件工厂、提升工作质量、提高开发速度，以及如何与智能体一起攀登信任阶梯，从而交付越来越多。他就是 potato。欢迎，非常感谢你来参加。

So, hello folks. I've got another treat for you today. Last time on this kind of podcasty thing, I suppose, we had Uncle Bob and we talked about software quality. We talked about agents. We talked about lots of cool stuff. Now, we have an incredible guest, someone who I'm delighted to welcome on, who's been exploding on Twitter recently about software factories, about increasing the quality of your work, about increasing your velocity and climbing the trust ladder with agents so that you can ship more and more and more. And it is potato. Welcome. Thank you so much for joining.

谢谢邀请。是的，非常兴奋能来这里。我是你的超级粉丝。

Thanks for having me. Yeah, very excited to be here. Yeah, big fan of yours.

我也是你的超级粉丝。我觉得大家一直在说这是技能界的巅峰会面，技能界的奥林匹斯山之类的，因为我们俩都有非常受欢迎的 skill 库。就像我们开始前说的，我还没大量用过你的 skill，我想把你脑子里的精华都榨出来，这样我就能正确地、更好地使用它们。我想从这儿开始：你最近大概 10 天前做了一场演讲，并在 X 上发帖，讲你上个月如何向生产环境提交了 2,500 个 PR，那条帖子在 X 上彻底火了，大概有 300 万浏览量。我看了，非常喜欢，也推荐了。我想把这次访谈做成那场演讲的问答形式，因为我对它有一大堆问题，想深入探讨。我想从你提到的智能体信任阶梯开始：随着你越来越信任智能体，你能让它们做越来越好的事情，或者扩展使用越来越多的智能体。那么，你攀登信任阶梯的故事是什么？当你进入 SpaceX 并开始越爬越高时，那是怎么运作的？

And a huge fan of yours. I think people have been talking about this like it's the meeting of the skill minds, the skill Mount Olympus or something because both of us have very popular skill libraries. I've not, as I was saying before we started, I've not used a ton of yours and I want to get all of the juice out of your brain so that I can go and use it properly and use it better. And I think where I want to start with this is you gave a talk pretty recently, about 10 days ago, and posted on X which went absolutely nuts about how I shipped 2,500 PRs last month to production, got about 3 million views or something on X. And I watched it and I loved it and I recommended it and I kind of want to run this as almost like a Q&A of that talk basically, giving you because I just had tons of questions about it and I wanted to dive into it. And I think where I want to start is you talk about a trust ladder with agents where as you trust agents more, you can get them to do better and better things and or scale them up to use more and more agents. So what is your story of how you climbed the trust ladder and how did that work when you got SpaceX and started climbing more and more?

我觉得这段旅程甚至在我加入 Cursor（现在叫 SpaceX AI）之前就开始了。故事是这样的：在 Meta 之后，我曾是 Meta React 团队的成员。我休了一个月的假，因为有点倦怠了。当然，倦怠的时候你会做什么？你会开始一个新的副业项目。于是我开始了一个副业项目。当然，我用 AI 来写代码。但后来我开始意识到，我花了太多时间只是微观管理一个智能体。当时是二月份，也许是二月初或一月份，人们非常痴迷于编排这个概念。那是在 Cursor 的智能体窗口流行之前。所以人们还在终端里，都在说“我建了一个自定义编排器”。当然，我有点被这个迷住了，当我在做我的玩具项目时，我被“如何让我的 AI 编码设置更高效”这个问题迷住了。所以我就从那里开始了这段旅程，我退后一步，意识到我把所有时间都花在微观管理一个智能体上。我在创建 skill，发现很难衡量 skill 的输出或结果影响，所以我有点在盲目飞行，但迭代得非常快。那个项目最终成了 PAC 的基础，尽管我当时不知道。我学到的一些技巧，比如构建早期那套 skill。实际上，它仍然是开源的，如果有人想看看的话。在我的 GitHub 上，叫 potato noodle，n o d l e。在那里你会看到一些 skill 和一个 brain 目录。所以我对这个想法非常感兴趣：如何提取我自己的能力，如果这说得通的话，并把它交给智能体。因为我意识到我所做的只是试图教智能体更像我去写代码，更像我去执行工作流。所以 skill 是做到这一点的入口。然后加入 Cursor 后，我开始开发智能体窗口，它有很多性能问题，很卡。因为我有 React 的经验，有人问我：“嘿，你想来帮忙搞智能体窗口吗？”所以 Cursor 旅程的开始非常手动。我深入查看火焰图和堆快照，试图找出应用为什么这么慢。但后来又回到同样的认识：我成了瓶颈。我什么都是手动做。我有点像“人肉代理”，对吧？我是我的智能体和 Chrome DevTools 之间的人肉代理。我对此非常恼火。

So I think this journey sort of began even before I joined Cursor, which is now SpaceX AI. So the story is after Meta, I used to work at Meta on the React team. I took a month off because I was feeling kind of burnt out and of course when what do you do when you're burnt out? You go and start a new side project. And so I started a side project. I was of course using AI to write code. But then I started to realize I was spending like so many hours just micromanaging one agent, right? And at the time, this was back in February, maybe February, early February or January, people were really obsessed with this idea of orchestration. This was before things like Cursor, the agents window had become popular. So people were still in like 2 land in their terminal and they were all talking about okay here I built a custom orchestrator. And so of course I was a bit nerd sniped by that and as I was building my toy project I got nerd sniped by oh how do I make my AI coding setup more efficient and so I kind of started the journey there where I just took a step back and realized I was spending all this time micromanaging a single agent. I was creating skills and I was finding it quite difficult to measure the output or the result the impact of the skill as well so I was kind of flying blind but I was iterating really fast. And so that project eventually sort of became the basis of PAC even though I didn't know it at the time and a lot of some tricks I had learned like building that early set of skills. Actually, it's still open source if you want to if anybody wants to take a look. It's on my GitHub like potato noodle n o d l e. And in there you will see some skills and a brain directory. And so I was really interested in this idea of how do I extract my own ability, if that makes sense, and give it to the agent, right? Because I realized that all I was trying to do was trying to teach the agent to write code more like me, do workflows more like me. So the skills were like an entry point to doing that. And then after I joined Cursor I was starting to work on the agents window and it had a lot of performance issues. It was pretty laggy. And so since I had experience working in React, I was asked like, "Hey, do you want to come and help out with the agents window?" And so this beginning of the Cursor journey was very manual. I was deep in looking at flame graphs and heap snapshots and trying to see why exactly is the app so slow. But then coming back to the same realization like I was sort of the bottleneck. I was doing everything manually. I was sort of the meat proxy in a way, right? I was the meat proxy between my agent and Chrome DevTools. And I was like really annoyed by that.

那是几月份？我们在时间线的哪个位置？

And what month of the year is that? Let's say where are we in the timeline?

我三月份加入 Cursor。所以大概是四月初，我加入的时候没有任何 skill，对吧？我有点放弃了我个人的 skill，因为我觉得它们不再相关了。但后来开发智能体窗口，现在开发 Grok Bot，我意识到我从构建最初那套 skill 中学到的很多经验非常相关，尤其是关于验证、工作中非常严谨这些方面。因为根据我的经验，即使是前沿模型也倾向于走捷径，做容易的事。所以我构建的很多 skill 都是关于如何让容易的事成为正确的事？如何让它成为最好的事？

So I joined Cursor in March. So this was like early April probably early April is when you know I joined and I didn't have any skills, right? I had I sort of abandoned my personal skills because I didn't think they'd be relevant anymore. But then working on the agents window and now working on Grok Bot I sort of realized that a lot of the lessons I had learned from those skill time building the initial set of skills were very relevant especially around things like verification being very rigorous in your work because I think from my experience even the frontier ones tend to take shortcuts. They tend to do the easy thing. So a lot of the skills that I've built have been around how do I make the easy thing the right thing? You know, how do I make that the best thing?

把专业知识提炼出来，把你每天做的事情变成流程，这个想法对我来说太熟悉了。这正是我一直在用 skill 做的事情。

The idea of sort of distilling your expertise and turning what you do every day into processes, that's something that feels super familiar to me. That's exactly what I've been doing with the skills.

我想这里面有个问题：很多人觉得，随着人们越来越依赖 AI，领域专业知识正变得越来越没用。你怎么看？就当是我们正式开聊前的一个氛围测试。

And I suppose there's something in that which is a lot of people think domain expertise is getting less useful now as people start to rely more on AI. What do you think about that, just as a sort of vibe check before we start talking?

我反而觉得领域专业知识比以往任何时候都更重要。我好像在 X 上写过这个，但有时候我会把 AI 想成——尤其是随着模型越来越聪明、越来越有能力，前沿模型变得实在太强了，顺便说一句我很喜欢 Opus 5.5——当模型变得非常非常非常强的时候，瓶颈几乎就不再是智能体了，对吧？瓶颈变成了你能否清晰地把自己的意图和目标表达出来，让智能体能够理解并真正执行。所以我认为，拥有大量领域专业知识的人有巨大的优势，尤其是如果你对技术有一点好奇心。我会想到像医生、律师，或者在某个非工程领域有深厚专长的人，只要他们稍微懂一点技术，能琢磨出怎么用智能体，他们其实就能做出非常非常棒的产品，对吧？只要他们脑子里有足够清晰的愿景，并且能把它表达出来让智能体去构建。我觉得这才是如今的瓶颈——把你的意图和愿景传递给智能体。

I actually feel like domain expertise is more important than ever. I think I wrote this on my X at some point, but at times I sometimes think of AI as — especially as the models get smarter and smarter and more capable, and the frontier models are just getting so good, like I love Opus 5.5 by the way — as the models get really, really, really good, it almost becomes like the bottleneck is no longer the agent, right? It becomes your ability to express your intent and your goals in a clear way that the agent can understand and actually carry out. And that's why I think people with a lot of domain expertise have a huge advantage, in my opinion, especially if you're a little bit tech-curious. So I think of people like a doctor or a lawyer or someone who has a deep expertise in a particular non-engineering domain, and if they're actually just a little bit tech-savvy and they can figure out how to use agents, they can actually build really, really great products, right? If they have a clear enough vision in their head and they can articulate it in a way that the agent can build it, I think that is really the bottleneck these days — it's like the transfer of your intent, right, and your vision to the agent.

是啊。基本上从智能体出现以来，我就对语言着迷了。百分之百着迷，一直在琢磨词语的组合，怎么把话说得更锋利，我用的那些措辞里可能藏着什么。我最喜欢的是，当你找到一个词，智能体就抓住它，然后说：“好，我要强化这个词。我要在思考轨迹里反复用它。”我发现 TDD 就是个早期的例子。最近关于 TDD 有很多讨论，比如人们问：该不该用 TDD 配合智能体？其实不重要。你真正做的是让智能体去思考 TDD，让它写测试，让它以和以前不同的方式排优先级。所以我觉得“拷问”之所以有效，是因为拷问是一种——

Yeah. I've been obsessed with language basically since agents dropped. Just obsessed 100%, and thinking constantly about the composition of words, how I can make things sharper, what might be hidden in the phrases that I'm using. And what I love is when you find a word that the agent then hooks on to and goes, "Okay, I'm going to reinforce that word. I'm going to reuse that in my thinking traces." I found that with TDD — it was an early example of that. A lot of chat about TDD recently, like people say, should you use TDD with agents? Doesn't matter. What you're doing is you're getting the agent to think about TDD, getting it to write tests, getting it to prioritize things in a different way than it did before. And that's why I think grilling works effectively. Grilling is a—

对，对。它能把那些词从你嘴里引出来，对吧？或者至少它帮智能体理解你的思路，这样它们就能把那些词提给你，你接过来就说：对，正是这个。

Yeah. Yeah. It draws those words out of you, right? Or at least it helps the agent understand your thinking so that they can propose those words to you and you can pick up and say, yes, exactly that.

我其实还抄了你分享的一些技巧。我最近最喜欢的一个——可能是过去几周里——是关于减少或消除同义反复的测试。智能体写的一堆没用的测试，是我最烦的事情之一。所以那一点上，“同义反复”这个词——我猜不是很多人都知道，尤其如果英语不是你的母语，但这个词含义很丰富。它几乎像是压缩过的，对吧？你把大量的意图和含义压缩进词语里。所以我完全同意你。其实我一直对语言感兴趣——比如编程语言、人类的自然语言，以及它们是怎么来的。而现在有了智能体，有意思的是，自然语言和编程语言交汇了，但底层全都是语言。全都是沟通。

I've actually copied some of the tips that you've shared as well. One of my favorite ones that you've shared recently — maybe in the past couple weeks — is about reducing or eliminating tautological tests. Like one of my pet peeves with agents is all of the useless tests that they write. And so that was one thing where the word tautology — I guess not many people necessarily know that, especially if English isn't your first language, but there's a lot of meaning to that word. And it's almost like compressed, right? You compress a lot of intent and meaning into words. And so I totally agree with you. I think I've always been interested in language, actually — like programming languages, natural human languages, and how they came to be. And it's so interesting that now with agents it's sort of this meeting of natural language with programming language, but it's all language under the hood. It's all communication.

完全同意。我读的是戏剧学位，对吧，所以我长期以来一直在琢磨语言、莎士比亚这些东西，所以这一切都让我觉得很熟悉。

Totally. I did a drama degree, right, so I've been thinking about language and Shakespeare and stuff for a long time, and so this all feels very familiar.

好，那么在进入正题之前——因为我想从你这儿听到的是软件工厂那套东西，对吧？软件工厂是个大热词。软件工厂也是我在思考的东西。我也在往这个方向推出一门课程。它本质上就是把自己扩展到不现实的 PR 数量——或者说在不懂这套怎么运作的人听来很荒谬的 PR 数量。所以我想聊的是，从今天大家做的一到五个智能体，一路扩展到同时运行几百个智能体，以及那套东西怎么运转。所以我很想听你讲讲你用米其林厨房而不是软件工厂的比喻，因为我觉得这能体现你对这件事的思考方式。

So okay, before we get into — because I think the thing I want from you is like software factory stuff, right? Software factory is the big buzzword. Software factory is the thing that I'm thinking about too. I'm sort of releasing a course in that direction too. And it's this sort of scaling yourself up to unrealistic numbers of PRs, basically — or PR numbers that sound ridiculous to people who don't understand how this works. So where I want to get to is sort of from people who are doing kind of like one to five agents today up to hundreds of agents running at once and how that sort of functions. And so I'd love to hear about your metaphor of the Michelin Kitchen instead of the software factory, because I think that says a bit about the way you think about this stuff.

是的。对。我一直不太喜欢“软件工厂”这个词。不是因为它不准确，而是我觉得很多人一想到工厂，并不会把它和质量或手艺联系起来，对吧——而质量和手艺对我和很多做产品的技术人来说非常重要。我们在意用户体验，在意我们做出来的东西。所以虽然我确实觉得软件工厂是个贴切的词，但它大概也会勾起一些负面联想。于是我最终落在了米其林厨房这个说法上，它更——我觉得它更有追求感，而且我很喜欢这个比喻，因为我喜欢食物。当然，我叫 Potato，我喜欢做饭，我看到很多相似之处，比如和食物。举个例子，当你给自己做一顿饭时，它既是功利的——你只是想喂饱自己、活下去——但它其实也可以被转化为艺术，对吧？这就是米其林星级厨师，甚至只是一个厨师或做饭的人，能用食物做到的事：把非常普通的东西变成一顿美味的饭，让你想起童年之类的。所以它几乎映射了我说的那个信任阶梯，你可以把自己作为家庭厨师的旅程想象出来，对吧？作为家庭厨师，所有食物、所有烹饪都是你自己做。你自己切菜，自己做所有准备工作，自己收拾——你真的是一个人的独角戏。这是个有趣的思维实验：好，如果你要做一顿饭，然后加入别人——你的伴侣、你的兄弟、你的姐妹——突然你整个家庭都在厨房里了。我觉得大多数人会因此非常紧张，对吧？一想到这么多人就在我厨房里瞎转悠，根本不知道餐具都在哪儿。

Yes. Yeah. I've never really liked the term software factory. Not because it's not accurate, but I think a lot of people, when they think factory, right, they don't necessarily equate that with quality or craft, right — things which are very important to me and a lot of people and technologists who work building products. We care about the user experience, we care about the things we're building. So while I do think software factory is an apt term, it also, I guess, maybe conjures up negative connotations. So Michelin Kitchen is the thing that I've sort of landed on, where it's much more — I feel like it's much more aspirational, and I like the metaphor a lot because I like food. I'm called Potato, of course, and I like cooking, and I see a lot of parallels, right, like with food. When you're cooking a meal for yourself, for example, it's both utilitarian — like you're trying to just feed yourself, right, and survive — but it can actually be transformed into art, right? And that's what a Michelin-starred chef, or even just a chef or a cook, can do with food: take something very ordinary and turn it into a delicious meal that takes you back to your childhood days or something like that. And so it almost mirrors that trust ladder that I talk about, where you can sort of imagine your own journey as a home cook, right? As a home cook, you are doing all of the food, the cooking yourself. You cut all the vegetables, you do all the prep work, you do all the cleanup — you are the one-man or one-woman show, really. And it's an interesting thought experiment: okay, if you were to cook a meal and then you add people — your partner, your brother, your sister — and now suddenly you have your whole family in the kitchen. I think most people would get very stressed by that, right? The thought of, oh, so many people are just mucking around in my kitchen. They have no idea where all the utensils are.

我厨房最多只能容纳一个人。对，绝对是这样。

I have a max capacity of one person in the kitchen. Yeah, absolutely.

所以，我觉得这个比喻真的很贴切，因为当你问自己这个问题：我如何从一个单打独斗的厨师，变成一个拥有军队——甚至不是军队，而是几个副厨师——在厨房里帮我的人？我如何以合理的方式划分工作？你知道，我不是为了划分而划分，而是要让整体大于部分之和。所以米其林厨房的比喻对我来说在这方面非常适用，因为作为一名厨师，如果你成为厨师，你就不再需要亲自烹饪所有食物，但你在思考——你几乎就像是厨房的技术负责人，厨师们不仅要考虑烹饪，还要基本上组织整个厨房，他们就像是厨房的 CEO。他们必须考虑什么时候订购食材、如何储存、如何准备、什么时候必须准备好。你知道，这是一整套工作，对吧？不仅仅是烹饪。嗯，我认为这再次映射了当今工程师编写代码的方式，你不再自己写代码了。你有智能体，对吧？但作为人类，你仍然对最终结果负责，对吧？你的名字仍然与你的工作相关联，你的声誉。所以你如何设置你的厨房，以及你如何设置你的技能、你的环境、你的代码库，我认为这些最终都是构建产品的新食材。

So, I feel like that's really apt because when you ask yourself that question of how do I go from being a solo cook, right, to having an army—or even not even an army but a few sous chefs, right, that are helping me in the kitchen. How do I think about dividing the work in a way that makes sense? You know, I'm not dividing work just for the sake of it, but in a way that actually makes the sum better than the total of its parts. And so the Michelin kitchen metaphor to me works really well in that regard because, you know, as a chef, if you become a chef, you're in a position where you're not necessarily cooking all the food yourself anymore but you are thinking—you're almost like the tech lead for the kitchen where chefs have to think about not just cooking but they have to basically organize the whole kitchen and they're like the CEO of the kitchen. They have to think about when do you order ingredients, how do you store them, how do you prepare them, when do they have to be prepared. You know, it's a whole job, right? That's not just cooking. Um, and I think that again it mirrors so much of how engineers write code today where you are not writing the code yourself anymore. You have agents, right? But you as the human are still responsible for the final outcome, right? Your name still is associated with the work that you do, your reputation. And so how you set up your kitchen, right, and how you set up your skills, your environment, your codebase, I think are ultimately the new ingredients that go into building product.

是的，我觉得我喜欢你的方法的地方在于你对智能体运行环境的关注程度，对吧，因为我认为很多人会想，智能体很好。我可能无法让它变得更好。我们就相信这些神奇的模型人放在框架和模型组合里的东西吧。我无能为力，比如我不能乱动 Claude Code 的内部结构之类的，或者你用的任何东西。嗯，但我喜欢你的方法的地方，也是我所倡导的，是你可以改变智能体运行的环境，对吧？你可以在代码库中做出改变，也可以给它验证工具，让它验证自己的工作。所以我喜欢看那个演讲的地方是你对验证的关注程度，就像那是你可以开始产生信任的杠杆。你能谈谈这一点以及具体是什么样子吗？让我们从实际方法开始，看看人们如何改进自己的流程、自己的厨房。

Yeah, I think what I love about your approach is the amount of focus that you put into the environment that the agent operates in, right, because I think a lot of people they think, right, the agent is good. I'm probably not going to be able to make it better. Let's just trust what these magic model people have put into the harness and the model combination. Uh, there's nothing I can really do, like I can't mess about with Claude Code's internals or something or whatever you're using. Um, but what I love about your approach, and it's something I advocate for too, is that you can change the environment the agent operates in, right? You can make changes in the codebase and also give it tools for verification as well and allow it to verify its own work. So the thing I loved about watching that talk is the amount of focus you put in verification and like that is the lever that you can start to generate trust. Can you talk about that and what that concretely looks like? Let's start like looking at practical ways that people can improve their own processes, their own kitchens.

是的，我其实说过很多次，即使你不使用 PAC 或你的技能，我认为你的工具箱中最重要的技能应该是验证，因为没有验证——顺便对观看的人解释一下，意思是你给智能体手和眼睛，打个比方，智能体能够运行代码，对吧？并且像普通人类用户一样与之交互，还能做调试、获取追踪和快照之类的事情。嗯，有趣的是，那其实是我加入 Cursor 时构建的第一个技能。那给了我很多——那是真正开始让我在信任阶梯上稍微上升的东西，而其他一些我看过或构建的技能并没有真正让我做到这一点，因为无论其他技能有多好，比如 how 技能、why 技能、unslop 技能，我仍然依赖自己作为智能体和输出之间的代理。所以如果智能体实际上看不到其工作的结果，它就无法迭代，对吧？这就是人们开始谈论循环的地方，循环这个概念。实际上，我觉得循环这个词似乎有点抽象，人们会问什么是循环，什么是智能体循环，但对我来说，循环中最重要的部分，让它成为循环的，是验证部分，因为智能体能够验证自己的工作，这让你脱离方程，现在我可以真正做点什么了——所以我最早使用验证的用例之一是我在 Cursor 的智能体窗口上做的性能工作，我想达到可以做一种叫做爬山法的程度，这是我认为实验室经常谈论的术语，意思是你有某种评分标准或判断或评分的方法。现在因为你有一个循环，你可以让智能体不断尝试改进。我认为 Andrej Karpathy 也著名地发布了叫做自动研究的东西，有很多这些想法。嗯，但是的，验证可以说是 PAC 和许多其他工具集中最重要的技能。我认为这是最应该关注的事情。所以我花了很多时间实际调整验证、创造性验证技能，而且内部我们现在有这么多验证技能，比如 Cursor 或 SpaceXAI 的每个应用都有一个自动维护的验证技能。它已经成为我们团队的关键基础设施，因为每个人都在使用它。

Yeah, I've said this a lot actually, that even if you don't use PAC or your skills, I think that the single most important skill that should be in your toolkit is verification because without verification—and by the way for those watching who don't know what that means, it's this idea that you can give your agent hands and eyes in a way that—the analogy is where the agent is able to run the code, right? And actually interact with it like a normal human user would and also do things like debug it, take traces and snapshots. Um and funnily enough, that was actually the first skill I built when I joined Cursor. That gave me a lot—that was the thing that actually started to let me ascend the trust ladder a little bit in a way that some of the other skills I had looked at or built had not really let me do because no matter how good some of the other skills were like the how skill, the why skill, the unslop skill were, I was still relying on me right as the proxy between my agent and the output. So if the agent can't actually see the result of its work, there's no way it can actually iterate, right? And so this is where people start to talk about loops, this idea of a loop. And really I think the term loop seems kind of almost abstract, like people like what is a loop, what is an agent loop, but really to me the most important part of a loop that allows it to be a loop is the verification part because the agent is able to verify its own work and that takes you out of the equation where now I can actually do something like—so one of the very first use cases I had for verification was the performance work that I was doing on Cursor's agent window and I wanted to get to a point where I could do something called hill climbing, which is a term that I think the labs talk about a lot, which is this idea that you have some kind of rubric or a way to judge or score something. And now because you have a loop, you can have an agent continually try to make improvements to that. I think Andrej Karpathy also famously released something called auto research that has a lot of these ideas. Um but yeah, verification I would say is probably the most important skill in PAC and many other tool sets. And I think it's the most important thing to focus on. So I spent a lot of time actually tuning the verification, the creative verification skill, and also internally we have so many verification skills now, like every app that Cursor has or SpaceXAI has has a verification skill that is auto-maintained as well. And it's become critical infrastructure for our team because everybody uses it.

而且你在这方面走得相当远，对吧，比如你在演讲中我看到你实际上为此构建了一个自定义 CLI。那么那个 CLI 是做什么的？它如何执行事情，以及你为什么——我的意思是，这证明了你深入的程度，对吧，你推动了多少。

And you went pretty far with that too, right, like you had a—in your talk I saw that you actually built a custom CLI for that too. So what does that CLI do? Like how does it execute things and why did you—I mean that's proof of how deep you're going, right, of how much you're pushing that.

是的。所以这其实是我早期学到的一个技巧，我想是在一月份或去年年底，人们担心的是上下文窗口，对吧？当时的大话题是如何管理上下文窗口，因为压缩摘要当时还不是很好，人们有这种——社区里几乎有个梗，一旦你的智能体总结或压缩一次，它就会在剩下的会话中变得有点愚蠢。所以有很多关于高效使用上下文的思考，这实际上是验证技能中一些 CLI 工作的灵感来源。我想现在不太关乎上下文了，因为智能体好多了，或者框架在摘要方面进步了很多。嗯，我仍然认为拥有干净的上下文窗口有一些好处。

Yeah. So this is actually a tip I learned early on where I guess back in January or late last year the thing that people were concerned about was context window, right? That was the big topic at the time was how do I manage the context window because compaction summarization wasn't really that good yet and people had this—there was almost this meme in the community that once your agent summarized or compacted once it would become sort of stupid right for the rest of your session. So there was a lot of thinking around being very efficient with your context usage and so that was actually the inspiration for some of the CLI work inside of the verification skills. I guess now it's less so about context because agents are much better or harnesses have gotten a lot better with summarization. Um, I still think there's some benefits to having a clean context window.

所以 CLI 其实更多只是我的一种方式：把技能里那些确定性的部分拿出来，编码成脚本或 CLI，从而减少——去掉那些本来没必要用到的判断。因为说到判断——我也把智能体和技能想成一个渐变谱系。有些工作部分完全是基于判断的，需要思考，需要把多块上下文拼在一起、去琢磨。然后还有更确定性的部分。比如，我不知道，如果你想按某种模式重构代码，那是非常机械的。你不需要智能体每次都去思考、以新颖的方式重新想一遍。所以这就是 CLI 的灵感来源。你在我构建的很多其他技能里也会看到这一点：我尽量把确定性的部分抽出来、变成代码，只把真正需要判断的部分留给智能体。所以某种意义上，我把技能看成一种包装器，对吧？它是一个包装器，带着一些轻量指令，说明如何使用技能内部这些自定义工具。但说实话，我不觉得 CLI 本身有多有意思。它不是什么新奇的软件。它只是跟 Playwright 和 Chrome DevTools 协议交互、调用一堆 API 的东西。就是一堆胶水代码。

So the CLI is really just more of a way for me to take the deterministic parts of what the skill does and encode that into a script or CLI, to reduce—to take away the judgment that would otherwise unnecessarily be used. Because with judgment—I also think of agents and skills as sort of a gradient. You have some parts of the work that are entirely judgment-based, something that requires thought, putting together multiple pieces of context, thinking. And then you have the more deterministic parts. Like, I don't know, if you wanted to refactor some code from one pattern to another, that's very mechanical. You don't need an agent to think about it and come up with it in a novel way each time. And so that was really the inspiration for the CLI. And you'll see this in a lot of the other skills that I built: I try to extract out the deterministic parts and turn that into code, and just leave only the parts that actually require judgment to the agent. So in a way I think of the skill as kind of like your wrapper, right? It's a wrapper with some light instructions around how to use these custom tools that are inside of the skill. But yeah, I don't think the CLI is really that interesting in its own right. It's not a novel piece of software. It's just something that interacts with Playwright and the Chrome DevTools protocol and calls a bunch of APIs. It's just a bunch of glue.

不，这很有意思，因为这是一种对技能隐藏信息的方式，对吧？这是一种节省技能的方式，我猜是让技能保持得相当小，然后你就能把更多复杂的确定性工作下放到技能内的脚本里。所以这几乎像是在压缩信息，让智能体更一致地做更一致的事。

No, it's fascinating, because it's a way of hiding information from the skill, right? It's a way of conserving the skill, keeping the skill quite small, I imagine, and then you're able to delegate more of the complicated deterministic stuff into a script within the skill. So it's almost like you're compressing information and making the agent do more consistent things more consistently.

对。

Yeah.

这很有意思。

That's fascinating.

而且这也有帮助，我猜，如果你在意上下文窗口的话——确实有帮助，因为现在智能体不需要重新发明东西了。因为我早期注意到的一件事是，在我们还没有 CLI 的时候，智能体会尝试验证它能工作，但它基本上每次都重建一遍世界，然后每个智能体的做法都不一样。我开始注意到，这非常低效，对吧？我在浪费——其实不只是上下文用量的问题，还有速度，对吧？因为现在智能体得真的跑去写脚本或 CLI 并测试它，结果不工作，而上一个智能体做过并且成功了，却把它丢掉了。所以那时候就很明显了：我应该把它做成一个 CLI，放进技能里，这样每个使用它的智能体都能从同一份成果中受益。但我也觉得，这能很好地推动大家去思考：你的技能和规则里有多少其实可以是确定性的。这是另一个核心点，也是我喜欢思考的核心原则之一：如何非常高效地利用确定性和非确定性，让智能体在非确定性的部分大放异彩，对吧？因为那正是它们被训练来做的事。而其他更机械、更直接的部分，就可以是纯粹的确定性。你在做迁移这类事情时也会看到这一点，这是我谈过的另一个大话题：从一种技术迁移到另一种技术，尤其是迁移到对智能体更友好的技术。而你能完成这种迁移的很多方式，我认为，是通过脚本和 CLI 这类东西——那些确定性的部分，比如 codemod，爬取抽象语法树、机械地转换代码，像脚本替你完成，而不是智能体。

And it also helps, I guess, if you care about context window—it does help, because now the agent doesn't need to reinvent things. Because one thing I had noticed early on, when we didn't have a CLI, was that the agent would try to verify it worked, but it would basically rebuild the world each time, and then every agent did it differently. And I was starting to notice, like, that's very inefficient, right? I was wasting—it was actually not just about context usage but also speed, right? Because now an agent had to actually go off and write the scripts or the CLI and test it, and it doesn't work, and the last agent did it and it worked but it discarded it. So it was just very obvious at that point: I should just turn this into a CLI and put that inside of the skill, so that every agent that uses it now benefits from that same piece. But I also think it's a good push for people to think about how much of your skills and rules could actually be deterministic. That's another core thing, or one of my core principles that I like to think about: how do I make very efficient use of determinism and non-determinism, and let agents shine at the non-deterministic parts, right? Because that's what they're trained to do. And the other parts, which are much more mechanical or straightforward, can be just pure determinism. And you'll see this as well for things like doing migrations, which is another big thing that I've talked about: going from one technology to another, especially one that is better for agents. And a lot of how you can do that migration is, I think, through things like scripts and CLIs—the deterministic parts, like codemods, crawling the abstract syntax tree and transforming code literally mechanically, like a script does it for you instead of the agent.

完全说得通。我是说，我觉得这里还有另一点，就是你把一些东西从智能体那里拿走，同时也把它放进环境里一点。也就是说，假设你注意到智能体总是把某件事做错，你想让这件事在环境里变得不可能发生。这也归结到代码质量。我是说，我经常谈，好的代码库意味着什么，对吧？什么是好的代码库？我喜欢的一个定义是：好的代码库是容易做改动的代码库，对吧？容易改动东西而不把事情搞砸。这意味着你有很多护栏，让智能体或人类被限制在非常狭窄的路径上。这又是你在演讲里谈到的。

Totally makes sense. I mean, I think there's another thing there, which is you're taking stuff away from the agent and you're kind of putting it in the environment too, a little bit. Which is, let's say you have a thing that you notice the agent always gets wrong. You want to make that just impossible within the environment. And that sort of comes down to code quality as well. I mean, I talk about a lot, like, what a good codebase means, right? What is a good codebase? And there's a definition I like, which is: a good codebase is a codebase that's easy to make changes in, right? Easy to change stuff without things screwing up. And that means that you have a lot of guardrails, that the agent or the human is constrained to very narrow paths. And that's again something you talk about in your talk.

而且你谈这个不只是在自动化检查那一侧——比如 linting 和类型检查之类的——还在于你设计抽象的方式。而且我觉得你们甚至为智能体搭建了一个供它工作的框架。

And you talk about this not only on the sort of automated checks side of things—so linting and type checking, blah blah blah—but also in the way you design abstractions. And you guys even, I think, built a framework for your agent to work in too.

我想我很想听的是——你显然认为这非常重要，对吧？那跟你本来可以做的其他事情相比，比如构建功能或交付工作，它有多重要？

I think what I'd love to hear is—you obviously think of that as very important, right? And how important is that compared to other things you could be doing, like building features or shipping work?

对，我觉得这几乎像是——我几乎觉得工程师的新工作就是花时间在环境上。其实我昨天差点为此写了一条推文，但没写。不过我觉得，如果你没有真正花时间去建立对智能体的信任、去构建技能和工具，你就会卡在这种状态里，在信任阶梯上位置很低，对吧？你对智能体的工作没多少信任。所以在这种情况下，唯一的应对方式就是死死盯住、微观管理你的智能体。而那非常耗时。当你卡在这种模式里，你就没有余裕去思考更高层次的事情，比如让自己更有生产力。就像——我猜这个类比是，如果你作为开发者自己写代码时，从没花时间学你的工具，你没听说过 VS Code，没听说过 Vim，你只知道记事本，甚至没听说过 Git。大概就是这个类比。就像你没花时间磨自己的刀，对吧？所以当然，如果你拿的是一把钝刀，那一切都会花很长时间。而你就只会——尤其当截止日期逼近时，你就卡在这个困境里，对吧？你没有锋利的刀，没有好工具，却又承受着交付的压力。于是你能做的就只有盯着那件事。

Yeah, I think that's a—I almost feel like the new job of the engineer is really to spend time on the environment. I almost actually wrote a tweet about this yesterday, but I didn't. But I think that if you haven't really spent time building trust in your agents and building skills and tools, you can get stuck in this mode where you're very low on that trust ladder, right? You don't have a lot of trust in your agent's work. And so the only way to cope when you're in that situation is just to kind of lock in and micromanage your agents. And that's very time consuming. And when you're stuck in that mode, you don't really have the luxury to think about higher-level things like making yourself more productive. In the same way that—I guess the analogy would be, if you've never taken the time to learn your tools as a developer when you were writing code yourself, and you've never heard of VS Code, you've never heard of Vim, you only knew about Notepad, and you hadn't even heard about Git. That's sort of the analogy. It's like you haven't spent the time sharpening your own knives, right? And so, of course, if you have a dull knife, then everything's going to take a long time. And you're just going to be—and especially if deadlines are looming, then you're stuck in this rut, right? Where you don't have sharp knives, you don't have good tools, but you're under all this pressure to ship. And so all you can do is just focus on that.

但我确实认为，如果你能腾出时间，真正去思考你的环境配置，这又回到了做饭的类比。比如说，切蒜超级慢，对吧？有压蒜器，你可以买一个，把蒜放进去一挤就出来了，对吧？超级快。机器和工具被发明出来是有原因的，对吧？所以如果你经营一家米其林厨房，而你的厨师没有任何工具，那当然一切都会极其低效。每个厨师都会自己瞎琢磨出一套做法。所以我认为，工具和确定性，对我来说，就是把那部分拿掉。就像你说的约束一样，约束对我来说也是——

But I do think that if you can find yourself the time to actually spend time thinking about your setup, it's again going back to the cooking analogy. If, for example, cutting the garlic is super slow, right? There are garlic mashers. You can buy one and put it in the thing and squeeze it out, right? It's super fast. Machines and tools were invented for a reason, right? And so if you're operating a Michelin kitchen and your cooks had no tools, then of course everything's going to be extremely inefficient. Every cook is going to make something up of their own. So I think the tools and the determinism, to me, are taking that part away. And just like you said about constraints as well, the constraints are, to me as well—

其实稍微岔开一下，我觉得我们应该聊聊 TypeScript，因为我们俩其实都有 TypeScript 的背景。你显然在 TypeScript 和 Total TypeScript 上做了大量工作，是这个领域的领军人物。而我很早就采用了 TypeScript，很多年前在 TypeScript Conf 做过一两次演讲。我当时做的一个演讲就是关于类型系统和约束类型的。我最喜欢 TypeScript 的一点其实是类型收窄（type narrowing），对吧？这个想法是，你从一个非常宽泛的类型出发，它可以是任何东西，然后通过类型守卫、类型收窄和运行时检查，你实际上可以收窄空间，说：哦，这不只是一个字符串，这是一个非常特殊的字符串类型，它是一个常量，对吧？我通过类型系统来确定这一点。在某种程度上，我觉得这和代码库中的约束有很多相似之处，你是在约束空间，对吧？如果你想想范畴论，你是在约束可能存在的类型数量，你说只有一种类型，对吧？对我们来说，那个我称之为 Dune 的框架——它不是开源框架。我向别人描述它的方式是，它有点像我们 Electron 应用内部的 Next.js。但它带有很多非常非常严格的 lint 规则，代码库的设计方式使得做一件事真的只有一种方法。所以我们大量使用约定俗成的模式。比如所有功能都放进一个特定的目录，每个功能都有自己的目录。举个例子，有一个东西通过注册表和爬取代码库之类的方式来发现功能。但这种约定俗成的模式和 lint 规则营造了一个环境，实际上很难写出糟糕的代码。这既释放了你自己的脑力，也让智能体不必再考虑那些，它只需要想：哦，只有——如果我想加一个新功能，它就放进新功能目录，所有代码都在那里，我不会去往一个上帝文件里追加，对吧？这其实是那些功能目录的灵感来源：Grok Bot 最早的几个版本由大约八个上帝文件组成，每个至少 10,000 行，甚至更长。所以我不得不把它拆成更小的部分。但这就是观察——其实那是另一个重要的部分——观察智能体如何失败。然后每次你看到一个错误，每次你看到可以做得更好的地方，你就退一步想：我怎么把它变成一条 lint 规则？我怎么让代码库使这变得不可能？对吧？这又回到我学习 TypeScript、类型和类型系统的背景：我怎么约束空间，以便我确切地知道我在处理什么。我觉得是的，那里有很多相似之处。

Actually, a slight tangent on that is I think we should talk about TypeScript, because we actually both share a background in TypeScript, where you obviously have done a lot of work with TypeScript and Total TypeScript, and you're a leader in that space. And I had adopted TypeScript pretty early and I had given a talk or two at TypeScript Conf many years ago. And so one of the talks that I did actually was about type systems and constraining types. One of my most favorite things about TypeScript is actually type narrowing, right? This idea that you go from a very broad type that could be anything, and then through type guards and type narrowing and runtime checks you can actually narrow the space and say, oh, this isn't just a string, this is a very special type of string. It's a constant, right? I determine that through the type system. And in a way there are a lot of parallels, I think, to that with constraints in your codebase, where you're constraining the space, right? If you think about category theory as well, you're constraining the number of possible types that can exist, and you're saying there's only one type, right? And for us, that framework that I'm calling Dune—it's not an open source framework. The way I describe it to people, it's kind of like an internal Next.js for our Electron apps. But it comes with a lot of really, really restrictive lint rules, and the codebase is designed in a way that there's really only one way to do something. So we make use of a lot of conventional patterns. So features all go into a specific directory. Every feature has its own directory, as an example. There's a thing that discovers features through a registry and crawling the codebase and stuff like that. But this conventional pattern and the lint rules make for an environment where it's actually very hard to write bad code. And that sort of frees up both your own mental capacity as well as the agent—it sort of doesn't have to think about that anymore, where it's just like, oh, there's only—if I want to add a new feature, it just goes in the new feature directory and all the code goes in there, and I'm not going to append to a god file, right? That was actually the inspiration for those feature directories: the very first couple of versions of Grok Bot were composed of like eight god files which were at least 10,000 lines long, if not longer. And so I kind of had to break it up into smaller pieces. But it was just observing—actually, that's another important part—observing how agents fail. And then every time you see a mistake, every time you see something that could be done better, you step back and think, how do I turn this into a lint rule? How do I make it so that the codebase makes this impossible? Right? And it comes back for me, from my background learning TypeScript and types and type systems, to how do I constrain the space so that I know precisely what I'm working with. And I think yeah, there's a lot of parallels there.

完全说得通。而且你把 TypeScript 和上帝文件放在同一句话里挺有意思的，因为 TypeScript famously 有一个 25,000 行的类型文件。不过我不知道他们有没有用 Go 重写那个——他们大概重写了吧，对吧？好。所以环境很重要。你应该像鹰一样盯着你的智能体，确保它犯的任何错误，你都把它们转化成环境里的东西。环境的好处是你不会让智能体过载，对吧，在规则方面，在它必须记住的东西方面。它就在环境里。所以它会撞上规则，被弹开，在正确的时刻碰到它们。好，我们还没聊那 2,500 个 PR。它们从哪来的？比如你怎么——你建好了信任阶梯，你搞定了环境，你明白，好，我现在想扩大规模。那么这种规模扩张的机制是什么？你每个月发起 2,500 个对话吗？那不可能对。所以肯定有——你的仓库里有没有某种自动触发器来触发东西？比如你怎么让软件工厂自己触发工作？

Totally makes sense. And it's funny that you mentioned TypeScript and god files in the same sentence, because TypeScript famously has a 25,000-line type file. Although I don't know if they've rewritten that in Go—they probably have, haven't they? Okay. So, environment is important. You should watch your agent like a hawk to make sure that any mistakes it makes, you turn them into things in the environment. And the benefit of the environment is you're not overloading your agent, right, in terms of rules, in terms of things it has to remember. It's just in the environment. And so it stumbles into the rules and bounces off them and hits them at the right moment. So okay, we still haven't talked about the 2,500 PRs. Where do those come from? Like how do you—you've built your trust ladder, you've worked on your environment, and you understand, okay, I now want to scale up. So what are the mechanics of that scaling? Are you initiating 2,500 chats per month? That can't be right. So there must be—are there any kind of automated triggers that trigger stuff in your repo? Like how do you get the software factory kind of triggering work by itself?

对。我肯定要说，像这么高数量的 PR 的前提是环境——就是我们刚聊的那些东西。如果我沒花时间思考厨房，对吧，还有刀和工具，我肯定做不到这一点。所以在某种程度上，我把这看作是我花时间建好了一个厨房和一家餐厅。现在我的处境是，我其实不必再待在那里了，因为环境——你知道，同样的类比，对吧？它非常适用。

Right. I'll definitely say that the prerequisite to something like a very high volume of pull requests is the environment—the stuff we just talked about. I definitely would not have been able to do this if I had not spent the time thinking about the kitchen, right, and the knives and the tools for my Asians. And so, in a way, I think of this as I've spent the time building one kitchen and one restaurant. And now I'm in a position where I don't actually have to be there anymore because the environment—you know, the same analogy, right? It works really well.

对。你开连锁餐厅，对吧？那就是——

Yeah. You open a chain of restaurants, right? That's—

对。没错。没错。就像你是 Gordon Ramsay，你把想出好菜单的所有诀窍都教给了你的行政主厨。厨房布置得非常好。一切都完美。而你现在处于可以开第二家、第三家餐厅的位置。

Yeah. Exactly. Exactly. It's like you're Gordon Ramsay and you've taught your executive chef all the tricks of coming up with a great menu. And the kitchen is set up really well. Everything's just perfect. And you're now in a position where you can open your second, your third restaurant.

我有点把我在做的每个项目、每个大的对话，都看作一家餐厅，对吧？我同时运营着好几家，在它们之间来回盘旋——有时候对某些投入更多，取决于我对它有多了解。但没错，这些项目确实缺少一些外部触发器和上下文。很长一段时间里，我就是那个代理。

I sort of see each project that I work on, each big chat, as sort of like a restaurant, right? I have multiple of them operating at the same time, and I'm sort of helicoptering between them—sometimes some more than others, depending on how in the loop I am. But yeah, definitely there are external triggers and context that those projects don't have. For a long time I was the proxy for that.

我能想到的最好的例子是：你有一个项目在做某个功能，或者你在试着修一个 bug，你会收到 bug 报告，但这些报告是发到 Slack、Linear 或 X 这类地方的，对吧？这些外部系统并没有连到你的内循环。所以我喜欢谈外循环和内循环。我不知道我用词是否准确，但对我来说，内循环基本上就是我的工程师——我的智能体工程师——在写代码，朝着一个意图或我意图的快照去构建。

The best example I have is: you have a project working on a feature, or you're trying to fix a bug, and you're getting bug reports, but the bug reports are going to things like Slack or Linear or X, right? These are external systems that aren't connected to your inner loop. So I like to talk about this outer loop and the inner loop. I don't know if I'm using the definition correctly, but to me my inner loop is basically my engineers—my agent engineers—working on the code, building towards an intent or a snapshot of my intent.

问题在于，这个快照会过期，对吧？新信息浮现出来，我就得充当代理，把那个上下文转给我的智能体。所以如果你没有这些触发器把信息拉回内循环，你就得扮演那个角色——跑到 Slack 或 X 之类的地方去收集上下文，对吧？你在获取关于 bug 报告、功能请求、某人说我们后端基础设施有某种限制的信息——所有这些信息，你都得搬运给你的智能体。

And the thing about that is that the snapshot can go stale, right? New information comes to light that I then have to be the proxy of and transfer that context to my agent. So if you don't have these triggers pulling information back into the inner loop, then you sort of have to play that role where you're off in Slack or X or whatever, gathering context, right? You're getting context about bug reports, about feature requests, about something someone said about our backend infrastructure having some limitation—all that information, you have to ferry that across to your agent.

所以我觉得像 Grok Bot 这样的工具就很好，因为它们帮你把外循环也自动化了。当你把这两个循环连起来，威力就非常非常大，因为突然之间，你的智能体有能力自己去获取上下文了，对吧？

So that's where I think tools like Grok Bot are really good, because they help you automate the outer loop as well. And when you connect those two loops, it's very, very powerful, because now all of a sudden your agents have the ability to get context for themselves, right?

举个例子，一个简单的例子：也许你有 Slack MCP，对吧？或者你有自己的 harness，为某个 Slack 频道内置了 Slack 订阅。现在突然之间，你可以告诉你的智能体：好，订阅这个 Slack 频道。每次有关于某事的 bug 报告，就去分诊那件事，对吧？去复现问题，用我们已经花时间构建的验证技能，以及我们设置好的所有其他技能，这样我就有很强的信任——我很信任这些智能体能真的去理解这个 bug，验证这个 bug 在 main 分支上是否仍然存在，而不是用户的设置或数据的问题，或者也许他们没装某个依赖之类的情况。

For example, a simple example: maybe you have the Slack MCP, right? Or you have your own harness that you've built a Slack subscription into for a particular Slack channel. Now all of a sudden you can tell your agents, okay, subscribe to the Slack channel. Every time there's a bug report about something, go off and triage that thing, right? Go reproduce the issue, using the verification skills that we've already spent time building and all those other skills that we've set up, so that I have a lot of trust—I have a lot of trust that these agents can actually go off and understand the bug, verify that the bug actually still exists on main and it wasn't something about maybe the user's setup or their data, or maybe they didn't install a dependency or something like that.

基本上，我认为创建这两个循环并把它们连起来，是如今这份工作非常重要的一部分，尤其是当你在考虑如何扩展自己的时候。所以这里的一大主题就是：始终思考我在这个流程里哪里是瓶颈？为什么我的智能体需要我来回答这个问题？我总喜欢这样想。所以我试着思考，怎么才能真正让智能体回答它自己的问题——不是靠幻觉，不是靠猜，而是靠真实数据。

Basically, I think creating those two loops and connecting them is really a very important part of the job these days, especially if you are thinking about how to scale yourself. So a big theme here is really just always thinking about: where am I the bottleneck in this process? Why do my agents need me to answer this question? I always like to think about that. And so I try to think about how do I actually get the agent to answer its own question—but not by hallucinating, not by guessing, but actually with real data.

很多人谈论“公司大脑”或“上下文图谱”这个概念，对吧？我觉得这些词没必要那么复杂，甚至有点抽象。对我来说，它就是：我怎么把智能体需要、否则得我自己去传递的信息，直接教会它怎么获取，对吧？这样就把我从等式里移除了。所以我能达到 2,000 个或不管多少个 PR，是因为我把这些循环都搭好了，对吧？它让我能开连锁餐厅——我真的可以把自己并行化。

And a lot of people talk about this idea of a company brain, right, or a context graph. I feel like those terms are unnecessarily complex or even abstract. To me, it's just about: how do I take information that my agent needs that I would otherwise have to go and pass myself, and just teach it how to do it, right? And that removes me from the equation. And so how I arrive at 2,000 or however many PRs is the fact that I have all these loops set up, right? It allows me to open chain restaurants—I can really parallelize myself.

所以没错，我不是坐在那里创建 2,500 个对话，对吧？当然不是。这些项目其实是——Cursor 有个新功能叫 Projects，就是这些协调者智能体。协调者智能体非常擅长委派，自己不干活，而是管理和监督几乎一个任务列表，然后生成子智能体去执行。所以我只是不断地喂上下文，或者教智能体如何自己获取上下文，然后它们就去替我做那些工作了。

So yeah, I'm not sitting there creating 2,500 chats, right? Of course not. These projects are actually—Cursor has a new feature called Projects, which are these coordinator agents. And the coordinator agents are really good at delegating and not doing work of their own, but they manage and supervise almost a list of tasks, and they spawn sub-agents to go and do them. And so I'm just constantly feeding context or teaching the agents how to get their own context, and then they're going off and doing the work for me.

最后我想说的是：让我达到 2,000 个 PR 的最大突破，是从这个问题出发倒推——我怎么才能让我的智能体合并它自己的代码？因为当我告诉别人我上个月提交了 2,000、2,500 个 pull request 时，他们显然会问：你怎么审的？那么多 PR 要审。你团队肯定恨死你了。

And really the last thing I'll say to this is: the big unlock for me for getting to 2,000 PRs is starting from the question and working backwards of how do I get to the point where my agent can merge its own code? Because the obvious thing people ask me when I tell them, oh, I shipped 2,000, 2,500 pull requests last month—they'll be like, how did you review that? That's a lot of PRs to review. Like your team must hate you.

你介意我们待会儿聊这个吗？因为那是个好问题。

Do you mind if we go there in a second? Because that's a good question about that.

好，好，好。

Yeah, yeah, yeah.

我想把这个类比再深化一点。以前，如果你手动发起所有这些对话，就像你手动把订单端给厨师，对吧？而如果你有个智能体来做传菜调度，你就能自己运转起来。那具体是什么样子？你有这些 Grok Bot 订阅频道、拉取 Slack 消息，听起来你还有几个协调者智能体或幕僚长智能体在监控这些。当你看着电脑管理你的智能体时，那是什么样子？

I want to deepen this analogy a bit. Before, if you're manually initiating all those chats, it's like you're bringing the orders to your chefs manually, right? Whereas if you've got an agent doing the expo, then you're able to run it yourself. What does that concretely look like? You've got these Grok Bots subscribing to channels, pulling in Slack messages, and it sounds like you have a couple of coordinator agents or chief-of-staff agents that monitor that. When you look at your computer to manage your agents, what does it look like?

好。这个嘛，我猜有点让人困惑，但我们正在简化和统一它。所以有 Grok Bot——当然你也可以用别的工具——但我大体上把这些工具看作你的外循环。像 Grok Bot 这样的工具有连接器。很多人叫它们个人智能体，但它们是连到你的邮件、日历、Slack、Plaid，我不知道，各种不同服务的连接器，是把上下文拉进你工作的绝佳来源。

Yeah. So this is, I guess, somewhat confusing, but we're working on simplifying and unifying it. So there's Grok Bot—or you can use other tools, of course—but I largely think of these tools as your outer loop. These are tools like Grok Bot that have connectors. A lot of people call them personal agents, but they're connectors to things like your email, your calendar, Slack, Plaid, I don't know, all these different services, and they are a great source of pulling context into your work.

就像一个人——如果多年前我是个带工程团队的管理者，我在 Netflix 工作时，管理者谈得最多的一件事就是“给上下文，而不是控制”，有趣的是，这一点在智能体的世界里也非常适用。

So the same way that a human—if I were a manager leading a team of engineers years ago, when I used to work at Netflix, one of the biggest things managers would talk about was this idea of context, not control, which funnily enough has so much carryover to the agents world.

当然，你可以通过控制来达到你想要的结果，对吧？比如通过微观管理，但你真正想要的是提供上下文，对吧？就像教智能体、教你的工程师如何自力更生，然后你就不必微观管理他们了。所以我觉得这里有很多相似之处。

You can of course drive to an outcome you want by control, right? Like by micromanaging, but what you want is to provide context instead, right? Like teach the agent, teach your engineers how to be self-sufficient and then you don't have to micromanage them. And so I see a lot of parallels there.

但没错，Grok Bot。具体来说，我有一些 Grok Bot 会查看我的 Slack 频道、我的 X、我的电子邮件或 Linear，它们只是不断地——它们有订阅的例程。所以它们一直在监视，我会告诉它们诸如“监视 Grok Bot 桌面应用中的 bug 问题”之类的事情。每当你们发现这些，就发送到我的 Cursor 项目。Grok Bot 的一个很酷的地方是它连接到 Cursor。所以 Cursor 有——就像我刚才提到的——这个叫做 projects 的新功能。一个项目实际上是一个——再次——你得到一个在云端的协调者智能体。它有自己的计算机，它真正要做的就像是一个智能体管理器。它就像你的行政主厨，对吧？你的幕僚长。它本身不做工作。它委托、编排和管理其他向你幕僚长汇报的子智能体的工作。它基本上负责推动工作向前发展、管理事务并向它们传递上下文。

But yeah, graphbot. So, concretely, I have some graph bots that look at my Slack channels, look at my X, or my emails, or Linear, and they're just constantly—they have routines that subscribe. So they're constantly watching and I'll tell them things like, you know, I'll watch for issues with bugs in the graphbot desktop app as an example. And whenever you find that, send it to my Cursor project. So one of the really cool things about graphbot is it connects to Cursor. So Cursor has—like I just mentioned—this new feature called projects. And a project is really a—again—like you get a coordinator agent that's in the cloud. It has its own computer and all it really does is like it's a manager of agents. It's like your executive chef, right? Your chief of staff. It doesn't do the work itself. It delegates and orchestrates and manages the work of other sub-agents that report to your chief of staff. And it basically is responsible for driving the work forward and managing things and passing context to them.

所以如果你突然遇到大量问题，比方说你在一个负载中一次性收到 30 个问题，或者非常快地收到，协调者智能体可以弄清楚并委托。

So if you get a sudden burst of issues, let's say you get 30 issues at once in one payload or something or very quickly, the coordinator agent can figure it out and delegate.

是的，没错。它收到大约 30 个负载，然后生成一个子智能体或一个单一的协调者智能体。它实际上可以执行多种不同的智能体拓扑结构，并会找出将任务高效分配给智能体团队的最佳方式。所以我经常使用 Cursor projects，也经常使用 Grok Bot，Cursor projects 是我的内循环，Grok Bot 是我的外循环。Grok Bot 获取所有上下文——外部上下文——并将其提供给项目，因为它实际上可以直接向那些项目发送消息，对吧？你甚至不必打开 Cursor。你只需告诉你的 Grok Bot：“好的，为这一系列任务创建一个项目。它们都相关。”举个例子，你突然遇到大量关于性能的问题，对吧？你的应用很慢，而且它们都相互关联。也许其中一些甚至有相似的修复方法。但你当然可以离开并只为每个任务生成一个智能体，但那样你就失去了它们之间的线索，对吧？你可能会重复工作，或者你可能没有真正考虑更高层次的问题。你知道，有时当你解决 bug 时，拥有多个略有不同的 bug 报告会有帮助，因为它帮助你真正拉远视角，看到实际上——当我查看这个报告时，我以为 bug 在这里，但当我看到其他大量 bug 时，实际上问题在上面。

Yeah, exactly. It gets like 30 or so payloads and spawns a sub-agent or a single coordinator agent. It can actually do a bunch of different topologies of agents and it will sort of figure out the best way to efficiently distribute the tasks to your team of agents. So I use Cursor projects a lot and I also use Grok Bot a lot, and Cursor projects are my inner loop and Grok Bot is my outer loop. Grok Bot takes all the context, external context, gives it to the projects because it can actually just send messages to those projects, right? You don't even have to open Cursor. You can just tell your Grok Bot, okay, create a project for these series of tasks. They're all related. Maybe as an example, you've had a big burst of issues that are all about performance, right? Your app is slow and they're all connected. Maybe some of them even have a similar fix. But you can certainly go off and just spawn one agent per task, but then you've lost that sort of thread between them, right? And you may duplicate work or you may not really think about the higher-level problem. You know, sometimes when you solve bugs, it helps to have multiple bug reports that are slightly different because it helps you really zoom out and see actually, you know, the problem—when I looked at this one report, I thought the bug was here, but actually when I see the other multitude of bugs, it's actually up here.

明白了。所以这就是为什么你在那个循环中有这么多智能体，对吧？因为不仅仅是有一个 bug 报告进来，你生成一个智能体来查看那个 bug 报告。那个单一的智能体会与其他智能体重复工作，对吧？因为如果有多个 bug 报告通过同样的方式进来，那可能会是重复工作。

Yeah. Got you. So that's why you have so many agents in that loop then, right? Because it's not just you have a bug report comes in, you spawn a single agent to look at that bug report. That single agent will be duplicating work with other agents, right? Because if there are multiple bug reports coming in through the same thing, that can be duplicated work.

是的。

Yeah.

太迷人了。这真的很有趣。好的。所以这 endless 的一系列触发器来自真实用户报告真实报告，构建了这种并加速了工厂，有点像增加了更多订单。除了 bug 报告，你还有其他来源用来加速推送这些 PR 吗？

Fascinating. That's really fascinating. Okay. And so this just this endless series of triggers coming from real users reporting real reports builds up this sort of and accelerates the factory sort of adds more orders in. Other than bug reports, are there any other sources that you use for like accelerating for pushing these PRs?

嗯，有趣的是，其中一些也来自阅读代码。所以，我想我有一种——嗯，澄清一下，你知道，那 2,500 个 PR 显然不是 2,500 个功能，对吧？很多工作实际上花在“园艺”上，这是另一个我非常喜欢的术语。所以我想当你有一个大型工程师团队——人类工程师——与你合作时，这更重要，而且这也回到我之前谈到的环境。你知道，建立一个真正好的环境，不仅帮助你和你的智能体，而且帮助团队中的每个人，对吧？想想一个新员工，他对你所有的工程实践没有太多上下文，加入你的团队。如果你有一个真正好的环境，他们可以从第一天起就高效工作，对吧？他们不必开一堆低质量的 PR。他们可以开始产出真正好的代码。而且，是的，我想我有点跑题了。

Well, funnily enough, some of it comes from reading the code, too. So, I guess I have sort of—well, to clarify that, you know, the 2,500 PRs, they're not obviously like 2,500 features, right? A lot of the work actually is spent on gardening, like another term that I really love. And so I guess this is more important when you have a big team of engineers—human engineers—that you work with, and also this goes back a little bit to what I was talking about with the environment. You know, setting up a really good environment that doesn't just help you and your agents, but everybody on your team, right? Think of a new hire who doesn't have a lot of context on all of your engineering practices joining your team. And if you have a really good environment, they can be productive from day one, right? They don't have to make—open a bunch of low-quality PRs. They can start just turning out really good code. And yeah, I think I sort of lost my train of thought.

我有一个后续问题，那就是触发的机制——比如你如何、何时触发一个智能体去查看代码，对吧？因为有些人可能会说：“哦，我们每小时做一次，或者用 cron job 之类的”，或者是什么——

I've got a follow-up, which is what are the mechanics of triggering—like how, when do you trigger an agent to go and look at the code, right? Because some people might say, 'Oh, let's just do that every hour or something or like on a cron job' or what's—

哦，是的。是的。是的。是的。我也看到你最近的一些推文，关于——你知道，你一直在发的一些推文，对于设置你的例程很有帮助。我也有一些类似的例程。所以其中之一是查看——再举一个简单的例子，你知道，React 有很多陷阱。所以，我相信你很清楚。所以我有一个智能体，它只是不断地寻找不良模式。有趣的是，我实际上并不告诉它先修复问题。我告诉它将其附加到文档中。然后每隔几天我查看一下，我发现实际上这些都是同一件事，你知道，所以这给了我——你几乎想要一个缓冲区、一个队列。有时这实际上比仅仅生成大量子智能体来修复每一件事更有效，因为当你处于纯粹的执行模式，只是试图非常快地执行进来的订单时，你有时会错过大局。所以有时有一个缓冲区会迫使你思考大局，因为你有这些工件和东西，你可以作为人类查看，并利用你自己的人类判断——或者我想你也可以用智能体来做。但你给智能体和你自己一种识别模式的方式，对吧，否则如果你只是一次解决一个 bug，你可能会错过。这也是拥有像幕僚长智能体这样的东西的真正好处：它除了实际执行之外，还能看到森林。

Oh, yeah. Yeah. Yeah. Yeah. I saw some of your recent tweets as well about like—you know, some of the tweets you've been doing which are great for setting up your routines. I have some routines like that as well. So one of them is like looking through—just another simple example is, you know, React has a lot of foot guns. So, as I'm sure you're aware. And so I have an agent that's just constantly looking for bad patterns. And the interesting thing about that one is that I don't actually tell it to fix the issue first. I tell it to append it to a document. And then every couple of days I look at it and I see actually these are all the same thing, you know, and so that gives me—you almost want like a buffer, a queue. Sometimes that's actually more effective than just spawning off a lot of sub-agents to fix every single thing because when you are in kind of pure execution mode and just trying to execute on the orders that are coming in very fast, you sometimes miss the big picture. So sometimes having a buffer forces you to think about the big picture because you have these artifacts and things that you can look at as a human and sort of use your own human judgment—or I guess you can use an agent to do that as well. But you give the agent and yourself a way to identify patterns, right, that you might otherwise miss if you're just only solving each bug at a time. And that's also really the benefit of having something like a chief of staff agent is it can see the forest in addition to actually doing the execution.

太迷人了。

Fascinating.

这——我是说，我的大脑有点爆炸了，关于软件工厂里的那种幕僚长。我可能得改改我下周要拍的一些课程。

That's—I mean, my brain is exploding a bit there with the sort of chief of staff at the software factory. I might have to change some of the course that I'm filming next week.

好吧。我们来谈谈审查，对吧？因为这是你得到的回复，你知道，是——你读了吗——你尝过所有 2500 道菜吗？它们从你面前掠过。

All right. Let's talk about review, right? Because this is the reply that you get, you know, is—did you read—did you taste all 2500 of those dishes as they swept past you?

我猜答案多种多样——是某种形式的“没有”。

And I assume the answer is a variety—is a version of no.

是的，我认为你不想陷入再也不能品尝自己食物的境地。但你也知道，为了规模，你不能品尝厨房里出来的每一道菜，尤其是如果你有多家餐厅。所以这更多是关于抽样，对吧？并且以同样的方式思考流程——我想也许这就是工厂比喻更贴切的地方——你知道，作为工厂的质量主管，你不能查看每一个项目，你抽样，对吧？你每天去那里，查看拉取请求的质量，查看智能体编写的代码，非常严格地审查，思考所有低效之处、智能体所做的坏模式，然后思考如何纠正环境，对吧？不是那个单个智能体。因为如果可能是一次性事件，那没关系。你知道也许那里没有什么可修复的。但如果你确实注意到多个智能体有同样的问题，对吧？它们走同样的捷径，它们到处传播同样的变通方法。那是一个信号，你应该去思考如何修改你的厨房或工厂，对吧？比如思考你的技能、你的约束、你的 lint、你的类型系统，并设置或调整它，以便那个问题不再发生。当你这样做足够多次时，你就会达到一个地方，代码库再次像环境一样受到如此多的约束，并且它如此好地引导你，以至于你可以直接走开，对吧？那就是梦想。我肯定会说，要达到这一点非常困难。我不想把这说成是，你知道，你只需使用 PAC 就能轻松做到的事情。就像需要大量的时间和精力来思考你的代码以及你看到智能体失败的地方，并且非常深思熟虑、有意识地设置护栏和约束，以便它们默认做正确的事情。

Yeah, I think you don't want to be in a position where you're not tasting your food ever again. But you also, you know, for scale, you cannot be tasting every single dish that comes out of your kitchen, especially if you have multiple restaurants. So it becomes more about sampling, right? And thinking about the processes in the same way that—I guess maybe this is where the factory analogy is a bit more apt—is you know as a quality supervisor on a factory you can't look at every single item you sample, right? You go in there every day and you look at the quality of the pull requests, you look at the code that the agents are writing, and you scrutinize it very rigorously, and you think about all the inefficiencies, the bad patterns that the agents are doing, and then you think about how to course correct the environment, right? Not that single agent. Because if maybe if it was a one-off incident, it's fine. You know that maybe there's nothing to fix there. But if you actually notice that multiple agents are having the same issue, right? They're taking the same shortcut, they're propagating the same workaround everywhere. That's a sign that you should go off and think about how to amend your kitchen or your factory, right? Like thinking about your skills, your constraints, your lints, your type systems, and setting or adjusting it so that that problem doesn't happen again. And when you do that enough times, then you get to a place where the codebase is again like the environment is so constrained and so it guides you so well that you can just step away, right? That's the dream. And I'll definitely say it's very hard to get to this point. I don't want to sell this as like, you know, something that you can just do easily by using PAC. Like it takes a lot of time and effort to think about your code and where you see your agents failing and thinking very thoughtfully, intentionally and setting up guard rails and constraints so that they do the right thing by default.

你不是——如果回到软件工厂的比喻，这不是一个黑暗工厂，对吧？这个——灯是亮着的，对吧？

And you're not like—if to go back to the software factory analogy, this isn't a dark factory, right? This—the lights are on, right?

有点像。是的，实际上。

It kind of is. Yeah, actually.

是吗？

Is it?

是的。嗯，从某种意义上说是黑暗的——所以从某种意义上说是黑暗的——嗯，我认为如果我的智能体在合并它们自己的拉取请求，那就有点变得黑暗了，我去睡觉，我的智能体现在 24/7 工作。我有相当于超过 10 个幕僚长，对吧？每个负责不同的领域。例如，我有一个负责 Grok Bot 桌面应用的性能，我有一个负责修复用户报告的 bug，我有一个在探索用另一种语言重写它只是为了好玩，你知道，就像如果——如果，你知道，只是重新想象如果它是一个原生应用会怎样。这只是一个玩具。但想法是，是的，我——当你花时间设置你的环境时，我已经达到一个点，我在拉取请求落地后审查它，对吧？我告诉我的智能体——全自动驾驶是你在 PAC 中可以做的事情，这会触发这个非常强烈的严格验证循环，它会为每个拉取请求生成一堆验证器智能体，它会模糊测试——对，模糊测试意味着它实际上会运行应用程序。它会点击并尝试像真人一样使用它，寻找回归，寻找你实现中的 bug，它会尝试找到问题，然后它会自己修复。它会再次这样做，最终让 PR 达到可以落地的状态。所以它相当消耗 token。你当然可以调整这个。所以你知道，不是 10 个验证器智能体，你可能只做一个，对吧？或者你只是告诉智能体验证它自己的工作。但是的，关键是验证部分真的是给我很多信心的关键部分——我想验证加上环境，对吧？是这两者的结合让我能够走开并说智能体去合并你的东西吧。我早上通过查看我的提交历史来审查它，如果我看到问题，我就去纠正，对吧？我会去还原或修改，添加新的 lint 规则等等。所以确实需要时间才能达到那个点，但一旦你达到，哦，感觉太神奇了。我告诉人们，我现在睡得好多了，因为，你知道，这需要——我打开那种黑暗工厂的第一天非常可怕，因为我想，‘哦，如果我调用 SE 呢，对吧？如果我一夜之间破坏了什么怎么办？’我认为这需要很多勇气，但不知何故我做到了。是的，现在我在一个我的智能体在我睡觉时合并它们自己代码的地方。

Yeah. Well, it's dark in the sense that—so it's dark in the sense that—well, I think if my agents are merging their own pull requests, it's sort of become dark where I go to sleep, my agents now work 24/7. I have the equivalent of more than 10 chiefs of staff, right? Each working on a different area. Like for example, I have one that's working on performance of the Grok Bot desktop app, I have one that's working on fixing bugs that users report, I have one that's exploring rewriting it in a different language just for fun, you know, like what if—what if, you know, just reimagining what it would be if it was like a native app. It's just a toy. But the idea is like, yeah, I—when you spend the time setting up your environment, I've gotten to a point where I review the pull request after it's landed, right? I tell my agents—full autopilot is something that you can do in PAC, and that will trigger off this very intense rigorous verification loop where it will spawn a bunch of verifier agents for every pull request, and it will fuzz—right, fuzzing meaning that it will actually run the application. It's going to click around and try to use it like a real human, look for regressions, look for bugs in your implementation, and it will try to find issues with the thing, and then it will fix it itself. It'll do that again and eventually get the PR to a state where it can land. So it is quite token intensive. You can tune this of course. So you know instead of like 10 verifier agents you might do like one, right? Or you just tell the agent to verify its own work. But yeah, the key thing is the verification part is really the key piece that gives me a lot of confidence—that I guess verification plus the environment, right? It's the combination of these two things that allow me to step away and say agents go off and merge your thing. I'll review it in the morning by looking at my commit history, and if I see problems, I go and course correct, right? And I'll go and revert or modify, add new lint rules and whatever. So it does take time to get to that point, but once you get it, oh, it feels so magical. I tell people like I'm sleeping so much better now because, you know, it took—the very first day I turned on the sort of dark factory was very scary because I was like, 'Ooh, what if I call the SE, right? What if I break something overnight?' And it took a lot of bravery, I think, to do that, but somehow I did it. And yeah, now I'm in a place where my agents are merging their own code while I sleep.

听起来像——

It sounds like—

我认为从那个意义上说是黑暗的。

I think it's dark in that sense.

是的，有时是黑暗的，对吧？你有时确实。

Yes, it's dark sometimes, right? You do sometimes.

那是真的。那是真的。

That's true. That's true.

因为我认为黑暗工厂几乎就像如果你采用 Karpathy 的 vibe coding 的原始定义，对吧，那就是代码几乎不存在。你忘记了代码可能是一个东西。我认为你的方法完全不同，那就是代码和环境是必不可少的。如果代码和环境不好，那么你就会得到糟糕的输出。垃圾进，垃圾出。所以我认为这是不同的东西。就像，你知道，那个——我不知道，也许有一个调光开关什么的，对吧？就像，你知道，有些部分黑暗，有些部分明亮。这就是为什么也许厨房是更好的比喻——餐厅——因为你知道即使作为餐厅，你仍然可能偶尔去你的餐厅偷看并品尝食物，对吧？

Because I think of a dark factory as like almost like if you take the original definition of Karpathy's vibe coding, right, which is the code almost doesn't exist. You forget that code might be a thing. I think your approach is totally different from that, which is that code and the environment is essential. And if the code in the environment are bad, then you will get bad outputs. Garbage in, garbage out. So I think this is a different thing. It's like, you know, the—I don't know, maybe there's a dimmer switch or something, right? Like, you know, some parts dark, some parts were light. This is why maybe the kitchen is a better analogy—the restaurant—because you know even as a restaurant you still might go to your restaurants every now and then to take a peek and taste the food, right?

我认为那是——

I think that's—

抽样而不是阻塞的想法我认为非常重要。

The idea of sampling instead of blocking I think is really important.

你会对那些人说什么——我猜你显然处于一个相当注重安全的环境中，你工作非常注重安全——嗯，也许有些人在医疗应用或法律或金融等领域工作。

What would you say to people who are in—I guess you're obviously in a pretty security conscious environment where you're working very security conscious—um, maybe there are folks working in like medical applications or law or finance or something.

我觉得有些 PR 有点像双向门，就是你可以合并然后回滚，对吧？回滚成本很低。但有些 PR 是单向门，对吧？会造成某种数据丢失，会做一些无法轻易撤回的事情。你怎么处理大多数 PR 都是单向门的情况？比如，这是你不推荐的做法，还是你怎么看？

I think some PRs are kind of like two-way doors, which is you can merge it and then revert it, right? It's cheap back through. But there are some PRs that are one-way doors, right? That will cause data loss of some kind, that will do something that can't be easily walked back. How do you deal with situations where most of your PRs, let's say, are one-way doors? Like, is this something you just wouldn't recommend or like what do you think?

是的，我觉得这是个很好的问题。我认为这归根结底取决于你能从智能体那里获得多高质量的验证。对于工作可验证的领域，这更容易，对吧？单向门在某种意义上变成了双向门。但如果你在做一些很难通过程序验证的事情，那么你肯定处于很难达到那种状态的位置。所以我确实认为领域的可验证性是能够做到这一点的重要方面。软件工程就是那些在很多情况下相当可验证的事情之一，也许不是完全可验证。其他领域比如数学，我认为是另一个例子——当然不是全部，但数学的某些方面如果写证明的话是可以验证的。所以是的，我觉得这是个很好的问题，我并没有真正的答案，我认为这是行业和我们作为工程师必须弄清楚的事情。我对未来的希望和预测是，我们会看到越来越多有趣的面向智能体的新编程语言，到目前为止我见过的最迷人的一个叫做 Bend。那种语言将编程与证明结合在一起。曾经有一段时间，你实际上不得不用不同的语言写证明。顺便说一下，对于不熟悉的人来说，证明就是你可以用数学方法形式化验证某些代码是正确的，对吧？特别是如果你以非常函数式编程的方式写代码。但很长一段时间里，你不得不在像 Lean 或 TLA+ 这样的单独语言中做这件事——我一时想不起其他例子了——但像那样的语言，你会构建数学证明，然后使用求解器来检测你已经覆盖了所有情况，没有竞态条件之类的。所以是的，试着总结这个问题，我认为如果你处于能够弄清楚你的智能体如何真正验证工作并给你信心的位置，你实际上可以让 PR 合并，因为如果它能编译，对吧，如果证明表明它是正确的，那你为什么不直接合并呢？但当然，并非所有领域都是可验证的。是的，这很难。

Yeah, I think that's a really good question. I think it all comes back to the quality of the verification that you're able to get out of your agent. And I think for domains where the work is verifiable, this is easier, right? And the one-way doors become two-way doors in a sense. But I guess if you're working on something that is very hard to verify programmatically, then I think yeah, you're definitely in a position where it's very hard to get to that point. So I do think verifiability of the domain is an important aspect to be able to do this. And software engineering is just one of those things where it's quite verifiable in a lot of cases, maybe not totally. Other domains like mathematics I think are another example—not all of it, of course, but some aspects of mathematics can be verifiable if you write a proof, for example. And so yeah, I think it's a great question that I don't really have the answer to, and I think that this is something the industry and us as engineers will have to figure out. My hope and prediction for the future is that we'll see more and more interesting new agent-oriented programming languages, and one of the most fascinating ones that I've seen so far is this one called Bend. And that language is one where it kind of marries programming with proofs. There used to be a time where you actually had to write your proofs in a different language. And proofs, by the way, for those who aren't familiar, is this idea that you can formally verify that some code is correct mathematically, right? Especially if you've written your code in a very functional programming way. But for the longest time you had to do that in a separate language like Lean or TLA+ or—I'm blanking on some of the other examples—but languages like that where you would construct the mathematical proof and then use a solver essentially to detect that you've covered all the cases, you don't have like a race condition or whatever. So yeah, I think trying to sum up the question, I think yeah, if you are in a position where you can figure out how your agents can truly verify the work in a way that gives you confidence, you can actually have the PRs merge because if it compiles, right, if the proofs show you that it's correct, then why wouldn't you just merge it? But of course, yeah, not all the domains are verifiable. Yeah, it's a tough one.

好的。我想我们得考虑收尾了，因为快到整点了。你之后还有事吗？

Okay. I think we've got to think about wrapping up because we are nearly on the hour. Have you got something after this?

我是说，在我给儿子做晚饭之前还有件事，但我可以在你之后再多聊一会儿。

I mean, I've got something before I give my son dinner, but I can go a bit longer after you.

好的，那我们再聊五分钟。我想再问一个问题，就是我想问你怎么看 Pstack 以及你总体上怎么看技能，比如——我们上节目前聊过——人们会想我的技能与你的技能，以及如何将框架组合在一起？你如何将 Pstack 与我的东西一起使用？应该从每个中汲取什么？因为我认为技能基本上只是从流程衍生出来的，就像它们只是把流程变成文字。我很想知道你建议人们如何将 Pstack 和我的东西也转化为他们自己的流程。我想你今天分享了一个我觉得非常相关的技巧，就是这个想法：你去查看你之前的转录，对吧？你从自己的提示中挖掘信息，看看你纠正智能体的地方，你不得不不断干预的地方，并把那种更高层次的学习转化为可重用的技能，对吧？这样智能体就不再重复那个错误。

Okay, let's go five minutes longer then. I think I just want to have one more question, which is I want to ask how you see Pstack and how you see skills in general, like in terms of—we talked about this before we went on air—which is like people think of as my skills versus your skills and how do you combine frameworks together? How do you use Pstack with my stuff? Like what should you take from each one? Because I think I see skills as sort of just derived from process basically, like they're just processes turned into words. And I would love to know how you recommend people take Pstack and take my stuff as well and turn it into their own processes. I think you shared a tip actually today that I thought was very relevant, which is this idea that you go off and look at your previous transcripts, right? And you sort of mine for information of your own—look through your own prompts, right, to the agents where you correct them, where you have to constantly intervene, and take that higher-level learning and turn that into a reusable skill, right? So that agents stop repeating that mistake.

我认为 Pstack 和你的技能非常互补。我完全同意你的观点，技能实际上只是流程。我的意思是，归根结底，技能只是英语或语言，只是 Markdown。我认为你绝对可以将它们编织在一起，以对你有意义的方式组合它们。但我确实认为每个人都应该有自己的那套刀，对吧？我总是回到烹饪的类比，但它太贴切了，因为每个厨师当他们去不同的工作，去不同的餐厅时，他们会带上自己的刀。工具跟着他们走，对吧？所以对我来说，信任实际上是对自己工具的信任。当你花时间磨砺它们并真正很好地理解它们时，你可以做伟大的事情。每个人的技能和工具集都会看起来不同。有人可能会发现将你的 grill me 与 docs 结合，或者将 wayfinder 技能与 Pstack 中的一些执行技能结合，会非常成功。有些人可能更多地使用你的技能，有些人可能更多地使用我的技能。我认为归根结底，这真的只是回到你有多信任我和 Matt，对吧？如果你信任我们俩，当然可以使用我们的技能，但我也鼓励你看看自己的转录。告诉智能体查看你使用过的所有模式，你不得不干预的次数，并建议将它们转化为 lint 规则或新技能，对吧？我经常说过去的聊天就像一个上下文的宝库，因为那就像流程的具体化，对吧？就像它是真实的流程。它不是你头脑中的抽象想法。它是实际的东西，对吧，你可以实际看到它是如何发生的，并从中提取大量信息。而且有太多信息了，所以我在 Pstack 中有一个叫做 recall 的技能，正是这个。这是一个模式，当时我在处理一个类似的问题——具体来说，我在为 Cursor 应用程序做虚拟化，有很多 bug。所以每次我开始新的聊天时，我就想，啊，上一次聊天有这么多好的上下文。所以我想把它带到新的聊天中。

I think that Pstack and your skills are very complementary. I totally agree with you that a skill is really much just process. I mean, it's just at the end of the day a skill is just English or language. It's just markdown. And I think you can definitely weave them, combine them in a way that makes sense to you. But I do think that everyone should have their own set of knives, right? I keep going back to the cooking analogy, but it's so apt because every chef when they go to a different job, when they go to a different restaurant, they bring their knives with them. The tools go with them, right? And so trust to me is really about trust in your own tools. And when you spend the time sharpening them and understanding them really, really well, you can do great things. And everybody's skills and tool set is going to look different. Someone might find a lot of success combining your grill me with docs, or wayfinder skill with some of the execution skills in Pstack as an example. Some people might use more of your skills, some people might use more of my skills. I think at the end of the day, it really just comes back to how much do you trust me and Matt, right? Like if you trust us both, of course, use our skills, but I also encourage you to look at your own transcripts. Tell the agent to look through all of the patterns that you've used, the times you've had to intervene, and suggest turning them into lint rules or new skills, right? The past chats I often say is like a treasure trove of context because that's like the process materialized, right? Like it's the real process. It's not an abstract idea in your head. It's the actual thing, right, and you can actually see how it happened in practice and extract so much information from that. And there's so much so that I actually have a skill in Pstack called recall which is exactly that. This was a pattern where I was working on a similar problem—specifically I was working on virtualization for the Cursor application and there were a lot of bugs. And so every time I started a new chat I was like, ah, there's so much good context from the last one. So I want to bring it over to the new chat.

我该怎么做？这就是 transcript 的由来——去看过去的对话记录。然后 recall 只是我用来把那个工作流折叠、压缩成一个 skill 的方式，这样我就不必每次都写一大段话：去看看所有这些对话，然后 blah blah blah。所以我认为 skill，尤其是随着智能体能力越来越强，本质上就是在编码工作流。去年的 skill 更多是关于实现细节——比如这里是你应该用的确切脚本命令。我觉得用最新的模型，你完全可以把那些部分删掉，真正专注于工作流。skill 变得更像是一系列步骤、一系列你的流程。而且我认为随着时间推移，skill 会变得越来越小、越来越紧凑。而且，它们非常兼容。或者，如果你愿意，为什么不读读我们的 skill，把它们组合进你自己的里面？把 Wfinder 和 potato mode 结合起来，做出你自己的自定义模式。我喜欢 skill 的地方就在于它们非常有可塑性。你想做什么都行。它只是语言而已。

How do I do that? And that's where the transcript came about — looking at the past transcript. And then recall was just a way for me to collapse and compress that workflow into a skill, so that I didn't have to write a long essay every time: go look at all these chats, and blah blah blah. So I largely think of skills, especially as agents get more capable, as really encoding workflows. Skills from last year were really more about almost like implementation details — like here are the exact script commands you should use. I think with the latest models you can just delete those parts and really focus on the workflow. The skill becomes more like a series of steps, a series of your process. And I think over time we'll see that skills get smaller and smaller, more compact. And yeah, they're very compatible. Or, if you want, why not read our skills and combine them into your own? Combine Wfinder with potato mode and make your own custom mode. The thing I love about skills is that they're so malleable. You can do anything you want. It's just language.

完全同意。它们里面没有任何魔法，对吧？它们只是文字。

Absolutely. There's nothing magical in them, right? They're just words.

正是如此。如果它们里面真有什么魔法，那也只是所选的词、所用的短语，以及把抽象流程转化为语言所付出的思考。而一旦那番思考完成了，它就在那里了。它可用。它就在表面上，你直接拿来用就行。

Exactly. If there is any magic in them, it's just the words chosen and the phrases used and the thinking that's been done to take an abstract process and turn it into language. And once that thinking has been done, then it's just there. It's available. It's on the surface and you just nick it.

Lauren，非常感谢你。这次对谈太精彩了。

Lauren, thank you so much. This has been glorious.

是啊，这次特别有意思。我真的很享受和你聊天。希望我们还能再来一次。

Yeah, this has been super fun. I really enjoyed talking to you. Hope we can do it again.

我很乐意再来一次。当然。好，我们到时候再联系——

I'd love to do it again. Absolutely. Yeah, we'll check in in —

我不知道。就周一吧。就这么定了。

I don't know. Yeah, Monday. Let's do it.

好，就这么定了。第二部。

Yeah, let's do it. Part two.

好了，非常感谢大家。我这就把直播关掉。Lauren 和我会再聊一会儿，留在这里。但非常感谢各位的观看。这次太精彩了。

Well, thank you so much. I'm going to close the stream here. Lauren and I will chat a little bit and stay here. But thank you guys so much for watching. This has been glorious.