OpenAI Codex 技術負責人 Michael Bolin 就是典型的後者。從 Google Calendar 到 Facebook 的 Buck 構建系統、再到虛擬檔案系統 Eden，以及如今 OpenAI 的 Codex，這位工程師的職涯軌跡，幾乎貫穿了過去十多年軟體工程基礎設施的關鍵演進。
在最近一期 The Developing Dev 播客中，主持人 Ryan 與 Michael Bolin 展開了一場橫跨 20 年工程實踐的深度對話。在這次訪談中，他回顧了自己從「寫 JavaScript 的工程師」到主導開發工具體系的轉變過程，也坦誠講述了其中的判斷失誤、能力邊界與成長代價。更重要的是，他試圖回答一個當下所有工程師都在面對的問題：在 AI 正在重塑開發方式的時代，哪些能力依然值得堅持，哪些又必須被重新理解。
在他看來，真正拉開差距的，從來不是寫程式碼的速度，而是你選擇解決什麼問題，以及你如何定義「更好的系統」。
其中幾個值得關注的關鍵觀點包括：
很多工程突破，源於對「現狀的不滿」和快速動手驗證 工程師的影響力，最終取決於是否解決「公司真正關心的問題」 AI 編程時代，80%-90% 的程式碼已可由模型生成，但關鍵部分仍需人類把控 相比寫程式碼，提出正確問題的能力正在變得更重要 長期來看，編程智能體的執行將更多遷移到雲端，而非本地 AI 看似什麼都會，但理解系統更底層怎麼工作的能力現階段仍然重要
以下是本次訪談全部內容的翻譯，InfoQ 在不改變原意的前提下進行了整理編輯。
從工程師到工具創造者：
一條被問題驅動的成長路徑
Ryan： 我深入研究了一下你的網站，發現所有內容都有很多可挖掘的資訊。其中有個項目當初傾注了你的很多心血，但現在所有連結都失效了，我已經完全找不到相關資料。所以，Chickenfoot 究竟是什麼？
Michael： 這事說來話長了。那是我的碩士畢業設計項目，是個 Firefox 擴充套件項目，也是當時極少數基於 JavaScript 為 Firefox 開發的畢業設計。它其實是個嵌在 Firefox 側邊欄上的小型編程工具，類似於即時解釋器，由終端使用者隨時調用，核心理念就是實現 Web 編程。
這裡頭包含著「enter」、「click」等函式。在調用相應函式後，使用者需要傳遞字串參數，再由它自動定位輸入框；比如輸入「click search」，即可執行點擊操作。這個項目的主要工作量是構建底層啟發式演算法：在輸入「enter first name」時，它會識別「first name」中的關鍵詞，定位最近的文字方塊，再透過 JS 將其轉為輸入內容。
現在回想起來還是挺有意思。我們當時做的很多工作，跟當前 AI 編程助手的原理其實很相似——只不過現在真正實現了自然語言處理，而不用再依靠當初的 JS 替代方案了。
Ryan： 有意思。所以它的作用就是解析前端介面，透過互動介面將使用者下達的指令描述轉化為相應操作。
Michael： 沒錯，我們會使用無障礙標籤和切換等技術把文字轉為功能，而且這套方案在 Craigslist 上效果特別好——畢竟那也是最簡單的網站之一。而且我有個朋友真就用這款工具自動處理任務，甚至靠這種效率優勢賺到了真金白銀，確實非常有趣。
Ryan： 你剛剛進入行業時就加入了谷歌，並帶著巨大的熱情參與到谷歌日曆項目當中。是什麼吸引你加入了谷歌？那段經歷給你留下了什麼回憶？
Michael： 我是在九十年代那會接觸網際網路的。記得當初瀏覽網頁時，經常得在一大堆搜尋引擎之間來回切換，才能找到自己需要的資訊。我現在還清楚記得，2000 年 3 月室友告訴我：「嘿，有款新搜尋引擎看著不錯哦。」它當時還掛在史丹佛大學的網域下。
我當時就發現谷歌搜尋確實更勝一籌。而在仔細研究之後，我發現它跟其他搜尋引擎的介面簡直天壤之別——雅虎介面雜亂不堪，而谷歌當時就刻意追求極簡設計，明顯原則層面的針對性更強。後來大家也就都知道了，許多公司都開始效仿這種風格。接著我身邊開始有人去谷歌工作，我心想：可以啊，他們招聘的都是一幫頂尖人才。
我真的很希望能跟那些人共事，他們確實非常非常了解 Web。相比之下，當時的微軟就根本不夠了解，並且宣布叫停 IE 專案。我當時覺得這可是通往 Web 的門戶，微軟卻打算拆掉它。而谷歌顯然更具 Web 前瞻性，再加上專案的工程質量和由此帶來的巨大影響，最終讓谷歌成為我畢業時最嚮往的去處。
Ryan： 當時谷歌的文化氛圍怎麼樣？記你在文章裡提到過，谷歌在產品和基礎設施兩條業務線之間也存在分歧。
Michael： 很多公司，尤其是發展到一定規模之後，都會有一個很明顯的傾向：創始團隊最早擅長、也最成功的那一塊業務，往往會被長期「偏愛」。
在谷歌，這一點也很典型。無論是資訊檢索，還是底層基礎設施，都是支撐公司成長的核心能力，也自然在內部擁有更高的地位。
而我當初之所以被谷歌吸引，很大程度上是因為他們推出了像 Gmail 這樣的產品。這些產品當時看起來更偏「面向使用者體驗」，方向也相對開放、有想象空間。但在公司內部，它們的地位其實始終無法與搜尋這樣的核心業務相比。
比如我當時參與的 Google Calendar，主要還是面向消費級市場，雖然同時也有一定的企業銷售場景。但從業務角度看，它並不是公司的營收核心。某種程度上，我們更像是在做一個「服務支援型」的產品團隊，而不是直接創造收入的那一類業務。在當時，大致就是這樣一種情況。
Ryan： 你最還是離開了谷歌。從發過的貼文來看，在谷歌供職的時光也是段苦樂參半的經歷。那是什麼促使你選擇離開的？
Michael： 我在谷歌前後工作了四年。說實話，讓我選擇離開的關鍵因素應該就是個人規劃。首先，工作四年之後我手裡有閒錢了，可以考慮的選擇更多。更重要的是，當時我發現自己有個壞習慣：總喜歡在那些對我個人很重要、但對谷歌未必重要的項目上傾注全部精力。比如我負責的日曆項目就屬於這種情況。
後來我又轉去做效率工具 Google Tasks，屬於日曆下的一個小小功能模組。使用者量較日曆一下子小了兩個量級，但我還是對此充滿熱情。同樣讓我著迷的還有 JS 基礎設施和 Closure 工具套件。這些專案當然也很精彩，我也享受開發的過程並為自己的付出而感到自豪——我甚至還專門為 Closure 寫了本書，可以說是幹勁十足。但從職業發展的角度看，這確實不是最明智的選擇，對吧？
我當時就想，我明明也在處理高質量的工程問題，但獲得認可的怎麼永遠是別人？我這麼拼命到底有什麼意思？可能真的是選擇永遠大於努力吧，所以我意識到或許該換條路徑去嘗試，要麼專心搞自己熱愛的事業、要麼投身於公司最看重的方向。
Ryan： 後來你又迴歸科技大廠，加入了當時的 Facebook。我瞭解到當時你已經是 JS 領域的專家，而在 Meta 的首個重大專案就是為 Android 程式碼庫構建工具鏈。能不能講講你參與這個項目的幕後故事？
Michael： 當時公司內部有一個非常明確的方向：Facebook 要做手機。
雖然此前已經有過一些失敗的嘗試，但這一次的氛圍明顯不同，大家普遍覺得「這次是真的要做成」。公司的計劃是與 HTC 合作，對 Android 進行定製化改造，在此基礎上做一此新的嘗試。
對剛加入公司的我來說，這件事非常令人興奮。我之前做過不少 Java 相關的工作——雖然整體更偏 JavaScript，但這個項目也讓我有機會更多接觸 Java。
當時公司內部還有一個叫「Face Web」的方向，本質上是希望把 HTML5 和 Facebook 的 Web 體驗直接搬到手機上。但很快大家就發現，這條路行不通。與此同時，有一點變得越來越清晰：移動端將成為決定公司成敗的關鍵戰場。
也正是在這個時候，有個朋友跟我說：「我知道你特別喜歡 JS，但現在最好多拿點精力鑽研鑽研 Java 或者 Objective-C，否則就往產品經理轉。」現在回頭看，這確實是一個非常重要、也非常及時的建議。
我當時想：我實在不喜歡 Objective-C，還是 Java 好。就這樣，我加入了項目。當時我們的時間非常緊迫，因為跟其他絕大多數項目不一樣，這次是有硬性截止日期的。而其他項目正常完成後就能發布，這個則需要按時把成果提交給 HTC，以保證給他們留夠時間在 3 月 1 日左右把程式碼燒錄到手機裡。
所以整個過程就是一場狂奔，而初始 Android 程式碼庫其實就是從谷歌僱用的外包商那直接拿過來的。大廠其實都差不多，Facebook 也不想親自開發原生應用，所以就付錢找人代工。結果應用上線後，對方甩手不管了，把程式碼直接一塞。其實谷歌本該把之前那堆破玩意直接丟了，但卻一直留在手裡——我們收到的就是這麼堆玩意，而對迭代速度的要求還相當高。
相信做過長期 Web 開發工作的朋友們早就習慣了先編輯再刷新的操作流程。但 Android 的構建系統就……特別粗糙。那些 Ant 之類的構建工具根本就沒法模組化，只能想辦法把它們硬生生拆分成四、五個模組。
每次開發都痛苦不堪。我當時就想：必須重組這套構建系統。我也用 Java 幹過不少活，人家不至於這麼慢，不至於在迭代構建的時候這麼卡頓。Facebook 有駭客松文化，所以我決定組織一輪駭客松，直接搞套新的構建系統。就照著谷歌構建系統的風格，爭取乾脆利落搞定。
其實那時候公司裡還有套叫 FB Build 的構建系統，本身也是谷歌構建系統的一種「山寨版」。它是用 Python 寫的，只支援 C 語言；但當時我就想，要麼把這東西修好，要麼躺平擺爛……或者直接辭職算了。畢竟修舊專案最煩了。
Ryan： 要是沒修好，你會辭職嗎？
Michael： 至少會申請換個項目，或者找到讓自己快樂的方式，這樣才能每天開心來上班。我來上班就是想寫程式碼、把事情做好，儘可能把自己的能力發揮出來。
說來也挺有意思的。後來回想起來，我還是挺佩服當時周圍那些人的——幾乎所有人都告訴我，我正在做的這件事是個很糟糕的主意。基本上所有人都不看好，除了一個人。
當時我擔任的是資深 Android 工程師，沒有人真正阻止我。大家會表達反對，但不會直接說「不行」。這一點和我在谷歌時的感受不太一樣——在谷歌，很多事情是會被明確否決的。
所以我就順著這個方向繼續做下去了。很快，我們就做出了一個明顯更好的版本——性能大概提升了一倍左右。結果一出來，大家的態度也隨之轉變了。很多人開始意識到：「好吧，這個方向確實更好，那我們就按這個來吧。」
Ryan： 我發現大廠有種慣性，就是沒人想去碰那些堆積如山的不利因素。其他很多工程師都注意到了同樣的問題，但只要覺得還有辦法能解決，就懶得另起個新項目。況且谷歌那邊還有競爭產品，這邊可能根本贏不了。那是什麼讓你堅信自己的項目能擊敗對手，成為市場的優先選項？
Michael： 這個主要有幾點吧。首先如我所說，我也做過其他 Java 專案，所以覺得原本的構建工具不應該這麼慢。或者說以軟體工程師的經驗來看，這種底層實現不應該如此低效。實際上大部分反對意見都基於僵化的邏輯：如果偏離標準方案，我們將失去標準支援。或者說，萬一下週標準性能提升了 100 倍，新方案卻沒法繼承，又該怎麼辦？
仔細想想這很可笑，畢竟 Facebook 的工程師們自己也搞過自研 PHP 虛擬機器和語言，也明明曾經擁抱過創新。不知道為什麼這次就例外了。我想說的是，當時整個移動端專案都在摸著石頭過河，我心裡充滿了焦慮、還有嚴苛的時間壓力。
高層人員似乎要把這個項目當作科學實驗來搞，但問題是我們面臨著硬性截止期限。但這樣真能最大程度利用好我們的時間嗎？好在最終還是成功了。另外我當時還刻意淡化了項目的基礎設施性質，只強調「要為 Android 打造構建系統」，可千萬不敢暴露太多的業務擴張野心。
我沒打算動別人的項目蛋糕，因為這種事肯定會引發更多摩擦。所以在設計時，就考慮到讓它支援更多團隊，而且從不強推。直到大概一年之後，iOS 團隊主動過來問「我們的構建系統太爛了，能合作一起搞 Buck 嗎？」我當場回應：「當然可以，來吧朋友。」
Ryan： 這點很有意思——你剛入職時缺乏公信力，畢竟新人都要經歷這個過程。後面你為了推進自己的項目，就得爭取更多人的支援。而所有人都說別這麼幹，你得說服他們，讓他們相信這才是正確的方向。那你是憑什麼在自己缺少信譽的條件下推動這種改變的？
Michael： 我其實是取了個巧。當時我有個同事 John Perlow，他也是資深 Android 工程師而且同样是谷歌出身，他當時說「沒錯，你就該這麼幹，趁還沒人反對趕緊行動。」他還提到，「要是搞定了我就支援你。」有了這樣一位早期支持者加上高產程式設計師，我的開發週期還真就變快了。
他算是最早給予我肯定的人之一，幫了我很大的忙。但我也得承認自己當時犯過大錯。你提到缺乏公信力——我剛從谷歌跳槽過來的時候，還以為這裡聚集的都是貝爾實驗室的精英，純純的頂尖人才。結果到了 Facebook 我才發現，這幫人不就是大學畢業生嗎……他們懂什麼技術？
但隨著犯錯，我逐漸對他們心生敬意。比如我在講谷歌那邊是怎麼做事時，他們常講「我們根本不在乎」——而且多數情況下，他們還真是對的。沒錯，在某些地方行之有效的辦法，在其他地方可未必同樣奏效。
Ryan： 最後還有件事想問，你們開發的工具性能比同類方案高出好幾倍。這種技術直覺是怎麼形成的？你做了哪些關鍵設計，才讓它這麼高效？
Michael： 我覺得最關鍵的一點，是我當時真的坐下來，把谷歌那套工具的實現邏輯從頭到尾梳理了一遍：它到底在做什麼？問題出在哪裡？
很快我就發現，它有一個很大的問題：只要有任何改動，它就會從頭開始全部重新構建。這也是它速度慢的根本原因，尤其是在增量構建的場景下，性能非常差。
於是我開始往更底層去拆：到底哪些東西依賴哪些？哪些步驟其實是不需要重複執行的？這裡面確實有一些複雜點，比如 Android 的資源處理，本身就比較特殊，邏輯也很複雜。正因為複雜，系統一開始採取了一個「簡單粗暴」的策略：一旦有變化，就全部清空、重來一遍。
但當我真正深入進去之後發現，其實是可以優化的——如果某些輸入沒有發生變化，那對應步驟的結果完全可以緩存下來，不需要重複執行。一旦引入這種緩存機制，整體速度就明顯提升了。
另外還有一個問題是模組化。當時系統基本只支援四個模組，一旦有人想新增模組，就需要寫大概 200 行 XML 的 ANT 構建腳本，而且這些配置幾乎沒人真正理解。結果就是，沒有人願意去做模組拆分——因為一旦做了，你就得負責維護那一堆複雜配置。
而 Buck 做的一件很重要的事情，就是把「新增模組」這件事變得非常簡單。於是，大家開始更願意拆分模組，模組數量也隨之增加。模組變多之後，構建就可以更細粒度地增量執行，整體效率也進一步提升。
所以從本質上來說，這不僅僅是一次技術優化，更是一種思維方式的改變。
Ryan： 說白了就是減少重複勞動。
Michael： 就是這樣。
「選對問題」：
重構 IDE 和虛擬檔案系統
Ryan： 在解決了 Android 構建方面的問題後，你又轉向了公司裡的其他方向。我注意到你開始更多地參與 IDE 相關的工作。當時你在 IDE 領域看到了什麼問題，促使你想深入去做這方面的事情？
Michael： 在做完 Buck 之後，我短暫去做了一段時間 iOS Messenger 的開發。當時我想的是：Android 已經做過了，不如拓展一下，試試別的方向。雖然說實話，我一直都不太喜歡 iOS 開發——後來也還是沒喜歡上。
很多人可能不知道，Objective-C 早期有一套機制叫 ARC（自動引用計數）。現在這些事情基本都由編譯器自動處理了，但在更早的時候，開發者是需要手動管理引用計數的。比如每建立一個物件、每增加一次引用，都要自己寫程式碼去維護。這種程式碼現在很多人都沒見過，但當時透過收購接手的 iOS Messenger 程式碼非常老，還是用這種方式寫的，維護起來非常痛苦。
如果是現在，也許可以用 Codex 之類的工具幫忙清理這些程式碼，但在當時，我們只能硬著頭皮改。再加上 Xcode 本身的使用體驗也讓我不太適應，比如標頭檔案和實現檔案分離這種設計，我一直都不太喜歡。
另外，從更巨集觀的角度看，無論是 Android 還是 iOS，Facebook 的應用規模始終是最大的。我們基本是把所有功能都塞進一個 App 裡統一發布。這和 Google 的策略不一樣——他們會拆成 Drive、Sheets 等多個應用，而且因為他們自己掌控平台，可以在系統裡預裝一整套應用。
這種差異帶來的結果是：Facebook 總是比其他公司更早撞上移動開發工具的規模瓶頸。
這對開發來說是很痛苦的，但從開發工具的角度看，其實也很有意思——因為我們被迫去解決一些別人還沒遇到的問題，而且這些問題不是「研究專案」，而是直接影響業務的。Xcode 的問題也是類似。我們當時和 Apple 溝通過，反饋是：「Xcode 在我們這個規模下已經不太能支撐了。」但他們的回應是：「那你們的專案就不該這麼大，應該拆小一點。」在這種情況下，自研工具就變得有一定合理性了。
當時我的思路也很直接：IDE 本質上在做什麼？無非是和編譯器（比如 Clang）以及語言服務打交道。那麼我們完全可以在這之上做一層更好用的「外殼」。
而且當時公司在版本控制上也開始從 Git 轉向 Mercurial，我就意識到，主流 IDE 不太可能原生支援這些定製需求。再加上我們已經在使用 Buck 作為構建系統，這些都是高度定製化的內部工具，Xcode 不可能很好地支援這些「Facebook 特有」的工作流。所以，從整體來看，投入精力去打造一套更適合我們的開發體驗，是一件說得通的事情。
相比之下，我在 Android 這邊就沒有類似的動力，因為 IntelliJ 本身已經做得很好，而且我們也已經找到了一套可以支撐大規模開發的使用方式。但在 iOS 上，Xcode 在當時確實更難用一些。
Ryan： 所以當時一方面是 Xcode 不行，不滿足你們的需求；另一方面公司裡其實還有另一套 IDE，是另一個團隊在做的，對吧？我記得好像是一個 Web IDE？
Michael： 對，是一個 Web IDE（笑）。我不是在笑這個方向本身，這個方向其實沒問題。問題在於，它是基於一個已經被放棄的 Google 開源專案構建的，而且這個專案是用 GWT（Google Web Toolkit）寫的——也就是你用 Java 寫程式碼，然後自動生成 JavaScript。
我當時其實嘗試過在他們的基礎上繼續做，也試圖先建立一些「信用」，甚至還幫他們優化了一些構建速度。
但後來我又回到了一個熟悉的判斷方式：看迭代速度、看技術棧本身。然後我就發現——這個專案本身是建立在一個已經被廢棄的開源專案上，而且還用的是 GWT 這種技術。與此同時，我們公司已經是 React 的發源地了。
那問題就來了：我們為什麼不讓開發工具構建在我們自己最擅長、也最認可的技術棧之上？
我當時的第一反應是：你們這條路其實選錯了。於是我就又做了一件和之前做 Buck 很像的事——我自己起了一個新專案。不過我當時的策略是一樣的：不正麵衝突，不試圖「接管一切」。我只是說：「我在這邊做一個新的編輯器，但我們只先聚焦 iOS 場景。」
Ryan： 你是在刻意避免摩擦。但當時那個 Web IDE 已經有很多使用者了吧？
Michael： 沒錯，大概有上千個工程師在用。
Ryan： 但最後公司還是選擇了你這條路線（後來變成 Nucleide）。你當時幾乎沒有使用者，為什麼最後會選你？
Michael： 我覺得主要有兩個原因。
第一，是技術路線本身。我當時強調的一點是：我們做的是一個桌面應用（desktop IDE），而不是 Web IDE。因為如果你真的想替代 Xcode，開發者一定會希望：能直接連接模擬器、能插手機除錯、能直接操作本地環境。理論上 Web 也可以做這些，但成本會高很多、複雜很多。
第二，是「歷史信用」。之前 Buck 做成了，所以大家願意再賭一次。簡單說就是：「上一個你做成了，那這次也可以再試試。」
Ryan： 看起來這段經歷加上你在工作中的其他表現，後來讓你晉升到了 E8——相當於業內所謂的首席工程師（Principal Engineer）了。當時你是什麼感受？
Michael： 我當時自然非常激動，但更重要的是一種「對齊感」。在 Google 的時候，我其實一直有點不太在節奏上——不只是技術上，而是我做的事情，和公司真正重視的方向之間，有一些偏差。
到了 Facebook，這次晉升對我來說，其實是一種確認：我不僅在技術上成長了，也開始更理解一件事——什麼樣的工作，是既重要、又符合公司方向的。這種理解本身，和技術能力一樣重要，甚至更重要。
Ryan： 我記得 Nucleide 是開源的，Buck 好像也是吧？那選擇開源的初衷是什麼？
Michael： 沒錯。相比之下，Buck 的開源更有代表性。Nucleide 在外部其實沒有特別流行起來。
我覺得這類公司本身從開源里受益太多了，所以會有一種想法：如果這個東西不是我們的「核心護城河」，那不如分享出來。像我職業生涯里做的一些東西，包括 Codex，也都是類似的思路。即使沒有人直接用你的工具，把實現方式公開出來，作為參考，對別人來說也是有價值的。
當然，在更理想的情況下，你還能獲得外部貢獻，比如有人提 PR、修 bug，這些都很有幫助。我記得 Uber、Airbnb 後來都用過 Buck。
某種意義上也挺自然的——Facebook 是規模最大的應用之一，所以很多問題我們會最先遇到；然後下一波公司開始遇到這些問題，就會來看我們是怎麼解決的。
另外一個有意思的點是，Google 內部其實用的是 Blaze，對外是 Basil。我們當時也會想，如果我們把 Buck 開源，是不是能在某種程度上「倒逼」他們開放更多東西。後來他們確實也做了一些開放，雖然不完全是因為我們，但多少也有點推動作用。
還有一個現實因素是招聘。開源也是在對外展示：我們在做什麼，我們擅長什麼。如果你想在這個領域做最前沿的事情，這裡就是你該來的地方。
Ryan： 那麼開源的決定是自下而上的嗎？是工程師們主動提議的，還是管理層在認可了價值之後推動的？你們有專門的內部政策檔案嗎？
Michael： 好像沒有這樣的檔案，但你講的兩種情況應該都有。比如像 React 和 PyTorch 這類典型的成功案例，它們就為公司創造了巨大的價值。但還有另外一些長期專案，在經濟狀況比較好的時候沒什麼爭議，可隨著巨集觀經濟環境變差，管理者也會抱怨工程師們在開源上投入了太多精力。
整體來說，大部分開源專案都是自下而上推動的，通常不會遇到太多阻力。還能順帶做幾場技術分享、寫幾篇部落格，這些內容其實是有長期價值的，對招聘也很有幫助，而且生命週期比很多人想象的要長。
Ryan： 既然已經晉升到了 E8，我猜你心裡的期望值也隨之提升了吧。那現在是不是該去找個跟 E8 職級匹配的難題了？升職之後，你做了什麼？
Michael： 哈哈，那时有點自不量力了。當時我想要解決 Web 載入速度的問題——這確實是個大挑戰，那會 facebook.com 的載入速度實在不理想，架構有些陳舊。但這個問題太大了，而我其實並沒有多少經驗。Facebook 負責 Web 的團隊成員大多已經在這個方向深耕了很多年，而我之前主要在做移動端和開發工具，所以並不熟悉這個領域。
我記得當時我和另外一位同事坐下來，打算根據原始碼編譯 V8 引擎，看看能不能優化 JS 生成機制使其更適配 V8。我們盲目嘗試了各種方法，最後全都無果而終。
現在回頭想想，不同的人適合不同類型的問題。我更擅長從零開始需要編寫大量程式碼的專案，而當時這個問題更側重於資料分析、跨團隊溝通和協調——這實在不是我的強項。
Ryan： 你提到職業生涯中的這個階段屬於「英雄之旅」，這個詞具體是指什麼？
Michael： 說來慚愧，這是指有些工程師總抱有「有誰能解決這個技術難題就好了」的幻想，而這份期待引發了我的自我膨脹。許多工程師都覺得，這個工程難題存在太久了，怎麼就沒人管呢？而我的想法也很簡單：JS 嘛，我最熟悉。於是就這麼投身進去了。
但我沒能搞定，徹底失敗了。回想起來，我覺得這是個重要的教訓，而且我至少還是重新總結一次：雖然我確實能解決很多問題，但真正讓我樂在其中、且能出色完成的事情其實是少數。我當然還會嘗試逐步拓展其他領域，但從結果看我還是應該專注於真正熱愛的事物，我不可能把事事都做到最好。
我覺得大家都能明白這個道理，也應該坦然接受自己的侷限性。
Ryan： 那你後來是怎麼找到真正符合 E8 級別的問題的？接下來發生了什麼？
Michael： 我覺得這多少也有些運氣成分。我們當時組織了小型工程師會議，集思廣益探討未來可能出現的瓶頸。我提到程式碼庫的持續膨脹終將引發擴充套件問題，而當時的部門經理、後來成為我主管的 Brian O'Sullivan 顯然聽進去了。
他決定召集人手開發虛擬檔案系統，打算提前解決這個問題。於是我、Adam Simpkins 和 Wes Furlong 三個人加入了團隊。這兩位都是頂尖工程師，甚至在很長一段時間里，我都覺得自己是項目裡最水的成員。
Ryan： 你提到了虛擬檔案系統。對於 Meta 這樣的大廠來說，自研這類系統有什麼好處嗎？
Michael： 之前我們採用的是單體倉庫（monorepo）模式——就是把所有程式碼都集中放在一個倉庫里。但多數人實際要用的只是倉庫中的某些子集，隨時查看特定檔案。所以我們的核心思路就是圍繞這套虛擬檔案系統設計配套工具：在克隆倉庫、切換提交版本時，系統不再需要把倉庫中的所有檔案都寫入磁碟。透過消除傳統檔案系統中的這種預設操作，就避免了檔案數量隨倉庫規模呈現指數級增長。
而這項工作中涉及兩個關鍵環節：其一是構建虛擬檔案系統——當使用者在某個提交點請求檔案內容時，系統會動態生成對應檔案，呈現出完整的檔案佈局效果。而在作業系統請求檔案內容時，又可以即時調取資料，使其呈現為使用者實際佈局的完整檔案結構。
而另外一部分就是我比較擅長的領域，即預判工具鏈中那些經常需要讀取全部檔案的工具。比如 grep 這類工具，就會直接讀取所有內容。我要考慮該如何調整開發流程和工具設計，使其圍繞虛擬檔案系統展開。因為如果硬要使用原本的工具直接呈現所有檔案，那新的虛擬檔案系統也就沒有意義了。
Ryan： 巨集觀上講，其本質就是對龐大的檔案系統進行延遲載入。不僅效率更高，而且無需在初始階段處理全部內容。
Michael： 沒錯。
Ryan： 你剛才提到你更擅長的是把所有功能都整合到這套基礎框架之上？
Michael： 是的。其實我在跟 Hanson Wang（目前也是 Codex 團隊的成員）合作時就意識到，傳統方案在需要透過 IDE 或編輯器實現超快速檔案搜尋時，大多會首先遍歷整個檔案系統來搜尋檔案。
我當時就覺得這絕對是個大問題。於是我們開始思考：要怎麼既實現檔案搜尋，又不破壞原本的檔案系統優勢，進而探索出超越現狀的新方案？最終，我們開發出名為 miles 的檔案系統（即 my files 的縮寫）。
它透過 cron 作業對主分支下的全部新提交進行索引，追蹤檔案增刪情況——且僅索引檔名而非內容，因為單憑檔名就足夠了。Hanson 還提出了一套維護索引的巧妙方案，實現了檔案模糊匹配功能。也就是說新系統不僅支援子字串匹配，哪怕檔案採取駝峰式命名時，僅輸入大寫字母或者存在拼寫錯誤，系統也能夠準確識別。
我們想出了一種非常有趣的表示方式，用來記錄全部曾被檢出的檔案，再配合一些標記來註明：在執行某項提交時，該檔案當時是否存在？當我們向系統發送查詢時——比如告知當前提交的版本號，以及是否在本地新增或刪除了檔案——就能返回相應的資料。
記得當時在處理超過百萬檔案的查詢時，響應時間大概只在 10 到 20 毫秒之間。這套框架比 Xcode 或者 MDS 碼的預設回應快得多，切實解決了性能遲緩的問題。
憑藉極快的執行速度，Miles 開始作為內部服務開放調用，並被大家廣泛應用於其他各種場景。我離開的時候，Miles 服務已經執行在全球至少 30 台伺服器上，以極大的部署規模滿足著遠超檔案搜尋的多種需求。
Ryan： 你剛剛提到了不少實現細節，畢竟多數人在工作中不會用到 leetcode。但我琢磨了半天還是有點不理解，你的輸入結構是怎麼實現的，用的是 try 嗎？
Michael：Try 確實挺強大的。我們在方案中用了兩個並行陣列：一個儲存檔案內容，另一個好像是指向索引的整數，具體記不清了。此外我們還設定了一條 64 位的掩碼，其中包含 26 個小寫字母、26 個大寫字母、10 個數字還有連詞符之類。只要搜尋檔案中出現過該字元，就設定相應的字元位。
這樣我們既能快速掃描列表、排除大量無效項，又實現了高度並行設計。所有陣列都採用並行佈局，從快取效率的角度考慮，CPU 以線性方式讀取記憶體時能獲得極佳的性能。這種結構天然適合對陣列進行分區並行處理。
Ryan： 我知道你參與 Eden 還有 Miles 項目的工作經歷最終帶來了進一步的晉升。但在晉升之前，你好像積累了一些關於提升個人影響力和處理意見衝突的經驗？
Michael： 是的，這也是我擔任 E8 級別管理職務時面臨的挑戰。我之前一直負責編寫程式碼，但實際上多數同級別或者更高職位的同事已經不寫程式碼了。他們幾乎完全專注於提升自己的影響力或者開展跨團隊協作，比如撰寫專案文件和協調各方意見等等。
所以身為 E8，要想達到預期中的影響力水平，光憑寫程式碼可做不到。我得花時間去影響他人，這對我自已有好處，也能讓上司滿意。
當然，有時候我們可能過於堅持自己的觀點，至少我那時候就這樣，結果就是態度過於強勢，最終讓自己吃了大虧。那段時間我的晉升被延後了一些，也被提醒需要調整方式。
當時的一個背景是，微軟收購 GitHub 之後，我非常焦慮。因為我們的 New Clyde 專案很大程度是建立在 GitHub 生態上的。我覺得這專案肯定要完了，畢竟 VS Code 肯定會吞噬它的獨立地位，後來這個也確實發生了。我當時焦慮得要命，覺得專案陷入了重大風險。於是我拼命催促大家改變方向，卻沒考慮到團隊裡很多人其實對當前工作是滿意的，也不想被突如其來的變動亂了陣腳。
後來上司把我叫過去狠狠訓了一頓，我也接受了指導，專門去學習如何更好地處理這種情況。
Ryan： 那你在這方面學到的最重要的一課是什麼？
Michael： 對我來說，我現在更清楚哪些情況會觸發自己的情緒反應，比如某些技術決策會讓我情緒上頭。在遇到這種情況時，我會馬上反應過來並提醒自己：好吧，千萬不能衝動行事。或者在意識到自己無法正常進行對話或者情緒狀態不佳時，我會選擇找對方的主管溝通，而不是直接闖進某個工程師的工位大喊：「我有個想法，是這麼回事……」
很多時候我會先說：「我現在對這個問題有點激動，可能表達方式不太好，你幫我一起看看怎麼推進更合適。」這種方式反而更有效。
Ryan： 挺有意思的一點是，你預見到了 VS Code 即將崛起，New Clyde 的底層架構將被淘汰，而你卻因為自己的判斷被推遲了晉升。事後證明你是對的，你一直在為正確的判斷據理力爭，卻被要求「冷靜點」。那在意識到事情發展成這個樣子、意識到自己一直就是正確的，那時候你是什麼感受？
Michael： 大概一年之後我確實找相關的人聊過這件事，相當於覆盤一下。畢竟之前事情鬧得挺尷尬。好在結果還不錯，我們總算是解決了問題。
Ryan： 所以最重要的是處理方式，而非立場本身。
Michael： 沒錯，確實如此。
AI 正在重塑開發方式：
Codex 帶來的真實變化
Ryan： 你在 Meta 似乎工作得挺愉快，但最終還是離開了。那是什麼吸引你去了 OpenAI 呢？
Michael： 有多方面因素。我最早是在 2023 年底面試的 OpenAI，當時我在 Meta 負責基於大模型的開發者工具專案，甚至還發布過自研授權版本的 Metamate——類似於 GitHub Copilot 的輕量版，也做過相關的論文和分享，比如 Code Compose 這樣的專案。
但現實是，我們會經常收到反饋，詢問為什麼不選擇用 GPT-4。我們只能解釋用的是 Llama 2，這兩者差距其實很明顯。我本身不是做模型研究的，我更想做的是把這些能力做成產品、做成體驗，所以我當時很自然地覺得，如果要做這件事，就應該去最好的模型所在的地方。
至於第二點，就是我在 OpenAI 身上感受到了當初谷歌對於頂尖人才的重視，這些人的選擇肯定不會錯。事實也確實如此。在 OpenAI，我有機會跟資深團隊共事，包括很多 Meta 那邊 8 級、9 級的專家，可以肆意發揮自己的價值。
第三點在於，這個時機還有 OpenAI 本身都很特別。我跟很多人提起過，那時候加入 OpenAI 很像 2000 年加入谷歌。注意，不是 1998 年的谷歌，而是 2000 年的谷歌。這時候公司已經站穩了腳跟，產品與市場的匹配度也初見成效，這個階段對個人來說是非有吸引力的。
還有一個更個人點的原因，我當初選擇 Facebook 就是看中了它龐大的消費級市場——畢竟我就曾經深耕消費級產品，做的日曆工具也廣受使用者歡迎。但結果我到了 Facebook 卻完全沒機會碰消費業務，後來做的開發者工具服務的其實是公司內部的工程師，大概就兩萬人左右。
後來想去 OpenAI，就是為了把握重返消費級領域的機會——至少可以擁有龐大的使用者基數。現在我負責的 Codex 專案，每週活躍使用者已經突破百萬——具體數字記不清了，但增長曲線確實非常陡峭。這樣的服務規模遠遠超過 Meta 內部 2 到 4 萬開發者的影響範圍。
Ryan： 沒錯，完全正確。行業中的開發工具大多也就到這個規模。
Michael： 對。
Ryan： 在我看來，Meta 更像是一個工程驅動的公司，工程師是核心，很多事情是自下而上推動的。而很多 AI 實驗室則更偏研究驅動，研究是第一優先，這也有它的合理性，畢竟模型本身很關鍵。你作為工程師，又不是做研究的，你怎麼看待研究主導型文化和工程主導型文化的差異？
Michael： 這確實是一個需要適應的變化，如果有人號稱自己能在這兩種文化之間順暢切換，我覺得都是在說謊。不過有一點是肯定的，在類似 FAANG 這樣的大公司待過的朋友會有個好習慣，就是關注對自身影響力的培養。這非常重要，我也在真心實意追求這種影響力。正如我熱愛在 Codex 和 Harness 專案上的工作，這都是很有意義、也很受尊重的成果。但如果模型本身不夠優秀，我們在 Harness 這頭做再多優化，其實意義也有限。
所以我加入 OpenAI 之後感覺特別棒，我們和研究團隊是緊密協作的，坐的也很近，很多事情是一起推進的。這也是我離開 Meta 投身的重要原因——我更希望和做模型的同事一起打造產品，攜手探索新的技術邊界。
或許在 Meta 也能實現類似的模式，但實際效果終究不能相提並論。
Ryan： 你剛剛提到加入時就參與了 Codex 項目的啟動工作。我聽說 Codex CLI 剛剛發布時，市場反響並沒能完全達到預期，但後來項目還是逐漸步入了正軌。能不能分享一下這段歷程？
Michael： 當然可以。這段旅程也是充滿了波折。2025 年 4 月我們發布了 Codex CLI，我們在宣傳直播末尾的彩蛋環節做了現場演示，同時開源了當時的 Core3Pro 專案，很多人都積極試用。大家都對這款全新編程助手充滿了期待，它的表現也還不錯，但當時的發布確實挺倉促的。
總體來講，這對項目吸引人氣還是很有幫助的——開源之後，我們收到了大量 PR。記得項目大概在一、兩週之內就得到了一、兩萬顆 star。那段經歷很有趣，而且也得到了很多使用者的衷心喜歡。但問題在於，當時的團隊可能還不具備推動項目發展的全面實力，畢竟公司需要同時推進多項業務。
在那之後的一個月，七名工程師加幾位研究員（具體人數我也記不清了）發布了 Codex 的 Web 版本——允許使用者直接在容器當中使用 Codex，甚至可以在手機上啟動新項目。這真的特別酷。總之投入的人力更充足了，我也堅信這個項目的長期願景值得期待。但從結果來看，它有點「走在使用者前面了」，使用者還沒有完全準備好。
相比之下，大家當時更傾向於本地編程智能體，所以我們的 Web 版本雖然獲得了一波增長，但粘性不如預期。
整個夏季我們還是持續在推進兩條產品線。直到盛夏時節，本地化智能體仍具備更強的產品市場契合度。但我個人始終覺得本地方案只是權宜之計。畢竟智能體的執行需要更多裝置，不可能單憑筆記型電腦來支撐。
所以夏天我們進行了重大調整：擴充套件了編程團隊，引入更多開發人員。當時 GPT-5 即將發布，市場前景特別特別旺。我個人對此相當興奮，因為之前除了 CLI 介面之外也做過幾次原型測試，這回人手也終於充足了。我們還同時啟動了 VS Code 擴充套件的開發，因為我堅持認為終端雖然適用於很多場景，但在互動上仍存在著諸多侷限性。在終端打造精美的使用者介面總要做出諸多妥協，而在 IDE 裡可以做得更自然、完整。
8 月是一個爆發期——GPT-5 問世，我們也發布了全新終端介面。與此同時，GPT 開源模型也一併亮相，我們在 TUI 中同樣對其提供支援。開放權重模型與開放訓練框架的設計著實令人驚嘆。同月晚些時候，VS Code 擴充套件發布，我們也由此進入瘋狂迭代的新階段。
正是這種種要素的交匯，催生並推動我們跨過了這波垂直增長的轉折點。這段歷程令人振奮，相關資料也都能在程式碼庫裡得到印證。無論是參與人數還是提交次數，各項常規指標都能讓人直觀感受到這種變化。現在回想起來，這也是段相當精彩的旅程。
Ryan： 你剛提到編程智能體的本地版本與雲版本兩種形態，而且你似乎堅信長久來看，未來的希望不在本地版本、而在雲端部署。你為什麼會這樣判斷？
Michael： 現在真正讓人「離不開」的那些使用場景，往往是這樣的：比如每當有新的 GitHub issue、或者 linear 任務之類的進來，你就自動觸發 agent 去處理。雖然這裡面確實有成本問題，也可能被濫用，但如果是在公司內部的私有倉庫裡，這其實是很自然的一種用法。
在這種情況下，agent 更像是自動化流水線的一部分，而不是一個只在你本地互動的工具。那就意味著，這些任務不可能都跑在你的筆記型電腦上。
從這個角度來說，作為個人開發者，你可能還是會更多時間在本地和 agent 互動；但如果看「agent 實際消耗的計算量」，我認為大頭還是會發生在雲端。前期部署這些東西可能稍微麻煩一點，但一旦搭好之後，體驗其實是很好的。
Ryan： 明白了。所以你指的並不是本地形態會消失，而是縱觀整個行業，智能體消耗的算力將主要遷移至雲端。
Michael： 沒錯。我記得 Freeze Code 擴充套件首次發布時，其一大核心功能就是當使用者進行對話時，只需點擊按鈕就能將對話內容傳輸至雲端（前提是已完成配置）。可以想見，未來我們會看到更多類似的場景——你在本地開始一件事，然後把它丟到雲端去跑，等它完成再拿回來。
Ryan： 今年以來，Codex 的使用量已經增長了 5 倍，目前使用者規模超過百萬。我好奇的是，自從開始使用新版 Codex 之後，你自己的 AI 工作流有很大變化嗎？
Michael： 確實有所改變。我現在使用 Codex 的頻率遠超之前的想象。以往我一直強烈依賴 VS Code 擴充套件，需要在側邊欄上把所有程式碼都放在眼前——當時我就覺得，應該把這些元素整合在一起。畢竟我本身就會關注程式碼內容。當然，如果真是那種一次性的原型實驗專案，我也不大閱讀程式碼。
這種可以自由選擇的感覺很棒，也絕對值得我們為此興奮不已。但對於 Codex 專案本體的程式碼，我還是必須親自把關。這一點非常重要，畢竟這個專案會影響到許多人。慢慢你會形成一種判斷：哪些改動可以放心交給模型，哪些地方你需要盯著，甚至需要「看著它做」。所以現在的方式有點像是，我會在一開始就把需求寫得更完整一些，然後交給模型去執行。
同時我本地會開四五個 Codex 倉庫的副本，然後配合 Codex App 來做多任務處理，這種方式對我來說效率提升很明顯，因為你基本可以一直待在一個視窗裡，同時推進多個任務。某種程度上確實有点像在「打遊戲」，你會下意識去想：我現在的吞吐量是多少？類似於同時能把多少顆球拋在空中再接住？
當然，有時候也会有點混亂，尤其是在上下文切換比較頻繁的時候，但你又能明顯感覺到產出在提升。有時候甚至會有點「愧疚」去手寫程式碼，因為你會想，如果一開始把問題描述清楚交給模型，可能會更快。
就像你本來只是想改三行程式碼，結果 30 分鐘過去還沒弄完——這種情況大家都經歷過，而現在很多時候其實是可以避免的。
Ryan： 那現在你寫的程式碼，大概有多少是自己寫的，又有多少是模型生成的？
Michael： 哎呀，現在模型生成的程式碼佔比得 80% 到 90% 了吧，這一點也不開玩笑。尤其是在除錯測試和持續整合這類工作裡，體現得就更明顯了。我就總喜歡讓大模型生成列印除錯之類的程式碼，真的很棒、能夠解放大量人力。
Ryan： 那咱們再聊聊哪些問題適合大語言模型處理，哪些不適合。比如你要怎麼判斷哪些任務需要親自動手編寫？也就是那 10% 到 20%，和餘下的 80%、90% 分別是什麼？
Michael： 這確實是個好問題。每次坐下來編程的時候，我都會琢磨：這部分有必要親手編寫嗎？而答案幾乎都是否定的。
有一類是偏底層的工作，比如 Codex 的 harness 這一層，我主要是在用 Rust 寫，這裡面會涉及很多作業系統層面的細節。
在實際工作中，我把大量時間花在了沙箱機制上。正是這套機制保障了我們工作的安全性和完整性，確保模型不會突破預設的邊界。這類工作我就更傾向於手動編寫，因為必須確保萬無一失。
為了確保測試覆蓋率足夠完善，有時候我會先進行初始化，待基礎框架搭建完成（比如我已經反覆推敲過的模組）後再讓 AI 自動填充剩餘的部分。
但除此之外，其實很多事情都很適合交給模型，比如重構程式碼、拆分 PR，這些以前要花很多時間的事情，現在基本都可以交給模型來做。比如我經常會有一個比較大的 PR，我自己也知道它太大了，就直接讓模型幫我拆成多個更容易 review 的 commit，這類工作節省的時間其實非常多。
Ryan： 那程式碼評審這塊呢？在 OpenAI，大概有多少程式碼是人工審查的？還是說已經有智能體幫你處理一部分？比如測試用例這類應該不需要人工審查吧？
Michael： 我比較認同一種方式，就是讓 agent 先做多輪自我審查，直到它自己足夠有信心，再交人來看。但最終在程式碼真正合入之前，我們還是會做人工審查，這是不会省的。
從實際情況來看，我們和其他團隊一樣，也會有 agent 的一些配置檔案，但還是會遇到模型知識不完整的地方，有些上下文需要補充進去，或者是一些沒有被明確寫進系統裡的經驗，這些往往是人還記得，但模型不知道的。所以在審查階段，確實還是能發現問題。
另外一個明顯的變化是，現在大家也開始用 AI 來寫 PR 的總結，這讓整個團隊的描述質量提升了不少。現在我去審查的時候，程式碼已經被 Codex 過了一輪，還有一份結構清晰的總結，明確寫了這次改動的原因和內容。這顯然大大加快了 PR 審查流程，消解了原本巨大的任務審查壓力。
Ryan： 這簡直太棒了。我感覺可能有一半的 diff 檔案都是空的，測試計劃裡簡單寫著「arc build」之類的模糊內容，根本不知道是幹嘛的。
Michael： 確實，莫名其妙的。
Ryan： 咱們聊聊這個吧——為什麼會決定對 Codex CLI 進行開源？
Michael： 理由很簡單：這是一個會在本地執行且權限很高的工具，這也正是開源的意義所在。我雖然不是那種極端的開源擁護者，但我非常理解這種想法：既然這個東西要跑在我的機器上，我當然關心它的運作機制。特別是在 AI 編程領域，讓使用者可以查看程式碼、理解其行為是極其關鍵的——畢竟大家對於 AI 智能體這類新生事物還存在諸多疑問。因此我覺得開源是必要的一步。
此外，我們也能藉此獲得大量寶貴的貢獻和 bug 報告，發現那些我們可能錯失的問題。同時，我們也在向全世界展示自己的實現方式，如何透過程式碼搭建起一項項功能。我之前發過一篇關於智能體迴圈工作原理的部落格，後面其實還想再多寫一些，只是時間確實有限。
還有個有意思的小插曲，有兩位候選人來面試，其中一位就拿著程式碼說是自己寫的，但我立馬發現那是我寫的。另外一位就好得多，還很認可我親自寫程式碼這回事，誇得我心裡美美的。
Ryan： 你提到的那篇博文介紹了 Codex 的工作原理，那 Codex 是如何發現環境中可用資源的？我在執行這些工具時，會看到它能自行思考，在終端裡找出各種東西，太神奇了。這到底是怎樣實現的？
Michael： 其實這裡用了好幾種辦法。比如 Codex 的基礎訓練機制，就決定了它特別擅長利用 RIP grep 查找各類資訊。此外如果在智能體裡的 MD 檔案或者 Readme 檔案裡標註說「這個倉庫中的這些工具很重要」，那它就會盡量優先使用。
另外如果大家用到了 MCP，並且把這些 MCP 伺服器關聯到當前專案，那這些工具的定義其實是在對話一開始就被注入進上下文的，所以嚴格來說，這部分不算是模型「自己發現」的，而是直接提供給它的。
Ryan： 明白了。一部分是在 Harness 中顯式注入上下文，另一部分則是模型自己去探索和調用。我的理解對嗎？
Michael： 就是這麼回事。
當 AI 已經能寫 80% 程式碼，
工程師的核心能力應該是什麼
Ryan： 回顧你的職業經歷，技術跨度其實非常大，從前端、JavaScript，到構建系統、虛擬檔案系統，再到現在的 Codex。你在這個過程中肯定也在不斷學習，有沒有哪些技術書籍對你影響比較大？
Michael： 有一本是作業系統的書，大概有一千多頁，是 Addison Wesley 出的，但我一時想不起作者了。當時我在做虛擬檔案系統那個專案，其實之前職業生涯裡一直沒怎麼寫過 C，本科更多是偏理論，也沒有真的深入到底層。
結果突然在做一個非常底層的系統，這也是為什麼我當時開玩笑說自己是項目裡最弱的工程師。有一次別人說了一些東西，我發現我完全聽不懂，就有點尷尬，於是就去問應該看什麼書，我當時的經理就推薦了這本。
我就直接買了這本書，從頭到尾讀了一遍，基本走到哪帶到哪，直到讀完為止。其實挺有意思的，很多人可以在軟體工程裡走很遠，但並不真正理解電腦是怎麼工作的，因為中間有太多抽象層了。
一方面這很解放生產力，但另一方面也會帶來一些儕限。後來我也發現，如果你能主動往底層走一走，很多問題其實是可以被重新理解甚至被「拆掉」的，比如你會意識到某些層之間存在多餘的開銷，一旦去掉，可能就是一個數量級的性能提升。
所以我現在會建議大家，主動往更底層去理解這些東西，這對解決問題的能力提升是非常明顯的。除此之外，我也挺喜歡 O'Reilly 出的一些 Rust 相關書籍，寫得比較紮實、也比較系統。
還有一個不算書的建議，但我自己收穫很大，就是去做一些 CTF（capture the flag）這類安全競賽。這類比賽其實挺像一個「電腦十項全能」，會涉及很多不同領域，比如有的題需要你懂組合語言，有的可能要你分析一個寫得很糟糕的 PHP 管理頁面。
這種方式會強迫你去接觸不同層面的知識，而且它本身像一個遊戲，也更有趣一些，比單純看書更容易堅持下去。
Ryan： 能稍微解釋一下什麼是 CTF 嗎？
Michael：CTF 可以有不同形式，但通常是資訊安全領域的一種競賽。最常見的一種是「Jeopardy」模式，也就是有一組設計好的題目，每道題都有對應的分值，你需要在規定時間內儘可能多地解出來，可以是個人參加，也可以組隊。
每道題裡通常都會藏著一個「flag」，也就是一段特定格式的字串，只有當你真正完成了逆向分析、漏洞利用或者其他解題步驟，才能拿到這個字串，然後提交它來證明你解出了這道題。
所以它有點像一種「終端裡的密室逃脫」，你只能依靠電腦本身去解決問題。這類練習會逼著你去接觸一些平時工作中不會碰到的內容，比如除錯底層程式、分析二進位、理解系統行為等。
從提升能力的角度來說，它不僅能鍛鍊你的技術廣度，也會讓你形成一種更偏「對抗性」的思維方式，這在很多複雜問題裡其實是很有幫助的。
Ryan： 所以你的建議是，如果有人想成為更強的工程師，可以去做一些類似 CTF 這樣的練習，因為它會逼著你去解決各種不同類型的問題，對嗎？
Michael： 對，我是這麼認為的。你會在這個過程中掌握一些平時很難接觸到的技能，比如除錯底層程式、分析系統行為，這些在日常開發中不一定會用到。
而且它會強迫你在不同技術領域之間切換，這種廣度其實很難透過常規工作獲得。如果你只是每天寫 React，很可能不會去開啟 GDB、不會去做逆向分析，也不會真正理解底層是怎麼運作的，但這些能力在很多關鍵問題上是非常有價值的。
從某種意義上說，這也是一種讓自己「向下穿透抽象層」的訓練方式，讓你不僅會用工具，也知道工具背後是怎麼工作的。
Ryan： 許多處於職業生涯早期的朋友，在看到 Codex 能在終端裡包辦一切時，都會感慨「那我不用學 GDB 了，反正 Codex 都懂。」在現在這種 AI 工具快速發展的環境下，你會怎麼建議他們去思考自己的工程能力建設？
Michael： 沒錯，我覺得當下有很多人都受困於這個問題。我自己也思考過很多，但找不到完美的答案。我個人還是會回到一個比較樸素的判斷：我依然覺得，應該主動去「往下走」，穿透這些抽象層，去理解系統更底層是怎麼工作的，這件事仍然至關重要。
當然，這個判斷未來可能會改變，但至少在現在，你問 agent 的問題質量，還是會直接影響你最終得到的結果。如果你問的問題不對，很可能就拿不到一個好的工程解法。 也許再往後，這一層也會被進一步抽象掉，但現在還不是。
整體趨勢肯定是在往「更高層抽象」走，問題是我們什麼時候會真正到達那個階段，現在還說不好。進展確實比很多人預期的更快，但我覺得掌握提出正確問題的能力仍然是最重要的。
至於這個能力對於新人來說意味著什麼，我自己其實也沒有完全想清楚。我現在能做判斷，很大程度上是因為過去的經驗積累，讓我形成了一種「直覺」和「品味」，知道該怎麼問。但對於剛剛起步的年輕朋友，我實在沒辦法給出確切的答案。更何況我們也不可能百分之百預知未來的走向，一切尚在未定之天。
Ryan： 回頭看你的職業發展，這些高級別崗位的要求其實挺誇張的。對大多數人來說，E7 或 Senior Staff 已經是很難達到的水平，而你又往上走了兩級。在日常工作中，你怎麼看這種「高期望」？對你有壓力嗎？
Michael： 對我來說，壓力就從沒消失過。畢竟每個人都經歷過績效評估，對吧？而到了這個職位，就像審視他人的職級和影響力那樣，我也想在自己的頭腦中建立起儘可能公平公正的評判體系。比如不同的職級要有相應的標準和影響區間。
類似這個職級要對應什麼標準，那個職級又該對應什麼標準。這時候我的腦袋裡就會不斷推演：如果是別人坐在我的評估席上討論標準，那他們也必須得公平公正。這是份巨大的壓力。比如到了 E8 的職級，突然開始面對 D1 級別的總監，就會想：我要怎麼跟手底下管理著上百人的高管去比拼影響力？
這確實很難，畢竟很多獨立貢獻者會透過另一種「間接管理」的方式來達成目標——比如撰寫規範文件、協調團隊間的協作之類。他們之所以選擇這種方式、而非直接擔任主管，是因為——我其實接觸過這類同事，他們強調自己擁有技術公信力、或者曾親手打造了當前專案，所以由他們進行團隊溝通時，其影響力要遠遠優於普通的工程主管等職務。
而且這種情況可不罕見。當那些資深貢獻者能夠影響到幾十、上百人時，就相當於具備了 D1 職級的影響力。而如果作為普通的程式設計師，我們則需要審慎地選擇專案。千萬別總想著「這個專案能讓我玩得開心」，畢竟沒人願意丟掉工作或者被大老闆在全體會議上吊起來批。
其實我在建立專案時，也會反覆權衡：對於某項功能，我也很想出於樂趣而親自動手。但在認真考慮後，還是決定交給別人做。比如說現在的 Codex 專案，我會考慮該親自編寫哪些程式碼才能儘量擴大自己的影響力。如果交給別人可以實現 80% 的效果，那就應該讓別人接手。
可即便如此，在領導一個五人專案時，想要達到 E8、E9 級別的貢獻預期還是很困難。所以關鍵是要找到能產生倍增效應的專案。比如虛擬檔案系統就是個絕佳案例，我們都知道它將解鎖無數可能性，避免團隊因性能瓶頸而遭到鎖死的困境。
另外還有個關鍵點——我的上司曾經強調過：我們往往低估了高層管理者的價值。正是他們將資深核心工程師與合適的專案進行了匹配。有些資深工程師是出色的問題解決者和程式碼高手，但卻並非創意的源頭。他們才是處理高難度技術專案的理想人選。我不想具體點名，但大家應該懂我的意思。很多時候當事人自己並沒有意識到，是管理者拍板認定「這個專案就得那個人來做」。
Ryan： 我曾問過你的前同事 Adam Ernst，有沒有遇到過自己特別欣賞的工程師、理由是什麼？當時他就提到了你的名字，而且專門強調說你的專案啟動能力非常出色。可以想象，有那麼多出色的專案都是你一手帶出來的，這種有了想法就去打造原型執行力可不簡單。
而且你還總能以極強的說服力，證明你的方案就是最優解。那麼對於其他找到了問題、也有了初步思路，想要從零開始構建項目的工程師，你有哪些建議？
Michael： 其實我覺得，很多優秀項目的靈感都來自對某些現狀的微小不滿。你會覺得某件事不應該是現在這樣，這種感覺本身就是一個很強的起點。
有趣的是，我最大的特點就是有一股衝勁，埋頭苦幹、不瞻前顧後，甚至壓根沒考慮過所謂最佳實現方式。其中的經典案例，當數谷歌日曆的早期版本。我當時突發奇想，打算把天氣功能塞進來。是的，就是在日曆上直接顯示天氣圖示。之後我就直接動手開幹了。
當時我主要是用 JS 開發，完全就沒接觸過後端。我硬著頭皮拼湊程式碼搞定了功能，結果技術主管問：等等，你這天氣資料是怎麼儲存的？我回答說，「就隨便扔了堆 XML 資料。」他提醒道，「我們得先討論協議緩衝區方案才行。」於是我恍然大悟，意識到二進位格式可以節省空間。
反正我就是這樣，只想著實現當前功能，壓根沒問問別人有沒有更好的方案。總之能跑起來就行。
Ryan： 看來正是你的這種獨特屬性，才特別適合深入挖掘問題根源並自主解決。幾乎每個專案都是這樣：現實怎麼會是這樣呢？一定要實現個功能來解決……然後你就開始動手了。
Michael： 對，就是這麼不管不顧的。
Ryan： 我覺得你還有另一個特點，就是很多人都習慣了待在舒適區裡。比如你之前提到的 Buck 專案，肯定有很多人都感受到構建速度慢得離譜了。但他們的想法是「算了，去餐吧那弄點東西吃，然後回來繼續」，而你憑什麼就覺得自己能大幅優化性能？
Michael： 其實那次要歸功於我在谷歌的經歷。雖然我從未參與過 Blaze 團隊的工作，也不了解項目的具體實現原理，更沒接觸過相關程式碼，但我明確知道世界上存在著某種更好的解決方案。這種存在性證明很重要——知道它存在，哪怕不確定自己能否實現，都足以支撐我試上一試。
另外，很多先前的技術成果也幫我積累了信心。我常常自詡為「編程機器」，哪怕現在有了 Codex、大家都成了編程機器，我也仍然保持著這份自信。快速構建原型至少可以解答疑問，或者在思想層面驗證基本假設——即我認為本該存在的東西，是否真有實現的可能。
簡單來講，只要決心堅定，往往就能找到解決的辦法。
Ryan： 我發現一個挺常見的現象，很多人在大公司見過世界級的基礎設施之後，再去別的公司，就會覺得「這個沒有、那個也沒有」，然後開始自己把這些東西重新做一遍。另外我讀過你的不少文章，發現你的行文極其清晰，堪稱技術寫作的優秀典範。對於有意提升寫作能力的工程師，你有沒有什麼建議？
Michael： 我覺得關鍵還是在於多閱讀，閱讀是提升寫作能力的最佳開端。無論是自覺還是潛意識，我們總能在閱讀的過程中掌握寫作的套路，比如作品的結構特徵之類。此外閱讀還有助於培養更巨集觀的思維：我們真正想要傳達的是什麼？讀者真正需要了解的是什麼？再就是一定得提前做好詳細的規劃大綱，很多人都強調過這點，但它的重要性往往被低估。
在具體寫作時，關鍵在於：內容之間能否形成線性的邏輯鏈條？我們還要時時自問：從這個點到那個點之間的跨度是不是太大了？有沒有哪些可能被讀者忽略、但實際上非常重要的環節？我覺得只要解決了這些疑問，對於邏輯斷層就能有比較明確的預判，有助於避免寫出來東西人家看不懂的問題。
在預見到這種情況後，我們就要巧妙地加入示例來引導和幫助讀者完成這種邏輯跳躍。至少在技術寫作領域，我覺得這也是非常重要的一點。
Ryan： 你之前寫過一篇關於職業發展的筆記深得我心，開篇就提出了擴大影響力的三步計劃。能不能具體解釋一下這三個步驟？我覺得大家都應該在職業發展中加以借鑑。
Michael： 第一步是搞清楚我們真正喜歡做什麼。就像我之前提到的，拓展興趣範圍固然很好，但真誠面對自己的內心也很重要——畢竟這個問題可沒那麼容易回答。就像我經歷的很多「英雄之旅」也曾失敗那樣，我做的不少事情也並非出於熱愛。至於第二步，就是搞清楚雇主真正看重什麼、什麼對它來說是最高價值的。
Ryan： 這個太重要了。
Michael： 比如我在谷歌的時候，就沒做好這一點。我做的是自己熱愛的事，但並不是谷歌廣告業務的核心。
第三步就是找到兩者的交集，然後儘可能把精力集中在這個交集上。你越能做到這一點，通常就越容易做出有影響力的成果。
當然，現實的問題是，這個交集有時候並不存在，那你可能就需要考慮換一個環境，去找到那個能讓它成立的地方。
Ryan： 最後一個問題：如果你現在帶著這些經驗，回到職業生涯的起點，你會給年輕的自己什麼建議？
Michael： 我本該更早敞開心扉學習更多事物。另外我也該對自己再狠一點。相信很多朋友都有同感：在起步階段，我們需要學習的東西實在太多，所以剛剛接觸第一門編程語言、特別是順利拿下之後，我們就會對這種語言抱有偏愛，總想找藉口證明它是最好的。比如無論什麼場景，我都會說「不不，這語言本身完全沒問題。」
畢竟它代表著我們真正開始做事、解決問題的起點，緊密關聯一種美妙的、「終於能夠搞點動靜」的舒爽感。但這也會成為我們的陷阱，讓我們想要死守這個工作。畢竟我們花了那麼久才站穩腳跟、終於可以高效工作了，結果又要為新的轉變和突破重新學習……這誰受得了啊？
我自己也是這樣，我發現自己在 JS 上鑽研得太深了。我覺得如果當時能對其他專案類型或者學習內容保持更多的好奇心跟靈活性，那結果會更好。雖然我最終還是做到了，但主動脫離舒適區肯定能讓我更早實現突破。
Ryan： 從過往的經歷看，你在 Xcode 時期曾經非常痛恨 Objective-C，後來甚至想出了把 Objective-C 編譯成 Java、之後再編譯回去的辦法。還有你對掌握 C 語言的執著，可能是受到某種刺激，反正就是逼著自己必須搞明白。好在 Codex 已經越來越成熟了，它能大大降低學習門檻，也許未來我們可以隨意讓它輸出 JS、Rust 或者任何語言形式的程式碼。
Michael： 確實，Codex 的發展成熟確實開啟了更多的可能性。
Ryan： 太棒了。感謝你的寶貴時間，交流下來我受益匪淺。
Michael： 不客氣 Ryan，也感謝你的邀約。
原文連結：
https://www.developing.dev/p/openai-codex-tech-lead-on-how-his