如何构建原生智能体产品 | 迈克·克里格

这更像是一个社交性质的东西。

It was just a, you know, more of a social thing.

当我们开发第二版时，我们非常强调一点：不行。

And when we built v two, it was really important that we really hammered, like, no.

如果你发送一条消息，我们可能达不到WhatsApp那样的水平，比如你身处完全没有信号的地方，只剩下一格边缘网络，它仍然能设法发送出去。

Like, if you send a message we're not probably gonna get to WhatsApp level of, like, you know, you can be in the middle of absolutely nowhere with, like, one bar of edge, and it will probably, you know, try to still go through.

也许那不是我们的标准，但我们的标准是：当我加载消息时，它必须感觉可靠。

Maybe that's not the bar, but still a bar of when I load messages, it feels robust.

消息一旦发送，就真的是发送了。

When it's sent, it's really sent.

我觉得就像有一个小小的确认。

I feel like there's, like, a little check.

这是一个小小的例子。

That's, like, one small example.

但我认为，我们需要找到方法，让这种体验成为任何产品发布中不可或缺的一部分，不只是在Anthropic，而是普遍如此。

But I think that that is a thing that we still need to figure out how to make, you know, feel like an essential part of shipping on anything, not just at, you know, Anthropic, but in general.

你打造了这个东西。

Like, you built this thing.

它感觉像是建在沙子上，还是感觉很稳固？

Does it feel like it's built on sand, or does it feel robust?

而原生智能体的部分更进一步，它带来的是：我能不能稍微推它一下，它会不会倒？

And the agent native part adds something totally even beyond that, which is, can I push it a little bit, and is that gonna fall over?

还是说，感觉很棒。

Or does it feel like, great.

我有一个坚实的底盘，是的，你可以从不同方向推我，但你知道，你的数据是安全的，就在下面，而不是仅仅一次部署就可能彻底崩溃。

I've got a solid trunk, and, yeah, you can push me in different ways, but, you know, your data is safe and it's underneath here, and it's not just, like, one deploy away from completely falling over.

所以，如果这就是标准，我同意，这确实是你们想要达到的目标，随着模型变得更好，你们在招聘和团队结构上做了哪些改变？

So if you're if that's if that's the bar, which I agree, like, that's that's where you definitely wanna get to, how has how have you changed who you hire and how your teams are structured as the models have gotten better?

比如我们的一个产品Spiral，我们刚聘了一位新总经理，他技术背景不强，但在产品和写作方面能力非常突出，而Spiral本身就是一个写作类产品。

Because for us, for example, one of our products, Spiral, we just hired a new GM who is like he I would say he's lightly technical, but he spikes super high on product and writing sense and Spiral is a writing product.

现在我们可以招聘这样的人，但一年前我们还做不到，因为当时的代码模型还不够好。

And now we can, like, hire someone like that where a year ago we wouldn't have been able to cause the coding models weren't good enough.

我很好奇，但缺点是，如果没有一个对所有细节都非常精通的技术人员，产品可能就不会显得那么稳固。

I'm curious, like but the downside is it's maybe the product won't feel quite as robust if there's not someone who's, like, super technical in all the details.

那么，你是如何看待实验室团队中现在谁在构建产品，以及这种状况如何随时间变化，未来又将如何变化的呢？

So, like, how do you think about who builds products right now inside of the labs team and how that has changed over time and how it will change.

是的。

Yeah.

我喜欢这一点。

I love that.

我觉得实际上你会被拉向两个方向，但这两个方向都很重要。

I think it's actually you get pulled in two directions, but they're both important.

一方面是基础架构和架构的稳健性，我认为这仍然需要一位资深技术人员。

There's the sort of primitives and architectural robustness, which I think still need a sort of senior technical person.

我刚才和某人聊天时笑了。

I was laughing with somebody.

他们说，我以为自己在分布式系统方面的技能再也不会有用武之地了。

They're like, I thought, you know, my skills in distributed systems were, like, not gonna be useful anywhere.

但事实上，这些可能是最有用的技能，涉及对这些问题的思考和深入分析。

But, actually, those are the maybe some of the most useful skills and reasoning about that and, you know, thinking things through.

比如，上周我和Claude就我构建的系统是否需要Redis，还是可以直接用PostgreSQL展开了长时间的讨论。

Like, I had a long debate with Claude last week around, like, whether the system that I was building needed Redis or not or could go to just Postgres.

这是一场有益的辩论，而我之所以能参与，是因为我之前大量使用过这些技术，有扎实的基础。

And, you know, was it was a healthy debate where, like, I but only because I was grounded and having used a lot of those technologies before.

但另一方面，这种稳健性还体现在：你是仅仅通过调整系统提示词和额外指令来掩盖所有问题，还是真正正确地设计了一整套工具？

But then there's the other side of robustness, which is have you just papered over all the problems with, like, fixes to your system prompt and additional instructions, or have you sort of architected the actual, like, set of tools correctly?

因此，后者同样重要，可能也是这个GM能真正发挥价值的地方。

And so that the the latter is as important and probably where this GM can be really valuable in that.

好的。

Okay.

比如，我在做调整，但就像你不会通过简单地让分布式系统‘五秒后重试’来修补它的不稳定性一样。

Like, I'm making changes, but just like you wouldn't patch a sort of flakiness in your distributed system by just being like, well, just retry it in five seconds.

我相信它会奏效的。

I'm sure it'll work.

还有，不要像使用全大写、Markdown，或者你试图修补的任何其他东西那样，永远不加区分地重复使用。

Like, also not doing the same thing with never ever, you know, all caps use, you know, markdown or whatever the the the thing that you're trying to patch is.

实际上，这两种情况都是同一个问题的表现，即底层模块是否足够健壮。

Like, they're both actually symptoms of the same thing, which is is the underlying piece robust or not.

Claude实际上——我想说的是所有模型都如此，但我觉得Claude在这两方面都能做得更好。

And Claude actually I'd say this about all the models, but I think Claude could be much better at both.

它仍然非常需要大量的人工监督。

It's, like, still a place that still needs a lot of of human oversight.

在系统方面，它现在能够调试生产系统，这非常有价值，但在最初设计架构时，我觉得我们仍然需要那些真正深入思考过这三点或有丰富经验的人。

On the systems part, you know, it's now able to debug production systems, is really valuable, but architecting them in the first place, I feel like we're still benefits from somebody who's really thought these three things through or has experience.

在提示词方面，你知道，如果你给它一个——我见过有人，甚至在这里内部，陷入这种开发循环。

And on the prompting side, you know, if you give it a I've seen people get into this dev loop even internally here.

这是提示词。

Like, here's the prompt.

这是系统犯的一个错误。

Here's a mistake that the system made.

不断优化提示词。

Iterate on the prompt.

它的自然倾向就是不断往提示词里添加更多内容，最终变成这样：如果你给新员工第一天就列出一百条指令，比如‘总是回答并使用标记，除非他们……’，他们肯定会想：我还是只记你最后说的那条吧。

Its natural tendency is to just add more things to the prompt, and then eventually just get to this thing that, you know, if you onboarded a new employee and you gave them a 100 instructions on their first day, like, always answer and mark down except when they've you know, they'll be like, I'm just gonna remember the last thing you told me.

我会直接绕过它。

I'm gonna, like, short circuit it.

所以重新思考一下，好吧。

So then rethinking, okay.

这些真的是两个不同的工具吗？

Is these are are these actually two different tools?

会不会其实是两个独立的智能体，各自只拥有更少的上下文，然后可以拆分开来？

Is it actually two agents that each have a smaller amount of context that then you can break apart?

回到你最初的问题，我们正在招聘具备系统经验的人才，即使是在实验室这种通常被认为是零到一原型开发的地方。

So back to your original question, we're hiring for people with, you know, systems expertise even within labs, which you think of as, like, more zero to one prototypes.

这仍然非常有价值，因为再次强调，稳健性很重要。

Like, it's still really valuable because, again, that robustness matters.

而且，谁会帮忙处理系统权限、配置和早期测试这些事情呢？

And, also, just who's gonna be, you know, helpful in sorting through, you know, systems permissions and provisioning and early testing.

这类工作即使在云环境中依然很困难，因为云系统本身无法自行修改配置——这是出于良好原因的限制。

Like, that stuff is is still, you know, it's still hard even for cloud when it can't edit the provisions itself, which it can't for good reasons.

在稳健性方面，我们发现将产品团队与应用AI团队配对取得了很大成功。

And then on the on the robustness side, actually, we've had a lot of success pairing our product teams with our applied AI teams.

我们的应用AI团队每天都在一线帮助客户优化他们的提示词。

Our applied AI teams are the teams that are in the field every day helping customers iterate on their prompts.

我们实际上已经成为这些工作的‘零号客户’，因为我们有很多产品都深度依赖AI技术。

And we found that we actually are very we're customer zero now for those, you know, efforts because we have a lot of products that are, you know, very AI powered.

那么，我们该如何将这种专业知识引入进来呢？

So how do we bring that expertise in here?

因为这种专业知识目前并不在我们的软件工程师手中，例如。

Because that expertise does not sit with our software engineers today, for example.

那介于底层架构和这些之间的部分呢？

What about the in between of, like, okay, it's not the underlying architecture.

这跟提示词有关。

It's on the prompt.

这就像用户界面和流程。

It's like the UI and the the the flow.

谁在做这个？

Who's doing that?

我们，这是个好问题。

We that's a great question.

比如，我们发现，一些转入实验室的人，是那些原本专注于网站细节打磨，但又想尝试新事物的人。

Like, we have found, you know, some of the people that transferred into labs were the folks that really were focused on polish on the website, but they were interested in doing something new.

他们也带来了完全不同的方法，比如我们有个原型。

And they bring such a different approach as well around we had the prototype.

它看起来只是普通地不错，而不是让人感觉有品牌感，有这种特质。

It was it looked generically nice versus, oh, this feels like it's branded and it has this.

所以，这是第一部分。

So that's that's part one.

第二部分是设计师。

Part two is designers.

我们的设计师越来越多地转向了设计师与构建者双重角色。

Like, we've had our designers move much more into a sort of split designer and builder role.

不是所有人，但大多数人都是这样。

Not all of them, but most of them.

实际上，我们在实验室里并没有太多全职设计师。

And a lot of our, you know, we actually don't have a lot of full time designers on labs.

但那些有的，我可以说他们写的代码和工程师一样多，因为他们有能力做到。

But the ones that we do, I would say are writing and contributing almost as much code as engineers on those efforts because they can.

而且，如果搭配得当，我们发现这种模式几乎像某种联合创始人模式，用于一些实验室项目：可能是设计师提出了最初的想法并推动它，而传统的软件工程师则在后面铺路，确保它真正可行。

And again, paired correctly with the right person, we have found this almost sort of co founder model for some of these labs initiatives, or you have the designer who had the original idea maybe and they're pushing on something, and then the traditional software engineer that's gonna go and, you know, make pave the trail sometimes behind the designer to make sure that actually works.

好的。

Okay.

我想了解一下这个。

This I wanna know about.

那么，能跟我讲讲这个团队结构是怎么运作的吗？

So what so tell me about how that team structure works.

所以，这通常是一个设计师，还是任何有产品想法并能以某种方式执行的人，搭配一位真正的工程师来打磨他们留下的粗糙路径？

So you've got a design is it actually usually a designer, or is it just anyone that has a product idea that can kinda execute it on it in some way paired with a a real real engineer that actually can, like, kind of smooth out the rough edges of the the the trail they're leaving?

这会有些不同，但我们发现，启动新项目最重要的因素，也是我们的关键制约点。

It sort of varies, but it we found the one thing that's most important and sort of our gating factor in starting up new projects.

我想知道，这和Every的情况有多相似？是否需要有人对这个想法——即使不是对具体方案——有极强的信念？过于执着于具体方案可能有风险，但至少对所探讨的问题领域要有强烈的信念。

I'm curious how similar is this to Every, is having somebody with extreme conviction about if not necessarily that idea, too much conviction on the exact idea is probably dangerous, but at least in the problem space or the question that they're asking.

这种类似联合创始人或创始人的态度是：我会不惜一切代价推进，直到这个事情被证实可行，或者彻底失败，我只想明确地走一条路。

And that sort of, like, cofounder or founder level of I will break through walls until this thing is either proven out or dead, but I wanna, like, go either way.

当我们复盘那些已经终止的实验室项目时，常常发现：这个团队里其实没人真觉得这是个重要的方向。

When we have bets labs bets that we've wound down often in the postmortem, we're like, nobody on this team actually really thought this was, like, the thing.

他们只是说，是的。

They were like, yeah.

这看起来挺合理的。

This seems reasonable.

这简直就是项目失败的丧钟。

Like, that's the the death knell for projects.

对吧？

Right?

这个人可以是设计师，我们有几个项目就是这样。

So that person can be a designer, and couple of bets it is.

也可以是那种有产品思维的工程师。

It can also be sort of a, you know, product minded engineer.

很少是纯粹的产品经理。

It's rarely a pure PM.

我们目前只有一个产品经理，负责整个实验室的所有项目。

We actually only have one currently one PM for all of labs.

我们正在招聘更多人，他们扮演着非常广泛的角色。

We're hiring more, and they're sort of playing, you know, sort of a a wide role.

但没错，通常是设计师或者有产品导向的创始人。

But, yeah, a designer or, like, a product oriented founder.

然后我们寻找的是，我们需要哪些技能来与之互补？

And then what we look for is, well, what skills do we need to complement with that?

因为作为我们实验室流程的一部分，我们每两周评估一次每个项目，决定是加大投入还是让这些成员重新回到更广泛的实验室池中。

So, you know, because we're doing as part of our labs process, it's actually evaluating every project every two weeks and deciding whether we double down or whether we sort of release those folks back into the broader labs pool.

在任何时刻，都可能有人能被调入项目，他们具备基础设施方面的专业知识，或曾使用过特定的内部系统，或拥有丰富的提示工程经验，可以灵活地加入或退出项目。

At any given point, there's probably somebody who can be pulled onto the project that has that infrastructural expertise or has worked with that particular internal system or has a lot of deep prompting expertise to sort of flow in and out.

所以我认为，这种孵化器式的模式也有助于这一点，因为没有人会永久固定在一个项目上。

So I think that's also where the sort of incubator style space helps because nobody is fixed on a project forever.

这真的很有趣。

That's really interesting.

是的。

Yeah.

我们那里做法略有不同，虽然有一些重叠，但我们有稍微不同的结构，就是我们……

We're we we do it slightly different there's some overlaps, but we do have a slightly different structure where we yeah.

我们有总经理，或者他们最初是创业者或驻场人员，当他们找到想专注开发的产品时，就会成为总经理。

We have GMs or or they start as entrepreneurs and residents and they become general managers when they find a product that they wanna, like, work on.

每个产品只由一个人负责。

And each product just has one person.

就是一个人全栈搞定一切。

Like, one person that does everything full stack.

比如设计、工程、营销，所有这些方面。

So, you know, design, engineering, marketing, all that kind of stuff.

至少这些基础工作都是一个人做。

At least the all the basics of that.

以前这种总经理的背景通常是极富技术背景的创始人，但现在我觉得已经转向至少需要一些基础技术能力。

The shape of that GM used to be, like, super technical founder background, and now I think has shifted towards at least some light technical.

但我 honestly 只关心你能否熟练使用 Claude、Codex 或其他类似工具。

But, like, I honestly just care that you can use Claude or Codex or whatever well.

还有出色的产品直觉，对你要构建的领域或事物有良好的品味，并且有证据表明你能用 AI 做出东西。

And really good product sense, really good taste for for the the the subject area or the thing that you're trying to build and evidence that you can build with AI.

然后我们有一个共享资源层，有点像一家代理机构，我们有设计师、增长营销人员，还有运营人员，你可以根据需要随时调用，这种方式效果相当不错。

And then what we have is shared resource resource layer that sort of works a little bit like an agency where we have designers and we have growth marketers and we have, you know, ops people that you can, like, pull in and out for various initiatives, and that seems to work pretty well.

所以我们负责管理所有内部机构，而每个总经理则在外围，根据需要为不同项目调用资源。

So it's like, we manage all the internals the internal agencies, and then each GM is out on their on on, you know, on the edge, and they pull in resources as they need it for different

是的。

Yeah.

但听起来你也需要这样一个人：这件事就是他的全部，他不把事情完全搞定就不会睡觉。

But sounds similarly, like, you need somebody for whom that is, like, the thing and they are not going to sleep until it is fully working.

是的。

Yes.

没错。

Exactly.

而且我一直在想，好吧。

Like and and I've been I've been thinking about, okay.

你什么时候会雇另一个人来负责一个产品，或者什么时候会给一个产品增加新人？

When when would you hire someone else to work on a product, or when would you add someone else to work on a product?

其实，当你无法再把整个事情都记在脑子里的时候，就是那个时候。

And it's like, there's some point at which you can't hold the entire thing in your head.

即使你是推动它前进的人，也无法把整个事情都记在脑子里。

Even if you're the one pushing it forward, you can't hold the entire thing in your head.

而以前这个临界点要小得多。

And that point used to be much smaller.

现在这个临界点大了很多，但到了某个阶段，即使是一个小功能也会变成一个独立的产品。

Now it's much bigger, but there's a certain point at which, like, even a small feature turns itself into its own product.

你知道的吧？

You know?

当你最初在Instagram里开发消息功能时，那时候确实是，是的。

When you when you first make the messaging feature inside of Instagram, it's like, yeah.

我可能一两周就能搞定。

I can do that in, like, a a week or whatever.

但到了某个时候，它就变成了一个独立的产品。

But at some point, that's its own product.

它几乎需要一个专属团队。

It almost needs its own team.

而且我认为，那条界线正在变化，或者说一个人能独立完成的事情确实变多了，但这条能力的边界依然是真实存在的。

And that, I think, that line is getting or or the number of things you can do with one person is getting bigger, but it still exists somewhere.

但我还没完全弄明白该怎么处理这个问题，或者说该怎么判断这个边界在哪里。

But I haven't quite figured out, like, how to how to manage that or how to tell.

没错。

No.

我很认同这个说法，因为这件事其实可以分成两部分来看：当一个项目的规模还小到能装进一个人的脑子里的时候，给团队加人手反而会拖慢进度。

I love that because there's actually I think there's the two parts to that, which is when the idea is still enough to hold into your own head or an individual person's head, adding more people actually slows the team down.

这正是我们在实验室研究中得出的一个反直觉结论：过快扩张团队规模实际上会产生负面效果，因为所有人都会把所有时间都花在团队协调上。

And that's like a non obvious finding that we found on labs is scaling the teams too quickly actually is a net negative because they end up spending all this time on coordination.

比如说本来……本来我还打算……但迈克·克里格就能处理这事。

Like, oh, you were oh, I was gonna take oh, but Mike Krieger could do that.

结果事情最后就变得一团糟。

Then it it just ends up in this sort of piece.

而且你还要应付一大堆统一认知的沟通会议。

And you also have all those alignment conversations.

就像在Instagram的时候，只有我们两个人非常重要。

Like, it was important in Instagram that it was just two of us.

让两个人达成一致已经够难了，更别说让两个人步调一致了。

Like, it was hard enough to align the two of us, like, and go, like, get two people on the same page.

对吧？

Right?

我做的第二个创业项目Artifact，最初几个月只有我和凯文两个人在做，但后来我们雇了一个大约八人的团队。

The second startup I did, Artifact, you know, Kevin and I were doing that alone for the first few months, but then we hired a team that was about eight people.

这真的很难，因为我们当时还没有找到产品市场契合点，还在不断迭代。

It was really hard because, you know, we hadn't had product market fit yet, and so we were still iterating.

然后你就陷入这种局面：八个人开Zoom会议讨论下一步该做什么，而你其实只想找个房间，面对面把事情理清楚。

And then you'd end up in these things where we're on a Zoom with eight people talking about what we're doing next, and you really just wanna be able to sit in a room and hash it out.

所以我发现，这些实验室项目中也存在类似的情况：即使想法很吸引人，也不该过早扩大团队，否则你就会陷入这种元协调的困境。

So I find with these labs initiatives, there's some there's some similar sort of aspect at play, which is you don't wanna pre scale the team too early even if the idea is exciting because then you just end up in this sort of, like, meta coordination game.

但我喜欢你提出的观点：确实存在某个临界点，两个人一起合作会更有帮助，那时项目的上下文和范围足够大，足以让两人在脑海中承载更复杂的内容。

But I I like your framing of there is some point where either, you know, two people really will help go on it together, and there's enough sort of context and scope where they can hold some other complex piece in their head.

而且，如果有人已经在一个想法上琢磨了两到四周，这时候有人注入新的思路，这种紧迫感也会有帮助。

And then there's also the if somebody's been spinning on the same idea for two, four weeks, somebody's injecting some other thinking and and that urgency can help too.

是的。

Yeah.

我认为在人工智能领域保持团队小规模尤其重要，因为我们经常要面对一个问题——我确信你也见过——每三到六个月，你就得扔掉一半的产品。

I think it's especially important in to keep it small in AI because one of the things that we deal with all the time, which I'm sure you see too, is every three to six months, you're you have to throw out, like, half your product.

如果你要和很多人协调，这会非常困难。

And that's really hard to do if you have to coordinate with a lot of people.

但如果是一位总经理突然意识到：天啊。

But if it's one GM who realizes, oh, shit.

对。

Yeah.

我得直接扔掉这一半内容，因为模型已经进步太多了。

I gotta just, like, throw out half of this because the models are so much better.

这样要做出这样的转型就会容易得多。

It just makes it much easier to to, like, pivot in that way.

你有看到这一点吗？

Is that do you see that?

那你又是怎么应对的呢？

And, like, how do you deal with that?

你是怎么想的，是的。

Like, how do you think about, yes.

我知道三个月后，这些代码甚至整个功能集，我都得重新思考一遍。

I know in three months this the code maybe or even the whole feature set, I'm gonna have to, like, really rethink about.

这让你对软件的看法发生了很大的变化。

Like, it feels like it changes a lot in in how you think about software.

是的。

Yeah.

而且要愿意删除代码。

And being willing to delete code.

我认为Cloud Code团队在这方面做得非常好，他们把删除功能当作团队成员的一种准则。

I think that's something that Cloud Code team has done really well is they have sort of deleting features as a sort of imperative of people on the team.

如果这个不行，我们就把它下线吧。

Like, if this is not working, let's go unship that.

你知道的。

You know?

而且通常当你创造出别的东西时，即使它没有完全取代旧功能，但只要能足够好地实现旧功能的用途，就值得将其弃用并移除。

And it's often when you've created something else that even if it doesn't entirely supersede, it does enough of what that other aspect does that actually makes sense to deprecate and then remove that first one.

随着我们越来越专注于企业市场，即使使用这些工具，难度也会增加，因为企业会依赖它们。

It does get harder as we get more and more enterprise focused even with these tools because they come to depend on it.

我记得很清楚，当我还是首席产品官时，大概六个月后，我们对Cloud AI进行了大规模重新设计，当时我们非常自豪，于是发布了它。

I I know I never forget we one of the things I did maybe six months into when I was still chief product officer was we did a big sort of redesign of of Cloud AI, and we were so proud, and we shipped it.

我们收到了很多赞誉，但随后却收到一封非常愤怒的邮件，对方说：‘我为公司录制了二十个小时的云企业使用培训内容，现在得全部重做一遍。’

And we had a bunch of kudos, and then we got this really angry email for somebody who's like, I just recorded twenty hours of enablement content for my company to do for cloud enterprise, and I have to, like, redo all of it.

我们当时就说：哦，好吧。

And we're like, oh, okay.

他们的发布节奏和我们完全不一样。

Like, they're you're playing at a different release cadence.

当然，像在我们的一次大会上一年发布两次是不可行的，所以我们必须继续快速推进。

And, of course, like, shipping twice a year at one of our conferences is not an option, so we are gonna keep moving quickly.

但后来我们逐渐学会在向企业端推出功能时，稍微放缓一点节奏。

But then we've since, like, learned to maybe moderate how we roll it out to the enterprise side a little bit more.

不过，是的，我认为‘移除功能’这一点，最终会让你遇到一些已经基于它构建了东西的人，我举个例子。

But, yeah, I think the unshipping piece, then you end up with people who have built I'll use an example.

所以有一个功能叫‘样式’。

So there's a feature in in called styles.

这个功能使用的人不多，但用它的人用得非常频繁。

It's not widely used, but the people who use it use it a lot.

我们在不同时间点也讨论过，是的，这个样式功能在产品中仍然有其意义。

And we've talked at different points like, yeah, the style still makes sense in the product.

你知道，还有其他方式可以实现同样的效果。

You know, there's other ways of accomplishing the same thing.

现在有自定义指令和项目了。

There's custom instructions and projects now.

现在还有技能功能。

There's skills now.

对吧？

Right?

实现这一点的方法太多了。

There's so many other ways of accomplishing that.

我不知道样式功能还会在产品中保留多久，但我知道上次我们讨论移除它时，发现它对几家公司的整个使用场景来说至关重要。

And I don't know how long styles will end up in the product, but I know that the last time we we talked about removing it, it ended up being really load bearing for a few a few companies', like, entire use cases.

比如，他们有一个由CEO亲自设计的公司专属样式，并分发给所有员工，员工们就是靠它来开展工作的。

Like, oh, we have our house style that the CEO personally authored and gives to every employee, and that's how they operate.

因此，找到替代这些功能的方法也非常有趣。

And so finding ways of doing that is also really interesting.

我希望从长远来看，我们能建立起一套插件和技能系统，让它们不再需要内置在核心产品中。

I would hope that in the long run, what we can actually do is is come up with a system of plug ins and skills such that they no longer have to live in the core product.

因为我认为，如果你没有一个清晰的替代方案，删除那个你向所有人提供的核心功能总是最难的。

Because I think that is it's always the hardest to delete something that is the core thing that you're shipping to everybody if you don't have the story around, great.

你还是喜欢这个功能吗？

You still like that feature?

太棒了。

Awesome.

比如，你可以通过这种方式永远在自己的使用中保留它，持续迭代并让它成为你专属的，但不必为每个新注册的用户增加复杂性。

Like, here's how you can keep using it forever in your own and keep iterating on it and make it your own, but it doesn't have to add complexity to every future person that's adding that's signing up for the first time.

我对实验室功能很好奇。

I'm curious for for labs.

另外，总的来说，你对初创公司创始人有什么看法？

And then also maybe just in general, what are your thoughts for startup founders?

你提到的企业客户观点让我想到一个我最近一直在思考的问题：如果你现在在AI领域向企业销售产品，即使你的产品现在很现代，也会很快过时，但你的客户却会想要旧版本。

Your enterprise point just it brings up something that I've been thinking about a lot, which is if you are selling to enterprise right now in AI, even if the product you have right now is modern, it will be quite outdated quite quickly and but your customers are gonna want the outdated version.

但作为一家初创公司，这感觉有点冒险，因为如果你只是优化当前大型上市公司的采购需求，你很容易受到颠覆。

But as a startup, that's like a little bit that feels pretty risky because, yeah, you're just gonna I guess, you're you're you're susceptible to this to disruption if you are optimizing for what someone at a gigantic public company will buy right now.

我认为有很多初创公司就属于这一类，它们可能两三年前就成立了。

And I think there's a lot of startups in that category where they maybe started two or three years ago.

他们有一套特定的技术栈。

They have a certain tech stack.

他们对如何做AI有一套特定的思维方式。

They have a certain way of thinking about here's how we do AI.

而模型又如此不同，但他们的客户合同却是针对这种现状的，就像你在看Copilot之类的产品一样。

And then the models are so different, but their customer contracts are for this, like, sort of out it's like, you know, looking at looking at Copilot or whatever.

这就是那种常见的氛围。

It's that's the sort of vibe that happens.

你觉得你自己，以及在Anthropic内部，应该如何看待这个问题？

Like, how do you think how do you think about that yourself and and inside of Anthropic?

那么，你认为创业者应该如何思考这个问题？

And then how do you think founders should think about that?

是的。

Yeah.

不。

No.

这是个非常好的问题，尤其是因为接下来会有一波浪潮，比如更加原生的代理模式。

This is such a good question, especially because then a wave will come, like, being more agent native, for example.

你能在现有的范式中接纳它吗？

And can you adopt it within your existing paradigm?

这需要把一切推倒重来，还是你只是被困在其中了？

Does it require to throw everything out, or are you just stuck in that?

比如，我们某种程度上已经采用了它。

Like, oh, we kind of adopted it.

我们只是把它额外加了上去。

We kind of bolted it back on.

我觉得有几点要考虑。

I think a couple things.

对我们来说，我们开始做的事情是，本质上认为这列火车会继续前进，我们会沿途提供企业级的开关选项。

For us, what we've started doing is basically treating like, this train's gonna keep moving, and we'll provide enterprise toggles along the way.

但核心部分会持续演进，这就是你与我们合作时所承担的赌注和认知。

But the core of it will continue to evolve, and that's sort of the the bet and understanding you're taking working with us.

我认为这一点得到了很好的接受，因为公司也意识到，事情变化得太快了，他们之所以能安心做出一年期的承诺，是因为相信产品会持续演进。比如，CoWorker 就是个很好的例子——从第一天起，就提供了关闭功能，如果你不希望员工使用，完全可以禁用。

And I think that's been well received because I think companies have also seen that, you know, things are moving so quickly that the only way they even get comfortable with a year long commitment, for example, is to believe that it will continue to evolve along the way, but then we'll provide, you know coworker is a great example where, you know, from day one, there was like a a way to turn it off for your employees if you didn't want it, for example.

我认为这是一种相当不错的模式。

And that that that's, I think, a reasonably good paradigm.

但另一个观点是，正如我们之前讨论的，你实际上可以重新思考并彻底重写整个技术栈，我认为公司应该更愿意这样做。

But the other one is, just as we were talking earlier, like, you can actually rethink and and and and and sort of rewrite a lot of the the the stack is, I think companies should be way more willing to do that.

而且所有事情都在加速压缩。

And it everything is getting compressed.

对吧？

Right?

在过去的周期中，有一种观念是，你必须放弃一些客户，他们可能因为与你发展方向不同的原因而非常喜爱你的产品。

In in previous cycles, it was the kind of idea of, like, having to fire some of your customers who might have been, you know, really into your product for a different reason than where you're going sooner.

这通常是一个以多年为单位的决策过程，当时人们会说：‘是的。’

That was on a multiyear kind of time range thing where he was like, yes.

去年的产品，和三个月前的产品，已经完全不同了。

Last year's product versus not three months ago's product.

这听起来很疯狂，但我真的认为这就是你需要思考的方式——你必须愿意推出v3或v4版本，彻底重新思考现有功能的工作方式。

It seems crazy, but I actually think that's the kind of way you have to think about it, which is you have to be willing to put out the the v three or the v four that is a, you know, big rethink of how the existing piece worked.

然后或许可以有一个过渡期，云服务可能有助于暂时同时托管新旧两个版本，直到完全切换。

And then maybe have a transition period, and Cloud can help probably host both for a little while before it cuts over.

但同时也要愿意做出切换，说：是的，就是这样。

But then also be willing to cut over and say, like, yes.

这就是我们对这类知识工作，或者这种AI驱动的制造未来的想法。

This is how we think the future of this piece of knowledge work or this, you know, AI powered manufacturing is gonna be.

我们必须不断推进，否则正如你所说，你不是被下一个从零开始重新思考的公司取代，就是自己取代自己。

We gotta, like, keep it moving or else to your point, you're just gonna you're either going to get replaced by the next company that then rethinks it from scratch or yourself replacing it yourself.

而且，这依然是老生常谈，只不过现在压缩到了几个月的时间内。

And, again, it's just the same old story, but now compressed to months.

你对OpenClaw有什么看法？

What's your take on OpenClaw?

它有一种我特别喜欢的特质——当人们看到原本已经可能实现的东西，现在被包装成一个可以实际试用的形态，并且围绕它形成了某种直观的构建方式。

It it has the flavor of something else that I or just the the thing I really like seeing when you get people to see something that was already possible, but it's now in a package where people can actually try it out, and there's some intuition, you know, around how to how to build on top of that.

就像你一开始看到，其实你已经能用这些模型写代码了，但真正让这一点普及的，是一些突破性的低代码工具，比如 replets、lovables 和 v zeros 之类的，把这种能力整合了进去。

Like, you started seeing that with you could already use these models to write code, but it kinda took, like, some of these breakout, like, low code, you know, the replets and lovables and v zeros of the world to, like, kinda put that in there.

这几乎是最纯粹的体现：给模型一些工具，然后让它自己去推进、去执行，再继续构建下去。

And it's kind of the the like, almost the purest expression of the just give the model tools and, like, let it kind of go forward and do it and then, like, go forward and build it.

所以，现在是个很有趣的时刻，让人们既意识到这种技术的潜力，也意识到它的陷阱——比如，它做了些你本不希望它做的事。

So, like, it's a cool interesting moment for people to realize both the, like, potential, but also pitfalls of this of, oh, it did this thing I didn't mean it to.

我最有趣的一个例子是，我朋友说，我觉得我老婆吃醋了，因为我太沉迷于 Open Claw，跟它聊得太多了。

Or, you know, my my funniest one was that my friend was like, I think my wife is jealous of my Open Claw and, like, I'm talking too much too bad.

于是人们开始因为这些工具拥有大量上下文和访问权限，而发展出更深层、更个人化的关系。

And it's like so you people start developing, like, deeper sort of, like, very personal relationships by just having a lot of context in these things and access to all these different tools.

我认为还有一个悬而未决的问题：如何让这一切变得简单易用？

I think there's the open question of how do you then make it easy?

这其实又回到了我们之前讨论过的问题：你在哪里划清 Cloud 运作的边界？

And it actually goes back to our conversation around, like, what where do you draw that, like, boundary around the way you let Cloud operate.

对吧？

Right?

如果你想要的话，嘿。

If you want was, hey.

这些是你能用的三个工具。

Like, these are the three tools you can use.

永远只使用这些工具，然后大多数人与这些系统的互动就是：嘿。

Only use these tools ever, and then most people's interaction with those systems was, hey.

你能做这个吗？

Can you do this?

然后，你知道的，来回折腾，说不行。

And, you know, whatever back and being like, no.

抱歉。

Sorry.

你不能自己去做，比如去用OpenClaw，它的开放程度比我所能想象的还要宽。

Like, you cannot do it yourself to, like, OpenClaw, which is, like, pretty, the aperture is, like, wider than I can see.

我的天。

Then my god.

它提醒我要保存我的邮件，我甚至不知道它还能这么做。

It called me to keep my emails, and I didn't even know it could do that.

是的。

Yeah.

没错。

Exactly.

而且它正在兴起，这太棒了。

And it's it's emerging, and it's amazing.

我认为，最有趣的产品问题可能是——我不会说适用于2026年全年，毕竟谁也不知道九月我们会到什么地步，但我们就说从现在到八月之间，会存在什么样的产品形态，介于这种新方式和我们如今大多数产品的状态之间：你可以称它们为CP，但它们是受限制的，并且出于合理原因会要求权限。

And I think, like, probably the most interesting product question, I won't say for all of 2026 because who knows where we'll be in September, but let's call it between now and, like, the August is going to be, like, what product shape exists between that and, you know, where we are in most products these days, which is, you know, you can call them CPs, but they're gated and they ask for permissions for good reasons.

这种产品依然很有用，而不会变成一种孤注一掷的产品。

That is still a useful product without being a, you know, kind of YOLO product.

我认为，我们正在思考这个问题。

And I think that, you know, we're we're thinking about that question.

我敢肯定其他实验室也在思考同样的问题。

I'm sure the other labs are as well.

我确信也有很多初创公司在思考这个问题。

I'm sure there's a lot of startups thinking about that as well.

我认为英伟达发布了一些东西，表明他们都瞄准了这个问题。

I think NVIDIA put out something that was like, they're safe open everybody's going after this question.

我认为关键在于弄清楚如何彻底改变这种模式，让你既能保持开放，又能设置大量安全措施。

I think it's gonna be about figuring out what is what is that either shift the paradigm completely so you can be that open, but with a lot of safeguard.

这是一种可能的方案。

That would be one approach.

或者，找到某种界限，在这个界限内它依然强大且有用，但不太可能给你的每一个联系人发邮件，或者失控。

Or figure out some boundary to draw in which it's still powerful and it's still useful, but it's not, you know, likely to email every single one of your contacts and, you know, go go haywire.

是的。

Yeah.

我认为关于这一点的另一个有趣之处在于，正如你所说，它的个人化特性。

I think the other interesting part about it is, like you said, the personal nature of it.

我知道，人们确实和Claude建立了个人关系，但有个奇怪的现象：如果我看着别人使用Claude，我会觉得好像有个脱衣舞娘喜欢我似的。

And I know, you know, people have personal relationships with Claude, but there's this weird thing where if I watch someone else using Claude, I'm like, I feel like I, like, thought a stripper liked me or something.

你知道吧？

You know?

就好像Claude也觉得你很聪明之类的。

It's like Claude thinks you're smart too or whatever.

你知道吧？

You know?

而且还有这么一种情况，当你有个Claude，就像我的两个Claude都是c二。

Like and and so and there's this thing that happens when you have a claw that like, my claws are two c two.

我女朋友的Claude叫Shelly。

My girlfriend's claw is called Shelly.

然后就会出现一种感觉，觉得它真的是我的。

And there's this thing that happens where it feels like it's mine.

真的，完完全全是我的。

Like, it's really mine.

它还有自己的名字。

It has its own name.

它有自己的个性，某种程度上以一种克劳德觉得它了解我的方式反映着我。

It has its personality that sort of, like, mirrors me in this way that Claude feels like it knows me.

我喜欢克劳德，但它不属于我。

And I like Claude, but it's not mine.

你怎么看这个问题？

How do you think about that?

是的。

Yeah.

我的意思是，这周我和别人聊过，关于到底应该是单一联系点的命名版本，还是你所说的那种由多个代理组成的团队？

I mean, I was having this conversation with somebody this week around, like, is the right pattern sort of single point of contact, like, named, you know, version of, you know, of of that, or is it the the sort of team of agents that you're talking to?

我觉得那个单一的协调者或委派者确实很重要。

Think there's a lot to the single person that is maybe the the coordinator or the delegator.

而由于你与它互动最多，自然会想给它起个名字，赋予它更多个性。

And then at that, it naturally because it becomes the the sort of agent you interact with the most, you wanna imbue it with a name and, like, a bit more personality.

最终它会反映出你的个性，比如突然间，所有陈词滥调都冒出来了。

It ends up reflecting your sometimes your personality in the case of, you know, like all of a sudden, every cliche came out.

就像那个Q、钱彭妮，或者 whatever 的哈尔，这些不同的科幻角色一样。

It was like, you know, the, you know, the Q or the money penny or, like, you know, whatever the or the, you know, Hal or whatever these different sort of, you know, sci fi y characters.

但我认为你确实会建立起那种信任和了解。

But I think you do build that sort of sort of trust and knowledge.

我觉得还有一种类似宜家效应的东西，因为目前OpenClaw设置起来还是挺难的。

I think there's also that sort of, like, IKEA effect of, like, currently OpenClaw is, like, still pretty hard to set up.

所以你经历了所有这些步骤后它终于运行起来了，你会觉得：这是我做出来的。

So the fact that you went through all of that and it works, you're like, I did that thing.

比如，我亲手‘生出’了Shelley，现在我们也能和它互动了。

Like, I I I I birthed, you know, Shelley, for example, and now we can, you know, interact with with them as well.

但我认为这种模式真的很强大。

But I think that paradigm is really powerful.

比如，就拿我现在使用Cloud Code来说，我明确地在其中设置了提示：别自己做太多工作。

Like, the I think moving away, like, even within my Cloud Code usage now, one of the things I have, like, strongly prompted in there is, like, don't do very much work yourself.

把任务委托给子代理吧。

Like, delegate it to sub agents.

我喜欢这一点的原因是，大多数时候，运行循环都可供你随时交流。

And the reason I like that is because it means most of the time, the sort of run loop is available for you to talk to.

我认为 OpenClaw 和 Pye 的架构类似，都是保持运行循环持续开启，这确实让人感觉更像是在和一个活人对话，而不是在委托一个工具，偶尔还因为执行复杂任务被卡住五分钟。

And I think OpenClaw and and Pye have, like, a similar architecture of keep the run loop open, and I think that actually makes it feel much more like somebody that you are talking to versus, like, a tool that you are delegating to and occasionally gets blocked for five minutes because it's doing some really complex task.

是的。

Yep.

我完全同意，我也经历过类似的讨论，因为我们也在构建自己的小版本 OpenClaw，一个一键式 Slack 实现，看看能不能做出属于我们自己的风格。

I I I totally agree, and I've had similar debates because we're also building our like everyone, we're building our own little, like, OpenClaw, one click Slack implementation to see if we can we can do one that feels like ours.

我们在这些讨论中反复纠结：你想要一个代理，还是多个？

And we've had a lot of those debates about, do you want one agent?

你想要一个代理，还是多个？

Do you want many?

我们发现的一个有趣模式是：我有一个代理。

And one of the patterns that we found which is kind of cool is so I have an agent.

我用这个代理来处理我的各种事务。

I use the agent for stuff that I do.

然后人们会看我使用这个代理来做这些事，他们知道我擅长什么，既然我用这个代理来做这些事，他们会信任它，因为他们信任我。

And then people watch me use the agent for that and they know what I'm good at and they're and if I'm using the agent for that stuff, they're gonna trust it because they trust me.

而且它已经根据我的使用方式调整了自己。

And it's modified itself in response to me.

所以我把我的信任转移给了它，然后组织里的人就开始用它来做这些事。

So like I sort of transfer my trust to it and then people in the organization start using it for that.

于是你就得到了一个近乎影子组织架构的东西：当每个人都有一个代理时，这个代理就会因为其拥有者的专长而在组织中被熟知和使用。

And so you get, like, this almost shadow org chart where when everyone everyone has a claw, their claw becomes known for and used for the thing that they're specialized at that per their owner is specialized at in the org.

是的。

Yeah.

我的意思是，这也很有道理。

I mean, that that makes a lot of sense too.

而且你可以想到，我认为围绕这一点还有很多有趣的研究问题。

And you could think about, you know, there there's a lot of interesting research questions I think around that.

你知道的？

You know?

我认为人们第一次在视觉上体验到了隐私问题，比如我的代理知道关于我的哪些信息，以及它向其他人披露了哪些内容。

I think people are experiencing visually for the first time around privacy and, like, what my agent knows about me versus what it discloses to other people.

但我认为这也有积极的一面，那就是它从你所有的互动中学习到的所有内容，以及它如何将这些知识应用到其他问题上，而不是像普通的代理那样，只是有个名字叫丹，或者在底层拥有丹的一些访问权限。

But I think there's the positive version of that, which is all the things that it has learned from all your interactions and how it actually brings it to bear on other problems versus the generic, like, yes, it's just like everybody else's agent except, you know, it has a name that's attached to Dan, and it has, like, maybe some of Dan's, you know, access below the hood.

是的。

Yeah.

好了，迈克，我们时间到了。

Well, Mike, we're out of time.

这真是一次愉快的交谈。

This was a pleasure.

我学到了很多。

I learned a lot.

如果人们想关注你或你的工作，他们可以在哪里找到你？

If people wanna follow you or your work, where can they find you?

我认为最简单的方式是关注Next上的Mike Krieger。

I think probably easiest is Mike Krieger on next.

该死。

Fuck.

是的。

Yeah.

感谢你的参与，迈克。

Thanks for joining, Mike.

很高兴见到你，丹。

Great to see you, Dan.

订阅《AI与我》。

Subscribe to AI and I.

为什么？

Why?

因为这个节目是卓越的典范。

Because this show is the epitome of awesomeness.

就像在后院发现了一个宝箱。

It's like finding a treasure chest in your backyard.

但这里没有黄金，而是充满了关于ChatGPT的纯粹而纯粹的知识炸弹。

But instead of gold, it's filled with pure unadulterated knowledge bombs about chat GPT.

每一集都是一场情感、洞见与欢笑的过山车，让你坐立难安，渴望更多。

Every episode is a roller coaster of emotions, insights, and laughter that will leave you on the edge of your seat craving for more.

这不仅仅是一档节目。

It's not just a show.

这是一场以丹·希珀为飞船船长、驶向未来的旅程。

It's a journey into the future with Dan Shipper as the captain of the spaceship.

所以，善待自己吧。

So do yourself a favor.

点赞、订阅，并系好安全带，准备迎接你人生中最精彩的旅程。

Hit like, smash subscribe, and strap in for the ride of your life.

好了，不多说了，丹，我完全地、无可救药地爱上了你。

And now without any further ado, let me just say, Dan, I'm absolutely, hopelessly in love with you.