OpenAI Codex 负责人：懂底层是没被淘汰的唯一底牌，顶尖工程师的终极归宿是“代码审查员”

来源：市场资讯

（来源：图灵人工智能）

您知道的人工智能干货，第一时间送达

转自AI科技大本营，仅用于学术分享，如有侵权留言删除

大厂晋升的真相，是去清理那些最丑陋的“屎山”。

编译 | 王启隆

来源 | youtu.be/hN5ZFzWFhhg

出品丨AI 科技大本营（ID：rgznai100）

在硅谷的工程师鄙视链里，有一群人是站在金字塔绝对顶端的。他们不写炫酷的前端，不搞花哨的产品，他们终日潜伏在操作系统的底层，和编译器、构建系统、虚拟文件系统死磕。他们存在的意义，是保证像 Meta 这样拥有几十亿行代码、上万名工程师的超级代码库，在每一次敲击回车时不会彻底崩溃。

Michael Bolin 就是大厂技术江湖里，真正镇守底层的“扫地僧”。

作为前 Meta 的杰出工程师（Distinguished Engineer，职级 E9，大厂技术岗的天花板），他曾主导重写了 Facebook 的 Android 构建系统，甚至因为代码库太大，硬生生在操作系统底层拦截系统调用，搞出了一个虚拟文件系统，只为了让工程师跑 git status 时电脑不会死机。

在很长一段时间里，Bolin 定义自己为“一台无情的写代码机器”。

但就是这样一个传统工程领域的顶级王者，在跳槽加入 OpenAI，成为 Codex（也就是后来 GitHub Copilot 的底层模型）的技术负责人后，他的世界观被彻底击碎了。

在最新一期《The Peterman Pod》的深度播客中，Bolin 用极其坦诚、甚至带着一丝自嘲的语气承认：“我现在几乎不手写代码了。我 80% 到 90% 的代码，都是 AI 帮我生成的。”

我们为你提炼了这场对话中最刺痛神经的几个核心论断：

• 大厂晋升的“英雄主义”陷阱： 很多高级工程师升不上去，是因为他们总想从零开始写一个完美的“玩具”，而不愿去接手那个丑陋但关系到公司命脉的遗留屎山。在 Meta 想要升到 E9，你必须是一个能干脏活累活的“政治家”。

• 文化休克：研究主导 vs 工程主导： 在 Google 和 Meta，工程师是绝对的王；但在 OpenAI，研究员（科学家）才是王，工程师只是为他们搭建算力基础设施的“辅助人员”。这种落差，让无数跳槽去 AI 实验室的大厂精英水土不服。

• 顶尖工程师的终极救赎是“写文档”： Bolin 透露，他在 Meta 升职的最关键武器根本不是写代码，而是“写出让高管和跨部门团队能看懂的技术规划”。

• AI 时代的护城河正在转移： 虽然 AI 替他写了 90% 的代码，但由于大语言模型容易陷入“幻觉”，拥有深厚的底层系统理解（如内存分配、指针、汇编），反而成了他能快速识别 AI 错误、修正大厂架构的唯一底牌。

以下是这场对谈的中文编译。

从 Firefox 插件到 Google 日历的“荒野求生”

Ryan Peterman（播客主持人，前 Instagram 软件工程师，以下简称“Ryan”）：欢迎来到本期播客。今天我们非常荣幸请到了 Michael Bolin。他是 OpenAI 开源项目 Codex 的技术负责人，也曾是 Meta 的杰出工程师（E9）。Michael，我们先从你的早期职业生涯聊起吧。我深度挖掘了你的个人网站，发现了一个你当年特别兴奋，但现在链接已经全部失效的项目——“Chickenfoot”（鸡脚）。那到底是个什么东西？

Michael Bolin（以下简称“Bolin”）：噢，天哪，这确实很有年代感了。那其实是我的硕士毕业论文项目，一个 Firefox 浏览器的扩展插件。你要知道，那是用 JavaScript 为 Firefox 编写的，这在当时可是一项绝对先锋的毕业设计。

简单来说，它是一个集成在 Firefox 侧边栏里的小型编程工具。它的核心理念是为 Web 提供“最终用户编程（End-user programming）”。它提供了一系列像 enter（输入）和 click（点击）这样的宏命令。你可以输入 enter，然后传入一个字符串参数，它就会在网页上自动寻找对应的输入框；你说 click search，它就会去点击网页上的搜索按钮。

在底层，我们构建了大量极其复杂的启发式算法（Heuristics）。它会去解析网页上的 DOM 结构，寻找“名”和“姓”这样的文本，然后定位到距离这些文本最近的文本框，最后用 JavaScript 把你的输入自动填进去。

现在回想起来，这特别有趣。因为现在很多 AI Agent（智能体）正在做的事情，简直和我们在 Chickenfoot 里做的一模一样——只不过现在它们用的是真正的自然语言大模型，而我们当年是用粗糙的 JavaScript 脚本硬生生“拼”出来的。

Ryan：所以它其实就是通过解析前端代码，提供一个交互式的控制台，让你能通过自然语言命令去操作网页？

Bolin：没错，我们利用了网页可访问性标签（Accessibility tags）、图片的 alt 文本等一切能抓取的信息。它在诸如 Craigslist 这种极其简陋的网站上运行得特别好。我还有些朋友用这个工具做了自动化脚本，甚至用来赚钱。

Ryan：后来你正式进入业界，第一站就去了 Google，而且一去就负责 Google Calendar（谷歌日历）项目。那个年代的 Google 是什么氛围？什么原因吸引了你？

Bolin：那还是 2000 年代初的事。我 90 年代刚接触互联网时，你如果想搜个东西，得同时打开五个不同的搜索引擎（如 Yahoo、Lycos 等）。我清楚地记得，在 2000 年 3 月，我室友跟我说：“嘿，斯坦福那边出了个叫 Google 的搜索引擎，好像比其他的都好用。”

我试了一下，发现它不仅搜索质量高，而且页面极其干净。在那之前，Yahoo 的首页塞满了各种眼花缭乱的广告和门户链接，而 Google 的首页就像是一片净土，非常克制。这种专注质量而非短期流量的工程文化，让我从一毕业就非常想去那里工作。

加入 Google Calendar 团队对我来说是个完美的契机。当时微软的 IE 浏览器正占据绝对统治地位，甚至他们直接砍掉了 IE 的后续开发计划。但就在这种恶劣的生态下，Google 试图通过网页端应用来打破僵局。那个年代，JavaScript 的工程质量极差，大家都觉得写前端就是“玩具代码”。但我们团队接纳了极其优秀的工程师，我们在尝试把桌面级应用的体验（比如拖拽日程、无刷新加载）搬到浏览器里。这在当时是极具开创性的。

Meta 战记（上）——在百万级代码库里“暴力拆解”构建系统

Ryan：在 Google 待了几年后，你跳槽去了当时如日中天的 Facebook（现 Meta）。我了解到你在那里是一个顶级的 JavaScript 专家，但你接手的第一个大项目，却是去重构 Android 端的构建系统（Build System）。这段故事是怎么发生的？

Bolin：当时的 Facebook 有一个非常疯狂的黑客松（Hackathon）文化。那时候公司刚刚决定：“移动端才是未来”，这成了关乎公司生死的头等大事。

有一天，一个懂 JavaScript 的朋友找到我：“嘿，我知道你很擅长 Java，你应该学学 Objective-C，然后来做移动端。现在所有想做产品的人，都必须懂移动端开发。”这对我来说是个极大的刺激，因为我压根不喜欢 Objective-C。

我最初给自己找的定位，是帮公司开发一套类似 PhoneGap 的框架（一种将网页打包成原生应用的早期技术）。我拉上了一小拨人，试图用 HTML5 来开发移动版 Facebook。但在实际推进中，这种基于网页的移动应用体验极其糟糕，性能慢得令人发指。最终，马克·扎克伯格（Mark Zuckerberg）亲自拍板，废弃了这个方案，宣布全线转回纯原生开发（Native App）。

在这个节点上，我面临一个选择：要么硬着头皮去学我不喜欢的原生语言，要么找点别的事干。

幸运的是，我找到了痛点。当时，Facebook 的 Android 团队每天都在痛苦中挣扎。对于每一个前线工程师来说，你修改了一行代码，然后点击“编译”并在模拟器里看到结果的时间（迭代周期），是决定生产力的核心指标。

但当时，Facebook 用的是一套极其陈旧的、基于 Ant（Apache 早期构建工具）的构建系统。整个构建过程没有模块化，也没有缓存。每修改一行代码，系统都要重新编译整个庞大的代码库，耗时极长。

我就想：“我懂 Java，这种底层构建的脏活累活肯定难不倒我。”我本来只是想去修几个 Bug，但我越深入，越发现这套系统的地基已经彻底烂了，必须推倒重来。

Ryan：但你们为什么没有直接用 Google 现成的工具呢？我记得那时候 Google 内部已经有了非常强大的构建系统（后来开源为 Bazel）。

Bolin：这是个绝佳的问题。确实，当时有很多人，特别是从 Google 跳槽来的人，都在说：“我们在 Google 有一套牛逼的工具，我们为什么不直接照抄过来？”

事实是，我们确实尝试过。我们甚至在内部复刻了一个微型的 Google 构建系统版本。但问题在于，Facebook 的代码库结构和 Google 完全不同。

Google 的代码库是非常规范的，每一个模块都有清晰的边界。但 Facebook 当时的 Android 代码库，是一堆充满了历史包袱的庞然大物，各种乱七八糟的资源文件（XML、图片）、极其定制化的脚本交织在一起。如果我们强行套用 Google 的那一套，我们就要重写所有的底层逻辑。

更致命的是时间线。当时是公司转型移动端的生死存亡之秋，管理层给的指令是：“我们要立刻、马上提高迭代速度！哪怕快一点点都行！”我们根本等不及花一年时间去重新搭一套完美的 Google 架构。

这就是我主导开发 Buck（Facebook 开源的构建工具）的背景。我们一开始只是用 Python 写了几个脚本，试图缓存一些中间编译结果。但随着时间推移，这种修修补补已经到了极限。于是，在一个黑客松上，我决定彻底抛弃 Python 脚本，用 Java 重新写了一套强类型、高并发的构建系统雏形。

我清楚地记得，当我把那个雏形跑起来时，编译速度直接提升了两倍。整个 Android 团队都惊呆了。他们原本对这种底层工具的重构毫不关心，但当我把编译时间从 4 分钟压到 1 分钟时，所有人都成了这套新系统的忠实信徒。

Meta 战记（下）——用重写 IDE 和拦截系统调用来对抗“规模诅咒”

Ryan：在解决了 Android 构建系统的难题后，你似乎并没有停下脚步。我看到你后来的工作轨迹，转向了更庞大的基础设施——你们开始重写 IDE（集成开发环境），甚至搞出了一个虚拟文件系统。这是怎么一回事？

Bolin：这其实是一个顺理成章的演进。当我把构建系统（Buck）做出来后，工程师们确实编译得更快了。但新的问题出现了：随着代码库的指数级膨胀，传统的 IDE 扛不住了。

我们当时用的是 Eclipse。对于一个拥有几千万行代码的大型单一代码库（Monorepo）来说，你只要用 Eclipse 打开这个项目，光是建立索引（Indexing）就要花半个小时。在此期间，你的电脑风扇会狂转，内存会被吃光，整个机器卡得像块砖头。

我们的工程师开始抱怨：“构建是快了，但我根本打不开代码啊！”

当时业界有两种声音：一种是彻底抛弃本地 IDE，把开发环境搬到云端浏览器里（Web-based IDE）；另一种是寻找一种轻量级的本地编辑器。

我们选择了一条中间路线。当时 GitHub 刚推出了 Atom 编辑器（VS Code 的前身）。Atom 是基于 Web 核心技术的，非常灵活。我们决定在 Atom 的基础上，开发一套专门针对 Facebook 巨型代码库的 IDE 插件系统，我们给它命名为 Nuclide。

我们把极其耗费性能的语言解析、自动补全、跳转定义等功能，全部剥离出来，放在远程的强大服务器上运行。本地的 Nuclide 编辑器只需要负责展示 UI 和接收用户的键盘输入。这相当于给每一个工程师配了一台看不见的“超级计算机”。

Ryan：这听起来非常巧妙。但你刚才提到了“虚拟文件系统”（Virtual File System），这又是因为什么痛点被逼出来的？

Bolin：虚拟文件系统的诞生，是为了对抗物理学定律。

你要知道，Facebook 秉持的是“单一代码库”（Monorepo）哲学。也就是全公司所有产品（Facebook、Messenger、Instagram等）的代码，全都在一个巨大的仓库里。

这就导致了一个灾难性的后果：当代码库膨胀到包含数百万个文件、几十 GB 大小时，传统的版本控制系统（比如 Git 或 Mercurial）彻底崩溃了。

想象一下这个场景：一个新员工入职，他只想修改一行前端代码。按照传统的逻辑，他必须把这几百万个文件、几十 GB 的数据完整地克隆（Clone）到自己的笔记本硬盘上。这不仅要耗费几个小时，而且他每次运行一次简单的 git status 命令，系统都要遍历这几百万个文件去检查有没有变动。这直接导致终端卡死。

面对这种“规模诅咒”，常规的优化手段已经失效了。我们必须深入到操作系统的最底层。

我们搞出了一个叫 Eden（后来演变成 Miles）的虚拟文件系统。简单来说，我们利用了 Linux 的 FUSE（Filesystem in Userspace）机制，或者 Mac 上的类似机制，拦截了操作系统的文件读取请求。

当你在笔记本上浏览代码库时，你看到的是几百万个文件的完整目录结构。但实际上，你的硬盘里根本没有这些文件。它们全是“占位符”。

只有当你真正双击打开某个文件，或者编译器需要读取某个文件时，我们的虚拟文件系统才会瞬间触发一个网络请求，从服务器上把那个特定的文件“懒加载”（Lazy load）下载下来。

这简直是魔法！通过这种按需加载的方式，原本需要几个小时的克隆时间，被压缩到了几秒钟；原本需要遍历整块硬盘的系统状态检查，变得瞬间响应。我们在操作系统的底层，骗过了所有的上层应用。

从 E8 到 E9 的“血肉之路”与晋升失败

Ryan：这太不可思议了。从构建系统到虚拟文件系统，你解决的都是大厂最硬核、最底层的生死难题。这也自然而然地引出了你职业生涯中最受关注的一段经历——你在 Meta 从 Principal Engineer（E8，首席工程师）晋升到 Distinguished Engineer（E9，杰出工程师）的过程。

很多在大厂挣扎的工程师，都面临着晋升难的问题。而从 E8 到 E9，这几乎是一条“血肉之路”。你能分享一下这背后的故事吗？

Bolin：这是一段极其痛苦，但也让我彻底蜕变的经历。

很多人对高级工程师有一种误解。他们觉得，只要我是一个“超级码农”（10x Engineer），只要我写的代码比谁都快、比谁都好，我就能一路晋升到顶点。

在早期的职级（从初级到高级）里，这确实是行得通的。但当你跨越了 Staff（E6）甚至到了 Principal（E8）之后，“纯写代码”反而会成为你晋升的最大毒药。

当时我刚完成 Nuclide 和早期底层工具的构建，我满心以为自己很快就能升到 E9。但我提交的晋升申请被无情地驳回了。

我的第一反应是极度的愤怒和不解：“我难道不是公司里最懂这些底层架构的人吗？我难道不是一个人顶十个人的产出吗？为什么不给我升职？”

但我后来冷静下来，和几位资深的 E9、E10 大佬进行了一次长谈。他们一针见血地指出了我的问题：我陷入了“英雄主义陷阱”。

在那段时间里，我习惯于发现一个问题，然后闭门造车，用极高的技术水平从零写一个全新的工具，然后跑去告诉大家：“看，我造了个更好的轮子，你们都来用吧！”

但这是一种极其傲慢的做法。当公司规模达到几千名工程师时，你强行推行一个新工具，意味着你要打破所有人现有的工作流。你会遇到极大的阻力。

真正能在 E9 级别产生影响力的，不是“造新轮子”，而是“解决那些无人认领的、极其丑陋的系统性难题，并带着所有人一起走”。

Ryan：也就是说，你需要从一个纯粹的技术极客，转变成一个具有极强政治手腕和布道能力的技术领袖？

Bolin：完全正确。那次晋升失败后，我收起了自己“手撸代码”的骄傲。我开始把大量的精力放在了“非标自动化”（Non-standard automation）和跨部门协调上。

就像刚才提到的虚拟文件系统 Eden。这个项目的阻力极其庞大，因为不仅需要修改底层客户端，还需要后端服务器的全力配合，更需要改变全公司数千人的开发习惯。

我花了数月的时间，不再是写 C++ 或 Java，而是疯狂地写文档（Tech Specs）、写战略规划。我必须在文档里向高管证明，为什么这件极其冒险的事情是非做不可的；我必须去游说后端的存储团队，让他们相信为我们专门开发一套 API 是值得的；我必须去安抚一线的业务工程师，承诺新系统上线时不会让他们丢掉数据。

这其实就是在玩一场“拼凑积分”的游戏。你需要找到一个公司级别的痛点，把分散在各个团队的资源像拼图一样拼凑起来，最终打赢这场战役。

当我最终带领团队，把那个极其丑陋但极其庞大、牵扯到无数利益的遗留屎山彻底清理干净时，我的 E9 晋升几乎是水到渠成的。那是水到渠成的结果，而不是我强行索要来的。

加入 OpenAI，“研究主导”的文化休克

Ryan：在 Meta 达到了工程师的荣誉顶峰后，你做出了一个让很多人意外的决定——离开这家你奋斗了 11 年、极其擅长其技术栈的巨头，转而加入了当时规模还远没有今天这么大的 OpenAI。是什么驱使你做出这个决定的？

Bolin：在 Meta 的最后一年，我其实陷入了某种程度的职业倦怠（Burnout）。我在底层架构这个领域待了太久，我已经清楚地看到了天花板。所有的优化都是边际收益递减的：我再花一年时间，可能也就是把某个系统的性能提升个 5%。这种修修补补的工作，让我失去了当初那种改变世界的兴奋感。

就在那个时候，也就是 2023 年底，大语言模型（LLM）的浪潮彻底爆发了。我开始在业余时间疯狂地阅读关于 Transformer、注意力机制（Attention Mechanism）的论文。我突然意识到，这是一种全新维度的计算范式。

我觉得，如果我错过了这班车，我这辈子的技术生涯可能就止步于此了。刚好 OpenAI 在招募懂大规模工程底层的资深人员，我就毫不犹豫地投了简历。

Ryan：当你从一个传统互联网巨头，跨入一家处于浪潮之巅的 AI 实验室时，最大的冲击是什么？

Bolin：简直是天翻地覆的“文化休克”（Culture Shock）。

在像 Meta、Google 这样的传统大厂，他们的核心文化是“工程主导”（Engineering-led）。这意味着什么？这意味着软件工程师（SWE）是公司的核心资产。产品经理提出需求，工程师决定架构、排期，最后把代码写出来上线。所有的光环、资源和晋升通道，都是围绕着工程师建立的。

但当你踏入 OpenAI 的那一刻，你会立刻感受到一种截然不同的空气——这里是“研究主导”（Research-led）的。

在这里，真正的核心王牌是那些拥有数学、物理学背景的研究员（Scientists/Researchers）。他们每天的工作是推导公式、调整模型结构、观察 loss 曲线（损失函数曲线）。

而我们这些有着光鲜履历的大厂顶级工程师，在某种程度上，变成了“辅助人员”。

我们的职责不再是决定产品的走向，而是像后勤部队一样，拼尽全力去构建最极致的分布式计算集群、优化 GPU 的显存利用率、搭建数据清洗的流水线。我们所做的一切工程努力，都是为了让那些研究员能够跑通下一次实验。

如果你是一个极度渴望个人英雄主义、渴望掌控产品的工程师，这种落差会让你非常痛苦。但我个人非常享受这种状态。因为在这个全新的领域里，我已经是一个“小学生”了。我放下了 E9 的架子，重新开始学习如何与科学家们对话，如何把那些天马行空的数学理论，转化为可以在成千上万张 H100 显卡上稳定运行的 C++ 和 CUDA 代码。这太刺激了。

Ryan：这就不得不聊到你在 OpenAI 负责的核心项目——Codex（也就是 GitHub Copilot 的底层大脑）了。我听说 Codex 最初其实脱胎于一场黑客松？

Bolin：是的，那是一个极其疯狂的周末。

其实 OpenAI 内部一直有工程师在使用早期的代码生成模型来辅助工作。但在一次内部的黑客松上，我们几个人突发奇想：“如果我们把这个模型封装成一个可以在命令行（CLI）直接调用的工具，会发生什么？”

我花了很短的时间，写了一个简陋的终端封装。结果跑出来的效果惊掉了所有人的下巴。你只需要在终端里用英语输入“帮我把当前目录下所有扩展名为 .txt 的文件重命名为 .md，并且去掉文件名里的空格”，它瞬间就生成了一段完美运行的 Python 或 Bash 脚本。

这个工具立刻在公司内部像病毒一样传播开来。它证明了一件事：AI 不仅仅能教你写代码，它能直接替你把杂活干了。

这也是后来我们决定将 Codex 的测试套件（Harness）完全开源的重要原因。我们希望让整个开源社区看到，这不是魔术，而是实实在在的工程标准。我们试图通过这种方式，去定义未来 AI 代码助手的评估标准。

Ryan：你作为一个顶级的底层系统工程师，现在每天写代码的时间还有多少？

Bolin：这个问题问到了点子上，也是我最近反思最多的一点。

以前的我，就像我说的，是一台写代码的机器。我极其享受那种在键盘上运指如飞、一行行敲出精妙逻辑的快感。

但现在，如果你问我：“你昨天写的代码里，有多少是你亲手敲进去的？”我会非常坦诚地告诉你：“可能连 10% 都不到。很多时候，这个数字接近于 0。”

我每天的工作流已经彻底改变了。我现在做的事情是：打开编辑器，写下一段极其详尽的英文注释（Prompt），描述我需要实现的数据结构、接口逻辑和边界条件。然后，我按下快捷键，看着 AI 在几秒钟内把几百行代码“吐”出来。

接着，我的角色从一个“写作者”（Writer），变成了一个“审阅者”（Reviewer）。

我运用我过去二十年积累的系统工程经验，去审视 AI 生成的代码有没有内存泄漏的风险，有没有并发死锁的隐患，有没有忽略某个边缘测试用例。如果有，我就指出问题，让它重新生成。

最让我感到解脱的是，AI 包揽了我曾经最讨厌的事情——写单元测试（Unit Tests）和配置 CI/CD 脚本。现在，我只需要说一句：“为上面的函数生成 100% 覆盖率的测试用例”，它就能生成极其完备的测试代码，甚至还能自动生成伪造的 mock 数据。

这让我有大量的时间去思考更高维度的系统架构设计，而不是在语法细节里浪费生命。

技术老兵的终极建议：降维思考，升维打击

Ryan：这真是让人感到震撼。对于那些还在学校，或者刚刚进入职场的年轻工程师来说，听到一个 E9 大佬说自己不再手写代码了，他们可能会感到恐慌：“既然 AI 都能写代码了，那我拼命学数据结构、学算法还有什么意义？”你会给他们什么建议？

Bolin：我非常理解这种恐慌。但我必须明确一点：深厚的技术基本功（Deep Technical Skills），在很长一段时间内依然是你最坚固的护城河。

为什么？因为现在的 AI，本质上还是一个基于概率的模型。它会产生幻觉，它会生成看似完美实则藏着致命 Bug 的代码。

如果一个初级工程师完全依赖 AI，当系统在线上崩溃，面对几千兆的日志和乱码般的堆栈报错时，他将束手无策。他根本不知道底层发生了什么。

而我能如此自信地依赖 AI 替我写 90% 的代码，正是因为我有那 10% 的底层掌控力。我懂 C++ 内存分配的底层原理，我懂操作系统的线程调度，所以我能在一眼扫过 AI 生成的代码时，瞬间判断出它是否在“胡说八道”。

在这个时代，AI 是你手里的一把无限子弹的机枪。但如果你不知道该瞄准哪里，甚至不知道怎么处理卡壳，这把枪也会变成杀死你自己的武器。

Ryan：在提升个人能力方面，你有哪些特别的经验可以分享？

Bolin：我强烈建议所有想提升系统深度的工程师，去玩一玩 CTF（Capture The Flag，网络安全夺旗赛）。

这是我个人的一个小秘密。在解决那些极其变态的底层安全漏洞时，你会被迫去深入理解汇编语言、寄存器的工作原理、网络协议的每一个字节。这种带有极强目标感、像解谜游戏一样的训练方式，比你干巴巴地啃教科书要有效一百倍。

另外，如果非要推荐技术书籍，我首推两本。一本是关于操作系统底层的（如经典恐龙书），另一本则是关于技术写作的。

Ryan：技术写作？这听起来不太“硬核”。

Bolin：这恰恰是最高级的硬核。

就像我在总结如何晋升 E9 时说的，当你试图撬动一个几百人的跨部门大项目时，你写的代码再好也没有用。你需要用一种极其清晰、有煽动性、逻辑严密的商业/技术文档，去说服那些根本不懂代码的副总裁和财务总监。

如果你只会写代码，你充其量是一个高级工匠；但如果你能用文字构建起一个宏大的技术愿景，并让所有人心甘情愿地追随你，你才是真正的技术领袖。

Ryan：非常感谢你，Michael。你为我们展现了一个从传统软件时代向 AI 时代跨越的极其精彩的个人缩影。

Bolin：谢谢你的邀请。很高兴能在这里把这些踩过的坑、流过的血，分享给大家。祝所有依然在深夜里 debug 的工程师们，好运。