北京
翻譯 | 核子可樂
策劃 | Tina
編輯 | 蔡芳芳
“大多數工程師在適應工具，而少數人會在不滿中重寫工具。”
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 在不改變原意的前提下進行了整理編輯。
1 從工程師到工具創造者：一條被問題驅動的成長路徑
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：就是這樣。
2 “選對問題”：重構 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：沒錯，確實如此。
3 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：就是這么回事。
4 當 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
聲明：本文為 InfoQ 前線整理，不代表平臺觀點，未經許可禁止轉載。
會議推薦
OpenClaw 出圈，“養蝦”潮狂熱，開年 Agentic AI 這把火燒得不可謂不旺。在這一熱潮下，自托管 Agent 形態迅速普及：多入口對話、持久記憶、Skills 工具鏈帶來強大生產力。但這背后也暴露了工程化落地的真實難題——權限邊界與隔離運行、Skills 供應鏈安全、可觀測與可追溯、記憶分層與跨場景污染、以及如何把 Agent 納入團隊研發 / 運維流程并形成穩定收益。
針對這一系列挑戰，在 4 月 16-18 日即將舉辦的 QCon 北京站上，我們特別策劃了「OpenClaw 生態實踐」專題，將聚焦一線實踐與踩坑復盤，分享企業如何構建私有 Skills、制定安全護欄、搭建審計與回放機制、建立質量 / 效率指標體系，最終把自托管 Agent 從可用的 Demo 升級為可靠的生產系統。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
