看著像弱智，干活像戰神，這個黃胖子橫掃AI編程

編程大神瑪特·波科克（Matt Pocock），外號TypeScript巫師，他在最新的編程課里這么形容一個工具。

“之前你無論用哪個模型編程都只能得到半成品，AI只能做一些雜活。但是這玩意可不一樣，你能把整個待辦列表交給它解決?！?/p>

這節課時長4個小時，售價375美元，容量是40人，而瑪特賣完它只用了半個小時。

關注vibe coding的程序員們，這兩天一定被一個挖著鼻孔、面容癡呆、頭發稀疏，一只眼睛站崗、另一只眼睛放哨的黃色胖子刷屏了。

這就是Ralph。

簡單來說，Ralph是一個Agent插件，開發者可以在輸入需求后就能當個甩手掌柜。

它自己會監督自己運行，通過不斷的測試代碼，直至最后跑出完全符合需求的結果才會停止。

一個真實的使用場景是，在睡覺之前打開Ralph，輸入明天的開發內容，到了第二天，Ralph就會完成所有代碼，等待你進行最后審閱。

而你沒有花費1秒鐘在編程上，甚至更不用像使用之前的vibe coding工具那樣，守在電腦前，一行一行地幫著聽不懂話的AI改代碼。

你唯一做的事情就是睡了個好覺。

自從Ralph被上傳到Github以后，不到兩周時間就收獲了7000顆星星。這個速度非常恐怖，在Github上，即使是頭部爆款項目，兩周時間也很難突破7000顆星。

要知道，哪怕是DeepSeek的主倉庫，在上線后同樣的時間里，也才將近8000顆星星。

在線編程教育平臺Treehouse的創始人瑞安·卡松（Ryan Carson）更是直言，“所有人都在討論Ralph”（Everyone is raving about Ralph）。

01

Ralph這個名字來源于動畫《辛普森一家》中的一個角色，Ralph Wiggum。他的特點就是不太聰明，但是執著不懈。

Ralph的開發者叫做杰弗里·亨特利（Geoffrey Huntley），不過在中文互聯網上，大家更愿意叫他的外號“澳洲放羊大叔”。

因為他并不是真正意義上的程序員，實際上他是在澳大利亞以放牧為生。而且澳洲放羊大叔從不住房子里，只住在自己的房車里。

回歸正題，Ralph并非一個全新的、獨立的軟件產品，而更像是一種工作哲學或一套可被執行的腳本，旨在讓現有的AI編程代理（如Anthropic的Claude Code、Cursor等）在你離開電腦時也能持續工作。

用澳洲放羊大叔自己的話來說，Ralph的核心簡單到可以概括為一行代碼，但其威力卻不容小覷，就像while true一樣。

它的工作流程可以分解為幾個關鍵步驟。

第一步是任務分解。它要求開發者將一個龐大的功能需求，拆分成一系列足夠小、可獨立完成的原子任務。關鍵在于，每個小任務都必須有明確的、可被機器自動檢測的“通過”或“失敗”標準。

模糊的指令，比如“讓界面更好看”，在這里是行不通的。任務必須是具體的，例如“添加一個優先級列，其默認值為中等”。

任務清單準備好后，Ralph便開始循環執行。

在每一輪迭代中，它會從任務列表中選擇一個尚未完成的任務。它會讀取項目的當前狀態，包括git的版本歷史、記錄工作進度的progress.txt文件，以及包含所有待辦事項的prd.json產品需求文檔。

然后，它會調用AI模型來編寫實現該任務所需的代碼。

代碼編寫完成后，流程自動進入測試環節。Ralph會運行預設的測試腳本來驗證新代碼是否正常工作，以及是否滿足了任務的驗收標準。

如果測試通過，它會自動將這次的代碼變更提交到git版本控制系統中，并在prd.json里將該任務標記為完成。這次成功的經驗，連同可能遇到的問題和解決方案，會被記錄在progress.txt中，作為后續迭代的參考。

如果測試失敗，它不會停下來等待用戶干預，而是會將錯誤信息記錄到errors.log文件中。在下一輪循環開始時，AI會讀取這些錯誤日志，從中學習，并嘗試用不同的方法來解決同一個問題，避免重復之前的錯誤。

這種工作方式解決了當前AI編程工具普遍面臨的難題——上下文窗口限制。

當開發者與AI進行長時間的連續對話，想要去構建一個復雜功能時。隨著代碼量的增加和對話輪次的增多，AI會逐漸忘記最初的指令和約束。

它可能會開始自相矛盾，或者在修改一處代碼時無意中破壞了另一處的功能。最終，開發者發現自己像在照顧一個記憶力不佳的小學生，需要不斷提醒和糾正，效率大打折扣。

問題出在任務的規模上。

通常來說，一個功能包含二十個部分，AI試圖將所有細節都保留在它的短期記憶里時，它往往力不從心。

Ralph的策略有點像“少食多餐”。它每次只專注于一個極小的任務，完成后就通過git提交來固化成果，然后清空自己的短期記憶（上下文），以一個全新的、干凈的狀態迎接下一個任務。

這意味著，理論上它可以構建無限復雜的軟件，而不會被越來越長的對話歷史所困擾。

它不是沒有上下文，而是把記憶轉化成了結構化的文件。

1. git歷史成為了AI的長期記憶，每一次提交都是知識的積累。

2. progress.txt文件記錄了已完成的工作和當前狀態，是項目進度的流水賬。

3. prd.json文件是產品需求文檔，明確所有待完成的任務。

4. AGENTS.md文件是操作指南，記錄構建和測試項目的具體方法。

5. errors.log用于下個循環時避免相同的錯誤。

02

雖然前面講了那么多，但Ralph的核心機制可以被濃縮為一行簡單的Bash腳本：

while :; do cat PROMPT.md | claude-code ; done

這行代碼的本質是一個無限循環。它不斷地將一個包含指令的提示文件喂給一個AI代理，讓其反復迭代，直到外部條件被滿足才停止。

這個看似“笨拙”的循環，恰恰是Ralph模式的創新所在。

許多AI模型在完成一輪輸出后，會認為任務已經“差不多完成”并自行退出。它們可能會忽略掉測試、構建、修復報錯等關鍵的收尾步驟。

Ralph的機制則接管了AI的退出信號。例如，在與Claude Code集成時，一個插件會攔截AI的退出指令。

它會檢查工作成果是否滿足預設的完成條件，在輸出中是否包含一個特定的完成標記。

如果沒有找到這個標記，插件就不會讓AI進程停止，而是強制它進入下一輪迭代。這種機制讓整個開發流程脫離了人工的“卡點”，實現了從編碼到測試再到修正的完全自動化。這是它能夠在開發者睡覺時也無人值守運行的底層基礎。

然而，托管的關鍵并非簡單地“讓AI一直跑下去”，而是“讓AI知道要跑到什么時候為止”。

如果沒有一個明確的、可被機器理解的完成標準，AI自己的迭代循環就會變成無目的的資源消耗，最終產出的結果可能依然無法使用。

因此，Ralph模式強調在啟動前就定義好明確、可量化、可被機器檢測的完成條件。這個條件被編碼在任務的驗收標準中。

在每一輪循環的末尾，AI都會自行檢查這些條件。如果條件未滿足，它就會阻止自己退出，并觸發下一輪迭代。這個過程會一直持續，直到所有任務的驗收標準都被滿足，最終的完成標記出現為止。

這相當于用機器替代了人工來完成“結果驗收”這一環節。

這種模式也提供了兩種主要的協作方式。一種是“離線Ralph”（AFK Ralph），開發者在晚上睡覺前設定好任務，然后讓它通宵運行。第二天早上醒來，新的功能可能已經開發完成并等待審閱。這種方式適合那些需求明確、直接了當的任務。

另一種是“手動擋Ralph”（Hands-on Ralph），開發者一次只運行一輪循環。在每一輪結束后，開發者會審查AI的提交，并在必要時進行引導和調整。這種方式更適合那些復雜的、探索性的功能，開發者希望在過程中保持更多的控制權。

但即便是在手動模式下，由于其結構化的任務和清晰的反饋循環，它通常也比傳統的Vibe Coding要高效得多。

03

除了工作模式上的創新，Ralph的另一個顯著特點是其運行成本相對較低。

根據一些開發者的分享，一次包含10輪迭代的典型Ralph運行，其API調用成本大約在30美元左右。

有一位開發者使用這種模式交付、審查并測試了一個完整的應用程序，總花費不到300美元。

而在過去，他開發同等復雜度的產品，外包成本可能高達50000美元。

即使Ralph只能完成90%的工作，開發者只需花費少量時間進行最后的清理和收尾，也相當于將數天的工作壓縮到了幾個小時。

這實際上有些反直覺，Ralph運行多個循環，卻比其他產品要便宜。

Ralph低成本的原因，與它獨特的工作流程相關。

當使用其他AI模型進行長對話時，為了讓模型記住半小時前討論過的內容，每一次發送新請求時，通常需要將之前的全部聊天記錄重新發送給它。

隨著對話變長，每次API調用所消耗的Token數量會呈指數級增長，導致費用急劇上升。

前文提到，整個項目的“記憶”被存儲在git和本地文件中，而不是昂貴的AI模型上下文里。

那么Ralph每次請求AI時，只需要提供與當前任務相關的最少信息。完成任務后，這個短暫的上下文就被拋棄。因為上下文很短，所以單次調用的成本非常低。

一些實際案例也印證了這種模式的潛力。在一個創業黑客松活動中，有團隊利用Ralph在一夜之間交付了6個不同的項目原型。澳洲放羊大叔本人，更是據稱在不到三個月的時間里，主要通過Ralph構建了一門完整的編程語言。

嚴格意義來說Ralph沒有競品，但Codeiu在2025年推出的Cascade可以在工程上實現和Ralph差不多的效果。

它和Ralph在目標上是一致的，托管開發，直至最終完成復雜編程。但是它沒有Ralph那么簡單直接，而是以“plan-act-verify”（規劃、執行、驗證）這個邏輯來運行。

從代碼執行上來講，Ralph是無限Bash循環+單次執行。在第一次運行之前，由于沒有建立logs，所以它就是會出錯，然后再到第二個循環，根據以前出過的錯改正。

而Cascade是先去規劃好整個流程，再執行，最后驗證。

由于經過一開始的編排和規劃，它的編程和驗證過程，都比Ralph的運行時間要少。

但問題就在于，Cascade無法無限循環。所以存在一個閾值，一旦項目的復雜程度超過這個閾值，Cascade就無法實現像Ralph那樣的托管。

此外，一個圍繞Ralph的生態系統也正在快速形成。

Anthropic已經將Ralph作為其AI編程工具Claude Code的官方插件之一。而前端開發平臺Vercel的實驗室也發布了支持該模式的AI SDK版本。

這些官方和半官方的采納，表明Ralph模式已經從一個項目，逐漸演變為一種被行業認可的、解決實際問題的有效范式。