编译：王启隆
来源：youtu.be/hN5ZFzWFhhg
在硅谷的工程师圈子里，有这样一群站在金字塔顶端的人。他们不追求酷炫的前端效果，也不沉迷于产品设计，而是终日与操作系统的底层、编译器、构建系统和虚拟文件系统打交道。他们的核心价值，是确保像 Meta 这样拥有数十亿行代码和上万名工程师的超级代码库，在每一次构建时都不会彻底崩溃。
Michael Bolin 就是这样一位镇守技术底层的“扫地僧”。
作为前 Meta 的杰出工程师（Distinguished Engineer，E9职级），他曾主导重写了 Facebook 的 Android 构建系统。甚至因为代码库过于庞大，他带领团队在操作系统底层拦截系统调用，构建了一个虚拟文件系统，只为让工程师运行 git status 时电脑不会卡死。
他曾长期将自己定义为“一台无情的写代码机器”。然而，当这位传统工程领域的顶级专家跳槽加入 OpenAI，并成为 Codex（即 GitHub Copilot 的底层模型）的技术负责人后，他的世界观被彻底重塑。
在最近一期的《The Peterman Pod》深度访谈中，Bolin 坦诚地承认：“我现在几乎不手写代码了。我 80% 到 90% 的代码，都是由 AI 生成的。”
我们将对话中的几个核心观点提炼如下：
- 大厂晋升的“英雄主义”陷阱：许多高级工程师难以晋升，是因为他们总想从零打造一个完美的“玩具”，而不愿去接手那些丑陋但至关重要的遗留系统。在 Meta 想要升到 E9，你必须成为一个既能干脏活累活，又懂得协调的“政治家”。
- 文化休克：研究主导 vs. 工程主导：在 Google 和 Meta，工程师是绝对的核心；但在 OpenAI，研究员才是主角，工程师更像是为他们搭建算力基础设施的“辅助人员”。这种文化落差让许多跳槽去 AI 实验室的大厂精英感到不适。
- 顶尖工程师的关键武器是“写文档”：Bolin 透露，他在 Meta 晋升的最关键因素并非写代码，而是“撰写出能让高管和跨部门团队理解的技术规划”。
- AI 时代的护城河转移：尽管 AI 为他编写了大部分代码，但由于大语言模型容易产生“幻觉”，深厚的底层系统理解（如内存管理、指针、汇编）反而成了他能快速识别 AI 错误、修正复杂架构的唯一底牌。
以下是这场对谈的中文编译精要。
从 Firefox 插件到 Google 日历的“荒野求生”
Ryan Peterman（主持人，前 Instagram 软件工程师）：欢迎 Michael。我们先聊聊你的早期项目。我看到了你个人网站上那个链接已失效的“Chickenfoot”项目，那是什么？
Michael Bolin：那真是年代久远了。那是我的硕士论文项目，一个 Firefox 浏览器扩展。简单说，它是一个集成在侧边栏的编程工具，理念是为 Web 提供“最终用户编程”。它提供像 enter（输入）、click（点击）这样的宏命令。例如，输入 enter 并传入一个字符串，它会自动在网页上寻找对应的输入框并填写。
底层我们构建了复杂的启发式算法来解析 DOM 结构。现在回想起来很有趣，因为当下许多 AI Agent 做的事，和我们当年用粗糙的 JavaScript 脚本实现的一模一样。
Ryan：所以你后来去了 Google，负责 Google Calendar 项目。那时的 Google 是什么氛围？
Bolin：那是 2000 年代初。我毕业后非常向往 Google，因为它当时展现出的专注质量而非短期流量的工程文化。加入 Google Calendar 团队是个完美契机，我们正试图在微软 IE 占据统治地位的时代，通过网页应用打破局面。我们尝试将桌面级体验（如拖拽日程）搬到浏览器中，这在那时极具开创性。
Ryan：后来你跳槽到 Facebook（现 Meta），作为一名 JavaScript 专家，为何会去重构 Android 构建系统？
Bolin：当时 Facebook 正全力转向移动端。我最初想用类似 PhoneGap 的 HTML5 方案，但体验极差。最终公司决定全线转向原生开发。那时我面临选择：去学我不喜欢的原生语言，或找别的方向。
我发现了痛点：工程师修改一行代码后，编译等待时间（迭代周期）太长。当时的构建系统基于陈旧的 Ant 工具，没有模块化和缓存，每次都要全量编译。我懂 Java，觉得可以试试。结果越深入，发现系统地基已烂，必须推倒重来。
Ryan：为什么不直接用 Google 内部的强大工具（后来的 Bazel）？
Bolin：我们试过。但问题是，Facebook 的代码库结构和 Google 完全不同。Google 的代码库规范、模块清晰；而 Facebook 的 Android 代码库充满历史包袱，资源文件、定制脚本混杂。强行套用意味着重写所有底层逻辑。
更重要的是时间压力。公司正处于移动转型的关键期，等不起一年去搭建完美架构。这就是我们开发 Buck（Facebook 开源的构建工具）的背景。我们最初用 Python 写脚本缓存中间结果，后来在一个黑客松上，我用 Java 重写了强类型、高并发的构建系统雏形。当编译时间从 4 分钟降到 1 分钟时，整个团队都成了新系统的支持者。
Ryan：构建系统之后，你们又开始重写 IDE 甚至做虚拟文件系统？
Bolin：这是顺理成章的演进。构建快了，但代码库膨胀导致传统 IDE（如 Eclipse）索引项目要半小时，电脑卡死。业界有转向云端 IDE 或轻量编辑器的声音。
我们选择了中间路线：基于 GitHub 的 Atom 编辑器（VS Code 前身），开发了名为 Nuclide 的 IDE 插件系统。我们把耗性能的语言解析、自动补全等功能剥离到远程服务器，本地只负责 UI 展示。
Ryan：“虚拟文件系统”又是为何而生？
Bolin：是为了对抗物理定律。Facebook 采用“单一代码库”哲学，所有产品代码都在一个仓库里。当它膨胀到数百万文件、几十 GB 时，Git 这类版本控制系统崩溃了。新员工克隆代码库要几小时，运行 git status 会卡死终端。
常规优化失效了，必须深入操作系统底层。我们开发了 Eden（后演变为 Miles）虚拟文件系统，利用 Linux FUSE 或 Mac 类似机制，拦截系统文件读取请求。
你在本地看到的文件目录结构，实际是“占位符”。只有当你真正打开或编译器需要某个文件时，系统才会从服务器“懒加载”下载它。通过这种按需加载，克隆时间从几小时压缩到几秒，系统状态检查瞬间完成。我们在底层“骗过”了所有上层应用。
从 E8 到 E9 的“血肉之路”与晋升失败
Ryan：你解决了这么多底层难题，那么从首席工程师（E8）晋升到杰出工程师（E9）的过程是怎样的？
Bolin：这段经历颇为曲折。许多人对高级工程师有误解，认为成为“超级码农”就能一路晋升。在初级到高级阶段或许可行，但到了 Staff（E6）甚至 Principal（E8）之后，“只写代码”反而会成为晋升的障碍。
我完成 Nuclide 等项目后，以为能顺利升 E9，但申请被驳回了。起初我感到愤怒不解。后来与资深 E9/E10 交流后，他们指出了我的问题：我陷入了“英雄主义陷阱”。
我习惯于发现问题，然后闭门造车，写一个新工具出来，再让大家使用。这在几千人的公司是行不通的，强行推行新工具会打破所有人的工作流，阻力巨大。
真正能在 E9 级别产生影响力的，是 “解决那些无人认领的、极其丑陋的系统性难题，并带领所有人一起前进”。
Ryan：所以你需要从技术极客转变为具有政治手腕的技术领袖？
Bolin：是的。失败后，我收起了骄傲，将大量精力放在“非标自动化”和跨部门协调上。像虚拟文件系统 Eden 这样的项目，阻力巨大，需要修改客户端、后端配合，并改变数千人的开发习惯。
我花了数月时间写技术文档、战略规划，向高管证明项目的必要性，游说后端团队，安抚一线工程师。这像一场“拼积木”游戏：找到一个公司级痛点，整合分散的资源，最终打赢战役。
当我带领团队清理掉那个庞大而丑陋的遗留系统后，E9 的晋升便水到渠成。
加入 OpenAI，“研究主导”的文化休克
Ryan：在 Meta 达到顶峰后，为何选择加入当时规模尚小的 OpenAI？
Bolin：在 Meta 的最后一年，我有些职业倦怠。底层架构的优化已边际收益递减，我失去了改变世界的兴奋感。2023年底，大语言模型浪潮爆发，我开始疯狂阅读 Transformer 等论文，意识到这是一种全新维度的计算范式。我觉得如果错过，技术生涯可能就此止步。恰好 OpenAI 在招募懂大规模工程底层的人，我便投了简历。
Ryan：从互联网巨头跨入 AI 实验室，最大的冲击是什么？
Bolin：简直是 “文化休克”。
在 Meta、Google 是 “工程主导”。软件工程师是核心，产品经理提需求，工程师决定架构和实现。所有的光环和资源都围绕工程师。
但在 OpenAI，是 “研究主导”。真正的核心是那些有数学、物理背景的研究员。他们推导公式、调整模型、观察损失曲线。
而我们这些大厂来的顶级工程师，某种程度上成了 “辅助人员”。我们的职责是构建极致的分布式计算集群、优化 GPU 利用率、搭建数据流水线，一切工程努力都是为了研究员能跑通下一次实验。
如果你渴望个人英雄主义和产品掌控权，这种落差会很痛苦。但我很享受，因为在这个新领域，我是“小学生”。我放下了 E9 的架子，重新学习如何与科学家对话，将数学理论转化为能在上万张 H100 显卡上运行的 C++/CUDA 代码。这非常刺激。
Ryan：聊聊你在 OpenAI 负责的 Codex（GitHub Copilot 的底层）吧，听说它源于一次黑客松？
Bolin：是的。OpenAI 内部早有工程师用早期模型辅助编码。一次黑客松上，我们突发奇想：如果把它封装成命令行工具会怎样？我写了个简陋的终端封装，效果惊人。你只需用英语输入“帮我把当前目录下所有 .txt 文件重命名为 .md，并去掉文件名空格”，它瞬间生成完美运行的 Python 或 Bash 脚本。
这个工具像病毒般传播开来。它证明 AI 不仅能教写代码，更能 直接替你把杂活干了。这也是我们后来决定开源 Codex 测试套件的原因，我们希望以此定义未来 AI 代码助手的评估标准。
Ryan：作为顶级系统工程师，你现在每天写代码的时间还有多少？
Bolin：这是我反思最多的一点。以前的我享受在键盘上运指如飞的快感。但现在，我昨天写的代码里，亲手敲的可能不到 10%，很多时候接近 0。
我的工作流彻底改变：打开编辑器，写下详尽的英文注释描述需求，然后让 AI 在几秒内生成数百行代码。
接着，我的角色从 “写作者” 转变为 “审阅者”。我运用二十年积累的系统工程经验，审视 AI 生成的代码是否存在内存泄漏、并发死锁风险，是否忽略了边缘用例。如果有问题，我就指出让它重写。
最让我解脱的是，AI 包揽了我曾经最讨厌的事——写单元测试和配置 CI/CD 脚本。现在我只需说“为上面的函数生成 100% 覆盖率的测试用例”，它就能生成完备的测试代码和模拟数据。这让我有大量时间思考更高维的系统架构，而非纠结语法细节。
技术老兵的终极建议：降维思考，升维打击
Ryan：年轻工程师听说 E9 不再手写代码可能会恐慌。既然 AI 能写代码，学数据结构、算法还有意义吗？
Bolin：我非常理解这种恐慌。但必须明确：深厚的技术基本功，在很长时间内依然是你最坚固的护城河。
因为当前 AI 本质上是概率模型，会产生“幻觉”，生成看似完美实则藏有致命 Bug 的代码。如果初级工程师完全依赖 AI，当线上系统崩溃，面对海量日志和复杂堆栈报错时，他将束手无策，因为他不懂底层发生了什么。
我能自信地让 AI 写 90% 的代码，正是因为我拥有那 10% 的底层掌控力。我懂 C++ 内存管理、操作系统线程调度，所以能一眼判断 AI 是否在“胡说八道”。
在这个时代，AI 是一把无限子弹的机枪。但如果你不知道瞄准哪里，甚至不会处理卡壳，这把枪也可能伤到你自己。
Ryan：在个人能力提升方面，你有什么特别建议？
Bolin：我强烈建议想提升系统深度的工程师去玩玩 CTF（夺旗赛）。在解决那些变态的底层安全漏洞时，你会被迫深入理解汇编、寄存器、网络协议字节。这种目标感强的训练，比啃教科书有效百倍。
另外，如果推荐技术书籍，我首推两本：一本关于操作系统底层，另一本关于 技术写作。
Ryan：技术写作？这听起来不“硬核”。
Bolin：这恰恰是最高级的硬核。就像我总结如何晋升 E9 时说的，当你撬动一个几百人的跨部门项目时，代码再好也没用。你需要用清晰、有煽动性、逻辑严密的技术文档，去说服不懂代码的副总裁和财务总监。
如果你只会写代码，你只是个高级工匠；但如果你能用文字构建宏大的技术愿景，并让所有人心甘情愿追随，你才是真正的技术领袖。这也是为什么在云栈社区的开发者广场中，分享清晰的技术思考与规划同样备受推崇。
发表于 昨天 21:51
|
查看: 4|
回复: 0
