揭秘Claude代码：来自构建工程师的深度解析

所以你正在推行某种lint规则，但没有自动修复功能，因为AST分析对于它来说太简单了。

So there's some kind of lint rule you're rolling out, there's no auto fixer because it's like AST analysis is kind of too simplistic for it.

我认为其他情况比如框架迁移。

I think other stuff is like framework migrations.

我们刚刚从一个测试框架迁移到了另一个不同的框架。

We just migrated from one testing framework to a different one.

这是一个非常常见的场景，因为输出很容易验证。

That's a pretty common one where it's super easy to verify the output.

我发现的一件事是，无论是在Every内部的项目还是开源项目中，如果你是一个正在构建产品的开发者，并且想实现一个之前已经做过的功能。

One of the things I found is, and this is both for projects inside of Every and then just open source projects, it's like if you're someone building a product and you want to build a feature that's been done before.

所以也许一个人们可能需要实现很多的例子就是内存管理。

So maybe an example that people might need to implement a bunch is memory.

你怎么实现内存管理？

How do you do memory?

因为我们内部有很多不同的产品，你可以直接启动多个云端子代理，去问问这三个其他产品是怎么做的。

Because we have a bunch of different products internally, you can just like spawn cloud sub agents to be like, how do these three other products do it?

而且这里还存在一种隐性的代码共享可能性，你不需要定义 API，也不需要去询问任何人，可以直接问：我们之前是怎么做这个的？

And there's like possibility for just like tacit code sharing where you don't need to like have an API, you don't need to like ask ask anyone, you can just be like, how does, how do we do this already?

然后借鉴最佳实践来构建你自己的方案。

And then use the best practices to build your own.

你也可以用开源项目来做这件事，因为有很多开源项目，人们已经花了整整一年时间研究内存管理，做得非常好。

And you can also do that with open source, because there's tons of open source projects where people are like, they've been working memory for a year and it's really, really good.

你可以问：人们已经发现了哪些模式？哪些模式是我想要采用的？

You can be like, what are the patterns that people have figured out and which ones do I want to implement?

完全正确。

Totally.

你还可以连接到你的版本控制系统。

You can also connect to your version control system.

如果你以前开发过类似的功能，Cloud Code 可以通过这些 API 直接查询 GitHub，找到过去人们是如何实现类似功能的，阅读代码并复制相关部分。

If you've built a similar feature in the past, Cloud Code can use those APIs, like query GitHub directly, and find how people implemented a similar feature in the past, and read that code and copy the relevant parts.

是的。

Yeah.

你有没有发现日志文件的用途，比如记录下我实现它的完整过程？

Have you found any use for log files of, Okay, here's the full history of how I implemented it.

把这些内容提供给Claude重要吗？

And is that important to give to Claude?

是实现这个功能，还是让它对Claude有用？

Implementing that or making it useful for it?

有些人非常推崇这种方法。

Some people swear by it.

在Anthropic公司，有些人每完成一项任务，都会让Claude Ko以特定格式写一篇日记，记录它做了什么、尝试了什么、为什么没成功。

There are some people at Anthropic where for every task they do, they tell Claude Ko to write a diary entry in a specific format that just documents like, what did it do, what did it try, why didn't it work.

他们甚至还有代理程序，会回顾过去的记忆并将其综合成观察结果。

And then they even have these agents that look over the past memory and synthesize it into observations.

我认为这还只是初步的萌芽，这里有一些有趣的东西可以产品化，但这是我们看到的一种新兴且效果良好的模式。

I think this is like the starting budding, There's something interesting here that we could productize, but it's a new emerging pattern that we're seeing that works well.

我认为，仅凭一次对话就注入记忆的难点在于，很难判断某个特定指令对所有未来任务的相关性。

I think the hard thing about one shotting memory from just one transcript is that it's hard to know how relevant a specific instruction is to all future tasks.

比如我们经典的例子是，如果我说‘把按钮变成粉色’，我不希望你记住要把所有按钮都变成粉色。因此，我认为从大量日志中综合出记忆，是一种更一致地发现这些模式的方法。

Like our canonical example is, if I say make the button pink, I don't want you to remember to make all buttons pink And in the so I think synthesizing memory from a lot of logs is a is a way to find these patterns more consistently.

看起来你可能需要一些方法，有些情况下你可以通过自上而下的方式总结或综合出信息。

It seems like you probably need like, there's some things where you're gonna know you'll be able to summarize, like synthesize or summarize in this sort of like top down way.

这些信息以后会很有用，你会知道在哪个抽象层次上它可能有用。

This will be useful later, and you'll know the right level of abstraction at which it might be useful.

但还有很多情况是，任何一个提交日志，比如‘把按钮变成粉色’，都可能有无数种你事先无法预知的用途。

But then there's also a lot of stuff where it's like, you actually, any given commit log, like make the button pink, it could be useful for kind of an infinite number of different reasons that you're not going to know beforehand.

因此，你还需要模型能够查找所有相似的过往提交，并在恰当的时候呈现出来。

So you also need the model to be able to look up all similar past commits and surface that at the right time.

这也是你在思考的问题吗？

Is that something that you're also thinking about?

是的，这可能是一种可行的方向。

Yeah, I there could be something like that.

我认为一种看待方式是，这种传统记忆存储工作，比如Memex之类的东西，你只是想把所有信息都存进系统，之后就变成一个检索问题。

I think one way to see it is this kind of like traditional memory storage work like Memex, like kind of stuff where you just want to put all the information into the system and then it's kind of a retrieval problem after that.

是的，随着模型变得越来越智能，我注意到它也开始自然地这样做，比如在Sonnet 4.5中，当它遇到卡壳时，会自发地像我们之前讨论的那样，使用bash命令去翻阅Git历史记录，然后说：哦，原来这样处理还挺有意思的。

Yeah, think as the model also gets smarter it naturally I've seen it start to naturally do this also with Sonnet 4.5 where if it's stuck on something it'll just naturally start looking like we talked about before like using bash spontaneously to just look through Git history and be like, oh, Okay, yeah, this is kind of an interesting way to do it.

对。

Yeah.

在我们开始录制之前，我们曾提到过一件事，那就是我们如今在每个项目中都深度依赖Cloud Code和CLI工具，这彻底改变了我们的工程方式。

One of the things that we were talking before we started recording, one of the things that we're doing inside of every I feel like it has really changed the way that we do engineering, because everyone is Cloud Code pilled, like CLI pilled.

我们有一种称为‘复利工程’的工程范式，在传统工程中，每增加一个新功能，都会让下一个功能更难实现。

And we have this engineering paradigm that we call compounding engineering, where in normal engineering, every feature you add, it makes it harder to add the next feature.

而在复利工程中，我们的目标是让每一个新功能的开发，都让下一个功能更容易构建。

And in compounding engineering, your goal is to make the next feature easier to build from the feature that you just added.

我们实现这一点的方式是，把所有开发过程中积累的经验和教训都系统化地记录下来。

And the way that we do that is we try to codify all the learnings from everything that we've done to build the feature.

比如：我们最初是如何制定计划的？计划中哪些部分需要调整？在测试时发现了哪些问题？我们遗漏了哪些关键点？

So how did we make the plan and what parts of the plan needed to be changed, or when we started testing it, what issues did we find, what are the things that we missed.

然后我们将这些经验固化到所有提示词、子代理和命令中，这样当下次有人遇到类似情况时，系统就能自动捕捉并提醒，从而让后续工作变得更轻松。

And then we codify them back into all the prompts and all the sub agents and all the slash commands so that the next time when someone does something like this, it catches it, and that makes it easier.

这就是为什么对我来说，比如，我可以直接进入我们的任何一个代码库并立即开始高效工作，即使我对代码的运作方式一无所知，因为我们已经建立了一套累积了所有实施过程中所学知识的记忆系统。

That's why for me, for example, I can hop into one of our code bases and start being productive, even though I don't know anything about how the code works, because we have this built up memory system of all the stuff that we've learned as we've implemented stuff.

但我们不得不自己构建这套系统。

But we've had to build that ourselves.

我很想知道，你们是否在构建类似的循环，让 Cloud Code 能自动实现这一点？

I'm curious, are you working on that kind of loop so the Cloud Code does that automatically?

是的，我们已经开始考虑这个问题了。

Yeah, we're starting to think about it.

有趣的是，我们也从菲奥娜那里听到了同样的说法。

It's funny, we heard the same thing from Fiona.

她刚加入团队，是我们主管。

She just joined the team and she's our manager.

她差不多有十年没写过代码了，类似这种情况。

She hasn't coded in like ten years, something like that.

但她第一天就提交了被合并的代码请求。

And she was winning PRs on her first day.

她还说，没错，我不但忘了怎么编程，但Quad Code让我轻松地重新上手，而且我不需要再熟悉任何上下文，因为我本来就了解这些。

And she was like, Yeah, not only did I kind of, I forgot how to code and quad code kind of made it super easy to just get back into it, but also I didn't need to ramp up on any context because I kind of knew all this.

我认为很大一部分原因在于，当人们为Quad Code提交拉取请求时，我觉得我们的客户也经常做类似的事情。

And I think a lot of it is about like when people put up pull requests for quad code itself, and I think our customers tell us that they do like similar stuff pretty often.

如果你看到一个错误，只需说：加Quad，把这个加到quadmd里，这样下次它就会自动知道了。

If you see a mistake, I'll just be like, add quad, add this to quadmd so that the next time it just knows this automatically.

你可以用各种方式来培养这种记忆。

And you can kind of like instill this memory in kind of a variety of ways.

你可以说：加Quad，把它加到quadmd里。

So you can say like add quad, add it to quadmd.

你也可以直接说：加Quad，写个测试。

You can also say add quad, write a test.

你知道，这是一种确保不会倒退的简单方法。

You know, that's like an easy way to make sure this doesn't regress.

而且，别再因为让人写测试而感到不好意思了，因为这实在太简单了。

I And don't feel bad asking anyone to write tests anymore, because it's like super easy.

我认为我们几乎100%的测试都是由Quad生成的，如果测试不好，我们就不会提交，只有好的测试才会被保留。

And I think probably close to 100% of our tests are just written by quad, and if they're bad, we just won't commit it, and then the good ones stay committed.

此外，我认为lint规则也是一个重要的方面。

And then also I think lint rules are a big one.

对于那些经常需要强制执行的规则，我们实际上有一套内部的lint规则。

So for stuff that's enforced pretty often we actually have a bunch of internal lint rules.

这些规则完全由Claude编写。

Claude writes 100% of these.

这通常就是在一个PR中添加Claude，然后写这个lint规则。

And this is mostly just like add Claude in a PR, write this lint rule.

是的，目前确实存在一个问题，就是如何自动实现这一点？

And yeah, there's sort of this problem right now about like how do you do this automatically?

我认为Kat和我通常的思路是，我们看到这种高级用户的行为，第一步是让产品可自定义，让最出色的用户能自己摸索出这些酷炫的新用法。

And I think generally how Kat and I think about it is we see this like power user behavior, and the first step is how do you enable that by making the product hackable so the best users can figure out how to do this cool new thing.

但真正的难点在于，如何将这种能力推广到所有人？

But then really the hard work starts of like how do you take this and bring it to everyone else?

对我来说，我属于‘其他人’这一类。

And for me, count myself in the everyone else bucket.

我其实不太会用VIM，也没有那种复杂的T box配置。

I don't really know how to use VIM, I don't have this crazy T box setup.

所以我的设置非常普通。

So I have a pretty vanilla setup.

如果你能做出一个我会用的功能，那就能很好地说明其他普通工程师也会使用它。

So if you can make a feature that I'll use, it's a pretty good indicator that other average engineers will use it.

这很有趣。

That is interesting.

跟我说说这个吧，因为我一直在思考这个问题：如何让产品具有足够的可扩展性和灵活性，让高级用户能发现你根本想不到的创新用法，同时又足够简单，让任何人都能轻松上手并高效使用，还能把高级用户的发现反馈到基础体验中。

Tell me about that, because that's something I think about all the time is making something that is extensible and flexible enough that power users can find novel ways to use it that you would not have even dreamed of, but it's also simple enough that anyone can use it, and they can be productive with it, and you can pull what the power users find back into the basic experience.

你是如何思考这些设计和产品决策的，以便实现这种平衡？

How do you think about making those design and product decisions so that you enable that?

一般来说，我们认为每个引擎环境都有所不同，因此我们系统的每个部分都必须具有可扩展性。

In general, we think that every engine environment is a little bit different from the others, and so it's really important that every part of our system is extensible.

从状态行到通过自定义斜杠命令，再到钩子——这些钩子允许你在四码流程的几乎每一步插入确定性逻辑。

So everything from your status line to adding your own slash commands through to hooks, which let you insert a bit of determinism at pretty much any step in quad code.

因此，我们认为这些是我们提供给每位工程师的基础构建模块，他们可以自由地进行探索和使用。

So we think these are the basic building blocks that we give to every engineer that they can play with.

关于插件，实际上这是我们团队的Daisy开发的，我们的目标是让像我们这样的普通用户更容易将这些斜杠命令和钩子融入自己的工作流程中。

For plugins, plugins is actually our so it was built by Daisy on our team, and this is our attempt to make it a lot easier for the average user like us to bring these slash commands and hooks into our workflows.

插件的功能是让你浏览现有的MCP服务器、现有的钩子、现有的插件，或者更准确地说，浏览现有的斜杠命令，然后只需在Cloud Code中输入一条命令，就能将它们一键添加到你的环境中。

And so what plugins does is it lets you browse existing MCP servers, existing hooks, existing plugins, and just like or sorry, existing slash commands, and just let you write one command in Cloud Code to pull that in for yourself.

产品领域有一个非常古老的概念叫‘潜在需求’，我认为这正是我个人思考产品和决定下一步该做什么的主要方式。

There's this really old idea in product called latent demand, which I think is probably the main way that I personally think about product and think about what to build next.

这是一个非常简单的理念。

It's a super simple idea.

你设计的产品要具备可篡改性，足够开放，让用户能将其用于原本未设计的其他用途，然后你观察他们如何‘滥用’它，再据此进行优化开发。

You build a product in a way that is hackable, that is of open ended enough that people can abuse it for other use cases it wasn't really designed for, then you see how people abuse it and then you build for that.

因为你清楚地知道，这种需求是真实存在的。

Because you kind of know there was demand for it.

对。

Right.

你知道，当我还在Meta的时候，我们就是用这种方式打造所有大型产品的。

And you know, when I was at Meta, this is how we built kind of all the big products.

我认为几乎每一个大型产品都蕴含着这种潜在需求的精髓。

I think almost every single big product had this nugget of latent demand in it.

比如，Facebook的交友功能就源于这样一个想法：当我们观察谁查看他人个人资料时，发现大约60%的浏览行为发生在异性之间，而他们彼此并不认识。

You know, like for example, something like Facebook data came from this idea that when we looked at who looks at people's profiles, I think 60% of views were between people of opposite gender, so kind of like traditional setup, that were not friends with each other.

于是我们想，哦，天哪，如果我们想做一个约会产品，或许可以利用这种已经存在的需求。

And so we're like, Oh man, okay, maybe if we want a dating product we can kind of harness this demand that exists.

这很有趣。

That's interesting.

对于 Marketplace 来说，情况也差不多。

And for Marketplace it was pretty similar.

当时我认为，Facebook群组中约有40%的帖子是买卖类帖子。

I think it was like 40% of posts in Facebook groups at the time were buysell posts.

所以我们觉得，人们正在自己使用这个产品。

And so we're like, okay, people are trying to use this product by themselves.

我们就围绕它开发了一个产品。

We just build a product around it.

这很可能行得通。

That's probably gonna work.

因此，我们以类似的方式思考，但同时我们还有为开发者构建产品的优势。

And so we think about it kind of similarly, but also we have the luxury of building for developers.

开发者喜欢折腾东西，也喜欢自定义功能。

And developers love hacking stuff and they love customizing stuff.

作为我们自己产品的用户，这让构建和使用这个工具变得特别有趣。

It's like as a user of our own product it makes it so fun to build and use this thing.

所以，正如我所说，我们只是搭建了合适的扩展点，观察人们如何使用它，这就能告诉我们下一步该开发什么。

And so yeah, like I said, we just built the right extension points, we see how people use it, and that kind of tells us what to build next.

比如，我们收到了大量用户反馈，说：‘天啊，Cloud Code 怎么要这么多权限，我正出去买咖啡呢。’

Like for example, we got all these user requests where people were like, Dude, Cloud Code is asking me for all these permissions, and I'm out here getting coffee.

我不知道它为什么问我如何才能让它在 Slack 上给我发提醒？

I don't know that it's asking me for How can I just get it to ping me on Slack?

所以我们开发了钩子，Dixon 做了 Hooks，让使用者能收到 Slack 的提醒。

And so we built hooks, Dixon built Hooks, so that people could get pinged on Slack.

你可以针对任何你想在 Slack 上收到提醒的事情设置提醒。

And you could get pinged on Slack for anything that you want to get pinged on Slack for.

因此，这明显反映出人们非常希望拥有执行某些操作的能力。

And so it was very much like people really wanted the ability to do something.

我们不想自己去开发这些集成，所以我们开放了 Hooks，让用户自己实现。

We didn't want to build the integration ourselves, and so we exposed Hooks for people to do that.

让我想到的是，你们最近发布了新版本，把 Cloud Code 的定位重新调整为一个更通用的代理 SDK。

The thing that makes me think of is you recently released, you kind of moved or rebranded how you talk about Cloud Code to be this more general purpose agent SDK.

这个转变是源于某种潜在需求吗？你们是否发现你们所构建的东西有更广泛的用途？

Was that driven by some latent demand where you saw there's a more general purpose use case for what you built?

我们意识到，就像你提到的用 Cloud Code 做编码以外的事情一样，我们也经常看到这种情况。

We realized that, similar to how you were talking about using Cloud Code for things outside of coding, we saw this happen a lot.

我们收到了大量案例，人们使用云代码来帮助他们撰写博客、管理所有数据输入，并以自己的语气进行初步处理。

We get a ton of stories of people who are using Cloud Code to help them write a blog and manage all the data inputs and take a first pass in their own tone.

我们发现有人用它来构建邮件助手。

We find people building email assistants on this.

我经常用它来做市场研究，因为本质上，它是一个代理，只要给你一个明确的任务，并能获取正确的底层数据，它就可以无限期地运行。

I use it for a lot of market research because at the core, it's an agent that can go on for an infinite amount of time as long as you give it a concrete task and it's able to fetch the right underlying data.

我之前在做的一个项目是，我想了解全球所有公司以及它们各自拥有的工程师数量，并据此创建一个排名。

So one of the things I was working on was I wanted to look at all the companies in the world and how many engineers they had and to create a ranking.

而这件事正是云代码可以做到的，尽管它并不是一个传统的编程用例。

And this something that quad code can do, even though it's not a traditional coding use case.

于是我意识到，底层的原语其实非常通用。

So I realized that the underlying primitives were really general.

只要有一个能够长时间持续运行的代理循环，并且能够访问互联网、编写代码和运行代码，那么只要你稍加想象，几乎就能用它构建任何东西。

As long as you have an agent loop that can continue running for a long period of time, and you're able to access the internet and write code and run code, pretty much you can, if you squint, you can kind of build anything on it.

我认为，当我们把产品从云代码SDK重新命名为云代理SDK时，已经有成千上万的公司在使用它了。

And I think at the point where we rebranded it from the Quad Code SDK to the Quad Agent SDK, there was already many thousands of companies using this thing.

而且很多这些用例根本不是关于编程的。

And a lot of those use cases were not about coding.

所以无论是内部还是外部，我们

So it's both internally and externally, we

看到了，比如健康助手、金融分析师、法律助手。

saw Yeah, it was like health assistants, financial analysts, legal assistants.

用途非常广泛。

It was pretty broad.

是的。

Yeah.

最酷的是哪些？

What are the coolest ones?

我觉得你最近在播客上采访过诺亚·布莱尔。

I feel like actually you had a Noah Briar on the podcast recently.

我觉得Obsidian思维导图笔记工具的使用案例真的令人震惊，有这么多人用它来做这个。

I thought the Obsidian mind mapping note keeping use It's cases is really insane how many people use it for this.

这种特定的组合。

This particular combination.

我认为一些编码或与编码相关的用例挺酷的，比如我们有一个针对Quad代码的问题追踪器。

I think some coding or coding adjacent use cases that are kind of cool is we have this issue tracker for quad code.

团队一直忙得不可开交，根本跟不上源源不断涌入的问题。

The team's just constantly underwater trying to keep up with all the issues coming in.

问题实在太多了。

There's just so many.

所以Quad会去重这些问题，自动识别重复项，而且做得非常出色。

So Quad dedupes the issues and it automatically finds duplicates and it's extremely good at it.

它还能进行初步的解决处理。

It also does first pass resolution.

通常当出现一个问题时，它会主动创建一个内部拉取请求，这是团队里的Inigo新开发的功能。

So usually when there's an issue it'll proactively put up a PR internally and this is a new thing that Inigo on the team built.

这相当酷。

So this is pretty cool.

还有值班机制，以及从其他地方收集信号，获取Sentry日志和BigQuery日志，并将所有这些信息整合起来。

There's also on call and collecting signals from other places, getting sentry logs and getting logs from BigQuery and collating all this.

而且它在这方面非常出色，因为所有这些都只是手动编写的Bash脚本。

Plus it's really good at doing this, because it's all just Bash in hand.

这些都是我看到的一些内部使用场景。

And so these are all these internal use cases that I saw.

所以当它在整合日志或去重问题时，是像你们在后台持续运行云服务吗？

So when it's collating logs or deduping issues, is that like you have clouds continually running in the background?

这是你们专门为这个构建的吗？

And is that something that you're building for?

对于这个特定功能，每当有新问题提交时就会被触发。

For that particular one, it gets triggered whenever a new issue is filed.

所以它只运行一次，但可以根据需要运行任意长时间。

So it runs once, but it can choose to run for as long as it needs.

明白了。

Got it.

那关于让四元组一直运行的想法呢？

What about the idea of quads always running?

哦，主动型四元组。

Oh, proactive quads.

我认为这确实是我们要达到的方向。

I think it's definitely where we want to get to.

我觉得目前我们非常专注于让四元组编码在单个任务中变得极其可靠。

I would say right now, we're very focused on making quad coding incredibly reliable for individual tasks.

还有多行自动补全、单轮代理，现在我们正在开发能够完成任务的四元组代码。我觉得如果你追踪这条发展曲线，最终会走向更高层次的抽象，处理更复杂的任务。

And multi line autocomplete and then single turn agents and then now we're working on quad code that can complete tasks, I feel like if you trace this curve, eventually you go to even higher levels of abstraction, even more complicated tasks.

然后，希望在这之后的下一步是大幅提升生产力。

And then hopefully, the next step after that is a lot more productivity.

比如理解你团队的目标、你的目标，能够说：嘿，我觉得你可能想尝试这个功能，这是我写的初步代码，以及我做出的假设，这些假设对吗？

So just understanding what your team's goals are, what your goals are, being able to say, Hey, I think you probably want to try this feature and here's a first pass at the code, and here are the assumptions I made, and are these correct?

我等不及了。

I can't wait.

我认为紧随其后的是，Claude 会成为你的经理。

And I think probably right after that is Claude is now your manager.

天哪。

Oh no.

这不在计划之中。

That's not in the plan.

所以团队里的每个人都对我们今天的对话感到非常兴奋，他们给了我一堆问题，我得确保回答到所有问题。

So everyone on the team was like super excited that we were talking today and they gave me a bunch of questions and I want to make sure I hit all the questions.

哦，这是个好问题。

Oh, here's a good one.

你们在架构中为什么选择智能检索而不是向量搜索？向量嵌入还有相关性吗？

Why did you choose agentic rag over vector search in your architecture, and are vector embeddings still relevant?

实际上，我们最初确实使用了向量嵌入。

So actually, initially we did use vector embeddings.

但它们很难维护，因为你必须不断重新索引代码，而且它们可能会过时，还有本地更改也需要被纳入。

They're just really tricky to maintain because you have to continuously re index the code and they might get out of date, and you have local changes, so those need to make it in.

当我们思考外部企业如何采用它时，我们意识到这会暴露更多的攻击面和安全风险。

And then as we thought about what does it feel like for an external enterprise to adopt it, we realized that this exposes a lot more surface area and security risk.

我们还发现，Cloud Code 和 Cloud Models 在代理搜索方面表现非常出色。

We also found that actually Cloud Code is really good and Cloud Models are really good at agentic search.

因此，你可以通过代理搜索达到相同的准确率，而且部署起来要简洁得多。

So, you can get to the same accuracy level with agentic search, and it's just a much cleaner deployment story.

这真的很有趣。

That's really interesting.

如果你确实想在 Cloud Code 中引入语义搜索，可以通过 MCP 工具来实现。

If you do want to bring semantic search to Cloud Code, you can do so via an MCP tool.

所以，如果你希望自行管理索引，并提供一个让 Cloud Code 调用的 MCP 工具，这是可行的。

So if you want to manage your own index and expose an MCP tool that lets Cloud Code call that, that would work.

你认为哪些 MCP 工具最适合与 Cloud Code 搭配使用？

What do think are the top MCPs to use with Cloud Code?

Puppeteer 和 Playwright 是其中比较突出的选择。

Puppeteer and Playwright are pretty high up there.

当然。

Definitely.

是的。

Yeah.

Sentry 的一个非常好。

Sentry has a really good one.

Asana 的一个也非常棒。

Asana has a really good one.

Do

Do

你认为在 Anthropic 内部或其他大型组织中，那些重度使用 Cloud Code 的用户有哪些不为人知但值得了解的高级技巧吗？

you think that there are any power user tips that you see people inside of Anthropic or other people who are big power inside of organizations that are big Cloud Code power users that people don't know about but they should?

Cloud Code 本身不太擅长主动提问，但我个人觉得这非常有用。

One thing that Cloud Code doesn't naturally like to do, but that I personally find very useful, Cloud Code doesn't naturally like to ask questions.

但你知道，当你和思维伙伴或合作者一起头脑风暴时，通常你们会互相提问。

But, you know, if you're brainstorming with a thought partner, collaborator, usually you do ask questions back and forth to each other.

所以这是我喜欢做的一件事，尤其是在计划模式下。

And so this is one of the things that I like to do, especially in plan mode.

我会直接告诉Cloud Code：嘿，我们只是在头脑风暴这件事。

I'll just tell Cloud Code like, Hey, we're just brainstorming this thing.

请问我问题。

Please ask me questions.

如果你有任何不确定的地方，我希望你主动提问，我会配合的。

If there's anything you're unsure about, I want you to ask questions and I'll do it.

我认为这实际上能帮助你得出更好的答案。

And I think that actually helps you arrive at a better answer.

我们还能分享很多技巧。

There's also so many tips that we can share.

我觉得我经常看到人们犯的一些常见错误。

I think there's a few really common mistakes I see people make.

就像你所说的，不够使用计划模式。

One is like you said not using plan mode enough.

这非常重要，我认为这对刚接触代理式编码的人来说尤其关键。

This is just super important and I think this is people that are kind of new to agentic coding.

他们往往以为这东西什么都能做，但实际上并不能。

They kind of assume this thing can do anything and it can't.

它今天的表现还不够好，但未来会变得更好；目前它只能一次性完成一些测试，无法一次性完成大多数任务。

It's not that good today and it's going to get better but today it can one shot some tests, it can't one shot most things.

因此，你必须了解它的局限性，明白自己在什么环节需要介入。

And so you kind of have to understand the limits, you have to understand where you get in the loop.

像计划模式这样的功能，如果你先确定好计划，就能轻松将成功率提升两到三倍。

And so something like plan mode, it can like two, 3x success rates pretty easily if you land on the plan first.

我还看到一些高级用户做得特别好的地方，比如那些大规模部署了Cloud Code的公司，幸运的是，现在这类公司很多，我们可以从中学习。

Other stuff that I've seen power users do really well is companies that have really big deployments of quad code, and now luckily there's a lot of these companies so we can kind of learn from them.

设置配置项。

Having settings.

将JSON文件提交到代码库中非常重要，因为你可以用它来预先允许某些命令，避免每次都要请求权限，同时也能阻止某些命令。

Json that you check into the codebase is really important, because you can use this to pre allow certain commands so you don't get permission prompted every time, and also to block certain commands.

假设你不想使用网络获取或其他功能。

Let's say you don't want web fetch or whatever.

这样作为工程师，我就不会被反复提示，我可以将这个配置提交到代码库，与整个团队共享，让每个人都能使用。

And this way as an engineer I don't get prompted, and I can check this in and share it with the whole team so everyone gets to use

我通过直接使用危险地跳过权限来绕过这个问题。

I get around that by just using dangerously skip permissions.

是的，我们这里也有这个功能，但我们不推荐使用。

Yeah, we kind of have this here, but we don't recommend it.

这是一个模型，你知道的。

It's a model, you know?

它可能会做出一些奇怪的事情。

It can do weird stuff.

我认为另一个有趣的用例是人们用停止钩子来做一些有意思的事情。

I think another kind of cool use case that we've seen is people using stop hooks for interesting stuff.

所以停止钩子会在每一轮任务完成时运行。

So stop hook runs whenever the turn is complete.

所以这结束了与各种工具的来回调用，任务已完成，并将控制权交还给用户。

So this has ended some tool calls back and forth with whatever, and it's done, and it returns control back to the user.

然后我们运行停止钩子。

Then we run the stop hook.

因此你可以定义一个停止钩子，比如如果测试未通过，就返回文本并继续执行。

And so you can define a stop hook that's like if the tests don't pass, return the text, keep going.

本质上，你可以让模型持续运行，直到任务完成。

Essentially it's like you can just make the model keep going until the thing is done.

当将这与 SDK 和这种程序化使用方式结合时，简直令人难以置信。

And this is just insane when you combine it with the SDK and this programmatic usage.

这本质上是一种随机的、非确定性的过程，但通过框架支持，你可以获得确定性的结果。

This is a stochastic thing, it's a non deterministic thing, but with scaffolding you can get these deterministic outcomes.

所以你们率先推动了这个命令行界面的范式转变。

So you guys started this CLI paradigm shift.

你们认为命令行界面会是最终的交互形态吗？

Do you think the CLI is the final form factor?

我们是一年后还是三年后主要在CLI中使用Cloud Code？

Are we going be using Cloud Code in the CLI primarily in a year or in three years?

还是有其他更好的方式？

Or is there something else that's better?

我的意思是，这并不是最终的形式，但我们非常专注于让CLI尽可能智能，并且尽可能可定制。

I mean, it's not the final form factor, but we are very focused on making sure the CLI is the most intelligent that we can make it and that it's as customizable as possible.

你可以谈谈下一代形式。

You can talk about the next form factors.

是的，凯特让我谈谈这个，因为没人跟得上这个速度，现在根本没人知道这些形式会是什么样子。我认为我们的团队正处于实验阶段，我们有CLI，然后推出了IDE扩展，现在又有一个新的IDE扩展，是一个GUI，更易用，我们还在GitHub上推出了Claud，你可以 anywhere 都添加Claud。

Yeah, I mean, Kat's asking me to talk about it because no one like this stuff's like it's just moving like so fast right like no one knows what these form factors are like right now I think our team is in experimentation mode so we have CLI then we came out with an IDE extension now we have a new IDE extension that's like a GUI it's a little more accessible We have claud in github so you can just add claud at anywhere.

现在还有网页版和移动端，你可以在这些地方使用它。

Now there's on web and on mobile so you can use it on any of these places.

我们正处于实验阶段，正在探索下一步该做什么。

And we're just in experimentation mode so we're trying to figure out what's next.

我认为如果我们从宏观角度看这些东西的发展方向，其中一个大趋势是更长的自主运行时间。

I think if we kind of zoom out and see where this stuff is headed, I think one of the big trends is longer periods of autonomy.

因此，对于每个模型，我们都会测量它能持续自主执行任务多久，在危险模式下的容器中自动压缩，直到任务完成。

And so with every model we kind of time how long can the model just keep going and do tasks autonomously, and just in dangerous mode in a container, keep auto compacting until the task is done.

现在我们已经达到了两位数小时的级别。

And now we're on the order of double digit hours.

我觉得上一个模型大概能运行三十个小时。

Think it's like the last model is like thirty hours.

差不多是这个水平。

Something like this.

下一个模型将能持续数天。

The next model is going be days.

当你考虑并行化模型时，会衍生出一系列问题。

As you think about kind of parallelizing models there's kind of a bunch of problems that come out of this.

其中一个问题是：这个程序运行在什么样的容器中？

So one is, what is the container this thing runs in?

因为你不想不得不关闭笔记本电脑。

Because you don't want to have to close your laptop.

我现在就是这样，因为我正在做很多Dispie。

I have that right now because I'm doing a lot of Dispie.

我读过相关的内容，关于DSPY或者Dispie的提示优化，它运行在我的笔记本上，我根本不想合上它。

I've read it, but DSPY or Dispie prompt optimization, and it's on my laptop, and it's like, I don't want to close it.

我总是开着笔记本屏幕，因为我不想合上它。

I'm like, in the window with my laptop open because I don't want to close it.

是的，没错。

Yeah, that's right.

对，我们之前拜访过一些公司和客户。

Yeah, we visited companies before, customers.

每个人都随身带着他们的四重代码。

Everyone's just walking around with their quad codes.

这是为其他人准备的吗？

Is this for other?

所以我认为其中一个问题是需要摆脱这种模式。

So I think one is kind of getting away from this mode.

然后我认为，很快我们就会进入这种监控四元组的模式。

And then I also think pretty soon we're going to be in this mode of monitoring quads.

我不知道这种模式的合适形态是什么，因为作为人类，你需要能够检查并了解正在发生什么。

I don't know what the right form factor for this is, because as a human you need to be able to inspect this and kind of see what's going on.

但同时，它也需要针对四元组进行优化，即优化四元组之间的通信带宽。

But also it needs to be quad optimized, where you're optimizing for kind of bandwidth between the quad to quad communication.

我的预测是，终端并不是最终的形态。

So my prediction is terminal is not the final form factor.

我的预测是，在未来几个月，甚至大约一年内，会出现几种新的形态。

My prediction is there's going be a few more form factors in the coming months, you know, maybe like a year or something like that.

而且它会持续快速变化。

And it's going keep changing very quickly.

你觉得呢？我经常给很多Every订阅者讲授云代码。

What do you think about, you know, I teach a lot of Cloud Code to a lot of Every subscribers

谢谢。

and Thank you.

不客气。

You're welcome.

为你代劳工作。

Doing doing your work for you.

我认为其中一件大事是，终端让人望而生畏。

And I think the like, one of the big things is just the terminal is intimidating.

和订阅者通话时，告诉他们如何打开终端，即使你非技术背景也能操作，这真的很重要。

And just being on a call with subscribers being like, here's how you open the terminal and you're allowed to do this even if you're non technical, is like a big deal.

你怎么看这个问题？

How do you think about that?

是的，我们市场团队的一位同事开始使用 Cloud Code，因为她正在撰写一些涉及 Cloud Code 的内容，我就说，你真的应该亲身体验一下。

Yeah, one of the people on our marketing team started using Cloud Code because she was writing some content that touched on Cloud Code, and I was like, you should really experience it.

她一用就弹出了大约30个弹窗，要求她接受各种权限，因为她以前从没用过终端。

And she got, like, 30 pop ups on her screen where she had to accept various permissions because she'd never used a terminal before.

对。

Yeah.

我完全同意你的看法。

So I completely see eye to eye with you on that.

对于非工程师来说，这确实很难，甚至有些工程师也发现日常使用终端并不完全自在。

It's definitely hard for non engineers, and there's even some engineers we found who aren't fully comfortable with working day to day in the terminal.

我们的 VS Code GUI 扩展是朝这个方向迈出的第一步，因为你根本不需要考虑终端。

Our Versus Code GUI extension is our first step in that direction because you don't have to think about the terminal at all.

它就像一个传统的界面，上面有一堆按钮。

It's like a traditional interface with a bunch of buttons.

我们正在开发更多图形化界面。

We are working on more graphical interfaces.

Cloud Code 网页版就是一个图形界面。

Cloud Code on the Web is a GUI.

我认为这可能是对技术不太熟练的人的一个很好的起点。

I think that actually might be a good starting point for people who are less technical.

是的。

Yeah.

几个月前，我有一次神奇的时刻，走进办公室时发现Anthropic的一些数据科学家就坐在Quad Code团队旁边。

There was this magic moment maybe a few months ago where I walked into the office and some of the data scientists at Anthropic sit right next to the quad code team.

这些数据科学家的电脑上竟然都在运行Quad Code。

And the data scientists just had quad code running on their computers.

我当时就问：这是什么？

And I was like, what is this?

你们是怎么发现这个的？

How did you figure this out?

我觉得可能是Brandon第一个这么做的。

I think it was like Brandon was the first one to do it.

他跟我说：哦，对啊，我就直接安装了。

And he was like, oh yeah, I just installed it.

我负责这个产品，所以我应该用它。

I work on this product, so I should use it.

我当时简直惊呆了。

And I was like, oh my god.

所以他弄明白了怎么使用终端和 Node。

So he figured out how to use a terminal and Node.

Js。

Js.

他以前没怎么做过这种工作流程。

He hasn't really done this kind of workflow before.

显然非常技术性。

Obviously very technical.

所以我认为我们现在开始看到越来越多与代码相关的功能，人们都在使用 Quad Code。

So I think now we're starting to see all these kind of like code adjacent functions, people use quad code.

是的，这还挺有意思的。

And yeah, it's kind of interesting.

从潜在需求的角度来看，这些人在自己动手改造产品，说明他们确实有使用它的需求。

From a latent demand point of view, these are people hacking the product, so there's demand to use it for this.

所以我们希望用更易用的界面让它变得更简单一些。

And so we want to make it a little bit easier with more accessible interfaces.

但与此同时，对我们来说，对于QuadCode，我们专注于为最优秀的工程师打造最好的产品。

But at the same time, for us, for QuadCode, we're laser focused on building the best product for the best engineers.

因此我们专注于软件工程，并希望把它做得非常好。

And so we're focused on software engineering, and we want to make this really good.

但我们希望让它成为其他人也能进行二次开发的东西。

But we want to make it a thing that other people can hack.

有时，Cloud Code 会生成一些略显冗长的代码，但你只需告诉它简化一下，它就能做得非常好。

Sometimes, Cloud Code will write code that's a bit verbose, but you can just tell it to simplify it, and it does a really good job.

有意思。

Interesting.

那么，你是在什么情况下、什么时候这样做的呢？

And so how and when are you doing that?

你是用斜杠命令，还是你……

So you're using a slash command or you're

我只是直接说出来。

I just say it.

就说 Every

Just say Every

每次你都是对的。

time you're just yeah.

有时候你会说，嘿。

Like sometimes you're like, hey.

这应该是一行代码的改动。

This should be a one line change.

是的。

Yeah.

我会在这里写五行代码。

And I'll write five lines here.

简化它。

Simplify it.

嗯嗯。

Mhmm.

它能立刻理解你的意思，我会马上修复。

And it understands immediately what you mean and I'll fix it.

是的。

Yeah.

我觉得我们团队里很多人也都会这么做。

I think a lot of people on our team do that too.

这挺有意思的。

That's it's interesting.

既然你总是这么说，那为什么不干脆把它做成一个斜杠命令或者集成到平台里，让它自动发生呢？

Why do you like why not then if you're saying that all the time, why not then, you know, push that into like a slash command or the harness or something like that to, yeah, make it just happen automatically?

我们在CloudMD里已经有相关的操作说明了。

We do have instructions for this in the CloudMD.

我觉得这种情况在对话中占比极低，我们不希望因此过度偏向另一个极端。

I think it impacts such a low percentage of conversations that we don't want it to, like, over rotate in the other direction.

嗯。

Mhmm.

而不是使用斜杠命令的原因是，你实际上不需要那么多上下文。

And then the reason why not a slash command is because you actually don't need that much context.

我认为斜杠命令非常适合那些通常需要写两到三行的情况。

I think slash command's really good for situations where you would otherwise need to write two, three lines.

嗯。

Mhmm.

但对于某些情况，比如计划模式，你其实可以用几个词，但有时候却需要两到三行才能完整表达出你在计划模式下想要的内容。

But for some like, even for plan mode, you actually can use a few words, but sometime but it actually takes two or three lines to capture the entirety of what you want in plan mode.

为了简化，你只需写‘简化它’，系统就能理解。

For simplify it, you can just write simplify it and it gets it.

是的。

Yeah.

对。

Yeah.

这说得通。

That makes sense.

酷。

Cool.

对。

Yeah.

好的。

Okay.

嗯，现在我们可以了。

Well, now we're we can.

这很有趣。

That's interesting.

是的，但这些东西，你知道，还是感觉太早期了。

Yeah, but this stuff, like, you know, it still feels just so early.

对。

Yeah.

你知道，我们之前录音前还聊过，关于我们现在处于采用曲线的哪个阶段，还是在早期阶段，或者不管怎么说。

You know, like we were talking before the recording about like kind of where are we on the adoption curve and it's still The Hauschen curve or whatever.

不管那个词是什么。

Whatever that term was.

没错。

Exactly.

而且感觉我们还处在前10%，这些东西变化会非常快，还会持续变化。

And it just feels like we're first 10%, still like this stuff is going to change so fast, it's going to keep changing.

即使我跟Anthropic之外的研究人员聊过他们使用Cloud Code的经历，他们也会卡在类似的问题上，比如没意识到可以直接让LLM简化它。

Even when I talk to researchers outside of Anthropic who've used Cloud Code, they also get stuck on things like this, like not realizing that they can just tell the LLM to simplify it.

我觉得这恰恰说明，即使是在这个行业工作的人，也并不总是意识到你可以直接跟模型对话。

And I think that just goes to show that even for people who are working in this industry, they don't always realize that you can just talk to the model.

关键在于，我认为人们潜意识里期望使用AI不应该需要什么技能，因为AI好像只要你说什么它就做什么。

That's the thing is like, I think that there's this underlying expectation that using AI shouldn't have to be a skill, like, because it just does whatever you say.

但你想想，你说的话本身会影响它的表现。

And you're like, well, I mean, whatever you say is going to matter for what it does.

所以如果你能表达得更好，它就会做得更好。

So if you can say things better, it's going to do better.

是的。

Yeah.

我的意思是，每个模型都不一样，这才是难点。

I mean, it changes with every model, That's the hard part.

比如，提示工程师曾经是个职业，但现在众所周知，它已经不再是职业了。

Like, prompt engineer was a job, and now famously it's not a job anymore.

会有很多类似的工作，之后也会消失。

There's gonna be more jobs that are then not jobs anymore.

这些你必须掌握的微小技能，随着模型变强，它能更好地理解你的意思。

These kind of little micro skills that you have to learn to use this thing and as the model gets better, it can just interpret it better.

但我觉得，对我们来说，这也是构建这种产品时必须保持的谦逊态度——我们真的不知道下一步会怎样，只是和大家一样在摸索中前进。

But I think that's also like, for us, this is part of this kind of humility that we have to have building a product like this that we just really don't know what's next, and we're just trying to figure it out kind of along with everyone else.

我们只是来体验这场旅程的。

We're just here for the ride.

所以你们为自己而构建它，这真的很棒，因为我觉得这才是真正了解它的最好方式。

And that's why it's cool that you're building it for yourself, because I think that's the best way to know that.

这就像是，你们——我们其实也是这样，你生活在未来，一直在使用它，所以很明显哪些功能还缺失。

It's just like, you're, and this is what we do too, is like, you're sort of living in the future, you're using it all the time, and it's pretty clear what's missing.

你心里想着，我就想要这个功能，然后直接去做下一个改进，而不是去问某个大公司的企业产品经理：你们想要什么样的AI功能？

You're like, I just want this thing, and you can just do the next thing, rather than being like, let me ask some enterprise product manager at some gigantic company, like, what kind of AI feature do you want?

他们说：我不知道。

And they're like, I don't know.

在IDE旁边加个聊天机器人，然后你就说：好吧。

Put a little chat bot on the side of my IDE, and you're like, Okay.

是的。

Yeah.

这就是开发工具的优越之处。

This is like the luxurious thing about building DevTools.

你就是自己的客户。

You're your own customer.

我认为这也是AI的独特之处，因为它为所有软件重新设定了游戏规则。

I think it's also really a unique thing about AI because it sort of reset the game board for all software.

所以我们有Quora、这个邮件助手，还有像Sparkle这样帮你整理文件的工具。

So we have Quora, this email assistant, and we have like Sparkle, which organizes your files.

任何你想要在电脑上使用的功能，如果你用AI来构建，很可能之前没人做过，因为整个格局已经被重新洗牌了。

And it's like anything that you do for something that you want to use on your computer, if you're building it with AI, there's a good chance that hasn't been done before because like the whole landscape has been reset.

所以，现在为自己构建东西是一个特别令人兴奋的时机。

And so it's a it's a uniquely exciting time to build stuff for yourself.

完全正确。

Totally.

我觉得这也彻底打开了竞争格局。

I think it totally opens the playing field too.

现在任何个人都可以开发一个应用来满足自己的需求，然后分享给其他人。

It's like any individual can now build an app to fill their need and then distribute it to everyone else.

是的。

Yeah.

对。

Yeah.

这真的很酷。

It's really cool.

我一直在原型化各种随机的个人项目。

I've been prototyping all these, like, random pet projects.

我刚搬进一个新公寓，里面空空如也。

I just moved into a new apartment and it's empty.

所以我用云代理SDK开发了一个购物顾问助手，因为谁有时间去读所有评论、查看所有选项、寻找价格呢？这些信息都很难获取。

And so I've been building this shopping advisor assistant on the Cloud Agent SDK because who has time to read all the reviews and look at all the options and find their pricing and everything's hard to discover.

它会问我一堆问题，然后我告诉它我想要什么。

And so it just asks me a bunch of questions and I tell it what I want.

比如家具？

Like for furniture?

是的，没错。

Yeah, exactly.

它会给我展示各种沙发的照片、不同选项以及网友的评价。

And it shows me a bunch of photos of different sofas and options and what people say online.

然后我会告诉它我不喜欢什么。

Then I tell it what I don't like.

这简直就像在和一个购物助手合作。

It literally feels like working with a shopping assistant.

这真的太棒了。

It's been really cool.

这真的很酷。

That's really cool.

我还有一个小小的邮件回复助手，帮我起草回复内容。

I also have my little email response agent that drafts responses for me.

但我平时不太用邮件，所以。

But I don't use email that much, so.

哦，我知道那不是你回复的。

Oh, and I knew it wasn't you responding.

所以才延迟了七天。

That's why it's seven days delayed.

这个代理做得非常细致。

The agent's just doing a very thorough job.

不过，代理SDK真的很棒。

Agent SDK is cool though.

是的，代理SDK很棒。

Yeah, Agent SDK is cool.

对，总是让人觉得惊讶，我们这么小的团队竟能构建出这么多东西。

Yeah, it always just feels amazing how much we're able to build with such a small team.

是的。

Yeah.

因为我觉得

Because I feel

还有另一件很酷的事，就是我觉得公司内部的人正在从依赖文档转向依赖演示。

like The there's other thing that's really cool is that I think people are just shifting their mindset from docs to demos internally.

我们的核心其实是演示。

Our currency is actually demos.

你希望人们对你做的东西感到兴奋。

It's like you want people to be excited about your thing.

给我们展示一下它能做什么，十五秒就够了。

Show us fifteen seconds of what it can do.

我们发现，现在团队里的每个人都已经形成了这种思维定式。

And we find that everyone on the team now has this kind of indoctrinated.

没错，这就是演示文化。

Democulture, for sure.

我认为这样更好，因为很多东西你可能只在脑子里有想法，如果你擅长写作，或许能想办法解释清楚。

And I think that's better because there's a lot of things that you might have in your head that if you're a great writer, maybe you could figure out how to explain it.

但即便如此，要解释清楚还是非常困难。

But even then, it's just really hard to explain.

但如果有人能亲眼看到，他们立刻就能理解。

But if someone can see it, they get it immediately.

我认为这种趋势在产品开发中正在发生，同时也正在影响各种其他类型的创意活动。

And I think that's happening for product building, but it's also happening for all sorts of other types of creative endeavors.

比如拍电影，以前你得去推销它。

Like making a movie, for example, you had to pitch it.

但现在你可以直接说：我做了个这样的视频，你看看。

But now you can just be like, I made this sort of video and check.

你可以以很低的成本看到你想要制作的东西的雏形。

You can kind of see the glimmer of the thing you're trying to make for very cheap.

这意味着你不必花太多时间去说服别人。

And so that means you don't have to spend time convincing people as much.

你只需要说：看，我做出来了。

You can just be like, here, I made it.

是的，而且作为创作者，你可以直接做出来，然后一遍又一遍地修改，直到你满意为止。

Yeah, and also as a builder, you can just make it, and then make it again, and then make it again until you're happy.

我觉得相反的是，过去你会写个文档或者在白板上画点什么，比如我会用Sketch或Figma画东西，但现在我们会直接动手做，直到感觉对了为止。

I feel like the flip side is you used to make a doc or whiteboard something or you know like I would draw stuff in like Sketch or Figma or whatever and now we'll just like build it until I like how it feels.

现在要传达那种感觉变得太容易了，我觉得以前你或许能用视觉呈现出来，或者用语言描述，但就是永远抓不住那种氛围。

And it's just like so easy to get that feeling out of it now and I think it's like you could see it visually before or you could describe it in words, but it's like you could never get the vibe.

现在，那种感觉变得非常容易捕捉了。

And now the vibe is real easy.

你把计划模式重做了三次。

And you built plan mode like three times

是因为你做了之后扔掉，再重做，又扔掉，再重做吗？

Like because of you built it and then you threw it out and rebuilt it and then threw it out and rebuilt it?

是的，待办事项这个功能，最初是西德做的，他也做了三四个版本。

Yeah, where to dos, like Sid built the original version, also like three or four, he built like three or four prototypes.

然后我听说之后还迭代了大约二十个版本，一天之内就完成了。

And then I've heard this had maybe like 20 versions after that, like in like a day.

是的，我觉得我们发布的几乎所有东西，背后都有至少几个原型。

Yeah, think this is like a lot of, pretty much everything we released, there was at least a few prototypes behind it.

你们是怎么跟踪并把从一个原型中学到的经验延续到下一个原型的？

How do you keep track of and carry forward the things you learn from prototype to prototype?

尤其是当一个人先做原型，然后你接手说，我要再做二十个版本的时候。

And especially if it's like, one person is prototyping it, and then you're like, I'm gonna take it over, I'm gonna do 20 more.

你如何最大化从中获得的收获？

How do you maximize what you get out of that?

这其中可能有几个要素。

There's maybe a few elements of it.

一个是风格指南。

One is the style guide.

所以我们发现了一些风格上的元素。

So there's some elements of style that we discover.

我认为这其中很多都是为终端而设计的。

And I think a lot of this is building for the terminal.

我们正在为终端发现一种新的设计语言，并边做边完善。

We're discovering a new design language for the terminal and building it as we go.

我认为其中一些内容可以编码到风格指南中，这就是我们的QuadMD。

And I think some of this you can codify in a style guide, so this is our QuadMD.

但还有一部分是产品直觉，我觉得模型目前还完全理解不了。

But then there's this other part of it that's kind of product sense where I don't think the model totally gets it yet.

我认为我们应该尝试找到方法，教会模型理解哪些做法有效、哪些无效，这种产品直觉。

And I think maybe we should be trying to find ways to teach the model this kind of product sense about this works and this doesn't.

因为在产品设计中，你希望以最简单的方式解决用户的问题，然后删除所有与此无关的内容，清除一切干扰。

Because in product you want to solve the person's problem in the simplest way possible and then delete everything else that's not that and just get everything out of the way.

所以你要尽快让产品与用户意图对齐。

So you align the product to the intent as quickly as possible.

也许模型目前还完全无法理解这一点。

And maybe the model doesn't totally get that yet.

是的，模型并不能真正体会到使用 Quad Code 的感受。

Yeah, it doesn't really feel what it's like to use quad code.

就像模型本身并不使用 Quad Code 一样。

Like the model doesn't use quad code.

所以我认为，当 Quad Code 能够自我测试、自我使用的时候，

So I think like when, you know, quad code can like test itself and it can kind of use itself.

我们在开发过程中就是这样做的，它能发现 UI 错误之类的问题。

And like we do this when developing and it can see like UI bugs and things like that.

我不知道，也许我们该试试直接提示它。

I don't know, maybe we should just try prompting it though.

说实话，很多这类事情就是这么简单。

Honestly, a lot of this stuff is as simple as that.

每当有新想法时，通常你只要提示一下，它往往就能奏效。

When there's some new idea, usually you just prompt it and often it just works.

也许我们就该试试这个。

Maybe we should just try that.

很多原型实际上都是用户体验交互。

A lot of the prototypes are actually the UX interactions.

所以我觉得，一旦我们发现新的用户体验交互，比如Shift

And so I think once we discover a new UX interaction like Shift

加

plus

Tab自动确认，我觉得Boris已经找到了。

Tab for auto accept, I think Boris figured out.

其实是伊戈尔。

That was Igor actually.

哦，伊戈尔。

Oh, Igor.

回去后

Went back

我们去了

we to went

博里斯。

Boris.

我们做了一周的原型。

We did doing prototypes for a week.

是的，Shift Tab 感觉非常好。

Yeah, Shift Tab felt really nice.

然后，当前计划模式的其中一个迭代采用了 Shift Tab，因为它实际上只是另一种方式，用来告诉模型它应该有多自主。

Then one of the now current plan mode iteration uses Shift Tab because it's actually just another way to tell the model how agentic it should be.

所以我认为，当更多功能使用相同的交互方式时，你会对各个功能应该放在哪里形成更强的心理模型。

And so I think as more features use the same interaction, you form a stronger mental model for what should go where.

我觉得是的。

Thinking Yeah.

我认为这是另一个非常好的点。

I think is another really good one.

我们最初在发布 Quad Code 之前，或者可能是第一个思考型模型的时候，是 3.7 吗？

First we were like, before we released Quad Code, or maybe it was like the first thinking model, was it like 3.7?

我忘了第一个版本叫什么了。

I forget what the first one was.

是的。

Yeah.

那时候它已经能够思考了，我们在头脑风暴：怎么才能切换思考模式？

And it was like, it was able to think and we're brainstorming, how do we toggle thinking?

然后有人就提议：如果直接让模型用自然语言来思考，它自己就知道该怎么思考了呢？

And then someone was just like, what if you just ask the model to think in natural language and it knows how to think?

我们就说，好的，太棒了，就这么办。

And we're like, okay, sweet, let's do that.

于是我们这么做了段时间，后来发现人们会不小心触发它。

And so we did that for a while and then we realized that people were accidentally toggling it.

所以他们就说：别想了。

So they were like, don't think.

然后模型就会想：哦，我应该思考。

And then the model's like, oh, I should think.

他们只是开始让它思考。

They just started thinking.

所以我们不得不调整一下，让‘别想了’不再触发它。

And so we had to kind of tune it out, so don't think didn't trigger it.

但那时仍然不够明显，于是我们做了个用户体验改进，来高亮显示思考状态。

But then it still wasn't obvious, so then we made a UX improvement to highlight the thinking Yeah, side yeah.

那样做真的很有趣，感觉特别神奇。

Of that so fun and it felt really magical.

当你使用超思考时，就像彩虹一样

When you do ultra think, it's like rainbow or

随便什么吧，对，没错。

whatever, Yeah, exactly.

在 Sono 4.5 中，我们发现开启扩展思考后性能有了显著提升。

And then with Sono 4.5, we actually find a really, really big performance improvement when you turn on extended thinking.

所以我们让它很容易切换，因为有时候你需要它，有时候不需要——对于简单任务，你不想让模型思考五分钟，你只想让它直接完成任务。

And so we made it really easy to toggle it because sometimes you want it, sometimes you don't because you kind of, for a really simple task, you don't want the model to think for like five minutes, you want it to just do the thing.

所以我们用 Tab 键来切换这个功能，然后移除了大量与思考相关的文字。

And so we used tab as the interaction to toggle it, and then we unshipped a bunch of the thinking words.

不过我觉得我们还是保留了‘超思考’，纯粹是出于情感原因。

Although I think we kept ultrathink just for sentimental reasons.

那真是个很棒的用户体验。

It was such a cool UX.

有意思。

Interesting.

你觉得有没有什么新的指标是关于你删除的内容的？

Do you think there's some new metric that's about what you deleted?

我觉得程序员一直觉得删除大量代码会让人感觉特别好，但如今因为构建东西变得如此迅速，删除代码也变得同等重要。

And I think programmers have always felt like deleting a bunch of code feels really good, but there's something about because you can build stuff so fast, it becomes more important to also delete stuff.

我觉得我最喜欢看到的 diff 是红色的 diff。

I think my favorite kind of diff to see is a red diff.

这太棒了。

This is the best.

比如当我收到一个时，我会说，好啊，来吧，再来一个，再来一个。

Like when I receive one, I'm like, yeah, bring it on, another one, another one.

但这很难，因为任何你发布的东西，都有人在使用。

But it's hard because anything you ship, people are using it.

所以你必须让所有人满意。

And so you've got to keep people happy.

我认为总体上我们的原则是，如果我们移除了某个功能，就必须推出一个更好、更能满足用户需求的新功能来替代它。

And I so think generally our principle is if we unship something, we need to ship something even better that people can take advantage of, that kind of matches that intent even better.

而且，这其实又回到了如何衡量四倍代码及其影响的问题上。

And yeah, think this is kind of back to how do you measure quad code and the impact of it?

这是每个公司、每个客户都会问我们的事情。

And this is something every company, every customer asks us about.

我觉得在Anthropic内部，自一月以来我们的规模大概翻了一倍左右。

I think so internally at Anthropic, think we doubled in size since January or something like that.

但在这段时间里，每位工程师的生产力却提升了近70%。

But then productivity per engineer has increased almost 70% in that time.

怎么衡量的？

Measured by?

我觉得我们实际上从几个方面进行了衡量，但PR是最简单也是最主要的指标。

I think we actually measured it in a few ways, but kind of PRs are the simplest one and the main one.

但正如你所说，这并不能完全反映全部情况。

But like you said, this doesn't capture the full extent of it.

因为很多情况下，原型开发变得更简单了，尝试新想法也更容易了，那些过去因为优先级太低而根本不会去做的功能，现在你都能一一实现。你本来有个愿望清单，现在因为太容易了，就全都做了，以前根本不可能做到。

Because a lot of this is it easier to prototype, it easier to try new things, making it easier to These things that you never would have tried because they're way below the cut line, you're launching a feature and there's this kind of wish list of stuff, now you just do all of it because it's so easy and just wouldn't have done it.

所以，真的很难谈论这个。

So yeah, it's really hard to talk about it.

然后还有另一方面，代码写得越多，你就得删除越多的代码。

And then there's this flip side of it, where more code is written, so you have to delete more code.

你必须更仔细地进行代码审查，并尽可能自动化代码审查过程。

You have to code review more carefully and automate code review as much as you can.

还有一个有趣的新产品管理挑战，因为你能发布太多功能，导致整体体验反而不够连贯，因为你可能只是在这里加个按钮、那里加个标签、再加点小东西。

There's also an interesting new product management challenge, because you can ship so much that it ends up not feeling as cohesive, because you could just add a button here and a tab there and a little thing here.

要构建一个包含所有你想要功能但缺乏任何组织原则的产品变得容易多了，因为你一直在不停地发布各种功能。

It's much easier to build a product that has all the features you want but doesn't have any sort of organizing principle because you're just shipping lots of stuff all the time.

我认为我们在这方面相当有纪律，确保所有抽象概念都足够清晰，即使某人只是听到功能的名字也能理解。

I think we try to be pretty disciplined about this and making sure that all the abstractions are really easy to understand for someone, even if they just hear the name of the feature.

我们有一个原则，我相信是Boris带给团队的，我非常认同：我们不希望有新的用户界面。

We have this principle that I believe Boris brought to the team that I really like, where we don't want a new user experience.

所有功能都应该足够直观，让用户一进来就能顺利使用。

Everything should be so intuitive that you just drop in and it just works.

我认为这为确保每个功能都极其直观设定了很高的标准。

And I think that's really set the bar really high for making sure every feature is really intuitive.

你们如何在对话式界面中做到这一点？

How do you do that with a conversational UI?

因为当没有一堆按钮和旋钮，而一开始只是一个空白的文本框时，你们如何思考如何让它直观？

Because when there's not a bunch of buttons and knobs and it's just a blank text box to start, how do you think about making it intuitive?

我们做了很多小细节。

There's a lot of little things that we do.

我们教用户可以使用问号来查看提示。

We teach people that they can use the question mark to see tips.

当 QuadCode 工作时，我们会显示提示。

We show tips as QuadCode is working.

我们会在侧边显示变更日志。

We have the change log on the side.

我们会告诉你，哦，有一个新模型发布了。

We tell you about, oh, there's a new model that's out.

或者我们在底部显示一个用于思考的通知区域。

Or we show you at the bottom, we have a notification section for thinking.

我认为我们只是通过一些微妙的方式向用户提示功能。

I think there's just subtle ways in which we tell users about features.

我认为另一件非常重要的事情是确保所有基础组件都定义得非常清晰。

I think the other thing that's really important is to just make sure that all the primitives are very clearly defined.

在开发者生态系统中，钩子具有共同的含义。

Hooks have a common meaning in the developer ecosystem.

插件在开发者生态系统中也有非常普遍的含义，我们要确保我们构建的内容与普通开发者听到这些词时立即想到的一致。

Plugins have a very common meaning in the developer ecosystem, and just making sure that what we build matches what the average developer would immediately think of when they hear that.

还有一种渐进式披露的方式。

There's also this progressive disclosure thing.

在QuadCode中每次运行时，你可以按Ctrl+O查看完整的原始转录内容，也就是模型看到的内容。

Any time in quad code when you run it, can hit control o to see the full raw transcript, the same thing the model sees.

我们只有在真正相关时才会向你展示这些内容。

And we don't show you this until it's actually relevant.