关于“AI是否会取代程序员”的争论仍在继续。但在OpenAI内部，答案似乎已经浮现：AI正在重塑工程师这个职业本身，并将从业者重新分层。
很多人还在争论“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 从向量库到 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 就突然可用了——他们之所以能吃到这波红利，是因为在产品设计时就把“模型必然会变强”当成前提写进了路线图。最终你会得到一种体验：它远远好过那种把模型能力当成静态、围着现状去打补丁的做法。
所以我的建议很简单：按模型未来的走向来设计。你可能需要稍微等一等，但模型变强的速度太快了，很多时候你并不需要等太久。
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 结语：拥抱变化，但别被噪音淹没
主持人： Sherwin，在我们结束之前，你还有什么想补充的吗？有什么你想留给听众的？有没有我们还没聊到、但你觉得很有帮助的点？
Sherwin Wu： 我只想留一个信息：我觉得接下来两到三年，会是科技圈和创业圈在很长一段时间里最有趣的一段时间。
我鼓励大家不要把它当成理所当然。我 2014 年进入职场，头两年挺不错，但接下来大概五六年，我觉得科技圈没那么“兴奋”。而过去三年，是我职业生涯里最让人兴奋、最有能量的阶段。
我觉得未来两到三年还会延续这种状态。
所以别把它当成理所当然。总有一天这波浪潮会走完，变化会变得更增量、没那么剧烈。
但在这段时间里，我们会探索很多很酷的东西，发明很多新东西，改变世界，也改变我们工作的方式。这就是我想留给大家的。
主持人： 我太喜欢这段话了，我想多问一句。你说“别错过”，那你具体建议大家做什么？是去 build、去拥抱、去学习、去加入一家做有趣事情的公司？你给那些想说“我不想错过这班车”的人什么建议？
Sherwin Wu： 我会说：去参与它（engage with it）。
基本就是你说的：去拥抱它。在这之上构建工具，是故事的一部分。但就算你不是软件工程师，你也完全可以拥抱它：去用这些工具。
我觉得很多工作都会被改变。所以你应该去用工具、理解它能做什么、不能做什么，理解它的限制，这样你才能看得见它随着模型进步会开始能做什么。
总之就是：让自己熟悉这项技术，而不是后仰着让它从你身边过去。
主持人： 但反过来，也有很多压力和焦虑：事情太多了，我怎么跟得上？我这周要学 Clawbot，下周又冒出别的……你在中心位置，你怎么不被这种“错过恐惧”压垮？你怎么保持节奏、怎么跟新闻？
Sherwin Wu： 我个人其实是个坏例子，因为我基本属于“长期在线”：X 上长期在线，公司 Slack 也长期在线，所以我确实会吸收很多信息。但我观察那些不像我这么“上瘾”的人，我觉得有一点很重要：大多数信息其实是噪音。
你不需要让 110% 的东西都穿过你的大脑。说实话，你只要选一两个工具，先从小处开始，就已经完全够了。
行业节奏太快，再加上 X 这个产品本身的机制，会制造一种极其疯狂的新闻节奏，让人非常压迫、非常容易被淹没。
但你真的不需要掌握所有这些，才能参与到当下正在发生的事情里。
哪怕只是装一下 Codex 客户端玩一玩；装一下 ChatGPT，接上你的一两个内部数据源——Notion、Slack、GitHub——看看它能做什么、不能做什么，我觉得就已经很有价值了。
从 OpenAI 内部的一线观察来看，AI 对工程生产力的重塑不是未来时，而是现在进行时。工具本身在快速进化，使用工具的最佳实践也在被重新定义。与其焦虑被替代，不如像 Sherwin 建议的那样，积极“参与它”——选择一个切入点，亲手实践，理解其边界与潜力。在这个过程中，与 云栈社区 这样的技术社区同行、交流，或许能帮助你更清晰地定位自己在这场变革中的新角色。
发表于 4 天前
|
查看: 17|
回复: 0
