AI 时代的前奏

主持人: 大家好，这里是最佳拍档。最近有一个很火的话题：AI 到底会不会取代程序员呢？从 GitHub Copilot 到 Claude Code，AI 写代码的速度和效率越来越高，这让很多身处行业内的工程师感到焦虑，甚至有刚入行的年轻人开始怀疑，花费大量时间学习数据结构、算法、底层原理，到底还有没有意义？今天我们就通过一位顶级工程师的职业经历来解答这个问题。他是前 Meta E9 杰出工程师，也是 OpenAI Codex 项目的技术负责人迈克尔·博林。作为硅谷底层技术领域的扫地僧，他曾经一手重构 Facebook 的 Android 构建系统，甚至为了解决代码库过大的问题，在操作系统底层搞出了虚拟文件系统。但就是这样一位以写代码著称的技术大佬，却坦言现在自己 80% 到 90% 的代码都由 AI 生成。从这期访谈中，我们或许能够知道，AI 时代工程师不被淘汰的唯一底牌到底是什么。

早期探索：Chickenfoot

主持人: 迈克尔·博林的技术生涯，从一个充满前瞻性的硕士毕设项目开始，这个项目就是 Chickenfoot，一款基于 Firefox 浏览器的扩展插件，也是他在研究生阶段的核心研究成果。在当时，用 JavaScript 为 Firefox 编写这样的插件，属于绝对先锋的技术尝试。而这个项目的核心理念，是为 Web 提供终端用户编程，这个理念甚至和现在的 AI Agent 有着异曲同工之妙。Chickenfoot 集成在 Firefox 的侧边栏中，是一个小型的编程工具，它提供了 enter、click 这类简单的宏命令。用户只需要输入 enter 并传入字符串参数，工具就能自动在网页上寻找对应的输入框并完成填充；或者输入 click search，工具就会精准点击网页的搜索按钮。在这个看似简单的功能背后，是大量复杂的启发式算法，这些算法会解析网页的 DOM 结构，识别各种文本信息，定位到距离文本最近的输入框，再通过 JavaScript 完成自动操作。为了提升识别的准确性，博林的团队还充分利用了网页的可访问性标签、图片的 alt 文本等所有可抓取的信息，这让 Chickenfoot 在 Craigslist 这类界面简陋的网站上也能完美运行，甚至有他的朋友利用这个工具，编写了一个自动化脚本实现了盈利。现在回头看，这个十几年前的项目，已经具备了现在 AI Agent 的核心逻辑：用简单的指令实现网页的自动化操作。唯一的区别只是，当年靠的是粗糙的 JavaScript 脚本，而现在靠的是大语言模型。

谷歌的文化熏陶

主持人: 完成硕士阶段的研究后，博林的第一份业界工作选择了 Google，并且一入职就负责 Google Calendar 项目。这个选择和他对 Google 工程文化的认可密不可分。上世纪 90 年代，互联网刚兴起时，搜索引擎还处于百家争鸣的阶段，想要找到一条有效信息，需要同时打开 Yahoo、Lycos 等五六个搜索引擎。而在 2000 年 3 月，博林从室友口中得知了斯坦福大学推出的 Google 搜索引擎。试用后他发现，这款搜索引擎不仅搜索质量远高于同类产品，页面更是极其简洁，没有 Yahoo 首页那些眼花缭乱的广告和门户链接。这种专注技术质量而非短期流量的文化，让他下定决心加入 Google。而 Google Calendar 团队，也给了他施展才华的最佳舞台。当时微软的 IE 浏览器占据绝对的市场统治地位，甚至一度砍掉了 IE 的后续开发计划，网页端应用的发展环境极其恶劣。而且在那个年代，JavaScript 的工程质量极差，行业内普遍认为写前端代码就是在写玩具代码。但是 Google Calendar 团队却聚集了一批顶尖工程师，他们的目标是打破这种局面，把桌面级应用的体验，比如日程的拖拽操作和页面的无刷新加载，搬到网页端，这在当时是极具开创性的尝试。博林在这个团队的经历，让他深刻理解了技术突破的价值，也为他后续解决大厂底层技术难题积累了核心经验。

Meta：底层技术攻坚

主持人: 在 Google 积累了足够的技术经验后，博林跳槽到了当时如日中天的 Facebook，也就是现在的 Meta，而这个阶段，成为了他职业生涯中最具有代表性的“底层攻坚期”。当时的 Facebook 正处于战略转型的关键节点，公司明确提出“移动端才是未来”的口号，这个决策直接关系到公司的生死存亡。而作为一名顶级的 JavaScript 专家，博林最初的规划是开发一套类似 PhoneGap 的框架，用 HTML5 技术开发移动版 Facebook。毕竟 PhoneGap 作为早期将网页打包成原生应用的技术，是当时的主流选择之一。但是在实际开发过程中，基于 HTML5 的移动应用暴露了严重的性能问题，体验糟糕到难以投入使用。最终 马克·扎克伯格 亲自拍板，废弃了 HTML5 方案，全线转回纯原生开发。这个决策让博林面临职业选择：要么硬着头皮，学习自己并不喜欢的 Objective-C 语言做原生开发；要么寻找公司发展中的其他技术痛点。幸运的是，他很快发现了 Facebook Android 团队的核心问题，那就是构建系统的效率低下。当时 Facebook 的 Android 团队使用的是基于 Ant 的老旧构建系统，这套系统没有模块化设计，也没有缓存机制。工程师修改一行代码后，系统需要重新编译整个庞大的代码库，而编译后在模拟器中看到结果的迭代周期，正是决定工程师生产力的核心指标。博林凭借自己的 Java 技术功底，决定接手这个底层的脏活累活。原本他只是想修复几个 Bug，但是深入研究后发现，这套系统的底层架构已经彻底失效，唯一的解决方案就是推倒重来。当时很多从 Google 跳槽到 Facebook 的工程师提出，直接照搬 Google 的构建系统就可以解决问题。博林的团队也确实做过尝试，甚至在内部复刻了一个微型的 Google 构建系统版本，但最终还是放弃了。核心原因有两个：一是 Facebook 的 Android 代码库和 Google 的代码库结构截然不同，Google 的代码库规范且模块边界清晰，而 Facebook 的代码库背负着大量历史包袱，各类资源文件和定制化的脚本交织在一起，强行套用 Google 的架构需要重写所有底层逻辑；二是时间不允许。当时 Facebook 正处于移动端转型的关键期，管理层的要求是立刻提升迭代速度，哪怕只有一点点，团队根本没有时间花一年去搭建一套完美的架构。正是在这样的背景下，博林主导开发了 Facebook 的开源构建工具 Buck。团队最初只是用 Python 写了几个简单的脚本，尝试缓存编译的中间结果，但是这种修修补补很快达到了极限。于是在一次 Facebook 的黑客马拉松活动中，博林决定彻底抛弃 Python 脚本，用 Java 重新开发了一套强类型、高并发的构建系统雏形。而这个雏形带来的效果超出了所有人的预期，让编译速度直接提升了两倍，原本需要 4 分钟的编译过程被压缩到了 1 分钟。这让原本对底层工具重构毫不在意的 Android 团队，瞬间成为了 Buck 系统的忠实信徒。解决了构建系统的问题后，博林并没有停下脚步，因为 Facebook 的代码库还在以指数级速度膨胀，新的规模诅咒很快出现：编译速度提升了，但是工程师连代码库都打不开了。当时 Facebook 使用的是 Eclipse IDE，而公司采用的是单一代码库模式，整个代码库有几千万行代码。用 Eclipse 打开这个项目，光是建立索引就要花费半个小时，期间电脑风扇狂转、内存被完全占满，整个机器彻底卡死。工程师们的核心抱怨变成了：“构建是快了，但代码根本打不开”。当时业界针对这个问题有两种解决方案：一种是彻底抛弃本地 IDE，把开发环境搬到云端的基于 Web 的 IDE；另一种是选择轻量级的本地编辑器。而博林的团队选择了一条中间路线。当时 GitHub 刚推出 Atom 编辑器，也就是 VS Code 的前身。这款编辑器基于 Web 核心技术开发，具备极高的灵活性。团队决定在 Atom 的基础上，开发一套专门针对 Facebook 巨型代码库的 IDE 插件系统，这就是 Nuclide。Nuclide 的核心设计思路是远程算力加持，团队把语言解析、代码自动补全、跳转定义这些极其耗费性能的功能，全部剥离出来放到远程的高性能服务器上运行，本地的 Nuclide 编辑器只负责展示 UI 和接收用户的键盘输入，相当于给每一位工程师配备了一台看不见的“超级计算机”，完美解决了本地 IDE 处理超大代码库的性能问题。而 Nuclide 解决的只是 IDE 的问题，Facebook 的单一代码库模式还带来了一个更棘手的问题，那就是代码库的物理体积过大。作为单一代码库，Facebook 把 Facebook、Messenger、Instagram 等所有产品的代码都整合在一个仓库中，这个仓库最终膨胀到包含几百万个文件、几十 GB 数据。传统的版本控制系统 Git 和 Mercurial 在这样的规模下彻底崩溃。最直观的问题就是，新员工入职后，哪怕只是想修改一行前端代码，也必须把几百万个文件、几十 GB 的数据完整克隆到本地笔记本，这个过程需要耗费几个小时。而更让人崩溃的是，工程师每次运行简单的 git status 命令，系统都要遍历几百万个文件检查变动，直接导致终端卡死。面对这种极致的规模问题，常规的优化手段已经完全失效，博林的团队只能深入到操作系统的最底层寻找解决方案，而最终的成果就是 Eden 虚拟文件系统，后来演变成了 Miles。Eden 的核心实现，是利用 Linux 的 Fuse 机制，以及 Mac 系统上的类似机制，直接拦截操作系统的文件读取请求。在工程师的笔记本上，看似能看到几百万个文件的完整目录结构，但这些文件其实都是占位符，硬盘中并没有实际的文件数据。只有当工程师双击打开某个文件，或者编译器需要读取某个文件时，Eden 才会瞬间触发网络请求，从服务器上把对应的文件加载到本地。这个设计带来的效果堪称魔法：原本需要几个小时的代码库克隆时间被压缩到了几秒钟，原本会导致终端卡死的 git status 命令实现了瞬间响应。团队在操作系统底层，成功骗过了所有的上层应用，彻底解决了单一代码库的规模诅咒。

职业转折：E9 晋升之路

主持人: 解决了构建系统、IDE、文件系统这一系列大厂最硬核的底层难题后，博林迎来了职业生涯的一个重要节点：从 Meta E8 首席工程师向 E9 杰出工程师的晋升。而这个过程，被他称为“血肉之路”，也让他彻底理解了大厂高级工程师的晋升真相。Meta 的 E9 职级，是技术岗的天花板。而在晋升之前，博林满心以为自己能顺利通过，毕竟他解决的都是关系到公司发展的核心底层问题。在他看来，自己作为超级码农，写代码的效率和质量远超同行，晋升是水到渠成的事。但现实却是，他的晋升申请被无情的驳回了，这让他陷入了极度的愤怒和不解。直到他和几位 Meta 的 E9、E10 资深大佬深入交流后，才发现了自己的核心问题，那就是陷入了“英雄主义陷阱”。在早期的职级晋升中，从初级到高级工程师，拼的是写代码的能力，是技术硬实力。但是当职级达到 E6 Staff 甚至 E8 Principal 后，只写代码反而会成为晋升的最大阻碍。博林当时的工作模式，是发现问题后闭门造车，用自己的顶级技术水平从零开发一个全新的工具，然后直接推给团队使用。这种做法看似高效，实则充满了技术傲慢。当公司拥有几千名工程师时，强行推行一个新工具，意味着打破所有人的现有工作流，必然会遭遇巨大的阻力。而 Meta E9 职级的核心要求，从来不是造一个新轮子，而是能解决那些无人认领的、丑陋的系统性难题，并且能带着所有人一起往前走，需要从一名纯粹的技术极客，转变为具备政治手腕和布道能力的技术领袖。这次晋升失败，成为了博林职业生涯的重要转折点。他收起了自己手撸代码的骄傲，开始把大量精力放在非标准自动化和跨部门协调上。而 Eden 虚拟文件系统项目，就是他转型后的核心实践。Eden 项目的推进，面临着前所未有的阻力。这个项目不仅需要修改底层的客户端代码，还需要后端存储团队的全力配合。更重要的是，它需要改变全公司几千名工程师的开发习惯。为了推动项目落地，博林花了数月时间，不再写 C++ 或 Java 代码，而是疯狂地撰写技术文档和战略规划。他需要在文档中向公司高管证明，这个看似冒险的项目是解决代码库规模问题的唯一方案；需要亲自游说后端存储团队，让他们相信为 Eden 开发专属 API 是值得的；还需要安抚一线的业务工程师，承诺新系统上线后不会丢失任何数据。用他的话来说，这就是一场“拼凑积分”的游戏：找到公司级别的核心痛点，把分散在各个团队的资源像拼图一样整合起来，最终推动项目落地。而当他带领团队，彻底清理掉 Eden 项目背后那座牵扯无数利益、极其丑陋的遗留屎山后，他的 E9 晋升申请也顺理成章地通过了。这也印证了大厂晋升的核心真相：高级工程师的价值，不在于写了多少优秀的代码，而在于能通过技术和协调能力，解决公司的核心系统性问题。

奔赴 AI 前沿：OpenAI

主持人: 在 Meta 达到技术职级的天花板后，博林做出了一个让所有人意外的决定：离开自己奋斗了 11 年的 Meta，加入当时规模还远不及现在的 OpenAI。而这个决定的背后，是职业倦怠和对新技术浪潮的向往。在 Meta 的最后一年，博林陷入了明显的职业倦怠。他在底层架构领域深耕多年，已经看到了技术的天花板。所有的优化工作都进入了边际收益递减的阶段，哪怕再花一年时间，也只是能把某个系统的性能提升 5%。这种修修补补的工作，让他失去了当初那种改变世界的技术兴奋感。而就在此时，2023 年底，大语言模型的浪潮彻底爆发。博林开始在业余时间疯狂阅读关于 Transformer、注意力机制的论文。他突然意识到，大语言模型带来的是一种全新维度的计算范式，如果错过了这波浪潮，自己的技术生涯可能就会止步于此。而恰逢 OpenAI 正在招募懂大规模工程底层的资深工程师，博林毫不犹豫地投出了简历，开启了自己的 AI 领域探索之路。

Codex 的诞生与影响

主持人: 从 Meta 到 OpenAI，博林遭遇了前所未有的文化冲击。这种冲击来自于传统互联网大厂和 AI 实验室的核心文化差异。在 Meta、Google 这样的传统大厂，奉行的是工程主导的文化，软件工程师是公司的核心资产。产品经理提出需求后，由工程师决定技术架构、项目排期，最终完成代码开发和上线，公司的所有光环、资源和晋升通道都是围绕工程师建立的。但是 OpenAI 奉行的是研究主导的文化，这里的核心王牌是那些拥有数学、物理学背景的研究员，他们的日常工作是推导数学公式、调整模型结构、观察 loss 曲线。而像博林这样拥有光鲜履历的大厂顶级工程师，在 OpenAI 的定位更像是辅助人员。他们的核心职责不再是决定产品的发展方向，而是像后勤部队一样，搭建极致的分布式计算集群、优化 GPU 的显存利用率、搭建数据清洗的流水线。所有的工程努力，都是为了让研究员能顺利跑通下一次模型实验。对于那些渴望个人英雄主义、希望掌控产品的工程师来说，这种落差会让人极度痛苦。但是博林却非常享受这种状态。在大语言模型这个全新的领域，他放下了 Meta E9 的身份，以一个小学生的心态重新学习，学着和研究员对话，学着把那些天马行空的数学理论，转化为能在成千上万张 H100 显卡上稳定运行的 C++ 和 Cuda 代码。而这种全新的技术挑战，让他重新找回了技术探索的乐趣。在 OpenAI，博林主导的核心项目就是 Codex。Codex 的诞生，源于一次 OpenAI 内部的黑客马拉松活动。其实在这之前，OpenAI 的工程师已经开始使用早期的代码生成模型辅助工作。但是博林和团队突发奇想：如果把这个模型封装成一个可以在命令行直接调用的工具，会带来什么样的效果呢？于是他花了很短的时间，写了一个简陋的终端封装程序，而这个程序的运行效果，让所有人都感到震惊。工程师只需要在终端里用自然语言输入需求，比如：“帮我把当前目录下所有扩展名为 .txt 的文件重命名为 .md，并且去掉文件名里的空格”，Codex 就能瞬间生成一段可以完美运行的 Python 或 Bash 脚本。这个工具很快在 OpenAI 内部像病毒一样传播开来，它也证明了一个核心事实：AI 不仅仅能辅助工程师写代码，还能直接替工程师完成那些繁琐的代码杂活。也正是因为这个原因，博林的团队后来决定将 Codex 的测试套件完全开源。他们希望让整个开源社区看到，AI 代码生成不是魔术，而是有实实在在的工程标准可循，而团队也试图通过这种方式，定义未来 AI 代码助手的行业评估标准。

AI 驱动的开发新范式

主持人: Codex 的成功，也彻底改变了博林的工作流。作为一名深耕底层二十年的顶级工程师，他现在几乎不再手写代码，甚至坦言自己亲手敲的代码连 10% 都不到，很多时候这个数字接近于零。他现在的工作模式，已经完成了从代码编写者到代码审查者的彻底转变。首先，在编辑器中写下一段极其详尽的英文提示词，在注释中清晰描述需要实现的数据结构、接口逻辑和边界条件，然后按下快捷键，AI 就能在几秒钟内生成几百行代码。接下来，他就会运用自己二十年的系统工程经验，对 AI 生成的代码进行全面审查，检查代码是否存在内存泄漏的风险、是否有并发死锁的隐患、是否忽略了某个边缘测试用例。如果发现问题，就向 AI 提出修改要求，让 AI 重新生成代码。而最让他感到解脱的是，AI 包揽了他曾经最讨厌的工作：写单元测试和配置 CI/CD 脚本。现在他只需要向 AI 提出“为上面的函数生成 100% 覆盖率的测试用例”，AI 就能生成极其完备的测试代码，甚至还能自动生成伪造的 Mock 数据。这种工作模式的改变，让他彻底从繁琐的代码语法细节中解放出来，拥有了大量的时间去思考更高维度的系统架构设计，而这也是 AI 时代工程师工作的核心趋势。

AI 时代工程师的护城河

主持人: 博林的经历，让很多年轻工程师感到恐慌：连顶级的 E9 工程师都不手写代码了，那我们拼命学习数据结构、算法、底层原理，还有什么意义呢？针对这个问题，博林给出了明确的答案：在很长一段时间内，深厚的技术基本功，依然是工程师最坚固的护城河。核心原因在于，现在的大语言模型本质上还是基于概率的模型，它存在一个无法避免的问题，那就是“幻觉”。它会生成看似语法完美、逻辑通顺的代码，但这些代码中可能隐藏着致命的 Bug。如果一名初级工程师完全依赖 AI 写代码，当系统在线上发生崩溃，面对几千兆的日志和乱码般的堆栈报错时，他会束手无策，因为他根本不知道代码的底层发生了什么。而博林之所以能自信的让 AI 生成 90% 的代码，核心在于他拥有那 10% 的底层掌控力。他懂 C++ 内存分配的底层原理，懂操作系统的线程调度机制，懂汇编语言的核心逻辑，所以他能在一眼扫过 AI 生成的代码时，瞬间判断出代码是否在胡说八道。他用一个形象的比喻来形容 AI 和工程师的关系：AI 是工程师手里一把无限子弹的机枪，威力巨大；但是如果工程师不知道该瞄准哪里，甚至不知道怎么处理卡壳，这把枪最终会变成杀死自己的武器。

核心价值与未来方向

主持人: 对于想要提升自身能力的工程师，博林也分享了自己的独家经验。首先，他强烈建议想提升系统底层理解的工程师去参与网络安全夺旗赛 CTF。这是他提升底层能力的核心方法。在 CTF 比赛中，工程师需要解决各类极其复杂的底层安全漏洞，这会逼着你深入理解汇编语言、寄存器的工作原理、网络协议的每一个字节。这种带有极强目标感、像解谜游戏一样的训练方式，比干巴巴地啃教科书有效一百倍。其次，他推荐了两本核心技术书籍：一本是关于操作系统底层的经典著作，也就是被行业称为“恐龙书”的《Operating System Concepts》；另一本则是关于技术写作的书籍。很多人会觉得技术写作并不够硬核，但是博林认为，技术写作恰恰是最高级的硬核能力。就像他在 Meta 晋升 E9 的经历一样，当你想要推动一个几百人的跨部门大项目时，写的代码再好也没用，你需要用清晰、有煽动性、逻辑严密的技术文档，去说服那些根本不懂代码的公司副总裁和财务总监，让他们认可你的技术规划。如果一名工程师只会写代码，那他充其量只是一个高级工匠；但如果他能用文字构建起一个宏大的技术愿景，并且让所有团队心甘情愿地追随，那他才是真正的技术领袖。迈克尔·博林的职业经历，是一个从传统软件时代到 AI 时代的工程师缩影。他的故事也为所有身处行业内的工程师指明了方向：AI 确实会取代大量繁琐的代码编写工作，但是也会让工程师的核心价值更加凸显。对于每一位工程师来说，与其焦虑 AI 会取代自己，不如沉下心来打磨底层能力。因为在 AI 时代，程序员真正的核心竞争力，从来都不是写代码的速度，而是对技术底层的理解和掌控力。感谢收看本期视频，我们下期再见。