从“盯着每一步”到“让 agent 自动合并 PR”

Hi, I'm Lauren Tan, I guess not many people know my last name. I am Potato on Twitter — "poteto", spelled with an E. And I have been at Cursor for about five months. Previously, I was at Meta, where I worked on the React team. I've been working on the React compiler, which was a whole lot of fun. I'm still on the core team and contributing to open source here and there. So that's really nice that they still let me do that.

大家好，我是 Lauren Tan，估计没多少人知道我的姓。我在 Twitter 上叫 Potato——拼成 “poteto”，带个 e。我来 Cursor 大概五个月了。之前在 Meta 的 React 团队，做 React Compiler（React 编译器），那段时间特别好玩。我现在还在 React 核心团队里，时不时给开源贡献点代码，他们还愿意让我继续参与，挺开心的。

And before Meta, I was at Netflix, where I was both a tech lead and I transitioned to be an engineering manager for the past two years. So I've had a lot of experience going between engineering management and being an individual contributor. And I think something I've noticed, actually, which is quite interesting, is that there are so many parallels with, you know, management skills, and how to, like, manage agents. And that's actually a big part about what I wanted to chat with you and everybody else about today.

在 Meta 之前我在 Netflix，先做技术负责人（tech lead），后来转做了两年工程经理。所以我在工程管理和一线工程师（IC）之间来回切换过很多次。我发现一件挺有意思的事：管理能力和“管理 agent（智能体）”之间有非常多的相通之处。这其实就是我今天想和大家聊的重点。

But yeah, that's, that's me. I do have some, like, very light slides, but it's not going to be just rambling. So let me just share and hope that I don't leak anything. Uh, oh, no, I need to allow permissions.

好，这就是我。我准备了一点很简单的幻灯片，不会只是瞎聊。我先共享一下屏幕，希望别泄露什么东西……哎呀，我得先开权限。

Uh, give me one second to rejoin.

给我一秒，我重新进一下。

Yeah, sorry.

啊，抱歉。

It's 2026 and I still don't know how to use Zoom.

都 2026 年了，我还是不会用 Zoom。

Okay. I assume you can see my screen.

好，我猜你们能看到我的屏幕了吧。

So yeah, today. Yeah, I think, I think the big theme for me as I've been using agents to write code and I'm sure you have had the same experience as well is how do you trust it? You know, especially if you are an engineer that's been writing code for a very long time, you have a lot of opinions and lessons that you've learned about doing good engineering. And when you see agents just winging it and guessing, hallucinating, confidently stating that they found the smoking gun for the hundreds of times, but it's actually not the real problem, you lose a lot of trust.

那今天……我觉得我在用 agent 写代码这件事上最大的主题——我相信你们也有同样的体验——就是：你怎么信任它？尤其如果你是写了很多年代码的工程师，你对“好的工程”有很多自己的看法和踩坑经验。然后你看到 agent 在那儿瞎蒙、乱猜、产生幻觉，第一百次信誓旦旦地说“我找到真凶了”，结果根本不是真正的问题——你就会对它失去很多信任。

And when you lose, when you don't have much trust in your agents, I feel like you really can't get the most out of them. And for me, the parallel is like with management. So if I'm an engineering manager of a team and I have a bunch of, you know, I have a team of engineers on my team and I don't trust them, then the mode of operation I'm going to be in is going to be like micro management, right?

而一旦你对 agent 没什么信任，我觉得你就很难把它的价值用足。对我来说，这和管理很像。假设我是一个团队的工程经理，手下有一群工程师，但我不信任他们，那我的工作方式就只能是微观管理（micromanagement），对吧？

I'll have to and spend a lot of time looking over my reports' shoulders and checking that they're doing their work well, you know, that they're not shipping bugs to production. And so I drew this chart because it's not a very scientific chart, but this is how I imagine myself and my journey through using agents. So fast forward or back forward or fast back, fast backwards, backwards like a year or so when not many people were using agents to code.

我得花大量时间盯着下属的肩膀看，检查他们活干得好不好、有没有把 bug 发到生产环境。所以我画了这张图——它不太科学——但这就是我想象中自己使用 agent 的旅程。倒回去大概一年左右，那时候还没多少人用 agent 写代码。

I think you get into this mode where you are in very heavily in the loop with one or several like a handful of agents and you find yourself just constantly figure, you know, trying to understand what your agents are doing and you're very, very in the loop. You're watching every single output. You are sitting there prompting and you really can't parallelize beyond that because you don't, again, you don't have that trust, right? You can't go to a hundred agents, like spawn a hundred agents when and you don't even trust the output of one agent.

我觉得你会进入一种状态：你和一个或几个 agent 紧紧绑在一起（heavily in the loop），一直在努力搞懂它们在干什么，你非常非常“在环中”。每一条输出你都盯着，你坐在那儿不停地写 prompt。你没法再往上并行，因为你没有那份信任，对吧？你连一个 agent 的输出都不信，怎么可能一下子开一百个 agent？

So over the past five months I feel like I've really been able to like ascend this trust curve and now I'm at the point where I actually have, this sounds kind of scary to say this and it makes me sound like a slop artist but I promise I'm not. But I actually have my agents now auto-merging PRs for me which is like a wild thing to say. But I woke up today, and there were 20 PRs landed, and I just reviewed them on main.

在过去五个月里，我觉得我真的一路爬上了这条“信任曲线”。现在我已经到了——这话说出来有点吓人，听起来像个“slop（垃圾代码）艺术家”，但我保证我不是——我现在真的让 agent 帮我自动合并 PR（auto-merge），这话说出来挺疯狂的。今天早上我醒来，已经有 20 个 PR 合进去了，我是直接在 main 分支上审它们的。

And they were good. So how did I get to that point? It's basically what I wanted to talk about today. Again, like, yeah, jump in if you have questions, Colin. But oh yeah, of course, I got to show this chart where No, do not trust someone requested to control my computer. I probably won't do that. But yeah, so this chart, I think I'm sharing this chart not to kind of like flex, but to kind of show like the journey, like so you can see like the curve, like it sort of like inversely matches the contributions I've been able to land at Cursor.

而且它们都没问题。那我是怎么走到这一步的？这基本就是我今天想讲的。还是那句话，Colin，有问题随时打断我。哦对，我当然得给大家看这张图——不不，别信，有人请求控制我的电脑，我大概不会同意的。好，我分享这张图不是为了炫耀，而是想展示这段旅程：你能看到这条曲线，它和我在 Cursor 落地的贡献量是“反过来对上”的。

So I joined five months ago. And five months ago, like I saw, you know, my first month, I was like not very productive you know, I was learning the code base, they didn't know what the heck was going on. And as I got more confident in my agents, I've really been able to kind of ramp up my productivity. And again, like, yeah, like last month, I shipped 1,000 PRs, which is ridiculous. And then this month, we're only on the 12th, I'm already at like almost 800 PRs landed.

我是五个月前加入的。五个月前，第一个月我效率并不高，我在熟悉代码库，完全搞不清状况。随着我对自己的 agent 越来越有信心，我的产出一路往上涨。就像上个月，我合了 1000 个 PR，这很离谱。这个月才到 12 号，我已经落地了将近 800 个 PR。

So the velocity is definitely high, And I should fear a lot of you will definitely be questioning how much of this code is actually good. And I think, yeah, that's definitely fair to question. But yeah, I think if you set up your agents well, you can definitely get to a very similar level. And so I'm gonna talk about how we do that. So for me, I think, I'm curious, like I guess Colin, your experience as well, but for me, I think the most important skill that you should have in your, toolbox when you work with agents is verification.

所以速度确实很高。我猜你们很多人肯定会质疑：这些代码到底有多少是好的？我觉得这个质疑完全合理。但我认为，只要你把 agent 配置好，你也绝对可以达到差不多的水平。下面我就讲讲怎么做。对我来说——Colin，我也好奇你的体验——我认为和 agent 一起工作时，你工具箱里最重要的一项能力是：验证（verification）。

And by verification, I mean the ability for an agent to actually run the code or take CPU traces or heap snapshots or open an iOS simulator, whatever, you know, however your application is exposed to your users, it can do the same thing and run it for real and actually test and verify it does work. Because that's the thing that really closes the loop. It doesn't guarantee your agent writes good code, but it allows them to at least write correct code, which is a big a really big step forward for being able to trust your agent. I will, I can share one example that we have, uh, within Cursor, uh, oops, where, let me open this.

我说的验证，是指 agent 有能力真正把代码跑起来，或者抓 CPU trace、堆快照（heap snapshot），或者打开 iOS 模拟器——总之，你的应用以什么方式呈现给用户，agent 就能用同样的方式去真实地运行它，实际测试并验证它确实能用。因为正是这一点真正“闭环”了。它不能保证 agent 写出好代码，但至少能让它写出正确的代码，这对于能否信任 agent 来说是非常大的一步。我可以分享一个我们 Cursor 内部的例子……哎，我打开一下。

So for the for Cursor's Agents Window, so this is actually an interesting story, but when I joined Cursor five months ago, they're actually, well, I was supposed to join a different team. I was supposed to join the cloud agents team. But then since I have a lot of experience working on React and Agents Window is a React application. I was asked to basically help out with the Agents Window work. but there weren't really any skills to help me.

就拿 Cursor 的 Agents Window 来说，这其实是个挺有意思的故事。我五个月前加入 Cursor 时，本来要去另一个团队——cloud agents（云端 agent）团队。但因为我在 React 上经验很多，而 Agents Window 是个 React 应用，所以我被拉去帮忙做 Agents Window。可当时根本没有什么 skill 能帮到我。

So I just found myself that, OK, Agents Window is going to launch in like a week. We have a really tight deadline. And there was, you know, I was just sitting there, like, okay, okay, I'm going to open up the performance, the Chrome DevTools and just like, take a trace, look at it myself and try to make sense of this flame graph. And keep in mind, I was just like, in my first week, so I had no idea what I was looking at, no idea, you know, I mean, I had some idea, but, you know, the code base was completely fresh to me.

于是我发现自己处在这种境地：Agents Window 大概一周后就要发布，截止时间特别紧。我就坐在那儿想，好吧，打开 Chrome DevTools 的性能面板，抓个 trace，自己看，试着读懂这张火焰图。要知道，那是我入职第一周，我根本不知道自己在看什么——好吧也有点概念——但这个代码库对我来说是全新的。

And I realized like my agent had no idea either, you know, like I would take a screenshot of the [unclear: trace] or send it to it and it'd be like, yeah, it kind of looks like this, you know, and it would like confidently state like, it's this thing. And then I try to fix that. And turns out that's not the actual thing. So this was a very, very slow process. And if you've ever done any like performance work yourself or just even development with an agent where you don't have a verification skill, you are the verifier.

然后我意识到，我的 agent 也完全不懂。我会把 trace 截图【此处听不清】发给它，它就说“嗯，看起来像是这样”，然后很自信地断言“就是这个问题”。我去修，结果发现根本不是那回事。所以这个过程非常非常慢。如果你自己做过性能优化，或者只是在没有验证 skill 的情况下用 agent 开发，你就会发现：你自己就是那个验证者。

All right, you're the bottleneck. You tell your agent to do something, and then it goes off and writes some code. Then you open up your local dev build, and then you start to say, oh, it doesn't work. Then you got to copy paste screenshots or console errors or whatever. And then your agent like slowly kind of like works with that and then tries to understand it and fix the thing. But then you're constantly just in the loop and being a bottleneck.

对，你就是瓶颈。你让 agent 去做点事，它写了些代码；然后你打开本地开发版，说“不行，没用”；再复制粘贴截图、控制台报错之类的；然后 agent 慢慢消化这些信息，试着理解、去修。你一直被困在环里，一直是瓶颈。

So there's really no way to parallelize. So the control glass skills are like one of the first skills I built for Cursor and glass by the way is the code name for agents window that we use internally, it's just Cursor I guess. And so this skill is, I guess the code itself is not super interesting. Your agent can very easily make one for you where if you're building an electron app or a web app or even iOS applications, you can teach your agent how to use like the Chrome DevTools protocol or through Apple has some utilities as well for running the simulator and taking traces and programmatic control as well.

这样根本没办法并行。所以 control-glass 这类 skill 是我在 Cursor 最早做的几个 skill 之一——顺便说一下，Glass 是我们内部对 Agents Window 的代号，其实就是 Cursor 本身吧。这个 skill 的代码本身没什么特别的，你的 agent 很容易就能帮你写一个：如果你在做 Electron 应用、Web 应用，甚至 iOS 应用，你可以教 agent 使用 Chrome DevTools Protocol（CDP），或者苹果也有一些工具可以跑模拟器、抓 trace、做程序化控制。

So that's really useful. But one thing I actually want to talk about is the, this thing. This skill comes with this very unique file called a feature map. And so the story then is I built this skill, and so now the agent was able to actually run the agent window and take traces and whatnot. But it had no idea what the agent's window was. So someone would say, oh, the left side bar is laggy or something like that.

这非常有用。但我真正想讲的是这个东西：这个 skill 带着一个很特别的文件，叫 feature map（功能地图）。事情是这样的：我做了这个 skill 之后，agent 能运行 Agents Window、能抓 trace 了，但它完全不知道 Agents Window 是什么。比如有人说“左侧边栏很卡”之类的，

Or the right side, the PR tab is not working. And the agent would just be kind of flailing around. It would spend a lot of time trying to look up the code. And where is this feature? How do I actually get to it on the UI? Which made it basically completely useless. I would run the skill locally. and it would spawn a dev build, but then it'd just be churning. It'd just try to click here. It wouldn't know how to get to things, and it was just an awful experience.

或者“右边的 PR 标签页不工作”，agent 就会到处乱撞，花很多时间去翻代码：这个功能在哪？我在 UI 上怎么才能点到它？这就让它基本毫无用处。我在本地跑这个 skill，它会起一个开发版，然后就一直空转，到处乱点，找不到东西，体验非常糟糕。

So who was putting arrows on my screen? So yeah, this feature map has been really useful because it teaches the agent how to get to all of the features that you have. And in pstack with a plugin that I've made, if you search for it in Cursor, you'll find it. But there is a create a verification skill in that plugin where it actually helps you set up something like this for yourself, including the feature map. So it will actually explore the code and build up this initial feature map that tells your agent how to get to all of the different features that you have.

……谁在我屏幕上画箭头？好，总之这个 feature map 非常有用，因为它教会 agent 怎么到达你所有的功能。我做了一个插件叫 pstack，在 Cursor 里搜就能找到。插件里有一个“create verification skill（创建验证 skill）”，能帮你给自己搭一个类似的东西，包括 feature map。它会去探索代码，生成一份初始的 feature map，告诉 agent 如何到达各个不同的功能。

And this is extremely powerful because now that you have these user reports that come in you can actually map, even like a vague report or even a screenshot. So we have this internally at Cursor where we have a Slack channel with lots of people giving us feedback on the agents window and Grok Bot [?] and whatnot. And oftentimes the report is very bad, very low-quality. you know, very often we get like a screenshot, like, and then someone just says, question mark, question mark, question mark, like, what is this?

这非常强大，因为当用户反馈进来时，哪怕是很模糊的描述、甚至只有一张截图，你也能把它对应到具体功能上。Cursor 内部有一个 Slack 频道，很多人在里面反馈 Agents Window、Grok Bot【?】等产品的问题。很多时候反馈质量很差，经常就是一张截图，然后有人打三个问号：“这是啥？？？”

And, you know, like, without this, your agent's like, I have no clue, right? But with a feature map like this, it has a lot more context and understanding of how to actually navigate, how to get to all of the different features. So like, you know, example, like, I guess like the sidebar, like, what is the sidebar? You know, like all the different sub-features that are present in it, like from the user point of view, shows how to get to it, all the different keyboard shortcuts, even like the what do you call it, the DOM elements, or yeah, like the attributes that you use for selecting things through the CDP are all there.

没有 feature map 的话，你的 agent 就是“我毫无头绪”，对吧？但有了这样的 feature map，它就有了更多上下文，知道该怎么导航、怎么到达各个功能。比如侧边栏：侧边栏是什么？它里面有哪些子功能（从用户视角来看），怎么到达，有哪些快捷键，甚至那些——叫什么来着——DOM 元素，或者说通过 CDP 选择元素时用的属性，全都写在里面。

So again, yeah, this is really, really, powerful for agents. And pstack ships that create-verification skill, but also a maintain-verification skill, so you can keep this up to date. [unclear]

所以，这对 agent 来说真的非常非常强大。pstack 里不仅有“创建验证 skill”，还有一个“维护验证 skill（maintain verification skill）”，让你能持续更新它。【此处听不清】

Yeah. so pstack is pretty interesting because well, first of all, the name is kind of goofy. Like the P the P in pstack is like "potato" — potato stack. Because I, so there is a pretty famous person, Garry Tan, who is the CEO of Y Combinator, and he's come up with this plugin called gstack, "Garry stack", and funnily enough we shared the last name, we have no relations, but I thought it would be funny to poke fun at Garry and make pstack, my version of his plug-in, but kind of just tailor it to my own set of engineering practices. But I honestly actually never set out to, to build pstack. It just started with a bunch of skills. I started with that control glass skill, and then I started with another skill called [unclear: "HAL"], which I also noticed through observing agents. So in the early days of me

好。pstack 挺有意思的，首先名字就很搞笑。pstack 里的 P 是 “potato”——potato stack。因为有一位挺有名的人，Y Combinator 的 CEO Garry Tan，他做了一个插件叫 gstack，也就是 “Garry stack”。巧的是我们同姓，但没有任何亲戚关系。我觉得拿 Garry 开个玩笑挺好玩的，就做了 pstack——我自己版本的插件，但按我自己的工程实践来定制。不过说实话，我从来没打算专门去做 pstack，它最开始只是一堆 skill。我先做了 control-glass 这个 skill，然后又做了另一个叫【听不清，疑似 “HAL”】的 skill，这也是我通过观察 agent 发现的需求。在我刚开始爬这条阶梯的时候，

Trying to climb this ladder. I was like super in the loop and I was basically nitpicking my agents to an extreme degree. I was like, I would tell it, you know, this feature has stopped working. Here's a bug report. Like, why isn't it working? And very often the agent would just like confidently state like, oh, it has to be this, right? It has to be this thing. And I noticed like when I looked at the actual tool calls, I noticed it wasn't actually reading the code that I thought should be affected.

我非常“在环中”，对 agent 的挑剔到了极致。我会跟它说：这个功能坏了，这是 bug 报告，为什么不工作？它经常会非常自信地说：“哦，肯定是这个，一定是这个原因。”然后我去看它实际的工具调用（tool calls），发现它根本没去读我认为应该相关的那部分代码。

And that made me just extremely suspicious. And at that point else is that I'm not gonna, I can't trust this agent anymore because it's just completely hallucinating. And I think it's very easy to just build up that distrust and kind of [unclear]. Like, you don't know how to help your agents succeed. But again, I think the management analogy is super helpful because imagine if you were a manager of an engineering team. And you had an engineer on your team who was a really good coder, no business context whatsoever.

这让我极度怀疑。那一刻我就觉得：我不能再信任这个 agent 了，它完全在胡编。我觉得人很容易就这样积累起不信任，然后【听不清】。你并不知道怎么帮你的 agent 成功。但管理的类比在这里同样非常有帮助：想象你是一个工程团队的经理，团队里有个工程师代码写得很好，但完全没有业务上下文——

You know, they just, you just hired them and they onboarded, you know, like five seconds ago. And so how do you actually teach that person to be effective? So how you do that is through a skill. Skill being just, you know, it's just markdown, right? But, you know, it encodes a lot of information, instructions, a lot of, You can really draw out a lot of intelligence from an agent by, well, some people on Twitter call it, like, you know, pull the agent to a different latent space, which is kind of like a fancy way of just saying, like, since, you know, LLMs are sort of like, they predict the next token.

你刚招了他，他五秒钟前才入职。那你要怎么让这个人真正高效起来？答案就是 skill。skill 说到底就是 markdown 文件，对吧？但它编码了大量的信息和指令。你可以通过它从 agent 身上“激发”出很多智能——Twitter 上有人把这叫做“把 agent 拉到另一个潜在空间（latent space）”，说白了就是：LLM 本质上是在预测下一个 token，

When you give it some high quality tokens to begin with, then, you know, it can kind of pattern match on like a higher space that's, you know, smarter. So that's like a very interesting model there. But yeah, I built pstack very, very incrementally. So started with just really observing how agents in all the different failure modes of that agents were having. And every time I saw that, I just, okay, I'm just gonna make that a skill.

当你一开始给它一些高质量的 token，它就能在一个更高、更聪明的空间里做模式匹配。这是个很有意思的思维模型。总之，我是非常非常渐进地把 pstack 做出来的：一开始就是认真观察 agent 的各种失败模式（failure modes），每次看到一种，我就说：好，我把这个做成一个 skill。

All right, like stop hallucinating, actually go and search up, look up

比如：别再胡编了，真的去搜一下、查一下……

Yeah, [unclear] Maybe I'll start with this one first. How do I maintain these skills? If you're not familiar with this concept, an eval is a way to... the mental model I have is like a unit test for an agent. You can make your own evals, you don't need a special framework for them. You can build one depending on how scientific and how rigorous you want to be. My screen, is red.

嗯，【听不清】我先从这个问题说起吧：我怎么维护这些 skill？如果你不熟悉这个概念：eval（评测）是一种……我的思维模型是，它就像 agent 的单元测试。你可以自己做 eval，不需要什么特别的框架，取决于你想做得多科学、多严谨。……我的屏幕变红了。

Sorry. Oh, if you mind disabling the drawing or something, I can't see my screen.

抱歉。能不能请大家把画图关掉什么的？我看不到我的屏幕了。

[unclear] clear, yeah okay yeah you got it perfect um yeah so evals are a way to unit test your skills basically and actually in pstack we ship uh under potato mode there's a playbook if you search right called eval playbook um and it's uh it's like not it's actually pretty rigorous the way it's done, but essentially what I do is I spawn a lot of different sub-agents. I have like my main coordinator agent come up with a rubric for what I want the skill to do and then it spawns all these sub-agents and it creates individual directories for them which are cleverly named to not let the sub-agent know that it's being evaluated because agents can actually tell and when they do, they change their behavior.

【听不清】清掉了，好，搞定，完美。嗯，所以 eval 基本上就是给你的 skill 做单元测试。pstack 里在 potato mode 下面有一个 playbook，搜一下就能找到，叫 eval playbook。它其实做得相当严谨。大致做法是：我会启动很多不同的子 agent（sub-agent）。先让主协调 agent（coordinator agent）针对我希望这个 skill 达成的效果写一份评分标准（rubric），然后它再派出这些子 agent，给每个子 agent 建独立的目录——目录名会巧妙地起，不让子 agent 知道自己正在被评测，因为 agent 其实能察觉到，一旦察觉，它们的行为就会改变。

But it does a bunch of stuff like that to essentially, yeah, like test whether or not the skill I'm making or changing is actually doing what I think it does. And one of the really nice things about Cursor is that we support so many different models. So you can actually eval your skill across all sorts of different models and get a sense of how well it performs across the different matrix especially for the models that you use.

它会做一堆类似的事情，本质上就是测试我正在新建或修改的 skill 是否真的在做我以为它在做的事。Cursor 一个很好的地方是我们支持非常多的模型，所以你可以在各种不同的模型上评测你的 skill，看看它在不同模型组成的矩阵上表现如何，尤其是你自己常用的那些模型。

So I do this a lot. Every time I modify a skill, I will run one of these like the eval playbook and make sure that it's actually leading to a result I want. But I will say like, maintaining skills is actually pretty hard. actually pretty hard. It requires I think a lot of taste and observation. So you kind of need to be very good at being a backseat driver. You know what I mean? If you've ever done pair programming, for example, and you watch a co-worker code, and you're just like, you could probably do this better. Or, you know, you could do it, like, why did you not do this, right? You ask a lot of questions to your co-worker. And it's kind of a similar thing here. You don't want to just be a passive observer of the agent, you want to be very in the driver's seat in

我经常这么做。每次改一个 skill，我都会跑一遍 eval playbook，确认它真的带来我想要的结果。不过我得说，维护 skill 其实挺难的，需要大量的品味（taste）和观察。你得非常擅长当一个“后座司机”。懂我意思吧？如果你做过结对编程，看着同事写代码，你会想：这里你可以写得更好；或者：你为什么不这样做？你会问同事很多问题。这里也是类似的。你不能只当 agent 的被动旁观者，在你搭建自己那套 skill 的初期阶段，

The initial stages when you're building up your own set of skills. Obviously you can use something like pstack, but if you're building your own set of skills, it's very, I think, opening up all the tool calls and reading the code and reading all the agent behavior and their thinking blocks is a really great way to see where they fail. Where are they being dumb? And then you, you can go and build a skill for that. And then with verification, how you trust it is, it's, I think it's also a very similar iteration loop where, you know, like, I actually did the same process for verifying the verification skill, where I actually [unclear].

你要牢牢坐在驾驶位上。当然你可以直接用 pstack 这类现成的东西，但如果你要建自己的 skill，我认为展开所有的工具调用、读代码、读 agent 的全部行为和它们的思考过程（thinking blocks），是发现它们在哪里失败、在哪里犯傻的绝佳方式。然后你就可以针对那个问题去写一个 skill。至于验证——你怎么信任它——我觉得也是非常相似的迭代循环。我其实用同样的流程去“验证这个验证 skill”，【听不清】。

So one thing that's interesting about evals is that you can sort of hill climb them, meaning that your eval can, can produce a score, right, a score that you can get your coordinator to produce, but also you can have a judge agent of a different model to kind of cross-reference and make sure that the first model is not being biased, the model that's judging all of the sub-agents that are running the thing. But you can also like hill climb.

eval 有个很有意思的地方：你可以对它做“爬山”（hill climbing）优化。也就是说，你的 eval 可以产出一个分数——你可以让协调 agent 打分，同时还可以让另一个不同模型的“裁判 agent”（judge agent）交叉核对，确保第一个模型——也就是给所有跑任务的子 agent 打分的那个模型——没有偏见。另外你还可以爬山：

So meaning that you can use like /loop in Cursor. And you can say, OK, keep looping on this eval until everything is 10 out of 10 as an example. And I did the same, basically the same approach with the control skill. And so I kind of, it was very, it was very hands off actually. So, you know, I kind of built, I built that skill that way, like the CLI in that skill. And over time it's gotten really good.

也就是说你可以用 Cursor 里的 /loop，告诉它：持续循环这个 eval，直到所有项都是 10 分（满分）为止。我做 control 那个 skill 时基本也是这个方法，过程其实非常放手。我就是这样把那个 skill——包括里面的 CLI——做出来的。随着时间推移，它变得非常好用。

But yeah, it was definitely not super smooth. At the beginning it required a lot of iteration. And I think there's an analogy here for me, which is, well, I make this analogy later in a different slide online drawing here. But I think of it like, as an engineer now, you're sort of more like a middle manager or the analogy I like is like you are like a chef in a restaurant. You're the head chef. You're not cooking all the food yourself anymore.

不过一开始绝对不顺利，需要大量迭代。我觉得这里有个类比——我在后面另一张手绘图里也会讲——我是这么看的：作为工程师，你现在更像一个中层经理；或者我更喜欢的类比是：你像餐厅里的厨师，而且是主厨。你不再自己做所有的菜了，

You have a team of cooks, right? You have line cooks, you have a sous chef, you have all these different stations. And it's your job to really design the environment. You know, you're in charge of setting up the kitchen. You're in charge of, you know, like giving tasks to different people. So, yeah, it's a very interesting way of working. But yeah, that's how I basically built these verification skills.

你有一支厨师团队，对吧？有一线厨师（line cook），有副主厨（sous chef），有各种不同的工位。你的工作是设计好整个环境：你负责布置厨房，你负责把任务分派给不同的人。这是一种非常有意思的工作方式。总之，我基本就是这样搭出这些验证 skill 的。

I think that the best place to start is local because you can definitely observe what your agents are doing. So if you're building a verification skill for yourself, I would definitely start local and just have your agent bring up the application, whether it's like a CLI or desktop app or whatever. And so you can actually observe, right? You can see how the agent is interacting with the application. You can see the application. You can see it calls the different APIs that allow it to interact with the application.

我觉得最好的起点是本地，因为你可以清楚地观察 agent 在做什么。如果你要给自己建一个验证 skill，我绝对建议从本地开始：让 agent 把应用拉起来，不管是 CLI 还是桌面应用之类的。这样你能真正观察到 agent 如何与应用交互，看到应用本身，看到它如何调用各种允许它操作应用的 API。

But for me, personally, I have basically been kind of mostly all-in on cloud agents, because of extremely powerful. And the really powerful thing about Cursor is the cloud agents, actually, where if you spend a little bit of time setting up the environment, these control skills, these verification skills, pay a huge amount of dividends because it's not just something that makes you as a single engineer better. It actually levels up your whole team and even your whole company because you can actually start thinking about cloud agents, you can start thinking about automations that automatically do things like, I'll, I get to, I kind of talk about this a bit later, but I'll just kind of get into it, where, you know, for example, like, I talk a lot about this agent we have called Benny, right,

但就我个人而言，我现在基本已经全面转向 cloud agents（云端 agent）了，因为它们非常强大。Cursor 真正强大的地方其实就是 cloud agents：只要你花一点时间把环境配置好，这些 control skill、验证 skill 就会带来巨大的回报，因为它不只是让你这一个工程师变强，而是让整个团队、甚至整个公司都升级。你可以开始考虑 cloud agents，考虑自动去做事的自动化流程（automations）。我后面会再讲，不过先直接说吧：比如我经常提到我们有个 agent 叫 Benny，

Who, you know, takes all of the bug reports that we get, and it automatically goes off in the cloud, opens up a cloud it's desktop., it runs, Cursor in it's own computer and it uses the same control skills to interact with the application and try to reproduce the bug or the user report, right? And this is so powerful because at once I can immediately, I get so much information from this automatically. Like here in this example, you can see that the Benny actually reproduced the bug, but it's already fixed on main.

它会接收我们收到的所有 bug 报告，然后自动在云端开一台自己的桌面电脑，在自己的机器上运行 Cursor，用同样的 control skill 去操作应用，尝试复现这个 bug 或用户反馈。这非常强大，因为我一下子就能自动拿到大量信息。比如这个例子里，你能看到 Benny 确实复现了这个 bug，但它在 main 分支上已经修好了。

So it actually confirms that we fixed this problem already. And all I need to do is just release another build of Cursor. So that's like huge information there that I didn't have to go off and sit with an agent and spend an hour trying to figure out, is this fixed? Is this not fixed? So you gain back so much time. But everybody on my team benefits from this. Everybody in the company benefits from this. So definitely think that, you know, keeping these, using cloud agents is super powerful.

所以它实际上确认了我们已经修复了这个问题，我只需要再发一个 Cursor 的新版本就行。这是非常关键的信息，而我不用自己坐下来跟 agent 花一个小时去搞清楚“到底修没修好”。你能省回大量时间，而且我团队里每个人、整个公司的每个人都能从中受益。所以我真心觉得用 cloud agents 非常强大。

But yeah, it's like a journey. You have to trust it first, right, before you get to this point. And that's, it goes back to what I was saying here, where, you know, it's very hard. It's almost impossible. And I would definitely encourage you not to try to jump from, you know, like, if you're still in this zone, you don't want to jump to like, I'm going to spawn a hundred or thousands of cloud agents right now because you're just going a waste of a lot of tokens and it's going to be extremely expensive.

但这是一段旅程。在走到这一步之前，你得先建立信任。这又回到我前面说的：这很难，几乎不可能一步跨过去。我绝对劝你不要试图跳级——如果你还在这个区间，就别想着“我现在就开一百个、几千个 cloud agent”，因为你只会浪费大量 token，而且会极其昂贵。

Yeah, exactly. I think that's why I drew this curve, right? Because this basically describes my journey of when I started, barely could use a couple of agents, and I was just observing every single thing. I think there's really no shortcut from going from here to there, because this is really about your personal level of trust in agents. Obviously, as an engineer, you don't want to just slop code into production. So how do you actually build up that trust?

对，完全正确。这就是我画这条曲线的原因。它基本描述了我的旅程：刚开始我几乎只能用两三个 agent，而且每一步都在盯着。我认为从这里到那里没有捷径，因为这本质上关乎你个人对 agent 的信任程度。显然，作为工程师，你不想把 slop 代码直接推到生产环境。那你要怎么建立起这份信任？

Takes a lot of, I guess, taste and judgment. But I think plugins like pstack definitely can help you get up to speed much quicker. And so I guess it's like, if you trust me and you trust pstack, then by extension, you can maybe trust your agents. But if you don't trust me, and I definitely would not encourage people to blindly trust me, [build] your own set of skills that you can obviously, you know, take a look at pstack and kind of fork it, make it your own, improve the skills, definitely encourage that. But for me, it's really all about, it just keeps coming back to trust. You know, every one of us here in this chat have a different standard for engineering. And there are different things that are important for us in our code base. And when you are able to encode all of that into skills and you can verify that

这需要大量的品味和判断力。但我觉得像 pstack 这样的插件确实能帮你更快上手。可以这么说：如果你信任我、信任 pstack，那顺带地你也许就能信任你的 agent。但如果你不信任我——我也绝对不鼓励大家盲目信任我——那就【去建】你自己的一套 skill：你当然可以看看 pstack，fork 一份，改成你自己的、改进里面的 skill，我非常鼓励这样做。但对我来说，一切的核心始终是信任。今天在场的每个人对工程都有不同的标准，对代码库里什么重要也各有看法。当你能把这些都编码进 skill，并且能验证

That your agent is actually doing, that allows you to really kind of ascend this curve and start automating things. There's another piece I wanted to talk about. If there's more. Yeah, go for it. I'll pick up more questions as I go. But yeah. I think there's a third part to this, which I haven't talked about yet, which is kind of an interesting one, which is like refactoring and rewriting, like one of the, I guess, most controversial, one of the most controversial topics in the industry I think is like should you rewrite your app or not because I think engineers are very prone to this where especially when you join a company you come in and you see like the code base and you're like man this is shit like who wrote this code it's terrible

你的 agent 确实照做了，你就能真正沿着这条曲线往上爬，开始把事情自动化。我还想讲另一部分——如果还有时间的话。（主持人：好，请继续，我边听边收集问题。）我觉得还有第三部分我还没讲，挺有意思的：重构和重写。这大概是业界最有争议的话题之一——你到底该不该重写你的应用？因为工程师特别容易有这种冲动，尤其是刚加入一家公司，看到代码库，就会想：天哪这是什么垃圾，谁写的，太烂了，

I want to rewrite the whole thing there is a very common inclination and I think a lot of you know before agents and I guess arguably even now people will definitely discourage you from rewriting stuff. But I'm actually here to make a case for why you might want to consider it. Because I think it really depends. Brownfield applications I think are actually in a pretty good spot, especially if they're set up well already. And like recently I've been talking to some people but you know I was just observing I just noticed this parallel which is that a lot of big tech company problems are now everybody's problems and the big tech company problem you know like when I was working at meta like we had this giant at monorepo, we had like, I don't know,

我要把整个东西重写一遍。这是很常见的倾向。我觉得在 agent 出现之前，甚至可以说直到现在，大家肯定都会劝你别重写。但我今天其实是来论证你为什么可以考虑重写。因为我觉得这要看情况。Brownfield（存量/老项目）应用其实处境还不错，尤其是本身已经搭得很好的那种。最近我和一些人聊，我观察到一个类比：很多大厂的问题现在变成了所有人的问题。大厂的问题是什么？比如我在 Meta 的时候，我们有一个巨型 monorepo，有大概——我也不知道——

Tens of thousands of engineers just, you know, like banging on their keyboards and shipping code. And a lot of really great engineers at Meta, but I'll say like, you know, you'll be surprised that the code quality is actually not that good. And so I often joke that like, you know, before AI slop, we had human slop. And so, you know, I think a lot of big tech info, like what Meta has, or Google, really big tech companies are actually designed for that, where you're sort of like, you're catering to the, you know, like, that sounds so bad to say, but like the least capable engineer in your team, right?

几万名工程师在那儿敲键盘、发代码。Meta 有很多非常优秀的工程师，但我得说，你会惊讶于它的代码质量其实并没那么好。所以我经常开玩笑说：在 AI slop 之前，我们早就有 human slop 了。所以我觉得很多大厂的基础设施——比如 Meta、Google 这种超大公司——其实就是为此设计的：你是在照顾——这话听起来很糟——团队里能力最弱的那个工程师，对吧？

You build frameworks, you build conventions, you build guardrails, you know, you restrict credentials so that, you know, your intern doesn't wipe your production database. There's, you know, ifs you have that level of infra already, I think your agents can actually already do a very solid job, right? Because they have, the guardrails are already in place for agents to not cause havoc, or not cause too much havoc in your codebase, and you can always add more, you know, guardrails.

你搭框架、定规范、建护栏（guardrails），你限制权限凭据，免得实习生把你的生产数据库删了。如果你已经有这种级别的基础设施，我觉得你的 agent 其实已经能干得相当不错了，对吧？因为护栏已经在那儿了，agent 不会在代码库里搞破坏，或者至少不会搞太大的破坏，而且你随时可以再加护栏。

But I think, like, Greenfield applications especially are, you know, the brand new applications are the biggest risk, in my opinion, for the greatest opportunity. Because if you vibe code a project, a prototype, like we did for Grok Bot, Grok Bot was spun up very quickly. And if you haven't heard of Grok Bot, it's like a new application we just launched yesterday. It's really cool. Let's you orchestrate your, create like individual agents that have their own identity.

但我觉得 Greenfield（全新）应用——也就是全新的项目——在我看来风险最大，也是最大的机会。因为如果你 vibe code（凭感觉让 AI 写）一个项目、一个原型——就像我们做 Grok Bot 那样，Grok Bot 是非常快就搭起来的。如果你还没听说过 Grok Bot，它是我们昨天刚发布的新应用，非常酷，能让你创建一个个有自己身份的 agent，

And you can kind of orchestrate them. It's super cool, definitely check it out. But yeah, it was a very green field application like most prototypes are. So it was like vibe coded very quickly humans were not reading the code at all. And I had this tweet recently where I said something about organic architecture, maybe I'll find it. But the idea is that when you have a completely vibe coded application, you essentially have no guardrails whatsoever.

然后你可以去编排（orchestrate）它们。真的很酷，一定去看看。不过它是一个非常典型的 greenfield 应用，就像大多数原型一样，是很快 vibe code 出来的，人根本没读过代码。我最近发过一条推，讲“有机架构（organic architecture）”，也许我能找出来。核心观点是：当你有一个完全 vibe code 出来的应用，你基本上没有任何护栏。

So your agents, when you give them a task, they will just solve it in whatever method is the most convenient. And over time, you get into this situation where you have a, a code base that is spiraling out of control because you don't understand it. Your agents understand it, I guess, in a way. But they've built something that is optimized for shortcuts. And you will have a lot of issues with that application. So I think starting your code base with very strong constraints is very much needed.

所以你给 agent 一个任务，它就会用最方便的方式去解决。久而久之，你就会陷入一种局面：代码库逐渐失控，因为你不理解它。你的 agent 某种程度上理解它，但它们造出来的东西是为“走捷径”而优化的。你会在这个应用上遇到很多问题。所以我认为，代码库一开始就要有非常强的约束，这是非常必要的。

Because when you have a code base that you can trust, when you have guardrails that actually help agents, right? Good code. You can get into this part of the curve where I said I woke up today and I had 20 PRs merged by my agents and that's because I invested a lot of time over 600 PRs. I calculated yesterday when I refactored all of Grok Bot to this new architecture that I've been building. And yeah, I've gotten to a point where I don't really look, I really don't look at the code anymore. And I say that not just to sell you tokens, but because it took a lot of work to get to that point, I spent a lot of tokens to get the code base to this point where I no longer have to look at it. But I'm very excited because of the potential where it's not just,

因为当你有一个可以信任的代码库，有真正能帮到 agent 的护栏——好的代码——你就能进入曲线的这一段：就像我说的，今天醒来有 20 个 PR 被 agent 合并了。那是因为我投入了大量时间——我昨天算了一下，超过 600 个 PR——把整个 Grok Bot 重构到我一直在搭的这套新架构上。现在我已经到了基本不看代码的程度。我这么说不是为了卖你 token，而是因为走到这一步花了大量功夫，我花了很多 token 才把代码库弄到不需要我再看的状态。但我非常兴奋，因为它的潜力在于：

But this doesn't just benefit me, it benefits everyone contributing to Grok Bot and it also empowers, you know, designers and product managers and, you know, people, even GTM people to add features to Grok Bot and I don't have to worry, you know, I don't have to wake up at night in the middle of the night and worry like, oh, shit, someone's just merged to perf regression. Right, I have a ton of constraints and CI is like, it's actually very annoying to write code in Grok Bot, like, agents absorb all of that annoyance, but yeah, I'm happy to talk about what exactly that is.

这不只让我受益，而是让所有给 Grok Bot 贡献代码的人受益，还能让设计师、产品经理，甚至 GTM（市场/销售）同事去给 Grok Bot 加功能，而我不用担心——不用半夜惊醒想“糟了，有人刚合进来一个性能回退”。我有一大堆约束，CI 让人在 Grok Bot 里写代码其实非常烦，但 agent 吸收了所有这些烦恼。我很乐意讲讲这些约束具体是什么。

I think it depends, maybe I'm trying to do this in a way where I'm not gonna like-

我觉得要看情况，也许我可以这样展示，不会……

I think this is fine. Benchmark. But like we have, so okay, this is not that interesting But well, fun fact is that virtualization in Grok Bot and in Cursor is actually powered by Pretext, which is a sort of new library that someone's built. That's really interesting, you should check it out. But that's not really that important. I think the average PR size's size, I actually don't know. I don't know if I wanna click on these. I probably can, but I would say like, there can range anywhere from a few hundred lines or 50 lines to like a thousand depending on what the thing is doing. So like here I'm deleting a bunch of files so I expect that it's just like mostly deletion. But yeah, it kind of varies. There's no like, yeah, is there a hard cap, or are they

我觉得这样没问题。【听不清】不过我们有——好吧，这个不太重要——有个冷知识：Grok Bot 和 Cursor 里的虚拟化（virtualization）其实是基于 Pretext 的，这是某人新做的一个库，挺有意思的，可以去看看。不过这不重要。平均 PR 大小我其实不知道。我不确定要不要点开这些……应该可以吧。我会说，从几十行（50 行）、几百行到一千行左右不等，看它在做什么。比如这里我在删一堆文件，那我预期大部分都是删除。所以差别挺大的。（主持人：有硬性上限吗？还是都是 50 行左右？）

All like 50 lines? There's no hard cap, but I do encourage my agents to split up their work into multiple PRs. I do that mostly because I like the way that Like, I like the idea of, I guess maybe this is much harder to do now as in the world of agents and you have like so many commits, but I like the idea that, you know, the Git history is a very rich source of context, and I like the, I like each PR to sort of atomically describe what that small piece of thing is doing, which also makes it easier for me to revert changes and like figure out, you know, oh, I shipped a bug and it's this, it's here.

没有硬性上限，但我会鼓励 agent 把工作拆成多个 PR。我这么做主要是因为我喜欢——虽然在 agent 时代这可能更难做到了，commit 实在太多——但我喜欢这个理念：Git 历史是非常丰富的上下文来源。我希望每个 PR 都能原子化地描述这一小块改动在做什么，这也让我更容易回滚，更容易定位：哦，我发了个 bug，就在这儿，

This 40,000 line PR, where who knows what landed in there. But I don't have a hard cap on PR size.

而不是藏在某个 4 万行的 PR 里，天知道里面合进去了什么。不过我对 PR 大小没有硬性上限。

Yeah, so well specifically for Grok Bot, so Dune is the sort of cheeky code name for the architecture that we've built for Grok Bot, the CI is pretty annoying because there's checks for everything so like literally I have, well, if you've written any React, for example, you know that one of the biggest foot guns in React is useEffect. So in Dune and in Grok Bot, we've banned useEffect. So Dune is just a, the mental model of what Dune is, you can kind of think of it as like Next.js for electron apps, and it's designed for agents to write. And it's like custom for, you know, our agent-forward applications.

好。具体说 Grok Bot 的话——Dune 是我们给 Grok Bot 搭的这套架构起的一个俏皮代号——CI 相当烦人，因为什么都要检查。比如，如果你写过 React，你就知道 React 里最大的“坑”（footgun）之一是 useEffect。所以在 Dune 和 Grok Bot 里，我们禁用了 useEffect。Dune 的心智模型是：你可以把它想象成“Electron 应用的 Next.js”，它是专门为 agent 来写而设计的，为我们这种以 agent 为核心的应用定制。

So the CI checks are very specific to that, like, you know, don't use useEffect. It's banned, like, CI will fail and yell at you. We have, like, some of the more interesting ones that people might raise eyebrows is like, I actually banned code comments as well, which is very interesting. But I've noticed that 99% of the time, agents just write code comments that kind of describes some historical thing that is actually totally irrelevant to the code.

所以 CI 检查非常有针对性，比如：不准用 useEffect，这是被禁的，CI 会直接失败并冲你“大喊”。还有一些可能会让人挑眉的规则，比如我把代码注释也禁了，这挺有意思的。因为我发现 99% 的情况下，agent 写的注释都在描述某段历史背景，而那跟代码本身完全无关。

Like it will often say like, oh, Lauren said you should never do this and it's now in a code comment. Like what, why, what, that was, I, I didn't say that as like a durable global rule. I just meant like your, this PR sucks and you should change that part. Agents don't really understand us that well, surprisingly, or they kind-of assume too much and they kind of do things in like very stupid ways. So like, yeah, we just ban everything.

比如它经常写：“Lauren 说过永远不要这样做”，然后这就进了代码注释。我心想：什么？为什么？我那句话可不是当作永久的全局规则说的，我只是说“这个 PR 很烂，你把那部分改掉”。agent 其实没那么懂我们，挺意外的；或者说它们揣测太多，然后用非常蠢的方式做事。所以，我们干脆全禁了。

Everything you can imagine like the agents are bad at, we ban. So one example that we actually suffer a lot in the agents window is we have, you know, if you use agents window, you've definitely seen performance issues and, you know, we're constantly trying to fix them. But it's like a, it's a never ending struggle because there's so many pull requests that get merged. Any one of them could just regress performance or stability or reliability. The agent window doesn't have this architecture yet.

凡是你能想到 agent 不擅长的，我们都禁了。举个我们在 Agents Window 里深受其害的例子：如果你用过 Agents Window，你肯定见过性能问题，我们一直在修，但这是一场永无止境的斗争，因为合进来的 pull request 太多了，任何一个都可能让性能、稳定性或可靠性退化。Agents Window 还没有用上这套架构，

I plan to do, bring this learning back there and kind of refactor everything there. But it just regresses super often because there's just one example is like we have, have very poor isolation between processes. So like on, you know, on Electron, you have a renderer thread that renders your UI. But you also have a main thread that you can run other code that doesn't need to block the renderer. But we do a poor job of separating those things.

我打算把这些经验带回去，在那边全部重构。但它退化得非常频繁，举一个例子：我们的进程隔离做得很差。在 Electron 里，有一个渲染线程负责渲染 UI，还有一个主线程，可以跑那些不需要阻塞渲染的代码。但我们没把这两者分好。

Oftentimes, you just accidentally have code that gets pulled into running on the renderer thread. And then all of a sudden, you're competing with the renderer that has. If you want 60 FPS, every frame that gets drawn has to be done in 16 milliseconds. So very, very small deadline per frame if you want a very smooth product. And when you start accidentally bringing in things that are very computationally heavy or they have a lot of IO, then you just get into a lot of jank.

经常会不小心把一些代码拉到渲染线程上跑，然后你就突然在和渲染争资源。如果你想要 60 FPS，每一帧都必须在 16 毫秒内画完——如果你想要非常流畅的产品，每帧的时限非常非常短。当你不小心引入了计算量很大、或者 IO 很多的东西，就会出现大量卡顿（jank），

And your FPS really drops, you start losing frames, you get long tasks that take more than 16 milliseconds and you just get this really choppy experience. So all of those patterns that we've learned basically building electron apps, we've encoded into this framework and it becomes like a hard failure. So I literally, in Grok Bot, we literally have a directory called electron main, electron renderer, and we have a import CI, I guess, where we actually check the dependency graph to make sure you're not accidentally importing code from one directory to another.

FPS 狂掉，开始丢帧，出现超过 16 毫秒的长任务（long task），体验就会变得非常卡。所以我们在做 Electron 应用时学到的所有这些模式，都编码进了这个框架里，变成了硬性失败。在 Grok Bot 里，我们真的有叫 electron-main 和 electron-renderer 的目录，还有一个 import 检查的 CI，会检查依赖图，确保你没有不小心从一个目录引入另一个目录的代码。

So that's enforced by CI. as well as Bugbot, which is Cursor's code review tool that runs on CI, in our AGENTS.md, it's everywhere. Like, so I have this thing here where I talk about like, you know, like there are multiple layers I think for building a good code base. Obviously the code base is one where, if you have an architecture like this, where it's extremely strict, you know, the way to build features is very conventional.

这由 CI 强制执行，同时还有 Bugbot——Cursor 的代码审查工具，在 CI 上运行——还有我们的 AGENTS.md，到处都有。我这里写了一个东西：我认为构建一个好的代码库有多个层次。首先当然是代码库本身：如果你的架构像这样极其严格，构建功能的方式非常约定俗成，

That's like the strongest, strongest level of enforcement because agents just love to copy existing patterns. So one example of this in Grok Bot is like, we have this, these concepts called like a feature and we have entry points and transcript cards. Like, you know, the cards that you see in the chat, these are all like, like nouns, I guess, in the framework. And so there's a very conventional way of creating them. And so like a feature is all in a single directory, as an example.

那就是最强的一层约束，因为 agent 特别喜欢照抄已有模式。Grok Bot 里的一个例子是：我们有一些概念，比如 feature（功能）、entry point（入口）和 transcript card（对话里的卡片）——就是你在聊天里看到的那些卡片——它们算是框架里的“名词”。创建它们有一套非常约定俗成的方式。比如一个 feature 全部放在一个目录里。

And so all of the code that contributes to that feature lives in one directory. So it's all co-located in one place. Makes it super easy. Agents don't have to like, grab around and try to figure out like, where all the things are. It just looks at the feature and like, oh, okay I'm working on the onboarding feature in Grok Bot. I'm just gonna work in this directory. And for 80% of the work, it's mostly just very encapsulated there.

所有为这个功能服务的代码都在同一个目录里，全部集中在一处，非常简单。agent 不用到处翻找东西在哪。它看一眼就知道：哦，我在做 Grok Bot 的 onboarding 功能，我就在这个目录里干活。80% 的工作基本都封装在那里面。

But it's like design, again, for the dumbest agent, you don't have to think, right? One of the key principles I have for this framework is the shortest path is the best path. So, because that plays exactly to how agents love to rank, they like to take shortcuts, really. You know, they'll define the quickest way to solve the problem. So why not make that the best way to solve the problem? So I probably won't get into all the specific details.

它的设计目标，再说一次，是让最笨的 agent 也不用动脑子，对吧？我给这个框架定的一个核心原则是：最短路径就是最佳路径。因为这正好契合 agent 的行事方式——它们就爱走捷径，会找最快的方法解决问题。那为什么不让最快的方法就是最好的方法呢？具体细节我大概就不展开了。

And this framework is really more of a collection of ideas and principles, rather than something that will open source. You can screenshot this, I guess, if you want, and tell your agent to do something like this for you too. Yeah, but it's really all about the layers, you know, like the code base is one part with features and directories and, you know, import or blocking import dependencies that shouldn't be imported. But and it all enforces that and static analysis.

这个框架更像是一套理念和原则的集合，而不是我们会开源的东西。你想的话可以截个图，让你的 agent 也给你做一个类似的。总之核心在于“分层”：代码库是一层，有 feature、有目录，有对不该被引入的依赖的阻断，所有这些都会被强制执行；然后是静态分析，

So like there's CI checks, we have a lot of lints for bad patterns that we observe compiler diagnostics. There's also rules in Bugbot which are, I think like 3, 4, 5 are more soft, right? These two actually make CI red, right? So that, you know, there's a hard constraint where the agent can't just write crappy code [ASR: "can"]. For rules and skills in Bugbot, your agents can still forget, right? You can still, or it may not always consistently apply them.

也就是 CI 检查——我们有大量针对已观察到的坏模式的 lint 规则——还有编译器诊断。再往下是 rules 和 Bugbot。我觉得第 3、4、5 层是偏“软”的，而前两层是真的能让 CI 变红的，对吧？这样就有了硬约束，agent 没法随便写烂代码【原话听起来像 “can”】。而对于 rules、skill 和 Bugbot，你的 agent 还是可能忘记，或者不总是一致地执行。

So I like them. I don't like to rely on them as the only source of enforcement because it's very, very soft. And if you only have rules, and Bugbot, and skills, and a style guide for your code, it's only a matter of time before your code base looks like, complete trash. Sorry to say that. But I definitely recommend investing in things that can be hard, enforced. And this is why maybe the choice of tech stack that you use is also very important.

所以我喜欢它们，但我不想把它们当作唯一的约束来源，因为它们非常软。如果你只有 rules、Bugbot、skill 和一份代码风格指南（style guide），那你的代码库变成一坨垃圾只是时间问题——抱歉这么说。我非常建议投入到那些可以被“硬性强制”的东西上。这也是为什么技术栈的选择也非常重要。

Like I think, for example, Rust is sort of making, is that getting super popular again? Because the compiler is so strict, right? The compiler enforces so many different things. There's a borrow checker that you have to appease. And as long as you make sure your agents don't write unsafe code blocks, you can more or less feel somewhat confident that if the code compiles, It probably works and it's good. But it gives you that level of trust and confidence that you, as a human engineer, no longer need to go and check it yourself.

比如我觉得 Rust 是不是又火起来了？因为它的编译器非常严格，强制了很多东西，你得满足借用检查器（borrow checker）。只要你确保 agent 不写 unsafe 代码块，你就能多多少少比较有把握：代码能编译通过，大概率就能跑而且还不错。它给你那种信任和信心，让你作为人类工程师不再需要亲自去检查。

You know, you rely on code and static analysis to actually make that a lot smoother. And I guess the worst part, the worst place to be in is if you are stuck in code review land where you actually enforce all of the constraints, the invariance in your code base by literally the human person saying, reading the code and saying, OK, you should not do this. Every time you have to do that, you should consider that as a code smell, like an anti-pattern.

你依靠代码和静态分析让这一切顺畅很多。我觉得最糟糕的处境是你被困在“代码审查地狱”里：代码库里所有的约束、所有的不变量（invariants），全靠人去读代码然后说“你不该这样做”来维持。每次你不得不这样做的时候，你都应该把它当成一种代码异味（code smell），一种反模式。

And you should say, OK, instead of me commenting on the PR, how do I turn this into a lint rule? How do I turn this into a CI failure? Or how do I even categorically eliminate this problem entirely. I can talk about another migration I've done, but I'll probably pause here.

你应该想：与其我在 PR 上留言，我怎么把它变成一条 lint 规则？怎么把它变成一个 CI 失败？甚至怎么从根本上彻底消灭这一类问题？我还可以讲讲我做过的另一次迁移，不过先在这儿停一下吧。

I've been yapping for quite a lot, so maybe let's just do questions.

我已经讲了很久了，不如直接答问题吧。

I think that's a really good point. I mean, like obviously, you know, I work at an AI lab where we have unlimited tokens. So I definitely cannot say that, you know, this is something everyone should do in the exact same way that I did it. I think it's possible to get to this point without, you know, breaking the bank. you know if you're like an engineering leader or, you know, you have a startup that you lead, I think to me it's a question of ROI, and it's like, yes, you spend a lot of money on tokens in the upfront stage, you know, like refactoring your code base is going to take a lot of tokens, adding all these things is going to take a bunch of tokens. But if we're heading to a world where agents are writing all the code and you know you want to be very lean right you don't

这是个很好的问题。显然，我在一家 AI 实验室工作，我们有无限的 token。所以我绝对不能说每个人都应该完全照我的方式来做。但我觉得不砸锅卖铁也能走到这一步。如果你是工程负责人，或者在带一家创业公司，我觉得这本质上是 ROI（投入产出比）的问题。是的，前期你要在 token 上花很多钱：重构代码库要花很多 token，加上所有这些东西也要花一大笔 token。但如果我们正走向一个由 agent 写所有代码的世界，你希望保持非常精简，

Want to have to hire you don't want to be you don't want to become like meta right I mean like in terms of you want to become a 10,000 person engineering org because I mean that's a cool problem to have but also you know you have so much overhead there's like planning you know like it's personally I wouldn't it is not super fun but I think you want to stay very nimble right and you want to be like agents are all about allowing you to do things that you couldn't do before that's really to me like the value of agents you know it's not just [unclear: "storing"] tokens on every single little thing but the thing I couldn't do before is like enforce this level of constraints in a code base by myself right like I'm just a single person

你不想不停招人，不想变成 Meta 那样——我是说，你不想变成一个一万人的工程组织。那当然是个“甜蜜的烦恼”，但同时也有大量的管理开销，各种规划……就我个人而言，那并不怎么好玩。我觉得你会想保持灵活。agent 的意义在于让你做到以前做不到的事，这才是我眼中 agent 的价值——不是在每件小事上【听不清】token，而是：我以前做不到的，是靠我一个人在代码库里推行这种级别的约束。我只是一个人，

You know uh it would have taken me years to build this framework uh and do all the refactoring and test everything myself and verify you know like run imagine if there it was just me right now in pre-agent era just like running you know by the way it would take me so long right and my salary is pretty high right like so you know the question I think an engineering leader might have is just then the tradeoff of do you hire someone to do this or do you spend the tokens to set up a codebase so that even the most naïve, the dumbest agents can do a good job and when you actually get to this point, even agents that are not [unclear: "fable-sized"] do an excellent job of writing code and this pays a lot of dividends as well for me personally

要我自己搭这个框架、做完所有重构、测试所有东西、验证一切，可能要花好几年。想象一下在没有 agent 的时代，就我一个人去跑这些，得花多久？而我的薪水又相当高。所以工程负责人可能会面对这样的权衡：你是招个人来做这件事，还是花 token 把代码库搭好，让最天真、最笨的 agent 也能做好工作？而当你真的走到这一步，即使不是【听不清，疑似“前沿大模型级别”】的 agent，也能把代码写得非常好。这对我个人也带来了很大的回报：

Where I have empowered not just myself, but again, like, PMs, designers, engineers who are not familiar with Grok Bot to just contribute in a way that is sustainable. So I think, yeah, it's definitely like a trade-off for sure. You know, like nothing is like free for sure. And tokens are pretty expensive. But oh, actually, I don't know how many of you have seen this, but we actually announced Grok 4.6 today. So very exciting. finally out so yeah Grok 4.6 — it's very smart it's really good on the on the benchmarks and it's the same the tokens well I hopefully I'm not saying this incorrectly but I believe the cost per token is the same as 4.5 so you're actually getting more intelligence for the same cost I think this is an area that Cursor tries to Cursor and SpaceX AI try to

我赋能的不只是我自己，还有产品经理、设计师，以及不熟悉 Grok Bot 的工程师，让他们能以可持续的方式做贡献。所以，这确实是个权衡，天下没有免费的午餐，token 也挺贵的。哦对了，不知道你们有多少人看到了，我们今天刚发布了 Grok 4.6，非常激动人心，终于出来了。Grok 4.6 非常聪明，在基准测试上表现很好。而且——希望我没说错——我记得它每个 token 的价格和 4.5 一样，所以你是用同样的成本拿到了更多智能。我觉得这正是 Cursor 和 SpaceX AI 努力

Really optimized for like that Pareto frontier of you know, cost versus intelligence, you know, we don't necessarily want to build the biggest model ever because that is extremely expensive to run. It's really about like, how do you find that sweet spot, right? You don't need a giant model, but it's just super smart, right. And it's not very expensive for inference. But yeah, I think to kind of round it up. I think it's like a it's it's there's a if you do your own analysis, I feel like it's pretty positive, it'll be pretty positive. The ROI you get from investing in stuff like this just empowers not just yourself, but your whole team to be so much more productive, right? Like imagine if you have an army of engineers like me who are shipping so much improvements and bug fixes, you know, every day, right? Like that is pretty exciting.

优化的方向：成本与智能之间的帕累托前沿（Pareto frontier）。我们不一定要造史上最大的模型，因为那运行起来极其昂贵。关键在于找到那个甜蜜点：不需要一个巨型模型，但它非常聪明，推理成本也不高。总结一下：如果你自己算一算，我觉得结果会是相当正面的。投资这类东西带来的 ROI，不只是让你自己，而是让你整个团队都大幅提升生产力。想象一下，你有一支像我这样的工程师大军，每天都在交付大量改进和 bug 修复，那是多么令人兴奋。

I think this is where Grok Bot has been actually exceedingly powerful, where, so before Grok Bot, like, you know, obviously Cursor only had Cursor, like we only had agents window, we had a CLI, we had an IDE. And these are really like power user tools, right, they're designed for developers. So it's very, very developer centric. You can do a knowledge work in them, but the UI is not really optimized for that. So we actually didn't really have, well, I think a lot of people in GTM product, like they might have used Cursor to do their work, but it definitely wasn't like a delightful experience with them. I think now with Grok Bot, it's become, Grok Bot is basically like their Cursor moment for people who are not in tech, in my opinion. It's like a very, very accessible way to use agents

我觉得这正是 Grok Bot 发挥巨大作用的地方。在 Grok Bot 之前，Cursor 只有 Cursor 本身：Agents Window、CLI、IDE。这些都是面向高级用户的工具，是为开发者设计的，非常以开发者为中心。你也可以在里面做知识型工作，但 UI 并没有为此优化。所以我们其实没有……我觉得很多 GTM、产品的同事，可能也用过 Cursor 做事，但体验绝对谈不上愉快。现在有了 Grok Bot，在我看来，Grok Bot 基本上就是非技术人群的“Cursor 时刻”。它是一种非常非常易用的使用 agent 的方式，

In a very comfortable, very familiar interface. It looks like iMessage and it's very fun too. You can give your agent a fun name. You can do orchestration in a very natural way where you can sort of, you know, each agent is like a person and now you have a team of agents working on You have one agent per account that you manage, as an example. Or if you're a PM, you can have an agent that summarizes all the work that Lauren did last night.

界面非常舒服、非常熟悉，长得像 iMessage，而且很好玩，你可以给你的 agent 起个有趣的名字。你可以非常自然地做编排：每个 agent 就像一个人，你现在有一支 agent 团队在干活。比如你管理的每个客户账户配一个 agent；或者如果你是产品经理，可以让一个 agent 总结 Lauren 昨晚干的所有活，

And then now you know what I did, right? So I think our PMs are leveraging that a lot and they're shipping code too. So oftentimes, they will just say, oh, here's a bug. I fix it. Can you look at it? And then I'll go review it and actually it's just perfect. I'm like, OK, stamp. So I think that shows that the Dune architecture is holding up, right? the really strict constraints allow people who are not experts in engineering to contribute at a high level. I feel like I've already seen that pay off a lot.

然后你就知道我做了什么，对吧？所以我觉得我们的产品经理大量在用它，而且他们也在提交代码。他们经常会说：“这有个 bug，我修了，你能看看吗？”然后我去 review，发现完全没问题，我就说：好，批准（stamp）。我觉得这说明 Dune 架构经受住了考验：非常严格的约束，让不是工程专家的人也能以很高的水准做贡献。我觉得这已经带来了很大的回报。

Designers and PMs are able to ship features directly. That makes the Grok Bot team super fast. We can ship that we can ship so quickly. And we have a lot planned, so I'm very excited to ship more stuff.

设计师和产品经理能直接交付功能，这让 Grok Bot 团队快得飞起，我们能交付得如此之快。我们还有很多计划，我非常期待交付更多东西。

Thanks for having me. And if you have any more questions, just DM me on Twitter. I'll open them up, I guess. I'll let the-

谢谢邀请。如果大家还有问题，直接在 Twitter 上私信我。我会打开私信吧，我让……

Yeah, I'll open the updates. So yeah, DM me, maybe I'll do like a Twitter space at some point, that's all for more questions, but really appreciate everyone for showing up, taking an hour out of your day. Yeah, all right. Thanks all. I'll see you the next one. Okay, thanks everyone. Bye.

是啊，我会打开的。所以私信我吧，也许我哪天会开个 Twitter Space 来回答更多问题。非常感谢大家来参加，从一天里抽出一个小时。好，谢谢大家，下次见。好，谢谢各位，拜拜。