“工程师正在变成巫师”｜与 OpenAI Sherwin Wu 谈软件开发的未来
“Engineers are becoming sorcerers” | The future of software development with OpenAI’s Sherwin Wu
嘉宾：Sherwin Wu
全文文稿 · 按对话顺序保留完整内容，深入理解上下文。
本篇目录1 章节
§01原文文稿 · 00:00–1:19:15§01原文文稿 · 00:00–1:19:15
95% 的工程师使用 Codex。我们 100% 的 PR 都由 Codex 审查。
对工程师来说，我不知道过去几年还有什么工作变化得更多。
工程师正在变成技术负责人。他们正在管理一支又一支的代理，数量多得数不清。这真的让人感觉我们像是在施展各种魔法的巫师，而这些魔法会出去替你做事。
你觉得人们还没有把什么因素计入考量？
一个人创办十亿美元公司的二阶或三阶影响。要让一家由一个人创办的十亿美元公司成为可能，也许还会有另外 100 家小型初创公司在构建定制软件。所以我认为，我们实际上可能会进入 B2B SaaS 的黄金时代。
我越来越常听到一种说法：当人们的代理无法工作时，会感到压力。
OpenAI 内部有一个团队正在做一项实验，他们维护的是一个 100% 由 Codex 编写的代码库。他们正好会遇到你描述的那些问题。通常你会说：“好吧，我卷起袖子自己弄清楚。”但这个团队没有这条退路。
你分享过，倾听客户并不总是 AI 领域的正确策略。
这个领域和模型本身变化得太快了。它们往往会自我颠覆。模型会把你的脚手架当早餐吃掉。
对于那些想说“好吧，我不想错过这趟车”的人，你有什么建议？
确保你是在为模型将要发展的方向构建产品，而不是为它们今天的状态构建。有一句我们科学副总裁 Kevin Weil 的话，他喜欢说：“模型现在的状态就是它们永远最差的状态。”
今天的嘉宾是 Sherwin Wu，OpenAI API 和开发者平台的工程负责人。几乎每一家 AI 初创公司都会接入 OpenAI 的 API，因此 Sherwin 对正在发生什么以及未来走向有着极其独特而广泛的视角。短暂感谢我们出色的赞助商后，就进入正题。（00:01:30）：本期节目由 DX 赞助。DX 是由顶尖研究人员设计的开发者智能平台。要在 AI 时代蓬勃发展，组织需要快速适应，但许多组织领导者很难回答一些紧迫的问题，例如：“哪些工具有效？人们如何使用它们？到底是什么在创造价值？”DX 提供数据和洞察，帮助领导者应对这一转变。Dropbox、booking.com、Adyen 和 Intercom 等公司通过 DX 深入了解 AI 如何为开发者创造价值，以及 AI 对工程生产力产生了什么影响。想了解更多，请访问 DX 网站 getdx.com/lenny，网址是 getdx.com/lenny。（00:02:14）：应用程序可能以各种方式出问题：崩溃、变慢、回归，以及只有真实用户出现后你才会发现的问题。Sentry 会捕捉这一切。你可以查看哪里发生了什么、为什么发生，追溯到引入错误的提交、发布代码的开发者，以及确切的代码行，所有信息都集中在一个相互关联的视图里。我肯定试过开五个标签页再配一条 Slack 线程来调试，这种方式更好。Sentry 会展示请求如何流转、运行了什么、哪里变慢，以及用户看到了什么。Sentry 的 AI 调试代理 Seer 会接手后续工作。它利用所有这些 Sentry 上下文告诉你根本原因、建议修复方案，甚至为你开一个 PR。它还会审查你的 PR，发现任何破坏性变更，并准备好修复方案。前往 sentry.io/lenny 免费试用 Sentry 和 Seer，并使用代码 LENNY 获得 100 美元的 Sentry 额度。这就是 S-E-N-T-R-Y.io/lenny。（00:03:15）：Sherwin，非常感谢你来到这里，欢迎参加这档播客。
谢谢你。谢谢你的邀请。
我想从一个像是 AI 进展晴雨表的问题开始，尤其是在工程领域：现在你的代码中有多少是 AI 写的？如果你现在还写代码的话，你和你的团队的代码又有多少是 AI 写的？
我现在偶尔还会写代码。实际上对像我这样的管理者来说，使用这些 AI 工具比手动写代码容易得多。所以就我自己以及 OpenAI 的一些其他工程经理而言，我们现在所有的代码都是 Codex 写的。但更广泛地说，内部充满了能量。大家对这些工具已经发展到什么程度、Codex 作为工具对我们来说变得多么好，感受到一种切实的兴奋。我们很难准确衡量有多少代码是写出来的，因为绝大多数代码，我会说接近 100%，通常都是先由 AI 生成的。不过我们会追踪的是：现在绝大多数工程师每天都在使用 Codex。因此，95% 的工程师使用 Codex。（00:04:21）：我们 100% 的 PR 每天也都会由 Codex 审查。所以，基本上任何进入生产环境、被合并的代码，Codex 都会看过，并在 PR 中提出改进和修改建议。这就是我们内部看到的情况。但最令人兴奋的还是整体的能量。 （00:04:40）：我们还有一个观察：倾向于更多使用 Codex 的工程师会提交多得多的 PR。他们实际提交的 PR 比不太使用 Codex 的工程师多 70%。而且这个差距还在扩大。所以我觉得，那些提交更多 PR 的人正在不断学习如何更好地使用工具，效率越来越高，70% 的差距也在持续扩大。自从我上次查看这个数字后，它可能实际上又增加了。
好，为了确保我们听懂你的意思：你的意思是，OpenAI 这 95% 工程师写的所有代码都是 AI 写的，先由 AI 写出来，再由他们审查？
是的，是的。
这太疯狂了，疯狂到现在几乎已经不疯狂了，我们正在逐渐习惯这一切。
我觉得大家还在适应，明确说来确实如此。我也认为有些工程师对 Codex 的信任稍微低一些，但我基本上每天都会遇到一个人，被某件我能做到的事震撼到，然后他们对模型的信任程度，或者说愿意让模型独立完成的事情的范围，就一次又一次地提高。我们的科学副总裁 Kevin Weil 有一句话，他喜欢说：“模型现在的状态就是它们永远最差的状态。”所以，对于软件工程来说，这就是模型永远最差的状态。随着时间推移，你会看到人们越来越信任它，同时也会看到模型越来越好。
是的。Kevin Weil 曾经参加过这档播客，他在这档播客里说过几次完全一样的话。
是的，这句话很棒。
是的，最近那个开发者——Clawdbot/Moltbot/OpenClaw，现在叫这个名字——分享过他在工作中使用 Codex 的经历。他觉得无论 Codex 做什么，他都会相信它做对了，几乎可以确定直接提交到 master 分支也会没问题。
是的，是的。他是 Codex 的优秀用户。我知道他和团队保持密切联系，也会给我们很好的反馈。他使用 Codex 并不令人意外。我的意思是，抱歉，现在叫 OpenClaw。
OpenClaw。对。
OpenClaw 是个很棒的产品。然后我今天早上看到了这个，我是说，这件事非常新，但今天早上我想 Moltbook 也是我们分享过的东西，看着所有 AI 代理互相交谈，感觉非常超现实。
听起来基本就是现实版的《她》。
是的。
回到我们正在经历的、尤其对工程师而言非常疯狂的时刻：我们已经从“你亲自写每一行代码”走到“AI 写下全部代码”。我不知道过去几年还有什么工作变化得更多，原本谁都没预料到它会变化这么多，以至于工程师的工作方式在整个职业生涯中都如此不同。短短几年，现在已经变成“我不再写代码了”。你觉得未来几年工程师的角色、软件工程师的工作会是什么样？这份工作究竟是什么？
是的，说实话，看到这种变化真的很酷。这也是令人兴奋的地方，因为未来一到两年里，这份工作可能会发生非常大的改变。不过我们似乎还在摸索阶段。所以我知道，尤其是一些软件工程师，会对这种罕见的时刻感到兴奋：也许接下来 12 到 24 个月，我们可以亲自摸索出一切，并为自己设定标准。（00:07:52）：关于我看到的方向，有一种大家都在说的共同看法：个人贡献者工程师正在变成技术负责人。他们现在基本上像管理者一样，管理一支又一支的代理。我知道团队里的很多工程师同时会有 10 到 20 条线程在推进。显然，这些不全是正在运行的 Codex 任务，而是许多并行线程。他们会检查进展，指挥代理和 Codex，并给它们反馈。所以他们的工作已经从亲自写代码，真正转变成近似管理者的角色。（00:08:32）：至于一到两年后会走向哪里，我经常回到的一个比喻其实来自我大学读过的一本编程教材，叫 SICP。不知道你是否听过，《计算机程序的构造和解释》。所以是 SICP。它在 MIT 很受欢迎，曾经长期作为入门编程课的教材。它有一种小众但狂热的追随者。它教你编程，也教你一种叫 Scheme 的 Lisp 方言。因此它会带你接触函数式程序设计，以这种方式来说非常开阔思路。（00:09:14）：但那本书让我印象深刻的地方是，我大学时读过它。开头部分把编程描述为一种学科，并把它比作巫术。它说软件工程师像巫师，编程语言像咒语，你在施放法术，而这些法术会出去替你做事。挑战在于，你需要念出什么咒语，才能让程序做你想让它做的事情？（00:09:43）：这本书写于 1980 年，已经是很久以前了。我认为这个比喻一直延续至今。随着我们进入 vibe coding，或者说软件工程的新阶段，这个比喻实际上正在变成现实，因为编程语言本质上就是咒语。它们随着时间改变，而趋势一直是：通过编程让计算机做你想做的事情变得越来越容易。（00:10:07）：我认为当前这波 AI 可能就是这种演化的下一阶段。现在它确实是咒语，因为你可以告诉 Codex 或 Cursor 你想做什么，它们就会替你去完成。我尤其喜欢巫师和巫术这个比喻，因为我觉得我们目前的状态开始接近《幻想曲》里的《魔法师的学徒》：米奇找到了魔法师的帽子，试着做各种事情。（00:10:36）：我觉得这确实是非常贴切的比喻。一方面，现在它非常强大，你施放的这些咒语具有极高的杠杆效应；但另一方面，你必须知道自己在做什么。《魔法师的学徒》的整个情节就是米奇失控，扫帚发疯，一切都被水淹没。我记得他让扫帚开始做一项任务，然后自己去睡觉。这就像最极致的 vibe coding。最终老魔法师回来收拾残局。（00:11:06）：当我看到工程师同时运行 20 个不同的 Codex 线程时，其中确实需要技能、资历和大量思考，因为你必须确保模型没有偏离轨道。你绝对不能彻底离开、不管它在做什么，但这种方式的杠杆效应也极高。一位非常资深、熟练使用这些工具的工程师，现在可以通过自己的操作完成多得多的事情。我认为这也是它有趣的地方。我们真的感觉自己现在像巫师，仿佛更接近一种魔法般的体验：施放各种法术，让软件替你完成所有这些事情。
你描述这个比喻时，我也正好在想《魔法师的学徒》。所以很高兴你提到了它。上一位参加这档播客的嘉宾把它描述成一个会实现愿望的精灵，这是个有用的框架，因为你必须非常明确自己想要的愿望。如果你想变大，你要多大——
是的。也可能像《猴爪》那样：你得到了自己想要的东西，但副作用是什么？
对。
是的。我觉得这个比喻很棒。对我来说，SICP 这本书的持久影响力也很不可思议。人们把它叫作“巫师之书”，因为这就是贯穿全书的比喻。而我们现在基本已经走到了那个阶段，这真的很酷。
我想沿着两个方向继续。一个是，我越来越常听到一种说法：当人们的代理无法工作时，会感到压力。你启动了这么多 Codex 代理，然后必须持续关注它们：“糟糕，有一个不工作。我在浪费时间。”你有这种感觉吗？你的团队里也有这种感觉吗？
是的，这种事一直在发生。我实际上认为，这正是目前这一切中最有意思的部分，因为这些模型并不完美，这些工具也不完美，而我们仍在努力弄清楚如何最好地与 Codex 或这些 AI 代理互动，以完成工作。我们一直会遇到这种情况。我们内部有一个特别有意思的团队。（00:13:05）：有一个团队现在正在 OpenAI 内部做一项实验，他们基本上维护着一个 100% 由 Codex 编写的代码库。你会让 AI 写代码，但显然最后会重写其中很多内容，可能还需要复核并修改。但这个团队完全沉浸在 Codex 中，彻底投入使用它，因此会遇到你描述的那些问题：他们想要构建某个功能，却无法让代理完成。（00:13:36）：通常这时你还有一条退路，会说：“好吧，我卷起袖子自己弄清楚。”然后你不再使用 Codex，可能会改用制表补全、Cursor 之类的工具。但这个团队在实验中没有这条退路。于是问题就变成：我怎样才能让代理完成这件事？我认为我们可能会发布一篇博客文章，分享从这里得到的一些经验，其中会涌现出许多迷人的范式和最佳实践。（00:14:03）：我们注意到一件有意思的事，我不知道你是否也有这种感觉，但我们在这里肯定能感受到：很多时候，当编码代理没有按你的要求做时，通常是上下文出了问题，也就是你提供给它的信息有问题。可能是你没有把要求说清楚，或者代理、Codex 没有足够的信息来了解如何完成某件事。（00:14:25）：因此，解决问题的挑战就变成了添加文档，围绕这个限制工作，把你脑中的更多内部知识编码进代码库。你可以通过代码注释、代码结构，或者通过 .md 文件、Skills 以及仓库中的任何其他附加资源来完成，让模型更好地执行任务。（00:14:53）：这个团队还有大量其他经验值得探索，我觉得很有意思。不过，移除“不再使用 AI”这条退路后，他们开始拼凑出很多真正投入使用代理时必须解决的问题。
人们还会遇到另一个问题。你刚才说大家提交 PR 的速度快得多，使用 AI 时 PR 数量也多得多。显然，代码审查正成为更大的挑战。你们团队有没有找到什么方法，既能加快代码审查，又能让它实现规模化，而不是把它变成一种可怕的工作，让人们整天坐在那里审查 PR？
有一点是，现在 Codex 会审查我们全部的 PR。所以我认为，一个很有意思的变化是，我们通常会立即交给模型的，往往是那些最让我们烦恼或软件工程中最无聊的部分。这也是现在工作更有趣的原因，因为我们可以做更多有趣的事情。（00:15:50）：就我个人而言，我非常讨厌代码审查，那是我最不喜欢的工作之一。我记得大学毕业后的第一份工作是在 Quora，当时我负责新闻推送，因此拥有新闻推送的代码。我也是新闻推送的审查者，那是所有人都会修改的核心代码。于是我每天早上登录，就会看到 20 到 30 个代码审查任务，心想：天哪，我得把这些全部处理完。我会拖延，然后数量涨到 50 个。代码审查实在太多了。（00:16:24）：Codex 非常擅长审查代码。我们注意到，尤其是 5.2 版本，在代码审查方面的能力变得极强，特别是当你把它引导到正确方向时。因此，虽然我们提交的 PR 很多，但 Codex 会审查全部 PR；它会把代码审查从我不知道的 10 到 15 分钟任务，有时缩短为两三分钟，因为很多建议已经预先生成好了。（00:16:50）：很多时候，尤其是对于小型 PR，实际上甚至不需要人来审查。我们在这方面相当信任 Codex。代码审查的好处是有第二双眼睛，确保你没有做蠢事。现在 Codex 已经是一双相当聪明的第二双眼睛。因此，这是我们大力投入的一件事。（00:17:10）：现在，通用 CI 流程以及代码推送和部署后的流程，也已经通过 Codex 在内部实现了高度自动化。和很多工程师聊过就知道，他们最烦恼的事情是：写完漂亮的代码之后，如何把它放进生产环境？你得跑各种测试，处理 lint 错误和代码审查。Codex 可以做很多自动化工作。因此我们在内部构建了一些工具，帮助自动化这个过程，自动处理 lint。如果出现 lint 错误，Codex 很容易修复，它可以直接打补丁，然后重新启动 CI 流程。我们正努力把所有这些压缩成工程师尽可能少的工作，结果就是他们现在可以合并并推出更多 PR。
Codex 写代码，Codex 审查自己的代码。我想知道，你们是否愿意使用其他模型来审查自己模型的工作？这条路可行吗，还是说已经足够好了，不需要别的？
我会说，这里确实存在循环问题。回到《魔法师的学徒》，你要确保自己没有让扫帚失控。因此，我们会非常谨慎地判断哪些 PR 可以完全由 Codex 审查。大多数人当然仍会看自己的 PR。所以并不是人类关注度降到了零，更像是从 100% 的关注降到 30%，这有助于让事情推进。（00:18:30）：关于多个模型，我们当然在内部测试很多模型，所以有大量模型可用。我们较少使用外部模型。我们认为，亲自使用自己的模型并从中获得反馈很重要，但你也可以使用许多内部模型变体，让它们从不同角度审查，我们发现这种方式效果很好。
好，为了了解今天 OpenAI 在 AI 和代码方面的现状，我确认一下，然后我们再聊别的话题：现在 OpenAI 的所有代码都是 Codex 写的吗？可以这样概括吗？
我不会说今天在生产环境运行的代码 100% 都是 AI 写的。而且这里很难做归因，但现在几乎每一位工程师都会在所有任务中大量使用 Codex。所以如果让我估计，目前绝大多数代码可能都是 AI 编写的。
太不可思议了。好，我们一直在讨论个人贡献者角色，也就是个人贡献者工程师的工作。相比之下，关于管理者角色变化的讨论更少，尤其是工程经理。随着 AI 兴起，你作为管理者的生活发生了什么变化？你认为未来管理者的角色会是什么？
管理者的变化肯定比工程师少。现在还没有给管理者用的 Codex。不过我会大量使用 Codex 来处理一些更偏管理的任务。我会说有几件事正在变化，存在一些趋势。我不认为变化已经很大，但我能看到趋势，如果把它推演下去，就会明白很多事情会走向哪里。一件越来越明确的事是，Codex 真正让顶尖表现者的生产力大幅提高。我认为这可能更广泛地适用于整个社会的 AI：真正投入其中的人、有高度能动性的人，以及真正学会使用这些工具的人，会给自己超级充电。我现在也注意到了这一点：顶尖表现者最终会变得高效得多，因此团队生产力的分布会变得更宽。（00:20:50）：我的管理理念一直是把大部分时间花在顶尖表现者身上，确保他们没有阻碍，确保他们快乐，确保他们有生产力、觉得自己的意见被听见。我认为在 AI 世界里，这一点更加正确，因为你的顶尖表现者将使用这些工具迅速领先。我想到的一个例子就是那个维护 100% Codex 生成代码库的团队，让他们放手探索，看看会发生什么。这已经带来了回报。（00:21:20）：所以我看到的一个趋势是，管理者可能会继续投入更多时间在顶尖表现者身上。另一点更像是一种观察，但我的感觉是，现在有很多 AI 工具可供管理者使用。它们不一定用来写代码，也可以是接入组织知识的 ChatGPT，帮助管理者进行研究，更好地理解组织背景。（00:21:50）：另一个很好的例子是，我们现在正在进行绩效评估。把接入内部知识、GitHub、Notion 文档和 Google 文档的 ChatGPT 用起来，其实很容易了解某个人过去 12 个月做过什么，并为此写一份深入研究报告。我的感觉是，在这个世界里，管理者将能够管理更大的团队，就像软件工程师可以管理 20 到 30 个 Codex 一样。我感觉这些工具会让人员管理者拥有更高的杠杆，也能让他们管理远超当前最佳实践的团队规模；对于软件工程来说，当前最佳实践大概是 6 到 8 人。（00:22:30）：在支持或运营等非工程领域，你也能看到类似情况：以前支持团队的规模可能有限，但当你能把更多工作交给代理时，就可以完成更多工作，也能以这种方式管理更多人。（00:22:50）：我认为人员管理也可能发生同样的事，尤其是在科技公司。我们已经看到了这种情况：有些团队的工程经理正在管理相当多的人，而且做得非常出色，因为这些工具让他们拥有更高杠杆，能更好地了解团队正在做什么，更好地理解组织背景，并以这种方式开展工作。
我很喜欢这个建议。你的描述是，你一直倾向于投入更多时间在顶尖表现者身上，为他们清除阻碍，确保他们快乐。Marc Andreessen 刚刚参加过这档播客，他的说法是：AI 会让优秀的人变得更好，让杰出的人变得卓越。你在这里说的是，继续做更多这样的事情可能是正确选择：花更多时间在团队中最优秀的人身上，为他们清除阻碍，确保他们拥有所需的一切。
对。一个很好的例子是，现在内部有一群工程师非常沉浸在 Codex 中，正在思考与这个模型互动的最佳实践。这对他们来说是极高杠杆的事情。作为管理者，我会说：“对，去探索吧。”无论从中产生什么最佳实践，我们都必须与整个组织分享。我们会举办各种知识分享会，在各处分享文档和最佳实践。诸如此类的事情会提升所有人。所以我把它看作我们正在看到的另一个趋势例子：顶尖表现者真正变得卓越。
人们都能感觉到，这件事很重大。AI 正在改变很多东西，世界也在变化。这会产生巨大影响。你觉得人们还没有把什么因素计入将要发生的变化和未来走向？有没有一个例子，让你觉得“好吧，我们还没有意识到这一点”？
我最喜欢的、从整个 AI 浪潮中出现的说法之一，就是“一人十亿美元初创公司”。我实际上觉得可能是 Sam 提出或第一个说出这个说法的人，但思考它很有意思。也就是说，如果人们的杠杆率如此之高，那么某个时候很可能会出现一家由一个人创办、价值十亿美元的初创公司。（00:24:53）：虽然我觉得这非常酷，但我认为人们还没有真正把它的二阶或三阶影响计入考量。因为“一人十亿美元初创公司”意味着，一个人使用这些工具后，可以拥有多得多的能动性和杠杆，因此很容易完成企业需要完成的一切，最终创造出一家价值十亿美元的公司。（00:25:19）：但我认为它还有几个其他含义。其中之一是，如果一个人很容易创建一家一人十亿美元初创公司，那也意味着人们创建普通初创公司会容易得多。我认为这会带来一个巨大的初创公司和小型企业繁荣期：任何人都能为任何事情构建软件。（00:25:45）：你已经开始在 AI 初创公司领域看到这种趋势：软件变得更加垂直化，为某个垂直领域创建 AI 工具通常效果很好，因为你真正深入了那个领域，也真正理解它的使用场景。如果把 AI 的发展推演下去，这类初创公司数量增加 100 倍也没有理由不可能。（00:26:13）：所以我们可能会看到这样一个世界：为了让一家一人十亿美元初创公司成为可能，还会有大约 100 家其他小型初创公司构建定制软件，为其他类型的一人十亿美元初创公司提供非常好的支持。因此我认为，我们实际上可能进入 B2B SaaS，以及软件和初创公司整体的黄金时代。（00:26:38）：这是一个非常有意思的趋势。随着构建软件越来越容易，运营公司也越来越容易，你可能会看到更多这类初创公司。我的思考方式是：可能会有一家一人十亿美元初创公司，但也可能有 100 家一亿美元初创公司，还有数万家一千万美元初创公司。作为个人，拥有一家一千万美元的企业其实已经非常好了，那已经足够让你一生无忧。所以我们可能真的会看到这种爆发，而我觉得人们还没有真正把这一点纳入思考。（00:27:20）：这还有一个三阶影响。同样，越往外推演，预测的不确定性就越高。如果我们最终进入这样一个世界：一些微型公司为拥有并经营企业的一两个人构建软件，我认为初创公司生态会改变，VC 生态也会改变。我们可能会进入这样一个世界：只有少数大型参与者提供平台并支持所有这些初创公司；而那些能让投资增长 100 倍或 1000 倍、真正带来风险投资级回报的初创公司类型，可能会减少。因为大量 1000 万到 5000 万美元的公司并不适合风险投资回报，但对于那些高度能动、真正投入 AI、为自己构建这些企业的个人来说却很好。
我喜欢我们已经讨论了这么多阶的影响。我现在想听听四阶影响，Sherwin。我开玩笑的。
四阶对我来说太烧脑了。我想不到那么远。
这就像《盗梦空间》，你越深入每一层，在销售每一层的过程中一切都变得越慢。好。关于一人十亿美元初创公司，我经常思考这个问题，因为我不可能创办一家十亿美元初创公司，我做的事情无论如何都不具备风险投资规模，也没有很高杠杆。但我看到自己收到这么多支持工单，很多问题荒谬到极点，这让我很难想象一家公司只有一个人……我对这种十亿美元初创公司持怀疑态度。我只是想简单分享这个想法，因为支持成本很高。即使 AI 在十亿美元规模上帮助你，除非你的平均合同价值很高、客户数量很少，否则光是处理支持就很难。人们会说他们能自己解决问题，但他们会想：“算了，我还是发邮件给支持，问问这件事。”（00:29:12）：根据我的经验，处理这些事情很难规模化。所以在我看来，除非你有一批承包商，而我也不知道那是否还算一人公司，否则要把一家十亿美元初创公司规模化，很难做到至少没有人帮你处理支持工作。我认为 AI 也只能带你走到这一步。
我认为这是真的。其实我的看法略有不同：我认为 Lenny’s Podcast 可能最终会成为一家十亿美元初创公司，但我觉得可能发生的事情是，你不必亲自派出 AI 去解决和修复那些支持工单，而是会有一大批其他初创公司构建软件，专门满足你的需求。可能会有 10 或 20 家初创公司为播客和 newsletter 构建支持软件。它们可以是一人初创公司，不需要很大，而且可以非常容易地编写出自己的产品。因为产品非常定制、独特，而且希望对你有用，所以你这个一人十亿美元初创公司可能会购买它。
我会买。我会买。
对。这涉及哪些事情由你内部完成，哪些事情外包。我认为，由于运行软件和构建产品的成本大幅下降，你可能会把很多事情外包出去，从而缩小公司的规模。这就是我认为可能出现的世界。对于这里会发生什么，我的确定性并不高，但最终结果仍可能是：一个人驱动一家高杠杆的大公司，而且它的价值可能真的达到十亿美元。
我能想象这一点。我还会想到 Clawdbot/Moltbot/OpenClaw 的 Peter，他现在被各种请求、邮件、提醒、私信和 PR 淹没了。我很好奇……而且他甚至还没有从这个东西上赚到钱。
是的，我无法想象他现在是什么感受。一定完全疯狂了。可能就像我们发布 ChatGPT 后的几个月，那种疯狂程度。
他是一个人。顺便说一句，他一周后会来参加这档播客。
哦，那很令人兴奋。是的。
也许第四阶影响是，分销会变得越来越重要，因为有太多该死的东西在争夺你的注意力。所以拥有受众和平台的人会变得越来越有价值，这是一件好事。（00:31:40）：好，我想回到你的管理工作。我很喜欢你关于把更多时间花在顶尖表现者身上、并且因此取得成功的洞察。想想你作为一个团队管理者，负责构建基本上支撑整个 AI 经济的平台，每一家 AI 初创公司都在你的 API 上构建。显然你做得很好。你还学到了哪些核心管理经验？你认为作为工程师和普通人的管理者，成功最重要、最关键的是什么？
我在这里学到的很多经验，我不知道它们是否特别适用于 OpenAI API，或者特别适用于我们的某些企业产品。我管理理念显然随时间改变了，但我认为相比变化，它一直保持不变的部分更多。（00:32:31）：其中一项原则就是我之前和你谈到的：花很多时间和顶尖表现者在一起。更具体地说，就是把超过 50% 的时间花在顶尖表现者身上，也许是表现最好的前 10%，真正、真正努力地赋予他们力量。（00:32:48）：我的思考方式会回到“软件工程师像外科医生”这个比喻上，它来自《人月神话》。这其实很有意思，因为我是从书里引用的，但在书中，他们实际上描述了一个世界。我认为他们是在预测未来，因为这本书大概写于 70 年代。（00:33:10）：他们说，软件工程可能最终进入这样一个世界：软件工程师像外科医生，或者像手术室里的人。有一个人负责执行工作，就像一个人负责切开并做手术，房间里的其他人都只是支持他。护士、助手、住院医生和专科培训医生都会在那里。外科医生说：“我要手术刀。”他们就把手术刀递给他；然后他说：“我要这个工具和这台机器。”他们就把它们拿过来。所有人都在那里支持这一个外科医生。（00:33:40）：所以《人月神话》实际上预测，软件工程会朝这个方向发展。我不认为现实完全如此，因为软件工程更协作，并不是只有一个人做工作，但我一直很喜欢这个比喻。这个比喻其实是我管理理念的努力方向：软件工程不像手术，并不是一个人完成所有工作；但我希望用对待团队成员的方式，以及自己作为管理者的行为，让他们感到自己像一名外科医生。我会赋予他们力量，确保支持他们，确保他们拥有完成工作所需的一切，让他们感觉像有一支军队在提供支持、提前发现问题并给他们所需的一切，而实际上这可能只有我这个管理者。（00:34:27）：我举的例子是，提前发现问题并清除阻碍，尤其是从组织层面清除阻碍，极其、极其有用。再回到 AI 的讨论，这在今天更加重要，对吧？如果人们不断提交一个又一个 PR，那么阻碍进展、阻碍交付的主要因素往往是组织或流程问题。如果你作为管理者能提前发现问题并为团队清除阻碍，就像外科医生需要手术刀，而管理者已经准备好手术刀，这就是最佳情况。这就是我处理管理、尤其是工程管理的方式。这一点一直伴随我的职业生涯。虽然软件工程师不完全是外科医生，但这个比喻一直留在我的脑海里。
我喜欢这个。我在想，也许 AI 能帮助管理者提前发现问题，预测某位工程师会被哪个决定卡住，我们需要弄清楚这个，我们需要——
对，这其实是个很好的观点。我还没试过，但我在想，如果我让接入公司知识的 ChatGPT 找出当前阻碍，会发生什么？浏览所有 Notion 文档，也许还有 Slack 消息，Slack 里可能有这些信息：我团队当前有哪些阻碍？我能做什么来帮助？这非常有意思。我之前没想到，但你说得对。
我们刚刚就在这里得到一个洞察。
对。对。
而且更有意思的是，你预计未来几个月这位工程师或这个团队会遇到什么阻碍？
对，你可以让模型，也就是让 AI，推演二阶和三阶影响。
这就对了。
预测这一点，也预测下个月的阻碍会是什么。
我觉得我们刚刚有了一个好想法。
对。
本期节目由 Datadog 赞助，现已将领先的实验和功能开关平台 Eppo 纳入旗下。全球最优秀公司的产品经理使用 Datadog，这也是工程师每天依赖的同一平台，用来把产品洞察与 bug、用户体验摩擦和业务影响等产品问题连接起来。首先是产品分析，产品经理可以观看回放、查看漏斗、深入留存并探索增长指标。（00:36:34）：其他工具止步的地方，Datadog 还能继续深入，帮助你诊断漏斗流失、bug 和用户体验摩擦的影响。知道重点后，实验可以验证什么有效。我在 Airbnb 工作时亲眼见过这一点，我们的实验平台对于分析什么有效、哪里出了问题至关重要，而在 Airbnb 搭建实验平台的同一团队创建了 Eppo。（00:36:56）：Datadog 还可以通过会话回放超越数字本身，利用热图和滚动图准确观察用户如何互动。所有这些都由绑定实时数据的功能开关驱动，让你安全发布、精准定向并持续学习。Datadog 不只是工程指标工具，它能让优秀的产品团队更快学习、更聪明地修复问题，并更有把握地交付。前往 datadoghq.com/lenny 申请演示。（00:37:27）：好，我们转向你们构建的 API 和平台。你和很多公司合作，让它们实施你们的 API、在你们的工具上构建。你告诉我，很多公司的 AI 部署实际上是负 ROI。我觉得很多人读到、感受到并想到的正是这样，而且有意思的是你确实在观察这种情况。问题出在哪里？他们做错了什么？AI 部署和 ROI 的世界发生了什么？
明确说，我没有看到这方面的定量数字。其实很难衡量，但特别是从观察一些尝试做 AI 的公司来看，如果很多 AI 部署实际上是负 ROI，我不会感到意外。全国各地、尤其科技行业之外的人，也普遍觉得 AI 是被强行塞给他们的。我认为，这可能部分就是一些负 ROI AI 部署的症状。（00:38:35）：我观察到几件事。首先，我们硅谷人总忘记自己生活在泡泡里。Twitter 是泡泡，抱歉，现在叫 X；硅谷是泡泡，软件工程也是泡泡。（00:38:51）：世界上大多数人、美国大多数人都不是软件工程师，也没有深度投入 AI，更不会关注每一次模型发布。所以他们完全不了解如何使用这项技术。我们总是在谈 Codex 的最佳实践、OpenAI 内部那些深度使用 Codex 的人。我确信 X 上发帖的人几乎都是这些 AI 工具的超级用户，他们使用 Skills 和 AGENTS.md。
MCP。
是的，所有这些。但当我和一些公司里实际使用这些工具的员工交谈时，他们尝试做的往往是最基础的事情，对这项技术的工作方式也几乎不了解。这是我的一个重大观察：他们提出的问题非常简单，还没有真正把技术推到极限。这也引出了我认为更多公司应该做的事情，以及更理想的 AI 部署方式。这也是我们在 OpenAI 内部运行的方式。（00:40:02）：我认为开始运转良好的公司，都同时具备自上而下的支持。比如高管层说：“我们要成为 AI 优先公司。”他们购买工具，得到高管支持；但同时也有自下而上的采用和认同。（00:40:18）：也就是说，真正做具体工作、对技术感到兴奋、愿意学习、推广、建立最佳实践并在组织内分享知识的员工参与其中。我们内部很明显：OpenAI 一直希望成为 AI 中心型公司，但真正开始起飞是在 Codex 和这些工具出现后，员工可以开始把它们应用到自己的工作中。（00:40:48）：我认为这是必需的，因为每个人的工作都很不一样，非常独特。软件工程不同于财务，财务不同于运营，运营不同于市场进入和销售。工作中最后一公里的细节必须自下而上完成。（00:41:07）：我的感觉是，很多 AI 部署没有自下而上的采用。它们只是高管命令，极度自上而下，和实际工作脱节。结果就是，一大群不理解技术的员工知道“我应该使用它，绩效评估可能也会看这个”，但不知道该做什么。他们环顾四周，发现没有其他人在做，也没有人可学。（00:41:32）：所以我的建议是，找到，甚至可以在内部配置一个全职团队，作为这样的内部突击队，探索技术能力的全部范围，把它应用到具体工作流，分享知识，为可能想使用技术的人创造兴奋感。没有这支队伍，真正学会使用它会很难。
你会把哪些人放进这支突击队？根据你的经验，它由工程师带头，还是跨职能团队？
有趣的是，很多公司没有软件工程师。我看到的模式是，这些人通常和软件工程相邻，是技术人员，但不是软件工程师。我认为他们最容易对这件事感到兴奋。（00:42:22）：比如不会写代码、但喜欢使用工具的支持团队运营负责人，或者 Excel 高手。这些人技术相邻、编程相邻，而且通常相当懂技术。我在这些公司看到的就是这类人，他们会真正被点燃、产生兴奋感。你通常可以围绕他们组建团队。（00:42:46）：但他们经常不是软件工程师。软件工程师可能理解这项技术，但并不是每家公司都有工程师。工程师其实很少见，也很难找、很昂贵。所以应该寻找其他类型的人。
我听到的是，反模式就是纯粹自上而下：CEO 和高管团队说“我们要成为 AI 优先公司，要投入 AI，所有人的绩效都要根据使用 AI 工具以及 AI 带来的生产力提升来评估”。但如果只有自上而下，没有建立一支自下而上布道、传播的团队，你发现这种方式行不通。
对，完全正确。
建议是找到最兴奋的人，不要把他们分散到整个组织里，而是建立一个小型 AI 布道团队，寻找使用方式，再把这些方式传播到工作中。
对。换一种说法，结合我自己的管理理念，就是找到 AI 采用方面的高绩效者并赋予他们力量。让他们组织黑客松、举办研讨会、分享知识，在内部播下兴奋的种子。
太棒了。我想听你谈几个热门观点。我看到你分享过一个：在 AI 领域，和客户交流、倾听客户并不总是正确策略，而且经常会把你带偏。
我不知道这算不算很热门的观点。重点是，你当然应该和客户交流，仍然应该听客户的。我只是认为，尤其根据我过去三年做 API、观察整个领域演化的经历，这个领域和模型本身变化得太快了，它们往往会自我颠覆，尤其是工具和脚手架领域。我本周早些时候读到一篇 X 文章，作者是 Fintool 创始人 Nicolas，他分享了在自己的金融服务 AI 代理初创公司里学到的一些最佳实践。（00:44:58）：其中一句话我觉得说得很好：“模型会把你的脚手架当早餐吃掉。”回到 2022 年 ChatGPT 刚发布时，模型还很原始，尤其在开发者领域，人们构建了各种产品脚手架来引导模型，让它做你想做的事，包括代理框架、向量库和许多其他工具。（00:45:30）：随着领域发展，模型变化很大、变得更好，最后真的吞掉了部分脚手架。我认为今天也是如此。Nicolas 文章里说，当前流行的脚手架是 Skills 和基于文件的上下文管理。我可以想象某个时候这也会变得没用，模型自己管理这一切，或者转向一种新的范式，不再需要这种基于文件的 Skills。当前的代理框架已经没那么有用。2023 年我们曾认为向量库会是把组织上下文引入模型的主要方式：把全部语料向量化、嵌入，做向量搜索，优化在正确时间填入正确信息。（00:46:29）：这一切都是因为模型还不够好，所以才需要脚手架。事实证明，随着模型变好，更好的方式是移除很多逻辑，信任模型，只给它搜索工具。它不必是向量库，可以是任何搜索，甚至是文件系统里的 Skills 和 AGENTS.md，用来引导模型。当然向量库仍有位置，很多公司仍在使用，但围绕它构建完整生态、假设它是唯一需要的脚手架，这种想法已经改变。（00:47:05）：这也解释了为什么不必总是听客户。由于领域变化太快，很多人处在局部最优。如果你盲目听客户，他们会说：“我想要更好的向量库，更好的代理框架。”如果只追这条路，你会构建出局部最优。模型变好后，我们不得不重新发明并重新思考围绕模型构建的正确抽象、工具和框架。酷、令人兴奋、又有点烦人的地方是，它是一个移动的靶子。所以现在这批工具和框架很可能会随着模型变聪明、变强而大幅演变。构建这个领域就是如此。和客户交流时，你需要在他们当前想要的反馈，与模型将要走向哪里、未来一两年的趋势之间取得平衡。
有趣的是，这和 AI、机器学习领域学到的“苦涩教训”很像：越不过度复杂化，给机器学习和 AI 添加的逻辑越少，它就越容易扩展和增长。把一切都移除，让它自己计算，给它更多能力，让它自己变得更聪明。
确实有一种适用于 AI 构建的“苦涩教训”：我们试图围绕模型设计所有东西，结果模型会把它们都吞掉。OpenAI API 团队也犯过这种错误，我们有时在不该左右转弯时转了弯。但模型最终仍会变好，我们每天都在学习这条苦涩教训。
对于在 API 上构建产品，或现在必须围绕模型构建一些东西的人，关键结论是什么？你的建议是什么？
我的总体建议是：要为模型将要发展的方向构建，而不是为它们今天的状态构建。这显然是一个不断移动的靶子。我见过很多真正做得很好的初创公司，它们会为模型理想中的能力构建产品，而这种能力今天可能已经达到 80%。它们最终拥有一个基本能运行、却还差一点的产品。（00:49:39）：但随着模型变好，它可能突然奏效，产品也会变得惊人。也许使用 o3 时还不行，到了 5.1、5.2 就突然被解锁了；关键是他们一直把模型能力的提升考虑在内。这样得到的体验会远好于一开始假定模型能力静态不变。你的产品可能需要等一等，但模型提升得非常快，通常不必等太久。
沿着这个方向，未来 6 到 12 个月 API、平台和模型会走向哪里？在能分享的范围内，有什么让你兴奋、或你认为人们应该开始准备的事情？
最明显的一点是模型能够连贯完成的任务时长。METR 基准测试软件工程任务，追踪模型 50% 或 80% 的成功率能完成多长的任务。我认为前沿模型目前大约能在 50% 的情况下完成数小时的软件工程任务，80% 的成功率则接近一小时。（00:51:06）：令人警醒的是图表里还列出所有过去的模型，可以清楚看到趋势。我非常期待这一点。今天的产品基本优化的是模型能连续几分钟完成的任务。甚至 Codex 和编码工具也很偏交互式，最多大约针对 10 分钟任务进行了优化。我见过有人把 Codex 推到极限，完成数小时任务，但那仍是例外。如果沿着趋势走，未来 12 到 18 个月，模型可能非常连贯地完成数小时任务，最终可能达到 6 小时甚至一天的任务：你派发任务后，它可以独立运行一段时间。（00:52:15）：围绕这种能力构建的产品会很不一样。你仍想给模型反馈，显然不想让它整整一天完全失控。可做的事情范围会大幅扩展，这是我非常期待的。（00:52:15）：未来 12 到 18 个月，另一个令人兴奋的方向是多模态模型，尤其是音频。模型现在已经很擅长处理音频，未来 6 到 12 个月会更好，尤其是原生多模态、语音到语音的模型。音频多模态也有新的模型和架构研究。（00:52:48）：尤其在企业和商业环境中，音频仍是被严重低估的领域。人们都谈编码，都是文本，但我们正在用音频交谈，世界上很多商业活动、服务和运营都通过说话和音频完成。未来 12 到 18 个月，这个领域会非常令人兴奋，音频模型会解锁更多能力。
简单总结：预计代理和 AI 工具会运行更长时间，这条趋势会继续；音频和语音会变得更重要，更原生、更好，也更核心地融入体验。
对。
非常酷。回到你的另一个热门观点：你非常看好业务流程自动化，认为这是 AI 世界里的机会。谈谈这个。
这回到我之前说的：硅谷生活在泡沫里，我们熟悉的软件工程、产品管理和产品构建，与支撑整个经济运行的工作形态非常不同。我每天和客户交谈都能看到这一点。只要和任何一家非科技公司的企业谈谈，就会发现大量业务流程。（00:54:18）：软件工程更像开放式知识工作，这也是 Codex 工具效果好的原因：它探索开放式问题。但软件工程本质上开放性很强、可重复性不高。你构建一个功能，不是为了反复构建完全相同的功能。（00:54:42）：很多科技岗位都属于这个空间，数据科学、部分战略财务工作也类似。但离软件工程和科技核心越远，很多工作就越是业务流程：可重复的操作，由公司经理逐步迭代，通常有标准操作程序，大家希望遵循而不偏离太多。软件工程的创造力在于偏离流程，但世界上很多工作其实是在执行流程和操作。打客服电话、打给公用事业公司，都是在运行这些流程。（00:55:35）：我非常看好这类业务流程自动化机会，因为它和硅谷的思考方式差别很大而被低估。如何把 AI、工具和框架应用于自动化业务流程，让可重复的流程更容易完成，保证高确定性，并与企业数据、业务决策和企业内部系统完整集成？这个领域有很多机会和工作要做，只是我们不在自己的舒适区，所以很少谈。
所以你的观点是，工程之外的 AI 机会要大得多，可以影响公司生产力和那些执行重复、容易自动化任务的人的工作？
既会影响工作，也会影响工作的完成方式。大量工作都是这样完成的。我经常和大型企业客户交流，他们问：“AI 会如何改变公司？20 年后在 AI 世界里如何运行？”软件工程只是故事的一部分，业务流程方面还有更多内容，而且变化可能更大，工作量也非常可观。（00:57:04）：我不知道按绝对比例或绝对规模，它是否比软件工程更大，因为软件本身也非常庞大、成本很高。但它确实很大，肯定比人们在 X 或 Twitter 上谈论或不谈论它时想象的更大。
换个方向。既然你构建了平台和 API，很多人基于 API 构建产品，大家最担心的是：如何避免 OpenAI 把我的想法压过去，自己构建同样的产品，摧毁我创造的市场？初创公司应该如何思考 OpenAI 不太可能进入的方向？
我的总体回答是，市场太大了。初创公司不应过度思考 OpenAI 或其他实验室会去哪里。我见过很多失败和成功的初创公司。失败的通常不是因为 OpenAI、大型实验室或 Google 来压垮它们，而是因为它们构建的东西没有真正引起客户共鸣。相反，即使在编码这样竞争激烈的领域，Cursor 也发展得很大，是因为它构建了人们非常喜欢的产品。所以我的建议是不要过度焦虑，只要构建人们喜欢的东西，就会有自己的空间。（00:58:35）：我无法夸大当下 AI 构建机会有多大。这个机会空间大到，VC 可以投资竞争公司这种过去不可接受的做法都已改变。对于初创公司来说，这是最令人赋能的事情：即使只是构建出少数人非常喜欢的东西，也会得到极高价值的企业。（00:58:59）：从 OpenAI 的角度，我们一直把自己看作生态系统平台公司，API 是第一个产品。我们认为培育生态、继续支持它，而不是压垮它，非常重要。每个发布在我们产品中的模型都会进入 API；即使 Codex 模型更适配 Codex harness，也会进入 API，客户都能使用。我们不保留这些能力，努力保持平台中立，不阻止竞争者，让大家可以使用模型。我们也在测试用 ChatGPT 登录的产品，希望培育这个生态。水涨船高，所有人都会受益，我们也会受益。我们的 API 正因为这样做而大幅增长。所以不要把 OpenAI 看作会把别人推开的力量，专注于构建有价值的产品，我们仍致力于开放生态。
这对 OpenAI 为什么重要？专注于构建平台、让人们能建立企业，是从一开始就有的愿景吗？
这是从一开始就有的愿景，也和我们的章程、使命有关。OpenAI 的使命一是构建 AGI，我们显然正在做；二是把它的利益传播给全人类，重点是“全人类”。ChatGPT 正在努力触达全世界。但我们很早就意识到，公司不可能自己触达全人类，世界的每个角落都很深。因此，要实现使命，我们需要一个平台，让其他人构建播客和 newsletter 主持人的客户支持机器人，因为我们自己不可能完成所有事情。（01:01:58）：API 让这个使命真正实现。我们经常与客户交流，也很喜欢看到 API 上构建出的多样产品。这从第一天就是使命的表达。
你还没提到你们正在推出的 ChatGPT 应用商店。
对。
顺便问一下，那属于你们的范围吗，还是另一个组织和团队？
这是另一个团队，隶属于 ChatGPT。我们当然与他们密切合作，他们构建了 Apps SDK，也是与我们团队密切合作开发的。但它更属于 ChatGPT 体系。这是另一个例子：ChatGPT 每周有 8 亿活跃用户，用户不断回来使用。作为企业资产非常棒，但如果能让其他公司也利用它、为这个受众构建产品，不是会更好吗？最终这也能帮助我们扩大用户群。这一切都回到使命上，而成为平台、保持开放往往有帮助。
就这个数字，8 亿，我以为是月活之类的——
不，不，是每周，每周活跃用户。
每周活跃。
对，很疯狂。
每周差不多有 10 亿人使用。我们已经习惯这些数字了，但这太荒谬、太史无前例了。
从规模角度看，我老实说觉得这难以想象。我的理解是，全世界有 10% 的人，而且还在增长，每周来到 ChatGPT 并使用它。
我想强调你说的这一点。OpenAI 的使命是让全人类都能获得 AI。有些人会嘲讽，说“它要花钱”。但 ChatGPT 有任何人都能使用的免费版本，它和世界上最强大的 AI 模型并没有很大差别，而且免费、没有门槛。即便你是亿万富翁，从 AI 中获得的额外价值，也没有比非洲村庄中的人多多少。我知道这对 OpenAI 一直很重要。
这也是我们投入健康领域的原因，教育也会非常有意思。另一个疯狂的趋势是，免费模型随着时间变得非常聪明。2022 年的免费模型在当时已经很好，但和今天能用到 GPT-5 的免费模型相比根本不值一提。提高全世界的能力下限是我们努力做的事情，也是使命的一部分。（01:04:42）：反过来说，关于亿万富翁，人们喜欢说你用的是和 Mark Zuckerberg 一样的 iPhone，或者亿万富翁使用的设备。但每月 20 美元，你基本就能使用和亿万富翁一样的 AI；每月 200 美元，你能使用他们使用的同一款专业模型，而他们可能也不会所有事情都用 Pro，日常可能只用 Plus。因此，让这项技术民主化、把它的利益传播到全世界，对我们很有意义，也驱动着很多工作。
最后一个问题。对于想基于 API 构建产品、刚发现可以用 OpenAI 模型和 API 做酷东西的人，你们的 API 和平台允许人们做什么？我知道可以在平台上构建代理，具体说说你们提供的能力。
从根本上说，API 提供许多开发者端点，让开发者调用我们的模型。现在最受欢迎的是 Responses API。这是一个针对构建长时间运行代理优化的端点。低层次上，你给模型文本，模型运行一段时间，你可以轮询查看它会做什么，之后得到模型响应。这是我们提供的最低层原语，也是很多人基于 API 构建产品的方式。它非常不带偏见，你几乎可以做任何事。（01:06:24）：我们也逐渐在上面构建更高层抽象，帮助人们构建代理。下一层是 Agents SDK，也非常受欢迎。它让你使用 Responses API 或其他端点，构建传统意义上的代理，也就是像在无限循环中工作的 AI。它可以委托给子代理，构建框架和脚手架。我们还在观察未来会怎样，但它让构建代理更容易，包括提供护栏、把子任务分给其他代理，以及编排代理群。（01:07:08）：再上面，我们开始构建部署代理所需的元层工具。AgentKit 和 widgets 是一组 UI 组件，可以很容易地在 API 或 Agents SDK 上构建漂亮的界面，因为不同代理的 UI 通常很相似。我们还有一批评估产品，比如 evals API，用来定量测试代理或工作流是否有效。（01:07:50）：所以我把它看成不同层次：它们都帮助你用我们的 AI 和模型构建想要的东西，只是抽象程度、约束程度逐渐提高。你可以使用整套技术栈，快速构建代理；也可以沿着技术栈往下走，只使用低层的 Responses API，构建任何东西。
Sherwin，还有什么想分享的吗？在进入闪电问答前，有没有任何遗漏或对听众有帮助的内容？
我想留下的是：未来两三年可能会是科技和初创公司很长时间以来最有趣的阶段。我希望大家不要把它当作理所当然。我 2014 年进入职场，前几年不错，之后科技行业有五六年并不令人兴奋。过去三年是我职业生涯中最令人兴奋、最有活力的时期，我认为未来两三年会延续这种状态。（01:09:01）：所以不要把它当作理所当然，我也在努力这样做。某个时候这波浪潮会走完，变化会更渐进；但在那之前，我们会探索很多酷的东西，发明新东西，改变世界和工作方式。这就是我最想留下的话。
我喜欢这个信息，还想多谈一点。你说不要错过它，建议人们做什么？构建、投入、学习、加入一家正在做有趣事情的公司？对于不想错过这趟车的人，你有什么建议？
参与其中。就像你说的，投入进去。构建这类工具是其中一部分，但只使用工具也可以，你不必是软件工程师。很多工作会发生变化，所以使用工具，理解它能做什么、不能做什么，这样随着模型改进，你就能观察它开始能做什么。关键是熟悉这项技术，而不是躺着让它从身边经过。
另一方面，很多人有压力和焦虑：“事情太多了，我怎么跟上？这周得学 Clawdbot，天啊。”你身处中心，如何避免过度压力、担心错过，保持了解新闻？你做过、学到过什么？
我个人可能是个坏例子，因为我长期在线于 X 和公司 Slack，确实会吸收很多信息。但观察那些不像我这么上瘾的人，我想说，大量内容其实是噪音。你不需要让 110% 的信息都进入大脑。坦率说，只专注一两个工具、从小处开始，已经远超所需。（01:11:02）：行业节奏极快，X 又制造了疯狂的新闻速度，这确实令人不堪重负。关键是，你不需要知道全部信息才能参与当下。哪怕只是安装 Codex、Cline，玩一玩；安装 ChatGPT，连接 Notion、Slack、GitHub 等内部数据源，看看它能做什么、不能做什么，这些都是参与的一部分。
太棒了。Sherwin，现在到了闪电问答。我有五个问题，准备好了吗？
准备好了，当然。
第一个问题：你最常推荐给别人的两三本书是什么？
我说一本非虚构和一本虚构。虚构作品是我刚读完的《There Is No Antimemetics Division》，作者是 qntm。我觉得他是网上的作者，之前在 X 上看到有人分享。这是一本科幻小说，我两天就读完了，写得非常好，非常引人入胜。它讲的是一个与会让人遗忘它的事物斗争的政府机构，是一本非常聪明、富有创意且素材新鲜的书。我推荐它。它还无意中很好笑，本来是科幻、几乎恐怖风格的书，却让我笑了几次。（01:12:43）：非虚构我作弊，推荐两本。过去一年我读了很多关于中国和中美关系的书。过去一年有两本书让我在这方面大开眼界。第一本是 Dan Wang 的《Breakneck》，非常好。我很喜欢他把美国比作律师社会、中国比作工程师社会的类比，各自有优点和缺点。我读完后想：美国确实像由律师管理。第二本是 Patrick McGee 关于苹果在中国的书，非常有趣。我是苹果超级粉丝，桌上全是苹果产品。它让我了解苹果与中国的关系，也提供了很多关于苹果公司的内部信息，读起来很有吸引力，而且非常应时。
这本反模因小说听起来太棒了，我现在就买。
对，只有几百页。我真的两天就读完了。
太完美了，理想状态。
真的非常好。
好建议。你最近特别喜欢哪部电影或电视节目？
这个问题难答，因为我有两个孩子，工作也很忙，没时间看太多。我最近几周看了几集。我是动漫迷，看了新一季《咒术回战》，第三季 JJK 很棒。总的来说，我非常喜欢日本动漫。我认为它们创造了西方媒体回避的、最新颖独特的情节和宇宙。所以我很喜欢。不过最近确实没看很多，只看了几集 JJK。
以你的工作状态来说完全可以理解。
对。
最近发现、非常喜欢的产品是什么？
我最近需要设置 Wi-Fi 和家庭网络，于是全面采用了 Ubiquiti 路由器和安全摄像头。在那之前从没听说过它。我过去一直用非常简单的网络配置。它是一款构建得极好的产品，有点像家庭网络领域的 Apple：产品漂亮，但真正让它出色的是软件也很好。它有很好的移动应用，帮助管理家庭网络。（01:15:19）：Ubiquiti 可以用来购买无线路由器，但你需要在家里布置以太网线路。我认为它最棒的是安全摄像头。如果摄像头接入 Ubiquiti 生态，它有出色的移动、Apple TV 和 iPad 应用，可以查看摄像头实时画面。价格有点高但不算离谱，产品体验非常棒。
好吧，我选了 eero，所以我选错了。
eero 也不错，不过——
它不是 Ubiquiti。
我现在已经完全改用 Ubiquiti 了。
好建议。再问两个问题：你有没有一个在工作或生活中经常想起的人生格言？
我总对自己重复的一句话是：永远不要自怜。工作和生活中会发生很多事，提醒自己不要自怜、始终拥有把自己拉起来的能动性，是我必须经常告诉自己的，也会对很多人重复。
最后一个问题。你过去在 Opendoor 工作，负责判断房屋应该支付多少钱，建立了一个模型告诉公司每套房该付多少。房价中有没有一个你没想到却非常重要、会影响价格的变量？
有很多出乎意料的。我列两个最有意思的。电线、特别是高压电线，影响价格很大。我去达拉斯观察之前没有完全意识到这一点：房子靠近巨大的高压线时会发出嗡嗡声，而大多数人有家庭，不想让孩子靠近，所以这让我很惊讶。
这很合理。
另一个一直很难量化的是户型，所以它非常重要。我们会研究厨房多宽、是什么风格、主卧在哪里，但很难定义什么是好户型、什么是坏户型。有些房子卖不出去，运营团队进去就说是户型问题。你问怎么知道？走进去凭感觉，户型就是不对。（01:17:50）：另一个比我预想更有影响的因素是整体临街观感，甚至是前门。我记得有一本 Zillow 的书提到，前门的位置往往是房屋投资回报最高的地方。买家走近房子时看到的感觉、互动和最初几秒，我过去低估了它的重要性。
这太有意思了，而且你必须把这些都编码出来，而不是走进房子观察。
户型还有很多故事。它没有数字化，Phoenix 和 Dallas 的房子中，有人保存着纸质户型图。Opendoor 那段时期有很多有趣故事。
Sherwin，非常感谢你参与。大家在哪里可以找到你，听众如何帮助你？
我在 Twitter，也就是 X 上，账号是 @SherwinWu。我主要发 OpenAI、API 和我们发布的产品。如果你正在构建初创公司或尝试一个想法，我很喜欢听大家在做什么。请在 X 联系我，我想了解你的构建内容，也想知道 OpenAI 如何支持你。
太棒了。Sherwin，非常感谢你来到这里。
谢谢你，Lenny。
大家再见。（01:19:16）：非常感谢收听。如果你觉得本期有价值，可以在 Apple Podcasts、Spotify 或喜欢的播客应用订阅节目。也请考虑评分或留下评论，这会帮助其他听众找到节目。你可以在 lennyspodcast.com 找到所有往期节目和更多信息。下期再见。