从 Chrome DevTools 到 AI 工程，与 Addy Osmani

这会让内存问题的调试变得更加困难。

And that makes it even harder to debug memory problems.

所以这些年来，内存调试的最新技术并没有太大的进步。

And so the state of the art around memory debugging hasn't evolved all that much over the years.

这是一个难题。

It's a hard problem.

DevTools 团队解决了很多有趣且困难的问题。

The DevTools team tackled a lot of interesting hard problems.

我们能不能谈谈你带来的一些新东西？

Can can we talk about a part that...

你带来了一些新的东西。

Where you brought in something new?

因为，你知道，以前调试内存问题，基本上就是……

Because, you know, debugging memory, just back in the day, it's pretty much...

我的意思是，如果你有一种语言，比如说有堆，你可以尝试可视化堆里有什么。

I mean, if you have a language that has, let's say, heap, you can try to visualize what's on there.

你可以尝试，也许能成功分配出哪些变量在那里。

You can attempt and maybe be successful at allocating which variables there are.

然后你也可以试着...

And then you can try to also...

我的意思是，有些变量是容易的部分。

I mean, some of variables are are the easy part.

还有栈。

There's also stacks.

而且，你知道，这会变得有点乱，但你基本上有内存，而且你通常关心的是什么在增长。

And, you know, it gets a little bit messy, but you you you basically have a memory, and and you're typically interested in what is growing.

还有一部分，我不确定我们在这方面进展了多少，但你有点想看看，是不是...

And there's a part that I I don't I don't I don't know that we got too far on that, but you're kind of trying to see, is it...

这是不是变大了？

Is this getting bigger?

循环是什么？

What are the loops?

在哪里

Where is

我的栈？

my stack?

当然。

Absolutely.

我觉得有几个有趣的阶段，我们看到自己和外部开发者遇到某些摩擦，然后和 DevTools 团队合作，尝试朝那个方向改进工具。

I would say that there are a few interesting arcs where we were seeing, you know, ourselves and developers externally running into certain kinds of friction and, you know, work with the DevTools team to try evolving some tooling in that direction.

其中一个重要的阶段是接受开发者越来越多地使用框架和库来构建网页这个事实。

One of the the big arcs was embracing the fact that developers were increasingly using frameworks and libraries to build for the web.

是的。

Yep.

现在，对于记得那些黑暗时代的人来说，想象一下你有一个非常交互式的页面，用了很多不同的库，你正在尝试调试发生了什么。

Now, for anyone that remembers those dark ages, imagine that you have a page that's very interactive, it's using lots of different libraries, and you're trying to debug what's happened.

你真正关心的是那段代码的哪一部分？

What part of that code do you actually care about?

你关心的是那些在幕后驱动一切的框架代码吗？

Do you care about the framework code that is powering things behind the scenes?

你关心的是那些你还没写的插件或组件吗？

Do you care about the plugins or the components sitting on top of it that you haven't written?

你关心的是你自己写的代码吗？

Do you care about the code you yourself have written?

所以，所有这些微妙的调试方面都需要一个解决方案。

And so you have all of these very nuanced aspects of debugging that need a solution.

我们试图引入的一件事就是尊重和理解，是的，开发者会使用这些不同的技术栈。

One of the things that we we tried to introduce was respect and understanding that, yeah, developers are gonna be using these different tech stacks.

你知道，我们有一个源映射的故事摆在那里。

You know, we had a source maps story sitting there

在那里，我们可能开始推理什么

Where potentially we can start to reason about what's

在映射回代码的哪一部分时，没错。

in You you map back to, like, what part of the code Exactly.

这可不是件简单的事。

Which is not trivial.

没错。

Exactly.

这确实不简单。

Which is not trivial.

而且我要大大表扬一下团队，因为我觉得我们最终搞定的那个源码映射方案，真的能帮你很好地理清思路，哪怕你用的是一长串工具链。

And a lot of kudos to the team because I think we ended up on a source map story that really helps you reason well about, you know, even if you were using a long tool chain of things.

比如说，你随便看看开发者用的那些工具……

Like, if you take a look at any tools that developers...

对于任何大型网站，不管是优步、奈飞，还是推特这种大平台，你很可能低估了同时运行的工具数量和复杂度，就为了完成一个任务。

For any big site, you know, whether it's Uber or Netflix or any large Twitter, any large site, you probably underestimate the complexity and the number of tools that you're running at any one time for any one task.

还能让用户看到，嘿，这些才是你真正关心的文件。

Being able to still allow people to see, well, hey, here's actually the files that you care about.

这真是个难题。

It's a hard problem.

我觉得让用户能看到那个视图，是我们带来的价值之一。

I think that allowing people to get that view was part of the value that we brought.

这些年来我们引入了各种黑盒视图，这样你就可以说，嘿，其实我不在乎你告诉我，比如，React 库有问题。

We introduced different kinds of black box views over the years so that you could say, well, hey, actually, I know that I don't care about you telling me there's an issue with, for example, the React library.

但我确实想让你告诉我，我写的 React 代码有问题。

But I do want you to tell me that there's an issue with the React code that I wrote.

所以，给你这些开关和控制，我觉得对用户来说非常有用。

And so giving you even those toggles, those controls, I think was very powerful for people.

移动端是另一个改变一切的转折点。

Mobile was another big moment that changed everything.

如果你想想移动端，今天，我觉得可能已经有了关于测试什么的成熟的最佳实践。

If you think about mobile, today, I would say there's probably established best practices around the things to test.

你想测试你的视口宽度、点击目标，我是不是点得够大。

You wanna test out your viewport width, your tap targets, if I'm It's tapping big on something enough.

没错，

Exactly,

在大屏幕上呢？

it it on big screen?

对，移动设备甚至还有各种不同的传感器。

Exactly, there are all these different kinds of sensors even that mobile devices have.

我们最初并没有针对这些东西的工具，所以最终我们在开发者工具里建立了一个不错的设备模式，让你可以预览你的网站在不同视口尺寸下的样子。

We didn't we didn't have tooling around any of this stuff originally, and so we ended up building out a nice device mode in DevTools that would allow you to preview what your site would look like at different viewport sizes.

你可以很快地切换，然后说，对，这大概就是它在iPhone或Pixel设备上的样子。

You can very quickly toggle and say, yeah, this is what it roughly looks like on an iPhone or a Pixel device.

当然，最好的测试方式当然是在那些真实的设备上试一试，但即使只是快速了解你是否走对了方向，对人们来说也是非常有价值的。

And, of course, the absolute best kind of testing would be trying it out on one of those app, those accurate devices, but even to quickly get a sense of whether you're heading in the right direction was very valuable to people.

随着更多的最佳实践开始确立，我们会随着时间的推移不断改进这一点。

We would evolve that over time as more of those best practices started to establish.

我想，随着Web应用逐渐成熟，比如PWA（渐进式Web应用），有一段时间人们真的想让Web与原生应用竞争。

I guess the web apps growing up, so PWAs, Progressive Web Apps, there was a period of time when people really wanted to make the web competitive compared to native.

所以你会想，还缺什么呢？

And so you think about, well, what are the things that are missing?

嗯，你需要一个很好的方案来处理离线缓存、推送通知、后台同步，这些我们之前都没有特别好的解决方案。

Well, you need a really good story for offline caching, push notifications, background sync, all of these capabilities that we didn't necessarily have a strong story for.

而且因为这些功能都不简单，你需要为它们都提供调试方案。

And because these are nontrivial features, you need to have a debugging story around all of them.

所以我们帮助构建了应用程序面板，这样你可以进去，对于这些功能中的任何一个，无论是调试 Service Worker、调试缓存还是调试其他任何东西，你都能做到。

And so we help build out the application panel so that you can go in, and for any of these features, whether it's debugging service workers or it's debugging your cache or debugging any of these things, you're able to do that.

所以尽管工具集随着每个时代的发展而扩展，我觉得 DevTools 一直都能跟上，尤其是浏览器中的 API 也在不断演变以应对这些时刻。

And so even though the toolset has expanded over time for each of these eras, I feel like DevTools has been able to keep up, especially as the APIs in the browser has also been evolving over time to meet these moments.

嗯，这很有趣，因为我通常……

Well, that's interesting because I I usually...

当我观察不同公司及其优势时，微软在构建 IDE 方面很出色，JetBrains 也是如此。

When I look through different companies and their strengths, Microsoft is amazing at building IDEs and so is, for example, JetBrains.

但对谷歌来说，我从来不觉得谷歌擅长构建 IDE，除了在 Chrome 内部。

But for Google, I never felt that Google was any good at building IDEs except for inside of Chrome.

比如，每当我需要调试一个 Web 应用时，我总是……

Like, whenever I I have to debug a web application, I always...

我……

I...

过去这么多年，我一直用 Chrome DevTools，因为它有……

The past, like, many many years, I used Chrome DevTools because it it had...

我的意思是，那种我习惯在 Visual Studio 里用的调试功能，比如断点、条件断点，还有各种调试选项，就像你……

I mean, the kind of debug functionality I'm used to having Visual Studio have, which is breakpoints, conditional breakpoints, all sorts of so many debug options from as you as you...

我们刚才提到的性能、内存，还有模拟这些场景的能力。

We just said performance, memory, being able to simulate some of those things.

所以对我来说，看到这些真的很有意思。

So it's very interesting to for me to see that.

感觉就像……

It's almost as if...

我不确定这是你、你的团队，还是整个 Google 的决定，但他们意识到了浏览器非常重要。

I'm not sure if this was you, your team, or Google as a whole, but they realized the browser is very important.

所以他们几乎像是建了一个……

And so so they built, like, almost like an...

这几乎就像里面内置了一个IDE。

It's almost like an IDE inside of it.

你可以直接在里面编辑内容。

You can you can edit the things in line.

我觉得作为工程师或开发者，除非你做前端，否则你很难注意到这一点，但一旦你注意到了，就会觉得它怎么整合得这么神奇。

And I think as engineers or as developers, unless you work in front end, you never really notice this, but when you do, it's fascinating how how how it came together.

确实很神奇。

It's really fascinating.

而且我觉得，我们是不是一个IDE，要不要往IDE方向发展，一直是团队里热议的话题。

And I think that are we in IDE, aren't we in IDE, is that a direction we wanna go in, was always a hot topic for the team.

我觉得最终的共识是，我们想贴近开发者，因为你总会有自己偏爱的编辑器。

And I think that where things kind of landed was, well, we wanna meet developers where they're at because you're always gonna have your favorite editor.

现在我们说的是你代理的控制平面。

Now we're talking about your control planes for your agents.

你总会有不同的界面，对吧，你主要想在那里工作。

You're always gonna have a different surface, right, that you wanna primarily work in.

而且只要开发者工具能在你所在的地方发挥作用，并且有用，我觉得那……

And as long as DevTools can meet you where you're at and be useful, I think that that...

这一直是团队努力在做的事情。

That's been something the team has tried to do.

我们继续经历了其他阶段。

We continued having other eras.

严高在帕维尔之后成为了我们的下一位技术负责人，并带领我们度过了试图弄清楚AI已经出现的时代，我们既要能够帮助人类理解浏览器为你生成的海量数据，也要让你能够将你的代理连接到Chrome和开发者工具，让它自动为你完成许多这样的流程。

Yan Gao became our next tech lead after Pavel and helped us through the era of trying to figure out AI is now in the picture, and we wanna both be able to help humans reason through this massive amount of data that the browser generates for you, as well as make it possible for you to connect your agent up to Chrome and DevTools and be able to have it just automate a lot of these journeys for you.

所以，我认为对于第一个问题，我记得每次和大型网站合作解决性能问题时，你很容易花上半天时间查看跟踪记录，甚至还没开始写任何修复。

And so, I think that for the first of those problems, I remember anytime I would work with a big site on their performance problems, you could easily spend half a day just looking at traces, before you've even written any fixes at all.

现在有了大语言模型，就能很快地推理海量的堆栈跟踪，真正找到可以做的修复。

And now that we have LLMs, it's very quick to, like, reason through massive stack traces and actually be able to get down to fixes you can make.

看到这一切真的非常非常棒。

And that's just been really, really wonderful to see happen.

Addy刚刚描述了用大语言模型从巨大的问题到实际修复的过程，这正好是谈论我们经验丰富的赞助商Sentry的完美时机。

Addy just described using LMs to go from massive tax issues to working fixes, which is the perfect moment to talk about our seasoned sponsor Sentry.

你大概已经知道Sentry是什么了，因为你是个开发者。

You probably already know what Sentry is because you're a developer.

如果你不知道，随便找个开发者问问，他们就会告诉你。

If not, just ask a dev and they'll tell you.

我用Sentry来监控pragmatic engineer的后端，捕捉所有错误。

I use Sentry to monitor the back end of the pragmatic engineer for any and all errors.

当然，Sentry不只是处理错误。

Of course, Sentry doesn't only do errors.

他们还有日志、回放、追踪片段、性能分析、指标等等，因为这些都是通过同一个追踪ID关联起来的。

They also have logs, replays, spans, profiles, metrics, and more because they're all connected by the same trace.

Sentry最近新增的一个我很喜欢的功能是修复错误的能力。

One new capability Sentry has built that I'm really liking is the ability to fix errors.

让我给你演示一下。

Let me show you.

这是我管理后台的错误列表。

Here's the list of errors on my admin back end.

认证那边最近有个错误，我想看看。

There's a recent error on auth that I wanna check out.

让SEER帮我们自动修复一下。

Let's have SEER run an auto fix for us.

SEER是Sentry的AI调试工具。

SEER is Sentry's AI debugging tool.

首先，它会生成一个根本原因分析。

First, it generates a root cause analysis.

它发现HTTP和HTTPS的URL之间有问题。

It's finding some problem with HTTP versus HTTPS URLs.

不错。

Cool.

现在我们知道哪里出错了，SEER可以制定一个修复计划。

Now that we know what's going wrong, seer can create a plan on how to go about fixing it.

我可以去修改这个计划，但我对它很满意。

I could go and edit this plan, but I'm happy with it.

那我们就来生成一个实际的代码修复吧。

So let's create an actual code fix.

这是SEER生成的代码修复。

Here's a code fix that seer generated.

假设看起来没问题，对我来说也确实没问题，那我们就来起草这个拉取请求。

Assuming it looks good, and in my case it does, let's draft the pull request.

然后，啪的一下，拉取请求就创建好了，可以直接合并了。

And boom, the pull request is created, ready to merge.

我喜欢Autofix的一点是，Sentry从仅仅显示我应用里的错误列表，变成了给我一个快速修复并闭环的途径，而且整个过程中我始终掌控着这个bug修复。

What I love about Autofix is how Sentry went from showing a list of errors inside my application to offering me a fast way to fix it and close the loop while I stay in charge of this bug fix the whole time.

调试变得更快、更简单了。

Debugging just got a whole lot faster and a whole lot easier.

去sentry.io/pragmatic看看Sentry吧，今天就开始检测错误、诊断根本原因、修复问题和回归。

Check out Sentry at sentry.io/pragmatic and start detecting errors, diagnosing the root causes, and fixing issues and regressions today.

Addy提到了我们使用LLM时会发生的一些变化。

Addy mentioned things that change when we work with LLMs.

有一点是肯定的，如果你和智能体一起工作，你的工作就不再是写代码，而是指定和测试代码。

One thing is for sure, if you work with agents, your job is no longer writing code, it's specifying and testing it.

这就把我们带到了我们的赞助商，Antithesis。

And this leads us to our presenting sponsor, Antithesis.

Antithesis 是当今验证智能体代码最有效的方法。

Antithesis is the most effective method of verifying agentic code today.

让我解释一下它是如何工作的。

Let me explain how it works.

Antithesis 在一个对抗性的模拟环境中运行你的整个系统。

Antithesis runs your whole system in a hostile simulation.

通过这样做，它能在用户之前发现每一个错误。

By doing so, it finds every bug before users do.

而且因为模拟是完全确定性的，Antithesis 不仅能发现错误，还能完美复现每一个问题。

And because the simulation is fully deterministic, Antithesis doesn't only find bugs, it gives you a perfect reproduction of every issue.

为了创建这样的工具，Antithesis 团队还需要发明新的调试工具。

To create such a tool, the Antithesis team needed to invent new kinds of debugging tools as well.

比如，这里有一个所谓的bug概率图。

For example, here is what's called a bug probability graph.

横轴是虚拟时间，纵轴是概率。

The x axis is virtual time and the y axis is probability.

当Antithesis运行宿主单元模拟时，它会标出bug概率增加的时间段，这对找出bug的根本原因非常有帮助。

As Antithesis runs the host cell simulations it plots timeframes when the bug probability increases which greatly helps with finding the root cause of bugs.

而且Antithesis还有一个日志可视化工具。

And Antithesis also has a log visualizer.

向下的竖线代表从同一状态分叉出的事件，紫色点就是bug发生的地方。

Vertical lines going down represent events branching off from the same state, and the purple dots are where the bug happens.

Antithesis是发布由代理编写的代码时最好的选择。

Antithesis is as good as it gets being able to ship agent written code.

Jane Street、fly.io和etcd社区等团队都在使用它，以便满怀信心地发布。

It's what teams at Jane Street, fly.io, and the etcd community use to ship with full confidence.

请访问antithesis.com/pragmatic了解更多信息。

Head to antithesis.com/pragmatic to learn more.

那么，有了这个，我们回到Addy那里，聊聊Core Web Vitals。

And with this, let's get back to Addy and talk about Core Web Vitals.

你真正推动的一个领域……

And one area that you really pushed...

你和团队一起推动整个行业前进的，就是Core Web Vitals。

You and the team pushed the industry together is Core Web Vitals.

你知道，这些是一套标准化的指标，用来衡量网页的真实用户体验。

You know, these are a standardized set of metrics to just figure out the real world experience to web pages.

还有一些……

And some of the...

你知道，在这之前，你可能会……

You know, before this, again, you would...

作为开发者，你会去测量，比如，渲染有多快，或者下载有多快。

As a developer, you would measure, like, alright, how quick does it render or how quick does it download.

那都是些很简单的东西。

It was very simple stuff.

但你引入了像LCP、最大内容绘制、CLS、累积布局偏移、FIE首次输入延迟，然后我还……

But you introduced things like LCP, largest Contentful Paint, CLS, cumulative layout shift, FIE first input delay, and then I n...

INP，即交互到下一次绘制。

IMP interaction to next paint.

就像，你在场一样。

Like, you were there.

比如，团队是怎么想出这些的？

Like, how did the team come up with these things?

它们……

They're...

如果你不是网络工程师，还是会有……

If you're not a web engineer, there's still...

理解它们需要一点时间，但它确实能解释用户的感受。

It takes a little time to understand them, but but it does actually explain, like, how users feel.

我觉得你们在谷歌内部不知怎么就把那种感受和数字联系起来了。

Like, I feel you somehow inside of Google managed to connect the kind of feel to a number.

我觉得Chrome团队一直都很重视用户体验研究。

I think that the Chrome team has always had an appreciation for user experience research.

而且，每当网络出现新情况时，我们都会重新参考那些研究，来了解用户的期望是什么，以及我们如何帮助满足这些期望。

And, again, every time there was new moment for the web, would reconsult that research to understand, well, what are users' expectations and how can we help meet them?

我们过去思考性能的方式，很大程度上就是，嘿，页面加载了吗？

The way that we used to reason about performance was very much like, hey, is a page loading?

那到底是什么意思？

And what does that even mean?

对很多人来说，就是页面准备好了吗？

Well, for many people, is the page ready?

但“准备好了”又是什么意思？

But what does ready mean?

是指我能看到它吗？

Does that mean that I see it?

还是指我能点击它，而且真的有反应？

Does it mean that I can click around it and anything actually happens?

所以我觉得在很长一段时间里，我们对页面加载时间的思考方式几乎是模糊不清的。团队觉得是时候对性能的考量方式提出一个更细致的视角了。

And so I think for a very long time, we had this this almost nebulous way of thinking about page load times, And the team felt like it was finally time to come up with a more nuanced perspective around how we reason about performance.

所以如果你把它拆开来看，用户旅程中有几个他们关心的关键节点。

And so if you break it down, there are a number of key moments across the user's journey that they care about.

开始了吗？

Is it happening?

有没有东西在加载？

Is anything loading?

你看到页眉了吗？

Do you see a header?

你看到加载图标了吗？

Do you see a spinner?

你看到任何东西了吗？

Do you see anything at all?

那里有没有对你有用的内容？

Is there something useful there for you?

所以可能那是一个头部图片。

So maybe that's a header image.

可能是一个主图。

Maybe it's a hero image.

可能是一个主视频。

Maybe it is a hero video.

可能那是页面上的核心内容。

Maybe it's the core piece of content on the page.

它有用吗？

Is it useful?

它好用吗？

Is it usable?

那里……

There...

所有这些不同的时刻都可以与这些不同的指标相关联。

And all of these different moments can correlate to these different metrics.

所以对于像你的主图这样的东西，你可以把它看作是最大的内容绘制。

So for things like your hero image, you can think about that as your largest contentful paint.

但这并不是每个页面都通用的。

And that's not gonna generalize across every page.

在某些情况下，图片可能不是最重要的。

In some cases, the image may not be the most important thing.

可能是文章的文字。

It might be the article text.

有些情况下，你可能希望页面能很快地进行交互。

There may be cases where you wanna be able to interact fairly quickly with a page.

我记得多年来有很多次，我在购物时，不管是在手机上还是在电脑上，点击“加入购物车”按钮，结果却毫无反应。

I can remember many times over the years when I might be shopping and whether it's on my phone or on my desktop, I will click the add to cart button and does crickets.

什么都不会发生。

Nothing will happen.

因为JavaScript没有加载，或者事件处理...

Because JavaScript did not load or the event hand...

或者，或者……

Or or the...

或者，也许是因为不是所有元素都加载完了，所以事件处理器没有绑定上。

Or maybe the event handler was not attached because not all elements finished loading.

我们作为工程师知道发生了什么，但作为用户，感觉就是……

We know as engineers what's happening, but as a user, it's like

作为用户，等等。

As a user, wait.

这……这是怎么回事？

What's what's happening?

有时候可能会发生这种情况，你就是一直点、点、点。

Stuff can happen where you you just tap, tap, tap.

然后事件处理器绑定了，结果你点了两三次，但你根本不知道。

The event handler gets attached, now you're adding it, like, twice or three times, but you don't know.

其实简单得惊人。

Are are shockingly simple.

你知道吗？

You know?

如果你想想一个人想过马路时的体验，如果灯不变绿，或者没有及时提示可以走，他们就会一直按那个按钮。

If you think about the experience you have with somebody that's just trying to cross the street, if the light doesn't turn, doesn't say they can walk fast enough, they'll just keep hitting that button.

他们在网上的体验也是一样的。

That's the same experience they have on the internet.

我觉得还有其他方面的用户体验，我们其实也承认是有问题的。

I think that there were other aspects of user experience that I think we acknowledged were actually problematic.

一个很大的问题是，这些年来，网站显然想尽办法尽可能多地变现，所以你不仅会看到横幅广告，还会看到弹窗，所有这些都直接甩在你脸上。而且就算你暂且不说商业变现的合理性，这些也不应该导致很糟糕的体验。

One big one was, over the years, obviously sites tried to monetize as heavily as they could, and so you would see not just banner ads, you'd see modals, you'd see all of these things thrown up in front of your face, And even if you set aside maybe there's some validity around a business needs to monetize, those things shouldn't cause a really bad experience.

如果我在一个有很多广告的页面上，我不应该刚开始读一篇文章，然后突然所有内容都被挤下去，对吧，就因为广告终于加载完了。

If I'm on a page that has a bunch of ads, I shouldn't start reading an article and then suddenly everything gets pushed down, right, just because the ad is finally loaded.

所以，累积布局偏移这个概念就是由此而来的。

And so that's where cumulative layout shift kind of comes from.

这个想法就是，嘿，我们应该尽量保持页面稳定，这样用户才能有好的体验。

It's this idea that, hey, we should be trying to keep that page stable so that the user has a good time.

我们反复推敲，试图用一种能涵盖多种细微差异场景的方式来定义这些指标，因为互联网其实并不那么单一。

There was a lot of iteration around how do we define these metrics in a way that captures a few of these different use cases that are very nuanced because the Internet is not all that homogenous.

不同的人对页面价值的看法以及看重的方面，往往大不相同。

There are lots of different ways that a person can think about the value of a page and what's important.

所以团队做了大量实验，尝试了各种思考这些指标的维度，并与标准社区和开发者紧密合作进行验证，看看大家是否真的认为这些指标能反映你们对自己页面价值的认知。

And so the team did a lot of experiments, experimented with lots of different ways of thinking about these metrics, and worked very heavily with both the standards community and developers to validate, hey, do you actually believe that these things line up with how you would say, you think about the value of your pages?

我一直觉得很有意思的是，有些公司从底层设计开始就考虑到了这一点。

One of the things that I always find fascinating is there are some companies where they have thought from the ground up.

比如，用户打开页面时面对的是一个空白屏幕，对他们来说，从头到尾真正重要的东西到底是什么？

Like, you start from a blank white screen, what is actually important to the user end to end?

然后还有很多公司，不管是因为时间不够还是压根没想过这个问题，都没经历过这种用户体验的梳理过程。

And then there are many companies where they haven't, for whatever reason, time or they just didn't think about it, they haven't gone through that journey.

所以 Core Web Vitals 的出现，让他们终于能展开更细致的讨论，比如：对我们来说，真正重要的是什么？

And so Core Web Vitals allowed them to finally get a more nuanced conversation going about, like, hey, what's actually important to us?

我们怎么确保用户在执行关键操作时能快速完成，并且保证他们不会遇到糟糕的体验？

How can we make sure that whatever key action the user has to take, they can do it pretty quickly and be guaranteed that they're not gonna have a bad time.

你在谷歌待了十四年。

Now you spent fourteen years inside of Google.

你……

You...

大部分时间都在Chrome团队。

Most of it was inside a Chrome organization.

后来你转到了云AI，也接触了通用AI。

Later, you moved over to to Cloud AI and work work with general AI as well.

我们之前研究过谷歌的工程文化，但你能概括一下在那里工作的感受吗？特别是……

We've done research before on Google's engineering culture, but can you can you summarize, like, what it felt working there in terms of what...

尤其是和你之前工作的初创公司相比。

And especially comparing to the start ups that you work before.

你现在也和谷歌以外的公司交流。

You also talk with with companies now outside of Google.

有哪些是谷歌独有的特点？

What were things that are uniquely Google?

在谷歌的这段经历里，我做了很多开发方面的工作。

As part of my Google journey, there was a lot of work that I did on the developer side.

同时，我也做了很多面向消费者方面的工作。

There's also a lot of work that I did on the consumer side.

比如，专注于Chrome的性能优化。

So working on, Chrome performance, for example.

当你做的东西要面向几十亿用户时，就像现在谷歌的很多产品那样，你对工程文化、速度和实验的思考方式，我觉得会和初创公司很不一样，尤其是当你想快速推进的时候。

And when you're working on something that goes out to billions and billions of users, which is the case for for many Google products now, the way that you think about engineering culture, velocity, experimentation is very, very different, I think, than sometimes how a startup might approach things, especially if you're trying to move very fast.

当我们试图在拥有全球大量用户的浏览器里做出改变时，需要进行大量的实验。

When we try to make a change inside a browser that has a global audience with a lot of people, there's a lot of experimentation that has to happen.

很多实验还需要测试，比如，这个问题是不是没有唯一解，而是根据你所在的市场，其实有好几个不同的方案？

A lot of experimentation that also requires testing out, well, hey, does this problem not have one solution, but actually a couple of different ones, depending on what market you're in?

而且，当可能同时有20个或100个其他实验在进行时，你如何评估成功？

And how do you evaluate success when maybe we have 20 other experiments or 100 other experiments happening at the same time?

所以，我觉得A/B测试文化是非常重要的一块。

And so, the AB testing culture, I would say, was a very big thing.

要感谢Chrome团队，现在他们有一个相当稳定和严谨的流程，能在现实世界中测试这些改动。

Kudos to the Chrome team for having what is now, I would say, a fairly stable and rigorous process for being able to try those things out in the real world.

我也觉得，虽然有时候从外部看不一定总是这样，但从谷歌整体来看，我确实觉得有很多人非常关心开发者的好感和情绪，但当你公司很大的时候，显然你不可能……

I also felt that even though sometimes from the outside it didn't necessarily always come across, zoomed out at the Google level, I did feel like there were many people that cared a lot about developer goodwill and developer sentiment, but when you have a very large company, obviously, you're not...

要让每个团队都互相沟通，那是不可能的。

It's gonna be very challenging to have every group talking to every other Impossible.

我们总是尽力去做到为开发者做正确的事情，尽我们所能。

We always made best efforts to try getting to a place where we were doing the right things for developers as best we could.

但我很高兴看到这种对社区和用户的关心和重视。

But I was glad to see that sentiment and that level of care for the community and for our users.

我也很欣赏谷歌愿意接受改变。

I also appreciated that Google was was open to change.

所以，如果让我总结我对Chrome文化的一大贡献，那就是要适应开发者的需求。

So I would say if if I had to summarize my my one big change contribution to Chrome's culture, it would be meeting the developers where they're at.

并且要接受人们会使用他们想用的任何技术。

And that embrace of people are gonna use whatever tech they wanna use.

你通常没法告诉别人该用什么。

You can't tell people what to use very often.

他们想用什么就用什么，你的工作是帮他们在你的平台上成功，并帮助他们的用户获得好的体验。

They're gonna use whatever they want, and your job is to help them be successful on your platform and to help their users have a great time.

我觉得我们多年来做的很多决定，让这件事变得更容易实现一些。

I think that there were a lot of decisions we made over the years that helped make that a little bit more possible.

我们和不同的框架团队有很好的合作，我们采纳了他们关于希望平台提供哪些API的反馈。

And we had good collaborations with different framework teams, we took their feedback about APIs they would like to see in the platform.

这变得更像是和社区的协作，而不是我们自己去猜测社区需要什么才能成功。

It became a lot more of a collaboration with the community, rather than guessing what we thought the community needed to be successful.

所以，我很高兴看到这种情况发生。

And so, I was very happy to see that happen.

我还想说，谷歌非常擅长让公司不同部门分享他们的经验，朝着某个共同点靠拢。

I would also say that Google was very good at allowing different parts of the company to share their learnings towards some point of convergence.

比如，《谷歌软件工程》这本书，是我最喜欢的书之一。

So, for example, the Software Engineering at Google book, one of my favorite books.

我很高兴多年来在公司内部看到各种不同的做法，因为你在这么大的公司工作，你总是好奇，什么才是最佳实践？

I was very happy to see different flavors of that over the years internally at the company, because you work at such a big company, you're always curious, well, what is best practice?

有没有最佳实践？

Is there a best practice

所以他们就像是在说，一般性的写作，比如这个组织在软件工程、构建、实验等方面是怎么做的。

So they were like, general writing, like, here's how this org is doing some parts of software engineering or building or experimentation or whatever.

我最喜欢做的事情之一就是，你知道，我很好奇，我的团队可能对测试或用户体验有自己的看法，但YouTube团队是怎么想的呢？

One of my favorite things to do was, you know, I was curious, well, my team might have a perspective on testing or user experience, but how does the YouTube team think about it?

有没有相似之处？

And are there parallels?

有没有什么可以互相学习的地方？

Are there things that we could learn from each other?

当然有。

And there certainly were.

即使只是看看别人怎么看待这个世界，有时也能带来合作的机会。

Even looking at how other people think about the world can sometimes lead to collaboration opportunities.

我们实际上曾与YouTube团队合作，改善他们的核心网页指标，他们很高兴看到有更精细的指标和体验思考方式。

We actually worked with YouTube team to improve their Core Web Vitals at one point, and they were excited to see that there were just more refined metrics and ways of thinking about experience.

我想需要指出的是，这种协作性质在任何……

I I guess it's just important to point out that this collaborative nature is not a given in any...

在所有大公司中都不是理所当然的。

In all large companies.

有些公司，我现在不想点名，但有些组织觉得彼此合作没有动力，因为他们可能有不同的目标。

There are some companies, don't wanna name names right now, but where organizations don't feel that they're incentivized to work with each other because they might have different goals.

并不是他们互相讨厌，只是他们专注于自己，那样感觉上会更有政治色彩。

And it's not that they hate each other, they're just focused on themselves, and it can feel a lot more political that sense.

现在经常谈论高主动性，我认为有时你看到这些合作发生，是因为双方都有足够主动性的人想要促成它。

Talk a lot about high agency these days, and I think that sometimes when you see those collaborations happen, it's because there are people with enough agency on both sides that they wanna make it happen.

他们看到了合作中的共同价值，因为探索如何改善像YouTube这样的用户体验，非常微妙，非常有教育意义，非常细致，但也花了很长时间。

And they see the mutual value in collaborating because exploring how to improve the user experience for something like YouTube, it was extremely nuanced, extremely educational, very nuanced, but also took a very long time.

我们只是觉得价值就在那里。

And we just felt like the value was there.

我很高兴我们做到了。

I was glad that we made it happen.

我们能谈谈你在谷歌的具体职业道路吗？

Can we talk about your specific career path inside of Google?

你在那里待了十四年，这是很长的时间，而且我开始觉得，在职业生涯的某个阶段，长期待在一个地方是件好事。

So you spent fourteen years there, which is a very long tenure, and I'm starting to develop a bias for, like, it's nice to have long tenure somewhere at some point in your career.

这有很多价值。

There's a lot of values.

你之前和Turbo Puffer的创始人Simon聊过这个。

You were just talking with with Simon, the founder of Turbo Puffer, about this earlier.

你入职时是什么级别？

What level did you get in?

你的职业发展是怎样的？

How was your career progression?

你是什么时候成为经理的？

At what point did you become a manager?

那你是怎么考虑像职业薪酬增长这些事情的？

And how did you think about things like career compensation growing?

其实我是在英国生活的时候开始我的谷歌职业生涯的。

So I started my Google career back when I was living in The UK, actually.

所以你是加入了谷歌英国？

So you joined Google UK?

我最初加入的是谷歌英国，我记得是以四级加入的，就是那个，对。

I joined Google UK originally, and believe I joined at a level four, like at the Yeah.

那是一个。

That that was one.

中级软件工程师。

The mid mid level software engineer.

那时候。

Back then.

我是一名开发者关系工程师，就是做DevRel的，但更侧重于开发者体验，你懂的。

And I was a developer relations engineer, so a person that's in DevRel, but you're a little bit more focused on, you know, the builder Yeah.

从开发者的角度来说。

Side of things.

这些年来，我在这个职位上逐渐晋升到了五级和六级。

Over the years, I kind of got promoted in that role to level five and level six.

我成为了DevRel部门的一名经理。

I became a manager within DevRel.

当你处于六级，也就是高级工程师级别的时候。

When you were at level six at the staff level.

是的，那时我负责带领DevRel团队的一部分。到了某个时候，大概五六年之后，我开始觉得，我非常喜欢做开发者关系的工作，但我骨子里其实是个工程师。

Yeah, and then I was was leading part of the DevRel team, and at some point, maybe five or six years in, I started to feel like, you know, I I loved doing developer relations, but I I am very much a builder at heart.

我喜欢工程，也喜欢产品。

I engineering and I love product.

我全都喜欢，你懂的，但是……

I love all of it, you know, but

我明白。

I get it.

我很好奇，你知道，站在那个位置会是什么感觉。

I was very curious, you know, what it would be like to be on the other side of that.

因为我在谷歌之前做过工程。

Because I'd been in engineering prior to Google.

在那之前我没有正式做过开发者关系的工作，我对回到那个方向很感兴趣。

I hadn't been in an official DevRel position prior to that, and I was interested in going back down that direction.

所以这些年来，我转回了软件工程，特别是工程经理的职位。

And so over the years, I transitioned back into software engineering and specifically an engineering manager role.

这让我既能做工程工作，又能管理团队。

That gave me the flexibility to both do engineering work, but also manage teams.

但你

But you

那时候团队比较小？

just had a smaller team at that point?

开始的时候团队比较小，后来就扩大了。

At the start, had a smaller team, and then it grew out.

我估计平均人数一度大概在四十五到五十人左右。

I would say the average at one point was probably in the 40 fives to fifties.

我觉得，在你领导或管理生涯的不同阶段，成功的定义是不一样的。

I think that depending on where you are in your leadership or manager journey, success means different things.

而且我说的不是职业上的成功，而是对组织而言的成功。

And not success from a career perspective, but just success for the organization.

因为最终你要达到的目标是，理想情况下团队几乎能自我运转。

Because ultimately, what you want to get to is a place where ideally the team is almost self sufficient.

我在我的书《Leading Effective Engineering Teams》里也提到过一点，你要让你的机器、你的组织足够自给自足，这样你只需要偶尔轻轻碰一下，确保一切正常运转。

And I write about this a little bit in my book, Leading Effective Engineering Teams, but you wanna get to a point where your machine, your org is self sufficient enough that you just need to occasionally tap the blimp, make sure that things are working.

如果出了问题，你可以及时纠正。

You can course correct if it's not.

但这样你就能腾出手来，专注于组织接下来需要重点解决的重要问题。

But that frees you up to then focus on the next important sets of problems that the org needs to tackle heads on.

这让我能够深入思考，比如，模型质量开始变好了，接下来该怎么办。

And that allowed me, for example, to really get deep into thinking about, okay, well, model quality is starting to get better.

这对开发人员意味着什么？

What does that mean for developers?

这对开发工具又意味着什么？

What does that mean for developer tooling?

这对我们如何看待基准测试、与第三方供应商的合作，以及构成开发者成功的所有其他因素有什么影响？

What does it mean for how we think about benchmarks and collaborations with third party vendors and all of these other things that are part of developer success?

所以我挺庆幸自己有了那段沉淀的时间，然后把这些经验带回去跟团队一起打磨，让我们走到今天这个阶段，能够帮开发人员把 DevTools 和 Chrome 对智能体的效用最大化。

And so I was I was glad that I had that time, and then I could take those learnings back to the team and work with them to evolve us into this moment where we could, you know, help developers maximize how useful DevTools can be, and DevTools and Chrome can be for agents.

所以我理解得对吗？你之前是独立贡献者，也就是个人 Contributor？

So do I understand correctly that, you know, you you were an individual contributor?

然后你在职业阶梯上往上走，这在像 Google 这样的大公司里，如果有合适的导师和架构，算是比较正常的晋升路径吧？

You were going up the career ladder, which is somewhat expected at a at a large company like Google with the right mentors and the right structure?

后来你转做管理了，方向也变了，但你觉得应该再拓展一下，于是把重心放在了……

And then when you became a manager and you switched, but you decided to build a bit more, you then focused on...

你带了一个不断扩大的大团队，大概有四十人左右。

You saw a growing and increasing large team, like 40 people.

这可不是个小团队，但你已经……

That's that's not a small team, but you've...

你试着帮团队解决问题，让他们基本上能自己运转，这样你就有时间做一些个人贡献者的工作，既能保持动手能力，也能帮助团队。

You try to help the team fix any issues, help them mostly run by themselves so that you would have some time to actually do some individual contributor like work so you can keep your hands dirty, but also help the team.

所以，看起来你……

So like, it it seems like you...

我理解得对吗？你就是优先留出时间来搞开发？

Do I understand that you just prioritized to have that time to build?

因为当然，当经理的话，很容易把所有时间都占掉。

Because, of course, when you're a manager, this could easily suck up all of your time.

哦，对。

Oh, yeah.

当然。

Absolutely.

而且我不想贬低达到那个目标所做的所有工作，因为很多管理工作的目标就是朝着那个方向努力。

And I don't want to make small of all the work it takes to get to that point, because a lot of management is trying to work towards that point.

你需要搭建团队结构，比如，有时候要有经理管理经理。

You need to build out a team structure, like, in some cases, have managers managing Managers.

对，就是管理其他团队的经理。

Managers, right, of other teams.

而且我们有一个全球团队，当然，这涉及到时区协调、沟通成本以及所有这些事情。

And we had a global team of people, of course, that comes with navigating time zones and coordination overhead and communication and all those things.

所以，我觉得我们很幸运，能够达到一个团队效率相当高的状态，并且能够创造更多的空间。

And so, I think that we were we were fortunate that we were able to get to a place where the team was largely pretty effective, and we were able to create more of the space.

然后我吸取这些经验，尝试帮助我的其他经理。

And then I take those learnings and I try to help some of my other managers.

比如，你怎么为自己创造这个空间，这样你也能帮助我们进行面向AI时代的现代化转型？

Like, how do you how do you create this space now for you so that you can also help us on this journey of modernizing for the AI moment?

所以，我从L6升到L7，再到总监，在我的……

So I went I went from l six to l seven to director in my...

总监是L8还是L7？

Is director L eight or l seven?

总监是L8。

Director's L 8.

总监是L8。

Director's L 8.

哦，哇。

Oh, wow.

所以那……

So that...

那有点……

That's kind of...

嗯，恭喜。

Well, congrats.

这真是……

It's it's...

它变成了……

It becomes...

据我了解，级别会变得越来越难，但你真的那么在意实际级别吗，还是更看重工作本身，事情自然就跟着走了？

Level becomes somewhat harder and harder as I understand, but did you care too much about the actual levels, or was it more about the work and things just followed?

我觉得在很长一段时间里，我确实更看重工作本身。

I think for a very long time, it was about the work.

但当你觉得组织运行得比较健康的时候，你确实会开始想，好吧。

But also, like, as you as you get to a point where you feel like the organization is in a healthy place, you do start thinking about, okay.

接下来我的职业发展，去解决不同类型的问题。所以如果……

Well, next level of my career, taking on different kinds of problems So if

更像是下一个挑战，对吧？

a little more like a next challenge, right?

对，下一个挑战。

Yeah, the next challenge.

所以我一直很想争取总监的晋升，而且我也一直在为此努力。

And so I was very much wanting to go for a director promotion for quite a while, and I was working towards that.

我觉得对于任何经历过职业变动或晋升的人来说，你都知道你得先在这个职位上干一段时间才能得到它，而且让你走到今天这一步的能力，不一定能帮你达到下一个高度。

And I think that for anyone that's gone through career changes or promotions, you know that you kind of have to be doing the job for a while before you get it, and what kind of got you where you are isn't what's gonna get you to that next level.

这是另一套挑战。

It's a different set of challenges.

所以，我很兴奋能开始体验这些挑战，并在谷歌内部更广泛地合作，更多地与我们的副总裁和高级副总裁层级合作，试图弄清楚，嗯，是的，接下来几年或者接下来一年安卓、Chrome以及我们不同的平台团队会是什么样子，因为我们正在经历这些革命性的时刻。

And so, I was excited to get to start experiencing those kinds of challenges and working more across Google, working more with our VP and SVP layers to try figuring out, well, yeah, what what is the next couple of years or what does the next year look like for Android, for Chrome, for our different platform teams as we're going through these these kind of revolutionary moments?

我们正在尝试重新思考一切。

We're trying to rethink everything.

我确实想问一下，因为我们有很多经验丰富的观众和听众。

I did wanna ask because we have a lot of pretty experienced viewers and and listeners.

在谷歌，成为总监具体有什么不同？

What is the difference in becoming a director at Google, specifically?

因为总监是第一个高管层级。

Because director, it does the first executive level.

我的意思是，不同公司叫法不同，但这是第一个在责任上、在肩上的重量上可能被包括在内的层级。

I mean, different companies call different, but, like, it's the first one which it it might be included in terms of responsibility, the weight on your shoulder?

因为在这样的大公司里，感觉在管理链条中这是最大的跳跃。

Because it does feel like that feels in the management chain that is the biggest jump at a large company like this.

我觉得可以这样理解：在我一步步晋升的过程中，总监通常就是你在高管层面的第一联系人，就像你刚才说的。

I think that a good way to think about it is when I was coming up through the ranks, your director was very often your first point of contact, as you said, at the executive level.

他们会负责督促你确保年度目标、季度目标等各项指标都按计划推进；当你需要推动大型项目或启动新计划时，他们也是你会去寻求支持的人。

They would be the ones who would be keeping you on the hook for making sure that any of your annual goals, quarterly goals, any of that was on track, they'd be the ones that you'd be looking to sponsor any large programs, any new projects, things like that.

如果工作严重偏离轨道，你需要承担责任，那么总监通常会定期主持复盘会议，确保整个团队的方向没有跑偏。

If things were going way off track and you were being held accountable, the directors were often the ones that would be having review forums regularly to make sure that that whole ship is actually still steering in the right direction.

所以到了这个层级，责任感会明显增强。

So there is an increased feeling of accountability at that level.

你得关注细节。

You have to pay attention to the details.

我觉得如果你只是放手不管，在那个职位上是做不好的。

I think that you can't be successful in that role if you're just letting go.

我说理想状态下团队能自主运转，并不是说完全撒手不管，而是要建立好足够的机制，让你能及时获取所需信息，团队遇到的任何决策问题或障碍都能迅速反馈给你，这样你才能帮他们排除阻碍。

When I say you want, ideally, to have a self running org, it's not about letting go entirely at all, but it's about having enough of a system in place where you get the information you need, any decisions, any blocks that your teams are running into are surfaced quickly to you so you can help them unblock them.

我觉得这是最关键的一点之一，就是确保业务目标得以实现，并且让那些可能不太清楚如何将技术与业务目标联系起来的人，也能非常清晰地看到这条主线。

I think that that's really one of the biggest pieces, like making sure that the business goals get done and making sure that people who perhaps sometimes don't necessarily understand how to connect the tech that's being done back to the business goals, like, see that through line very clearly.

我记得，我在做总监的时候，负责Gemini和Cloud AI的项目。

I remember that, you know, I was doing the director role through my time working on Gemini and Cloud AI.

我负责我们的一些……

I was responsible for some of our...

比如，我们当年的一个首要目标。

Like, one of our top goals for the year.

你每两周左右就要汇报一次，并且要承担责任。

You're expected to report on that every week or two and be held accountable.

所以你得确保一切进展顺利，让这些数字和目标朝着正确的方向前进。

So you need to make sure that everything happens to keep those numbers and those goals moving in the right direction.

所以我觉得，这个职位确实承担了很多责任。

So there's a lot of accountability, I would say, that comes with

对，到了那个级别。

that level.

所以听起来……

So it sounds like it's

差不多就像你在同时处理好几件事的时候，突然又多了两个球要接，也就是说，现在你……

almost like if you're juggling stuff, you're given, like, two extra balls, which is, like, now you...

既要承担那些责任，向上跟高管沟通业务目标，又要兼顾日常运营等其他工作。

Both the accountability, communicating upwards with with execs owning the business goals while doing everything else in terms of, like, running an...

现在带的团队可能更大了，还得能深入细节，随时掌握最新动态。

Now probably larger team, being able to deep dive into the details, so keeping yourself to date.

所以，对，我想这挺合理的：在一个组织里待得越久，积累的背景信息就越多，通常也会准备得更充分。

So, yeah, well, I guess it kinda makes sense that there's a trajectory where if the longer you work in an organization, the more context you'll have, the more ready you often become.

没错。

Absolutely.

确实如此。

Absolutely.

我觉得有个挺有意思的例子值得分享一下，而且我觉得这不只是谷歌的情况。过去几年里，让我最兴奋的一点是，随着模型质量和工具的不断优化，我看到很多总监、副总裁甚至高级副总裁级别的高管都亲自上手，尝试各种新东西。

And I think an interesting anecdote that I think is worth sharing is, and I don't think this was specific to Google, one of the things I found most exciting in the last couple of years was seeing as model quality's gotten better and harnesses and tools have gotten better, how many people that were directors or VPs or SVPs or any of these levels were actually rolling up their sleeves and trying things out.

看到这样的场景真是太棒了，因为每周我都能和这些人展开交流，比如：嘿。

And that was was awesome to see because every week, could then have conversations with people like, hey.

你周末做了什么？

What did you build at the weekend?

你在试哪些模型？

What models are you trying out?

你在哪些地方遇到困难了？

What are you running into friction with?

你在用哪些工作流程？

What workflows are you using?

这在以前是不会发生的。

And that's not something that was happening before.

高管们通常只关注公司的大问题或工作上的大问题。

Execs were very typically focused on big company problems or big work problems.

但最近几年情况变了。

But that's been changing in the last couple of years.

这让我们很自然地过渡到下一个话题，那就是根据你的观察和经验，AI 正在如何改变软件工程。在我们开始讨论之前，你经常被很多人问到一个问题，你自己也在思考，那就是“认知投降”这个概念。

Which received us very nicely into the next topic, which is how AI in your observation and experience is changing software engineering right before we started talking about one question that comes up to you from a lot of people and you're also thinking about is this idea of, like, cognitive surrender.

那我们进入这个话题吧。

Let's get into that.

这里其实有两部分。

So there's two pieces here.

第一部分是认知负债。

The first is cognitive debt.

也就是说，你越用AI，你的记忆力和对正在处理的问题的理解力就会逐渐退化。

So the more that you use AI, it's it's sort of the erosion of your ability to have good memory and have good understanding of the problems that you're working on.

随之而来的自然结果就是认知投降，也就是你盲目接受AI给出的任何答案。

And the natural follow-up to that is cognitive surrender, which is where you blindly give in to whatever the AI says as your answer.

它的答案就成了你的答案。

Its answer becomes your answer.

于是你开始真正放弃批判性思维，解决问题的能力也就慢慢荒废了。

And so you start to really let go of critical thinking, and your ability to solve problems just goes to the wayside.

我觉得这是我们要避免的，因为，你知道，我……

I think that that's something we wanna avoid because, you know, I'm I'm...

我个人非常看好Harness工程、Loop工程以及软件工厂这些技术的发展趋势。

Personally, I'm a I'm a big fan of the evolution curve we're seeing with harness engineering and loop engineering and software factories and all of these things.

我对它们的前景感到非常兴奋。

I'm very excited about them.

但与此同时，我认为我们仍需深入理解其运作原理，这样一旦出现问题，我们才能切实解决，而不是单纯指望AI代理能自行搞定。

But at the same time, I think that we still need to understand enough about how things work so that if something does go wrong, we're actually able to fix it and not just hope and pray that the agent is able to figure things out.

大约一年前，你曾撰文强调在与AI代理协作时的重要性，当时它们的能力远不如现在。

And it was about a year ago where you wrote about the importance of when you're working with an agent, and this was before they were as capable as today.

但当你在使用智能体时，要仔细阅读它生成的内容，仔细思考，然后当它生成代码时，也要通读一遍代码，确保自己真正理解。

But when you're working with an agent, read through read through what it it has, think through, and then, you know, when it generates a code, read through that code, make sure you understand.

就像是在做一种审查工作。

So, like, you're kind of, like, doing a review.

现在我们有了功能更强大的智能体。

Now we have a lot more powerful agents.

我们现在可以……

We can now...

有些人会同时用多个代理。

Some people work, like, with multiple agents.

你觉得跟着代理的节奏去读、去理解，你怎么看？

What is your thinking on the kind of the reading, the going at the same pace of the agent?

而且，你知道，因为现在放手太容易了，因为你想放手，然后欠下认知债。

And and, you know, like, because there's friction of, like, it's now so much easier to, like, not not let go because you wanna let go and have cognitive debt.

就是，它们更快，而且大部分时候都挺好。

It's just, like, they're faster, and it's pretty good for the most part.

生活中遇到的很多挑战，其实都是因为缺乏主动避免它们的意识。

With many challenges people run into in life, there's a lack of intentionality around wanting to avoid them.

我经常看到这种情况发生。

This is one of those places where I see this happen quite a lot.

我的想法有点变了。

And my thinking on this has changed a little bit.

一年前，你可能会收到代理的一条思考消息，说，嘿，我在后台思考。

A year ago, maybe you would have one thinking message from the agent saying, hey, I'm thinking in the background.

然后你展开它，就能看到整个轨迹，还有所有正在发生的事情的总结。

And you'd expand it, and you would see a trajectory, and you'd see the summary of all the things that are happening.

而且速度也跟得上，你能看明白。

And it was in speed where you could follow as well.

每隔几秒就有新东西冒出来。

Like every few seconds, something coming.

现在呢，如果你用 quad code 或者 Codex，很可能已经有二三十个子代理在跑了。

And now, if you're using quad code or Codex, it's very possible that 20 or 30 sub agents have fired.

我可不会一个个点开那三十个东西去读它们的轨迹，但我一定会做两件事。

I am not gonna click through 30 of those things to read through their trajectories, but I do make sure that I do two things.

第一件事，我会确保如果最后有个总结，把所有做的决定列出来，我会读一遍；如果没有，我会要求它给出决策过程。

The first thing I do is I try to make sure that if there is a summary at the very end, here are all the decisions that were made, I will read through that end If to there hasn't been, I will prompt for that decision process.

而且你得小心，因为你不希望模型在那些决策上糊弄你。

And you have to be careful because you don't want a model to kinda BS you about, like, these decisions that were made.

因为它有时候真的会瞎编。

Because sometimes it can just, like, make things up.

但它运行……

But It run...

而且而且而且，作为作为

And and and as as

我们知道，这不一定是故意的，但它超出了上下文窗口。

we know, it's not deliberate necessarily, but it runs out of context window.

就像，它……

Like, it's...

这些东西是有局限性的。

There's limitations to these things.

没错。

Exactly.

而且那里……

And there...

这就引出了第二点。

And that goes on to the second thing.

我非常喜欢这种相互促进的想法。

I'm a really big fan of this idea of mutual amplification.

如果你和一个智能体合作，一个编程智能体，你可以做很多事情来确保这个智能体每天都在进步，而你作为工程师，也在每天进步。

If you are working with an agent, a coding agent, there are a lot of things that you can do to make sure that the agent is getting better every day, and you, as an engineer, are getting better every day.

有一些简单的事情可以做到这一点。

There are simple things that can play into that.

比如，即使在会话中或在这个项目中，你能记录下你从会话中学到的东西吗？

Things like, even within the session or within this project, can you log your learnings from the session?

你能记录下做出的任何决定吗？

Can you log any decisions that were made?

你遇到的任何摩擦，你认为你处理这个问题的方式有什么独特之处，我应该记住的？

Any friction that you ran into, anything that you think is unique about how you've approached this problem that I should just keep in mind?

这就是有意为之。

That's intentionality.

这就像，我想了解事情在幕后是如何运作的。

That's like, I I want to understand how things work behind the scenes.

而且只要你有那种好奇心，至少保持一点点好奇的渴望，我觉得你就可以和模型合作，同时还能保留一些你对事物运作方式的认知理解。

And as long as you have that curiosity and that thirst for at least being just a little bit curious, I think that, you know, you can work with models in a way where you're still preserving a little bit of your cognitive understanding about how things work.

基因工程中即将出现的一个新构建块是循环工程的概念，彼得·斯坦伯格写过相关文章。

One new building block that's coming up in genetic engineering is this idea of loop engineering, and Peter Steinberger wrote about it.

鲍里斯·丘尼也写过关于运行循环的内容。

Boris Churney wrote about it, about running loops.

我们很多人都在试图弄清楚循环到底是什么。

A lot of us are trying to figure out what loops exactly are.

你也写过一篇关于循环的文章。

You also wrote a post about loops.

你觉得循环是什么？

What do you think loops are?

我们应该怎么理解它们？

How should we think of them?

还是说这只是一些……

Or is is just some...

这是对少数人有用的事情吗？

Something that is useful for a few people?

你在这方面进展如何？

Where are you at with that?

一个好的思考方式是……

A good way to think about...

所以，循环是我们旅程的一部分，目的是为了有效地创建软件工厂，或者有些人喜欢称之为……

So loops are part of this journey we are on to effectively create software factories or some people like

软件工厂的意思是，你给出一些指令，就像在工厂里，我想生产一辆汽车，然后有一个全自动的工厂，汽车就出来了。所以……

Software factory meaning like a thing where you give some instructions, you're like, in a factory, I would like to produce a car and then there's a fully automated factory, and the car comes So

而不是仅仅专注于提示以得到结果，你是在构建一个系统，这个系统可以处理提示、生成结果，并为你进行测试和验证，这实际上是软件演进每个阶段的下一步。

instead of focusing on purely the prompting towards getting an outcome, you're building the system that can do the prompting and generate the outcome, do the testing and verification for you, and it's effectively the next step of every phase of software evolution.

这就像抽象概念的不断上升的浪潮。

It's just like a rising tide of abstractions.

这是下一个抽象。

This is the next abstraction.

这里面有很多细微之处需要考虑。我觉得如果你直接告诉别人，对，搞个系统帮你把所有活儿都干了，那些在行业里待过一阵子的人肯定会有些显而易见的疑问，比如质量怎么保证？

And it comes with a lot of nuance because I think that if you tell someone, yeah, create a system that will just do all of your work for you, anyone that's been in the industry for a while are gonna have obvious questions like, what about quality?

你怎么确保事情不会跑偏呢？

How are you making sure things aren't going off the rails?

所以我认为你得想清楚，哪些环节需要让人保持在流程中参与进来。

And so, I think that you have to be very intentional with, okay, well, what are the parts of this where you're keeping the human in the loop?

你的系统是不是应该提醒你，嘿，有些改动涉及到了系统里挺关键的部分，你可能还是得让人工审核一下。

Are you having your system flag to you that, hey, there are changes that were touched that actually you know, are hitting a pretty critical part of the system, and you probably do want human review on this.

但如果只是让循环去构建一切，却没有设置好控制影响范围的护栏，也没有对质量把控建立相应的约束，我认为这简直是灾难的预兆。

But simply just having your loops build everything without having some guardrails around the blast radius, without having guardrails around how you think about quality, I think is a recipe for disaster.

我听到很多地方都在用软件工厂这个比喻，再说一遍，它……

I hear the analogy of software factory a lot of places, again, it...

当然还有黑灯工厂。

And and, of course, dark factory as well.

黑灯工厂的意思是工厂里灯火通明，灯都关了，因为机器人不需要照明，这样还能省电省钱。

Dark factory meaning it's fully on in factories, lights are turned off because the robots don't need to see and save energy and money.

但有一件事我一直在想……

But one thing that I'm...

我一直在想，这个类比通常就像，在工厂里，你生产一个东西。

I keep thinking that is often this analogy is like, in a factory, you produce a thing.

它可能是一辆车。

It could be a car.

它可能是一颗螺丝。

It could be a screw.

它可能是别的东西。

It could be something.

它就在那里，完成了。

It's it's there and it's done.

但对于软件，特别是SaaS和我们做的大多数软件来说，它并没有完成。

But with software, specifically SaaS and most software that we do, it's not done.

当它完成时，我们发布到生产环境，然后就在那里崩溃，bug就出来了。

When it's finished, we release it to production and that's where it crashes, the bugs come out.

所以我在想，这种整个想法，比如，好吧，我们有一个工厂生产软件，并且它做了所有的测试。

So I wonder if this whole idea of like, okay, we'll have a factory that produces the software and it does all the testing.

如果在生产环境中，它没有与运行方式连接起来，没有那种反馈，那...

If in production, it's not connected to how it's running and having that feedback, that's...

你明白我的意思吗？

You you see what I mean?

就像，...

Like, the...

我们说的是一种不同类型的工厂。

It's a different type of factory that we're talking about.

所以你完全说中了下一阶段的关键。

So hit you hit the nail exactly on sort of the next phase of that.

你可以...

You can...

如果你能有一个系统，能够决定需要构建什么，如何验证，如何测试，以及所有这些东西，那么没有什么能阻止你将它与遥测、其他系统、用户反馈以及任何其他有助于构建产品的信号连接起来。

If you can have a system that can sort of decide what needs to get built, how to verify, how to test, and all of those things, there's nothing stopping you from then connecting that up to your telemetry, up to your other systems, up to user feedback, up to any other signals that can help build out the product.

你可以把它连接到产品待办事项列表，然后你可能会看到一个世界，在这个世界里，这个系统可以访问所有这些不同的信号，了解产品如何改进，甚至可能达到主动改进的程度。

You can connect it up to the product backlog, and you can potentially see a world where you then have this system that has access to all of these different signals for how the product can be improved to a point where maybe it even could get proactive.

我们正在看到……

And we're seeing...

有很多例子可以接入，比如你正在使用 Sentry。

There are so many examples that you can plug it up, for example, if you're using Sentry.

Sentry 有自动化功能，比如，如果 Sentry 中触发了一个全新的错误，你可以设置一个钩子，启动你最喜欢的编码代理，它一次性修复问题，然后交给你审查。

Sentry has automations where, like, if an error fires in Sentry that is net new, you could have a hook that kicks off your favorite coding agent where it one shots a fix and it puts you in your review.

当然，你把它……

Now, of course, you took it...

你可以更进一步，允许它自动执行，这在今天听起来是个坏主意，但你可以做到。

You could take it further and you could allow it to automatically do it, which sounds like a bad idea today, but you could do it.

我在想，这是否……

And I wonder is...

当我们谈论循环时，这是否，比如说，我们所说的一个循环？

When when we're talking about loops, is this, for example, a loop that we say?

也许“循环”这个词不太合适。

And maybe the the loop is just not a good word for it.

也许它更像是……

Maybe it's...

我听到的是“工作流”。

I I heard workflow.

我听到的是，比如……

I heard, like...

或者如果我说“反馈循环”。

Or if I say feedback loop.

好的。

Okay.

比如，那可能是个更好的词。

Like, that might be a better word.

也许……

Maybe...

这只是一个用词的问题吗，比如我们对这个词有点困惑？

Is it just a wording thing where, like, we're a little bit confused with the

我的意思是，考虑到事情发展得这么快，我们很可能会看到每个月都有新术语冒出来。

I mean, I I think that given how fast things are moving, we are very likely to see new terminology sprout out every month.

其中一些会很合适，而另一些则还需要进一步完善。

And some of them will be good fits, and some of them will continue to require some refinement.

所以我完全能理解，用“工作流”可能比“循环”更贴切。

So I could totally see workflow being a better fit, than loop.

但从视觉角度来看，我确实……

But from a visual perspective, I do...

我个人确实觉得它像一个循环。

I personally do see it as a loop.

“工作流”也说得通。

Workflow also also works.

但是，你能给我举一些例子吗，比如你用过或见过你团队里的人或行业里的人用过的循环？

But but then can you give me examples of loops that you've you've used or you have seen people on your team or people on the industry use?