從拒絕 AI 到一切先問 Agent，DHH：這是我最爽的編程時刻之一，但程序員黃金時代到頭了

整理 ｜ 蔡芳芳

策劃 ｜ Tina

六個月前，Ruby on Rails 作者、37signals 聯合創始人兼 CTODavid Heinemeier Hansson（DHH）還在訪談中明確表示：他不會用 AI 寫代碼，所有代碼仍然親手完成。短短半年之后，這一狀態已經發生了翻天覆地的變化。

在最近的一場訪談對話中，DHH 詳細介紹了他如何從最初對自動補全式 AI 工具的排斥，轉向如今的Agent-First 編程工作流——現在的大多數新項目，他已經不再從手寫代碼開始，而是先讓 Agent 生成實現草稿，再由自己審閱與調整。

不過，這種變化并不是理念轉變，而是工具能力躍遷帶來的結果。當模型開始能夠穩定生成可直接合并的代碼時，AI 才真正進入他的日常開發流程。而與此同時，他對代碼質量、設計審美以及“代碼工匠精神”的標準并沒有降低，反而變得更加重要。

在訪談中，DHH 還討論了多個值得開發者關注的變化趨勢：

• 為什么 Ruby on Rails 可能因為 AI 再次迎來復興

• 為什么設計能力正在成為軟件工程核心競爭力之一

• 為什么資深工程師比初級工程師更容易從 AI 中獲益

• 為什么 CLI 正在成為最適合 Agent 的接口形態

• 為什么傳統“兩個月一個功能周期”的開發節奏正在失效

• 為什么程序員的“黃金時代”可能要走到頭了

更重要的是，這次對話展示了一種不同于常見 AI 敘事的立場：AI 并不會削弱工程判斷力的重要性，反而正在放大它的價值。在 Agent 可以快速生成代碼的時代，真正稀缺的能力不再只是實現功能，而是決定應該構建什么、如何構建，以及什么才是值得合并進系統的代碼。

下面是本次訪談的完整內容，由 InfoQ 翻譯整理，力求完整呈現出 DHH 對 Agent-First 編程實踐、設計審美、團隊結構變化，以及軟件工程未來形態的系統性思考，也希望能把他在訪談中展現出的充沛能量同樣傳遞給你。

主持人：David，很高興你來到節目。最近這段時間你主要在忙些什么？

DHH：我一直在做各種各樣的東西。事實上，我已經在互聯網上持續構建軟件快三十年了。我大概是在 1994 年第一次接觸互聯網，從那之后基本就沒有停下來過。

在過去六個月里，我做了不少項目，其中之一是一個新的 Linux 發行版，叫Omarchy。大概兩年多前我開始切換到 Linux，當時先用了 Ubuntu，用得挺開心，但后來我意識到其實更想從零開始構建一個完全屬于自己的系統，于是就在 Arch 和 Hyprland 之上搭建了 Omarchy。

這個項目最初只是一個夏季的小項目，當時我在參加勒芒 24 小時耐力賽，那一周其實有不少空閑時間，于是我就順手開始寫這個系統，結果很快就發展起來了。最讓我感到振奮的是，即便在 Linux 發行版這樣一個極度擁擠的市場里——大約有 7000 個發行版，其中很多歷史悠久，而且不少理念彼此相似——依然存在創造新東西的空間。

這再次提醒我：即使世界上的想法看起來都已經被做過了，也沒關系，因為你的實現方式仍然是獨特的。我只是按照自己的方式重新構建了 Linux，打造了一個對我來說理想的計算機系統。而每當我做出真正滿足自己需求的東西時，總會發現還有成千上萬的人和我有類似需求，他們同樣會從中獲得樂趣。無論是 Ruby on Rails、Kamal，還是“下云”的實踐，這種模式一直在重復出現。

主持人：Rails 當年其實也是這樣誕生的，對吧？你只是為了解決自己的需求寫了一些組件，然后把它們開源出來。

DHH：基本上是這樣。我是在 2000 年代初接觸 Ruby 的，而真正開始深入使用它是在 2003 年，當時我們開始開發 Basecamp。此前我都是幫客戶做項目，而客戶通常會指定技術棧，比如他們會說：“我們用 PHP，因為團隊里有人會這個?！庇谑悄憔捅仨氂?PHP。

但 Basecamp 是我們自己的產品，我終于可以自由選擇技術方案，于是我選擇了 Ruby。當時 Ruby 在 Web 應用開發方面幾乎沒有成熟工具，所以我不得不把相關工具全部自己寫出來，而這些工具后來就演變成了 Ruby on Rails，而且直到今天它仍然發展得很好，我也仍然深度參與其中。

從某種意義上說，我覺得Rails 現在甚至正在經歷一次新的復興，因為它是構建 Web 應用時最節省 token 的技術棧之一，這一點在當前 agent 工作流環境下非常重要。當然這種優勢未必會永遠持續，也許過不了多久 agent 就開始直接寫機器碼或者匯編語言了，那時情況可能又會變化。但至少在當前階段，token 效率仍然重要，而且 agent 生成的代碼仍然需要人類能夠閱讀和驗證。

這些“為了解決自己問題而構建”的項目能夠吸引越來越多社區成員參與進來，這件事本身就非常令人興奮。比如 Omarchy 這個項目才發布六個月左右，現在已經有大約 400 名貢獻者提交了代碼，而且還有數以萬計的人把它作為日常系統使用。

我一直很喜歡這種體驗：發現某種新的、有趣的、令人興奮的技術，比如當年的 Ruby。甚至 Linux 也可以算是一種“重新發現”，因為很多人以前從未在個人電腦上使用過它，現在才第一次接觸。如果我能夠幫助一批新的 Linux 用戶——甚至未來的 Linux 愛好者——更容易開始使用它，比如降低入門門檻，讓默認安裝環境看起來就已經很好用，而不是需要投入 100 個小時去調整配置，這本身就是一件非常有成就感的事情。

當然，更有意思的一點是，無論是 Ruby on Rails 還是 Omarchy，它們都不僅僅是興趣項目。我一直很喜歡做興趣項目，也會持續做下去，但我同樣希望這些項目能夠服務于實際業務。

在 37signals，我們已經基于 Ruby 和 Rails 構建了一整套業務體系，持續運行了 20 多年?，F在公司里大多數開發者機器也已經切換到 Linux，因為我們有了自己的發行版。

主持人：所以大家還是可以自由選擇系統嗎？

DHH：某種程度上是這樣，但后來我們發現繼續保持完全自由選擇其實已經沒有太大意義了。就像在 37signals，如果有人說：“我要用 Django，用 Python 寫這個系統”，那顯然也說不過去，因為我們已經有 Ruby 和 Rails 了。

所以最開始我只是邀請大家嘗試 Linux，說如果你感興趣可以試試看。但當 Omarchy 項目逐漸成熟之后，我就決定讓所有技術崗位全面切換過去——當然 iOS 開發者除外——凡是做 Web、Ruby 或 DevOps 的人，都應該使用 Linux。

首先，這是因為我們的生產環境一直運行在 Linux 上，從公司成立第一天起服務器端就是 Linux。因此讓開發環境更接近生產環境本身就是一個明顯優勢。同時我們也正在構建自己的發行版，自然希望有更多人參與進來幫助完善它。再加上我是公司的 CTO，我本來就需要負責技術方向，而這正是我希望推動的方向。

37signals 是如何構建軟件的

主持人：能不能簡單快速地介紹一下 37signals，比如這些年大致是怎么發展的，現在整體處于什么階段？你們一直在持續發布各種新產品，而且都挺有意思，比如最近的 Fizzy。

DHH：37signals 成立于 1999 年，最初是一家網頁設計公司。我是在兩年后的 2001 年加入的，之后和 Jason 一起做了幾年咨詢項目。到了 2003 年，我們開始開發 Basecamp，并在 2004 年正式發布。

有個挺有意思的小巧合是，Basecamp 上線時間和 Facebook 幾乎是前后腳——不是早一天就是晚一天，算是同一批時代的產物。大約一年之后，我們意識到這個產品開始真正起飛，于是決定全面轉型，從咨詢公司變成一家軟件公司。

到現在差不多已經過去 22 年了。這期間我們發布了很多產品，其中 Basecamp 是第一個，也是至今最重要的一個產品。這其實挺反直覺的，因為很多人會以為隨著經驗增長，你會越來越聰明、越來越容易做出更好的產品。但現實是，對很多人來說，第一個想法反而就是最好的那個。

我完全不避諱地說，從商業角度來看，Basecamp 就是我們做過最好的產品。而且它已經持續發展了二十多年，依然保持活力，這一點讓我非常自豪。真正能做到這種生命周期的軟件產品其實非常少見。當然這些年我們也嘗試了很多其他項目，也取得了一些不錯的成績。比如 2020 年我們發布了郵件服務 HEY.com，現在回頭看，這其實是一個相當瘋狂的決定。

因為電子郵件市場幾乎被 Google 的 Gmail 完全統治了。雖然 Gmail 已經 17 年幾乎沒什么變化，但它依然是一個非常穩定、可靠的產品，而且很多人用得挺滿意的。甚至很多人同時抱著一種奇怪的矛盾心理：一邊說“我討厭郵件”，一邊卻完全沒有意識到自己其實是在討厭 Gmail。

但我們還是決定做一個真正意義上的競爭產品。而這個領域的市場集中度可能是我能想到所有軟件類別里最高的之一。在美國，Gmail 的郵件流量占比大概接近 85%，也可能是 80%，總之就是極高——基本就是 Gmail 加上一點點其他服務的組合。

我自己從 Gmail 發布不久后就開始使用它，當時還需要邀請碼，那其實是一次非常聰明的發布策略。從那之后我差不多用了 17 年 Gmail。在這段時間里，我逐漸積累了大量對它“不太滿意”的地方，于是我們把這些想法全部投入到了一個全新的產品里。

我們花了接近兩年時間開發 HEY，投入了數百萬美元研發資金，并在 2020 年夏天正式上線——順便說一句，那真不是一個發布新產品的理想年份。我們當時甚至在想：“能不能找一周，全世界稍微正常一點？”結果最后終于挑了一周上線，然后立刻迎來了和 Apple 的一場正面沖突。

主持人：我記得那件事。Apple 當時拒絕批準你們的應用上線。

DHH：沒錯。他們要求我們必須支付 30% 的“過路費”，否則就不允許進入 App Store。對于一個郵件產品來說，這幾乎等于判了死刑——因為你必須存在于手機平臺上，而且更具體地說，是必須存在于 iPhone 上。

直到今天，大多數 HEY 的付費用戶仍然是 iPhone 用戶，因為美國既是最大的高收入市場，而 iPhone 又是這個市場最主流的平臺。所以如果不能進入 iPhone，這個業務根本不可能成立。

我們和 Apple 來回拉扯了兩周，最終時間點剛好卡在 WWDC 前后。Apple 大概也不太希望在開發者大會期間看起來像是一個巨人碾壓小開發者，于是最后他們調整了規則，讓我們得以上線。

這當然算不上徹底勝利，但至少讓我們活了下來。而且結果挺有意思：HEY 最終獲得了巨大成功，其中一個重要原因反而是 Apple 給了我們整整兩周的“全媒體曝光”。

現在回頭看，如果當時讓我重新選擇，我可能不會冒這個險。因為另一種可能的結局是：Apple 拒絕上線，我們只獲得 200 個用戶，然后產品直接死亡。但現實情況是，他們反而給了我們一次價值數百萬美元級別的免費宣傳，我們在最初幾周就獲得了數萬用戶注冊。那是一段瘋狂但又非常令人滿足的經歷。

更重要的是，我自己真的非常喜歡 HEY。我每天都在用它。Web 應用里我用得最多的是 Basecamp——那是我們協作工作的核心平臺。但排在第二位的幾乎總是 HEY，甚至很多時候它是第一位，因為我每天大量時間都在處理郵件、寫郵件、溝通事情。

當郵件環境變得舒適而愉快時，整個工作體驗都會改變。而 Gmail 的一個問題是：世界上任何陌生人都可以直接讓你的手機震動，只要默認通知開啟。這件事在我看來其實非?；闹嚒扔谑侨魏稳硕伎梢酝阕钪匾娜蝿樟斜砝锊迦雰热?。

HEY 的設計理念正好相反。它有一個 Screener 機制，在你明確允許之前，沒有人可以進入你的收件箱。而且大多數時候，我其實都會選擇拒絕。流程很簡單：點個 我愿意聽這個人的郵件；點個 以后永遠別再聯系我。

主持人：我就是這么聯系到你的。我不確定我們是不是在 X 上互相關注，但我直接給你發郵件，然后 Screener 給了我通過。

DHH：因為 Screener 就是我本人在看，并沒有 AI 替我判斷是否要回復誰。事實證明，每天花一點時間處理 Screener 并不麻煩，因為世界上真正需要回復的人其實沒有那么多。如果你把那些煩人的銷售郵件擋在外面——那些在 Gmail 里可以連續給你發七封郵件的人——工作量馬上就下降了，而且體驗會變得非常愉快。

以前我用 Gmail 時，經常會被一種銷售策略“套住”：比如你禮貌地回復一句“謝謝，不感興趣”，對方就會繼續發第二封郵件。這時候你就開始猶豫：我是不是還得再回復一次？很多時候你甚至真的會回復。但就算你不回復，他們依然可以繼續聯系你——因為他們的分階段式營銷（Drip Campaign） 從來就不是一封郵件，而是七封起步。如果你表現出任何一點回應跡象，那可能就變成 52 封。

而在 HEY 里，我只需要點一次 ，就永遠不會再收到這個人的郵件。這種體驗非常爽，就像把花園里的雜草一下清理干凈，剩下的全是花。突然之間，郵件不再是負擔，而變成你愿意打開的東西。

這其實就是我們開發 HEY 的核心目標：讓人重新愛上郵件。

很多人討厭郵件，并不是因為郵件本身，而是因為現有系統太糟糕了。最初電子郵件協議設計時的假設是：這是大學里的科學家之間互相通信的工具，而科學家通常都很有禮貌，不會給你發 52 封銷售郵件。但當它進入現實世界之后，你很快就發現事情不是這樣——尤其當銷售人員出現之后，你就需要更強的防御機制。

對我們來說，HEY 就是這種防御機制，它讓人可以重新喜歡郵件。而且我認為擁有一個強大的“為什么要做這件事”的理由非常重要。這可以追溯到 Viktor Frankl 的觀點：當你找到“為什么”，就更容易忍受過程中的困難。構建軟件本身很多時候確實既冷冰冰又麻煩又令人沮喪，但如果你知道自己為什么在做這件事，一切就會變得更容易堅持。

主持人：如果換個角度，從開發者視角來看，你能具體講講 HEY 當時是怎么構建出來的嗎？你剛才提到花了兩年時間，那最開始是不是只有一兩個人在做？我猜你們肯定大量使用了 Ruby on Rails，也可能有一些原生開發部分。

但兩年這個時間聽起來還是挺長的，尤其考慮到你們公司規模不大，而且團隊又很強。很多開發者第一反應可能是：“兩年？一個高手團隊？這不是周末項目嗎？”——這幾乎是 Hacker News 評論區的經典句式，比如當年 Dropbox 發布時也有人說“我周末就能寫一個”。所以我挺好奇，到底是什么讓這個過程花了這么久？

DHH：我完全理解這種反應，因為我自己也有這種本能。開發者常常會覺得自己無所不能，好像任何東西都能很快做出來。事實上，你確實可以很快做出一個原型——今天甚至不用一個周末，幾個小時就夠了，啟動一個 agent 就能搞定。

但真正耗時間的，從來不是“能不能做出來”，而是到底應該做什么。而要把一個東西打磨到值得發布的程度，往往還需要更長時間。至少對我們來說是這樣，我覺得所有認真做產品的人大概都是這樣。

HEY 最初的技術實現其實只有我一個人參與。事實上，我們大多數重要產品都是這樣開始的：要么只有我一個開發者，要么再加一個人，總之都是一個非常非常小的團隊，先把產品的形狀摸出來，把架構方向搞清楚，然后才逐步擴大規模。

我一直覺得，如果方向還不清晰，就往項目里堆人，反而會讓進度變慢。因為當你不知道自己要做什么時，再多的人也幫不上忙。你必須先弄清楚目標是什么。

當然，這一點最近因為 AI 的進步正在發生變化——現在確定“我要做什么”這件事的速度正在明顯提升。但在 HEY 當時的階段，最初是我，然后是 Jason，再加上一兩位設計師，一個非常小的團隊，一起慢慢摸索產品形態。

如果你要挑戰 Gmail，就不能只是做一個“藍色版本的 Gmail”。那沒有人會感興趣。你必須做出真正新的東西，而且不僅要新，還必須好——要解決那些用戶甚至還沒意識到自己存在的問題。

很多人說“我討厭郵件”，但正如我們前面討論過的，我的判斷是：他們其實討厭的是 Gmail，以及所有那種默認任何人都能直接進入你收件箱的舊式郵件系統。找到這個真正的問題形態，本身就需要時間，而這個探索過程其實也挺有意思，因為你是在資源有限的情況下不斷試探邊界。

Basecamp 當年也是一樣的路徑——技術上最初只有我一個人參與。這里面其實也體現了一些 Shape Up（ Basecamp 提出的產品開發方法論）的思路：設計師不僅要決定產品長什么樣，還要決定它應該怎么運作。產品必須是漂亮的、獨特的、有吸引力的，而這些都需要時間。

更重要的是，要找到產品的“重心”在哪里，最核心的部分是什么，然后圍繞這個核心不斷拆解結構。我們所有大型產品基本都是這樣開始的：一個開發者，加一兩個設計師，先持續推進，一點一點打磨，直到某一刻突然出現“對了，就是這個”的感覺。

一旦進入這個階段，我們才會逐步增加人手。當項目大約完成到 80% 左右時，整體地形已經清晰了，這時候再讓更多人加入，推進速度反而會明顯加快。

主持人：這點其實挺有意思，而且很多人可能不會意識到它的重要性。因為在大多數融資型創業公司，或者像 Uber、Facebook 這樣的公司里，項目通常是產品經理先寫 spec，可能配一個設計師，然后開發者后期才加入。但你們的方式是：一兩個設計師加一個開發者，從一開始就一起推進。而且你們最近還剛招了一位設計師 Zoltan，我也跟他聊過，他很厲害。我感覺你們對設計師的理解方式和行業主流其實挺不一樣的。

DHH：確實不一樣。在 37signals，設計師不是來“把 spec 做漂亮”的，而是來決定 spec 應該是什么的。

某種意義上，他們其實也是產品經理。他們負責回答“為什么這樣做”和“應該怎么做”這些問題。有時候這些判斷來自用戶反饋，有時候來自直覺，但最終都會被提煉成：我們到底要做什么，以及這個東西應該如何運作。

除此之外，他們還直接參與實現。他們負責寫 CSS，寫 HTML，經常也會參與 JavaScript，甚至 Ruby 代碼?，F在有了 agent 加速之后，他們甚至可以直接完成完整實現流程——至少可以做出一個接近最終形態的版本。

不過我也承認，我們在這一點上確實比較特殊。因為很多來自其他公司的設計師，并不習慣同時戴三頂帽子：產品經理、設計師和實現者。但當一個人同時兼具這三種角色時，他就會真正了解自己所使用的“材料”——知道它們能如何延展，知道“接縫”該怎么裁，于是也就能更自然地順應互聯網的底層肌理來工作。

如果你直接寫 CSS、直接寫 HTML，你對這個媒介的理解就會完全不同。這就像珠寶設計師必須了解黃金的物理特性，建筑師必須理解結構受力原理一樣。雖然他們不會親自澆筑混凝土，但理解材料本身會極大影響設計質量。

DHH：順便說一句，這也是為什么像 Daring Fireball 的 Gruber 這樣的老派 Mac 用戶會對 Apple 最近的發展方向感到失望。因為 Apple 曾經代表的是那種極致精致的原生 Mac 應用，而這種東西現在幾乎已經消失了。

現在很多應用都是 Electron，本質上就是“把網頁裝進一個盒子里”。當然 Electron 也被罵得太狠了——很多問題其實是實現質量的問題，而不是技術本身的問題。但大家真正失望的是：原生應用那種“真實感”正在消失。

一個應用到底是“原生的”還是“合成的”，用戶其實是能感覺出來的。而今天越來越多東西看起來都是合成出來的，而不是自然生長出來的。

Web 世界稍微好一點，因為這是一個更大的平臺，也有更多人關注質量。但在大型公司里，這種設計 - 實現一體化的模式仍然非常少見。不過我覺得這種情況正在改變，因為 agent 加速正在讓設計師具備更強的實現能力。

DHH：其實程序員這邊也是一樣的。當年我說 Basecamp 發布時只有我一個開發者，很多人覺得這不現實，甚至有人覺得這是在吹牛——他們認為沒有大團隊就不可能做出真正重要的產品。

但我的判斷從一開始就是：那只是因為你還沒用過 Ruby on Rails，還沒體驗過更好的工具帶來的加速效果。而現在大家終于意識到：如果再疊加 agent 加速，一個人確實可以構建非常有價值的軟件系統。

看到整個行業慢慢朝“小團隊更高效”的方向轉變，其實挺有意思的。因為當溝通成本按指數級增長時，小團隊的優勢會越來越明顯。而 agent 加速正在改變的其中一個關鍵變量，就是初級工程師和高級工程師之間原有的協作關系。

“懷疑 AI”的軟件手藝人為什么開始擁抱 AI 工作流

主持人：我想先順著剛才的話題往前走一步。在深入討論之前，我其實有個感覺：你顯然非常重視軟件工程作為一種“手藝”（craft），這一點很明顯。但與此同時，我也感覺你同樣非常重視設計本身——包括用戶體驗、軟件設計，甚至是那種“做出來的東西用起來是否舒服”的整體感覺。無論是軟件還是硬件，你似乎都把這些當作一種手藝來看待，而且你在主動尋找這種品質。我這樣理解對嗎？

DHH：完全正確。我非常認同這一點。在我看來，美感本身就意味著某種程度上的“正確”。當一個東西是美的，它往往也是對的。這一點在數學里成立，在物理里成立，在很多領域里都成立。當你抵達一種正確的審美狀態時，往往意味著你已經接近某種更深層的正確性。

我們其實都有一種直覺，會引導我們走向這種美，因為這種美通常同時意味著正確、意味著高貴，也意味著值得追求。而且我還相信，美本身會讓人更幸福。被設計良好、運行順暢、外觀優雅的物品包圍，是幸福感的重要來源之一。

反過來說也是成立的：當你周圍的一切都運轉糟糕時，那種焦慮和挫敗感會迅速累積。比如系統卡頓、觸控失靈、設備動不動就要重啟；又比如你打電話給旅行代理，對方卻說系統不支持，因為后臺還是一套古老又僵硬的 COBOL 系統——這樣的世界其實到處都是。

現實世界里不僅存在“劣化”（原本不錯的系統變糟），還存在大量從一開始就很糟糕的系統。我認為這其實已經成為一種文明層面的倦怠來源。如果我們身邊能有更多設計優美的物件、更多結構優雅的系統，人類整體的幸福感真的會提高。

而這里說的“美”，不僅指外在視覺層面的美，同樣也包括內部結構層面的美。對我來說，這兩者通常是統一的。Steve Jobs 當年為什么那么在意電路板布局？因為他直覺上知道：在意電路板布局的人，也一定會在意用戶界面的細節，也一定會在意打開外殼時的手感和體驗。所以我覺得，如果你本身對這種審美敏感——而我認為幾乎所有人其實都有，只是意識程度不同——那你自然會希望讓一切都變得更優雅、更協調、更美。

對我來說，Ruby 就是一門非常關鍵的語言，因為它能寫出我認為最優雅的代碼。說實話，在這方面幾乎沒有什么競爭對手。確實也有一些語言在某種意義上是優雅的，比如 Smalltalk，我就非常欣賞它的極簡之美，但它不是我想長期居住的“房子”。Ruby 才是我愿意住進去的那棟房子。它既有審美上的一致性，同時又不像很多語言那樣被僵硬的理念束縛住。這其實是非常罕見的一種特質。

當然，這種對美的執著通常也有代價。很多人在這方面走得很深之后，會變得有些狹隘，這是一種常見的副作用。但我覺得 Ruby 在這里取得了一種很難得的平衡：既保持開放的表達空間，同時又高度關注代碼本身的優雅結構。

總體來說，我認為我們必須使用美的工具，也必須創造美的系統，還必須設計流暢自然的交互體驗。這正是我們作為“手藝人”應該追求的目標——不斷打磨它，直到沒有任何毛刺為止。

主持人：我們正好可以聊聊這個話題。不過在進入之前，我其實想先問一個更基礎的問題：AI 到底是怎么改變你的工作方式的？它又是如何影響你對軟件這門“手藝”的理解？

畢竟你在 37signals 招的人，也和你一樣，既重視設計、又重視軟件開發這門手藝的質量。我很好奇，AI 有沒有改變你從這門“手藝”里得到的東西？AI 在哪些方面讓這件事變得更好了，哪些方面有可能讓它變差了？我想先從你的看法變化聊起。

你上一次比較系統地談這個問題，還是在 Lex Fridman 的播客里。當時你對 AI 其實還是挺懷疑的——當然那時候工具也確實不夠成熟。但現在情況已經明顯不一樣了。

DHH：這個問題其實有點微妙，甚至可能聽起來像是在替自己辯護，但我真的覺得：我的觀點本身并沒有改變，改變的是現實條件和客觀事實。

從 ChatGPT 發布那一刻起，我就已經意識到我們面對的是一種全新的東西，而且它注定會改變很多事情。回頭看計算機科學的發展時間線，我認為 ChatGPT 的發布顯然屬于那種必須標記出來的重要節點之一——那種“以后回頭看一定會說，這是轉折點”的事件。

第一次看到人們可以用這種方式與計算機交互，而且還能看到它們進行某種形式的“推理”（雖然這個詞是否準確仍有爭議），對我來說已經足夠說明問題：這些系統真的非常聰明，在很多方面甚至比我更聰明。至于這種聰明來自權重、來自數據、還是來自別的什么，其實并不重要。我們甚至都還搞不清楚人類意識和智慧是怎么工作的，所以沒必要對“什么才算智能”下過于武斷的定義。

但問題在于早期模型的使用方式讓我非常不舒服。那時候主流形態還是自動補全，比如 Copilot 或 Cursor 在編輯器里不斷猜你下一步要寫什么字符。這種體驗對我來說非常煩躁，就像我們正在對話，而你卻一直打斷我：“是不是這個意思？是不是這個意思？”我當時的反應基本就是：能不能讓我先把一句話說完？

即使它偶爾確實能提升效率，但錯誤率太高了，這種“加速”反而更像是一種干擾。哪怕整體算下來可能是正收益，對我來說也完全談不上愉快體驗。或者也可能是我放棄得太早，但無論如何，我當時并不喜歡這種方式。我覺得模型還不夠好，而自動補全這種交互方式本身也很糟糕。甚至有一段時間，我還短暫地對整個行業的發展方向產生了一點悲觀情緒。我以為未來大家都會變成那種不停按 Tab 鍵的人，而我真的不想變成那樣。

主持人：我記得 Cursor 當時還送過一個“Tab 鍵”周邊。

DHH：對，那感覺真的挺反烏托邦的。我當時甚至想起《辛普森一家》里有一集：Homer 把一只機械小鳥放在鍵盤上，讓它不斷幫自己按回車鍵。結果突然出現核反應堆過載警報，小鳥還是繼續按回車，最后整個系統爆炸了。那一刻我真的覺得：這畫面太貼切了。《辛普森一家》果然什么都預言到了。

但無論如何，我當時并不喜歡這種使用方式。雖然我依然對整體發展方向保持樂觀，因為它確實令人驚嘆。最早讓我真正感到價值的，其實是把 ChatGPT 當作導師或者結對編程伙伴使用——不是替我寫代碼，而是幫我理解代碼。

比如我可以問它：“這段代碼為什么這樣工作？”、“這里的問題在哪里？”這其實就是我一直以來使用互聯網的方式。從 Google 時代開始就是這樣：看到報錯信息就去搜索，在 Stack Overflow 上找答案，有時候還能看到一些帶點攻擊性的評論，但最終總能找到解決方案。而 ChatGPT 的不同之處在于，它往往能給出非常好的解釋。

主持人：我之前和游戲開發者 Jonas Tyroller 聊過類似問題。他當時的做法是直接關閉 IDE 里的自動補全，只在需要時主動去 ChatGPT 提問。這樣他就能保持一整天都在“專注區”，只有真正需要幫助時才切換模式。聽起來你當時的體驗也很類似。

DHH：完全一樣。我當時確實擔心未來大家都會變成那只不停按鍵的小鳥，而我并不想成為那只小鳥。我甚至一度想：那我是不是應該改行去種土豆？畢竟丹麥在這方面傳統悠久。

不過后來事情發生了變化，而且是兩個關鍵變化：

• 一是 Agent 模式的出現，逐漸成熟并開始真正形成影響力。隨著 Agent Harness 的出現，AI 不再只是回答問題，而是獲得了工具：它可以調用 bash，可以操作終端，可以訪問互聯網，可以主動獲取上下文信息。這時我們才真正從“AI”進入“Agent”階段。

• 二是模型能力本身的躍遷。對我來說，像 Opus 4.5 這樣的模型是另一個明顯的時間節點。那是第一個讓我持續、穩定地被輸出質量震驚的模型。無論是分析能力，還是在模糊輸入條件下生成代碼的能力，都達到了新的水平。更關鍵的是，它生成的代碼往往可以直接合并進項目，而幾乎不需要修改。即使需要調整，只要我告訴它一次，它下次就不會再犯同樣的錯誤。

這兩個變化疊加在一起，才真正構成了轉折點。

當然，對我來說還有一個額外門檻，因為我的標準本來就很高。我們剛才也討論過，我對代碼的審美要求非常嚴格。如果 Agent 生成的 Ruby 代碼達不到我的水平，我是不會合并的，就像我不會合并一個還沒完全掌握團隊風格的初級工程師寫的代碼一樣。

早期模型確實能生成可運行的軟件，而且已經很驚人了。我記得第一次讓它生成一個貪吃蛇游戲時，我真的震驚了——那是我從六歲開始就想做的事情，而它只花了三十秒就完成了。復制 HTML、運行、完成，簡直像魔法一樣。但即便如此，真正適合長期使用的工作形態，其實花了一段時間才出現。對我來說，真正的轉折點就是基于終端界面的 Agent Harness 出現的時候。從那一刻開始，它不再只是“一個可以聊聊天的工具”，而變成了“我真的愿意讓它寫代碼的工具”。

深度使用 Agent-First 工作流

DHH：現在我開始任何新項目，默認都是Agent-First。這是一個非常巨大的變化，而且幾乎是在一瞬間發生的。對我來說，大概就是 Opus 4.5 發布那一天，也就是去年 11 月 27 日左右。

當然，也有人認為轉折點其實來得更早，比如從 Opus 4.0 或 Sonnet 3.7 開始。但總體來說，行業內確實存在某種共識：真正的轉折點，大概出現在去年 11 月底到 12 月初。

當時正值冬季假期，大多數科技公司基本都停擺了兩周。很多人開始拿那些一直擱置、始終沒做完的 side project 來試這些新工具。本來想著反正也做不完，結果卻突然發現：居然真做出來了。那種感覺就像電影里突然響起一段磁帶倒轉聲——“等等，剛才發生了什么？”

某種意義上，這是一場分散發生、卻又高度同步的集體震驚。每個人都是單獨經歷到它的，但感受到的沖擊卻出奇一致。等到一月份大家回到公司，尤其是那些原本已經不怎么在一線寫代碼的 CTO 和資深工程師，也開始上手體驗這些工具，然后回來直接說：“你們必須用這個。我已經看見未來了?！?/p>

那種感覺有點像新一代硬件剛出現的時候：別人把設備遞到你手里，對你說，“你得親自試一下，不然你不會信?！倍@種體驗本身，確實很難用語言準確傳達。如果你還沒經歷過那個“啊哈時刻”，光聽別人講其實是很難被說服的。你得自己坐下來，用一個 Agent Harness——比如 OpenCode——配上一個前沿模型，親手試一次。

如果還有人沒試過，我會建議他們現在就去試，而且不需要有那種“如果我現在還沒學會 AI 就落后了”的焦慮。那種焦慮完全沒有必要。就算你現在開始學，三周時間就足夠補上進度。這其實也是 AI 時代一個很神奇的地方——很多過去必須按時間線逐步學習的東西，現在可以直接跳躍式跨越。比如去年春天大家都在討論 MCP，而現在你完全可以直接跳到 CLI 和 Agent 工作流。

當然，我也承認有些人確實更早看到了這一切。比如 Shopify 的 Toby Lütke，就是我認識的人里最早意識到變化規模的人之一。他一直不斷給我發消息：“你看看這個，你看看這個?！鄙磉呌羞@樣的人其實很重要。有些人的視線總是看得更遠，而我的視線通常更貼近眼前的路。有時候他們會看錯方向，但這一次 Toby 看得非常準確——兩年前就已經看清趨勢了。而我是等到去年 12 月才真正意識到。

更有意思的是，在這之前我其實一直在說：“等模型足夠好之后，一切都會變得非常驚人?！敝皇俏耶敃r以為這個時間點可能還要等 18 個月、兩年，甚至五年。誰也很難預測這種拐點什么時候出現。甚至整個行業本身也沒預測到。但它就是發生了。而從那之后，我的日常工作方式完全改變了?，F在我的工作默認就是Agent-First。

主持人：那你現在具體是怎么工作的？

DHH：現在幾乎所有事情我都是先從 Agent 開始。

我主要使用的是 OpenCode，偶爾也會用 Claude Code。不過他們因為早期優勢形成了一些生態鎖定，比如如果你想用 Max 訂閱，就必須使用他們自己的 harness。我覺得這其實是個錯誤決定，不過先不展開說這個。不管怎樣，我們還是應該承認一點：Opus 現在確實是最強模型。對我來說，4.5 就是關鍵拐點，而 4.6 也很不錯。正因為它這么強，也激發了整個行業的競爭。大家都在試圖追趕甚至超越它。

看看 Anthropic 的收入增長就知道了：年初還是 9 億美元規模，幾周后變成 14 億，現在已經接近 19 億。這種增長速度幾乎是火箭級別的，自然會吸引大量資本進入這個領域，這是一件好事。

當然，我也并不是完全喜歡他們所有決策，就像我對 Apple 也有很多意見一樣。但與此同時，我始終還戴著另一頂帽子：我首先只是一個喜歡計算機的人。比如他們的新 Neo，我甚至可能會買一臺來試試；再比如 Opus 每月 500 美元的訂閱費，我也完全愿意付，因為它確實值這個價。

實際上，現在只要遇到特別困難的問題，我第一反應就是：交給 Opus。當然，我也不會只用一個模型。我現在的工作流通常是同時運行兩個模型，而且速度不同、職責不同。

我的工作環境是這樣的：在 Omarchy 里我有一個布局模板，左側是 NeoVim 編輯器，右側是兩個 Agent 窗口。上面運行的是 OpenCode + Kimi K2.5，下面運行的是 Claude Code + Opus。底部再留一條終端窗口。

我通常會先把任務交給其中一個 Agent，讓它生成實現草稿，然后切回 NeoVim，看 diff。如果結果正確，我直接提交；如果不滿意，就自己修改。

真正讓我震驚的是這個比例變化的速度。去年 11 月初的時候，我的工作方式還是完全Code-First：先打開編輯器自己寫代碼，寫一段時間，如果卡住了或者想聽第二意見，再去問模型?，F在已經完全不是這樣了。我是先讓 Agent 寫草稿，然后我審閱草稿，必要時再修改。而就在最近，這個比例甚至又進一步變化了。

比如我們現在正在為 Basecamp 開發一個 CLI，讓 Agent 可以完整訪問 Basecamp——這件事本身就非常驚人。不過讓我稍微往前倒一點說：當我真正意識到 Agent 已經這么強大之后，我的第一反應其實是抬頭往更遠處看——我們是不是甚至不需要 MCP？不需要 CLI？什么都不需要？Agent 自己能不能搞定一切？

于是我安裝了 OpenClaw，在一臺虛擬機上跑起來，然后開始做實驗。我想看看它到底能做到什么程度。

我先試了一個最簡單的想法：把它當成一個普通用戶一樣邀請進我們的產品里。我對它說：“去 fizzy.do 注冊一個賬號。”沒有給它任何工具，沒有 MCP，沒有 CLI，就只是告訴它網址。它開始執行，然后回來告訴我：“注冊需要郵箱地址?！蔽也乓庾R到，對，它沒有郵箱。于是我又說：“那你先去 hey.com 注冊一個郵箱?！?/p>

我當時心想，這一步肯定失敗。結果它過了一會兒回來告訴我：“我已經注冊好了，這是密碼，請保存好。我也已經完成了 Fizzy 注冊，并收到了確認郵件。接下來要做什么？”

我當時真的愣住了。它居然可以一次性完成整個瀏覽器注冊流程。當然，也許這種能力在更早的模型里就已經存在，比如 Sonnet 3，我也不確定。但當你親眼看到它在你自己的環境里完成這些事情，那種沖擊是完全不同的。于是我繼續測試：既然它能注冊 HEY，也能注冊 Fizzy，那能不能讓它加入 Basecamp？

我給它發了一封邀請郵件，讓它加入我們 AI Labs 項目，并讓它介紹一下自己。它進去之后寫了一段話：“大家好，我是 David 的助手，很高興認識大家。我看了一些之前的討論，發現大家對這些事情都很興奮?！?/p>

我當時又是一句：“等等，什么？”

雖然整個過程花了大概七分鐘——在 Agent 世界里，這已經算挺久了——但它確實完成了。這讓我意識到一個可能的終局狀態：未來的 Agent 不需要任何專門為它們準備的接口，也不需要所謂“無障礙通道”。它們不會坐著輪椅進來，而是踩著仿生腿跑進來，而且速度可能是我們的五倍。

當然，這個階段還沒到來。但我也不能坐在那里等 AGI 出現。所以我們要為“今天”構建系統。這就是為什么我們現在在給 Basecamp 做 CLI，也會給 HEY 做 CLI，還會給 Fizzy 做 CLI，甚至可能包括一些老產品。

我之所以特別喜歡 CLI，一個重要原因是，它再次驗證了 Unix 自 1971 年以來那套樸素卻強大的理念：把工具做小，再通過管道把它們組合起來。這其實就是 Unix 哲學的核心。真正的魔力并不在于“Basecamp 有了 CLI 之后更好用了”，而在于 GitHub 也有 CLI，Sentry 也許沒有 CLI，但有 MCP。于是，這些原本分散的系統就能夠被真正串聯起來。

現在，你可以直接對 Agent 說：去 Sentry 看看報錯，寫一份分析報告發到 Basecamp，再去 GitHub 提交一個 PR；做完之后，再回到 Basecamp 更新狀態。這樣一來，Basecamp 就成了一個中央控制臺，我們可以實時看到 Agent 正在推進的整個工作流，而它則在后臺自動查資料、寫代碼、推動任務往前走。

這種體驗其實很難只靠語言解釋清楚?，F在 YouTube 上已經有不少 OpenClaw 的演示視頻，至少可以讓你先“坐在副駕上”感受一下。但最好的方式，還是親自上手：拿你自己的項目、你自己的任務、你自己的 prompt，完整跑一遍。

只要真正體驗過一次，你幾乎一定會被“洗腦”——而且是同時生出兩種情緒：一方面會非常興奮，因為我們竟然真的造出了這樣的系統；但另一方面，你也會隱約感到一絲焦慮，因為你開始意識到，未來的變化可能會快得驚人。如果過去三個月已經徹底改變了我對計算機能力的理解，那未來三個月會發生什么？九個月之后呢？十八個月之后呢？

AI 絕大多數收益流向資深工程師

主持人：我其實很長時間都和你一樣，對預測未來保持謹慎態度。我更愿意相信已經發生的事情，而不是推測未來。比如當年大家都說摩爾定律會永遠持續下去，但后來它確實失效了——至少在單核層面上。

DHH：沒錯，不過后來大家只是換了一種方式繼續推進，比如開始做多核，現在 AMD 的芯片已經可以做到 256 核了。即使單核性能增長放緩，我們仍然通過功耗優化、尺寸優化等方式繼續推進性能提升。所以現在確實很難說“增長就會停在這里”。訓練規模還在持續擴大，而且目前為止這種路徑仍然有效。

還有一篇我覺得特別值得一讀的文章，叫 《The Bitter Lesson》。這篇文章其實很短，但影響極大。它講的是一個許多人未必愿意輕易接受的事實：我們總希望相信，自己的知識、經驗和訓練方式是獨特且不可替代的；但現實往往并不完全如此。

不過有意思的是，在當前這個時間點上，這種情況又呈現出一種新的分化：在 37signals 內部，我看到利用 Agent 加速工作最成功的反而是最資深的工程師。因為他們具備判斷能力，能夠判斷 Agent 生成的代碼是否真的適合部署到面向數百萬用戶的系統中。

就在昨天還有一條新聞，說 Amazon 發生了一次比較嚴重的系統故障，而他們內部的分析基本已經得出一個結論：不能再允許初級程序員把 Agent 生成的代碼未經審查直接部署到生產環境。

我覺得這其實正是整個行業現在普遍開始意識到的一件事：對于那些關鍵系統來說，目前我們還不能完全依賴 Agent，而初級工程師也還不具備足夠能力判斷 Agent 輸出是否可靠。于是初級工程師的角色在短短六個月里突然變得更加不穩定了。

相反，資深工程師正在獲得巨大的加速能力。因為他們不僅可以同時和多個 Agent 并行工作，更重要的是，他們能夠判斷 Agent 輸出的質量，并對其是否適合上線形成高度可靠的判斷。如果方向不對，他們還能及時糾正。

這其實正是他們之所以成為資深工程師的原因：他們擁有長期經驗、系統視角以及架構理解能力。他們本來就是在指導初級工程師，而現在，他們是在指導 Agent。而 Agent 在執行指令和接受修正方面，比人類初級工程師要快得多。

于是突然之間，一個資深工程師的個人產出能力可能提升 5 倍、10 倍。接下來就會出現一個二階效應：如果你把一個資深工程師的效率提升 10 倍，那么這個人每小時的價值也幾乎提升了 10 倍。

那接下來問題來了——這一個小時應該怎么用？是繼續用來驅動 Agent 寫更多代碼？還是像過去一樣，用來培養初級工程師？現在這個方程式正在發生變化，而它最終會如何收斂，目前還沒有答案。

當然，也有一種可能性是：未來 Agent 會變得足夠可靠，不再犯這些錯誤，從能力上變成“資深工程師級別”的代碼生產者。

如果從更長時間尺度來看，我覺得這其實是一個合理的猜測。因為類似的事情已經發生在自動駕駛領域?，F在 Tesla 的自動駕駛，在平均意義上已經比人類司機更安全了——不是所有人、不是所有場景，但總體來說確實如此。如果我們已經愿意把這種級別的風險——每天坐在高速移動的金屬盒子里、任何一個錯誤都可能致命——交給 Agent，那么它們遲早也能學會寫代碼。

我認為這一天一定會到來，只是不知道什么時候、以什么方式到來。但在當前這個階段，絕大多數收益確實正在流向最資深的工程師。

主持人：我一直在想，這件事的發展路徑，可能和自動駕駛有些相似。比如對一家還沒有用戶的創業公司來說，很多東西其實可以直接 one-shot 發布，就算系統崩了，代價也相對有限。但在 Uber 這樣的公司里，情況就完全不同了。

我最近正好了解了一些他們內部采用 AI 的細節。他們其實已經部署了很多工具，比如 Claude Code 之類的。問題在于，公司內部系統實在太復雜：有 monorepo，有 ticket 系統，有 Slack，有 RFC 文檔，有設計規范，還有大量微服務架構歷史遺留下來的復雜依賴。后來他們不得不專門構建一整套內部系統，為 Agent Harness 提供足夠的上下文支持，之后整體效果才明顯提升。

這又讓我想到另一件事：如果一個資深工程師從 Uber 跳到 Google，他在相當長一段時間里也未必能保持原來的效率，因為他首先得重新理解整套系統架構。于是我就在想，軟件工程會不會也像自動駕駛一樣——只有當整個環境被充分“地圖化”之后，Agent 才能真正發揮出最大的能力？

畢竟，自動駕駛也是花了將近十年，才一步步走到今天。可我當年還在 Uber 的時候，大家都在說“明年方向盤就要消失了”，仿佛司機這個職業很快就會不復存在。

DHH：是的，而且這件事本身其實很有意思，因為它恰好說明了 Elon 當年的信念到底有多強。2017 年他宣布自動駕駛即將完成時，背后的系統其實仍然是大約 50 萬行手寫 C++。沿著那條技術路線走下去，根本不可能實現真正意義上的完全自動駕駛?？杉幢闳绱耍廊粓孕欧较虮旧硎菍Φ?。直到后來 AI 真正進入系統，一切才開始發生根本性的變化。當模型能夠在數十億小時的真實道路數據上訓練之后，它確實開始變得比大多數人類司機更安全。

我自己也算是一個還不錯的司機，但當我把車交給 Tesla 自動駕駛時，它幾乎已經像是世界上最好的司機之一：加速很平順，減速也非常精準，比我開得好，可能也比你開得好，甚至也許比英國女王的專職司機還要好。在這個非常具體的任務上，它幾乎已經表現出了某種接近 AGI 的能力。

更有意思的是，這種能力躍遷發生得極快。真正基于 AI 的 FSD 系統，并不是花了十年才達到今天這個水平。真正的質變，其實是在最近短短 18 個月里發生的。比如在早期的 13.1 版本上，你會覺得：“這已經挺不錯了，但我還是得盯著方向盤?！苯又?13.2、14.0、14.2……然后突然有一天，你開始忍不住懷疑：如果它已經開成這樣了，那方向盤為什么還在？

很多人今天看待編程 Agent，其實也是類似的心態：如果在當下，資深工程師仍然必須審核代碼，否則 AWS 就可能出現嚴重故障，那么一年之后又會是什么樣？

當然，你也完全可能因為這些問題陷入過度焦慮。我自己在過去一年里，其實也經歷過那個階段。但后來我決定：與其不斷試圖預測 12 個月之后會不會出現 AGI，我更愿意把注意力放在今天能做什么、今天能享受什么。

Agent 帶來的開發加速體驗

主持人：從軟件工程師的角度來看，這多少有點讓人不安。很明顯行業正在朝這個方向前進，大量公司會圍繞這個方向建立，大量風險投資也會投入進去，而這些公司最終要么成功，要么失敗，但無論如何，這條路徑都會繼續推進。

那在 37signals 內部呢？你們團隊里大多數都是資深工程師，但也確實有初級工程師。他們的工作方式發生了什么變化？工作的滿足感有沒有變化？畢竟現在也有人擔心，這些工具會不會讓開發者變得更不快樂。

DHH：對我來說，最大的驚喜其實不是 Agent 的能力，而是使用它們時的愉悅感。

去年夏天我在 Lex Fridman 的播客上說過，我不想變成 Agent 的項目經理。因為當時我腦子里的“項目經理”模型是：遠離生產一線、遠離代碼、只負責協調別人做事。而那不是我想要的狀態。我希望自己仍然在代碼里動手。

但后來我發現，真正使用 Agent 的體驗完全不是那樣。它更像是穿上了一套超級機甲外骨骼。突然之間，我不再只有兩只手，而是有十二只手；我可以同時盯著七個屏幕、操作五個鍵盤。雖然我沒有逐字符敲代碼，但我仍然是在寫程序，只是能力被極大放大了。

這仍然是一種程序員體驗，只是換了一種形態。而且當我寫 Ruby 代碼時，那種審美關聯仍然存在。同時，我還能在更多任務上保持高效率推進。甚至在問題分析能力上，這種提升也非常明顯。

一個讓我真正“頓悟”的時刻發生在 Omarchy 3.4 發布之前。當時 GitHub 上大概有 250 個待處理 PR，我看了一眼就嘆了口氣——如果每個 PR 花 15 分鐘，那得花多久？于是我決定換個方法試試，我直接把 PR 的 URL 丟給 Claude，讓它來做 review。

結果在大約 90 分鐘內，我處理了 100 個 PR。當然，并不是所有 PR 都能直接合并。實際上大概只有 10% 可以直接合并；另外約 20% 的情況是，Claude 發現的問題本身是對的，但原始實現方式并不理想。于是我就讓它按照項目現有風格，重新從頭實現一版，它幾乎立刻就完成了，而且代碼風格和整個項目保持得非常一致。剩下大約 25% 的 PR，我看完之后覺得其實不應該合并；還有約 25%，則屬于 Claude 對問題方向的判斷可能沒錯，但實現路徑不夠理想，同時也看不到特別明確的改進空間。

90 分鐘處理 100 個 PR——這原本至少是一周的工作量。更驚人的是，其中至少一半 PR 涉及的內容是我原本并不熟悉的領域，而 Claude 的分析明顯比我自己更專業、更準確。不是說我做不到，而是我根本不會投入那么多時間去研究它。這也是這些 PR 之前一直堆在那里沒有處理的原因之一。

這種 Agent 加速體驗，對我來說絕對是可以排進個人編程生涯前二十的重要時刻之一。

主持人：聽起來 Agent 特別適合處理那些“本來應該做，但又不太想做”的任務。而這些任務如果交給團隊成員處理，未必更快，甚至可能更慢。另外我還在想，我們經常討論 AI 是否提升效率，比如 PR 數量增加多少，但還有一個更重要的問題：它是不是讓我們開始做以前根本不會做的事情？

DHH：正是這樣。真正關鍵的變化不是效率提升，而是問題空間在爆炸式擴大。

現在我們內部啟動了大量以前根本不會考慮的項目。比如有一次性能優化項目，通常大家關注的是 P50、P95、P99 延遲指標。但 Jeremy——我們團隊里最擅長使用 Agent 的工程師之一——提出一個問題：為什么不優化 P1？也就是最快的那 1% 請求。

當時我們的 P1 延遲大概是 4 毫秒。他覺得還能繼續壓縮。于是幾天時間里，他把它優化到了不到 0.5 毫秒，相當于提升了 10 倍。

如果換成過去，我根本不會批準這個項目，因為它看起來太像“性能炫技”。但現在不同了，因為探索成本幾乎為零。整個 P1 項目大概涉及十幾個 PR，總共修改了大約 2500 行代碼，而且只用了幾天時間。以前幾乎沒人會做這種優化，因為它看起來商業價值不明顯。但現在，我們突然可以認真考慮這些問題了。

這讓我想起《終結者 2》里的一段情節：他們找到第一部電影留下的芯片，然后說了一句話——“它讓我們產生了一些原本根本不會考慮的想法。”現在的情況其實非常類似。

Agent 把探索一個模糊想法的成本，幾乎壓低了上千倍。現在我經常會隨手把一些自己都還沒完全想清楚的念頭丟給它，連 prompt 都寫得很隨意，只是想看看會發生什么。

有時候結果當然會很糟，那我就直接把代碼回滾掉。但如果放在以前，這 75 行代碼需要我自己花兩個小時寫出來，我肯定不會這么隨便地去試?，F在則完全不同了。

有時我甚至會覺得自己像個國王，對手下說：“去調查一下遠方邊境的稅收情況。”以前，這種任務可能要三周之后才會帶著結果回來；現在，幾分鐘內就能得到答案。更有意思的是，很多一開始看起來很糟糕的想法，最后反而會變成真正的好主意。

比如 Omarchy 的用戶一直希望能支持 dual-boot，這樣他們就可以同時保留 Windows 來玩游戲。但這并不是我自己的需求，所以我一直懶得處理。直到最近，我突然意識到：這恰恰就是最適合交給 Agent 的那類問題。

于是我讓 Opus 和 Codex 先圍繞實現方案來回討論，讓它們彼此評審計劃，反復迭代了幾輪。最后我看了一眼方案，說：很好，這完全可以做。接下來只需要啟動實現流程即可。

這種“順手啟動一個大型改動項目”的能力，到現在我自己都還沒有完全適應。放在以前，這種事情一定會被拖到“以后再說”；但現在，甚至可以在吃午飯的時候順手把它啟動起來。

主持人：這確實像是一個全新的世界。即使模型能力從現在開始不再繼續進步，我們可能也還需要十年，才能真正學會如何把它們的潛力發揮到極致。

DHH：完全正確。就像當年 Commodore 64 剛發布時的那些游戲，和 20 年后開發者把硬件潛力幾乎榨干之后做出來的作品相比，看上去簡直像來自兩個時代。PlayStation 也是一樣：首發時期的游戲，和生命周期末期的游戲，幾乎不像是同一代主機上的產品。

所以，即使模型能力從這一刻起停止增長，我們仍然可以花上十年時間，去學習如何更好地使用它們。更何況，現實并不是這樣——現實是，幾乎每三個月，就會出現一個更強的新模型。

主持人：那當團隊生產力突然提升之后，你們是否考慮擴大團隊規模？還是保持原來的規模？

DHH：以我們目前的情況來看，同樣的人可以完成更多事情，這就已經足夠了。事實上，我們一直都有能力擴張團隊，只是沒有那么多足夠好的想法值得擴張而已?，F在這些新增生產力正好可以用來推進像 P1 這樣的項目，它們確實能讓產品變得更好。

過去那種“一個重要功能需要兩個月才能完成”的思維方式，其實已經過時了。這種變化遲早會影響整個軟件開發方法論體系，比如 Shape Up 原本是圍繞兩個月周期設計的，但現在這個節奏顯然已經不再合理。當然，目前還沒有哪家公司真正完成了這套方法論的重寫，因為變化發生得實在太快了。當發布速度越來越快時，你就必須更嚴格控制上線流程，并持續驗證功能是否真的有效。

程序員職業的“黃金時代”可能已經快走到頭了

主持人：我們繼續回到剛才那個問題，開發者即將面對的變化。

DHH：我認為，如果一個軟件工程師到現在還沒有意識到變化正在到來，那多少有點自欺欺人。過去，開發者之所以能夠獲得高薪，很大程度上是因為他們曾經是生產能力的瓶頸：能寫代碼的人相對有限，所以他們的時間格外值錢?？梢坏┻@個瓶頸開始松動——比如產品經理自己都能做出可上線的功能——整個行業的結構就會隨之改變。

如果讓我下注，我會說：程序員職業的“黃金時代”可能已經快走到頭了。那些需要經過多年訓練、教育和長期技能積累才能成為程序員的人，未來未必還需要像今天這么多，才能完成同樣規模的軟件工作。

當然，Jevons 悖論依然成立：當一件事變得更便宜時，人們通常會消費得更多。但這并不意味著所有程序員都會因此受益。軟件的總產量當然會比歷史上任何時候都更高，可這并不等于每一個人都會被需求增長“拯救”。

順便說一句，我覺得 GitHub 最近其實也承受了不少批評，而且其中很多批評并非沒有道理。我看到過一個統計，說它的 uptime 只有 92%。這個數字聽起來確實有點離譜——雖然我并不確定它具體是怎么測出來的——但我完全能理解為什么人們會產生這樣的感受。

另一方面，我也多少有點同情他們。因為現在整個世界的軟件生產量正在呈火箭式增長。作為一個文明整體，我們正在以前所未有的速度制造軟件。比如 OpenClaw，本身就已經有大約 40 萬行代碼。過去要做到這個規模，可能需要十年時間。再比如 Shopify 的主單體倉庫，大概有 300 萬行代碼，那是二十年的積累。如果把所有參與過這個項目的工程師人數加起來，大概可能接近兩萬人次。

所以現在確實正在發生巨大變化，軟件產量正在迅速上升。我可以理解為什么 GitHub 這樣的基礎設施開始出現壓力，因為提交量只會繼續加速增長。

而且，某種意義上說，我們甚至還沒有真正開始。如果你去看 AI 在企業里的采用曲線，就會發現絕大多數公司其實根本還沒有開始真正使用 AI。我們身處 X 上的技術圈子，很容易產生一種“所有人都已經在用 AI”的錯覺，但現實世界并不是這樣。

當然，ChatGPT 很快就達到了 8 億用戶規模，這說明大規模普及本身確實存在。但距離那些最先進公司內部真實發生的生產力加速，我們依然還有很長的路要走。

所以我認為，一個普通程序員如果開始擔心：程序員的“黃金時代”是不是已經過去了——這種擔心其實完全合理。未來幾乎肯定會出現價格壓力。

因為不同類型的公司，將會受到完全不同的影響。像我們這樣的公司，幾乎總有無限空間去構建新功能，可以把新增的生產力不斷投入到產品擴展之中；但也有很多公司，它們只需要完成某一件非常明確的事情。如果它們能用十分之一的成本把這件事做完，那本身就是巨大的優勢。

而在那些把軟件開發視為成本中心的組織里——事實上，這類組織可能構成了全球軟件開發活動中的大多數——這種壓力只會體現得更加明顯。

主持人：聽起來，如果我是軟件工程師，現在最重要的一件事，是確保自己不在“成本中心”崗位上，或者至少要讓自己在那里變得不可替代。另外我也在想，未來公司招聘的軟件工程師畫像可能會繼續變化。

如果回顧過去幾十年的變化路徑：90 年代的軟件工程師形象是那種只寫匯編、不怎么說話的技術宅；到了 2000 年代，仍然主要按語言技能招聘；到了 2010 年代，很多創業公司開始按算法能力招聘，因為語言可以后學。而現在我看到一些最新融資的公司在招聘 product engineer 時，已經明確把同理心、溝通能力這類能力寫進要求里——默認你會寫代碼，只不過是最基礎的門檻而已。而且我最近接觸到的很多開發者，也確實越來越符合這種畫像：他們大多非常善于溝通，也愿意直接和客戶交流；他們并不把這件事看成負擔，甚至還樂在其中。

DHH：因為真正稀缺的能力已經變了。現在真正稀缺的是：我們應該構建什么？應該怎么構建？應該和哪些客戶交流？應該把注意力放在哪里？這些問題本質上就是產品管理問題。

說實話，這對我來說也挺有意思的。因為過去我并沒有特別高看產品經理這個角色。我覺得這個崗位里確實有不少水分，有些人也確實沒有真正做出太多實質貢獻。但其中一個重要原因是：他們當時根本沒有成為瓶頸資源的條件。

真正的瓶頸在實現環節。產品經理可以提出一個想法，但必須等待四周，才能讓昂貴的程序員把它變成現實。在這四周里，他們其實也做不了太多事情，所以看起來像是被低效利用。而現在，這個結構正在發生變化。純實現能力，在某一天會被解決。

我不是說現在已經解決了——任何試過把 Agent 生成代碼未經審查直接部署進大型代碼庫的人都知道，這還遠遠不現實。但就像去年夏天我在 Lex 播客里說過的，我也不會再賭它一年之內不可能發生。

主持人：這可以說是一種常識性判斷：在通用場景下，“實現”這件事遲早會被解決。對于一些邊緣場景，它可能需要更長時間；還有少數特殊領域，可能始終不完全適合自動化。就像自動駕駛一樣——對普通乘用車來說已經基本可行，但對卡車這種復雜場景，落地可能更慢，或者需要更專門化的方案。不過整體趨勢是明確的：這些“例外區域”會越來越小。

DHH：所以我確實認為，那種“我只想安靜坐著寫代碼”的工程師形象，將來只有極少數人還能維持。你必須達到 John Carmack 那個級別，才有資格繼續只做實現工作。

主持人：就連 John Carmack 自己，其實也是非常強烈擁抱 AI 的人，他同時也是一個技術方向的引領者。更重要的是，他當年還能準確判斷市場趨勢，比如什么類型的游戲會有人買。這意味著他不僅僅是技術高手，還具備商業判斷能力，或者至少身邊有這樣的人跟他協作。

DHH：所以現實是：你必須成為行業里最頂尖的一小撮人。而且還不只是“非常優秀”這么簡單，你還必須比現成的 Agent 更強，才能繼續享有“只負責實現”的這種特權。

給想成為頂尖工程師的人的建議

主持人：那么問題來了：真正的頂尖工程師到底是什么樣的人？以及，如果有人現在想成為“這個時代最優秀的工程師”，你會給他們什么建議？

DHH：這是個非常好的問題。但老實說，沒有人真正能回答這個問題。

我這么說，是因為我們已經看過成千上萬份申請。雖然不像 Google 那樣動輒幾百萬份，但數量也已經相當可觀了。而真正被錄用的程序員，其實非常少。即便是這些最終錄用的人，也并不是全部都長期留下來了。我們最近統計過，招聘成功率最多也就是略高于 50%。也就是說，就算經歷了完整嚴格的篩選流程，最終仍然有接近一半的人并不適合長期合作。所以現實情況是：沒有任何組織能夠把招聘做成一門精確科學。

Google 很早之前就發布過一篇研究論文，嘗試分析是否可以通過常見指標預測員工表現，比如名校背景、GPA、算法題成績等等。結論基本是：這些指標幾乎沒有預測能力。換句話說，我們其實并不知道如何準確預測誰會成功。

另一方面，我自己也承認，我的判斷標準某種程度上被“慣壞了”。因為我長期和非常優秀的人一起工作，不僅是在公司內部，也包括開源社區。結果就是，我對“普通程序員水平”的認知可能被扭曲了。

每次招聘時，我幾乎都會有同樣的感受：大多數申請材料其實都很一般，很多人甚至沒有認真準備，去真正展示自己的能力。這聽起來也許像老派抱怨，但現實就是——如果你想拿到一份工作，你必須讓自己明顯地脫穎而出。

我知道這讓人不舒服，因為它意味著競爭非常激烈。但把招聘理解成一個簡單的概率問題其實是錯的。很多人會想：一千個申請者，只錄用一個，那我被錄取的概率就是千分之一?？墒聦嵅⒉皇沁@樣。那一千個人里，大多數人的概率其實是零；真正準備充分、表現最好的那幾個人，概率可能是 10%、20%，甚至 30%。

通常在第一輪，我們就會直接淘汰至少一半申請者，有時甚至會淘汰三分之二。原因很簡單：他們沒有針對崗位準備申請材料，沒有按照招聘說明提交內容，或者顯然不符合崗位要求。剩下的人里，大約只有三分之一能進入下一輪，然后我們再篩到大概二十人，發放筆試作業測試。

很多人不喜歡這種測試，覺得那是在提供免費勞動力。我其實不太理解這種看法——難道你會覺得我們真的會把這些測試代碼直接部署到生產環境里嗎？這些題目本來就是專門設計出來評估能力的。

當然，我也理解另一種顧慮：如果要花六個小時做測試，最后卻沒有任何結果，確實會讓人不愿意投入。但現實就是，這件事沒有捷徑。你不可能只投一份簡歷，再接一個 30 分鐘電話，就順利被錄用。自從我進入這個行業以來，我從沒見過這種事。

主持人：除非有特別強的內部推薦。

DHH：對，只有這種情況才可能發生。而且這種情況通常只發生在公司非常早期的階段，比如創始團隊搭建時期。那時候大家是基于長期合作經驗建立信任，比如“我和這個人一起工作過兩年，我可以完全信任他”。事實上，如果看長期成功率，通過這種“強推薦”進入公司的員工，比公開招聘進入公司的員工更容易長期留下來。

說實話，通過公開招聘找到真正適合我們的工程師，一直都非常困難。當然也有成功案例，所以我仍然愿意相信這條路徑是可行的。但如果你把概率算清楚，會發現確實非常低。而強推薦路徑成功率明顯更高。

但問題是，這對大多數人來說并不是可執行建議。真正可執行的建議只有一個：盡可能提升自己的能力，并且認真對待你正在工作的地方。

很多人會覺得，如果自己所在公司不好，就沒必要努力。這其實是在傷害自己。你在一個不理想的公司里工作，然后決定隨便應付、刷刷 Reddit、看看 X，那你未來最有可能獲得推薦的人是誰？恰恰是那些和你一起工作過的人。而他們只會推薦那些即使在糟糕環境中，仍然認真工作、持續學習、持續交付的人。

你必須變得足夠優秀。而如果你不練習，就不可能變得優秀。如果你覺得當前公司“不值得你認真投入”，那其實是在限制自己。因為優秀公司招聘的是那些能夠持續提高標準的人。

就算你不喜歡老板，也沒關系。我職業生涯早期合作過的大多數老板，我也談不上特別喜歡。但我仍然努力工作，因為那是為了我自己的成長，也是為了讓我成為那種“機會來臨時已經準備好的人”。當所有能力都被打磨到位、所有技能都成熟時，你才真正有資格抓住機會。

主持人：這其實和你進入 37signals 的經歷很像吧？當時那只是一個合同崗位，你對產品也沒有所有權，但你依然全力投入。結果 Jason 后來意識到：“這個家伙必須給點股份，否則留不住。”這其實是一個挺典型的故事。

DHH：沒錯，不過這種故事本身就是典型的“創始人敘事”，不能輕易外推成一種通用路徑。幾乎所有創始人故事都有這個特點。但其中真正具有普適性的原則，其實很簡單：愿意出現，愿意投入，努力做到最好，并且持續學習。

還有一點是我后來有些后悔的——在某種程度上，我自己也曾助長過一種觀念：好像你可以成為一個優秀的程序員，卻并不真正喜歡編程；好像你也不需要在工作之外繼續關心這件事。

主持人：這是你當時的真實想法嗎？

DHH：某種程度上是的，不過這是一個誤解。因為我當時是在反對那種“每周工作 100 小時甚至 120 小時”的極端文化。但那從來都不是我的工作方式。我們開發 Basecamp 的這 25 年里，一直基本保持平均每周工作 40 小時的節奏。

不過與此同時，就像我一開始說的，我是真的喜歡計算機。我會在業余時間折騰計算機，看新的技術，探索新的系統。這并不是那種“全天候給 Basecamp 客戶交付功能”的工作，而更像是一種興趣驅動的探索。但它確實一直存在。

而在 2010 年代，有一段時間行業形成了一種誤解：你完全可以不做這些事情，只要按時上班寫代碼就夠了。因為編程太稀缺了、太值錢了，公司幾乎愿意錄用任何人——哪怕這個人其實并不怎么在乎編程。

如果這種時代真的存在過，那它現在已經結束了。當年代碼訓練營（bootcamp） 的興起，其實就是一個很明顯的信號。這本來就是經濟體系應有的反應：當某個職業的薪資高到離譜，就意味著供給不足，于是自然會有更多人涌進來。這本身并沒有問題。只是那個階段，如今已經過去了。

主持人：我們剛才一直在討論一個問題：程序員的黃金時代是不是已經過去了？也許所謂的“黃金時代”，其實指的是——只要愿意投入幾個月甚至幾年時間學習，大多數人都可以進入這個行業。那時候你可以去大學，也可以去訓練營，只要投入時間，就能找到工作。面試不會嚴格查推薦人背景，甚至很多公司根本不做推薦人背調。

但現在這種情況可能正在結束。未來公司可能會越來越依賴推薦人調查，而且不只是確認“你是否在那里工作過”，還會深入了解你的能力表現。比如 Databricks 就很出名，他們不僅做推薦人調查，還會詳細追問：你是否愿意再次和這個人合作？他的弱點是什么？你是否還會再次錄用他？等等。

DHH：不過這里有個有意思的地方：所謂“程序員黃金時代結束”，聽起來像是會影響所有程序員，其實并不是這樣。真正優秀的程序員——甚至不用是全球最頂尖的那種，只要是很強的程序員——現在反而比以往任何時候都更有價值。因為他們最擅長利用 AI 帶來的加速能力。

而改變我看法的關鍵一點是：至少在 37signals 內部，以及我自己的體驗里，我現在做程序員的快樂程度，是自 2000 年代初第一次接觸 Ruby 以來最高的一次。那種感覺真的很像“剛發現 Ruby 的時候”。

你可以在多個維度同時高速推進：探索 P1 指標優化、思考 Omarchy 的 dual-boot 支持、快速嘗試各種新想法——整個工作過程本身變得前所未有地有趣。而我看到我們團隊里那些最積極使用 AI 的程序員，也有同樣的體驗。雖然他們也會有一些焦慮，但這種焦慮往往被“創造能力突然增強”的興奮感壓過去了。

所以現在其實出現了一種分化狀態：我們一方面知道未來充滿不確定性，這確實會帶來焦慮，尤其當你的收入關系到孩子七年后的大學學費時，這種焦慮完全可以理解。但問題是，這種焦慮本身并不能轉化成任何建設性行動。唯一有效的路徑，就是主動投入進去。

如果你只是坐在那里反復思考七年后的世界會變成什么樣，那其實是在浪費時間。真正可行的路徑只有一個：開始使用這些工具，而且通常這并不需要太大努力。比如把一個你以前一直沒完成的業余項目拿出來，用模型試試看。如果你真的喜歡計算機，我很難想象你不會覺得這個過程有趣。

我也看到很多人正在進入這樣一個階段，比如 Kent Beck。他寫程序已經 52 年了，但他說自己現在依然非常享受編程。最近他在做一個一直想做的項目——實現一個 Smalltalk 服務器。過去這類事情可能要花很久才能完成，而現在，它正在逐漸接近成型。與此同時，他還能住在湖邊的房子里，寫到一半停下來，看兩個小時的鳥，然后再回來繼續寫代碼。

順便說一句，Kent Beck 一直都是我的偶像之一。2001 年我剛開始編程的時候，曾在丹麥的一次會議上聽過他的演講，當時我完全被他的表達能力和思想深度震住了。在那之前我已經讀過《Extreme Programming》之類的書，而他的《Smalltalk Best Practice Patterns》到今天仍然是我最推薦的編程書之一。如果你真的想理解方法設計、類結構設計這些更偏“戰術層面”的編程模式，那本書是最好的材料之一。所以看到他現在既在使用 Agent，又還能悠閑地去看鳥，我覺得非常棒。

不過也有一個現實變化：我觀察到很多真正“all-in AI”的人，現在反而比以前工作得更努力了。我自己也是這樣。當你只需要用一小時監督 Agent，就能產生這么大的影響力時，那種效率帶來的興奮感是非常容易讓人上癮的。

如果你是那種對“發布成果”會產生多巴胺反饋的人，現在這種反饋幾乎是過載狀態。但我也不斷提醒自己：這不是限時促銷活動。AI 下個月還在，之后幾年也還在，不需要把所有興奮感都壓縮在兩周之內消耗完。

我覺得對那些最深入使用這些工具的人來說，現在最大的挑戰反而是：不要被它吞沒。因為正如那句老話說的——現在已經是它們最弱的時候了。未來只會越來越強。所以你更應該想辦法保持節奏，而不是被興奮感徹底帶著跑。

主持人：這種“被卷進去”的狀態確實存在。比如 Steve Yegge 最近看起來就有點疲憊——雖然他自己也很坦誠地說，他確實被這波變化吸進去了。他身邊很多朋友也是這樣。你現在顯然已經是深度使用 AI 的人之一，那你是怎么保持平衡的？比如我記得你以前提到過睡眠的重要性，而且你甚至不用鬧鐘？

DHH：是的，我基本不用鬧鐘。當然現在我妻子會用，因為孩子要按時上學。但對我來說，每晚睡滿八小時，是對認知能力最好的投資。只要少睡兩小時，比如從八小時變成六小時，你接下來那 18 小時的狀態都會明顯下降。這是一筆非常糟糕的交換。

我偶爾確實也會失眠，比如最近圍繞 AI 這些事情，有幾次腦子轉得太快睡不著。不過這種情況非常少見。但無論如何，我認為最不應該犧牲的就是睡眠，其次是不應該犧牲健康。為了多做 Agent 工作而少鍛煉三小時，是一筆非常差的交易。如果你想保持頭腦清晰，整個系統都必須維持良好狀態。

我確實看到有些人現在已經有點過度消耗自己了，但問題是：這不是一場短跑，而是一場至少持續十年的變化過程。所以別透支健康，也別透支睡眠，更別透支飲食質量。哪怕只從短期效率來看，減少睡眠也完全沒有意義。連續三周每天少睡兩三個小時，你最后只會變成一團混亂的狀態，而不是更高效的人。

主持人：那我們最后換個角度聊聊。你其實早就可以退休了，完全可以去湖邊聽鳥叫。但你還是每天繼續寫代碼——過去是打開終端，現在是調度 Agent。到底是什么驅動你繼續做這些事情？以及接下來你最期待什么？

DHH：驅動我繼續工作的，其實就是我對計算機的熱愛。對我來說，這是最有趣、最值得投入時間的事情。當然，我也做很多別的事情，比如開賽車、陪孩子。但如果每天有八小時要投入到某件事情上，那最好的選擇依然是計算機。

從我五歲開始就是這樣。最早是電子游戲，而現在調度這些 Agent，其實某種程度上也像在玩策略游戲，比如在玩《星際爭霸》一樣指揮單位行動。所以不管是不是出于經濟原因，我都會繼續折騰計算機、理解它們的工作方式，并繼續創造新的東西。

很多人對“財富”的理解其實有誤區，他們以為財富是一個終點：達到之后就可以徹底躺平。但過去一百年的心理學研究早就說明，這種狀態并不會帶來幸福。如果你擁有無限時間，卻沒有目標和使命感，那并不會令人滿足。幾乎所有賣掉公司套現的創業者都是這樣：在海灘躺三周，然后又重新回來創業。

因為他們真正追求的，從來不是終點，而是過程本身。這種創造過程，就是意義本身，也是滿足感的來源。所以我會繼續做這些事情。不管是自己敲代碼，還是調度 Agent，還是向它們學習——我都會繼續和計算機打交道。

而且過去三個月之后，我現在已經非常堅定地投入到Agent 可訪問性（agent accessibility）這個方向上了。最近幾周我們就在開發新的 Basecamp CLI。這個過程也再次提醒我：我們還沒有達到 AGI。你當然可以讓 Agent 寫 CLI，但如果你希望它“剛剛好”，仍然需要人工參與優化。

不過我很樂意做這件事。我們很快就會發布 Basecamp 的 CLI，也會為其他產品推出類似工具。我現在非常關注一個問題：我們到底還能把這些能力推進到什么程度？

另外還有一點是，我現在每天早上都會產生一種新的沖動：醒來之后特別想看看世界又發生了什么變化。我甚至需要刻意控制自己不要一醒來就打開 X，因為變化實在太快了，我總想第一時間知道最新進展。這種好奇心短期內肯定不會消失。事實上，我現在比五年前更喜歡計算機了，這種感覺真的非常棒。

視頻原鏈接：

https://www.youtube.com/watch?v=JiWgKRgdgpI

會議推薦

世界模型的下一個突破在哪？Agent 從 Demo 到工程化還差什么？安全與可信這道坎怎么過？研發體系不重構，還能撐多久？

AICon 上海站 2026，4 大核心專題等你來：世界模型與多模態智能突破、Agent 架構與工程化實踐、Agent 安全與可信治理、企業級研發體系重構。14 個專題全面開放征稿。

誠摯邀請你登臺分享實戰經驗。AICon 2026，期待與你同行。

今日薦文

你也「在看」嗎？