95% 的工程师使用 Codex。100% 的 PR 都由 Codex 为工程师进行审查。我不知道过去几年里还有什么工作发生了更大的变化。工程师们正在成为技术负责人。他们在管理成群结队的 agent。这感觉就像我们巫师在施放各种咒语，而这些咒语会出去帮你做事。你认为人们还没有充分意识到什么？一人十亿美元创业公司所带来的二阶或三阶效应——为了支撑一人十亿美元创业公司，可能会有另外一百家小型初创公司在构建定制软件。因此，我认为我们可能真的会进入一个 B2B SaaS 的黄金时代。我越来越多地听到一种压力：当人们的 agent 不工作时，他们会感到焦虑。OpenAI 内部有一个团队正在做一项实验，维护一个 100% 由 Codex 编写的代码库。他们遇到了你描述的那些具体问题。通常你会说，好吧，我卷起袖子自己解决。但这个团队没有那条退路。你曾提到，在 AI 领域，倾听客户并不总是正确的策略。这个领域和模型本身变化得太快了。它们往往会自我颠覆。模型会轻易吃掉你搭建的脚手架。对于那些说“我不想错过这趟车”的人，你的建议是什么？确保你是在为模型未来的发展方向而构建，而不是为它们当下的能力而构建。我们这里的科学副总裁 Kevin Whale 有句话，他喜欢说：“这是模型表现最差的时候。”
今天，我的嘉宾是 Sherwin Woo，OpenAI API 与开发者平台的工程负责人。考虑到几乎所有 AI 初创公司都接入了 OpenAI 的 API，Sherwin 对正在发生什么以及未来走向有着极其独特而广阔的视角。在我们精彩的赞助商简短介绍之后，让我们进入正题。本期节目由 DX 赞助，DX 是由顶尖研究者设计的开发者智能平台。要在 AI 时代蓬勃发展，组织需要快速适应。但许多组织领导者难以回答紧迫的问题：哪些工具在发挥作用？它们是如何被使用的？真正驱动价值的是什么？DX 为领导者提供应对这一转变所需的数据和洞察。借助 DX，Dropbox、Booking.com、Adion 和 Intercom 等公司能够深入理解 AI 如何为开发者创造价值，以及 AI 对工程生产力产生了何种影响。欲了解更多，请访问 DX 网站 getdx.com/lenny，也就是 getdx.com/lenny。应用会以各种方式出问题：崩溃、变慢、回归，还有那些只有真实用户出现时才会暴露的情况。Sentry 能捕获所有这些问题。你可以在一个关联视图中看到问题发生在何处、为何发生，精确到引入错误的提交、提交代码的开发者，以及具体的代码行。我肯定试过开五个标签页、翻 Slack 线程那种调试方式。Sentry 更好用。它会向你展示请求如何流转、运行了什么、哪里变慢了、用户看到了什么。Seir 是 Sentry 的 AI 调试 agent，它会接着处理：利用 Sentry 的全部上下文告诉你根因、建议修复方案，甚至为你打开一个 PR。它还能审查你的 PR，标记任何破坏性变更，并准备好修复方案。免费试用 Sentry 和 Seir，请访问 sentry.io/lenny，使用优惠码 Lenny 可获得 100 美元 Sentry 额度。网址是 s-e-n-t-r-y.io/lenny。
Sherwin，非常感谢你来到这里，欢迎收听本期播客。谢谢。谢谢你邀请我。我想先从一个话题开始，它感觉像是衡量 AI 进展的晴雨表，尤其是在工程领域。你自己写的代码——如果你现在还写代码的话——以及你们团队写的代码，目前有多大比例是由 AI 完成的？我现在偶尔还会写代码。而且说实话，对于我这样的管理者来说，现在使用这些 AI 工具比手动编码要容易得多。所以我知道，就我自己以及 OpenAI 其他一些新晋管理者而言，目前我们所有的代码都是由 Codex 编写的。但更广泛地说，公司内部存在着一种实实在在的活力，围绕这些工具已经进步到何种程度、Codex 作为工具对我们来说已经变得多么好用。很难精确衡量代码中有多少是 AI 写的，因为绝大多数——我想说接近 100%——通常首先由 AI 生成。不过我们确实会追踪的是，目前绝大多数工程师每天都在使用 Codex。95% 的工程师使用 Codex。100% 的 PR 每天也由 Codex 审查。所以基本上，任何进入生产环境、合并到主分支的代码，Codex 都会过目，并在 PR 中提出改进建议、修改建议。这就是我们内部看到的情况。但总体而言，最令人兴奋的还是这种活力。我们还有一个观察：使用 Codex 越多的工程师，提交的 PR 也越多。他们实际上比不太使用 Codex 的工程师多提交 70% 的 PR，而且这个差距还在扩大。我觉得那些提交更多 PR 的人，正越来越学会如何使用这个工具，变得越来越高效，这 70% 的差距随着时间推移不断增长，自从我上次看这个数字以来，可能又变大了。好的。所以确认一下我们听到的：你说 OpenAI 这 95% 的工程师，他们的所有代码都是由 AI 编写的。AI 写出来，然后他们再审查。是的，没错。这太疯狂了，但几乎又不再那么疯狂了，因为我们正在逐渐习惯。说实话，我觉得还在适应过程中。确实也有一些工程师对 Codex 的信任度稍微低一些，但基本上每天我都会遇到有人被 Codex 的某项能力惊艳到，他们对模型的信任门槛——或者说他们放心让模型独立完成的程度——在不断提高。我们这里的科学副总裁 Kevin Whale 有句话，他喜欢说：这是模型表现最差的时候。对软件工程来说，这也是模型表现最差的时候。所以随着时间推移，你会看到人们越来越信任它，而我们也会看到模型变得越来越好。是的。Kevin Wheel 曾是播客嘉宾，他在这期节目里就说过这句话，而且说过好几次。是啊。Peter the Claudebot，现在叫 moldbotclaw，这位开发者最近分享说，他在工作中使用 Codex，感觉每当它完成什么任务时，他完全相信它做对了，几乎确信可以直接提交到 master 分支，而且不会有问题。是的，他是 Codex 的重度用户。我知道他和团队保持密切联系，给了我们很多很好的反馈。他用 Codex 我并不意外。我是说，抱歉，那叫 OpenClaw。OpenClaw。对。OpenClaw 是一款很棒的产品。然后我还看到，我是说就在最近，今早我想 mold's book 也被分享了出来，看到那些 AI agent 互相交谈，感觉非常超现实。我听到的说法是，基本上电影《Her》正在现实中上演。是啊。所以回到我们正经历的这个疯狂时刻，尤其是对工程师而言。我们已经从亲手写下每一行代码，发展到如今 AI 为你编写所有代码。我不知道过去两年有什么工作发生了如此巨大的变化——那种我们原本没料到会变化如此之大的工作。工程师这份职业在整个工程师生涯中都变得截然不同了，过去几年里，现在已经转变成了“我不再写代码了”。你如何看待未来几年工程师的角色，以及软件工程师这份工作会变成什么样？这份工作到底是什么？是的，说实话，亲眼见证这一切真的非常酷，这也是令人兴奋的部分原因。因为这份工作在未来一到两年里很可能会发生非常重大的变化。不过感觉我们仍在摸索中，因此有一种兴奋感，我知道尤其是一些软件工程师会觉得，我们正处于一个罕见的时刻——也许在未来12到24个月里——我们将能够自己把事情搞清楚，并为我们自己设定标准，就我所看到的发展方向而言。所以我觉得大家都在说一个共同的现象，那就是人们普遍认为，IC 工程师正在变成 tech lead。他们现在基本上就像经理一样。他们在管理成批成批的 agent。我知道我团队里的很多工程师基本上同时有10到20个 threads 在推进。显然不是正在 active 运行的 codeex 任务，但就是有很多并行的 threads。他们会跟进这些 thread 的进展，引导 agent 和 codeex，并给予反馈。所以他们的工作已经从单纯写代码本身，变成了几乎像一名经理。关于我认为未来一到两年这会往什么方向发展。有一个比喻是我经常会想到的，它来自我大学时读过的一本编程教材，叫 SICP。不知道你有没有听说过。《Structure and Interpretation of Computer Programs》，也就是 SICP。在 MIT 它非常受欢迎，很长一段时间里都是入门编程课程的教材，它有一批狂热的追随者。它教你编程，教你一种叫 Scheme 的 Lisp 方言，因此它向你介绍了函数式编程，在这方面非常开阔思维。但对我来说，那本书令人印象深刻的地方在于，我在大学时读了它，它的开篇将编程描述为一门学科，并把它比作巫术。它说软件工程师就像巫师，编程语言就像咒语，你在念咒，你发出这些咒语，这些咒语会出去为你做事，而挑战在于你必须说出什么样的咒语才能让程序按你的意愿执行。这本书写于1980年，所以那是很久以前的事了，我认为这个比喻实际上一直流传了下来。我认为当我们进入 vibe coding 的新时代，或者当软件工程变成新的形态时，这个比喻正在成真，因为编程语言基本上就是这些咒语。它们随时间演变，挑战一直存在，而且趋势是，通过编程让计算机做你想做的事变得越来越容易。我认为当前这波 AI 浪潮可能是这种演进的下一阶段。因为现在真的就是咒语了，因为你可以告诉你的……你可以告诉 Codex，告诉 Cursor 你具体想做什么，然后它就会去帮你完成。我特别喜欢巫师和巫术的类比，因为我认为我们当前的状态开始有点像《幻想曲》里的《魔法师的学徒》，米奇找到了魔法师的帽子，试图做各种事情。我觉得这个比喻非常贴切，因为首先，现在你能施展的这些咒语真的非常强大，杠杆效应极高，但你得知道自己在做什么，对吧？就像《魔法师的学徒》里，整个情节就是米奇失控了，扫帚发了疯，到处都在发洪水。我觉得他 literally 就是让扫帚去执行任务，然后自己去睡觉了。所以，你知道，这就像是 vibe coding 发挥到极致，最后老魔法师回来收拾烂摊子。当我看到工程师们同时推进这20个不同的 codeex thread 时，这需要一定的技巧和经验，需要投入很多思考，因为你得确保模型不会跑偏。你肯定不想完全离开，然后无视它。但这也带来了极高的杠杆效应，一个非常资深且真正精通这些工具的工程师，现在可以通过他所做的事完成更多的工作。我觉得这也是它有趣的地方。感觉我们现在真的就像巫师一样。感觉我们离让这一切成为一种魔法般的体验更近了，我们在施展各种咒语，让软件为你做所有这些事情。你描述的时候，我正好也在想《魔法师的学徒》这个比喻。所以很高兴你提到了这个。之前有一位播客嘉宾把它描述为你有一个能实现愿望的神灯，这是一个有用的框架，因为你必须非常清楚自己想要的愿望是什么，比如你想变大，那到底要多大。是的。或者也可能像 monkey's paw 那样，你得到了你想要的，但副作用是什么？是的。我觉得这个类比很棒。对我来说，最不可思议的是那本书的生命力。SICP 被称作“巫师书”。人们叫它巫师书，因为这就是贯穿全书的比喻。而我们基本上现在已经到达了那个阶段，这真的很酷。这里有两个线索我想跟进。第一，我越来越多地听到，当 agent 不工作时，人们会感到一种压力。你启动了所有这些 codeex agent，然后你必须时刻盯着它们。哦，有一个不工作了，我在浪费时间。你有这种感觉吗？你的团队有这种感觉吗？是的，是的。这一直都在发生。实际上我认为这就是目前这一切有趣的地方，因为这些模型并不完美，这些工具也不完美，我们仍在摸索如何与这些 codeex 或 AI agent 最佳地交互以完成工作。我们经常遇到这种情况。我们内部有一个特别有趣的团队。有一个团队目前正在 OpenAI 内部做一个实验，他们基本上在维护一个100%由 codeex 编写的代码库。你知道，通常你会让 AI 写代码，但最后你会重写很多部分，你可能需要反复检查和修改，但这个团队完全投入到 codeex 中，彻底 leaning in。他们遇到的正是你描述的问题，比如他们的挑战是，我想把这个功能做出来，但我无法让 agent 完成它。所以通常都会有一条退路，你会想：“好吧，那我卷起袖子自己来解决。”然后不用 Codex，转而使用 tab complete、Cursor 之类的工具。但这个团队——在这个实验中——没有这条退路。于是挑战就变成了：我怎么才能让这个 agent 做到这件事？而且我觉得我们可能会就此发布一篇博客文章，分享我们的一些心得。不过，很多有趣的范式和最佳实践正从中涌现出来。我们注意到一件很有意思的事——我不知道你是否也有同感，但我们这里确实深有体会——很多时候，当编程 agent 没有按你的意愿行事，通常是因为上下文出了问题，或者你给它的信息有问题。要么是你描述得不够充分，要么是关于如何做这件事的信息不够，agent 拿不到，Codex 也拿不到。所以当你不得不通过这种方式来解决时，挑战就变成了：去补充文档，想办法绕过这个限制，基本上就是把你脑子里的部落知识以某种方式编码进代码库——不管是通过代码注释本身、代码结构本身，还是通过文本文件，比如 MD 文件、skills 文件，或者仓库里的任何其他补充资源——好让模型能更好地完成任务。从这个团队身上还有很多其他收获，我觉得都非常值得探索。但没错，取消那条“不再使用 AI”的退路，让他们得以开始拼凑出很多我们必须解决的问题——如果我们真的想大力拥抱 agent 的话。另一个大家遇到的问题是，你提到人们现在疯狂地发 PR，如果用 AI 工作，PR 数量会多很多。显然，code review 正成为更大的挑战。你们团队在加速 review、让它具备可扩展性方面，有没有什么办法？而不是给大家制造一份苦差事，让他们整天坐在那里审 PR。有。首先，Codex 目前会 review 我们 100% 的 PR。所以我觉得，发生了一件很有意思的事：我们倾向于第一时间交给模型的任务，往往正是那些让我们感到厌烦、或者软件工程中最枯燥的部分。这也是为什么现在工作变得更有趣了，因为我们可以去做更多更有意思的事情。就我个人而言，我真的很讨厌 code review。这对我来说几乎是最痛苦的事情之一。我记得大学毕业后的第一份工作是在 Quora。我当时负责 Newsfeed，所以 Newsfeed 的代码由我维护。因此我是 Newsfeed 的 reviewer，而那是所有人都会碰到的核心代码。于是每天早上我登录系统一看，会有二三十个 code review。我就想，天哪，我得把这些全部看完。我还会拖延，然后数量就涨到 50 个左右。所以就是大量的 code review。
Codex 非常擅长 review 代码。其实我们注意到，它尤其非常擅长 review 代码，尤其是当你能把它引导到正确方向上时。所以对于 code review 来说，没错，我们产生了很多 PR，但 Codex 会 review 所有 PR。这让 code review 从原本大概 10 到 15 分钟的任务，有时甚至缩短到只需两三分钟，因为已经有一大堆建议内置在里面了。很多时候，尤其是对于小 PR，你其实根本不需要人来 review。我们在这方面相当信任 Codex。原始作者会看一下 Codex 的 review。你知道，code review 的好处就在于有第二双眼睛，确保你没有做什么蠢事。Codex 目前已经是相当聪明的第二双眼睛了，所以我们非常倚重这一点。另外，整个 CI 流程，以及代码提交后的部署流程，目前内部也已经大量通过 Codex 实现了自动化。如果你和很多工程师聊，最让他们抓狂的事就是：在你写好了漂亮的代码之后，怎么把它弄进生产环境？你得跑一大堆测试，还得处理 lint error，还要过 code review。有很多自动化工作可以借助 Codex 来完成，所以我们内部其实搭建了一些工具来自动化这个流程，自动化 lint。比如如果有 lint error，Codex 修起来非常简单。它可以直接打补丁，然后重新启动 CI 流程。所有这些，我们都在试图把工程师的工作量压缩到最小，而随之而来的副产品是，他们现在可以合并并发布更多的 PR 了。
Codex 写代码，Codex review 自己的代码。我很好奇，你是否愿意用其他模型来 review 你们模型的产出？这是一条可行的路，还是说现在已经够好了，不需要别的了？这么说吧，这里确实存在一个循环问题。就像回到《魔法师的学徒》一样，你得确保别让扫帚失控疯跑。所以我想说，我们对于哪些 PR 完全只由 Codex 来 review，是非常谨慎的。大多数人显然还是会看一下自己的 PR。所以并不是降到零，更像是注意力从 100% 降到 30%，而这已经足够让事情推进下去了。至于多模型方案，我们显然在内部测试了很多模型，所以手头也有不少。我们较少使用外部模型。我们认为“吃自己的狗粮”、从自家模型那里获取反馈是很重要的。不过你也可以——我们有很多内部模型变体，可以用它们来提供不同的视角，这也被证明相当有效。好。那么为了确认一下，作为衡量 OpenAI 当下 AI 与代码结合程度的一个标尺——我先确认一下，然后想换个话题——目前 OpenAI 100% 的代码都是由 Codex 写的。应该这样表述吗？我不会说今天生产环境里运行的代码 100% 都是 AI 写的。而且这事儿也很难做归属判定。但可以说，几乎每位工程师目前在所有任务中都在重度使用 Codex。所以如果我要估算的话，目前绝大多数代码很可能都是由 Codex 完成的。好的。很多人都在讨论，而且我们一直在聊 IC 的角色，也就是 IC 工程师的工作。但很少有人讨论经理——尤其是工程经理——角色的变化。作为经理，你的生活随着 AI 的兴起发生了怎样的变化？你认为未来经理的角色是什么？我的变化肯定比工程师小。目前还没有针对经理的 Codex，至少现在还没有。不过，我也会相当频繁地用 Codex 来处理一些更偏管理性质的任务。我想说有几件事正在发生变化，出现了一些趋势。所以我觉得目前变化还不算太大。但我看到了一些趋势，而且如果你顺着这些趋势推演下去，就能大概看出这一切正在走向何方。有件事越来越明显，那就是 codeex 确实能让顶尖表现者大幅提升生产力。我认为这可能也适用于更广泛的 AI 领域，乃至整个社会——那些真正投入其中、或者说那些具有高主动性、愿意熟练掌握这些工具的人，将会让自己获得超强动力。我现在也注意到了这一点，顶尖表现者最终会变得高效得多。因此，你会看到团队生产力出现更大的分化。一直以来，我的一项管理哲学就是把大部分时间花在顶尖表现者身上，确保他们不受阻碍、确保他们开心、确保他们感到自己富有成效且被倾听。在 AI 时代，这一点甚至更为成立，因为你的顶尖人才使用这些工具后会突飞猛进。举个例子，那个维护 100% codec 生成代码库的团队，让他们放手去做、看看能发生什么，这带来了回报。所以我认为这是我观察到的一个趋势：管理者把更多时间花在顶尖表现者身上，这种做法很可能会持续下去。另一点更多是观察。我感觉管理者有了这些 AI 工具——不是写代码，而是像接入组织知识的 chat GBT，能够做研究、更好地理解组织背景。另一个很好的例子是，我们现在正在做绩效评估，使用接入内部知识的 chat GBT，关联 GitHub、我们的 Notion 文档和 Google 文档，很容易就能清楚了解这个人过去 12 个月做了什么，并写一份深度研究报告。我的感觉是，在这个时代，管理者将能够管理更大的团队，就像软件工程师管理 20 到 30 个 codeex 一样。这些工具能让管理者、人员管理者拥有更高的 leverage，让他们管理的团队规模远超目前软件工程领域的最佳实践——我想大概是六到八人吧。你可以看到这也适用于非工程领域，比如支持或运营部门。以前支持团队的规模可能有限，但当你能把更多事情交给 agent 处理时，你实际上能完成更多工作，也能用这种方式管理更多人。我认为人事管理也可能发生同样的情况，尤其是在科技公司。我们已经看到了这一点。有些团队里的 EM 管理着相当多的人，而且他们做得相当娴熟，正是因为这些工具让他们获得更高的 leverage，更了解团队在做什么，更好地理解组织背景，并以这种方式运作。我很喜欢这个建议。你刚才描述的方式是，你一直倾向于顶尖表现者，花更多时间在他们身上，帮他们排除障碍，确保他们开心。Mark Andre 最近也上了这期播客，他的说法是，AI 让优秀的人更好，让卓越的人非凡。是的，是的。而你现在说的是，越来越这么做可能是正确的做法。花更多时间和团队里最优秀的人在一起，帮他们排除障碍，确保他们拥有所需的一切。是的。现在有一个很好的例子：公司内部有一群工程师非常投入地使用 codeex，正在思考如何与这个模型交互的最佳实践，这对他们来说是 leverage 极高的事情。作为管理者，我就说，去探索吧，无论总结出什么最佳实践，我们都得分享给整个组织。我们会做各种知识分享会，分享文档和最佳实践到各处。这类事情能提升所有人，我认为这也是我们看到的趋势的另一个例子——顶尖表现者真正变得非凡。人们隐约感觉到这是件大事。AI 正在带来巨大的改变。世界在改变。这将会影响深远。你认为人们还没有把什么因素计入未来的变化和趋势中？有没有什么事情你觉得我们还没意识到？这么说吧，这次 AI 浪潮中我最喜欢的一句话或概念之一就是“一人十亿美元创业公司”。我觉得 Sam 可能最早提出了这个说法，但这确实引人深思，对吧？就是说，如果人们的 leverage 如此之高，未来很可能出现一家由一个人创办的、价值十亿美元的公司。虽然我觉得这很酷，但我认为人们并没有真正计入这件事的二阶或三阶效应。因为“一人十亿美元创业公司”意味着一个人使用这些工具可以拥有更多的主动性和 leverage，能够轻松完成业务所需的一切，最终创造出价值十亿美元的东西。但我认为这还有另外几层含义。其中之一是，如果一个人能创办一家“一人十亿美元创业公司”，那也意味着人们创办公司总体上会容易得多。实际上，我认为一个二阶效应是将会出现一场巨大的创业潮，以及小型企业（SMB）的繁荣，任何人都可以为任何事情开发软件。你已经开始在 AI 创业领域看到这种情况，软件变得更加垂直化，针对某个特定垂直领域打造 AI 工具往往效果很好，因为你真正深入那个领域，真正理解其用例。如果把 AI 推演下去，没有理由不能出现 100 倍于现在的这类创业公司。因此，我认为我们可能看到的一个未来是：为了实现“一人十亿美元创业公司”，可能会有另外一百家小型创业公司开发定制软件，非常好地支持其他类型的小型“一人十亿美元创业公司”。所以我们实际上可能会进入 B2B SAS 乃至软件和创业领域的黄金时代。我认为这是一个非常有趣的趋势，因为随着开发软件越来越容易，随着经营公司越来越容易，你最终可能会看到多得多的创业公司。所以我的想法是，没错，可能会出现一家市值十亿美元的一人创业公司，但可能会有上百家市值一亿美元的公司，可能会有成千上万家市值一千万美元的公司。作为个人，拥有一家一千万美元的企业其实相当不错，那已经足够让你这辈子衣食无忧了。所以我们可能会看到这方面的爆发式增长，而且我觉得人们还没有真正意识到这一点。嗯，这还有另一种第三阶效应。再说一遍，所有这些——随着预测的时间越来越久远，我觉得都存在很大的不确定性。我认为，如果我们最终进入这样一个世界：出现一些微型公司，开发的软件只为一两个人服务，而这些人就是公司的所有者并在那里工作，那么创业生态会发生变化，风投生态也会发生变化。我们可能会进入一个只有少数几家大平台公司提供平台并支持所有这些初创企业的世界。但是，那些能带来风投规模回报、能让你的投资真正翻百倍或千倍的初创公司类型，如果你最终出现大量这种规模较小的一千万到五千万美元的公司，实际上可能会萎缩。这些公司对于风投来说不是什么好回报，但对于个人——那些现在真正利用AI为自己打造企业的高能动性个人来说，却是极好的。我喜欢我们已经聊了多少阶的效应。现在我想听听第四阶效应。Sherwin，我开玩笑的。我做不到，第四阶太复杂了，对我来说太烧脑了。我想不了那么远。这就像《盗梦空间》，每深入一层，所有事情就变得越来越慢。嗯，好吧。关于十亿美元创业公司，我经常思考这个问题，因为我不会做成一家十亿美元的公司，因为我做的事情无论如何都不具备风投规模，杠杆效应也不是特别高，但光是看到我会收到多少工单，全是因为一些最荒谬的事情。我很难想象一个人能搞定这一切，我对这种十亿美元的一人公司持悲观态度。我只是想分享这个想法，纯粹是因为支持成本——即使AI在帮你，如果要做成十亿美元规模，除非你的ACV非常高、客户非常少，否则光是处理支持问题，而且人们明明可以自己解决问题，但他们就是想发邮件问客服这事儿，光处理这些就很难规模化。除非你有大量承包商，我不知道这算不算单人公司。我觉得要让一家十亿美元初创公司规模化，却很难至少没有人在支持工作上帮你，这非常难，而且AI我认为也只能帮到你一定程度。所以我是这么认为的。嗯，实际上我的看法略有不同，我认为，你知道，Lenny 的播客最终可能会成为一家十亿美元的创业公司。但我的想法是，与其你作为一个人去派AI解决和修复那些工单，我认为最终可能会有一大批其他初创公司，开发专门针对你需求的软件。所以，可能会出现十到二十家为播客和通讯提供支持软件的初创公司，那可能就是一家一人创业公司。不需要做大。他们可能非常轻松地就能编写出这个产品，能够做出自己的东西，因为它非常量身定制、独特，而且希望对你有用。作为一家十亿美元的一人创业公司，你可能会购买它。我会买的。我会买的。是的。这里有个问题，就是哪些东西你内部做，哪些东西你外包。我认为可能发生的是，由于编写软件和构建产品的成本正在急剧下降，你可能会把很多东西外包出去，从而减少公司规模。所以我觉得那可能就是最终会出现的世界，同样，这里存在很大的不确定性（清嗓），但最终结果仍然可能是一个人驱动这样一家杠杆极高、规模巨大的公司，最终可能真的达到十亿美元。我能想象。我也想到 Peter，就是那个 Clawbots/moldbot/openclaw 的，他现在被各种请求、邮件、提醒、私信和公关需求轰炸得多厉害，我很好奇，而且他甚至还没靠这个东西赚钱。嗯。是啊，我无法想象他现在是什么状态。肯定疯狂至极。可能就像，嗯，你知道的，就像我们推出 Hatchvt 之后那几个月的疯狂状态，作为一个人。顺便说一下，他下周要（清嗓）来播客了。哦，那太令人兴奋了。是的。嗯，也许第四阶效应就是分发变得越来越重要，因为有太多该死的东西在争夺你的注意力。所以我觉得有受众和平台的人会变得越来越有价值，这是好事。好了。嗯，我想回到你的管理话题。我真的很喜欢你关于花更多时间与顶尖表现者相处的见解，这对你来说非常成功。想想你作为管理者，带领团队构建基本上支撑整个AI经济的平台，就像每家AI初创公司都在你们的API上构建。显然你做得很好。你还学到了哪些核心管理教训？你觉得作为工程师和普通员工的管理者，什么才是真正重要、是你成功的关键？是的。嗯，我觉得我在这里学到的很多教训，我不知道这在多大程度上特指 OpenAI API 或者我们的某些企业产品。我的管理理念显然随着时间推移有所变化，但可能保持不变的部分比变化的部分更多。其中一个原则就是我之前跟你聊过的，你知道，花大量时间与顶尖表现者相处，真的花——具体来说，就是把超过50%的时间花在你最顶尖的，可能是前10%的表现者身上，然后竭尽全力去赋能他们。我是这么想的：这让我想起那个把软件工程师比作外科医生的类比，出自《人月神话》这本书。实际上挺有意思的。我是从书里引用的，但书里其实描述了这样一个世界，我觉得他们像是在预测未来，因为我想这本书大概是70年代左右写的。他们说软件工程最终会进入一个世界，软件工程师就像外科医生，或者在手术室里，只有一个人在做实际工作。你知道，只有一个人在切割或者做所有手术，而房间里的其他人都是为了支持他，对吧？就像护士、住院医生、进修医生，然后外科医生说“我要手术刀”，他们就把手术刀递过去，然后他说“我要那个工具和那台机器”，他们就会拿过来。所有人都在那儿，就是为了支持那位外科医生。《人月神话》（The Mythical Man-Month）其实早就预言过，这大概就是软件工程师将要走向的方向。但我认为现实并不完全如此，软件工程的协作性要强得多，并非只有一个人在工作。不过我一直很喜欢这个类比，而且我也一直努力在自己的管理哲学中去效仿它。也就是说，软件工程并不真的像外科手术那样，只靠一个人完成工作；但我对待团队成员的方式，以及我作为管理者的行事风格，是希望能赋能他们，让他们感觉自己像一位外科医生——只要我在支持他们，确保他们拥有完成工作所需的一切，他们就会感觉仿佛有一整支军队在支持自己、帮他们预判障碍、提供所需的一切，尽管实际上只有我这位管理者而已。所以我举的例子是：预判障碍、帮团队扫清障碍，尤其是从组织层面去做这件事，是极其有用的。再说回 AI 的话题，如今这一点更加重要了，对吧？如果人们只是不断地提交 PR（Pull Request），那么阻碍进展、阻碍产品交付的瓶颈往往在于组织层面或流程层面。如果你作为管理者能够预判障碍、帮团队扫清障碍——比如说，外科医生需要手术刀，而管理者已经提前把手术刀准备好了——那就是最理想的情况。这大致就是我对待管理、尤其是工程管理的方式。所以这一点长久以来都让我印象深刻。尽管软件工程师并不完全等同于外科医生，但这个比喻在我余下的职业生涯中一直萦绕在我脑海里。我喜欢这个比喻。而且我想知道，AI 是否能在“预判障碍”这件事上帮上忙——预测这位工程师即将因某个决策而受阻，我们需要解决这个问题，我们需要去——
是啊，这确实是一个很好的观点。我还没试过，但我好奇如果我把 ChatGPT 接入公司知识库去问会发生什么，比如：当前活跃的阻塞点有哪些？翻翻所有的 Notion 文档，还有 Slack 消息，估计就在 Slack 的某个地方。我团队当前有哪些活跃阻塞点？我能帮上什么忙？嗯，这我还真没想过，但你说的对。你刚刚就在这儿有了个洞察。是啊，是啊，是啊。而且我觉得更有趣的是，你可以预判什么将成为这位工程师或这个团队在未来几个月里的障碍——
对。你让模型——你让 AI 去做那些二阶、三阶（second and third order）的思考。预判这些，伙计。也预判一下下个月会出现什么障碍。呃，我觉得我们刚刚想到了一个好点子。是啊，是啊。本期节目由 DataDog 赞助呈现。DataDog 现已整合 EPO——领先的实验与功能开关（feature flagging）平台。全球顶尖公司的产品经理们每天都在使用 DataDog——和他们的工程师依赖的是同一个平台——将产品洞察与产品问题（如 bug、UX 摩擦和业务影响）关联起来。
一切从产品分析开始，产品经理可以观看回放、查看漏斗（funnels）、深入分析留存（retention），并探索各项增长指标。当其他工具止步于此，DataDog 却能更进一步。它帮助你真正诊断漏斗流失（funnel drop-offs）、bug 和 UX 摩擦所带来的影响。一旦你知道该聚焦何处，实验（experiments）就能验证什么才是真正有效的。我在 Airbnb 时曾亲身经历过，我们的实验平台对于分析什么有效、哪里出了问题至关重要。而正是那个在 Airbnb 搭建实验平台的团队打造了 EPO，让你能够结合会话回放（session replay），通过热力图（heat maps）和滚动图（scroll maps）真正理解用户行为，超越单纯的数字。而这一切都由与实时数据相连的功能开关（feature flags）驱动，让你能够安全发布（roll out）、精准定向，并持续学习。DataDog 不仅仅是工程指标。它是顶尖产品团队更快学习、更智能修复、自信发布的平台。
前往 datadog.com/lenny 申请演示。没错，datadog.com/lenny。好，我要把话题转向你们搭建的 API 和平台。你们与很多公司合作，它们接入你们的 API、你们的平台，基于你们的工具做开发。你跟我说过，你发现很多公司在 AI 部署上的 ROI（投资回报率）实际上是负的。我觉得这也是很多人在阅读和思考时感受到的，而你说自己亲眼见到了这种情况，这很有意思。到底发生了什么？他们哪里做错了？在 AI 部署和 ROI 方面，你看到了什么？是的。但先说明一下，我并没有看到明确的量化数据。实际上这些东西很难衡量。不过，尤其是从观察一些公司尝试做 AI 的情况来看，如果很多 AI 部署实际上是负 ROI，我一点都不会惊讶。我的意思是，部分原因还在于，我认为全国范围内、基本上是科技行业之外的人，普遍有一种感受，那就是 AI 正在被强加给他们。我觉得这部分原因可能正是一些 AI 部署出现负 ROI 的症状。关于这一点我观察到几件事。首先，我觉得这一点我反复强调：我们硅谷的人只是忘了自己活在一个泡沫里。我们太——Twitter 是个泡沫，抱歉，X 是个泡沫。硅谷是个泡沫。软件工程是个泡沫。世界上大多数人，美国的大多数人，都不是软件工程师，对 AI 并不十分精通，也不会关注每一个模型发布。所以我们完全不了解大多数人是怎么用这项技术的。因此，我们总是在谈论 Codex 的各种最佳实践，谈论 OpenAI 内部那些使用 Codex 的人。我相信 X 上发帖的每个人都是这些 AI 工具的疯狂高级用户，你知道，他们深挖各种技巧（skills），深挖 agent、MCPs。对，没错，所有那些。而当我与一些这类公司交流，与实际使用这些工具的员工交谈时，发现他们尝试做的事情是最基础的，而且他们对这项技术究竟如何运作几乎一无所知。所以这对我来说是一个重大观察，那就是：他们向这些工具提出的都是非常简单的问题。他们目前还没有真正深挖。这就回到了我认为更多公司应该怎么做，或者理想一点的 AI 部署架构应该是什么样的。我们在 OpenAI 内部大致也是这样运作的。我认为那些开始取得很好效果的公司，都同时具备自上而下的支持。就是高管层（C-suite），就是“我们要成为一家 AI 优先（AI-first）的公司”。所以有支持，他们采购工具，有高管支持（executive support），但同时也有自下而上的采纳和支持（buy-in）。我的意思是，这需要有真正的员工来实际执行这项工作，他们对这项技术充满热情，愿意学习、推广、建立最佳实践，并在组织内部进行知识分享。我们在内部见过很多这样的情况。显然，OpenAI 一直想成为一家非常以 AI 为核心的公司，但这一切真正开始快速发展，是在引入了 codecs 和这些工具之后——普通员工自己也能开始将其应用到工作中。我认为这真的很重要，因为归根结底，每个人的工作都非常不同，非常独特。软件工程不同于财务，财务不同于运营，运营又不同于市场和销售。因此，工作中存在大量这种“最后一公里”的细微差别，这真的需要以自下而上的方式来完成。我的感觉是，许多 AI 部署并没有实现自下而上的采用。这像是一道死命令，极其自上而下，与实际工作严重脱节。最终结果是，你拥有了一大批并不真正理解这项技术的员工。他们的心态是：我知道我应该用这个，也许我的绩效评估里也有这一项，但我不确定该怎么做。他们环顾四周，发现没人这么做，也没人可以学习。所以我对那些推动这件事的公司的建议是，找到——甚至可以在内部组建一个全职团队——作为这种内部的 tiger team，去探索能力的全部边界，将其应用到具体的工作流程中，进行知识分享，在那些可能想要使用这项技术的人中间创造兴奋感。因为如果没有这些，实际上很难真正上手——
你会在这个 tiger team 里放什么样的人？是以工程师为主导吗？根据你的经验，这是一个跨职能团队吗？是的，这很有意思。另外，很多公司没有软件工程师。所以我看到的模式往往是，这些人属于软件工程相关岗位，基本上是技术人员，但不是软件工程师。我认为这些人最容易对此感到兴奋。比如说，可能是支持团队的运营负责人，他不会写代码，但很喜欢使用这些工具，也许是 Excel 高手之类的。所以是技术相关、编程相关、而且相当有技术背景的人。我在这些公司看到的正是这样的人，他们真的会眼前一亮，对这项技术非常兴奋。你通常可以围绕这样的人组建一个团队。但没错，往往不是软件工程师。软件工程师我想也会理解这些，但不是每家公司都有软件工程师。这其实挺罕见的。他们难找，而且很贵。所以是其他类型的人。我听到你说的反模式是自上而下。就是 CEO 或高管团队说，我们要全面拥抱 AI，我们要 All in AI，每个人都要根据使用 AI 工具的情况来考核，你的生产力因为 AI 提升了多少。如果这只是自上而下，而没有组建一个自下而上传播“福音”的团队，你会发现这行不通。是的。是的。完全正确。完全正确。而你的建议是，找到最兴奋的人，与其让他们分散在组织各处，不如组建一个小小的 AI 布道团队，找到使用它的方法，并在工作中推广开来。是的。听你复述给我，另一个思考角度是，回到我自己的管理理念，就是找到那些在 AI 采用方面表现优异的人，并赋能他们。让他们组织黑客松，举办研讨会，进行知识分享，在内部种下兴奋感的种子。好的，太棒了。我想听几个你的犀利观点。有些东西我看到你谈论和分享过。一个是，你分享过在 AI 领域，与客户交谈和倾听客户意见并不总是正确的策略，它可能经常把你带偏。我不确定这是否算多么犀利的观点。主要的意思是，显然你应该和客户交谈，和客户交谈是有用的。我只是觉得 AI 这个领域，尤其是过去三年我在 API 方面工作，看着这一切演变过来的过程中，这个领域和模型本身的变化速度实在太快了，它们往往会自我颠覆，尤其是在工具和脚手架这个层面。所以我这周早些时候读到一篇文章，来自一个叫 Nicholas 的人，他是 finol 这家创业公司的创始人。我想他分享了很多在 FinTool 这家初创公司为金融服务构建 AI agent 时学到的最佳实践。他有一句话说得很好：模型会把你的脚手架当早餐吃掉。如果你回溯到 2022 年 ChatGPT 刚发布的时候，这些模型还非常原始，当时有很多产品脚手架和工具，尤其是在开发者领域，试图去引导模型，在它周围搭建脚手架让它按你的意愿工作，比如 agent 框架，那时候向量存储非常流行，还有一大堆各种各样的工具。随着这个领域的发展，模型变化太大了，能力提升太多了，最终确实“吃掉”了其中一些脚手架。我认为这在今天依然成立。Nicholas 的文章里提到，目前流行的脚手架是基于 skills files 的上下文管理。我能想象，在将来的某个时刻，这也不再有必要了，模型可以自己管理所有这些，或者可能会转向某种新的范式，你不再需要这种基于文件的 skills 之类的东西。你确实已经看到了这种演变，对吧？agent 框架我觉得现在没那么有用了。曾经有一段时间，大概是 2023 年，我们认为向量存储会是将组织上下文引入模型的主要方式，你需要把你所有的语料库都向量化、嵌入，然后还要做大量工作来优化向量搜索，以便在正确的时间填入正确的信息。所有这些都是脚手架，因为模型当时还不够好。结果证明，随着模型变得更好，更好的方法其实是去掉很多这种逻辑，信任模型，给它一套搜索工具。这不一定是向量存储，你其实可以把它接到任何类型的搜索上，甚至可以是文件系统上的文件，比如 skills 和 agents.md 来引导它。显然，向量存储仍然有一席之地，我知道很多公司还在用，但围绕它搭建的一整套脚手架，以及围绕它构建的整个生态系统，还有认定那是你唯一需要的脚手架，这些都已经发生了很大变化。所以回到这一点，你不必总是听客户的，因为这个领域在任何时候都在发生巨大变化，很多人其实都处于某种局部最优状态；如果你盲目听从客户，他们会说“我想要更好的向量数据库”，或者“我想要更好的 agent 框架”之类的，如果你只沿着那条路追下去，实际上只会让你再次陷入局部最优。而随着模型变得更好，我们不得不重新发明，并重新思考围绕这些模型构建的正确抽象、正确工具和框架。而这个过程中很酷、很令人兴奋、又有点抓狂和恼人的部分是，目标一直在移动。所以是的，目前这一大堆工具和框架很可能会随着时间的推移而发生显著演变和变化，因为模型变得越来越聪明、越来越好。但这就是在这个领域构建东西的本质。我认为这正是它令人兴奋的地方。但这也意味着，当你与客户交流时，你需要在某种程度上平衡他们想要的具体反馈，以及你对模型发展方向和未来一到两年趋势的判断。有趣的是，这就是“苦涩的教训”——AI 和 ML 领域的人们学到的这个重要教训——就是不要过度复杂化，你往机器学习、往 AI 里添加的逻辑越少，它就越能扩展和成长； basically 就是把所有东西都拿掉，让它自己去计算， basically 就是给它更多算力，让它自己变得更聪明。是的，“苦涩的教训”确实有一个适用于用 AI 做构建的版本——我们曾试图围绕模型搭建各种架构，结果发现模型会把这些东西统统吞噬掉。说实话，OpenAI API 团队也犯过这种错误，我们本不该绕那些弯子的，但模型最终还是变得更好了，我们每天都在学习这个苦涩的教训。那么对于基于 API 做构建的人，或者只是在构建 agent、目前不得不在周围搭建一些配套东西的人来说，关键要点是什么？或者说，你有什么建议？我的总体建议是——我已经跟很多人说过一段时间了，而且我认为今天依然适用——确保你是在为模型未来的发展方向做构建，而不是为它们今天的能力做构建。这显然是一个移动的目标。我认为我见过很多做得非常好的公司和初创企业，他们都是为一种理想的、今天可能只实现了 80% 的能力类型来构建产品的。最终他们的产品是那种“基本能用但还差一点”的状态，但随着模型变得更好，突然有一天就开窍了，然后他们的产品变得非常不可思议，因为它真的管用了。比如可能某个时候在 o3 上突然能跑通了，然后在 5.1、5.2 上突然就解锁了。他们构建这些产品时，是把模型能力的提升考虑进去的，这样一来，你最终创造出来的体验，会比一开始你就假设能力是静态的要好得多。所以这就是我的一个总体建议：为模型未来的发展方向做构建，而不是为它们今天的能力做构建。这样你最终会做出更好的产品。你可能需要等一小段时间，但模型进步得如此之快，你往往并不需要等太久。顺着这个话题，未来六到十二个月里，API 会走向何方？平台会走向何方？模型会走向何方？在你能分享的范围内，我知道这里有很多保密内容，但有哪些是你最兴奋的，或者你认为人们应该开始为之做准备的？我觉得最明显的一点是这些模型能够连贯完成的任务时长。有一个 SWE-bench 基准测试，它追踪软件工程任务，看这些模型能在 50% 的情况下、80% 的情况下完成多长的任务。我认为目前 frontier models 在 50% 的情况下已经能完成长达数小时的软件工程任务了，而 80% 的情况大概是在将近一小时以内。但那张图表令人警醒的地方在于，他们把所有之前的模型也都标在了这张图上，所以你能很清楚地看到这个趋势。这是让我非常兴奋的一点。实际上我认为今天的产品真正优化的还是模型一次只能做几分钟的任务。即使是 Codex 和编程工具，我觉得你现在看到它们还是交互式的，优化的其实最多也就十分钟左右类型的任务。我也见过有人把 Codex 推到极限，去做长达数小时的任务，但我觉得那更多是例外。不过如果你顺着这个趋势看，我认为未来 12 到 18 个月里，我们可能会看到模型能够非常连贯地完成长达数小时的任务。在某个时间点，它可能会达到比如六小时、长达一整天的任务长度，你可以把它派出去，让它自己独立运行一段时间。围绕这种能力构建的产品类型会非常不同。你想给模型反馈，显然你并不希望它完全失控地跑一整天——也许你想，但你大概不想。然后你能让模型去做的事情的空间就会真正扩大。所以这是我非常期待看到的事情。另一个在未来 12 到 18 个月里会很酷的事情是多模态模型的改进。实际上，说到多模态，我主要指的是音频。模型在音频方面已经相当不错了，但我认为未来 6 到 12 个月里它们会在音频上变得好得多，尤其是那些原生的多模态模型、端到端语音模型。我觉得在多模态音频方面，也有一些关于新型模型和架构的有趣工作正在进行。但音频，尤其是在企业和商业场景中，仍然是一个被严重低估的领域——所有人都在谈论编程，都是文本，但我们在用音频交流，世界上大量的商业是通过音频完成的，大量的服务和运营也是通过说话和音频来进行的。所以我认为这个领域在未来 12 到 18 个月里会看起来非常令人兴奋。而且我认为我们在音频模型方面能做到的事情会有更多的解锁。太棒了。快速总结一下：预计 agent 和 AI 工具的运行时间会更长，这个趋势会继续增长；然后音频和语音会变得更重要，更加 first party、更加原生、更加出色，并成为体验的核心。是的。太酷了。好的，我想回到你的一个热门观点，另一个我看到你讨论过的观点。你对 AI 领域的业务流程自动化非常看好。聊聊这个吧。是的，这回到我之前提到的那个观点——我们生活在硅谷的泡沫里，我们所习惯的很多工作，比如软件工程、产品管理、打造产品，其形态与支撑整个经济运转的工作非常不同。我在与客户交流时不断看到这一点。如果你去和任何一家非科技公司交谈，你会发现那里存在大量的业务流程。我这么说是什么意思呢？我通常这样划分：软件工程有点像开放式的知识工作，对吧？这就是为什么我认为像 Codex 这类工具往往表现相当好，因为它在探索，你在给它一些开放式的任务。但软件工程从根本上说是相当开放的，而且可重复性不高——你开发一个功能，不会试图一遍又一遍地开发完全相同的功能。很多科技类工作都属于这个范畴，我觉得数据科学也在一定程度上如此，甚至一些战略性财务工作也是这样。但当你离软件工程和科技核心越来越远时，很多工作其实就是业务流程。它们是可重复的事项、可重复的运营操作，由公司的某位经理不断迭代优化。通常有一套人们想要遵循的标准操作流程，你不希望偏离太多。要知道，在软件工程中，创造力并不在于偏离流程，但世界上大量的工作实际上只是在按流程和操作规程执行。比如我打客服热线，他们就是在按流程办事；我打电话给公用事业公司，他们能做什么、不能做什么，都有一整套流程。因此，我对这一大类应用极其看好，而且我认为它被低估了，因为它与我们在硅谷惯常思考的东西太不一样了，人们往往不会想到它。但问题是，我们如何将 AI 以及我们现有的一些工具和框架应用到这类业务流程自动化中，让具有高确定性的、可重复的业务流程变得更自动化、更简单，并且与业务数据、业务决策以及企业内的不同系统完全打通？我们如何真正优化这一流程？因为我确实认为这个领域有很多机会和很多工作要做，而我们之所以不怎么谈论它，是因为它稍微超出了我们的舒适区。所以你的观点——为了确保我完全理解——是你认为在工程领域之外，AI 对企业生产力有着大得多的机会产生影响，也会影响那些从事重复性、易被自动化任务的人的工作，还会影响工作本身的完成方式，因为很多工作都是以这种方式进行的。比如我一直在和大企业客户交流，他们问：AI 将如何改变我的公司？在 20 年后的 AI 世界里，它将如何运转？软件工程只是其中一部分，但业务流程方面的空间要大得多。而且我认为业务流程那边的变化可能看起来会更加不同，那边的工作量也是相当可观的。这其实很有意思。从绝对比例或绝对值来说，我不知道它到底比软件工程更大还是更小。软件本身也非常庞大、非常广泛。但业务流程这边确实非常巨大，而且绝对比你基于人们在 X 或 Twitter 上的谈论（或是不谈论）所想象的要大。好的，稍微换个方向。既然你们搭建了这个平台、构建了 API，那些在 API 之上做开发的人心里最大的疑问始终是：我怎么才能不让 OpenAI 压垮我的想法、自己做同样的东西，然后摧毁我开创的这个市场？总体政策是什么？初创公司应该如何思考 OpenAI 不太可能进入的领域，这背后的总体理念是什么？我对此的总体回答是，市场非常、非常庞大，实际上我认为初创公司根本不该过度去思考 OpenAI 或其他实验室会往哪个方向发展。我聊过很多初创公司，有些没做成，有些做得很好。我见过的每一家最终失败的初创公司，都不是因为 OpenAI、某家大型实验室或 Google 过来压垮了他们，而是因为他们做的东西确实没有引起客户共鸣。而那些起飞的公司，即使在像编程这样竞争非常激烈的领域——比如 Cursor 现在已经非常大了——也是因为他们做出了人们真正热爱的东西。所以我的一般建议是，不要为此过度焦虑。只要做出人们喜欢的东西，你就会有自己的空间。我现在这个机会有多大，怎么强调都不为过。用 AI 做建设的机会空间是如此之大。一个很好的例子是，这个空间大到完全改变了风险投资家可接受与不可接受之事的“奥弗顿窗口”。风投们现在在左右投资相互竞争的公司，就是因为这个空间太大了，因为这个机会是我们以前从未见过的。虽然这影响了风投的运作方式，但从初创公司的角度来看，这是世界上最赋能的事情，因为即使你只是做出了一些让某些人非常、非常热爱的东西，你最终也会拥有一家价值巨大的企业。所以我才跟大家说，别想太多。另外，我认为还有一件事很重要，至少从 OpenAI 的角度来说：我们始终非常珍视的一点是——Sam 和 Greg 也从高层不断强调这一点——我们从根本上将自己视为一家生态平台公司。API 是我们的第一个产品。我们认为培育这个生态并持续支持它、而不是压制它，对我们来说非常重要。如果你看看我们做的决策，这一切都被贯穿其中。我们在自家产品中发布的每一个模型，都会在 API 中发布。比如现在我们发布了这些针对 Codex 工具链做了更多优化的 Codex 模型，但它们最终总会进入 API，我们所有的客户最终都会用到这些模型。我们不会在这方面有所保留。我们认为保持平台中立非常重要，所以我们不会封杀竞争对手，我们允许人们使用我们的模型。另外，我们最近也在更多地测试类似 "Sign in with ChatGPT" 这样的产品，所以我们想要培育这个生态，而且我认为这一点非常重要。关于这件事的整体思路是，水涨船高。我们现在可能更像一艘航空母舰，规模已经相当大了，但我们认为抬高水位很重要，因为所有人都能从中受益，我认为我们自己也会受益。比如我们的API本身增长就非常显著，正是因为我们秉持这种方式。所以我真的希望大家不要把OpenAI看作那种会把别人挤开的存在，而是专注于创造价值。我们始终致力于提供一个开放的生态系统。为什么这对OpenAI很重要？就是这种专注于打造平台、为人们创造创业途径的思路，是不是从一开始就有这样的愿景？我们希望这成为一个平台。这从一开始就是愿景所在。实际上这要追溯到我们的宪章，也就是我们的使命。OpenAI的使命一直都是：第一，打造AGI。显然我们正在做这件事。第二，则是将AGI的益处传播给全人类。这里的关键在于“全人类”。显然ChatGPT也在努力做到这一点，我们试图触达全世界尽可能多的人。但早在很早的时候——这也就是为什么我们在2020年左右就推出了API，真的非常早——我们就意识到，作为一家公司，我们无法触达全人类。世界每个角落都非常非常深入。所以我们实际上觉得，为了完成使命，我们需要某种平台化的东西，赋能其他人去构建，比如为播客主和newsletter作者打造客服机器人，因为我们自己不可能做完所有这些事。我们在API上很大程度上已经看到了这一点得以实现。这就是为什么我们与如此多的客户交流，并且真心乐于看到平台上构建出的多样化应用。是的，这一点从第一天就存在，因为我们视其为使命的一种表达。而且你们甚至还没提到你们正在推出的那个应用商店，就是ChatGPT应用商店。对。顺便问一下，那是归你们管，还是另一个团队负责？那是另一个团队。所以它是归在ChatGPT下面的。我们显然与他们合作非常紧密，他们构建了一个App SDK，这也是与我们团队密切协作完成的。但这更多是在ChatGPT的体系下。不过这也是另一个例子，对吧？ChatGPT拥有8亿周活跃用户，他们不断回流。作为企业，这是一项很棒的资产，但如果我们能以某种方式允许其他公司也进来利用这一点，为这个受众群体做开发，那岂不是更好？而且我们认为这最终也会帮助我们扩大这个群体。所以这一切都回归到使命上，我们发现成为平台、保持开放往往在这方面有所帮助。光是8亿这个数字，我觉得每周、每周……
每周有8亿人使用，每周。这太荒谬了，我们现在对这些数字已经习以为常，但这太疯狂了，前所未有。是的，从规模的角度老实说，这让我觉得难以想象。我的理解是，这相当于世界人口的10%，而且还在增长，一直在飙升。来使用ChatGPT，每天，哦不对，每周。在这一点上，我想进一步强调你说的这一点。OpenAI的使命是让AI惠及全人类。我觉得有些人对此嗤之以鼻。他们会说，这要钱啊，等等。但事实是，ChatGPT有一个任何人都能使用的免费版本，它与世界上现存最强大的AI模型相差无几，免费开放给任何人使用。如果你是一个亿万富翁，你能从AI中获得的东西，比起非洲某个村庄里的人能获得的，也多不到哪里去。我知道这一直对OpenAI非常重要。是的。我是说，这就是为什么我认为我们投入了很大精力在健康领域。我们也投入了精力在教育上，这会是非常有意思的方向。另一个疯狂的趋势是，免费模型随着时间推移变得越来越聪明。2022年的免费模型在当时还不错，但跟今天你能得到的完全没法比，因为现在你用的是GPT-5。所以，提升全球的基础水平是我们真正在努力做的事，我们视其为使命的一部分。另一方面，顺便说一下，谈到亿万富翁什么的。我知道人们会说，你用的iPhone和史蒂夫——哦对不起——马克·扎克伯格或亿万富翁们用的是一样的。但每月只要20美元，你基本上就在用和亿万富翁一样的AI。每月200美元，你就能获得和所有亿万富翁一样的Pro模型，但他们也不可能事事都用Pro。他们日常大概也就是用Plus那一档。所以，这种民主化，将这种益处传播到全世界，对我们非常有意义，也驱动着我们做的很多事。最后一个问题，针对那些正考虑基于API做开发，或者突然觉得可以用开放模型和API做出很酷东西的人。你们的API和平台能让人们做什么？我知道你们可以在平台之上构建agents。请讲讲你们提供了什么能力。从根本上说，API提供了一系列开发者端点，这些端点基本上允许你调用我们的模型。目前最受欢迎的一个叫做responses API。这是一个端点，专为构建长时间运行的agents而优化，也就是会运行一段时间的agents。在最基础的层面上，你基本上只需要给模型输入文本，模型会运行一段时间，你可以去轮询它，看看它在做什么，然后最终在某个时间点拿到模型的返回。这是我们为用户提供的最底层原语，实际上这也是很多人使用的方式。这是基于API构建的最流行方式。它非常开放，几乎没有预设观点，你基本上可以随心所欲。这是最底层的东西。我们也开始在之上构建越来越多的抽象层，来帮助人们构建这类应用。再往上一层，我们有叫做agents SDK的东西，它也非常非常受欢迎。这允许你使用responses API或我们其他一些API端点，来构建你更传统意义上认为的agent，比如一个AI在无限循环中工作，它可能有子agent可以委派任务。它实际上开始构建起所有这些框架和脚手架。至于这一切最终会走向何方，我们拭目以待。但这会让你更轻松地构建这类 agent，为它设置 guard rails，让它能够将子任务委派给其他 agent，并协调一群 agent。agents SDK 就能让你实现这些。再往上，我们还开始构建一些工具，帮助你在部署 agent 的元层面开展工作。所以我们有一款产品叫 agent kit 和 widgets，本质上是一组 UI 组件，能让你非常轻松地在我们的 API 或 agents SDK 之上构建出非常漂亮的 UI，因为很多 agent 从 UI 角度来看都很相似。此外我们还有一些 eval 类产品，比如 eval API，如果你想测试自己的模型、agent 或工作流是否正常运行，可以用我们的 EDOLs 产品进行非常量化的测试。所以，我把这些视为不同的层级，它们都在帮助你用我们的 AI、我们的模型构建你想要的东西，抽象程度越来越高，框架的预设性也越来越强。你可以使用整个技术栈，它能让你快速构建出一个 agent；也可以往下走到尽可能底层的 responses API，基于这个非常底层的接口构建任何你想要的东西。
Sherwin，你还有什么想分享的吗？在进入我们非常精彩的 lightning round 之前，还有什么想留给听众的，或者我们没聊到但你觉得可能有帮助的内容吗？我想留给听众的唯一一点是，我认为未来两三年将是科技界和创业圈很长一段时间以来最有趣的时期。我只想鼓励大家不要把它视为理所当然。我 2014 年进入职场，头几年很棒，但感觉之后有五六年，科技界并不怎么令人兴奋。而在过去三年里，这是我职业生涯中最疯狂、最激动人心的时期，我认为未来两三年也会延续这种状态。所以我鼓励大家不要认为这是理所当然。我自己也在努力不辜负这个时代。某个时刻，这股浪潮终会过去，会变得渐进式得多。但与此同时，我们将探索很多非常酷的东西，发明很多新事物，改变世界，改变我们的工作方式。这就是我想留给听众的主要内容。我很喜欢这个观点。我想再多聊几句。你说不要错过，你建议人们怎么做？是投身建设、lean in、学习、加入一家在做有趣事情的公司吗？对于那些说“好吧，我不想错过这波浪潮”的人，你有什么建议？是的，我只想说要去接触它。基本上就是你说的那样，lean in。在这上面构建工具是故事的一部分。只是使用这些工具——你不必是软件工程师也能投身其中。我认为很多工作都会因此改变。所以要去使用这些工具，了解它能做什么、不能做什么的局限，这样你就能观察随着模型进步，它开始能做哪些事情的趋势。基本上就是去习惯这项技术，熟悉它，而不是躺平，让它从你身边溜走。另一方面，我觉得有很多压力和焦虑，因为发生的事情太多了。我怎么跟得上？我这周得学习 cloudbot。天哪。你身处风暴中心，学到了什么？你怎么才能不过度焦虑、不担心错过正在发生的事，同时又能跟上新闻？你学到了什么，做了什么？是的，我觉得我个人在这方面是个坏榜样，因为我基本上长期泡在 X 和公司 Slack 上。所以我其实会吸收大量信息。但如果说我观察到的那些不像我这样沉迷于此的人，其实很多信息都是噪音。你不需要让 110% 的信息都进入你的大脑。说实话，只投身于一两个不同的工具，从小处着手，就已经绰绰有余了。我觉得行业疯狂的节奏加上 X 这个产品的特性，共同制造了这种 insane 的新闻节奏，老实说非常 overwhelming。关键是，你不需要知道所有这些，也能真正参与当下正在发生的事。哪怕只是像安装 Codex 客户端玩一玩，安装 ChatGPT，把它连接到几个你内部的数据源——Notion、Slack、GitHub——看看它能做什么、不能做什么，所有这些我觉得都是参与的一部分。太棒了。Sherwin，说到这里，我们进入了非常精彩的 lightning round。我有五个问题要问你。准备好了吗？是的，当然准备好了。第一个问题，你发现自己最常推荐给他人的两三本书是什么？哦，我来讲一本 non-fiction 和一本 fiction。fiction 的那本我刚读完，我真的非常推荐。是 Q&M 写的 *There Is No Antimemetics Division*。我觉得作者是在线作家，我是在 X 上看到有人分享的。这是一本科幻风格的书，我基本上两天就啃完了。写得超级好，超级精彩。讲的是一家政府机构对抗那些会让你忘记它的事物。所以这是一本非常聪明、非常有创意、题材也很新颖的书，我很喜欢。所以我推荐这本。这本书也无意之中很搞笑。它本来是想写成科幻甚至恐怖风格的，但有好几次把我逗笑了。所以这是 fiction 的推荐。non-fiction 的话，我要作弊一下，推荐两本。过去一年我读了更多关于中国以及中美关系的内容。我觉得去年出版的两本书在这方面真的让我大开眼界。第一本 Dan Wang 的 *Breakneck*，非常好。我很喜欢他的类比：美国是律师社会，中国是工程师社会，各有优劣。我读的时候就在想，嗯，是啊，美国确实像是被律师管理的。这是第一本。另一本是 Patrick McGee 关于 Apple 和中国的书，超级有趣。我是个超级 Apple 粉，如果你现在能看到我的桌子，全是 Apple 的东西。一方面，了解 Apple 与中国的关系非常迷人；另一方面，书中有很多关于 Apple 这家公司的内幕信息，我觉得很精彩。所以这也是一本非常吸引人的书，而且非常应景。这本 antimemetics 的书听起来太棒了。我现在边听你说边下单。对对对。好像也就两百来页。我 literally 两天就读完了。真的太精彩了。好的，感谢推荐。对了，你最近特别喜欢的一部电影或电视剧是什么？这个挺难回答的，因为我有两个孩子，工作又很忙，所以真的没什么时间看剧。不过要说最近几周，我确实看了几集。我是个资深动漫迷，所以看了几集 Jujutsu Kaisen 的新一季，也就是 JJK 第三季，真的很好看。总的来说，我是日本动漫的忠实粉丝。我觉得日本动漫能创造出最新颖、最独特的剧情和世界观，而西方媒体往往会回避这些。所以我一直很喜欢动漫，不过最近确实没怎么看，就刚看了几集 JJK。以你的身份来说，这完全可以理解。是啊。你最近发现并且特别喜欢的产是什么？好的。我最近需要搭建 Wi-Fi 和家庭网络，于是全套买了 Ubiquiti 的路由器和安防摄像头。我以前从没听说过这个牌子。以前一直用的都是很简单的设备。但这个产品做得实在太好了。不知道你用过没有，它基本上就是家庭网络领域的 Apple。产品设计很漂亮。但真正让它非常出色的是软件做得很好。他们有一个非常棒的手机 App，可以管理所有的家庭网络。基本上，你可以用 Ubiquiti 买无线路由器，不过家里需要预先布好 Ethernet 线才能用。但我其实觉得真正出彩的是他们的安防摄像头。如果你把安防摄像头接入 Ubiquiti 的生态系统，他们有一款 incredible 的手机 App，还有 Apple TV 和 iPad 的 App，可以查看摄像头的实时画面。价格虽然有点贵，但也没那么贵。总之，整个产品体验令人难以置信。好吧，我买的是 Eero，所以买错了。感谢推荐。
Eero 也挺好的。但我现在已经完全转向 Ubiquiti 了。推荐得好。还有两个问题。你有没有一句特别喜欢的座右铭，在工作或生活中会反复想起？有的。我总是对自己说的一句话是：永远不要自怜。工作和生活中总会发生很多事。提醒自己不要自怜，提醒自己永远有主观能动性去让自己振作起来，这是我经常对自己说的，也是我经常对别人说的一点。最后一个问题。你之前在 Open Door 工作过，负责的核心工作基本上是确定买房的价格。你搭建了一个模型，告诉公司“这套房我们出价多少”。那么，有没有哪个影响房价的变量是你没想到的，但实际上非常重要？有很多都挺意外的。我列几个最有趣的吧。一个是高压电线，它们对房价的影响其实非常大。我以前没真正意识到这一点，直到我去了达拉斯，亲眼看到有些房子旁边就是那种巨型高压线，嗡嗡作响。大多数人都有家庭，你肯定不想让孩子住在那附近。所以这一点真的让我挺意外的。这倒是能理解。是啊。另一个让我们一直很难量化的因素是户型。户型当然很重要，但要量化什么样的户型好、什么样的户型差，我们真的做了各种尝试，比如厨房多宽、是什么风格的厨房、主卧在哪里等等，但就是很难量化。我记得户型是个大问题，因为有时候有房子卖不出去，我们的运营团队去看就会说，这是户型问题。那你怎么判断呢？就是你走进去就能感觉到，你知道，户型给人的感觉。这也是让我很意外的。最后一个比我预想的更重要的因素是整体的路边吸引力，甚至包括前门。其实 Zillow 有本书就讲到过，换前门通常是房子投资回报率最高的一项。但作为买家走到房子前时的那种感受，你接触到的东西，以及房子给你的第一印象，我觉得我之前低估了它的重要性。这太有意思了。而且我很佩服你们得用代码把这些都搞清楚，而不是走进去肉眼判断户型。关于户型我有很多故事。户型资料没有被数字化，所以在凤凰城和达拉斯这些地方，有一小撮人手上有所有房子的纸质户型图。嗯，在 Open Door 那段时间有很多很多有趣的故事。好的，Sherwin，非常感谢你来做这期节目。聊得太棒了。大家可以在网上哪里找到你？听众能怎么帮到你？我在 Twitter 也就是 X 上活跃，用户名就是 Sherwin Woo。我主要发一些关于 OpenAI、API 以及我们发布的一些产品的内容。至于大家能怎么帮到我，我很喜欢听别人在做什么项目，所以如果你在创业，如果你在捣鼓什么想法，很欢迎你直接在 X 上联系我。我很想听听你在做什么，以及了解 OpenAI 能怎么支持你。太棒了。Sherwin，非常感谢你来参加节目。谢谢，Lenny。各位再见。非常感谢收听。如果你觉得这期节目有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客 App 上订阅。另外，也欢迎给我们打分或留下评论，这真的很能帮助其他听众发现这档播客。你可以在 lennispodcast.com 找到所有往期节目或了解更多信息。下期再见。