OpenAI Codex 負責人：懂底層是沒被淘汰的唯一底牌，頂尖工程師的終極歸宿是“代碼審查員”

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

　　編譯 | 王啟隆

　　來源 | 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 的工程師們，好運。

　　（投稿或尋求報道：zhanghy@csdn.net）