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

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

這節(jié)課時(shí)長(zhǎng)4個(gè)小時(shí)，售價(jià)375美元，容量是40人，而瑪特賣完它只用了半個(gè)小時(shí)。

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

這就是Ralph。

簡(jiǎn)單來(lái)說，Ralph是一個(gè)Agent插件，開發(fā)者可以在輸入需求后就能當(dāng)個(gè)甩手掌柜。

它自己會(huì)監(jiān)督自己運(yùn)行，通過不斷的測(cè)試代碼，直至最后跑出完全符合需求的結(jié)果才會(huì)停止。

一個(gè)真實(shí)的使用場(chǎng)景是，在睡覺之前打開Ralph，輸入明天的開發(fā)內(nèi)容，到了第二天，Ralph就會(huì)完成所有代碼，等待你進(jìn)行最后審閱。

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

你唯一做的事情就是睡了個(gè)好覺。

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

要知道，哪怕是DeepSeek的主倉(cāng)庫(kù)，在上線后同樣的時(shí)間里，也才將近8000顆星星。

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

01

Ralph這個(gè)名字來(lái)源于動(dòng)畫《辛普森一家》中的一個(gè)角色，Ralph Wiggum。他的特點(diǎn)就是不太聰明，但是執(zhí)著不懈。

Ralph的開發(fā)者叫做杰弗里·亨特利（Geoffrey Huntley），不過在中文互聯(lián)網(wǎng)上，大家更愿意叫他的外號(hào)“澳洲放羊大叔”。

因?yàn)樗⒉皇钦嬲饬x上的程序員，實(shí)際上他是在澳大利亞以放牧為生。而且澳洲放羊大叔從不住房子里，只住在自己的房車?yán)铩?/p>

回歸正題，Ralph并非一個(gè)全新的、獨(dú)立的軟件產(chǎn)品，而更像是一種工作哲學(xué)或一套可被執(zhí)行的腳本，旨在讓現(xiàn)有的AI編程代理（如Anthropic的Claude Code、Cursor等）在你離開電腦時(shí)也能持續(xù)工作。

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

它的工作流程可以分解為幾個(gè)關(guān)鍵步驟。

第一步是任務(wù)分解。它要求開發(fā)者將一個(gè)龐大的功能需求，拆分成一系列足夠小、可獨(dú)立完成的原子任務(wù)。關(guān)鍵在于，每個(gè)小任務(wù)都必須有明確的、可被機(jī)器自動(dòng)檢測(cè)的“通過”或“失敗”標(biāo)準(zhǔn)。

模糊的指令，比如“讓界面更好看”，在這里是行不通的。任務(wù)必須是具體的，例如“添加一個(gè)優(yōu)先級(jí)列，其默認(rèn)值為中等”。

任務(wù)清單準(zhǔn)備好后，Ralph便開始循環(huán)執(zhí)行。

在每一輪迭代中，它會(huì)從任務(wù)列表中選擇一個(gè)尚未完成的任務(wù)。它會(huì)讀取項(xiàng)目的當(dāng)前狀態(tài)，包括git的版本歷史、記錄工作進(jìn)度的progress.txt文件，以及包含所有待辦事項(xiàng)的prd.json產(chǎn)品需求文檔。

然后，它會(huì)調(diào)用AI模型來(lái)編寫實(shí)現(xiàn)該任務(wù)所需的代碼。

代碼編寫完成后，流程自動(dòng)進(jìn)入測(cè)試環(huán)節(jié)。Ralph會(huì)運(yùn)行預(yù)設(shè)的測(cè)試腳本來(lái)驗(yàn)證新代碼是否正常工作，以及是否滿足了任務(wù)的驗(yàn)收標(biāo)準(zhǔn)。

如果測(cè)試通過，它會(huì)自動(dòng)將這次的代碼變更提交到git版本控制系統(tǒng)中，并在prd.json里將該任務(wù)標(biāo)記為完成。這次成功的經(jīng)驗(yàn)，連同可能遇到的問題和解決方案，會(huì)被記錄在progress.txt中，作為后續(xù)迭代的參考。

如果測(cè)試失敗，它不會(huì)停下來(lái)等待用戶干預(yù)，而是會(huì)將錯(cuò)誤信息記錄到errors.log文件中。在下一輪循環(huán)開始時(shí)，AI會(huì)讀取這些錯(cuò)誤日志，從中學(xué)習(xí)，并嘗試用不同的方法來(lái)解決同一個(gè)問題，避免重復(fù)之前的錯(cuò)誤。

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

當(dāng)開發(fā)者與AI進(jìn)行長(zhǎng)時(shí)間的連續(xù)對(duì)話，想要去構(gòu)建一個(gè)復(fù)雜功能時(shí)。隨著代碼量的增加和對(duì)話輪次的增多，AI會(huì)逐漸忘記最初的指令和約束。

它可能會(huì)開始自相矛盾，或者在修改一處代碼時(shí)無(wú)意中破壞了另一處的功能。最終，開發(fā)者發(fā)現(xiàn)自己像在照顧一個(gè)記憶力不佳的小學(xué)生，需要不斷提醒和糾正，效率大打折扣。

問題出在任務(wù)的規(guī)模上。

通常來(lái)說，一個(gè)功能包含二十個(gè)部分，AI試圖將所有細(xì)節(jié)都保留在它的短期記憶里時(shí)，它往往力不從心。

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

這意味著，莊閑和游戲app理論上它可以構(gòu)建無(wú)限復(fù)雜的軟件，而不會(huì)被越來(lái)越長(zhǎng)的對(duì)話歷史所困擾。

它不是沒有上下文，而是把記憶轉(zhuǎn)化成了結(jié)構(gòu)化的文件。

1. git歷史成為了AI的長(zhǎng)期記憶，每一次提交都是知識(shí)的積累。

2. progress.txt文件記錄了已完成的工作和當(dāng)前狀態(tài)，是項(xiàng)目進(jìn)度的流水賬。

3. prd.json文件是產(chǎn)品需求文檔，明確所有待完成的任務(wù)。

4. AGENTS.md文件是操作指南，記錄構(gòu)建和測(cè)試項(xiàng)目的具體方法。

5. errors.log用于下個(gè)循環(huán)時(shí)避免相同的錯(cuò)誤。

02

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

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

這行代碼的本質(zhì)是一個(gè)無(wú)限循環(huán)。它不斷地將一個(gè)包含指令的提示文件喂給一個(gè)AI代理，讓其反復(fù)迭代，直到外部條件被滿足才停止。

這個(gè)看似“笨拙”的循環(huán)，恰恰是Ralph模式的創(chuàng)新所在。

許多AI模型在完成一輪輸出后，會(huì)認(rèn)為任務(wù)已經(jīng)“差不多完成”并自行退出。它們可能會(huì)忽略掉測(cè)試、構(gòu)建、修復(fù)報(bào)錯(cuò)等關(guān)鍵的收尾步驟。

Ralph的機(jī)制則接管了AI的退出信號(hào)。例如，在與Claude Code集成時(shí)，一個(gè)插件會(huì)攔截AI的退出指令。

它會(huì)檢查工作成果是否滿足預(yù)設(shè)的完成條件，在輸出中是否包含一個(gè)特定的完成標(biāo)記。

如果沒有找到這個(gè)標(biāo)記，插件就不會(huì)讓AI進(jìn)程停止，而是強(qiáng)制它進(jìn)入下一輪迭代。這種機(jī)制讓整個(gè)開發(fā)流程脫離了人工的“卡點(diǎn)”，實(shí)現(xiàn)了從編碼到測(cè)試再到修正的完全自動(dòng)化。這是它能夠在開發(fā)者睡覺時(shí)也無(wú)人值守運(yùn)行的底層基礎(chǔ)。

然而，托管的關(guān)鍵并非簡(jiǎn)單地“讓AI一直跑下去”，而是“讓AI知道要跑到什么時(shí)候?yàn)橹埂薄?/p>

如果沒有一個(gè)明確的、可被機(jī)器理解的完成標(biāo)準(zhǔn)，AI自己的迭代循環(huán)就會(huì)變成無(wú)目的的資源消耗，最終產(chǎn)出的結(jié)果可能依然無(wú)法使用。

因此，Ralph模式強(qiáng)調(diào)在啟動(dòng)前就定義好明確、可量化、可被機(jī)器檢測(cè)的完成條件。這個(gè)條件被編碼在任務(wù)的驗(yàn)收標(biāo)準(zhǔn)中。

在每一輪循環(huán)的末尾，AI都會(huì)自行檢查這些條件。如果條件未滿足，它就會(huì)阻止自己退出，并觸發(fā)下一輪迭代。這個(gè)過程會(huì)一直持續(xù)，直到所有任務(wù)的驗(yàn)收標(biāo)準(zhǔn)都被滿足，最終的完成標(biāo)記出現(xiàn)為止。

這相當(dāng)于用機(jī)器替代了人工來(lái)完成“結(jié)果驗(yàn)收”這一環(huán)節(jié)。

這種模式也提供了兩種主要的協(xié)作方式。一種是“離線Ralph”（AFK Ralph），開發(fā)者在晚上睡覺前設(shè)定好任務(wù)，然后讓它通宵運(yùn)行。第二天早上醒來(lái)，新的功能可能已經(jīng)開發(fā)完成并等待審閱。這種方式適合那些需求明確、直接了當(dāng)?shù)娜蝿?wù)。

另一種是“手動(dòng)擋Ralph”（Hands-on Ralph），開發(fā)者一次只運(yùn)行一輪循環(huán)。在每一輪結(jié)束后，開發(fā)者會(huì)審查AI的提交，并在必要時(shí)進(jìn)行引導(dǎo)和調(diào)整。這種方式更適合那些復(fù)雜的、探索性的功能，開發(fā)者希望在過程中保持更多的控制權(quán)。

但即便是在手動(dòng)模式下，由于其結(jié)構(gòu)化的任務(wù)和清晰的反饋循環(huán)，它通常也比傳統(tǒng)的Vibe Coding要高效得多。

03

除了工作模式上的創(chuàng)新，Ralph的另一個(gè)顯著特點(diǎn)是其運(yùn)行成本相對(duì)較低。

根據(jù)一些開發(fā)者的分享，一次包含10輪迭代的典型Ralph運(yùn)行，其API調(diào)用成本大約在30美元左右。

有一位開發(fā)者使用這種模式交付、審查并測(cè)試了一個(gè)完整的應(yīng)用程序，總花費(fèi)不到300美元。

而在過去，他開發(fā)同等復(fù)雜度的產(chǎn)品，外包成本可能高達(dá)50000美元。

即使Ralph只能完成90%的工作，開發(fā)者只需花費(fèi)少量時(shí)間進(jìn)行最后的清理和收尾，也相當(dāng)于將數(shù)天的工作壓縮到了幾個(gè)小時(shí)。

這實(shí)際上有些反直覺，Ralph運(yùn)行多個(gè)循環(huán)，卻比其他產(chǎn)品要便宜。

Ralph低成本的原因，與它獨(dú)特的工作流程相關(guān)。

當(dāng)使用其他AI模型進(jìn)行長(zhǎng)對(duì)話時(shí)，為了讓模型記住半小時(shí)前討論過的內(nèi)容，每一次發(fā)送新請(qǐng)求時(shí)，通常需要將之前的全部聊天記錄重新發(fā)送給它。

隨著對(duì)話變長(zhǎng)，每次API調(diào)用所消耗的Token數(shù)量會(huì)呈指數(shù)級(jí)增長(zhǎng)，導(dǎo)致費(fèi)用急劇上升。

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

那么Ralph每次請(qǐng)求AI時(shí)，只需要提供與當(dāng)前任務(wù)相關(guān)的最少信息。完成任務(wù)后，這個(gè)短暫的上下文就被拋棄。因?yàn)樯舷挛暮芏蹋詥未握{(diào)用的成本非常低。

一些實(shí)際案例也印證了這種模式的潛力。在一個(gè)創(chuàng)業(yè)黑客松活動(dòng)中，有團(tuán)隊(duì)利用Ralph在一夜之間交付了6個(gè)不同的項(xiàng)目原型。澳洲放羊大叔本人，更是據(jù)稱在不到三個(gè)月的時(shí)間里，主要通過Ralph構(gòu)建了一門完整的編程語(yǔ)言。

嚴(yán)格意義來(lái)說Ralph沒有競(jìng)品，但Codeiu在2025年推出的Cascade可以在工程上實(shí)現(xiàn)和Ralph差不多的效果。

它和Ralph在目標(biāo)上是一致的，托管開發(fā)，直至最終完成復(fù)雜編程。但是它沒有Ralph那么簡(jiǎn)單直接，而是以“plan-act-verify”（規(guī)劃、執(zhí)行、驗(yàn)證）這個(gè)邏輯來(lái)運(yùn)行。

從代碼執(zhí)行上來(lái)講，Ralph是無(wú)限Bash循環(huán)+單次執(zhí)行。在第一次運(yùn)行之前，由于沒有建立logs，所以它就是會(huì)出錯(cuò)，然后再到第二個(gè)循環(huán)，根據(jù)以前出過的錯(cuò)改正。

而Cascade是先去規(guī)劃好整個(gè)流程，再執(zhí)行，最后驗(yàn)證。

由于經(jīng)過一開始的編排和規(guī)劃，它的編程和驗(yàn)證過程，都比Ralph的運(yùn)行時(shí)間要少。

但問題就在于，Cascade無(wú)法無(wú)限循環(huán)。所以存在一個(gè)閾值，一旦項(xiàng)目的復(fù)雜程度超過這個(gè)閾值，Cascade就無(wú)法實(shí)現(xiàn)像Ralph那樣的托管。

此外，一個(gè)圍繞Ralph的生態(tài)系統(tǒng)也正在快速形成。

Anthropic已經(jīng)將Ralph作為其AI編程工具Claude Code的官方插件之一。而前端開發(fā)平臺(tái)Vercel的實(shí)驗(yàn)室也發(fā)布了支持該模式的AI SDK版本。

這些官方和半官方的采納，表明Ralph模式已經(jīng)從一個(gè)項(xiàng)目，逐漸演變?yōu)橐环N被行業(yè)認(rèn)可的、解決實(shí)際問題的有效范式。