科技巨擘升遷的真相，是去清理那些最醜陋的「技術債務堆積」。
編譯／王啟隆
來源｜https://youtu.be/hN5ZFzWFhhg
出品｜AI 科技大本營（ID：rgznai100）
在矽谷的工程師鄙視鏈中，有一群人站在金字塔的絕對頂端。他們不寫酷炫的前端，不搞花俏的產品，而是終日潛伏在作業系統的底層，與編譯器、建置系統、虛擬檔案系統纏鬥。他們存在的意義，是要確保像 Meta 這樣擁有數十億行程式碼、上萬名工程師的超級程式碼庫，在每次按下 Enter 鍵時不會徹底崩潰。
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 日曆）專案。那個年代的 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 的工程師們，好運。