“如果你不能用300行代碼寫個Cursor，這行你就別待了！”Ralph Loop創造者、Claude Code核心技術設計者的暴論

編譯 | 宇琪

策劃 | Tina

“軟件開發已經死了，因為現在任何人都可以成為軟件開發者。過去六個月的變化比過去三十年都多，而大多數工程師還在當 Jira 工單猴子，渾然不覺自己已經站在了懸崖邊上。”

最近，Ralph Loop 的創造者 Geoffrey Huntley 在播客節目中與主持人 Hendrik Krack 展開了一場火花四濺的對話。

這套“癡呆但管用”的內存管理方法，如今已經被 Claude Code、Cursor、Copilot 等主流工具內置進去。

Ralph Loop 最早在 2025 年 7 月由 Geoffrey 提出，到 12 月前后開始在開發者社區發酵，并被 Claude Code 吸收到自己的 harness 里。它解決的問題是：當一個任務需要持續推進、反復檢查、不斷修正時，怎么讓 agent 不要跑一輪就停下。

在原始 Ralph Loop 里，agent 會先規劃、拆任務，再開啟新的 session，用干凈的上下文繼續推進。Claude Code 后來則進一步改進了這個 Loop：它沒有完全照搬這種多 session 方式，而是在單個 session 里加入循環機制，通過最大迭代次數、safe word 和 stop hook，讓 Claude 在任務沒完成時繼續跑下去。也就是說 Ralph Loop 最重要的意義是把 coding agent 從一次性生成，推向了長時間運行。

在這次播客中，他們從“軟件開發已死”的宣言聊到“K 型分化”下的職業生存法則，從 Ralph Loop 的“癡呆”設計哲學聊到代碼審查的“心理折磨”。

下文基于播客視頻整理，經 InfoQ 編輯。

太長不看版：

Q：軟件開發真的"不行"了嗎？那我怎么辦？

A：任何人用上 Cursor 都能生成代碼。如果你只把自己定義為"軟件開發者"，那現在人人都是了——你正在跟時薪 10.42 美元的崗位賽跑，麥當勞做漢堡都比這高。但"軟件工程師"依然稀缺。區別在于：你能不能用 300 行代碼構建一個 Coding Agent，并講清楚它的架構？解釋不清的話，你只是個"使用者"，不是"構建者"。

我們這一行之所以最先被 AI 沖擊，恰恰因為它可以被機械地驗證——軟件要么編譯通過，要么不通過。但模塊化、數據建模、安全這些沒法"一鍵驗證"的硬核能力，才是真正的護城河。

Q："工單猴子（ JIRA ticket monkeys）"還有轉型機會嗎？

A：有，但窗口期很短。技術不斷變化，過去六個月的變化比過去三十年都多，員工用時間和技能換錢。如果你公司禁止用 AI，這本身就是危險信號——就像當年禁止上云一樣，是在把你往死路上推。

Q：那我該重點學什么？

A：三個方向優先級最高：首先是軟件驗證——代碼生成已經免費了，但生成的東西對不對才是瓶頸。去了解 TLA+、Lean、Coq 這類定理證明器；再次是屬性測試、確定性系統測試——比單元測試高一個維度；最后是類型系統更強的語言（Rust、Haskell）——無效數據根本建模不了，編譯不過就拒絕幻覺，自然到不了代碼審查環節。Python 和 Ruby 生成完不跑一遍你不知道會不會炸，驗證成本太高。

Q：Ralph Loop 是什么？為什么都在聊它？

A：Ralph 很簡單：給一個目標，用最少的上下文，讓它自回歸地逼近結果，這是一種“癡呆”技術。最喜歡的用例是把一個開源項目從一種語言自動移植到另一種語言。比如.NET，轉變成 Rust。但記住： Python、Rust、Go、TS 是"被祝福"的語言，而 Ruby、Java、.NET、Kotlin，前沿實驗室根本不會自己內部去用這些。

Q：我該從哪開始？最緊急的一步是什么？

A： 如果你不能在幾個小時內重建 Cursor，你下次面試會非常艱難，因為那只是 300 行代碼的一個 while 循環。

以下是原文：

軟件開發已死

Geoffrey：軟件開發已經死了（ 譯者注 ：Geoffrey 在自己介紹這個 Loop 的博客曾說過：“軟件開發已死——是我親手毀了它”）因為現在任何人都可以成為軟件開發者，產品經理們也能直接“吐出”代碼來。但你得區分清楚：你是“寫代碼的人（coder）”，還是“軟件工程師（software engineer）”，這兩者之間有天壤之別。很多人一直只是在蒙混過關，把編程等同于敲鍵盤，現在這部分工作已經被取代了。任何人只要用上 Cursor 或類似的工具，就能生成代碼。而如果你把自己定義為“軟件開發者（software developer）”，恭喜你，現在人人都是軟件開發者了。你正在跟一個時薪只有 10.42 美元的崗位賽跑，拜托，在麥當勞做漢堡的時薪都比這高。

計算機一直以來都是有門檻的，你要么是那個學會讓計算機“可塑”的人，學編程、學如何塑造它、讓它服從你的意志，要么你就只能乖乖用別人給你的用戶界面。過去 30 年里，絕大多數人都是后者。但現在，這個局面被徹底翻轉了。他們現在擁有了讓計算機變得可塑的能力，他們現在也是“軟件開發者”了，但這絕不意味著他們是“軟件工程師”。

Hendrik：對我們這些過去一直深陷在“寫代碼”這件事里的軟件開發者來說，還剩下什么可做的？

Geoffrey：如果你能稱自己為“高級軟件開發者”或“高級軟件工程師”，那我問你：你能不能只用 300 行代碼就給我構建一個 Coding Agent？能不能在白板上畫出來，講清楚它的架構？如果你根本解釋不清這東西是怎么工作的，你只是一個消費者。

剩下可做的其實還有很多。軟件模塊化（modularity）、抽象（abstractions）、思考數據和數據庫非常重要，身份驗證、安全依然很難。但任何人都能隨手生成東西了，這確實改變了游戲規則。對于那些還在糾結“我到底還有沒有工作”的人，如果你保持好奇心，你就有工作。如果你在過去兩年里沒有保持好奇心，你就是可替代的。

K 型分化

Hendrik：你昨天發表了一個關于“K 型分化”（K-shape）的演講，我們正處在一條分岔路上，大家應該注意什么？

譯者注：K 型分化，是 Geoffrey Huntley 在 AI:Engineer Miami 大會演講中拋出的概念。如圖所示，往右上角走的是模型優先公司，往右下角走的是還在抗拒 AI 的傳統大公司。模型優先公司就像頂級掠食者，它們在潛空間中構建，人更少，可以像經典的初創公司那樣更靈活。傳統公司，通常不會擔心初創公司，因為初創公司要花很長時間才能進入市場來攻擊它。但在 K 型分化的概念中，隨著模型、工作流、實踐變得更好，運營得更精簡，會得到“坡上加坡”的加速效應，時間線將被加速、被壓縮。模型優先公司的收入數字，是指數級的，可以在利潤率上碾壓。

參考鏈接：https://www.youtube.com/watch?v=7Pkwv353DeI

Geoffrey：如果你的公司商業模式是 SaaS，按人頭收費，你要明白，沒有人知道未來會怎樣，包括我自己。任何聲稱自己百分百確定未來走向的人，都是在吹牛。但我們百分百確定的是，現在完成同樣的事情，你絕對需要更少的人。而如果你的公司靠向客戶收費賺錢，那些客戶也需要更少的人，那么你的收入基線就會變得非常不穩定，我們管這叫“遺留 SaaS”（legacy SaaS）。從財務角度來看，變化的不僅僅是我們的職業，整個單位經濟模型已經變了。

現在創始人正在思考新的單位經濟模型，比如，你能不能按“動作（action）”收費，而不是按人頭收費？假設我們現在做的這期視頻要被轉錄，你可以按轉錄次數收費，而不是按你的音視頻團隊有多少人來收費，或者按存儲錄像的每 GB 容量來收費，基于使用量的定價（utility-based pricing）正在成為新的趨勢。

當我們進入 K 型分化時，公司需要兩到三年時間來完成人員轉型，搞清楚如何用 AI，甚至先要搞清楚 AI 對它們到底有沒有用，很多公司正在強迫 AI 做它做不到的事。

與此同時，有一類新興公司，它們只有五到十個人，正在順著 AI 的趨勢構建產品，它們天生就是 AI native 公司。

Hendrik：我看到的未來是，我們會擁有更多的創業公司。我們現在有能力探索更多事情，構建更多東西。你覺得我們必須為一個擁有更多小公司、但每個公司規模更小的世界做好準備嗎？

Geoffrey：這就要說到杰文斯悖論（Jevons Paradox）了。我認為軟件開發者數量會爆炸性增長，因為現在人人都能當軟件開發者。所以，軟件工程師或開發者需要找到自己的區分度。軟件開發本質上已經變得免費了，不過是些 token，而 token 比人便宜。但接下來往哪兒走？

現在創業比歷史上任何時候都簡單。但問題在于，不是每個人都適合當企業家，大多數軟件工程師甚至不知道什么是產品工程師（product engineer）。如果他們不懂產品思維，就不可能成為好的創業者。這里有一個結構性障礙：如果你在一家遵循“豐田式 Spotify 敏捷流程”的公司工作，產品經理負責所有客戶研究，工程師只負責給 Jira 工單估點數、寫代碼，如果你只是個“Jira 工單猴子（JIRA ticket monkeys）”，那你完蛋了。產品經理也一樣，如果產品經理還在試圖說服別人該建什么，他們也完蛋了，因為產品經理現在可以用 AI 做客戶研究并直接構建產品。

Hendrik：如果我現在就是個“工單猴子”，該怎么辦？

Geoffrey：如果你在一家禁止使用 AI 的公司工作，你應該立刻辭職。我們這行一直是個“自動扶梯”，技術不斷變化，過去六個月的變化比過去三十年都多，員工用時間和技能換錢。還記得當年有人因為公司不上云而離職嗎？道理一樣。AI 不是 IntelliJ 那樣的工具，它更像一把吉他，你應該去彈它、去發現、去培養直覺：知道 AI 擅長什么、不擅長什么、在哪會翻車。如果你的公司禁止你學這個，你應該為了自己的職業生涯離開它。

Hendrik：這讓我想起，我在灣區計算機歷史博物館看到 1970 年代 IBM 的薪資表，軟件工程師下面竟然還有“打孔卡沖壓員”這個職位。你覺得軟件工程師也會變成博物館里的展品嗎？

Geoffrey：我不確定，軟件工廠（software factory）模式是否會持續存在，直到我們擁有更好的編程語言和形式化驗證方法。

Hendrik：但英語不就是現在的編程語言嗎？

Geoffrey：不，我覺得數學正在成為真正的編程語言，我們終于要真正定義“工程”的含義了。軟件工程師這個職位至少還會存在五到十年，我不認為它會馬上像打孔卡沖壓員一樣消失。但有一點是絕對確定的：現在，軟件開發，人人都能做。

Hendrik：這有點像印刷術的發明，突然之間所有人都能讀寫和分發知識了。

Ralph Loop：內存管理，刻意遺忘

Hendrik：聊聊你最近的成果，Ralph Loop。我現在就有一個 Claude bot 在 24/7 監督運行，幫我整合用戶反饋到 Jira 工單，再觸發 CodeRabbit 的規劃工作流，循環到審查通過，然后把已解決的問題發布到 GitHub。你最喜歡 Ralph Loop 的哪些用例？我的方向對嗎？

譯者注：Ralph Loop（拉爾夫循環）是 Geoffrey Huntley 提出的一種極簡的 AI Agent 工作模式。名字來源于《辛普森一家》的角色 Ralph Wiggum，寓意是“最簡單、最笨”的方法。它的核心做法是：為 Agent 分配一個單一的、明確的目標。將所有相關的上下文（規格、代碼、審計歷史等）“釘”在這個任務的周圍，形成一個聚焦的上下文數組。然后讓 Agent 在這個受控的邊界內循環執行，直到完成目標。簡單來說，Ralph Loop 就是把大語言模型有限的上下文窗口當作一個需要嚴苛管理的內存空間，通過給每個循環分配一個獨立、聚焦的“內存陣列”，來換取高任務成功率和低認知負載。

參考鏈接：https://www.youtube.com/watch?v=zX_Wq9wAyxI

Geoffrey：Ralph Loop 的本質是內存管理。上下文窗口就是一堆內存，用得越多，性能越差，所以我讓 LLM 自己決定什么最重要。一開始我像高指揮官一樣定義所有事情，后來我只給它一個任務列表，讓它自己選優先級。結果它居然能按正確的實現順序來，比如先做日志系統和審計追蹤，再處理數據庫。這讓我震驚：它有品味和判斷力了。

Ralph 很簡單：給一個目標，用最少的上下文，讓它自回歸地逼近結果，這是一種“癡呆”技術。別人都在搞復雜的 agent-to-agent 并行計算，我卻用小的順序循環，刻意遺忘、重新分配目標和上下文，效果驚人地好。它不完美，有漏洞，但它是增量的進步。

Hendrik：當我在 Claude Code 上嘗試這個概念時，我印象非常深刻。我產品的第一次迭代有大約 300-400 個用戶。周末跑完 Ralph Loop 回來，發現登錄按鈕不好使之類的好多小問題都被修了。雖然不是大的架構問題，但效果很驚艷。

Geoffrey：我最喜歡的用例是把一個開源項目從一種語言自動移植到另一種語言。我會把源碼給它，讓它把源碼縮減成產品經理式的規格說明和測試用例，然后告訴它創建一個查找表，再直接說“這是.NET，我要它變成 Rust”，然后扔 tokens 進去。我認為它改變了很多事情，比如，人們通常因為大的開源生態生態系統而采用某樣東西，選擇具有正確健全性、正確高級別能力、易于驗證的工具或編程語言。但我不再關心這個了，對于邊緣、小眾的東西，比如，你想用 OCaml？盡管用。以前大家說 OCaml 開源生態不夠大，現在無所謂，你直接生成就行。Ruby 的庫好？縮減一下，現在 OCaml 里也有了。

Hendrik：但訓練數據還是偏向流行框架吧？比如 Gemini 生成 Web 應用會選 React 而不是 Angular。

Geoffrey：我同意，這就像木工活，要順著木紋走，不要逆著木紋干。比如用 OCaml，訓練數據較少，但質量非常高。但如果你想做 Web，就會有點困難，你必須做上下文工程，比如"這是我的 OCaml 自定義框架如何工作的"，才能得到一個 Web 應用。而如果你直接說“我想要一個網站”，出來的就是一堆垃圾。現在 Python、Rust、Golang、TypeScript 算是“被祝福”的語言，因為前沿實驗室在用它們做自主軟件開發，軟件、模型都自己構建自己，它們在“dog fooding（內部自用）”這些語言。而 Ruby、Java、.NET、Kotlin，前沿實驗室根本不會自己內部去用這些，只是 benchmark 里的一個數字，所以選擇實驗室自己用的語言有戰略優勢。

代碼審查是“心理折磨”

Hendrik：你提到，你不再相信代碼審查了。怎么回事？

Geoffrey：我相信也不相信，關鍵在于我們怎么做。我一直在思考，應該采用一種基于風險分級的方法來決定是否需要代碼審查。現在的情況是非黑即白：你做了一個改動，就得追著同事到處跑，讓他們給你“打勾、打勾、打勾”，這到底給業務帶來了什么價值？很多時候，我們使用代碼審查的方式，不幸的是變成了對同事的騷擾和霸凌，往往價值極低。

Hendrik：我得反駁一下，代碼審查有學習價值，尤其是對初級工程師。

Geoffrey：是有，但你跟初級工程師聊聊，他們會說他們被批得體無完膚。它本應是指導，但指導并沒有發生在代碼審查中。全是吹毛求疵，那根本不是學習，是心理折磨。當然不是所有公司都這樣，但我們確實沒有用好代碼審查。它本應是指導，但并沒有做到。

最好的代碼審查方式一直是：盡早打開一個變更（CL），然后持續進行代碼審查，堆疊 PR（stack PRs），在每個增量上做審查，這才是指導型的方法。但看看所有企業或公司，代碼審查實際上已經變成了一個“橡皮圖章”，人們追著同事說“快給我蓋章、蓋章、蓋章”。它被奉為不可侵犯的神圣之物，但我們都知道它只是個幌子。不過它還是有價值的，因為它能捕捉回歸缺陷。

所以，我希望改變代碼審查的方式：默認不進行代碼審查。如果有人要更新營銷文案，直接發布，它只是文本。對于網站，發布。國際化、翻譯，發布。但如果是更關鍵的東西，比如給數據庫加索引，那就需要代碼審查。這就像值班（on-call）的哲學：如果半夜尋呼（paged）叫醒一個工程師，它應該鏈接到一個運行手冊，里面有明確的指示需要做什么。整個目標實際上是最小化發送給你團隊的尋呼數量，因為這被視為需要作為工程嚴謹性來完成的事情，但我們需要最小化我們做它的次數。而在代碼審查中，沒有人會想："我們如何最小化我們做的代碼審查數量？"

如果代碼審查是基于變更類型的風險分類觸發的呢？或者可以觸發一個 Agent，自動通知相關同事：“我跑了這段代碼路徑幾次，關于認證這塊，我覺得可以，但可能不夠，讓我們聽聽第二意見。”隨著模型越來越好，我們完全可以多跑幾輪代碼路徑，檢查安全和其他問題。我們可以做一些事情來減少代碼審查，或者重塑我們對代碼的思考方式，我們需要對發布的內容負責。我絕不是說我們需要完全的 YOLO，“永遠不做代碼審查”之類的，我只是認為我們應該有意識地思考，如何通過工程化來消除對代碼審查的需求，從而最小化需要代碼審查的次數。

Hendrik：那你的升級方案是什么？上次 AI 工程大會上，我和 Max Kanat-Alexander 聊過，他非常推崇代碼審查，并把通過代碼審查進行指導的做法奉為圭臬。如果我們按你設想的那樣“廢除”代碼審查，你打算如何向初級工程師和即將到來的新一代傳遞知識？

Geoffrey：現在很多組織正在強行把 AI 塞進工作流，他們嘴上不說，但員工能感覺到“不用 AI 就滾蛋”。這制造了一種焦慮：人們覺得自己在使用 AI 這件事上被審判。

我親眼見過這種場景，我們在一家公司推出了一個功能：所有人的 prompt 都是公開可見的。起初效果非常好，大家互相分享“如何撥弄 LLM 這把樂器才能彈出好曲子”，分享的是技巧，而不是結果，這是一種很棒的知識共享。但績效評估季一到，所有人都慌了。每個人都在拼命寫績效文檔，AI 使用突然變成了“強制任務”，焦慮瞬間蔓延。最后我們不得不關掉這個功能。

修復這種指導式的“師徒”關系是有方法的，其中一個是自動與同事共享 prompt，并建立“prompt 治理”機制。就像軟件物料清單一樣，每次代碼增量提交時，把用到的 prompt 也“蓋章”上去。但前提是必須有心理安全感，人們得愿意分享。而現在的問題是，人們害怕自己被評判，害怕自己“AI 用得不夠好”，而 AI 本身又在飛速變化，沒人知道什么才算“足夠好”，這整個系統是破碎的。

用語音輸入讓創造力流淌

Hendrik：以前我會花很多時間精心打磨 prompt，但現在我發現，用 Whisper Flow 這類語音輸入工具，直接把自己的想法“碎碎念”進去，效果反而更好。你覺得呢？

Geoffrey：Whisper Flow 或者任何語音輸入，絕對是上帝模式。我想讓大家思考一件事：當你寫作時，你通常有“寫作模式”和“編輯模式”兩種狀態。你寫一封郵件，但不會立刻發送，你需要時間和空間來思考。問題是，“先寫后改”是一項需要學習的技能，尤其是剛開始做內容創作、公開演講和寫作的人。而大多數人在打字時，會把“寫作”和“編輯”同時進行：打一個字，“不對，不是這個詞，換一個”。他們陷入了高度控制循環，這極大地限制了創造力的流動。

而語音輸入完全打破了這種限制。我會對 Claude 說：“去看看這個組件的 HTTP 庫，研究一下它。”然后繼續說：“現在我想做一個集成到零的東西。去研究一下我們所有的客戶端。這個零客戶端需要用到我們的 HTTP 客戶端。我需要你構建它，但在我喊‘動工’之前不許動手。”接著我會開始一個規劃會話，來回推演，像揉面團一樣探索它理解了什么。如果它不理解代碼庫的某個部分，我會說：“想搞清楚這個 HTTP 客戶端怎么做重試？我們有單獨的 HTTP 重試庫，別自己編。”整個對話過程就是我的 prompt，用語音輸入，你更富有表現力，產出也更好，因為它剝離了“編輯模式”。

Hendrik：對于那些處在“K 型”曲線頂端、走在好奇探索路徑上的人，他們該怎么做才能保持領先？

Geoffrey：軟件驗證。

Hendrik：所以我構建的所有東西都必須附帶單元測試、端到端測試……

Geoffrey：甚至更多。如果你想站在 K 型曲線的最頂端，你應該去玩一玩 TLA+、Lean 和 Coq，學習什么是定理證明器、如何驗證軟件。去思考，如果我們擁有更強大、驗證更嚴謹的編程語言，就能最大限度地減少代碼審查和人工干預。你可以搞單元測試，但如果你想站在最頂端，你應該研究屬性測試、確定性系統測試這些高階主題。因為代碼生成問題已經解決了，但生成的東西是不可驗證的。

如果你能用不同的技術或更強大的工具解決驗證問題，你就能比那些還在搞軟件工廠或用 Python 寫“Gas Town”的人獲得更好的結果。我不是在抨擊 Python，但從類型理論的角度看，它不是一個嚴謹的語言。你用 Python 生成代碼，不跑一遍你不知道它會不會炸，Ruby 也一樣，這意味著幻覺的驗證成本更高。而像 Rust、Haskell 這類語言，無效數據根本無法建模，它編譯不過，就會拒絕幻覺，生成周期就無法完成，無法提交 git，自然也就到不了代碼審查環節。

Hendrik：在結束之前，還有什么其他建議或分享嗎？

Geoffrey：我現在正在做 Latent Patterns，一個教育平臺，教大家基礎知識。比如，“上下文窗口本質上就是一個來回傳遞的數組”、“子 Agent 就是一塊可丟棄的內存堆”等等第一性原理，重點是教大家：AI 時代計算機科學的 CS 101 是什么？CS 102、103 又是什么？

我的建議是：現在就去自己構建一個 Agent。如果你不能在幾個小時內重建 Cursor，你下次面試會非常艱難，因為那只是 300 行代碼的一個 while 循環。幾周前在立陶宛的 PyCon 上，一個 13 歲的孩子在現場展示了自己搭建的 Coding Agent，把所有資深工程師都震住了。如果你是個資深工程師，卻不能從底層解釋 AI 和重建 Cursor，那你就不再是資深工程師了，你是初級工程師。資深工程師應該保持好奇，理解引擎的每個部件，并且能重建整個引擎。

Hendrik：我覺得這就是為什么 Dario Amodei 說過那句名言：軟件和軟件生成之所以遙遙領先，是 AI 最先解決的領域，因為軟件工程師一直是勞動力中最好奇的一群人。

Geoffrey：對，但能真正解釋清楚這些東西的人數低得驚人。而現在市場對懂得這些并能教會別人的人，需求高得離譜。我們這一行之所以能最先被 AI 解決，是因為它可以被機械地驗證——軟件要么編譯通過，要么不通過。現在我們有代碼審查，是因為它編譯通過了，但沒實現該實現的功能，或者有 bug。如果我們能把所有狀態建模成不可能編譯通過的狀態，就能減少代碼審查的數量。

訪談視頻原鏈接：https://www.youtube.com/watch?v=fbqAh46eMkc

其他相關鏈接：

https://www.youtube.com/watch?v=7Pkwv353DeI

https://www.youtube.com/watch?v=mR-WAvEPRwE

https://ghuntley.com/loop/

聲明：本文為 InfoQ 原創，不代表平臺觀點，也不構成投資建議，未經許可禁止轉載。

會議推薦

大會限時早鳥票享 8 折專屬優惠，現在報名立減 1160，更多詳情可掃碼或聯系票務經理 13269078023 進行咨詢。