AI 已能写 80% 代码，但 Agent 也有致命短板！OpenAI Codex 技术总监：问错了，比不会写更麻烦

OpenAI Codex 技术负责人 Michael Bolin 就是典型的后者。从 Google Calendar 到 Facebook 的 Buck 构建系统、再到虚拟文件系统 Eden，以及如今 OpenAI 的 Codex，这位工程师的职业轨迹，几乎贯穿了过去十多年软件工程基础设施的关键演进。

在最近一期 The Developing Dev 播客中，主持人 Ryan 与 Michael Bolin 展开了一场横跨 20 年工程实践的深度对话。在这次访谈中，他回顾了自己从“写 JavaScript 的工程师”到主导开发工具体系的转变过程，也坦诚讲述了其中的判断失误、能力边界与成长代价。更重要的是，他试图回答一个当下所有工程师都在面对的问题：在 AI 正在重塑开发方式的时代，哪些能力依然值得坚持，哪些又必须被重新理解。

在他看来，真正拉开差距的，从来不是写代码的速度，而是你选择解决什么问题，以及你如何定义“更好的系统”。

其中几个值得关注的关键观点包括：

• 很多工程突破，源于对“现状的不满”和快速动手验证
• 工程师的影响力，最终取决于是否解决“公司真正关心的问题”
• AI 编程时代，80%-90% 的代码已可由模型生成，但关键部分仍需人类把控
• 相比写代码，提出正确问题的能力正在变得更重要
• 长期来看，编程智能体的执行将更多迁移到云端，而非本地
• AI 看似什么都会，但理解系统更底层怎么工作的能力现阶段仍然重要

以下是本次访谈全部内容的翻译，InfoQ 在不改变原意的前提下进行了整理编辑。

Ryan： 我深入研究了一下你的网站，发现几乎所有内容都有很多可挖掘的信息。其中有个项目当初倾注了你的很多心血，但现在所有链接都失效了，我已经完全找不到相关资料。所以，Chickenfoot 究竟是什么？

Michael：天内，这事说来话长了。那是我的硕士毕业设计项目，是个 Firefox 扩展项目，也是当时极少数基于 JavaScript 为 Firefox 开发的毕业设计。它其实是个嵌在 Firefox 侧边栏上的小型编程工具，类似于实时解释器，由终端用户随时调用，核心理念就是实现 Web 编程。

这里头包含着“enter”、“click”等函数。在调用相应函数后，用户需要传递字符串参数，再由它自动定位输入框；比如输入“click search”，即可执行点击操作。这个项目的主要工作量是构建底层启发式算法：在输入“enter first name”时，它会识别“first name”中的关键词，定位最近的文本框，再通过 JS 将其转为输入内容。

现在回想起来还是挺有意思。我们当时做的很多工作，跟当前 AI 编程助手的原理其实很相似——只不过现在真正实现了自然语言处理，而不用再依靠当初的 JS 替代方案了。

Ryan： 有意思。所以它的作用就是解析前端界面，通过交互界面将用户下达的指令描述转化为相应操作。

Michael：没错，我们会使用无障碍标签和切换等技术把文本转为功能，而且这套方案在 Craigslist 上效果特别好——毕竟那也是最简单的网站之一。而且我有个朋友真就用这款工具自动处理任务，甚至靠这种效率优势赚到了真金白银，确实非常有趣。

Ryan： 你刚刚进入行业时就加入了谷歌，并带着巨大的热情参与到谷歌日历项目当中。是什么吸引你加入了谷歌？那段经历给你留下了什么回忆？

Michael：我是在九十年代那会接触互联网的。记得当初浏览网页时，经常得在一大堆搜索引擎之间来回切换，才能找到自己需要的信息。我现在还清楚记得，2000 年 3 月室友告诉我：“嘿，有款新搜索引擎看着不错哦。”它当时还挂在斯坦福大学的域名下。

我当时就发现谷歌搜索确实更胜一筹。而在仔细研究之后，我发现它跟其他搜索引擎的界面简直天壤之别——雅虎界面杂乱不堪，而谷歌当时就刻意追求极简设计，明显原则层面的针对性更强。后来大家也就都知道了，许多公司都开始效仿这种风格。接着我身边开始有人去谷歌工作，我心想：可以啊，他们招聘的都是一帮顶尖人才。

我真的很希望能跟那些人共事，他们确实非常非常了解 Web。相比之下，当时的微软就根本不够了解，并且宣布叫停 IE 项目。我当时觉得这可是通往 Web 的门户，微软却打算拆掉它。而谷歌显然更具 Web 前瞻性，再加上项目的工程质量和由此带来的巨大影响，最终让谷歌成为我毕业时最向往的去处。

Ryan： 当时谷歌的文化氛围怎么样？记得你在文章里提到过，谷歌在产品和基础设施两条业务线之间也存在分歧。

Michael：很多公司，尤其是发展到一定规模之后，都会有一个很明显的倾向：创始团队最早擅长、也最成功的那一块业务，往往会被长期“偏爱”。

在谷歌，这一点也很典型。无论是信息检索，还是底层基础设施，都是支撑公司成长的核心能力，也自然在内部拥有更高的地位。

而我当初之所以被谷歌吸引，很大程度上是因为他们推出了像 Gmail 这样的产品。这些产品当时看起来更偏“面向用户体验”，方向也相对开放、有想象空间。但在公司内部，它们的地位其实始终无法与搜索这样的核心业务相比。

比如我当时参与的 Google Calendar，主要还是面向消费级市场，虽然同时也有一定的企业销售场景。但从业务角度看，它并不是公司的营收核心。某种程度上，我们更像是在做一个“服务支持型”的产品团队，而不是直接创造收入的那一类业务。在当时，大致就是这样一种情况。

Ryan： 你最终还是离开了谷歌。从发过的帖子来看，在谷歌供职的时光也是段苦乐参半的经历。那是什么促使你选择离开的？

Michael：我在谷歌前后工作了四年。说实话，让我选择离开的关键因素应该就是个人规划。首先，工作四年之后我手里有闲钱了，可以考虑的选择更多。更重要的是，当时我发现自己有个坏习惯：总喜欢在那些对我个人很重要、但对谷歌未必重要的项目上倾注全部精力。比如我负责的日历项目就属于这种情况。

后来我又转去做效率工具 Google Tasks，属于日历下的一个小小功能模块。用户量相较日历一下子小了两个量级，但我还是对此充满热情。同样让我着迷的还有 JS 基础设施和 Closure 工具套件。这些项目当然也很精彩，我也享受开发的过程并为自己的付出而感到自豪——我甚至还专门为 Closure 写了本书，可以说是干劲十足。但从职业发展的角度看，这确实不是最明智的选择，对吧？

我当时就想，我明明也在处理高质量的工程问题，但获得认可的怎么永远是别人？我这么拼命到底有什么意思？可能真的是选择永远大于努力吧，所以我意识到或许该换条路径去尝试，要么专心搞自己热衷的事业、要么投身于公司最看重的方向。

Ryan： 后来你又回归科技大厂，加入了当时的 Facebook。我了解到当时你已经是 JS 领域的专家，而在 Meta 的首个重大项目就是为 Android 代码库构建工具链。能不能讲讲你参与这个项目的幕后故事？

Michael：当时公司内部有一个非常明确的方向：Facebook 要做手机。

虽然此前已经有过一些失败的尝试，但这一次的氛围明显不同，大家普遍觉得“这次是真的要做成”。公司的计划是与 HTC 合作，对 Android 进行定制化改造，在此基础上做一些新的尝试。

对刚加入公司的我来说，这件事非常令人兴奋。我之前做过不少 Java 相关的工作——虽然整体更偏 JavaScript，但这个项目也让我有机会更多接触 Java。

当时公司内部还有一个叫“Face Web”的方向，本质上是希望把 HTML5 和 Facebook 的 Web 体验直接搬到手机上。但很快大家就发现，这条路行不通。与此同时，有一点变得越来越清晰：移动端将成为决定公司成败的关键战场。

也正是在这个时候，有个朋友跟我说：“我知道你特别喜欢 JS，但现在最好多拿点精力钻研钻研 Java 或者 Objective-C，否则就往产品经理转。”现在回头看，这确实是一个非常重要、也非常及时的建议。

我当时想：我实在不喜欢 Objective-C，还是 Java 好。就这样，我加入了项目。当时我们的时间非常紧迫，因为跟其他绝大多数项目不一样，这次是有硬性截止日期的。而其他项目正常完成后就能发布，这个则需要按时把成果提交给 HTC，以保证给他们留够时间在 3 月 1 日左右把代码烧录到手机里。

所以整个过程就是一场狂奔，而初始 Android 代码库其实就是从谷歌雇用的外包商那直接拿过来的。大厂其实都差不多，Facebook 也不想亲自开发原生应用，所以就付钱找人代工。结果应用上线后，对方甩手不管了，把代码直接一塞。其实谷歌本该把之前那堆破玩意直接丢了，但却一直留在手里——我们收到的就是这么堆玩意，而对迭代速度的要求还相当高。

相信做过长期 Web 开发工作的朋友们早就习惯了先编辑再刷新的操作流程。但 Android 的构建系统就……特别粗糙。那些 Ant 之类的构建工具根本就没法模块化，只能想办法把它们硬生生拆分成四、五个模块。

每次开发都痛苦不堪。我当时就想：必须重组这套构建系统。我也用 Java 干过不少活，人家不至于这么慢，不至于在迭代构建的时候这么卡顿。Facebook 有黑客松文化，所以我决定组织一轮黑客松，直接搞套新的构建系统。就照着谷歌构建系统的风格，争取干脆利落搞定。

其实那时候公司里还有套叫 FB Build 的构建系统，本身也是谷歌构建系统的一种“山寨版”。它是用 Python 写的，只支持 C 语言；但当时我就想，要么把这东西修好，要么躺平摆烂……或者直接辞职算了。毕竟修旧项目最烦了。

Ryan： 要是没修好，你会辞职吗？

Michael：至少会申请换个项目，或者找到让自己快乐的方式，这样才能每天开心来上班。我来上班就是想写代码、把事情做好，尽可能把自己的能力发挥出来。

说来也挺有意思的。后来回想起来，我还是挺佩服当时周围那些人的——几乎所有人都告诉我，我正在做的这件事是个很糟糕的主意。基本上所有人都不看好，除了一个人。

当时我担任的是资深 Android 工程师，没有人真正阻止我。大家会表达反对，但不会直接说“不行”。这一点和我在谷歌时的感受不太一样——在谷歌，很多事情是会被明确否决的。

所以我就顺着这个方向继续做下去了。很快，我们就做出了一个明显更好的版本——性能大概提升了一倍左右。结果一出来，大家的态度也随之转变了。很多人开始意识到：“好吧，这个方向确实更好，那我们就按这个来吧。”

Ryan： 我发现大厂有种惯性，就是没人想去碰那些堆积如山的不利因素。其他很多工程师都注意到了同样的问题，但只要觉得还有办法能解决，就懒得另起个新项目。况且谷歌那边还有竞争产品，这边可能根本赢不了。那是什么让你坚信自己的项目能击败对手，成为市场的优先选项？

Michael：这个主要有几点吧。首先如我所说，我也做过其他 Java 项目，所以觉得原本的构建工具不应该这么慢。或者说以软件工程师的经验来看，这种底层实现不应该如此低效。实际上大部分反对意见都基于僵化的逻辑：如果偏离标准方案，我们将失去标准支持。或者说，万一下周标准性能提升了 100 倍，新方案却没法继承，又该怎么办？

仔细想想这很可笑，毕竟 Facebook 的工程师们自己也搞过自研 PHP 虚拟机和语言，也明明曾经拥抱过创新。不知道为什么这次就例外了。我想说的是，当时整个移动端项目都在摸着石头过河，我心里充满了焦虑、还有严苛的时间压力。

高层人员似乎要把这个项目当作科学实验来搞，但问题是我们面临着硬性截止期限。但这样真能最大程度利用好我们的时间吗？好在最终还是成功了。另外我当时还刻意淡化了项目的基础设施性质，只强调“要为 Android 打造构建系统”，可千万不敢暴露太多的业务扩张野心。

我没打算动别人的项目蛋糕，因为这种事肯定会引发更多摩擦。所以在设计时，就考虑到让它支持更多团队，而且从不强推。直到大概一年之后，iOS 团队主动过来问“我们的构建系统太烂了，能合作一起搞 Buck 吗？”我当场回应：“当然可以，来吧朋友。”

Ryan： 这点很有意思——你刚入职时缺乏公信力，毕竟新人都要经历这个过程。后面你为了推进自己的项目，就得争取更多人的支持。而所有人都说别这么干，你得说服他们，让他们相信这才是正确的方向。那你是凭什么在自己缺少信誉的条件下推动这种改变的？

Michael：我其实是取了个巧。当时我有个同事 John Perlow，他也是资深 Android 工程师而且同样是谷歌出身，他当时说“没错，你就该这么干，趁还没人反对赶紧行动。”他还提到，“要是搞定了我就支持你。”有了这样一位早期支持者加上高产程序员，我的开发周期还真就变快了。

他算是最早给予我肯定的人之一，帮了我很大的忙。但我也得承认自己当时犯过大错。你提到缺乏公信力——我刚从谷歌跳槽过来的时候，还以为这里聚集的都是贝尔实验室的精英，纯纯的顶尖人才。结果到了 Facebook 我才发现，这帮人不就是大学毕业生吗……他们懂什么技术？

但随着犯错，我逐渐对他们心生敬意。比如我在讲谷歌那边是怎么做事时，他们常讲“我们根本不在乎”——而且多数情况下，他们还真是对的。没错，在某些地方行之有效的办法，在其他地方可未必同样奏效。

Ryan： 最后还有件事想问，你们开发的工具性能比同类方案高出好几倍。这种技术直觉是怎么形成的？你做了哪些关键设计，才让它这么高效？

Michael：我觉得最关键的一点，是我当时真的坐下来，把谷歌那套工具的实现逻辑从头到尾梳理了一遍：它到底在做什么？问题出在哪里？

很快我就发现，它有一个很大的问题：只要有任何改动，它就会从头开始全部重新构建。这也是它速度慢的根本原因，尤其是在增量构建的场景下，性能非常差。

于是我开始往更底层去拆：到底哪些东西依赖哪些？哪些步骤其实是不需要重复执行的？这里面确实有一些复杂点，比如 Android 的资源处理，本身就比较特殊，逻辑也很复杂。正因为复杂，系统一开始采取了一个“简单粗暴”的策略：一旦有变化，就全部清空、重来一遍。

但当我真正深入进去之后发现，其实是可以优化的——如果某些输入没有发生变化，那对应步骤的结果完全可以缓存下来，不需要重复执行。一旦引入这种缓存机制，整体速度就明显提升了。

另外还有一个问题是模块化。当时系统基本只支持四个模块，一旦有人想新增模块，就需要写大概 200 行 XML 的 ANT 构建脚本，而且这些配置几乎没人真正理解。结果就是，没有人愿意去做模块拆分——因为一旦做了，你就得负责维护那一堆复杂配置。

而 Buck 做的一件很重要的事情，就是把“新增模块”这件事变得非常简单。于是，大家开始更愿意拆分模块，模块数量也随之增加。模块变多之后，构建就可以更细粒度地增量执行，整体效率也进一步提升。

所以从本质上来说，这不仅仅是一次技术优化，更是一种思维方式的改变。

Ryan： 说白了就是减少重复劳动。

Michael： 就是这样。

Ryan： 在解决了 Android 构建方面的问题后，你又转向了公司里的其他方向。我注意到你开始更多地参与 IDE 相关的工作。当时你在 IDE 领域看到了什么问题，促使你想深入去做这方面的事情？

Michael：在做完 Buck 之后，我短暂去做了一段时间 iOS Messenger 的开发。当时我想的是：Android 已经做过了，不如拓展一下，试试别的方向。虽然说实话，我一直都不太喜欢 iOS 开发——后来也还是没喜欢上。

很多人可能不知道，Objective-C 早期有一套机制叫 ARC（自动引用计数）。现在这些事情基本都由编译器自动处理了，但在更早的时候，开发者是需要手动管理引用计数的。比如每创建一个对象、每增加一次引用，都要自己写代码去维护。这种代码现在很多人都没见过，但当时通过收购接手的 iOS Messenger 代码非常老，还是用这种方式写的，维护起来非常痛苦。

如果是现在，也许可以用 Codex 之类的工具帮忙清理这些代码，但在当时，我们只能硬着头皮改。再加上 Xcode 本身的使用体验也让我不太适应，比如头文件和实现文件分离这种设计，我一直都不太喜欢。

另外，从更宏观的角度看，无论是 Android 还是 iOS，Facebook 的应用规模始终是最大的。我们基本是把所有功能都塞进一个 App 里统一发布。这和 Google 的策略不一样——他们会拆成 Drive、Sheets 等多个应用，而且因为他们自己掌控平台，可以在系统里预装一整套应用。

这种差异带来的结果是：Facebook 总是比其他公司更早撞上移动开发工具的规模瓶颈。

这对开发来说是很痛苦的，但从开发工具的角度看，其实也很有意思——因为我们被迫去解决一些别人还没遇到的问题，而且这些问题不是“研究项目”，而是直接影响业务的。Xcode 的问题也是类似。我们当时和 Apple 沟通过，反馈是：“Xcode 在我们这个规模下已经不太能支撑了。”但他们的回应是：“那你们的项目就不该这么大，应该拆小一点。”在这种情况下，自研工具就变得有一定合理性了。

当时我的思路也很直接：IDE 本质上在做什么？无非是和编译器（比如 Clang）以及语言服务打交道。那么我们完全可以在这之上做一层更好用的“外壳”。

而且当时公司在版本控制上也开始从 Git 转向 Mercurial，我就意识到，主流 IDE 不太可能原生支持这些定制需求。再加上我们已经在使用 Buck 作为构建系统，这些都是高度定制化的内部工具，Xcode 不可能很好地支持这些“Facebook 特有”的工作流。所以，从整体来看，投入精力去打造一套更适合我们的开发体验，是一件说得通的事情。

相比之下，我在 Android 这边就没有类似的动力，因为 IntelliJ 本身已经做得很好，而且我们也已经找到了一套可以支撑大规模开发的使用方式。但在 iOS 上，Xcode 在当时确实更难用一些。

Ryan：所以当时一方面是 Xcode 不行，不满足你们的需求；另一方面公司里其实还有另一套 IDE，是另一个团队在做的，对吧？我记得好像是一个 Web IDE？

Michael：对，是一个 Web IDE（笑）。我不是在笑这个方向本身，这个方向其实没问题。问题在于，它是基于一个已经被放弃的 Google 开源项目构建的，而且这个项目是用 GWT（Google Web Toolkit）写的——也就是你用 Java 写代码，然后自动生成 JavaScript。

我当时其实尝试过在他们的基础上继续做，也试图先建立一些“信用”，甚至还帮他们优化了一些构建速度。

但后来我又回到了一个熟悉的判断方式：看迭代速度、看技术栈本身。然后我就发现——这个项目本身是建立在一个已经被废弃的开源项目上，而且还用的是 GWT 这种技术。而与此同时，我们公司已经是 React 的发源地了。

那问题就来了：我们为什么不让开发工具构建在我们自己最擅长、也最认可的技术栈之上？

我当时的第一反应是：你们这条路其实选错了。于是我就又做了一件和之前做 Buck 很像的事——我自己起了一个新项目。不过我当时的策略是一样的：不正面冲突，不试图“接管一切”。我只是说： “我在这边做一个新的编辑器，但我们只先聚焦 iOS 场景。”

Ryan： 你是在刻意避免摩擦。但当时那个 Web IDE 已经有很多用户了吧？

Michael： 没错，大概有上千个工程师在用。

Ryan： 但最后公司还是选择了你这条路线（后来变成 Nucleide）。你当时几乎没有用户，为什么最后会选你？

Michael：我觉得主要有两个原因。

第一，是技术路线本身。我当时强调的一点是：我们做的是一个桌面应用（desktop IDE），而不是 Web IDE。因为如果你真的想替代 Xcode，开发者一定会希望：能直接连接模拟器、能插手机调试、能直接操作本地环境。理论上 Web 也可以做这些，但成本会高很多、复杂很多。

第二，是“历史信用”。之前 Buck 做成了，所以大家愿意再赌一次。简单说就是：“上一个你做成了，那这次也可以再试试。”

Ryan： 看起来这段经历加上你在工作中的其他表现，后来让你晋升到了 E8——相当于业内所谓的首席工程师（Principal Engineer）了。当时你是什么感受？

Michael：我当时自然非常激动，但更重要的是一种“对齐感”。在 Google 的时候，我其实一直有点不太在节奏上——不只是技术上，而是我做的事情，和公司真正重视的方向之间，有一些偏差。

到了 Facebook，这次晋升对我来说，其实是一种确认：我不仅在技术上成长了，也开始更理解一件事——什么样的工作，是既重要、又符合公司方向的。这种理解本身，和技术能力一样重要，甚至更重要。

Ryan： 我记得 Nucleide 是开源的，Buck 好像也是吧？那选择开源的初衷是什么？

Michael：没错。相比之下，Buck 的开源更有代表性。Nucleide 在外部其实没有特别流行起来。

我觉得这类公司本身从开源里受益太多了，所以会有一种想法：如果这个东西不是我们的“核心护城河”，那不如分享出来。像我职业生涯里做的一些东西，包括 Codex，也都是类似的思路。即使没有人直接用你的工具，把实现方式公开出来，作为参考，对别人来说也是有价值的。

当然，在更理想的情况下，你还能获得外部贡献，比如有人提 PR、修 bug，这些都很有帮助。我记得 Uber、Airbnb 后来都用过 Buck。

某种意义上也挺自然的——Facebook 是规模最大的应用之一，所以很多问题我们会最先遇到；然后下一波公司开始遇到这些问题，就会来看我们是怎么解决的。

另外一个有意思的点是，Google 内部其实用的是 Blaze，对外是 Basil。我们当时也会想，如果我们把 Buck 开源，是不是能在某种程度上“倒逼”他们开放更多东西。后来他们确实也做了一些开放，虽然不完全是因为我们，但多少也有点推动作用。

还有一个现实因素是招聘。开源也是在对外展示：我们在做什么，我们擅长什么。如果你想在这个领域做最前沿的事情，这里就是你该来的地方。

Ryan： 那么开源的决定是自下而上的吗？是工程师们主动提议的，还是管理层在认可了价值之后推动的？你们有专门的内部政策文件吗？

Michael：好像没有这样的文件，但你讲的两种情况应该都有。比如像 React 和 PyTorch 这类典型的成功案例，它们就为公司创造了巨大的价值。但还有另外一些长期项目，在经济状况比较好的时候没什么争议，可随着宏观经济环境变差，管理者也会抱怨工程师们在开源上投入了太多精力。

整体来说，大部分开源项目都是自下而上推动的，通常不会遇到太多阻力。还能顺带做几场技术分享、写几篇博客，这些内容其实是有长期价值的，对招聘也很有帮助，而且生命周期比很多人想象的要长。

Ryan： 既然已经晋升到了 E8，我猜你心里的期望值也随之提升了吧。那现在是不是该去找个跟 E8 职级匹配的难题了？升职之后，你做了什么？

Michael：哈哈，那时我有点自不量力了。当时我想要解决 Web 加载速度的问题——这确实是个大挑战，那会 facebook.com 的加载速度实在不理想，架构有些陈旧。但这个问题实在太大了，而我其实并没有多少经验。Facebook 负责 Web 的团队成员大多已经在这个方向深耕了很多年，而我之前主要在做移动端和开发工具，所以并不熟悉这个领域。

我记得当时我和另外一位同事坐下来，打算根据源代码编译 V8 引擎，看看能不能优化 JS 生成机制使其更适配 V8。我们盲目尝试了各种方法，最后全都无果而终。

现在回头想想，不同的人适合不同类型的问题。我更擅长从零开始需要编写大量代码的项目，而当时这个问题更侧重于数据分析、跨团队沟通和协调——这实在不是我的强项。

Ryan： 你提到职业生涯中的这个阶段属于“英雄之旅”，这个词具体是指什么？

Michael：说来惭愧，这是指有些工程师总抱有“有谁能解决这个技术难题就好了”的幻想，而这份期待引发了我的自我膨胀。许多工程师都觉得，这个工程难题存在太久了，怎么就没人管呢？而我的想法也很简单：JS 嘛，我最熟悉。于是就这么投身进去了。

但我没能搞定，彻底失败了。回想起来，我觉得这是个重要的教训，而且我至少还是重新总结一次：虽然我确实能解决很多问题，但真正让我乐在其中、且能出色完成的事情其实是少数。我当然还会尝试逐步拓展其他领域，但从结果看我还是应该专注于真正热爱的事物，我不可能把事事都做到最好。

我觉得大家都能明白这个道理，也应该坦然接受自己的局限性。

Ryan： 那你后来是怎么找到真正符合 E8 级别的问题的？接下来发生了什么？

Michael：我觉得这多少也有些运气成分。我们当时组织了小型工程师会议，集思广益探讨未来可能出现的瓶颈。我提到代码库的持续膨胀终将引发扩展问题，而当时的部门经理、后来成为我主管的 Brian O’Sullivan 显然听进去了。

他决定召集人手开发虚拟文件系统，打算提前解决这个问题。于是我、Adam Simpkins 和 Wes Furlong 三个人加入了团队。这两位都是顶尖工程师，甚至在很长一段时间里，我都觉得自己是项目里最水的成员。

Ryan： 你提到了虚拟文件系统。对于 Meta 这样的大厂来说，自研这类系统有什么好处吗？

Michael：之前我们采用的是单体仓库（monorepo）模式——就是把所有代码都集中放在一个仓库里。但多数人实际要用的只是仓库中的某些子集，随时查看特定文件。所以我们的核心思路就是围绕这套虚拟文件系统设计配套工具：在克隆仓库、切换提交版本时，系统不再需要把仓库中的所有文件都写入磁盘。通过消除传统文件系统中的这种默认操作，就避免了文件数量随仓库规模呈现指数级增长。

而这项工作中涉及两个关键环节：其一是构建虚拟文件系统——当用户在某个提交点请求文件内容时，系统会动态生成对应文件，呈现出完整的文件布局效果。而在操作系统请求文件内容时，又可以即时调取数据，使其呈现为用户实际布局的完整文件结构。

而另外一部分就是我比较擅长的领域，即预判工具链中那些经常需要读取全部文件的工具。比如 grep 这类工具，就会直接读取所有内容。我要考虑该如何调整开发流程和工具设计，使其围绕虚拟文件系统展开。因为如果硬要使用原本的工具直接呈现所有文件，那新的虚拟文件系统也就没有意义了。

Ryan： 宏观上讲，其本质就是对庞大的文件系统进行延迟加载。不仅效率更高，而且无需在初始阶段处理全部内容。

Michael： 没错。

Ryan： 你刚才提到你更擅长的是把所有功能都整合到这套基础框架之上？

Michael：是的。其实我在跟 Hanson Wang（目前也是 Codex 团队的成员）合作时就意识到，传统方案在需要通过 IDE 或编辑器实现超快速文件搜索时，大多会首先遍历整个文件系统来搜寻文件。

我当时就觉得这绝对是个大问题。于是我们开始思考：要怎么既实现文件搜索，又不破坏原本的文件系统优势，进而探索出超越现状的新方案？最终，我们开发出名为 miles 的文件系统（即 my files 的缩写）。

它通过 cron 作业对主分支下的全部新提交进行索引，追踪文件增删情况——且仅索引文件名而非内容，因为单凭文件名就足够了。Hanson 还提出了一套维护索引的巧妙方案，实现了文件模糊匹配功能。也就是说新系统不仅支持子字符串匹配，哪怕文件采取驼峰式命名时，仅输入大写字母或者存在拼写错误，系统也能够准确识别。

我们想出了一种非常有趣的表示方式，用来记录全部曾被检出的文件，再配合一些标记来注明：在执行某项提交时，该文件当时是否存在？当我们向系统发送查询时——比如告知当前提交的版本号，以及是否在本地添加或删除了文件——就能返回相应的数据。

记得当时在处理超过百万文件的查询时，响应时间大概只在 10 到 20 毫秒之间。这套框架比 Xcode 或者 MDS 码的默认响应快得多，切实解决了性能迟缓的问题。

凭借极快的运行速度，Miles 开始作为内部服务开放调用，并被大家广泛应用于其他各种场景。我离开的时候，Miles 服务已经运行在全球至少 30 台服务器上，以极大的部署规模满足着远超文件搜索的多种需求。

Ryan： 你刚刚提到了不少实现细节，毕竟多数人在工作中不会用到 leetcode。但我琢磨了半天还是有点不理解，你的输入结构是怎么实现的，用的是 try 吗？

Michael：Try 确实挺强大的。我们在方案中用了两个并行数组：一个存储文件内容，另一个好像是指向索引的整数，具体记不清了。此外我们还设置了一条 64 位的掩码，其中包含 26 个小写字母、26 个大写字母、10 个数字还有连词符之类的。只要搜索文件中出现过该字符，就设置相应的字符位。

这样我们既能快速扫描列表、排除大量无效项，又实现了高度并行设计。所有数组都采用并行布局，从缓存效率的角度考虑，CPU 以线性方式读取内存时能获得极佳的性能。这种结构天然适合对数组进行分区并行处理。

Ryan： 我知道你参与 Eden 还有 Miles 项目的工作经历最终带来了进一步的晋升。但在晋升之前，你好像积累了一些关于提升个人影响力和处理意见冲突的经验？

Michael：是的，这也是我担任 E8 级别管理职务时面临的挑战。我之前一直负责编写代码，但实际上多数同级别或者更高职位的同事已经不写代码了。他们几乎完全专注于提升自己的影响力或者开展跨团队协作，比如撰写项目文档和协调各方意见等等。

所以身为 E8，要想达到预期中的影响力水平，光凭写代码可做不到。我得花时间去影响他人，这对我自己有好处，也能让上司满意。

当然，有时候我们可能过于坚持自己的观点，至少我那时候就这样，结果就是态度过于强势，最终让自己吃了大亏。那段时间我的晋升被延后了一些，也被提醒需要调整方式。

当时的一个背景是，微软收购 GitHub 之后，我非常焦虑。因为我们的 New Clyde 项目很大程度是建立在 GitHub 生态上的。我觉得这项目肯定要完了，毕竟 VS Code 肯定会吞噬它的独立地位，后来这个也确实发生了。我当时焦虑得要命，觉得项目陷入了重大风险。于是我拼命催促大家改变方向，却没考虑到团队里很多人其实对当前工作是满意的，也不想被突如其来的变动乱了阵脚。

后来上司把我叫过去狠狠训了一顿，我也接受了指导，专门去学习如何更好地处理这种情况。

Ryan： 那你在这方面学到的最重要的一课是什么？

Michael：对我来说，我现在更清楚哪些情况会触发自己的情绪反应，比如某些技术决策会让我情绪上头。在遇到这种情况时，我会马上反应过来并提醒自己：好吧，千万不能冲动行事。或者在意识到自己无法正常进行对话或者情绪状态不佳时，我会选择找对方的主管沟通，而不是直接闯进某个工程师的工位大喊：“我有个想法，是这么回事……”

很多时候我会先说：“我现在对这个问题有点激动，可能表达方式不太好，你帮我一起看看怎么推进更合适。”这种方式反而更有效。

Ryan： 挺有意思的一点是，你预见到了 VS Code 即将崛起，New Clyde 的底层架构将被淘汰，而你却因为自己的判断被推迟了晋升。事后证明你是对的，你一直在为正确的判断据理力争，却被要求“冷静点”。那在意识到事情发展成这个样子、意识到自己一直就是正确的，那时候你是什么感受？

Michael：大概一年之后我确实找相关的人聊过这件事，相当于复盘一下。毕竟之前事情闹得挺尴尬的。好在结果还不错，我们总算是解决了问题。

Ryan： 所以最重要的是处理方式，而非立场本身。

Michael： 没错，确实如此。

Ryan： 你在 Meta 似乎工作得挺愉快，但最终还是离开了。那是什么吸引你去了 OpenAI 呢？

Michael：有多方面因素。我最早是在 2023 年底面试的 OpenAI，当时我在 Meta 负责基于大模型的开发者工具项目，甚至还发布过自研授权版本的 Metamate——类似于 GitHub Copilot 的轻量版，也做过相关的论文和分享，比如 Code Compose 这样的项目。

但现实是，我们会经常收到反馈，询问为什么不选择用 GPT-4。我们只能解释用的是 Llama 2，这两者差距其实很明显。我本身不是做模型研究的，我更想做的是把这些能力做成产品、做成体验，所以我当时很自然地觉得，如果要做这件事，就应该去最好的模型所在的地方。

至于第二点，就是我在 OpenAI 身上感受到了当初谷歌对于顶尖人才的重视，这些人的选择肯定不会错。事实也确实如此。在 OpenAI，我有机会跟资深团队共事，包括很多 Meta 那边 8 级、9 级的专家，可以肆意发挥自己的价值。

第三点在于，这个时机还有 OpenAI 本身都很特别。我跟很多人提起过，那时候加入 OpenAI 很像 2000 年加入谷歌。注意，不是 1998 年的谷歌，而是 2000 年的谷歌。这时候公司已经站稳了脚跟，产品与市场的匹配度也初见成效，这个阶段对个人来说是非常有吸引力的。

还有一个更个人点的原因，我当初选择 Facebook 就是看中了它庞大的消费级市场——毕竟我就曾经深耕消费级产品，做的日历工具也广受用户欢迎。但结果我到了 Facebook 却完全没机会碰消费业务，后来做的开发者工具服务的其实是公司内部的工程师，大概就两万人左右。

后来想去 OpenAI，就是为了把握重返消费级领域的机会——至少可以拥有庞大的用户基数。现在我负责的 Codex 项目，每周活跃用户已经突破百万——具体数字记不清了，但增长曲线确实非常陡峭。这样的服务规模远远超过 Meta 内部 2 到 4 万开发者的影响范围。

Ryan： 没错，完全正确。行业中的开发工具大多也就到这个规模。

Michael： 对。

Ryan：在我看来，Meta 更像是一个工程驱动的公司，工程师是核心，很多事情是自下而上推动的。而很多 AI 实验室则更偏研究驱动，研究是第一优先，这也有它的合理性，毕竟模型本身很关键。你作为工程师，又不是做研究的，你怎么看待研究主导型文化和工程主导型文化的差异？

Michael：

这确实是一个需要适应的变化，如果有人号称自己能在这两种文化之间顺畅切换，我觉得都是在说谎。不过有一点是肯定的，在类似 FAANG 这样的大公司待过的朋友会有个好习惯，就是关注对自身影响力的培养。这非常重要，我也在真心实意追求这种影响力。正如我热爱在 Codex 和 Harness 项目上的工作，这都是很有意义、也很受尊重的成果。但如果模型本身不够优秀，我们在 Harness 这头做再多优化，其实意义也有限。

所以我加入 OpenAI 之后感觉特别棒，我们和研究团队是紧密协作的，坐的也很近，很多事情是一起推进的。这也是我离开 Meta 投身的重要原因——我更希望和做模型的同事一起打造产品，携手探索新的技术边界。

或许在 Meta 也能实现类似的模式，但实际效果终究不能相提并论。

Ryan： 你刚刚提到加入时就参与了 Codex 项目的启动工作。我听说 Codex CLI 刚刚发布时，市场反响并没能完全达到预期，但后来项目还是逐渐步入了正轨。能不能分享一下这段历程？

Michael：当然可以。这段旅程也是充满了波折。2025 年 4 月我们发布了 Codex CLI，我们在宣传直播末尾的彩蛋环节做了现场演示，同时开源了当时的 Core3Pro 项目，很多人都积极试用。大家都对这款全新编程助手充满了期待，它的表现也还不错，但当时的发布确实挺仓促的。

总体来讲，这对项目吸引人气还是很有帮助的——开源之后，我们收到了大量 PR。记得项目大概在一、两周之内就得到了一、两万颗 star。那段经历很有趣，而且也得到了很多用户的衷心喜欢。但问题在于，当时的团队可能还不具备推动项目发展的全面实力，毕竟公司需要同时推进多项业务。

在那之后的一个月，七名工程师加几位研究员（具体人数我也记不清了）发布了 Codex 的 Web 版本——允许用户直接在容器当中使用 Codex，甚至可以在手机上启动新项目。这真的特别酷。总之投入的人力更充足了，我也坚信这个项目的长期愿景值得期待。但从结果来看，它有点“走在用户前面了”，用户还没有完全准备好。

相比之下，大家当时更倾向于本地编程智能体，所以我们的 Web 版本虽然获得了一波增长，但粘性不如预期。

整个夏季我们还是持续在推进两条产品线。直到盛夏时节，本地化智能体仍具备更强的产品市场契合度。但我个人始终觉得本地方案只是权宜之计。毕竟智能体的运行需要更多设备，不可能单凭笔记本电脑来支撑。

所以夏天我们进行了重大调整：扩充了编程团队，引入更多开发人员。当时 GPT-5 即将发布，市场前景特别特别旺。我个人对此相当兴奋，因为之前除了 CLI 界面之外也做过几次原型测试，这回人手也终于充足了。我们还同时启动了 VS Code 扩展的开发，因为我坚持认为终端虽然适用于很多场景，但在交互上仍存在着诸多局限性。在终端打造精美的用户界面总要做出诸多妥协，而在 IDE 里可以做得更自然、完整。

8 月是一个爆发期——GPT-5 问世，我们也发布了全新终端界面。与此同时，GPT 开源模型也一并亮相，我们在 TUI 中同样对其提供支持。开放权重模型与开放训练框架的设计着实令人惊叹。同月晚些时候，VS Code 扩展发布，我们也由此进入疯狂迭代的新阶段。

正是这种种要素的交汇，催生并推动我们跨过了这波垂直增长的转折点。这段历程令人振奋，相关数据也都能在代码库里得到印证。无论是参与人数还是提交次数，各项常规指标都能让人直观感受到这种变化。现在回想起来，这也是段相当精彩的旅程。

Ryan： 你刚提到编程智能体的本地版本与云版本两种形态，而且你似乎坚信长久来看，未来的希望不在本地版本、而在云端部署。你为什么会这样判断？

Michael：现在真正让人“离不开”的那些使用场景，往往是这样的：比如每当有新的 GitHub issue、或者 linear 任务之类的进来，你就自动触发 agent 去处理。虽然这里面确实有成本问题，也可能被滥用，但如果是在公司内部的私有仓库里，这其实是很自然的一种用法。

在这种情况下，agent 更像是自动化流水线的一部分，而不是一个只在你本地交互的工具。那就意味着，这些任务不可能都跑在你的笔记本上。

从这个角度来说，作为个人开发者，你可能还是会更多时间在本地和 agent 交互；但如果看“agent 实际消耗的计算量”，我认为大头还是会发生在云端。前期部署这些东西可能稍微麻烦一点，但一旦搭好之后，体验其实是很好的。

Ryan：明白了。所以你指的并不是本地形态会消失，而是纵观整个行业，智能体消耗的算力将主要迁移至云端。

Michael：没错。我记得 Freeze Code 扩展首次发布时，其一大核心功能就是当用户进行对话时，只需点击按钮就能将对话内容传输至云端（前提是已完成配置）。可以想见，未来我们会看到更多类似的场景——你在本地开始一件事，然后把它丢到云端去跑，等它完成再拿回来。

Ryan： 今年以来，Codex 的使用量已经增长了 5 倍，目前用户规模超过百万。我好奇的是，自从开始使用新版 Codex 之后，你自己的 AI 工作流有很大变化吗？

Michael：确实有所改变。我现在使用 Codex 的频率远超之前的想象。以往我一直强烈依赖 VS Code 扩展，需要在侧边栏上把所有代码都放在眼前——当时我就觉得，应该把这些元素整合在一起。毕竟我本身就会关注代码内容。当然，如果真是那种一次性的原型实验项目，我也不大会阅读代码。

这种可以自由选择的感觉很棒，也绝对值得我们为此兴奋不已。但对于 Codex 项目本体的代码，我还是必须亲自把关。这一点非常重要，毕竟这个项目会影响到许多人。慢慢你会形成一种判断：哪些改动可以放心交给模型，哪些地方你需要盯着，甚至需要“看着它做”。所以现在的方式有点像是，我会在一开始就把需求写得更完整一些，然后交给模型去执行。

同时我本地会开四五个 Codex 仓库的副本，然后配合 Codex App 来做多任务处理，这种方式对我来说效率提升很明显，因为你基本可以一直待在一个窗口里，同时推进多个任务。某种程度上确实有点像在“打游戏”，你会下意识去想：我现在的吞吐量是多少？类似于同时能把多少颗球抛在空中再接住？

当然，有时候也会有点混乱，尤其是在上下文切换比较频繁的时候，但你又能明显感觉到产出在提升。有时候甚至会有点“愧疚”去手写代码，因为你会想，如果一开始把问题描述清楚交给模型，可能会更快。

就像你本来只是想改三行代码，结果 30 分钟过去还没弄完——这种情况大家都经历过，而现在很多时候其实是可以避免的。

Ryan：那现在你写的代码，大概有多少是自己写的，又有多少是模型生成的？

Michael：哎呀，现在模型生成的代码占比得有 80% 到 90% 了吧，这一点也不开玩笑。尤其是在调试测试和持续集成这类工作里，体现得就更明显了。我就总喜欢让大模型生成打印调试之类的代码，真的很棒、能够解放大量人力。

Ryan：那咱们再聊聊哪些问题适合大语言模型处理，哪些不适合。比如你要怎么判断哪些任务需要亲自动手编写？也就是那 10% 到 20%，和余下的 80%、90% 分别是什么？

Michael：这确实是个好问题。每次坐下来编程的时候，我都会琢磨：这部分有必要亲手编写吗？而答案几乎都是否定的。

有一类是偏底层的工作，比如 Codex 的 harness 这一层，我主要是在用 Rust 写，这里面会涉及很多操作系统层面的细节。

在实际工作中，我把大量时间花在了沙箱机制上。正是这套机制保障了我们工作的安全性和完整性，确保模型不会突破预设的边界。这类工作我就更倾向于手动编写，因为必须确保万无一失。

为了确保测试覆盖率足够完善，有时候我会先进行初始化，待基础框架搭建完成（比如我已经反复推敲过的模块）后再让 AI 自动填充剩余的部分。

但除此之外，其实很多事情都很适合交给模型，比如重构代码、拆分 PR，这些以前要花很多时间的事情，现在基本都可以交给模型来做。比如我经常会有一个比较大的 PR，我自己也知道它太大了，就直接让模型帮我拆成多个更容易 review 的 commit，这类工作节省的时间其实非常多。

Ryan： 那代码评审这块呢？在 OpenAI，大概有多少代码是人工审查的？还是说已经有智能体帮你处理一部分？比如测试用例这类应该不需要人工审查吧？

Michael：我比较认同一种方式，就是让 agent 先做多轮自我审查，直到它自己足够有信心，再交给人来看。但最终在代码真正合入之前，我们还是会做人工审查，这是不会省的。

从实际情况来看，我们和其他团队一样，也会有 agent 的一些配置文件，但还是会遇到模型知识不完整的地方，有些上下文需要补充进去，或者是一些没有被明确写进系统里的经验，这些往往是人还记得，但模型不知道的。所以在审查阶段，确实还是能发现问题。

另外一个明显的变化是，现在大家也开始用 AI 来写 PR 的总结，这让整个团队的描述质量提升了不少。现在我去审查的时候，代码已经被 Codex 过了一轮，还有一份结构清晰的总结，明确写了这次改动的原因和内容。这显然大大加快了 PR 审查流程，消解了原本巨大的任务审查压力。

Ryan： 这简直太棒了。我感觉可能有一半的 diff 文件都是空的，测试计划里简单写着“arc build”之类的模糊内容，根本不知道是干嘛的。

Michael：确实，莫名其妙的。

Ryan： 咱们聊聊这个吧——为什么会决定对 Codex CLI 进行开源？

Michael：理由很简单：这是一个会在本地运行且权限很高的工具，这也正是开源的意义所在。我虽然不是那种极端的开源拥护者，但我非常理解这种想法：既然这个东西要跑在我的机器上，我当然关心它的运作机制。特别是在 AI 编程领域，让用户可以查看代码、理解其行为是极其关键的——毕竟大家对于 AI 智能体这类新生事物还存在诸多疑问。因此我觉得开源是必要的一步。

此外，我们也能借此获得大量宝贵的贡献和 bug 报告，发现那些我们可能错过的问题。同时，我们也在向全世界展示自己的实现方式，如何通过代码搭建起一项项功能。我之前发过一篇关于智能体循环工作原理的博客，后面其实还想再多写一些，只是时间确实有限。

还有个有意思的小插曲，有两位候选人来面试，其中一位就拿着代码说是自己写的，但我立马发现那是我写的。另外一位就好得多，还很认可我亲自写代码这回事，夸得我心里美美的。

Ryan： 你提到的那篇博文介绍了 Codex 的工作原理，那 Codex 是如何发现环境中可用资源的？我在运行这些工具时，会看到它能自行思考，在终端里找出各种东西，太神奇了。这到底是怎样实现的？

Michael：其实这里用了好几种办法。比如 Codex 的基础训练机制，就决定了它特别擅长利用 RIP grep 查找各类信息。此外如果在智能体里的 MD 文件或者 Readme 文件里标注说“这个仓库中的这些工具很重要”，那它就会尽量优先使用。

另外如果大家用到了 MCP，并且把这些 MCP 服务器关联到当前项目，那这些工具的定义其实是在对话一开始就被注入进上下文的，所以严格来说，这部分不算是模型“自己发现”的，而是直接提供给它的。

Ryan：明白了。一部分是在 Harness 中显式注入上下文，另一部分则是模型自己去探索和调用。我的理解对吗？

Michael：就是这么回事。

Ryan： 回顾你的职业经历，技术跨度其实非常大，从前端、JavaScript，到构建系统、虚拟文件系统，再到现在的 Codex。你在这个过程中肯定也在不断学习，有没有哪些技术书籍对你影响比较大？

Michael： 有一本是操作系统的书，大概有一千多页，是 Addison Wesley 出的，但我一时想不起作者了。当时我在做虚拟文件系统那个项目，其实之前职业生涯里一直没怎么写过 C，本科更多是偏理论，也没有真的深入到底层。

结果突然在做一个非常底层的系统，这也是为什么我当时开玩笑说自己是项目里最弱的工程师。有一次别人说了一些东西，我发现我完全听不懂，就有点尴尬，于是就去问应该看什么书，我当时的经理就推荐了这本。

我就直接买了这本书，从头到尾读了一遍，基本走到哪带到哪，直到读完为止。其实挺有意思的，很多人可以在软件工程里走很远，但并不真正理解计算机是怎么工作的，因为中间有太多抽象层了。

一方面这很解放生产力，但另一方面也会带来一些局限。后来我也发现，如果你能主动往底层走一走，很多问题其实是可以被重新理解甚至被“拆掉”的，比如你会意识到某些层之间存在多余的开销，一旦去掉，可能就是一个数量级的性能提升。

所以我现在会建议大家，主动往更底层去理解这些东西，这对解决问题的能力提升是非常明显的。除此之外，我也挺喜欢 O’Reilly 出的一些 Rust 相关书籍，写得比较扎实、也比较系统。

还有一个不算书的建议，但我自己收获很大，就是去做一些 CTF（capture the flag）这类安全竞赛。这类比赛其实挺像一个“计算机十项全能”，会涉及很多不同领域，比如有的题需要你懂汇编，有的可能要你分析一个写得很糟糕的 PHP 管理页面。

这种方式会强迫你去接触不同层面的知识，而且它本身像一个游戏，也更有趣一些，比单纯看书更容易坚持下去。

Ryan： 能稍微解释一下什么是 CTF 吗？

Michael：CTF 可以有不同形式，但通常是信息安全领域的一种竞赛。最常见的一种是“Jeopardy”模式，也就是有一组设计好的题目，每道题都有对应的分值，你需要在规定时间内尽可能多地解出来，可以是个人参加，也可以组队。

每道题里通常都会藏着一个“flag”，也就是一段特定格式的字符串，只有当你真正完成了逆向分析、漏洞利用或者其他解题步骤，才能拿到这个字符串，然后提交它来证明你解出了这道题。

所以它有点像一种“终端里的密室逃脱”，你只能依靠计算机本身去解决问题。这类练习会逼着你去接触一些平时工作中不会碰到的内容，比如调试底层程序、分析二进制、理解系统行为等。

从提升能力的角度来说，它不仅能锻炼你的技术广度，也会让你形成一种更偏“对抗性”的思维方式，这在很多复杂问题里其实是很有帮助的。

Ryan： 所以你的建议是，如果有人想成为更强的工程师，可以去做一些类似 CTF 这样的练习，因为它会逼着你去解决各种不同类型的问题，对吗？

Michael： 对，我是这么认为的。你会在这个过程中掌握一些平时很难接触到的技能，比如调试底层程序、分析系统行为，这些在日常开发中不一定会用到。

而且它会强迫你在不同技术领域之间切换，这种广度其实很难通过常规工作获得。如果你只是每天写 React，很可能不会去打开 GDB、不会去做逆向分析，也不会真正理解底层是怎么运作的，但这些能力在很多关键问题上是非常有价值的。

从某种意义上说，这也是一种让自己“向下穿透抽象层”的训练方式，让你不仅会用工具，也知道工具背后是怎么工作的。

Ryan： 许多处于职业生涯早期的朋友，在看到 Codex 能在终端里包办一切时，都会感慨“那我不用学 GDB 了，反正 Codex 都懂。”在现在这种 AI 工具快速发展的环境下，你会怎么建议他们去思考自己的工程能力建设？

Michael：

没错，我觉得当下有很多人都受困于这个问题。我自己也思考过很多，但找不到完美的答案。我个人还是会回到一个比较朴素的判断：我依然觉得，应该主动去“往下走”，穿透这些抽象层，去理解系统更底层是怎么工作的，这件事仍然至关重要。

当然，这个判断未来可能会改变，但至少在现在，你问 agent 的问题质量，还是会直接影响你最终得到的结果。如果你问的问题不对，很可能就拿不到一个好的工程解法。 也许再往后，这一层也会被进一步抽象掉，但现在还不是。

整体趋势肯定是在往“更高层抽象”走，问题是我们什么时候会真正到达那个阶段，现在还说不好。进展确实比很多人预期的更快，但我觉得掌握提出正确问题的能力仍然是最重要的。

至于这个能力对于新人来说意味着什么，我自己其实也没有完全想清楚。我现在能做判断，很大程度上是因为过去的经验积累，让我形成了一种“直觉”和“品味”，知道该怎么问。但对于刚刚起步的年轻朋友，我实在没办法给出确切的答案。更何况我们也不可能百分之百预知未来的走向，一切尚在未定之天。

Ryan： 回头看你的职业发展，这些高级别岗位的要求其实挺夸张的。对大多数人来说，E7 或 Senior Staff 已经是很难达到的水平了，而你又往上走了两级。在日常工作中，你怎么看这种“高期望”？会让你有压力吗？

Michael：对我来说，压力就从没消失过。毕竟每个人都经历过绩效评估，对吧？而到了这个职位，就像审视他人的职级和影响力那样，我也想在自己的头脑中建立起尽可能公平公正的评判体系。比如不同的职级要有相应的标准和影响区间。

类似这个职级要对应什么标准，那个职级又该对应什么标准。这时候我的脑袋里就会不断推演：如果是别人坐在我的评估席上讨论标准，那他们也必须得公平公正。这是份巨大的压力。比如到了 E8 的职级，突然开始面对 D1 级别的总监，就会想：我要怎么跟手底下管理着上百人的高管去比拼影响力？

这确实很难，毕竟很多独立贡献者会通过另一种“间接管理”的方式来达成目标——比如撰写规范文档、协调团队间的协作之类。他们之所以选择这种方式、而非直接担任主管，是因为——我其实接触过这类同事，他们强调自己拥有技术公信力、或者曾亲手打造了当前项目，所以由他们进行团队沟通时，其影响力要远远优于普通的工程主管等职务。

而且这种情况可不罕见。当那些资深贡献者能够影响到几十、上百人时，就相当于具备了 D1 职级的影响力。而如果作为普通的程序员，我们则需要审慎地选择项目。千万别总想着“这个项目能让我玩得开心”，毕竟没人愿意丢掉工作或者被大老板在全体会议上吊起来批。

其实我在建立项目时，也会反复权衡：对于某项功能，我也很想出于乐趣而亲自动手。但在认真考虑后，还是决定交给别人做。比如说现在的 Codex 项目，我会考虑该亲自编写哪些代码才能尽量扩大自己的影响力。如果交给别人可以实现 80% 的效果，那就应该让别人接手。

可即便如此，在领导一个五人项目时，想要达到 E8、E9 级别的贡献预期还是很困难。所以关键是要找到能产生倍增效应的项目。比如虚拟文件系统就是个绝佳案例，我们都知道它的出现将解锁无数可能性，避免团队因性能瓶颈而遭到锁死的困境。

另外还有个关键点——我的上司曾经强调过：我们往往低估了高层管理者的价值。正是他们将资深核心工程师与合适的项目进行了匹配。有些资深工程师是出色的问题解决者和代码高手，但却并非创意的源头。他们才是处理高难度技术项目的理想人选。我不想具体点名，但大家应该懂我的意思。很多时候当事人自己并没有意识到，是管理者拍板认定“这个项目就得那个人来做”。

Ryan：我曾问过你的前同事 Adam Ernst，有没有遇到过自己特别欣赏的工程师、理由是什么？当时他就提到了你的名字，而且专门强调说你的项目启动能力非常出色。可以想象，有那么多出色的项目都是你一手带出来的，这种有了想法就去打造原型的执行力可不简单。

而且你还总能以极强的说服力，证明你的方案就是最优解。那么对于其他找到了问题、也有了初步思路，想要从零开始构建项目的工程师，你有哪些建议？

Michael：其实我觉得，很多优秀项目的灵感都来自对某些现状的微小不满。你会觉得某件事不应该是现在这样，这种感觉本身就是一个很强的起点。

有趣的是，我最大的特点就是有一股冲劲，埋头苦干、不瞻前顾后，甚至压根没考虑过所谓最佳实现方式。其中的经典案例，当数谷歌日历的早期版本。我当时突发奇想，打算把天气功能塞进来。是的，就是在日历上直接显示天气图标。之后我就直接动手开干了。

当时我主要是用 JS 开发，完全就没接触过后端。我硬着头皮拼凑代码搞定了功能，结果技术主管问：等等，你这天气数据是怎么存储的？我回答说，“就随便扔了堆 XML 数据。”他提醒道，“我们得先讨论协议缓冲区方案才行。”于是我恍然大悟，意识到二进制格式可以节省空间。

反正我就是这样，只想着实现当前功能，压根没问问别人有没有更好的方案。总之能跑起来就行。

Ryan： 看来正是你的这种独特属性，才特别适合深入挖掘问题根源并自主解决。几乎每个项目都是这样：现实怎么会是这样呢？一定要实现个功能来解决……然后你就开始动手了。

Michael：对，就是这么不管不顾的。

Ryan：我觉得你还有另一个特点，就是很多人都习惯了待在舒适区里。比如你之前提到的 Buck 项目，肯定有很多人都感受到构建速度慢得离谱了。但他们的想法是“算了，去餐吧那弄点东西吃，然后回来继续”，而你凭什么就觉得自己能大幅优化性能？

Michael：其实那次要归功于我在谷歌的经历。虽然我从未参与过 Blaze 团队的工作，也不了解项目的具体实现原理，更没接触过相关代码，但我明确知道世界上存在着某种更好的解决方案。这种存在性证明很重要——知道它存在，哪怕不确定自己能否实现，都足以支撑我试上一试。

另外，很多先前的技术成果也帮我积累了信心。我常常自诩为“编程机器”，哪怕现在有了 Codex、大家都成了编程机器，我也仍然保持着这份自信。快速构建原型至少可以解答疑问，或者在思想层面验证基本假设——即我认为本该存在的东西，是否真有实现的可能。

简单来讲，只要决心坚定，往往就能找到解决的办法。

Ryan：我发现一个挺常见的现象，很多人在大公司见过世界级的基础设施之后，再去别的公司，就会觉得“这个没有、那个也没有”，然后开始自己把这些东西重新做一遍。另外我读过你的不少文章，发现你的行文极其清晰，堪称技术写作的优秀典范。对于有意提升写作能力的工程师，你有没有什么建议？

Michael：我觉得关键还是在于多阅读，阅读是提升写作能力的最佳开端。无论是自觉还是潜意识，我们总能在阅读的过程中掌握写作的套路，比如作品的结构特征之类。此外阅读还有助于培养更宏观的思维：我们真正想要传达的是什么？读者真正需要了解的是什么？再就是一定得提前做好详细的规划大纲，很多人都强调过这点，但它的重要性往往被低估。

在具体写作时，关键在于：内容之间能否形成线性的逻辑链条？我们还要时时自问：从这个点到那个点之间的跨度是不是太大了？有没有哪些可能被读者忽略、但实际上非常重要的环节？我觉得只要解决了这些疑问，对于逻辑断层就能有比较明确的预判，有助于避免写出来东西人家看不懂的问题。

在预见到这种情况后，我们就要巧妙地加入示例来引导和帮助读者完成这种逻辑跳跃。至少在技术写作领域，我觉得这也是非常重要的一点。

Ryan：

你之前写过一篇关于职业发展的笔记深得我心，开篇就提出了扩大影响力的三步计划。能不能具体解释一下这三个步骤？我觉得大家都应该在职业发展中加以借鉴。

Michael：第一步是搞清楚我们真正喜欢做什么。就像我之前提到的，拓展兴趣范围固然很好，但真诚面对自己的内心也很重要——毕竟这个问题可没那么容易回答。就像我经历的很多“英雄之旅”也曾失败那样，我做的不少事情也并非出于热爱。至于第二步，就是搞清楚雇主真正看重什么、什么对它来说是最有价值的。

Ryan： 这个太重要了。

Michael：比如我在谷歌的时候，就没做好这一点。我做的是自己热衷的事，但并不是谷歌广告业务的核心。

第三步就是找到这两者的交集，然后尽可能把精力集中在这个交集上。你越能做到这一点，通常就越容易做出有影响力的成果。

当然，现实的问题是，这个交集有时候并不存在，那你可能就需要考虑换一个环境，去找到那个能让它成立的地方。

Ryan：最后一个问题：如果你现在带着这些经验，回到职业生涯的起点，你会给年轻的自己什么建议？

Michael：我本该更早敞开心扉学习更多事物。另外我也该对自己再狠一点。相信很多朋友都有同感：在起步阶段，我们需要学习的东西实在太多，所以刚刚接触第一门编程语言、特别是顺利拿下之后，我们就会对这种语言抱有偏爱，总想找借口证明它是最好的。比如无论什么场景，我都会说“不不，这语言本身完全没问题。”

毕竟它代表着我们真正开始做事、解决问题的起点，紧密关联一种美妙的、“终于能够搞点动静”的舒爽感。但这也会成为我们的陷阱，让我们想要死守这个工作。毕竟我们花了那么久才站稳脚跟、终于可以高效工作了，结果又要为新的转变和突破重新学习……这谁受得了啊？

我自己也是这样，我发现自己在 JS 上钻研得太深了。我觉得如果当时能对其他项目类型或者学习内容保持更多的好奇心跟灵活性，那结果会更好。虽然我最终还是做到了，但主动脱离舒适区肯定能让我更早实现突破。

Ryan：

从过往的经历看，你在 Xcode 时期曾经非常痛恨 Objective-C，后来甚至想出了把 Objective-C 编译成 Java、之后再编译回去的办法。还有你对掌握 C 语言的执着，可能是受到某种刺激，反正就是逼着自己必须搞明白。好在 Codex 已经越来越成熟了，它能大大降低学习门槛，也许未来我们可以随意让它输出 JS、Rust 或者任何语言形式的代码。

Michael：确实，Codex 的发展成熟确实开启了更多的可能性。

Ryan：太棒了。感谢你的宝贵时间，交流下来我受益匪浅。

Michael：不客气 Ryan，也感谢你的邀约。

原文链接：

https://www.developing.dev/p/openai-codex-tech-lead-on-how-his

会议推荐

OpenClaw 出圈，“养虾”潮狂热，开年 Agentic AI 这把火烧得不可谓不旺。在这一热潮下，自托管 Agent 形态迅速普及：多入口对话、持久记忆、Skills 工具链带来强大生产力。但这背后也暴露了工程化落地的真实难题——权限边界与隔离运行、Skills 供应链安全、可观测与可追溯、记忆分层与跨场景污染、以及如何把 Agent 纳入团队研发 / 运维流程并形成稳定收益。

针对这一系列挑战，在 4 月 16-18 日即将举办的 QCon 北京站上，我们特别策划了「OpenClaw 生态实践」专题，将聚焦一线实践与踩坑复盘，分享企业如何构建私有 Skills、制定安全护栏、搭建审计与回放机制、建立质量 / 效率指标体系，最终把自托管 Agent 从可用的 Demo 升级为可靠的生产系统。