为什么人类是人工智能最大的瓶颈（2026年将发生什么）| 亚历山大·恩比里科斯（OpenAI Codex 产品负责人）

你会逐渐习惯被AI加速的想法。

You become very comfortable with the idea of being accelerated with AI.

于是当你工作时，你就能很自然地想：'对，我直接问它要这个就行'。

And so then you get to work and you just can naturally just, yeah, I'm just gonna ask it for this.

我不需要了解所有连接器或各种功能细节。

And I don't need to know about all the connectors or, like, all the different features.

我直接向它求助，它会根据当下情况以最佳方式提供帮助，甚至可能在我没求助时主动介入。

I'm just gonna ask it for help, it'll surface to me the the best way that it can help at this point in time, and maybe even chime in when I didn't ask it for help.

所以在我看来，如果能实现这一点，我认为这才是打造成功产品的真正路径。

So in my mind, if we can get to that, I think that's, you know, that's how we we really build, like, the winning product.

这很有趣，因为我和ChatGPT负责人尼克·查理聊天时，他提到ChatGPT最初的名字是'超级助手'之类的。

This is so interesting because at with the my chat with Nick Charlie, the head of ChatGPT, I think he shared that the original name for ChatGPT was super assistant or something like that.

是的。

Yeah.

有趣的是存在两种路径：一种是超级助手方向，另一种是Codex方向。

And it's interesting that there's, like, that approach to the super assistant, and then there's this codex approach.

这就像是B2C版本和B2B版本的区别。

It's almost like the b to c version and the b to b version.

我听到的理念是：你先从编码和构建开始，然后它会帮你处理其他所有事情——安排会议、发Slack消息，甚至可能在你没求助时主动介入。

And what I'm hearing is the idea here is, okay, you start with coding and building, and then it's doing all this other stuff for you, scheduling meetings, I don't know, probably posting in Slack, I don't know, shipping designs.

我不知道。

I don't know.

这是否意味着，就像ChatGPT的商业版？

Is that is the idea there, this is like the the business version of ChatGPT in a sense, or is there or or is there something else there?

是的。

Yeah.

所以我们在讨论大约一年内的发展前景。

So, you know, so we're getting to the, like, the, like, one year time horizon conversation.

很多事可能会更快发生，但按模糊度来说，我认为是一年。

A lot of this might happen sooner, but in terms of fuzziness, I think we're the one year.

我会提出一个论点和一个可能实现的路径。}

So I'll give you, like, a contention and a plausible way we get there.

至于具体如何实现，谁知道呢？

But as for how it happens, who knows?

简而言之，如果我们要构建一个超级系统，它必须能执行各种任务。

So basically, if we're gonna build a super system, it has to be able to do things.

我们将拥有一个模型，它能做些影响你世界的事情。

So we're gonna have a model and it's gonna be able to do stuff affecting your world.

过去一年左右我们获得的一个认知是：要让模型发挥作用，当它们能使用计算机时效率会高得多。

And one of the learnings I think we've seen over the past year or so is that for models to do stuff, they are much more effective when they can use a computer.

对吧？

Right?

好的。

Okay.

所以现在我们需要一个能使用计算机的超级系统，或者说多台计算机。

So now we're like, okay, we need the super system that can use a computer, right, or many computers.

现在的问题是：它该如何使用计算机呢？

And now the question is, okay, well, how should it use the computer?

对吧？

Right?

使用电脑的方式有很多种。

And there's lots of ways to use a computer.

你知道，你可以尝试黑入操作系统，比如使用无障碍API。

You know, you could try to hack the OS and, like, use accessibility APIs.

或许更简单的方法是直接点击操作。

Maybe a bit easier is you could point and click.

这种方式有点慢，而且有时不太可靠。

That's a little slow and, unpredictable sometimes.

而另一种方式，事实证明模型使用电脑的最佳方式就是编写代码。

And another way, it turns out the best way for models to use computers is simply to write code.

所以我们逐渐得出一个观点：如果你想构建任何智能体，或许应该构建一个编码智能体。

And so we're kind of getting to this idea where like, well, if you want to build any agent, maybe you should be building a coding agent.

对于非技术用户来说，他们甚至不会意识到自己正在使用编码智能体，就像没人会思考自己是否在使用互联网一样。

And maybe to the user, a non technical user, they won't even know they're using a coding agent, the same way that no one thinks about, are they using the internet or not?

他们最多只会问，Wi-Fi开了吗？

It's just they're more just like, is Wi Fi on?

对吧？

Right?

所以我认为我们正在用Codex打造一个软件工程队友。

So I think that what we're doing with Codex is we're building a software engineering teammate.

作为其中的一部分，我们正在构建一个能通过编写代码来操作计算机的智能体。

And as part of that, we're kind of building an agent that can use a computer by writing code.

所以我们已经看到了一些这方面的需求。

And so we're already seeing some pull for this.

虽然还很早期，但我们开始看到人们将Codex用于编码相关的产品用途。

It's quite early, but we're starting to see people who are using Codex for coding adjacent product purposes.

随着这一趋势的发展，我认为我们会自然而然地发现，哦，原来只要能用编码解决问题，就应该让代理写代码。即使你在做财务分析，也可以写些代码。

And so as that develops, I think we'll just naturally see that, Oh, it turns out we should just always have the agent write code if there is a coding way to solve a problem instead of Even if you're doing a financial analysis, maybe write some code.

所以基本上，就像是在问：这是不是ChatGPT超级助手产品的两个发展方向？

So basically, were like, Hey, is this the two ends of this product for the super assistant of ChatGPT?

在我看来，编程是包括ChatGPT在内的任何智能体的核心能力。

In my mind, just coding is a core competency of any agent, including ChatGPT.

因此我们真正在构建的正是这种能力。

And so really what we think we're building is that competency.

智能体编写代码最酷的地方在于你可以导入代码。

So here's the really cool thing about agents writing code is that you can import code.

代码具有可组合性和互操作性。

Code is composable, interoperable.

对智能体最简化的理解可能是：给它一台电脑，它就会点击操作四处探索。

One very reductive view we could have for an agent is it's just gonna be given a computer and it's just gonna like point and click and go around.

但这正是未来。

But that is the future.

至于如何实现这个目标，很难规划具体路径，因为构建智能体的许多问题不在于'它能否做到'

And then how we get there is difficult to sort of chart a path because a lot of the questions around building agents aren't like, can the agent do it?

而更多在于'我们如何帮助智能体理解其工作场景'

But it's more about, well, how can we help the agent understand the context that it's working in?

就像使用它的团队那样，他们有自己的做事偏好方式。

And like the team that's using it, you know, has a way that they like to do things.

他们有指导原则。

They have guidelines.

他们可能希望关于智能体能做什么或不能做什么有某些确定性保证。

They probably want certain deterministic guarantees about what the agent can or cannot do.

他们想知道智能体是否理解这类细节，举个例子，如果我们查看一个崩溃报告工具，为其连接器时，每个子团队可能都有不同的元提示来说明他们希望如何分析崩溃情况。

What they wanna know that the agent understands sort of this detail, like an example would be, you know, if we're looking at a crash reporting tool, hitting a connector for it, Every sub team is probably has a different meta prompt for how they want the crashes to be analyzed.

于是我们开始面临这样的情况：是的，我们有一个坐在电脑前的智能体，但我们需要为团队或用户提供可配置性。

And so we start to get to this thing where, yeah, we have this agent sitting in front of a computer, but we need to make that configurable for the team or for the user.

对于智能体经常执行的任务，我们可能希望直接将其构建为该智能体具备的固定能力。

Stuff that the agent does often, we probably just want to build in as a competency that this agent has that it can do.

所以我认为最终我们会实现你所描述的这种通用性——一个能为任何需求自主编写脚本的智能体。

So I think we end up with this generalizable thing that you were saying of an agent that can just write its own scripts for whatever it wants to do.

但关键在于，我们能否将智能体高频执行或擅长的事项存储记忆，使其无需重复编写脚本？

But I think that the really key part here is can we make it so that everything that the agent has to do often or that it does well, we can just remember and store so that the agent doesn't have to write a script for that again, right?

或者如果我刚加入一个团队，而你已经和我同队，我就可以直接使用那些智能体已经写好的脚本。

Or maybe if I just joined a team and you are already on the same team as me, I can just, like, use all those scripts that the agents have written already.

是的。

Yeah.

这就像，如果这是我们的队友，他们可以分享从与公司其他人合作中学到的东西。

That's like, if this is our teammate, we can they can share things that it's learned from working with other people at the company.

这个比喻很贴切。

It just makes sense as a metaphor.

没错。

Yeah.

感觉你今天属于Karpathy阵营，认为现在的智能体并不出色，大多是粗制滥造，也许未来会变得很棒。

It feels like you're in the Karpathy camp of agents today are not that great and mostly slop, and maybe in the future, they'll be awesome.

你觉得呢？

Does that resonate?

我想是的，我认为编程智能体已经相当出色了。

I think so I think coding agents are pretty great.

思考

Think

老兄，我觉得

Man, I feel it's

价值巨大。

a ton of value.

至于编码之外的智能体，目前还处于非常早期的阶段。

And then I think agents outside of coding, it's still very early.

这只是我的个人观点，但我认为一旦它们能以组合方式运用编码能力，表现会大幅提升。

And this is just my opinion, but I think they're gonna get a whole lot better once they can use coding too in a composable way.

为软件工程师开发产品时，这部分特别有趣。

It's kind of the fun part of when you're building for software engineers.

在我创业期间，很长一段时间我们也是为软件工程师打造产品。

In my startup, we were building for software engineers too for a lot of that journey.

他们是最有趣的用户群体，因为他们自己也热衷开发，在思考技术应用时往往比我们更具创造力。

And they're just such a fun audience to build for because they also like building for themselves and are often even more creative than we are in thinking about how to use the technology.

因此，为软件工程师构建产品时，你能观察到大量自发行为，以及应该融入产品的功能和改进点。

And so, like, by building for software engineers, you get to just observe a ton of emergent behaviors and, like, things that you should do and build into the product.

我很喜欢你这种说法，因为很多为工程师开发产品的人会感到非常恼火，因为工程师总是在抱怨。

I love how you you say that because a lot of people building for engineers get really annoyed because the engineers ever so they're just always complaining about stuff.

他们总是说‘这太烂了’。

They're like, that sucks.

‘你们为什么要这样设计？’

So why'd you build it this way?

我很高兴你喜欢它，但我想这可能是因为你为工程师们打造了一款真正能解决问题、甚至能替他们编程的出色工具。

I love that you enjoy it, but I think it's probably because you're building such an amazing tool for engineers that can actually solve problems and just, you know, code for them.

顺着这个思路，你知道的，人们总在讨论工作、工程师和编程的未来会怎样。

Kinda along those lines, you know, there's always this talk of what will happen with jobs, engineers, coding.

人们还需要学习编程吗？诸如此类的问题。

Do you have to learn coding, all these things?

显然，按照你的描述，它更像是一个队友。

Clearly, the way you're describing it is it's a teammate.

它会与你协作，让你变得更强大。

It's gonna work with you, make you more superhuman.

按照你对工程领域影响的思考方式，它不会取代你，而是拥有一个超级智能的工程队友。

It's not gonna replace you with the way you just think about the impact on the field of engineering, having a super intelligent engineering teammate.

我认为这件事有两面性。

I think there's there's two sides to it.

但我们刚才讨论的是这样一种观点：也许每个智能体都应该实际使用代码，成为一个编程智能体。

But the one we were just talking about is this idea that maybe every agent should actually use code and be a coding agent.

在我看来，这只是这个更广泛理念的一小部分——随着代码变得更加无处不在，即使在AI之前，你也可以说它现在已经无处不在，对吧？

And in my mind, that's just like a small part of this broader idea that like, Hey, as we make code even more ubiquitous, I mean, you could probably claim it's ubiquitous today, even pre AI, right?

但随着代码变得更加无处不在，它实际上将被用于更多目的。

But as you make code even more ubiquitous, it's actually just going to be used for many more purposes.

因此，对具备这种能力的人——即掌握这项技能的人类——的需求将会大幅增加。

And so there's just going to be a ton more need for people with this, like humans with this competency.

这就是我的观点。

So that's my view.

我认为这是一个相当复杂的话题。

I think this is like, quite a complex topic.

所以，你知道，这是我们经常讨论的事情，我们需要观察它的发展。

So, you know, it's something we talk about a lot, and we have to kind of see how it pans out.

但我认为我们作为这个领域的产品团队能做的，就是始终思考如何打造一个工具，让它感觉像是在最大限度地加速人们的工作，而不是制造一个让人类更不清楚该做什么的工具。

But I think what we can do, what we can do basically as a product team building in the space is just try to always think about how are we building a tool so that it feels like we're like maximally accelerating, people, you know, rather than building a tool that makes it more unclear what you should do as the human.

我想举个例子，现在当你与编码代理合作时，它会编写大量代码，但事实证明编写代码其实是许多软件工程师工作中最有趣的部分。

I think to give an example right now, nowadays when you work with a coding agent, it writes a ton of code, but it turns out writing code is actually one of the most fun parts of software engineering for many software engineers.

结果你却要花时间审查AI生成的代码。

It's then you end up reviewing AI code.

对吧？

Right?

而这通常是许多软件工程师工作中不那么有趣的部分。

And that's often a less fun part of the job for many software engineers.

对吧？

Right?

因此我确实认为，我们看到这种情况在各种微观决策中不断上演。

And so I actually think, like, we see that this comes up, plays out all the time in a ton of micro decisions.

所以我们作为产品团队一直在思考：如何让这件事变得更有趣？

So we, as a product team, are always thinking about, okay, do we make this more fun?

如何让你感觉更有掌控感？

How do we make you feel more empowered?

而当前这种方式并不奏效。

Whereas it's not working.

我认为审查AI编写的代码就是当前比较无趣的一个环节。

And I would argue that reviewing agent written code is a place that today is like less fun.

于是我在思考：我们能为此做些什么？

And so then I think, okay, what can we do about that?

我们可以推出代码审查功能，帮助你增强对AI编写代码的信心。

Well, we can ship a code review feature that helps you build confidence in the AI written code.

好的，很棒。

Okay, cool.

我们还可以做的是让代理能更好地验证自己的工作成果。

Another thing we could do is we can make it so that the agent's better able to validate its work.

这甚至深入到微观决策层面。

And it gets all the way down into micro decisions.

如果你要让代理具备验证工作的能力，比如说现在我想到了Codex Web，你有一个面板可以反映代理所做的工作。

If you're gonna have an agent capability to validate work, and let's say you have, I'm thinking of Codex Web right now, you have a pane that sort of reflects the work the agent did.

你首先会看到什么？

What do you see first?

是看到代码差异对比，还是看到它编写代码的图像预览？

Do you see the diff or do you see the image preview of the code it wrote?

我认为如果你从这个角度思考：如何赋能人类？

I think if you're thinking about this from perspective, how do I empower the human?

如何让他们感受到最大程度的加速？

How do I make them feel as accelerated as possible?

你显然会先看到图像对吧？

You obviously see the image Right?

除非先看过图像，否则你不应该直接审查代码——除非这些代码已经经过AI审核。

You shouldn't be reviewing the code unless first, you know, you've seen the image unless maybe it's been, like, reviewed by an AI.

现在该你查看一下了。

Now it's time for you to take a look.

当我邀请Cursor公司的CEO迈克尔·奇拉尔达上播客时，他提出了我们正在向超越代码的领域迈进的观点。

When I had, Michael Chiralda, CEO of Cursor on the podcast, he he had this kind of vision of us moving to something beyond code.

我观察到一种称为'规范驱动开发'的趋势兴起，你只需编写规范，AI就会自动为你生成代码。

And I've seen this rise of something called spec driven development where you kinda just write the spec and then the code, you know, the AI writes code for you.

因此你开始在更高的抽象层次上工作。

And so you kinda start working at this higher abstraction level.

你是否认为这就是未来方向——工程师不再需要实际编写或查看代码，我们将专注于更高层次的抽象？

Is that something you see where we're going just like engineers not having to actually write code or look at code, and there's gonna be this higher level of abstraction that we focus on?

是的。

Yeah.

我认为这些抽象层级是持续存在的，而且实际上在今天就已经有所体现了。

I mean, I think I think there's, like, constantly these levels of abstraction, and they're actually already played out today.

对吧？

Right?

就像今天，编程代理大多是基于提示进行补丁操作，对吧？

Like, today, like coding agents, mostly it's like prompts to patch, right?

我们开始看到人们尝试规范驱动开发或计划驱动开发。

We're starting to see people doing like spectrum in development or like planned and driven development.

这实际上就是当人们问'如何在超长任务中运行Codecs'时的解决方案之一。

That's actually one of the ways when people ask like, Hey, how do you run Codecs on a really long task?

通常的做法是先与系统协作制定计划。

Well, it's like often collaborate with it first to write like a plan.

比如创建一个Markdown文件作为你的计划书。

Md, like a markdown file that's your plan.

当你对这个计划满意后，就可以让AI去执行具体工作。

And once you're happy with that, then you ask a kid to go off and do work.

如果这个计划包含可验证的步骤，它就能处理更长时间的任务。

If that plan has verifiable steps, it'll like work for much longer.

所以我们完全看到了这一点。

So we're totally seeing that.

我认为规范驱动开发是个有趣的想法。

I think spec driven development is an interesting idea.

我不确定这种方式是否可行，因为很多人也不喜欢写规范。

It's not clear to me that it'll work out that way because a lot of people don't like writing specs either.

但似乎有些人会采用这种方式工作。

But it seems plausible that some people will work that way.

不过有个略带玩笑的想法是，想想现在很多团队的工作方式，他们通常不一定有规范，但团队自我驱动力很强，所以事情自然就完成了。

A bit of a joke idea though is if you think of the way that many teams work today, they often don't necessarily have specs, but the team is just really self driven and so stuff just gets done.

所以我临时想到这个不太好的名称——'闲聊驱动开发'，就像事情都是在社交媒体和团队通讯工具中发生的。

So almost that is like, I'm coming up with this on the spot, so it's not a good name, but chatter driven development where it's just like stuff is happening on social media and in your team communications tools.

结果就是代码被编写并部署了。

And then as a result, code gets written and deployed.

所以是的，我觉得我更倾向于这种方式，我甚至不一定非要写规范。

So yeah, I think I'm a little bit more oriented in that way of, I don't even necessarily want to have to write a spec.

有时我会想写规范，但仅限于我喜欢写的时候。

Sometimes I want to, only if I like writing specs.

其他时候我可能只想说：'嘿，这是客服渠道，告诉我有什么值得关注的点。'

Other times I might just want to say, Hey, here's the customer service channel and tell me what's interesting to know.

但如果是小问题，直接修复就好。

But if it's a small bug, just fix it.

我不想为此专门写规范。

I don't wanna have to write a spec for that.

我有个喜欢用来激发讨论的假想未来场景：当我们拥有真正强大的智能代理时，独立开发者会是什么样子？

I have this hypothetical future that I like to share sometimes with people as a provocation, which is in a world where we have, like, truly amazing agents, like, what does it look like to be a solo printer?

有个糟糕的设想是：实际上会存在一个手机应用。

And, you know, one terrible idea for how it could look is that it's actually there's a mobile app.

代理的每个想法都会以竖屏视频形式出现在你手机上。

And every idea that the agent has to do is just, like, vertical video on your phone.

你可以左滑表示这是个坏主意，右滑表示好主意。

And then you can, like, swipe left if you think it's a bad idea, and you can, like, swipe right if it's a good idea.

比如，你可以长按手机说话，在滑动前获取关于这个想法的反馈。

And, like, you can press and hold and, like, speak to your phone if you wanna get feedback on the idea before you swipe.

你知道吗？

You know?

在这个世界里，你的工作基本上就是把这个应用接入每一个信号系统、记录系统，然后你就可以坐享其成，只管滑动。

And in this world, like, basically, what your job is just to, like, plug in this app into, like, every single, like, signal system, you know, system of record, and then you just sort of sit back and, like, swipe.

我不知道。

I don't know.

我太喜欢这个了。

I love this.

所以这就是Tinder遇上TikTok再遇上Codex。

So this is, Tinder meets TikTok meets Codex.

这想法挺糟糕的。

It's pretty terrible.

不。

No.

这太棒了。

This is great.

所以这个想法是，这个智能体在观察、倾听你，关注市场和用户动态，然后它就会觉得'酷'。

So the idea here is this thing is this agent is watching and, right, listening to you, paying attention to the market, your users, and it's like, cool.

这是我应该做的事情。

Here's something I should do.

就像一个积极主动的工程师，直接说'看这个'。

It's like a proactive engineer just like, here.

我们应该开发这个功能并修复这个

We should build this feature and fix this

问题。

thing.

没错。

Exactly.

我认为这正是我们要做的。

I think that's what really gonna do.

以最基础的方式与你交流，就像这样。

Communicating with you in, like, the lowest, like Yeah.

没错。

Yeah.

就像现代沟通方式那样。

Like, the modern way way to communicate.

对。

Yeah.

左右滑动和垂直信息流。

Swipe left to right and and vertical feed.

然后是Sora视频。

And then the Sora video.

好的。

Okay.

现在我明白这一切是如何联系起来的了。

So I see how this all connects now.

我明白了。

I see.

是啊。

Yeah.

明确一下，我们并不是在构建那个东西，你知道的，这只是个有趣的想法。

To be clear, we're not building that, like, you know, it's a fun idea.

我是说，你看，在这个例子中，它正在做的事情之一就是接收外部信号。

I mean, you see, you know, like, in this example, though, like, one of the things that it's doing is it's consuming external signals.

对吧？

Right?

我认为另一个非常有趣的点是，如果我们想想迄今为止最成功的人工智能产品是什么？

I think the other really interesting thing is, like, if we think about, like, what is the most successful, like, AI product to date?

说来有趣，虽然不想把事情搞混，但第一次我们使用Codex品牌和OpenAI时，实际上是为GitHub Copilot提供动力的模型。

I would argue, it's funny, actually, not to confuse things at all, but, like, the first time we used the the the brand Codex and OpenAI was actually the model powering GitHub Copilot.

这要追溯到很久以前，好几年前的事了。

This is, like, way back in the day, years ago.

所以我们最近决定重新使用Codex这个品牌，因为它实在太出色了，你知道的，编解码器、代码执行。

So we decided to reuse that that brand recently because it's just so good, you know, codecs, code execution.

但我认为实际上，IDE中的自动补全功能是当今最成功的人工智能产品之一。

But I think actually, like, auto completion and IDEs is, like, one of the most successful AI products today.

它最神奇的地方在于，当它能正确提供帮助时能极大加速你的工作，即使出错也不会让人特别烦躁。

And part of what's so magical about it is that when it can surface like ideas for helping you really rapidly when it's right, you're accelerated when it's wrong, it's not like that annoying.

虽然有时确实会让人恼火，但还不至于太糟糕。

It can be annoying, but it's not that annoying.

对吧？

Right?

这样你就能创建这种能根据你当前操作意图进行上下文响应的智能辅助系统。

And so you can create this like next initiative system that's like contextually responding to like what you're attempting to do.

因此在我看来，这对我们OpenAI正在构建的东西来说是个非常有趣的方向。

And so in my mind, this is like a really interesting thing for us as open AIs we're building.

举个例子，当我考虑推出浏览器时——就像我们之前用Atlas做的那样，对吧？

So for instance, when I think about launching a browser, which we did with Atlas, right?

在我看来，我们能做的一件非常有趣的事情是，可以根据上下文情境为你日常工作中提供帮助的方式。

Like in my mind, one of the really interesting things we can then do is we can then like contextually surface like ways that we can help you as you're going about your day.

这样我们就突破了局限，不再只是查看代码或停留在终端里，而是意识到一个真正的团队成员要处理的远不止代码。

And so we break out of this, we're just looking at code or we're just in your terminal into this idea that, hey, a real teammate is dealing with a lot more than just code.

他们还需要处理大量网络内容相关的事务。

They're dealing with a lot of things that are web content.

我们该如何在这方面帮助你呢？

You know, how can we help you with that?

天啊，这里面的内容太丰富了。

Man, there's so much there.

我太喜欢这个了。

I love this.

好的。

Okay.

那么浏览器里的网页自动补全功能。

So autocomplete on web with the browser.

这太有趣了。

That's so interesting.

就像这样，当你浏览网页和处理日常事务时，我们可以为你提供各种帮助。

Just like, here's all the things that we can help you with as you're browsing and going about your day.

我想谈谈Atlas。

I wanna talk about Atlas.

我稍后再回到这个话题。

I'll come back to that.

编解码器，代码执行。

Codecs, code execution.

我之前不知道这个。

Did not know that.

这真的很巧妙。

That's really clever.

我现在明白了。

I I get it now.

好的。

Okay.

然后这些闲聊。

And then this chatter.

什么是闲聊驱动开发？

What is a chatter driven development?

我有个不。

I had a no.

这真是个绝妙的主意。

This is a really good idea.

但这让我想起，我曾邀请Block公司的CTO John G Donji上播客，他们有个内部产品叫Goose，是他们自己的智能代理工具。

But it reminds me, I had John g Donji on the podcast, CTO of Block, and they they have this product called Goose, which is their own internal agent thing.

他提到Block有位工程师让Goose实时观察他的屏幕、旁听所有会议，并主动完成他可能需要做的工作。

And he talked about an engineer at Block just has Goose watch him with, like, his screen and listens to every meeting and proactively does work that he should probably wanna do.

比如提交PR、发送邮件、起草Slack消息。

So he ships to PR, sends an email, drafts a Slack message.

所以他正在以一种非常初级的方式，做着你所描述的事情。

So he's doing exactly what you're describing in in kind of a very early way.

是的。

Yeah.

那非常有趣。

That's super interesting.

而且，你知道吗？我敢打赌，如果我们去问他们这种生产力的瓶颈是什么，他们有分享过吗？

And, you know, I bet you the so if we go if we went and asked them what the bottleneck to that productivity is, did did they share what it is?

可能就是在观察它，并确认这是正确的事情。对。

Probably looking at it and just making sure this is the right thing to Yeah.

是的。

Yeah.

所以我们现在看到了这种情况。

So we see this now.

我们为Codex集成了Slack功能。

We have a Slack integration for Codex.

人们喜欢这样——当需要快速完成某事时，大家就会直接@Codex。

People love if there's something that you need to do quickly, people will just mention Codex.

你认为这个bug为什么会发生？

Why do you think this bug is happening?

不一定要是工程师，甚至像数据科学家这类角色也经常大量使用Codex来回答诸如'你认为这个指标为什么波动？'之类的问题。

Have to be an engineer, even like maybe data scientists often appear are using Codex a ton to just answer questions like, why do you think this metric moved?

发生了什么？

What happened?

所以提出问题后，你能直接在Slack里获得答案。

So questions, you get the answer right back in Slack.

这太棒了，超级实用。

It's amazing, super useful.

至于编写代码时，你还是得回头检查代码对吧？

As for when it's writing code, then you have to go back and look at the code, right?

所以目前真正的瓶颈我认为在于验证代码是否有效，以及编写代码审查。

And so the real, like, I think bottleneck right now is like validating that the code worked and like writing code review.

所以在我看来，如果我们想要达到类似你提到的那个朋友World的水平，我认为我们真的需要想办法让人们配置他们的编程代理，使其在工作后期阶段能更加自主运作。

So in my mind, if we wanted to get to something like, you know, that, a friend you were talking about, World, I think we, we really need to figure out how to get people to configure their coding agents to be much more autonomous on those later stages of the work.

有道理。

It makes sense.

就像你说的，写代码我

Like you said, writing code I

曾经是

used to be

一名工程师。

an engineer.

我当了十年工程师。

I was an engineer for ten years.

写代码真的很有趣，进入心流状态、构建、架构设计、测试都很有意思。

Really fun to write code, really fun to just get in the flow, build, architect, test.

但审查别人的代码就没那么有趣了，特别是当你必须为那些可能导致生产环境崩溃的愚蠢代码负责时。

Not so fun to look at everyone else's code and just have to go through and be on the hook if it is doing something dumb that's gonna take down production.

现在构建已经变得更容易了，我从那些真正处于技术前沿的公司那里一直听到的是，现在的瓶颈在于确定要构建什么，然后到了最后阶段，就像，好吧。

And now that building has become easier, what I've always heard from companies that are really at the cutting edge of this is the bottleneck is now, like, figuring out what to build, and then it's at the end of, like, okay.

我们有所有这些100个PR需要审查。

We have all this all a 100 PRs to review.

谁来处理所有这些呢？

Who's gonna go through all that?

没错。

Right.

是的。

Yeah.

本节目由Jira Product Discovery赞助播出。

This episode is brought to you by Jira Product Discovery.

构建产品最困难的部分其实并不是构建产品本身。

The hardest part of building products isn't actually building products.

而是其他所有事情。

It's everything else.

关键在于证明工作的重要性，管理利益相关者，并提前做好规划。

It's proving that the work matters, managing stakeholders, trying to plan ahead.

大多数团队把更多时间花在被动应对而非主动学习上，疲于追逐更新、为路线图辩护，并不断解决阻碍以维持运转。

Most teams spend more time reacting than learning, chasing updates, justifying roadmaps, and constantly unblocking work to keep things moving.

Jira产品发现功能让您重掌主动权。

Jira Product Discovery puts you back in control.

通过Jira产品发现，您可以捕捉洞见并优先处理高影响力的创意。

With Jira Product Discovery, you can capture insights and prioritize high impact ideas.

它具有灵活性，能适应团队的工作方式，帮助您制定促进共识而非质疑的路线图。

It's flexible so it adapts to the way your team works and helps you build a road map that drives alignment, not questions.

由于它基于Jira构建，您可以在同一平台跟踪从战略到交付的整个创意流程。

And because it's built on Jira, you can track ideas from strategy to delivery all in one place.

减少奔波，腾出更多时间思考、学习并构建正确的事物。

Less chasing, more time to think, learn, and build the right thing.

免费获取Jira产品发现功能，请访问atlassian.com/lenny。

Get Jira product discovery for free at atlassian.com/lenny.

网址是atlassian.com/lenny。

That's atlassian.com/lenny.

Codec对您作为产品人员、项目经理的工作方式产生了什么影响？

What has the impact of Codec's been on the way you operate as a product person, as a PM?

工程团队受到的影响显而易见。

It's clear how engineering is impacted.

代码是为你编写的。

Code is written for you.

它对你和OpenAI的PM们的工作方式产生了什么影响？

What has it done to the way you operate and the way PMs operate at at OpenAI?

是的。

Yeah.

我认为主要是让我感觉更有能力了。

I mean, I think mostly I just feel, like, much more empowered.

我一直都是偏技术型的项目经理。

I've always been sort of more technical leaning PM.

尤其是当我为工程师开发产品时，感觉必须亲自'吃自己的狗粮'(使用自家产品)。

And especially when I'm working on products for engineers, feel like it's necessary to dog food the product.

但除此之外，我觉得作为产品经理能做的事情多太多了。

But even beyond that, I just feel like I can do much, much more as a PM.

Scott Belsky曾提出过'压缩人才栈'这个概念。

And Scott Belsky talks about this idea of compressing the talent stack.

我不确定这个表述是否准确。

I'm not sure if I phrased that right.

但核心思想是：由于人们能承担更多工作，这些角色之间的界限变得不像过去那么必要了。

But it's basically this idea that maybe the boundaries between these roles are a little bit less needed than before because people can just do much more.

每当有人能承担更多职责时，就能减少一个沟通环节，让团队效率大幅提升。

And every time someone can do more, you can skip one communication boundary and make the team that much more efficient.

所以我认为这种现象已经出现在多个职能领域了。不过既然你问的是产品方面——现在回答问题变得容易多了，你可以直接咨询Codex获取想法。

So I think I think we see it, you know, in a bunch of functions now, but I guess since you asked about like product specifically, you know, now, like answering questions much, much easier, you can just ask Codex for thoughts on that.

很多产品经理的工作，比如理解需求变化...

A lot of, like, PM type work understanding what's changing.

再次强调，直接向Codex寻求帮助即可。

Again, just ask Codex for help with that.

制作原型通常比编写规范文档更快。

Prototyping is often faster than writing specs.

这是很多人讨论过的话题。

This is something that a lot of people have talked about.

我认为虽然不算特别出人意料，但稍微让人惊讶的是：我们主要开发Codex是为了编写可部署到生产环境的代码，但实际上现在很多人用Codex编写一次性代码。

I think something that I don't think it's super surprising, but something that's slightly surprising is we see We're mostly building Codex to write code that's gonna be deployed to production, but actually we see a lot of throwaway code written with Codex now.

这某种程度上回归了'无处不在的代码'这个概念。

It's kind of going back to this idea of ubiquitous code.

比如你会看到有人想做数据分析时——

So you'll see someone wants to do an analysis.

如果我想理解某些数据，就直接给Codex一堆数据，然后让它为这些数据构建一个交互式数据查看器。

Like if I wanna understand something, it's like, okay, just give Codex a bunch of data, but then ask it to build an interactive data viewer for this data.

过去做这种事太麻烦了，但现在完全值得花时间让智能体去完成。

That's just too annoying to do in the past, but now it's just totally worth the time of just getting an agent to go do something.

类似地，我在设计团队看到一些相当酷的原型，比如设计师想制作一个动画，这就是硬币动画Codex。

Similarly, I've seen like some pretty cool prototypes on our design team about like, if you want to well, like a designer basically wanted to build an animation and this is the coin animation codex.

通常来说，编程实现这个动画会非常麻烦。

And it was like, normally, it'd be too annoying to program this animation.

所以他们直接快速编写了一个动画编辑器，然后用这个编辑器制作动画，最后将动画提交到代码库。

So they just vibe coded a animation editor, and then they use the animation editor to build the animation, which they then check into the repo.

实际上，我们的设计师在这方面效率提升非常显著。

Actually, our designers are there's a ton of acceleration there.

说到人才栈压缩，我认为我们的设计师非常全能（PME）。

And, like, speaking of compressing the talent stack, I think our designers are very PME.

他们做了大量产品工作，甚至用快速编码的方式为Codex应用做了完整的功能原型。

So, you know, they they do a ton of product work and, like, they actually have, like, an entire, like, vibe coded sort of side prototype of the Codex app.

我们讨论问题的方式往往是快速头脑风暴，因为要处理的事情实在太多了。

And so a lot of how we talk about things is we'll have a really quick jam because there's 10,000 things going on.

然后设计师会去思考这个功能应该如何运作。

And then the designer will go think about how this should work.

但他们不会再次讨论，而是直接在独立原型中即兴编写一个原型。

But instead of talking about it again, they'll just vibe code a prototype of that in their standalone prototype.

我们会试用它。

We'll play with it.

如果我们喜欢，他们会将这个原型即兴编码或即兴工程化，变成一个实际的PR提交。

If we like it, they'll vibe code that prototype into or vibe engineer that prototype into an actual PR to land.

然后根据他们对代码库的熟悉程度，比如Codec CLI和Rust稍微难一些，他们可能会自己提交，或者接近完成时由工程师协助提交PR。

And then depending on their comfort with the code base, like Codec CLIs and Rust is a little harder, Maybe they'll, like, land it themselves or they'll, like, get close and then an engineer can help them, like, land the PR.

你知道，我们最近发布了Sora安卓应用，这实际上是最令人震撼的加速案例之一，因为OpenAI内部对Codex的使用率显然非常高。

You know, we recently shipped the Sora Android app, and, that was one of the most sort of mind blowing examples of acceleration actually, because usage of Codex internally to open AI is obviously really, really high.

但这一年来它一直在增长，现在基本上所有技术人员都在使用它。

But it's been growing over the course of the year, both in terms of like now it's basically like all technical staff use it.

甚至关于如何最大化利用编码代理的深度和技巧也大幅提升。

But even like the intensity and know how of how to make the most of coding agents has gone up by a ton.

所以Sora安卓应用这个全新的应用，我们仅用18天就完成了从零到员工发布的全部流程。

And so the Sora Android app, like a fully new app, we built it in eighteen days, it went from like zero to launch to employees.

然后十天后，总共二十八天，我们就向公众全面发布了。

And then ten days later, so twenty eight days total, we went to just GA to the public.

这完全是在Codex的帮助下完成的。

And that was done just with the help of Codex.

所以开发速度相当惊人。

So pretty insane velocity.

我想说这有点——不想说是简单模式——但如果你是一家在多个平台上构建软件的公司，Codex确实特别擅长一件事。

I would say it was a little bit, I don't want say easy mode, but there is one thing that Codex is really good at if you're a company that's like building software on multiple platforms.

所以你已经弄清楚了一些底层的API或系统。

So you've already figured out like some of the underlying like APIs or systems.

让Codex像移植东西一样工作非常有效，因为它有现成的东西可以参考。

Asking Codex to sit like to port things over is really effective because it has something you can go look at.

因此那个团队的工程师基本上就是让Codex参考iOS应用，生成需要完成的工作计划，然后去执行这些计划。

And so the engineers on that team were basically having Codex go look at the iOS app, produce plans of work that needed to be done, and then go implement those.

我当时同时关注着iOS和Android的情况。

And I was kind of looking at iOS and Android at the same time.

所以，基本上，从内部发布到员工用了两周，总共四周时间。

And so, you know, basically, it was like two weeks to launch employees, four weeks total.

速度快得惊人。

Insanely fast.

更疯狂的是它成为了App Store排名第一的应用。

What makes that even more insane is it was the it became the number one app in the App Store.

我不知道。

I don't know.

这简直让人难以置信。

This just boggles the mind.

好的。

Okay.

是啊。

So yeah.

想象一下

So imagine doing

第一名

the number

在应用商店上架的应用，仅由少数工程师开发完成。

one app on the app store with, like, a handful of engineers.

我想大概就两三个人，在几周内完成的。

I think it was, like, two or three possibly, in a handful of weeks.

是的。

Yeah.

这太荒谬了。

This is absurd.

所以，这是个展示加速发展的绝佳例子。

So, yeah, so that's a really fun example of acceleration.

另一个例子是Atlas，我记得本做过一期关于Atlas的播客，详细介绍了我们的开发过程。

Then like Atlas is the other one that I think Ben did a podcast, engine lean on Atlas, sharing a little bit about how we built there.

要知道，Atlas实际上是个浏览器，对吧？

You know, many Atlas is is actually mean, it's a it's a browser, right?

开发浏览器真的非常困难。

And building a browser is really hard.

因此我们不得不构建许多复杂的系统来实现这一目标。

And so we, had to build a lot of difficult systems in order to do that.

基本上，我们让那个团队现在拥有了大量Codex的高级用户。

And basically we got to the point where that team has a ton of power users of Codex right now.

而且，你知道吗，发展到后来他们基本上都在讨论这个，因为很多那些工程师都是我创业前共事过的同事。

And, you know, it got to the point where they were basically, were talking to them about it because a lot of those engineers are people I used to work with before my startup.

所以他们会说，要知道在以前这需要两三个工程师花两三周时间才能完成。

And so they'd say, you know, before this would have taken us like two to three weeks for two to three engineers.

而现在只需要一个工程师一周时间。

And now it's like one engineer, one week.

所以这里也有巨大的效率提升。

So massive acceleration there as well.

最酷的是，你知道，我们最初是在Mac上发布Atlas的，但现在我们正在开发Windows版本。

And what's quite cool is that, you know, we we shipped Atlas on on Mac first, but now we're working on the Windows version.

要知道，团队现在正专注于Windows平台的开发，他们也在帮助我们优化Windows上的编解码器——虽然目前还处于早期阶段，比如我们上周发布的模型是首个原生支持PowerShell的版本。

You know, that so the team now is, like, ramping up on Windows and they're helping us make codecs better on Windows too, which is admittedly earlier, like, just the model we we shipped last week is the first model that natively understands PowerShell.

PowerShell作为Windows系统原生的脚本语言。

So, you know, PowerShell being, the native, like, shell language on Windows.

是的，看到整个公司因Codex而加速发展真是令人振奋——最明显的是研究部门在加速模型训练和提升效果，甚至包括我们之前讨论的设计和营销领域。

So, yeah, it's been it's been really awesome to see, like, whole company getting accelerated by Codex, from And most obviously, also research and improving how quickly we train models and how well we do it, and then even design as we talked about and marketing.

实际上，现在我们的产品营销人员经常直接在Slack上修改字符串或更新文档。

Actually, we're at this point now where my product marketer is often also making string changes just directly from Slack or, like, updating docs directly from Slack.

这些都是令人惊叹的案例。

These are amazing examples.

你们正站在技术可能性的最前沿，这将成为其他公司未来的工作方式。

You guys are living at the bleeding edge of what is possible, and this is how other companies are gonna work.

再次发布后便登顶应用商店榜首，风靡全球——至少霸榜一周。

Just shipping, again, what became the number one app in the app store and just beloved all over the it just, like, took over the, I don't know, the world for at least a week.

你说核心功能只用了28天开发？不对，好像是10天，还是18天就搞定了基础框架。

Built, you said, at twenty eight days and, like, I don't know, ten days, eighteen days just to get, like, the core of it working.

是啊。

Yeah.

所以，大概十八天后，我们就有了一个员工们都在玩的东西。

So, like, eighteen days, we had a thing that employees were playing with.

对。

Yeah.

然后十天后，我们就发布了。

And then ten days later, we were out.

你还说只有几个工程师。

And you said just a couple engineers.

嗯。

Yeah.

两三个。

Two or three.

好的。

Okay.

然后你说Atlas花了一周时间构建。

And then Atlas, you said it was took a week to build.

不，不，不。

No, no, no.

Atlin项目其实只用了不到一周，但它是个相当复杂的项目。

So Atlas, not the whole week, but Atlas was like a really meaty project.

我当时正在和Atlas团队的一位工程师讨论他们如何使用Codex。

And so I was talking to one of the engineers on Atlas about just how what they use Codex for.

基本上就是，我们所有事情都用Codex来完成。

And it's basically like, we use Codex for absolutely everything.

我当时就想，好吧，那你们要怎么测量加速度呢？

I was like, Okay, well, how would you measure the acceleration?

所以我得到的回复基本上是，以前需要两三个工程师花两三周时间，现在只要一个工程师一周就能搞定。

So basically, answer I got back was, previously, it would have taken two to three weeks for two to three engineers, and now it's like one engineer one week.

你觉得最终会发展到让非工程师来做这类工作吗？

Do you think this eventually moves to non engineers doing this sort of thing?

比如说，必须由工程师来构建这个东西吗？

Like, does it have to be an engineer building this thing?

能不能由产品经理或设计师之类的人来构建呢？

Could sort of built been built by, I don't know, a PM or designer?

我认为我们很大程度上会达到一个界限变得模糊的阶段。

I think we will very much get to the point where well, basically, where the boundaries are a little bit blurred.

对吧？

Right?

我认为你会需要了解他们正在构建内容细节的人，但这些细节会不断演变。

Like, I think you're going to want someone who's like understands the details of what they're building, but what details those are will evolve.

有点像现在，如果你在写Swift代码，就不必懂汇编语言。

Kind of like how now, like, if you're writing Swift, you don't have to speak assembly.

世界上只有少数人真正精通汇编语言，也许比少数多一些，但他们的存在确实很重要，对吧？

There's a handful of people in the world and it's really important that they exist and like speak assembly, maybe more than a handful, right?

但这就像一种专业职能，大多数公司并不需要具备。

But that's like a specialized function that like most companies don't need to have.

所以我认为我们自然会看到抽象层次的增加。

So I think we're just gonna naturally see like an increase in layers of abstraction.

而现在最酷的是，我们正在进入语言抽象层，比如自然语言。

And then the cool thing is now we're entering like the language layer of abstraction, like natural language.

而且自然语言本身非常灵活，对吧？

And the natural language itself is really flexible, right?

比如工程师可以讨论计划，也可以讨论规范，还可以直接讨论产品或想法。

Like you could have engineers talking about a plan and then you could have engineers talking about a spec and then you could have engineers talking about just a product or an idea.

所以我认为我们也可以开始向上移动这些抽象层次。

So I think we can also start moving up those layers of abstraction as well.

但我确实认为这会是一个渐进的过程。

But I do think this is gonna be gradual.

我不认为会突然发展到没人写任何代码，只剩规范的地步。

Don't I think it's gonna go up to all of a sudden nobody ever writes anything and any code and it's just specs.

我觉得更像是：我们已经把编码代理设置得很擅长预览构建或运行测试。

I think it's gonna be much more like, okay, we've set up our coding agent to be really good at previewing the build or at running tests.

这可能是大多数人已经完成的第一部分。

Maybe that's the first part that most people have set up.

就像，好了，现在我们设置好了，它们可以执行构建并看到自己更改的结果。

And it's like, okay, now we've set it up so they can execute the build and it can see the results of its own changes.

但我们还没有建立一个好的集成框架，以便它能够——顺便说一下，在Atlas的情况下，不知道他们是否已经做了这些。

But we haven't yet built a good integration harness so that it can, in the case of Atlas, by the way, don't know if they've done any of this or not.

我认为他们已经做了很多这方面的工作，但也许下一阶段是让它加载几个示例页面看看效果如何。

I think they've done a lot of this, but maybe the next stage is enable it to load a few sample pages to see how well those work.

那么，好了，现在我们要设置到那个阶段。

So then, okay, now we're gonna set up to that.

我认为至少在一段时间内，我们会有人类来筛选这些连接器、系统或组件，确定代理需要擅长与哪些交互。

And I think for some time, at least we're gonna have humans curating which of these connectors or systems or components that the agent needs to be good at talking to.

然后，你知道，在未来会有更大的突破，Codex会告诉你如何设置，或者可能在代码库中自行设置。

And then, you know, in the future, there will be an even greater unlock where Codex tells you how to set it up or maybe sets itself up in a repo.

活在这个时代真是太疯狂了。

What a wild time to be alive.

哇。

Wow.

我很好奇这类事物的二阶效应，就是它能多快地构建东西。

I'm curious just the second order effects of this sort of thing, just how quickly it is to build stuff.

那会带来什么影响？

What does that do?

这是否意味着分发变得极其重要？

Does that mean distribution becomes much, much more important?

这是否意味着创意的价值会大幅提升？

Does it mean, ideas are just worth a lot more?

思考这种变化的速度很有意思。

It's interesting to think about how quick, how that changes.

我想知道你的看法。

I'm curious what you think.

我仍然不认为创意的价值有大多数人想的那么高。

I still don't think ideas are worth as much as maybe a lot of people think.

我还是认为执行非常困难，对吧？

I still think execution is really hard, right?

就像你可以快速构建某样东西，但你仍然需要很好地执行它。

Like you can build something fast, but you still need to execute well on it.

仍然需要合理且整体上连贯。

Still needs to make sense and be a coherent thing overall.

是的，而且分销渠道至关重要。

Yeah, and distribution is massive.

是啊。

Yeah.

只是感觉其他所有事情现在都变得更加重要了。

Just feels like everything else is now more important.

所有非构建环节的事情——想点子、推向市场、盈利，诸如此类的一切。

Everything that isn't the building piece, which is coming up with an idea, getting to market, profit, all that kind of stuff.

我认为我们可能曾处于这个奇怪的临时阶段，有一段时间你只需要擅长构建产品就够了，因为那时做产品实在太难了，或许你并不需要对特定客户有深刻理解。

I think we might have been in this weird temporary phase where for a while, you could just it was so hard to build product that you mostly just had to be really good at building product and it maybe didn't matter if you had an intimate understanding of a specific customer.

但现在我认为我们正达到这样一个阶段：如果只能选择理解一件事，那真正理解特定客户面临的问题将变得极具意义。

But now I think we're getting to this point where actually, if I could only choose one thing to understand, it would be really meaningful understanding of the problems that a certain customer has.

如果我只能具备一项核心能力。

If I could only go in with one core competency.

所以我认为这最终仍将是最重要的因素。

So I think that that's ultimately still what's going to matter most.

如果你今天要创办新公司，并且对当前AI工具服务不足的客户群体有深刻理解和人脉网络，我认为你就稳了。

If you're starting a new company today, and you have a really good understanding and network of customers that are currently underserved by AI tools, I think you're set.

对吧？

Right?

而如果你只是擅长搭建网站这类技能，却没有明确的客户对象，那你的处境会艰难得多。

Whereas if you're, like, good at building, like, you know, websites, but you don't have any specific customer to build for, I think you're in in for a much harder time.

按我的理解，你是在看好垂直领域AI初创公司。

Bullish on vertical AI startups is what I'm hearing.

是的。

Yeah.

我完全同意。

I completely agree.

你知道，有些通用方案能解决很多问题，但有些方案则专注于把演示做得极其出色——我们会比任何人都更懂演示问题，会融入你的工作流程，会解决所有与这个特定问题相关的细节。

There's like, you know, there's like the general thing that can solve a lot of problems, then there's like, we're gonna solve presentations incredibly well, and we're gonna understand the presentation problem better than anyone, and we're gonna plug into your workflows and and all these other things that matter for a very specific problem.

好的。

Okay.

太棒了。

Incredible.

当你思考Codex的进展时，我猜你们有一堆评估指标，还有各种公开基准测试。

When you think about progress on Codex, I imagine you have a bunch of evals and there's all these public benchmarks.

你们会关注什么指标来判断进展良好？

What's something you look at to tell you, okay, we're making really good progress?

我猜不会是单一指标，但你们主要关注什么？

I imagine it's not gonna be the one thing, but what do you focus on?

你们正在重点推进什么方向？

What's like something you're trying to push?

有哪些关键绩效指标？

What's like a KPI or two?

我时常提醒自己的一点是，像Codex这样的工具本质上是一种你会逐渐成为高级用户的工具。

One of the things that I'm constantly reminding myself of is that a tool like Codex sort of naturally is a tool that you would, you know, become a power user of.

对吧？

Right?

因此我们可能会无意中花费大量时间思考那些用户采用旅程中非常深入的功能。

And so we can accidentally spend a lot of our time thinking about features that are like very deep in the user adoption journey.

所以我们最终可能会过度解决这个问题。

And so we can kind of end up over solving for that.

因此我认为查看D7留存率至关重要。

And so I think it's just critically important to go look at your D7 retention.

只需重新尝试产品，从头开始注册。

Just go try the product, sign up from scratch again.

我有太多ChatchaPity专业账户了，为了充分进行内部测试，我用Gmail注册的这些账户每月要花费我200美元。

I have a few too many, like, ChatchaPity pro accounts that I've just, like in order to maximally correctly dog food, like, sign up for on my Gmail, they charge me, like, $200 a month.

这些我需要报销。

I need to expense those.

但是，你知道，我认为作为一个用户的感受和早期留存数据对我们来说仍然非常重要，因为尽管这个领域正在快速发展，我认为人们使用它们仍处于非常早期的阶段。

But, you know, like, I think just, like, the feeling of being a user and the early retention stats are still like super important for us because, you know, as much as this category is is taking off, I think we're still in the very early days of like people using them.

我们做的另一件事——我认为我们可能是这个领域里最关注用户反馈的团队——就是我们几个人经常在Reddit和Twitter上活跃。

Another thing that we do that might be I think we might be the most user feedbacksocial media pill team out there in this space is a few of us are constantly on Reddit and Twitter.

上面有赞扬也有很多抱怨，但我们非常认真地对待这些抱怨并加以研究。

And there's praise up there and there's a lot of complaints, but we take the complaints very seriously and look at them.

我认为这再次是因为你可以将编程代理用于如此多不同的用途，它往往在特定行为上存在各种问题。

And I think that, again, because you can use coding agent for so many different things, it often is kind of broken in many sort of ways for specific behaviors.

所以我们实际上经常监测社交媒体上的舆论氛围，特别是对于Twitter X来说，它更偏向炒作一些。

And so we we actually monitor a lot just like what the vibes are on social media pretty often, especially, I think for for Twitter X, it's a little bit more hype y.

而Reddit则更负面但更真实。

And then Reddit is a little more negative but real, actually.

所以我开始越来越多地关注人们在Reddit上实际是如何讨论使用Codex的。

So I've started increasingly paying attention to, like, how people are talking about using codex on Reddit, actually.

这一点大家需要知道。

This is important for people to know.

你最常查看哪些子版块？

Which subreddits do you check most?

有没有类似r/codex的版块？

Is there, like, an r codex?

还是

Or

虽然算法在内容推荐上做得不错，但r/codex这个版块确实存在。

I mean, the algorithm is pretty good at servicing stuff, but, like, r slash codex is is there.

好的。

Okay.

我会记下的。

I'll take.

非常有趣。

Very interesting.

如果在Twitter上有人@你，你仍然能看到，但可能不如在Reddit上看到那么有效。

And then if people tag you on Twitter, you still see that, but maybe not as powerful as seeing it on Reddit.

嗯，是的。

Well, the yeah.

有趣的是，Twitter的特点在于它更像是点对点的交流，即使是在公开场合。

And the interesting well, the thing with Twitter is it's a little bit more one to one even if it's, like, in public.

而Reddit则有很好的投票机制，而且可能大多数用户还不是机器人。

Whereas, like, with Reddit, there's, like, really good upvoting mechanics, and, like, maybe most people are still not bots.

不确定。

Unclear.

所以你能够获得关于重要事项和其他人看法的良好信号。

So you get you get, like, good signal on what matters and what other people

有意思的是，Atlas，我想简单聊聊这个。

So, interestingly, Atlas, I wanna talk about that briefly.

你们推出了Atlas。

You guys launched Atlas.

我其实发推说过试用了Atlas，但我不太喜欢纯AI的搜索体验。

I tweeted actually that I tried Atlas, then I I don't love the AI only, search experience.

有时候我就是想要用谷歌之类的。

Was just like, I just want Google sometimes or whatever.

比如等着AI给我答案时，

Like, waiting for AI to give me an answer.

我就觉得不想等，而且没法切换模式。

I'm like, I don't wanna and there was no way to switch.

我就发了条推说，嘿，

I just tweeted, hey.

我要换回原来的主页了。

I'm I'm switching back at home.

这个体验不太好。

It's not great.

感觉让OpenAI的几个产品经理难过了，还看到有人发推说好吧。

And I feel like I made some PMs at OpenAI sad, and I saw someone tweet, okay.

我们现在有了这个，我想这原本就是计划的一部分。

We have this now, which I imagine was always part of the plan.

这可能是个例子，说明我们只管发布产品，先看看人们如何使用，然后再想办法完善。

It's probably an example of we just ship we gotta ship stuff, see how people use it, and then we figure it out.

所以我想一点是，我不知道。

So I guess one is that I don't know.

那里有什么东西吗？

Is there anything there?

第二点，我只是好奇，你们为什么要开发一个网页浏览器？

And two, I'm just curious, why are you guys building a web browser?

我曾经参与Atlas项目一段时间。

So I I worked on Atlas for a bit.

现在已经不做了。

I don't work on it now.

但你知道，对我来说这里的部分故事背景是——简单说说我的经历——我当时在做这个屏幕共享的结对编程创业项目。

But, you know, like the a bit of the narrative here for for me, just to tell my story a bit, was like, I was working on this, like, screen sharing, like pair programming startup.

对吧？

Right?

然后我们加入了OpenAI。

And then we joined OpenAI.

所以这个想法其实是构建一个情境感知的桌面助手。

And so the idea was really to build a contextual desktop assistant.

我认为这非常重要的原因是，我觉得每次都要向助手交代所有背景信息，再让它想办法帮你，这真的很烦人。

And the reason I believe that's so important is because I think that it's really annoying to have to give all your context to an assistant and then to figure out how it can help you.

对吧？

Right?

所以如果它能直接理解你想做什么，就能最大限度地为你提速。

And so if it could just like understand what you were trying to do, then it could maximally accelerate you.

因此我现在依然把Codex视为某种情境助手，只是从编码任务这个略有不同的角度切入。

And so I still think of Codex actually as like a contextual assistant from a little bit of a different angle, like starting with coding tasks.

但至少我个人认为——虽然不能代表整个产品——很多工作都是在网页端完成的。

But some some of the thinking, at least for me personally, I can't speak for the whole product, but was that a lot of work is done in the web.

如果我们能构建一个浏览器，就能以更原生方式为你提供情境支持。

And if we could build a browser, then we could be contextual for you, but in a much more first class way.

我们不像其他桌面软件那样需要各种兼容性处理，那些软件对渲染内容到无障碍树的支持参差不齐。

We weren't hacking like other desktop software, which have like very varied support for for like what content they're rendering to the accessibility tree.

我们不必依赖速度较慢且不可靠的屏幕截图。

We wouldn't be relying on screenshots, which are a little bit slower and unreliable.

相反，我们可以直接嵌入渲染引擎，对吧？

Instead, we we we could like be in the rendering engine, right?

并提取任何我们需要的信息来帮助你。

And like extract whatever we needed to, to help you.

我还喜欢用电子游戏来类比，比如不知道你玩过《光环》没有？

And also I like to think of like, you know, video games, like, I don't know if you've played, like, I don't know, say Halo, right?

就像你走向一个物体。

Like you walk up to an object.

其实很多游戏都是这样的。

I mean, this is true for many games.

你按下按键，伙计，已经很久了。

You press, man, it's been a long time.

这有点尴尬。

This is embarrassing.

按下x键，它就会自动执行正确的操作。

Press x, and it just does the right thing.

对吧？

Right?

我是那种每买一个电子游戏都会仔细阅读说明书的人。

And I was one of those guys who always read the instruction manual for every video game that I bought.

还记得我第一次读到关于情境化操作的概念时，就觉得这真是个超酷的点子。

And I remember the first time I read about a contextual action, and I just thought it was, like, this really cool idea.

要知道，关于上下文操作的关键在于我们需要了解你试图做什么。

And, you know, the thing about a contextual action is we need to know what you are attempting to do.

我们需要掌握一些上下文信息，这样我们才能提供帮助。

We need have a little bit of context and then we can and then we can help.

我认为这至关重要，因为想象一下我们即将到达的那个世界，在那里每天有智能代理为你提供数千次帮助。

And I think this is critically important because, you know, imagine this world that we reach, right, where where we have agents that are helping you thousands of times per day.

想象一下，如果我们只能通过推送通知来告诉你我们帮了你。

Imagine if the only way we could tell you that we helped you was if we could like push notify you.

那么你每天会收到一千条AI推送通知，写着'嘿，我做了这件事'。

So you get a thousand push notifications a day of an AI saying like, Hey, I did this thing.

你喜欢吗？

Do you like it?

那会非常烦人，对吧？

It'd be super annoying, right?

而想象一下回到软件工程领域，比如我正在看仪表盘，注意到某个关键指标下降了。

Whereas imagine going back to software engineering, like, I was looking at a dashboard and I noticed some, like, key metric had, gone down.

那时候AI可以主动查看，并在我盯着仪表盘时直接呈现它对指标下降原因的分析和可能的修复方案。

And, you know, at that point in time, an AI could, maybe go take a look and then surface the fact that it has an opinion on why this metric went down and maybe a fix right there, right when I'm looking at the dashboard.

对吧？

Right?