OpenAI 一线开发现实观察：能同时盯住 10～20 个 Agent、跑小时级任务的人，正在把其他工程师远远甩开|agent|openai|一线开发|工程师|智能体|程序员

编译 | Tina

很多人还在吵“AI 会不会取代程序员”。OpenAI 内部给出的答案是：AI 正在把工程师重新分层。差距不会慢慢拉开，它会被工具放大、被流程放大、被组织放大，最后变成一种很难追回的“复利”。

在 OpenAI，95% 的工程师每天都在用 Codex。PR 先过 AI 的眼，再轮到人；代码评审从每个 10～15 分钟压到 2～3 分钟；真正拥抱工具的人，提交的 PR 数量比同事高出 70%，而且差距还在继续扩大。工程师的角色也跟着变形：越来越像“Tech Lead + 调度员”，同时盯着 10～20 条并行的 Codex 线程，主要工作变成引导、验收、兜底，亲手写代码反倒成了偶尔为之。

Sherwin Wu 是 OpenAI API 与开发者平台工程负责人。几乎所有 AI 创业公司都在集成 OpenAI 的 API，因此 Sherwin 对整个生态正在发生什么、以及未来走向，有一个极其独特、广阔的视角。

他在播客里还丢了一个判断：很多公司今天引以为豪的 AI“脚手架”——向量数据库、Agent 框架、复杂流程编排——可能只是一段过渡期的拐杖。模型进化会把它们吞掉。真正跑出来的团队已经换了打法：为模型将要到达的能力提前设计工作流，产品现在只有 80% 好用也能上线，等下一代模型升级，直接跨过那条门槛。

AI 也不会平均抬升所有人。它会把高主观能动性的工程师推到一个“不成比例”的高度：能拆需求、能控上下文、能调度多 Agent、能把验证闭环做扎实的人，一个人就能顶过去一个小团队。随之而来的不只是所谓“一人独角兽”，更像是组织结构被迫重写：更小团队、更快迭代、更陡分化。

工程之外，Sherwin 认为更被低估的机会在业务流程自动化：现实世界的大多数工作运行在可重复、强约束、标准作业流程里。AI 真正深入这些流程，改变的将是企业运作方式本身，而不只是效率。

如果你觉得最近两三年的变化快得让人焦虑，那你没感觉错。Sherwin 的话更像是在提醒我们：这其实是一个不会持续太久的窗口期。变化总有一天会放缓，但如果错过了这一段，很多人可能连这套“新分层的规则”都还没来得及学会。

我们翻译了这期播客。

1 Agent 时代的工程分层，已经在 OpenAI 出现

主持人：Sherwin，非常感谢你来到节目。我想从一个现在几乎成了 AI 进展“晴雨表”的问题开始，尤其是在工程领域。你自己现在还写代码吗？如果写的话，你和你的团队，现在有多少代码是由 AI 写出来的？

Sherwin Wu：我现在偶尔还会写代码。不过说实话，对像我这样的管理者来说，现在用 AI 工具反而比手写代码更容易。

就我个人，以及 OpenAI 里的一些工程管理者来说，我们的代码基本都是由 Codex 写的。从更宏观的角度看，内部有一种非常强烈、非常真实的能量感——大家都在感叹这些工具已经走了多远，Codex 对我们来说已经有多好用。

我们其实很难精确衡量“到底有多少代码是 AI 写的”，因为绝大多数代码——我会说接近 100%——几乎都是先由 AI 生成的。

我们真正去跟踪的指标是：现在绝大多数工程师每天都会用 Codex。

95% 的工程师在日常使用 Codex，100% 的 PR 每天都会被 Codex 审查。也就是说，任何最终合并、进入生产环境的代码，Codex 都会“看一眼”，并在 PR 阶段提出改进建议、指出潜在问题。

但比这些数字更让我兴奋的，是那种整体的氛围和能量。

我们还有一个有意思的观察：使用 Codex 更多的工程师，会打开明显更多的 PR。他们提交的 PR 数量比不常用 Codex 的工程师多 70%，而且这个差距还在扩大。

我感觉那些 PR 打得多的人，正在不断学习如何更高效地使用这个工具，这个 70% 的差距随着时间推移还在继续拉大。说不定现在这个数字已经比我上次看到的更高了。

主持人：我确认一下我理解得对不对：你的意思是，在 OpenAI，那 95% 的工程师，他们的代码基本都是AI 先写，然后由他们来 review？

Sherwin Wu：对，对，没错。

主持人：听起来很疯狂，但又好像已经不那么疯狂了，我们正在迅速适应这种状态。当然，我觉得还是需要一点时间来适应。

Sherwin Wu：是的，确实还在适应中。也有一些工程师，对 Codex 的信任度相对低一些。但几乎每天，我都会听到有人被它做出来的事情震惊到，然后他们对模型“可以独立完成多少事情”的信任阈值，一次次被拉高。

Kevin Weil（我们的科学副总裁）有句话我特别喜欢。他常说：“这是模型此生最差的一刻。”这句话放到软件工程上同样成立：时间越往后走，人们会越来越愿意把关键工作交给模型，而模型本身也只会变得更强。

主持人：Kevin Weil 之前也上过这个节目，他在节目里也说过这句话，而且说了不止一次。最近 OpenClaw（之前叫 Claudebot / Moltbot）的开发者 Peter 也分享过，他在工作中大量使用 Codex。他说很多时候，Codex 做完事情之后，他几乎是完全信任的，甚至觉得可以直接合并进 master 分支，结果也会很好。

Sherwin Wu：对，他确实是 Codex 的一个非常优秀的用户。我知道他和我们团队保持着很密切的沟通，也给了很多很好的反馈，所以我一点也不意外他会这样用。

主持人：回到这个我们正身处其中的疯狂时刻，尤其是对工程师来说。我们已经从“你要亲手写下每一行代码”，变成了“AI 写你所有的代码”。我真的想不出还有哪个职业，在短短几年内发生了这么剧烈、而且完全出乎预料的变化。一个工程师整个职业生命周期里的“工作内容”，在这两年里被彻底重塑了。那你怎么想象，接下来一两年里，软件工程师这个角色会变成什么样？这个“工作本身”会是什么？

Sherwin Wu：说实话，看到这一切真的非常酷。这种兴奋感的一部分，就来自于：这个职业在未来一到两年里，很可能还会发生一次非常显著的变化。

但我们现在也还在摸索阶段。对很多工程师来说，这正是一个非常罕见的窗口期——在接下来的 12 到 24 个月里，我们几乎可以亲手定义标准，定义“工程师应该是什么样”。

目前大家常说的一种趋势是：IC 工程师正在变成技术负责人，基本就像是管理者一样。他们在管理一整支又一整支的 agent“舰队”。

我团队里的很多工程师，实际上同时在拉着10 到 20 条并行的线程。当然不是同时跑着 10 到 20 个 Codex 任务，但确实是在处理大量并行的工作：不断查看进度、调整方向、给 agent 和 Codex 提反馈。他们的工作，已经从“写代码”，变成了几乎是在“管理”。

如果要给我一个对未来一到两年的直觉隐喻，我常会想起大学时读过的一本编程教材——《Structure and Interpretation of Computer Programs》（SICP）。这本书当年在 MIT 非常流行，长期作为入门编程课教材，在程序员圈里也有点“邪典经典”的地位。它用 Scheme 来教你编程，引你进入函数式的世界，读起来很开脑洞。

但真正让我记住的，是它开篇对“编程”这件事的比喻：把软件工程说成一种巫术。书里讲，软件工程师像巫师，编程语言像咒语——你念出咒语，咒语就会被释放出去，替你完成事情。难点不在于你能不能念，而在于：你要念什么样的咒语，程序才会按你想要的方式运行。SICP 写于 1980 年，这个隐喻却一直有效。我甚至觉得，它正在被今天的现实真正“兑现”。

从这个角度看，无论是 vibe coding，还是未来的软件工程，都像是这条演进路线的自然延伸。编程语言本来就是咒语，只不过咒语在不断进化，让我们越来越容易让计算机做我们想做的事。而这一波 AI，很可能就是下一站。它把“咒语”这件事推到了极致：你几乎可以直接告诉 Codex、告诉 Cursor 你想要什么，它就会替你把事情做出来。

我尤其喜欢“巫师”这个隐喻，因为眼下的状态越来越像《幻想曲》里的《魔法师学徒》。你戴上魔法帽开始施法，力量强得离谱，但前提是：你得清楚自己在做什么。《魔法师学徒》里，米老鼠让扫帚去干活，自己转身就睡，结果扫帚越干越多、洪水失控、屋子直接被淹——这几乎就是 vibe coding 的极限形态：愿望实现得太快，失控也来得太快。

所以，当我看到工程师同时跑着 20 个 Codex 线程时，我想到的并不是“爽”，而是这背后其实需要技能、资历和大量判断力。你不能彻底放手不管，也不能假装一切都会自动变好。

但它的杠杆率也确实高得惊人。一个真正把这些工具用顺了的资深工程师，现在能完成过去根本不可能完成的工作量。这也是它迷人的地方：我们真的开始有一种很具体的感觉——自己像个巫师在施法，而软件在替我们跑腿、替我们干活。那种“魔法感”，前所未有地接近现实。

主持人：我这里有两个线索想继续追问。其中一个是，我最近越来越多地听到一种反馈：当智能体不按预期工作时，人会产生很强的压力。你一下子发出去一堆 Codex agent，然后就得时刻盯着它们——“这个不跑了”“那个卡住了”，感觉时间在被白白浪费。你自己有这种感受吗？你在团队里也看到这种情况吗？

Sherwin：有的，有的，这种情况一直都在发生。说实话，我反而觉得这是当下最有意思、也最关键的地方。因为模型并不完美，这些工具也不完美，我们其实还在摸索：到底该怎么和 Codex、和这些 AI 智能体协作，才能把事情真正做成。这类问题在我们内部经常出现。

我们有一支特别有意思的团队，正在 OpenAI 内部做一个实验：他们维护的是一个100% 由 Codex 编写的代码库。一般情况下，你可能会让 AI 先写一版代码，然后再自己重写一部分、检查一遍、修修补补；但这个团队是完全 “Codex 化”，几乎是彻底 lean in。

小编注：Sherwin Wu 提到的这次实验，OpenAI 已经写成博客公开了：https://openai.com/index/harness-engineering/。文章记录了一个“0 人手写代码”的软件工程实验：团队用 5 个月从空 Git 仓库起步，做出一个真实可用的内部产品——能上线部署、会出故障也会被修复，且已经被数百名内部用户使用（包括每天都在用的重度用户）。但从头到尾没有任何人工直接写代码：应用逻辑、测试、CI 配置、文档、可观测性、内部工具，全部由 Codex（Codex CLI + GPT-5）生成。最终在仅 3 名工程师驱动下，累计合并约 1500 个 PR、产出接近 100 万行代码；他们估算整体交付速度约为传统手写的 1/10。

于是他们就会遇到你刚才说的那种问题：比如我想把某个功能做出来，但怎么都让 agent 做不对。通常这时候，人是有“逃生出口”的——你可以说“算了，我自己撸袖子来”，不用 Codex，改用 tab complete、Cursor 之类的工具直接手写。但这个实验团队没有这个出口，这是实验设计的一部分。

所以问题就变成了：我到底要怎么做，才能让这个 agent 把事做好？其中一个我们反复看到的现象是——不知道你有没有类似感受，但我们这边非常明显——很多时候，编码智能体做不好，并不是“它不行”，而是上下文出了问题。要么是你给的信息不够明确，要么是 agent 根本拿不到完成这件事所需要的信息。

一旦你意识到这一点，解决方式就会发生变化：你不再是去“调 prompt”，而是开始补文档、补结构，想办法绕过这个限制。说白了，就是把你脑子里的“隐性经验”“团队共识”“默认做法”，想办法编码进代码库里——可能是代码注释，可能是代码结构，也可能是一些 Markdown 文档、skills 文件，或者仓库里的其他辅助资源。目标只有一个：让模型在仓库里就能读到它完成任务所需要的一切信息。

这个团队还有很多其他收获，我觉得都非常值得展开聊。但至少有一点已经很清楚了：刻意拿掉“不用 AI 的退路”，反而逼着他们看清楚——如果我们真的要全面拥抱 agent，这些问题是迟早都要解决的。

2 把工程师对 PR 的注意力，从 100% 降到 30%

主持人：我们刚才聊到，使用 AI 的人疯狂地在发 PR，PR 数量明显变多了。显然，代码评审现在会变成更大的挑战。你们团队有没有摸索出什么办法，让 code review 也能更快、更规模化，而不是把大家变成“每天坐在那里审 PR 的苦力”？

Sherwin Wu：有的。首先，现在Codex 会评审我们 100% 的 PR。

我觉得这里发生了一件特别有意思的事：我们最先交给模型去做的，往往就是那些最烦人、最无聊的软件工程部分。也正因如此，现在写软件反而更有趣了——我们可以把更多时间花在真正有意思的事情上。

就我个人而言，我以前特别讨厌 code review，真的属于我最不喜欢的工作之一。我记得我大学毕业后的第一份工作是在 Quora。我当时负责 Newsfeed，所以 Newsfeed 那块代码基本归我“所有”，我也就成了 Newsfeed 的主要 reviewer。那段代码是整个系统里最核心的一块，几乎所有人都会动它。

结果就是，我每天早上一登录，就看到20 到 30 个 code review，我会直接心里一沉：“天啊，我得把这些全过一遍。”我经常会拖延，然后待审的 PR 会涨到50 个。review 的量非常大。

Codex 在 code review 这件事上真的很强。我们观察到一个现象：5.2（GPT-5.2 这一代）尤其擅长审代码，尤其是你能把它引导到正确方向的时候。

所以我们这里虽然 PR 的量确实变多了，但 Codex 会先过一遍所有 PR，这会让 code review 从原来那种10～15 分钟的任务，变成很多时候2～3 分钟就能搞定的任务，因为它已经提前把一堆建议“烤”在里面了。

很多时候，特别是一些小 PR，你甚至不一定需要再拉人来 review。我们在某种程度上会信任 Codex。因为 code review 的核心价值就是“第二双眼睛”帮你确认你没有做蠢事——而现在 Codex 已经是一双相当聪明的第二双眼睛了，所以我们在这点上非常用力地 lean in。

另外，我们内部现在 CI 流程、以及 push 之后到部署的那套流程，也已经大量通过 Codex 自动化了。

如果你问很多工程师最烦的是什么，往往不是写代码本身，而是：你写完一段漂亮的代码之后，怎么把它送进生产环境。你得跑一堆测试，要处理 lint error，要走 code review……这里面有很多流程性的工作。

这些东西其实都很适合让 Codex 来做，所以我们内部也做了一些工具去自动化这些步骤，比如自动处理 lint：如果出现 lint error，Codex 通常很容易就能修掉，它可以直接 patch，然后重启 CI 流程。

我们总体在做的事情，就是尽可能把工程师需要投入的“人肉操作”压缩到最少。副作用（其实是好处）就是：大家现在可以合并更多 PR、发布更多代码。

主持人：Codex 在写代码，Codex 也在 review 自己写的代码。我很好奇，你们会不会考虑用别的模型来 review 你们模型的工作？这是不是一个方向？还是说现在这样已经够好了，不需要其他东西？

Sherwin Wu：我会说，这里确实存在一种“循环”的风险。回到《魔法师学徒》的隐喻，你得确保自己没有让扫帚失控、满屋乱跑。

所以我们在“哪些 PR 可以完全由 Codex review”这件事上，其实是很谨慎的。大多数人当然还是会自己看一眼自己的 PR，并不是说人类 review 就彻底归零了。

更准确的描述是：把一个人对 PR 的注意力从100% 降到 30%。这样就能让事情更顺畅地推进。

至于“多个模型”的问题，我们内部当然会测试很多模型，所以我们手上有大量不同的版本。但我们相对少用外部模型——因为我们认为“吃自己的狗粮”很重要，要用自家的模型去做实际工作，从而获得真实反馈。

当然，你也可以用一些内部的不同变体模型来获得另一种视角，我们发现这种方式也挺有效。

主持人：我再确认一下我对 OpenAI 当下“AI + 代码”现状的理解，确认完我想切换到另一个话题。你是说，现在 OpenAI 全部的代码，100% 都是 Codex 写的？这样表述对吗？

Sherwin Wu：我不会直接说“今天在生产环境里跑的所有代码都是 AI 写的”。这句话我不会这么下结论，因为很难在归因上做得那么精确。

但可以肯定的是：几乎每一个工程师，在所有任务中都非常重度地使用 Codex。如果你让我估一个大概的比例，我会说：现在绝大多数代码，很可能最初的作者就是 AI。

3 AI 时代，管理者的杠杆在谁身上？

主持人：大家讨论很多的是 IC（个人贡献者）工程师的角色变化，但关于“管理者”的变化讨论得少得多，尤其是工程经理这种角色。AI 崛起之后，你作为一个 manager 的生活发生了什么变化？你觉得未来 manager 的角色会是什么？

Sherwin Wu：它的变化确实没有工程师那么大。至少现在还没有“专门给管理者用的 Codex”。不过，我确实会用 Codex 去处理一些我做的“更管理向”的工作。我会说，现在变化还没有那么剧烈，但我能看到一些趋势。你把这些趋势推演下去，就能大概看到很多事情会往哪里走。

一个越来越明显的点是：Codex 会让顶尖表现者变得更高效得多。我觉得这可能也是 AI 在更大范围内的普遍规律：那些真正愿意深度拥抱、那些主观能动性很强的人，或者能把这些工具用到很溜的人，会把自己“超级加速”。

我现在也能明显感觉到：团队里顶尖表现者会变得更多产，于是团队生产力会出现更大的分化和跨度。

我一直以来的一个管理理念是：我会把大部分时间花在顶尖表现者身上——确保他们不卡住、确保他们开心、确保他们觉得自己在高效推进、也觉得自己的声音被听见。

我觉得在 AI 时代，这件事会变得更重要，因为顶尖表现者会用这些工具跑得更快、更猛。

比如之前提到的那个团队：维护一个100% 由 Codex 生成的代码库。让他们放开去做、看看会发生什么，这件事实际上回报非常大。所以我看到的一个趋势是：对于管理者来说，未来可能会更频繁地、更多地把时间投入在顶尖表现者身上。

另一个趋势是：管理者可用的 AI 工具，会让管理者的杠杆率变高。不是写代码层面的，而是像“带组织知识的 ChatGPT”这种——它能帮你做研究、理解组织上下文。举个很现实的例子：我们现在在做绩效评估。你可以很容易地用一个接了内部知识的 ChatGPT——它连着 GitHub、Notion 文档、Google Docs——让它快速形成对某个人过去 12 个月做了什么的完整理解，然后给你写一份小型“深度研究报告”。

我的直觉是，在这种世界里，管理者可以管理更大的团队。就像工程师现在在管理 20～30 个 Codex 线程一样，这些工具也会让“人管人”的管理变得更高杠杆。

现在工程团队里所谓的最佳实践，一个 manager 通常带6～8 个人。但我觉得未来可能会变。

你在客服、运营这些非工程领域已经能看到类似现象：过去支持团队规模会受限，但当你能把更多工作交给 agent，你就能做更多事，也能管理更多人。

我觉得 people management 在科技公司也可能发生类似变化。我们已经在看到一些团队：有些 EM 管的人已经不少了，但他们依然能管理得很好，因为工具让他们能更高杠杆地理解团队在做什么、理解组织上下文，并以此运转。

主持人：我很喜欢你这里的建议：你一直以来都会倾向于把更多时间投在顶尖表现者身上，帮他们扫清障碍，确保他们开心。Mark Andreessen （著名风投创始人）最近也上了这个播客，他的说法是：AI 会让好的人更好，让伟大的人变得卓越。

Sherwin Wu：对，对。你说的这个点就是：在未来，这件事可能要做得更多、更极端一点——花更多时间在团队里最强的人身上，确保他们有一切需要的资源。

我现在的一个很好的例子是：内部有一小群工程师，真的非常“Codex 化”，他们在非常认真地琢磨“和这个模型交互的最佳实践到底是什么”。这是一件极其高杠杆的事情。

作为 manager，我就是直接说：你们去探索。无论你们总结出什么最佳实践，我们都必须把它分享给整个组织。我们会做各种知识分享 session，会把文档、最佳实践到处同步。

这种事情会把所有人一起往上抬。我也把它看作是这种趋势的又一个例子：顶尖表现者会变得更卓越。

4 软件与创业，正在进入一个新阶段

主持人：人们会有一种感觉：这件事很大，AI 正在改变这个世界，“一人十亿美元公司”这个概念正在改变很多东西，它会是一件大事。你觉得大家还没有真正把哪些变化算进去？也就是，未来会怎么走，有什么你认为我们还没意识到、但其实很关键的例子？

Sherwin Wu：这波 AI 浪潮里，我最喜欢的一个说法，就是“一人十亿美元公司”。我记得好像是 Sam 最早说出这个概念的（至少是最早把它讲出来的人之一）。它真的很耐人寻味：如果一个人的杠杆变得足够高，某个时间点上，确实可能出现一个“一人十亿美元公司”。

这件事本身当然很酷，但我觉得大家还没有真正把它的二阶、三阶影响算进去。

因为“一人十亿美元公司”背后隐含的意思是：一个人借助这些工具，可以拥有更强的主观能动性、更高的杠杆，于是他很容易就能把一个公司需要做的所有事情都搞定，最终做出一个价值十亿美元的东西。但这还只是其中一个层面。它还有其他含义。

其中一个二阶影响是：如果一个人都能做到“一人十亿美元公司”，那也就意味着——创业这件事整体会变得容易得多。我其实认为，这会引发一个巨大的“创业潮”，尤其是那种偏 SMB（中小企业）风格的小型创业潮：几乎任何人都可以为任何需求做软件。

你现在已经能在 AI 创业圈里看到一点苗头：软件正在变得更“垂直化”。也就是，为某个特定行业 / 垂直领域做一个 AI 工具往往非常有效，因为你能更深地理解那个领域的实际场景和用例。

如果把 AI 的演进继续往后推，我看不出有什么理由不会出现 100 倍数量的这类创业公司。

所以我设想的一个世界是：为了支撑一个“一人十亿美元公司”，可能会出现上百家小型创业公司，专门做高度定制、做得非常贴合需求的“bespoke software”，来为这些公司提供支持。

这会把我们带进一个可能非常有意思的阶段：我们可能真的会进入一个B2B SaaS 的黄金时代，甚至更广义地说，是软件与创业的黄金时代。因为随着写软件越来越容易、经营公司越来越容易，你最终看到的，很可能不是“只有一个一人独角兽”，而是——也许会有一个“一人十亿美元公司”，但同时还会有一百家一亿美元公司，还会有几万家一千万美元公司。

而对个人来说，一千万美元的生意其实已经非常好了——那基本就意味着“这辈子稳了”。所以我觉得我们可能会在这个方向上看到一次爆炸式增长，而很多人还没把这一点真正算进去。

再往下一层——算是三阶影响——当然越往远推不确定性越大，但如果我们真的走向这样一个世界：到处都是这种“微型公司”，做的软件可能只服务一两个人，公司也就是一两个人在拥有、在运营。

那整个创业生态会变，VC 生态也会变。

我们可能会进入一个世界：只有少数几个超级大玩家提供平台，然后平台上托举、支撑着大量小公司。

但与此同时，那种真正符合“风险投资尺度”的项目——能把你的投资翻 100 倍、1000 倍的项目——可能反而会变少。因为更多出现的会是大量 1000 万到 5000 万美元的公司：它们对个体来说非常棒，但对 VC 来说未必是理想的回报结构。

这些公司会非常适合那些主观能动性极强的人——他们深度拥抱 AI，为自己打造业务。

主持人：我太喜欢我们一路聊到第几阶影响了。我现在想听第四阶影响了，Sherwin——开玩笑的。

Sherwin Wu：我真的不行，第四阶太“巨脑”了，我想不了那么远。

主持人：这就像《盗梦空间》一样，你每往下一层，时间就变慢，事情就更复杂。不过说回“一人十亿美元公司”，我确实经常想这个问题。因为我做的事情不可能变成十亿美元公司，它完全不符合 VC 尺度，也不算特别高杠杆。

但我会想到一个现实问题：我每天收到的支持工单实在太多了，而且经常是一些特别离谱、特别琐碎的事。光是“支持成本”这一块，就让我很难想象一个人怎么能撑起十亿美元规模。所以我对“一人十亿美元公司”这件事其实是偏谨慎、甚至偏悲观的。我想分享这个观点，核心就是：支持成本太难规模化。就算 AI 能帮你一部分，在十亿美元规模下，除非你的 ACV 很高、客户很少，否则光是处理支持和各种人类沟通，就很难扩张。

在我自己的经验里，很多用户其实是能自己解决问题的，但他们还是会选择给支持邮箱发一封邮件问一个小问题。处理这些事非常难规模化。所以除非你雇了一堆承包商——但那还算“一人公司”吗？——否则我觉得要把公司做大到十亿美元，同时又没有人帮你处理至少支持工作，这几乎不可能。AI 也只能帮到一定程度。

Sherwin Wu：我同意你说的这个问题。只不过我对“它会怎么发生”的看法稍微不一样。

我甚至觉得，Lenny，你的播客未来可能会变成一个十亿美元级别的生意。但它发生的方式可能不是：你一个人去派遣 AI，一张一张处理支持工单、修问题、回邮件。

更可能发生的是：会出现一大堆其他创业公司，专门做非常贴合你需求的软件，而且是高度定制、极其垂直的那种。比如，可能会有 10 家、20 家创业公司，专门为播客、newsletter 这类业务做支持软件。它们自己可能就是“一人公司”，不一定要做得很大。

因为在这个世界里，做出一个产品会变得非常容易。他们可以把产品做得很贴合、很独特、真的对你有用，然后你会愿意为它付费——作为那个“高杠杆的一人公司”，你买这些工具来外包掉那些你不想做的事情。

主持人：我会买的，我真的会买。

Sherwin Wu：对，这里面有一个关键问题就是：哪些你要 in-house，哪些你要外包出去。

我觉得可能发生的事是：因为写软件、做产品的成本在极速坍塌，你会把更多东西外包出去。于是你反而能把公司规模压得更小。

这就是我觉得可能出现的世界。当然这里仍然有很高的不确定性，但最终形态可能仍然是：由一个人驱动的、极高杠杆的公司，真的有机会做到十亿美元规模。

主持人：我能理解。我还会想到 Peter（OpenClaw 那位），他现在被各种需求、邮件、私信、DM、PR 完全淹没。而且他甚至还没靠这个赚到钱。我真的很难想象他现在的生活是什么样——一定非常疯狂。这大概就像你们当初发布 ChatGPT 后的那几个月那种疯狂，但他是一个人扛着。也许第四阶影响就是：分发 / 触达（distribution）会越来越重要。因为有太多东西在争夺你的注意力。于是拥有受众、拥有平台的人会越来越值钱——这倒是挺有意思的。

主持人：好，我其实想回到你刚才说的管理话题。我真的很喜欢你那个洞见：你说把更多时间花在顶尖表现者身上，对你来说非常有效。你现在在带的团队是在做平台，而这个平台基本驱动着整个 AI 经济——几乎每个 AI 创业公司都在用你们的 API。显然你做得非常好。那除了这一条，你还有哪些核心的管理经验？你觉得哪些东西对你作为一个工程团队、以及人的管理者来说，特别重要，也构成了你成功的关键？

Sherwin Wu：我学到的很多东西，我不确定是不是特别“OpenAI API 团队专属”，或者是不是只适用于我们的一些 enterprise 产品。

我的管理哲学确实在变化，但整体来说，它更多是保持一致，而不是完全翻新。其中一个原则就是我之前说的那条：把大量时间花在顶尖表现者身上。更具体一点说，我会把超过 50% 的时间花在团队里最强的那部分人身上，比如前 10%，尽最大努力去赋能他们。

我常用一个隐喻来理解这个问题：把软件工程师看作“外科医生”。这个隐喻来自一本很老的书《The Mythical Man-Month》。这本书写于 70 年代左右，它里面其实是在“预测未来”。书里描述了一种可能的世界：软件工程会走向一个模式——工程师像外科手术室里那位主刀医生，手术室里只有一个人真正动刀，其余的人都围绕他提供支持：护士、住院医、fellow……主刀说“我要手术刀”，就有人把手术刀递上去；主刀说“我要这个工具”，就有人把设备推过来。所有人都在支持那一个人。

《人月神话》预测软件工程会往这个方向走。我不觉得现实完全是这样——软件工程仍然更协作，不是只有一个人干活。

但我一直很喜欢这个比喻，也一直努力把它用在我的管理方式里。也就是说：软件工程不等同于手术，但我希望我对团队成员的支持方式，能让他们感觉自己像那位“主刀医生”——他们在推进最关键的工作，而我作为 manager 的职责，就是确保他们手里有一支“支持团队”，确保他们需要的东西随时可用。哪怕实际上所谓的支持团队只有我一个人，我也希望做到这种效果。

我常举的例子就是：提前看见拐角处的阻碍，并把人从组织流程里解卡出来，这件事极其有价值。

而且在 AI 时代，这件事更重要。因为当工程师能一口气刷很多 PR、连续高频交付时，真正限制进展与交付速度的，往往就变成了组织层面的阻碍、流程层面的阻碍。

如果你作为 manager 能够“看得更远一步”、提前准备好他们需要的资源——就像主刀医生需要手术刀，而你已经把手术刀准备好了——那就是最理想的状态。这就是我理解的管理方式，尤其是工程管理。这个隐喻一直跟着我，也基本贯穿了我的职业生涯。

主持人：我太喜欢这个比喻了。我甚至会想，AI 会不会也能帮到这件事：帮你“看拐角”。比如预测：这个工程师接下来会被哪个决策卡住，我们得提前把它解决掉。

Sherwin Wu：我还没试过，但我现在突然很好奇：如果我问一个接了公司内部知识的 ChatGPT——比如让它去扫 Notion 文档，看看 Slack 里哪里提过——我直接问它：“我团队现在有哪些活跃的 blocker？我能做什么来帮他们？”这个思路我之前真的没想到，但你说得对，你刚刚给了我一个洞见。

主持人：而且更进一步，甚至可以问：你预判接下来几个月这个工程师、这个团队会被什么卡住？你刚才在聊二阶三阶影响，现在我让模型帮你做二阶三阶影响：提前预判下个月的 blocker，提前把它解决掉。

Sherwin Wu：对，对。我们这里可能真的挖到一个好点子了。

5 为什么这么多 AI 部署，最后成了负 ROI？

主持人：好，我想切到你们做的 API 和平台。你们会和很多公司打交道：它们在接入你们的 API、用你们的平台、基于你们的工具去做产品。你之前跟我说，你观察到很多公司的 AI 部署其实 ROI 是负的。我觉得这也是很多人读新闻、自己体感里隐约相信的结论，但你说你真的在一线看到它发生，这很有意思。到底怎么回事？他们哪里做错了？现在 AI 部署与 ROI 的现实状况是什么？

Sherwin Wu：我先澄清一下：我并不是在“显式地”看到那种可量化的 ROI 数据——这件事其实很难测。但仅凭我观察到的一些公司“上 AI”的方式，我不会惊讶如果不少部署最后落成了负 ROI。与此同时我也注意到，在科技圈外——比如美国很多非技术行业的人群里——存在一种很普遍的情绪：AI 是被强塞进来的。而这种抵触感，本身很可能就是“负 ROI 部署”的外在症状之一。

我看到的典型问题大概有几个。

首先，我总会回到一个老问题：硅谷经常忘了自己活在泡沫里。Twitter 是泡沫——抱歉，现在叫 X——硅谷是泡沫，软件工程也是泡沫。世界上绝大多数人、美国绝大多数人，都不是软件工程师。他们没有那么 “AI pilled”（被 AI 深度洗礼），也不会追踪每一次模型发布。很多人其实根本不知道怎么用这项技术，甚至对它怎么工作都没什么概念。

你看我们在 OpenAI 内部，会聊很多 Codex 的 best practices，甚至有一群人专门研究怎么把 Codex 用到最有效。X 上那些经常发帖的人，也几乎都是 AI 工具的疯狂 power user：skills、agents.md、MCP……这些他们都玩得很溜。

但当我去和很多公司聊，尤其是和真正要把工具用到日常工作的一线员工聊时，你会发现他们的需求非常基础，而他们对这项技术的理解也很有限。他们问的问题都很简单，离“把工具推到极限”还差得很远。

这也引出了我觉得更理想的 AI 部署方式应该是什么样——也是我们在 OpenAI 内部大体上是怎么运转的：那些“做得很顺”的公司，往往同时具备两件事。

第一，是自上而下的 buy-in。高层明确表态：我们要变成 AI-first 公司。于是资源会投入、工具会采购、组织会给到明确支持。

但第二同样关键：必须有自下而上的 adoption 和 buy-in。也就是那些真正干活的一线员工，要对这项技术感到兴奋，愿意学习、愿意布道、愿意总结 best practice，愿意在组织里做知识分享。

我们在 OpenAI 内部也经历过类似过程。OpenAI 一直希望自己以 AI 为中心，但真正让这件事“起飞”的，是 Codex 这类工具出现之后——因为员工终于能把它直接用到具体工作里。

你之所以需要自下而上的推动，是因为每个人的工作都不一样、非常具体。软件工程不等于财务，不等于运营，也不等于市场销售。落地到工作层面，会有大量“最后一公里”的细节，必须靠一线的人去试、去打磨、去改 workflow。

而很多 AI 部署之所以失败，恰恰是因为缺少自下而上的 adoption：它更像一条来自高层的命令，过于 top-down，又和真实工作怎么做脱节。结果就是，面对一整个庞大的员工群体，他们并不真正理解这项技术，只知道“我应该用它”，甚至绩效里也写着“你得用 AI 提升生产力”，但没人告诉他们具体怎么用。

他们环顾四周，发现也没有别人真的在用：没人可学、没路径可抄，于是就卡在原地。

所以我给那些想推进 AI 的公司的建议是：找到——甚至专门配备——一个全职的小团队，作为内部的 tiger team。这支队伍负责把能力摸透、落到具体 workflow 上，做持续的知识分享，在组织内部制造兴奋感，让更多人愿意尝试。没有这种机制，AI 真的很难被“捡起来用”。

主持人：那你会把谁放进这个 tiger team？它应该是工程师主导吗？还是你觉得更像一个跨职能团队？

Sherwin Wu：这个问题很有意思。因为现实是：很多公司根本没有软件工程师。所以我看到更常见的一种模式是——tiger team 的核心成员，往往来自“软件工程相邻”的岗位：技术向，但不一定是工程师。

这些人反而最容易先兴奋起来。比如支持团队或运营负责人：他不写代码，但特别爱折腾工具，可能还是个 Excel 高手、流程高手。你会发现，这类人一旦接触到 AI 工具，往往会“亮起来”——上手快、动力足，也愿意主动把用法总结出来。

所以这类 tiger team 的典型画像是：技术相邻、编码相邻，整体技术能力不弱，愿意试、愿意学、愿意带人。你通常可以以他们为核心搭起一个小团队。

当然，工程师加入会很有帮助，他们能更快理解底层机制、也更擅长做系统化落地。但很多公司没有这个条件：工程师是稀缺资源，难招也昂贵。于是很多时候，真正把 AI 推起来的，反而是这些“非工程师但技术向”的角色。

主持人：我听下来，你说的反模式就是：自上而下。比如 CEO 和高管团队拍板：我们要 AI-first，我们要全面拥抱 AI。每个人都会被考核：你用 AI 工具提升了多少生产力。但如果只有自上而下，没有建立一个自下而上“传播与带动”的团队，那这事就做不起来。

Sherwin Wu：对，完全是这样。核心建议就是：找到那些最兴奋的人。与其把他们分散在组织各处，不如把他们聚起来，组成一个小的“AI 传教士团队”。他们去探索怎么用、怎么落地，然后把用法扩散到整个组织。你这么复述我，我突然意识到：这也能和我自己的管理哲学对上。换句话说：找到 AI 采用上的高绩效者，然后赋能他们——让他们办 hackathon，让他们做分享会，让他们做知识分享，在内部种下兴奋感的种子。

6 从向量库到 skills：脚手架正在一层层被吃掉

主持人：我有几个“热观点”想听你展开一下。有一个我看到你经常提到：你说在 AI 领域，“去跟客户聊、听客户的话”不一定总是对的策略，甚至经常会把你带偏。

Sherwin Wu：我不确定这算不算多“热”。我想说的也不是“不该跟客户聊”——当然应该聊，而且非常有价值。

我更想强调的是：AI 这个领域（尤其是我过去三年在 API 这一侧看到的变化）迭代速度实在太快了。模型和整个生态会不断自我颠覆，特别是在工具链、脚手架这一层。

我这周刚看到一句话，来自 X 上的一篇文章，作者是 Nicholas——一家叫 Finol 的创业公司创始人。他分享了不少在金融服务场景做 AI agent 的实战经验（我记得他之前也在一家叫 FinTool 的公司做过类似方向）。他有句话我特别喜欢：“模型会把你的脚手架当早餐吃掉。”

你回看 2022 年 ChatGPT 刚发布的时候，模型还很粗糙。于是开发者工具圈冒出了大量“脚手架式产品”，用来约束、引导模型按你期望的方式工作：各种 agent 框架、向量数据库……那时候向量库尤其火，周边还长出了一大圈配套工具。

但这几年一路看下来，模型变得太快、也变得太强，结果它真的会把其中一部分脚手架“吃掉”。我觉得这件事今天仍然成立。Nicholas 那篇文章提到的“当前时髦脚手架”，是基于 skills 文件的上下文管理。你完全可以想象一个世界：未来某个时间点，这套东西也不再有用，因为模型可以自己管理这些上下文；或者整个范式又会切换到别的方向，不再需要这种文件式的 skills。

你已经亲眼看过这种事发生：agent 框架现在没那么有用了；2023 年一度我们以为向量库会是把组织知识引入模型的“主路径”——你需要把所有语料 embedding、做向量检索，还要做大量优化，保证在正确时间取到正确的信息。

那一整套，本质上都是脚手架，因为模型当时还不够强。而当模型变强后，更好的方式往往是：把很多逻辑拿掉，信任模型本身，给它一组用于搜索的工具就行。

这个搜索不一定非得是向量库，它可以接任何形式的搜索——甚至可以只是文件系统里的文件，比如 skills、agents.md 这种，来引导它。

当然，向量库仍然有它的位置，很多公司还在用。但“围绕向量库搭建整个脚手架生态、把它当成唯一答案”的那种假设，已经发生了很大变化。

所以回到“客户反馈”：你不一定总要听客户的，因为这个领域变化太快。很多客户在某个时点上其实处在一个“局部最优”里。

如果你只盲听客户，他们会说：我想要更好的向量库，我想要更好的 agent 框架……但如果你只沿着这条路走，你可能会做出一个“局部最优”的产品；而当模型能力再上一个台阶时，我们往往需要重新发明、重新思考：什么才是正确的抽象、正确的工具、正确的框架。而更有趣、也更令人兴奋、同时也有点让人抓狂的是：这是一个移动靶。

你今天认为“正确”的工具和框架组合，未来很可能还会继续演化、继续大改，随着模型越来越聪明、越来越强。这就是在这个领域里做产品的本质。这也是它令人兴奋的地方。但它也意味着：你和客户聊的时候，你需要在“他们此刻想要什么”与“你认为模型将往哪里走、未来一到两年会如何演化”之间做平衡。

主持人：这听起来很像所谓的 “bitter lesson”：在 AI/ML 领域里一个重要教训就是——你加得越多复杂逻辑、越多手工设计，反而越限制它规模化成长。你应该尽可能拿掉这些东西，让它计算、让它自己变强。

Sherwin Wu：对，这里确实存在一个“把 bitter lesson 应用到 AI 产品构建”的版本。我们曾经试图在模型周围架构很多东西，结果模型能力提升之后，它会把这些东西直接吃掉。说实话，OpenAI 的 API 团队在某些时候也犯过这个错：我们走过一些不该走的弯路。但模型还是会变强，我们也只能在日常中不断学习这条 bitter lesson。

主持人：那对那些在用 API 构建产品、构建 agent 的人来说，关键 takeaway 是什么？因为他们现在还是得围绕现阶段能力搭一些东西。你会给什么建议？

Sherwin Wu：我一直给大家的总体建议——到今天我仍然觉得成立——是：为模型将要去的地方而构建，而不是只为模型今天能做到什么而构建。

因为目标本质上是个移动靶。我见过不少做得特别好的创业公司，会围绕一种“理想能力”来设计产品：这种能力在当下也许只实现了 80%。所以他们的产品现在当然“能用”，但总像差最后一口气。

可一旦模型能力再往前迈一步，体验会突然“咔哒”一下被解锁：原本差的那一口气补上了，产品整体就从“勉强可用”变成“非常惊艳”。

比如某个关键能力在 o3 时代还不够稳，但到了 5.1、5.2 就突然可用了——他们之所以能吃到这波红利，是因为在产品设计时就把“模型必然会变强”当成前提写进了路线图。最终你会得到一种体验：它远远好过那种把模型能力当成静态、围着现状去打补丁的做法。

所以我的建议很简单：按模型未来的走向来设计。你可能需要稍微等一等，但模型变强的速度太快了，很多时候你并不需要等太久。

主持人：顺着这个话题，你能分享一下未来 6～12 个月 API 会往哪走？平台会往哪走？模型会往哪走？我知道这里很多内容可能是机密，但你可以分享多少就分享多少——你最兴奋的、你觉得大家应该开始准备的。

Sherwin Wu：一个最明显的方向是：模型能连续、稳定完成任务的时长正在变长。

有一个我觉得很有参考价值的基准指标（他提到的 meter benchmark），用来跟踪在软件工程任务里，模型能稳定跑多久——比如在50% 成功率下能撑多长时间、在80% 成功率下又能做到多久。

我印象里，当前前沿模型大概是：在 50% 成功率上已经能完成“多小时级”的任务；但如果把门槛提高到 80% 成功率，可能还停留在“接近 1 小时、但还不到”的水平。这个基准指标最让人清醒的地方在于：它把历代模型都放在同一条时间线上，你能非常直观地看到趋势是怎么一步步往前推的。

让我兴奋的是：今天很多产品，其实还在围绕“模型能跑几分钟”来做优化。哪怕是 Codex 这种编码工具，你也会发现它更偏交互式、更像一个随叫随到的协作伙伴——它最擅长、也被优化得最充分的，往往还是十分钟左右的任务。

当然，我也见过有人把 Codex 推到极限，用它去跑多小时级的任务，但那仍然是少数案例，并不是常态。

如果沿着这个趋势继续往前推，我认为在未来 12～18 个月，我们会看到模型能更稳定、更连贯地完成“多小时任务”。甚至可能出现这样的阶段：你把一个大约 6 小时量级的任务交给它，让它自己先跑一段时间，再回来给你结果和进度。

一旦能力到了这个级别，围绕它构建的产品形态会完全不一样。你仍然需要给模型反馈，也肯定不希望它毫无约束地跑上一整天——也许有人会想这么做，但多数场景下不会。而当任务时长真正拉长，模型能覆盖的工作范围会一下子变得更大，能做的事情的“宇宙”也会随之扩张。这也是我最兴奋的一点。

另一个我觉得未来 12～18 个月会很酷的方向，是多模态模型的进步。更具体地说，我主要指音频。

现在模型在音频上已经挺不错了，但我认为未来 6～12 个月，它会变得更强——尤其是那种原生多模态、speech-to-speech 的模型。同时音频侧可能还会有一些新的模型结构、架构方向出现。而音频在企业与商业场景里，仍然是一个被严重低估的领域：大家都在聊 coding，都在聊 text，但我们现在就是用音频在对话。世界上很多业务，就是靠“说话”完成的；很多服务与运营，也是靠沟通完成的。

所以我觉得未来 12～18 个月，音频会变得非常令人兴奋，我们会看到更多“被解锁”的能力。

主持人：我快速总结一下：你认为 agent 和 AI 工具会越来越能跑更长时间的任务，这个趋势会持续增强；然后音频与语音会变得更重要，更原生、更核心、体验更好。

主持人：回到你刚才的“热观点”。我还看到你经常讲另一个：你对“业务流程自动化”这个方向非常看多，觉得它会是 AI 世界里巨大的机会。聊聊这个？

Sherwin Wu：对，这其实又回到我前面说过的那件事：我们在硅谷生活在一个泡沫里。我们熟悉的工作形态——软件工程、产品管理、做产品——跟支撑整个经济运转的大量工作形态，其实完全不是一回事。我跟客户聊的时候经常能强烈感受到这一点：如果你去跟任何一家非科技公司聊，你会发现他们有海量的“业务流程”。

我一般会这样区分：软件工程更像一种开放式的知识工作（open-ended knowledge work）。这也是为什么像 Codex 这种工具会很强，因为它擅长探索，你给它的是开放式问题。

但软件工程的本质是非常开放的，而且它并不“可重复”。你做一个功能，不是为了反复做同一个功能一遍又一遍。很多科技类岗位都属于这种开放式工作：数据科学也有点像，甚至一些偏战略的财务工作也有点像。

但当你离软件工程、离“科技公司核心”越来越远，你会发现很多工作其实就是业务流程：可重复的事情、可重复的运营操作。它往往是某个公司的管理者长期迭代出来的一套做法，通常会有标准操作流程（SOP）。大家希望按 SOP 来做，而且不希望偏离太多。

软件工程的“聪明才智”往往在于创新、偏离、探索；但世界上大量工作的本质，其实就是按这些流程跑下去。

比如我打电话去客服，对方就在按一套流程走；我给水电煤公司打电话，他们也有很多流程和规则：哪些能做、哪些不能做。所以我对这一大类机会非常看多：用 AI 去做业务流程自动化。而且我觉得它被低估了，因为它跟硅谷日常聊的东西太不一样了，大家就很少想它。

但如果你去想：我们能不能用 AI、用我们现有的工具和框架，去自动化这些可重复、确定性很强（high determinism）的业务流程？能不能把它做得更省力、更顺滑？关键还在于：它必须深度集成企业的数据、企业的决策逻辑，以及企业内部的各种系统。我觉得这块机会巨大、要做的工作也非常多，只是我们不怎么聊，因为它不在我们的“舒适区”。

主持人：我确认一下我理解得对不对：你认为 AI 在“工程之外”的机会更大——它能更大幅度影响公司的生产力，影响大量从事可重复、容易自动化工作的人，甚至改变工作的组织方式。因为现实里很多工作就是这样被完成的。

Sherwin Wu：对。我经常跟很多大型企业客户聊：AI 会怎么在 20 年后改变我的公司？公司在 AI 世界里会怎么运转？

软件工程当然是故事的一部分，但业务流程那一侧还有更多。而且我觉得业务流程那一侧，最终可能会呈现出更“彻底不同”的样子，要做的工作量也非常大。

从绝对规模上说，我不确定它到底比软件工程更大还是更小——软件本身也非常庞大、覆盖面也非常广。但可以确定的是：这块真的很大，而且它远远大过你在 X/Twitter 上看到的讨论热度。很多人根本不谈它，所以你会低估它。

7怎么才能不被 OpenAI “碾压”？

主持人：换个方向。你们做平台、做 API，很多人在 API 上做产品。大家脑子里最大的一个问题永远是：我怎么才能不被 OpenAI “碾压”？你们会不会自己做同样的东西，然后把我刚建立的市场给毁了？你们的总体政策、总体哲学是什么？创业公司应该怎么判断：哪些方向是 OpenAI 不太可能亲自下场的？

Sherwin Wu：我的总体回答是：市场太大了，机会空间巨大到离谱。创业公司真的不用过度纠结 OpenAI 或其他大模型实验室会做什么。

我见过很多创业公司，有做得不好的，也有做得很好的。所有我见过“熄火”的公司，没有一个是因为 OpenAI、某个大实验室、Google 之类“跑来碾压他们”。它们失败的原因更简单：他们做的东西没有真正打动客户，没有和客户需求产生共振。

相反，那些起飞的公司，即便在极其竞争的领域里也能做起来。比如 coding 这个领域竞争够激烈了，但 Cursor 现在依然很大——因为他们做出了大家真的很喜欢的东西。

所以我的建议是：别太焦虑这件事。专注做一个用户喜欢的产品，你一定能在里面找到空间。

我没法强调得更重：现在 AI 的机会有多大。机会大到一个程度，连 VC 的“可接受范围”（overton window）都被改变了——VC 现在在同一个赛道里投“互相竞争的公司”投得非常多、非常激进，就是因为空间太大、机会太大，几乎前所未有。

从创业者视角看，这反而是最赋能的环境：只要你做出一个让一部分人非常非常喜欢的东西，你就能做出一个价值巨大的生意。所以我才会反复说：别过度思考“会不会被碾压”。

另外还有一点也很重要，至少从 OpenAI 的角度：我们一直非常非常重视一件事，这也是 Sam 和 Greg 从顶层不断强调的——我们从根本上把自己看成一家“生态平台公司”。API 是我们的第一个产品。我们认为自己必须去培育这个生态、持续支持它，而不是去摧毁它。

你看我们做的很多决策，这条逻辑一直贯穿其中：我们每发布一个模型、在某个产品里上线，它最终都会进入 API。哪怕我们现在推出的 Codex 模型更偏向 Codex harness 的优化，它们最终也都会进 API，让所有 API 客户也能用到。

我们不会把这些能力“藏起来不放”。我们认为保持平台中立非常重要：我们不会屏蔽竞争对手，我们允许大家访问我们的模型。我们最近也在测试“用 ChatGPT 登录”这类产品，我们希望继续壮大这个生态——这件事非常重要。总体的逻辑就是：水涨船高。我们现在可能像一艘航母，体量很大，但我们认为把“潮位”整体抬高，对所有人都有好处，我们自己也会受益。

我们 API 的增长，某种程度上就是因为我们一直以这种方式行动。所以我真的鼓励大家别把 OpenAI 想成一个会随时把你推开、把你挤出去的存在。你应该把注意力放在：做出真正有价值的东西。我们会持续致力于提供一个开放的生态。

主持人：为什么这对 OpenAI 很重要？这种“做平台、让别人做生意”的坚持，是一开始就有的愿景吗？

Sherwin Wu：对，这是从一开始就有的。它甚至可以追溯到我们的章程、我们的使命。

OpenAI 的使命一直是两件事：第一，构建 AGI。我们当然在做这件事。第二，是把它的收益扩散到全人类（spread the benefits to all of humanity）。关键就在“全人类”。ChatGPT 当然在做这件事，我们想触达全世界。但很早我们就意识到：仅靠 OpenAI 作为一个公司，我们不可能触达世界的每一个角落。世界太大了，每个角落的需求都很深、很细。

所以为了完成使命，我们必须做一个平台：去赋能其他人来构建那些我们自己不可能亲自去做的东西——比如你刚才举的“为播客和 newsletter 主理人做客服 bot”这种产品，我们自己不会去做，但别人可以在平台上做出来。这就是 API 的意义。我们也一直非常喜欢看到生态里涌现出的各种东西，所以从第一天开始，这就是使命的一种体现。

主持人：而且你还没提你们要上线的 ChatGPT “应用商店”（app store）。这个是在你管的范围里吗？还是另一个组织 / 团队？

Sherwin Wu：那是另一个团队，更偏 ChatGPT 体系。但我们和他们合作非常紧密。他们做了一个 apps SDK，也是和我们团队密切协作出来的。但它确实是在 ChatGPT 的 umbrella 之下。

不过它也是同一个逻辑的例子：ChatGPT 现在大概有8 亿每周活跃用户，这些用户会反复回来用。对业务来说这是非常强的资产。但如果我们能让其他公司也进来，利用这个入口，为这个人群去构建产品——那不是更好吗？最终我们也认为这会帮助我们把这个用户群体继续做大。所以它依然回到使命：做平台、保持开放，往往能带来更大的增长。

主持人：你刚说的 8 亿这个数字……是每周活跃 8 亿吗？我刚刚脑子卡了一下。

Sherwin Wu：每周活跃 8 亿。

主持人：这太夸张了，简直前所未有。我们已经对这种规模数字麻了，但它真的离谱。

Sherwin Wu：对，从规模角度想这件事，我也觉得非常震撼。我会这么理解：差不多是全世界10% 的人口，而且还在增长。它还在往上冲。每周会有 10% 的世界人口来用 ChatGPT（准确说是每周）。

主持人：我也想再强调一下你刚才说的点：OpenAI 的使命是让 AI 的益处触达全人类。有些人会嘲讽这句话，说“这不是要收费吗”。但现实是：任何人都能用免费的 ChatGPT。免费版的能力，和世界上最强的 AI 模型也没有“天差地别”的那种距离，它不是被严格门槛挡住、只给少数人用的。如果你是亿万富翁，你能从 AI 里获得的增量，其实也有限；而一个在非洲某个村庄里的人，只要他能上网，他能获得的 AI 能力并不会差到哪里去。我知道这一直是 OpenAI 很在意的东西。

Sherwin Wu：对，这也是为什么我们会很重视医疗、很重视教育——教育这块会非常有意思。

还有一个很疯狂的趋势是：免费模型本身也越来越聪明。你回头看 2022 年的免费模型，当时已经算不错了，但跟今天比完全不是一个量级。你今天拿到的是 GPT-5（他这里提到“2 GB 5”，我按语义理解为 GPT-5 级别的免费能力）——所以我们所谓“抬高全球底线”（raising the floor）这件事，就是我们使命的一部分。

另外，从“亿万富翁”那个角度还有个有趣对比：有人说你用的 iPhone，跟 Zuckerberg 或那些亿万富翁用的，可能就是同一款。而现在某种程度上也类似：你每月 20 美元，就能用到“亿万富翁也在用的那套 AI”。你每月 200 美元，就能上 Pro——“亿万富翁也在用的 Pro”。但他们日常也不一定全用 Pro，很多时候也就是 Plus 级别。

所以这种“民主化”、这种把益处扩散到全世界的事情，对我们来说非常有意义，也驱动了我们很多决策。

主持人：最后一个问题：对那些想在 API 上做东西的人来说——可能他们突然意识到“我也可以用开源模型和 API 做很酷的东西”——你们的 API 和平台到底允许大家做什么？我知道你们能在平台上构建 agents。你能整体讲讲你们提供了哪些能力吗？

Sherwin Wu：从根本上说，API 提供的是一组开发者端点（developer endpoints），让你可以从我们的模型里采样（sample）。

现在最受欢迎的端点叫Responses API。它是一个专门为构建“长时间运行的 agent”优化的 endpoint——也就是能工作一段时间的 agent。

在最底层的 primitive 上，你基本就是给模型一段文本，让模型工作一会儿；你可以去轮询它（poll），看看它在做什么；然后在某个时间点拿到模型的返回。这是我们给开发者的最低层原语，也是很多人最常用的构建方式。它非常“不带观点”（unopinionated）：你几乎可以拿它做任何事，它就是最底层的构建块。在这个之上，我们开始提供越来越多的抽象层，帮助大家更容易地构建这些东西。

再上一层，我们有一个非常受欢迎的东西叫Agents SDK。它允许你基于 Responses API 或其他端点，去构建更传统意义上的 agent：比如一个 AI 在一个近似“无限循环”的工作流里持续运行；它可能有子 agent，可以把任务委派出去。

它会帮你搭出一整套框架 / 脚手架——当然，未来这套脚手架会不会也被模型“吃掉”，我们也会继续观察。但在当下，它确实让构建 agent 变得容易很多：你能给它 guardrails，让它把子任务分发给其他 agent，去编排一个 agent swarm（蜂群式的 agent 体系）。Agents SDK 就是帮你做这些的。

然后再往上，我们也开始做一些更偏“部署层（meta level）”的工具。我们有一个产品叫Agent Kit和一些Widgets：本质是一组 UI 组件，让你可以很快地在 API 或 Agents SDK 之上做出一个很漂亮的界面。因为很多 agent 从 UI 视角看起来非常相似，所以提供一套组件能大幅加速产品化。

此外我们也有一些评估相关的产品，比如Eval API：如果你想测试模型、测试你的 agent 或 workflow 是否有效，你可以用我们的 eval 产品做比较量化的测试。

所以我会把它理解成一个分层的栈：不同层级帮助你用我们的模型构建你想要的东西，抽象层级越来越高、也越来越“带观点”。你既可以把整套栈都用起来，很快就做出一个 agent；也可以一路下沉到最底层，只用 Responses API 去搭你自己想要的一切。

8 闪电问答

主持人：Sherwin，在我们进入很刺激的 lightning round 之前，你还有什么想补充的吗？有什么你想留给听众的？有没有我们还没聊到、但你觉得很有帮助的点？

Sherwin Wu：我只想留一个信息：我觉得接下来两到三年，会是科技圈和创业圈在很长一段时间里最有趣的一段时间。

我鼓励大家不要把它当成理所当然。我 2014 年进入职场，头两年挺不错，但接下来大概五六年，我觉得科技圈没那么“兴奋”。而过去三年，是我职业生涯里最让人兴奋、最有能量的阶段。

我觉得未来两到三年还会延续这种状态。

所以别把它当成理所当然。总有一天这波浪潮会走完，变化会变得更增量、没那么剧烈。

但在这段时间里，我们会探索很多很酷的东西，发明很多新东西，改变世界，也改变我们工作的方式。这就是我想留给大家的。

主持人：我太喜欢这段话了，我想多问一句。你说“别错过”，那你具体建议大家做什么？是去 build、去拥抱、去学习、去加入一家做有趣事情的公司？你给那些想说“我不想错过这班车”的人什么建议？

Sherwin Wu：我会说：去参与它（engage with it）。

基本就是你说的：去拥抱它。在这之上构建工具，是故事的一部分。但就算你不是软件工程师，你也完全可以拥抱它：去用这些工具。