Codex 推出 /goal 功能，不達目標，不罷休
整理版優先睇
Codex 推出 /goal 功能，設定目標後 AI 會自動循環執行到完成，代表從「過程導向」轉向「目標導向」嘅人機協作新模式
呢篇文章係整理自 OpenAI 嘅 Codex CLI 新功能 /goal，同埋社區對 Ralph Loop 模式嘅討論。文章作者想帶出嘅核心問題係：點樣將 AI 嘅工作模式從「逐個步驟指示」變成「目標委託」，令 AI 自己不斷嘗試直到完成。
整體結論係：/goal 功能雖然只係實驗性，但佢代表咗一個重要趨勢——人類以後要專注嘅唔係點樣執行步驟，而係清楚定義自己想要嘅目標同點樣驗證結果。文章仲詳細介紹咗用法、防護機制同源碼分析，指出呢個功能嘅設計係為咗防止 AI 空轉或過早判斷完成。作者認為，呢個改變就好似從手繪地圖變成導航 App，人類只需要輸入目的地，路線由 AI 自己規劃。
- 結論：/goal 將 AI 協作從「你講一步我做一步」變為「你定目標我全程負責」，代表 Software 3.0 嘅趨勢。
- 方法：喺 Codex CLI 輸入 /goal 後加目標描述，AI 會自動循環執行，並有 /goal pause、/goal resume、/goal clear 等輔助命令。
- 差異：Codex 嘅 /goal 係「馬拉松」模式，同一會話持續追蹤目標，唔似社區 Ralph Loop 嘅「接力賽」模式每次重新開上下文。
- 啟發：人類嘅工作重心應該從過程監控轉向目標定義同結果驗證，呢個先係更考驗判斷力嘅部分。
- 可行動點：可以試用 Codex CLI 0.128.0 以上版本，喺 config.toml 啓用 goals 功能，並將詳細指令寫入 .md 文件用 /goal follow 執行。
Codex CLI 開源倉庫
OpenAI Codex CLI 官方開源倉庫，包含 /goal 功能源碼
Felipe Coury 原帖
介紹 /goal 功能嘅帖文
Ralph Loop 社區實現
一款開源嘅 Ralph Loop 模式實現，採用接力賽方式
Ralph Loop 同 /goal 嘅關係
Codex 嘅 /goal 功能背後有個概念叫 Ralph Loop，源自《辛普森一家》嘅 Ralph Wiggum，代表一種「設定目標後不斷嘗試直到成功」嘅 Agent 循環模式。社區原始實現用接力賽方式：每輪完結後重新開新上下文，靠 git 記錄保持記憶。
Ralph Loop
接力賽
而 Codex 嘅 /goal 就唔同，佢係同一會話入面持續循環，好似馬拉松選手，唔需要每次都重新嚟過。呢個分別令目標追蹤更連貫，減少上下文丟失。
馬拉松
點樣用 /goal 同輔助命令
先確保 Codex CLI 版本 >= 0.128.0，然後喺 ~/.codex/config.toml 加入配置啓用功能。之後喺 CLI 輸入 /goal 後面跟目標描述，AI 就會自動開工。
[features]
goals = true/goal 重構所有的數據庫查詢，添加連接池- /goal pause：暫停當前目標
- /goal resume：恢復暫停嘅目標
- /goal clear：清除目標
/goal follow instructions.md
如果目標描述太長，可以寫入 .md 文件，然後用 /goal follow 執行，咁就唔會被上下文壓縮而丟失細節。仲有個 /side 命令，可以喺唔打斷主線目標嘅情況下開分支會話問問題，問完按 Esc 返主線。
/side
上下文壓縮
防護機制：點樣防止空轉同提早收工
一個會自動循環嘅 Agent 最怕就係空轉或者過早判斷完成。Codex 設計咗幾層防護。
零工具調用抑制
如果一輪續跑中 Agent 冇調用任何工具（冇寫 code、冇 run command），系統會判定佢卡住咗，自動停止循環。
預算控制
每個目標可以設 token 預算同時間上限，超出時系統會提示模型總結進度，俾用戶下一步指示。
完成審計
- 1 將目標拆解成具體嘅可交付物
- 2 建立檢查清單，將每個需求映射到實際證據
- 3 檢查真實嘅文件、輸出、測試結果
- 4 唔可以只係因為「測試通過咗」就認為目標完成
呢個審計機制專門防止「代理證據接受」——即係模型將「我產出咗嘢」當成「我達成咗目標」。測試通過唔等於功能完成，呢啲係 Agent 循環最隱蔽嘅失敗模式。
代理證據接受
過早關閉
目標導向嘅意義
/goal 改變嘅唔係 AI 嘅能力邊界，而係人同 AI 嘅協作界面。從「你講一句我做一步」變成「你定目標我全程負責」，從對話變成委託。
過程導向
目標導向
呢個轉變好似從手繪地圖變成導航 App：以前你要自己規劃路線、記住每個路口；而家你只需要輸入目的地。Karpathy 喺 AI Ascent 演講入面將呢個趨勢總結為 Software 3.0 —— 從 how（點做）到 show（示範）再到 what（要乜）。
Software 3.0
作者→教練→指揮官
OpenAI 幫 Codex CLI 加咗個新指令，叫 /goal。
你畀佢設定一個目標，佢就不停咁行，跨多輪唔會丟失上下文，唔達到目的唔罷休。
呢個功能隨住 Codex CLI 0.128.0 版本推出，暫時仲係實驗性功能，要手動開啓。Codex 團隊嘅 Felipe Coury 係咁樣介紹佢嘅：
“ 令目標喺多個回合入面保持活躍。唔達成，就唔停。
而喺我睇嚟，呢個功能背後其實隱藏住一個趨勢：喺 AI 時代，過程開始變得冇咁重要，重要嘅，係目標。
01Ralph Loop
要理解 /goal，要先講下 Ralph Loop。
呢個名嚟自《阿森一族》入面嘅 Ralph Wiggum，嗰個「無知、執着、樂觀」嘅男仔。開發者 Geoffrey Huntley 用佢個名命名咗一種 Agent 循環模式：畀 Agent 設定一個目標，等佢自己不停疊代，失敗咗就重新嚟過，直到達成目標。
VentureBeat 甚至寫咗篇文章叫《Ralph Wiggum 點樣由阿森一族變成 AI 界最紅嘅名》。
喺開發社羣嘅原始實現入面，Ralph Loop 嘅做法比較「粗暴」：每一輪完結之後，Agent 從頭開始一個新嘅上下文窗口，靠 git 記錄同進度檔案嚟保持記憶。
相當於每次換班，都交一份書面交接。
而 Codex 嘅 /goal ，就採用咗唔同嘅路線。
佢係一個進程入面嘅持續循環，目標喺同一個會話入面跨輪次保持活躍，唔需要重新開一個新上下文。
換句話講，開發社羣嘅 Ralph Loop 好似接力賽，每一棒換個新人。
而 Codex 嘅 /goal，更加似一個馬拉松選手，由頭跑到尾，攰嘅時候可以抖下，但係唔會換人。
點樣用
用法好簡單。
首先要確保 Codex CLI 版本係 0.128.0 或以上，然後喺設定檔 ~/.codex/config.toml 入面加一段：
●●●
[features]
goals =true└
開咗之後，喺 Codex CLI 度輸入：
●●●
/goal 重構所有的數據庫查詢，添加連接池└
Codex 就會開始圍繞呢個目標持續工作，寫代碼、行測試、檢查結果，做完一輪如果目標未達成，佢會自動開下一輪。
另外，仲有幾個輔助指令：
• /goal pause：暫停當前目標
• /goal resume：恢復暫停咗嘅目標
• /goal clear：清除目標
如果你㩒 Ctrl+C 中斷，目標會自動暫停，下次恢復線程嘅時候會自動繼續。
一個實用嘅小技巧係：如果你嘅目標描述太長，直接寫喺指令度可能會出錯。可以將詳細嘅指示寫喺一個 .md 檔案裏面，然後用 /goal follow instructions.md 嚟執行。
呢個技巧我好耐之前就不停推薦過，放喺檔案仲有一個好處，就係唔會因為上下文壓縮而丟失細節。
呢個版本仲附帶咗一個 /side 指令，可以喺唔打斷主線目標嘅情況下，臨時開一個分支會話問問題。問完㩒 Esc 就返返主線，分支會話直接掉咗。呢兩個指令配合埋一齊，其實幾就手。
不過……呢個應該係為咗避嫌抄襲 Claude Code，否則直接叫 /btw 咪得囉
，見：Claude Code 新增 /btw 功能：等你喺 AI 做嘢嗰陣「插嘴」提問
唔會停，但係都唔蠢
一個會自動循環嘅 Agent，最令人擔心嘅就係：佢會唔會喺冇意義嘅嘢上空轉呢？
Codex 嘅實現入面做咗一套防護機制。
零工具調用抑制。如果一輪續跑入面，Agent 冇調用任何工具（冇寫代碼、冇行指令、冇讀檔案），系統會判定佢「卡住咗」，自動停止循環，直到有新嘅輸入先會重新觸發。
預算控制。每個目標可以設定 token 預算同時間上限。當消耗超出預算嗰陣，系統會注入一條提示，話畀模型知：唔好再開新任務，總結下進展，畀用戶一個明確嘅下一步。
完成審計協議。每次續跑開始嗰陣，系統會注入一條隱藏嘅 developer 指令，要求佢執行一套「完成審計」：
1. 將目標拆解成具體嘅可交付成果
2. 整一份檢查清單，將每個需求對應到實際證據
3. 檢查真實嘅檔案、輸出、測試結果
4. 唔可以淨係話「測試通過咗」就當目標完成
亦即係話，系統喺機制層面防止咗模型嘅一個常見問題：將「我產出咗嘢」錯當成「我達成咗目標」。
測試通過咗唔等於功能完成咗，代碼寫完咗唔等於需求滿足咗。呢種「代理證據接受」（proxy-evidence acceptance）係 Agent 循環入面最隱蔽嘅失敗模式之一。
04原始碼分析
Codex 係開源嘅，所以可以直接睇佢係點樣實現。我更新咗代碼之後叫 AI 幫我睇咗一次。
功能嘅核心邏輯喺 codex-rs/core/src/goals.rs 入面，大概 1570 行 Rust 代碼。
成個系統有三層：
持久化層： 目標狀態存喺 SQLite 數據庫入面，進程重開、線程恢復都唔會丟失。目標有四種狀態：Active（進行中）、Paused（暫停）、BudgetLimited（預算用盡）、Complete（完成）。
工具層： 系統向模型暴露咗三個工具：get_goal（讀取當前目標）、create_goal（創建目標）、update_goal（更新目標狀態）。
呢度有個關鍵嘅設計決策：模型只能夠將目標標記為「完成」，唔可以暫停或者恢復。 暫停同恢復，只有用戶先可以做到。
原始碼入面嘅邏輯係：
●●●
if args.status != ThreadGoalStatus::Complete {
return Err(FunctionCallError::RespondToModel(
"update_goal can only mark the existing goal complete"
));
}└
點解要咁樣設計呢？
呢個係為咗防止模型自己「偷懶」，覺得差唔多就畀自己暫停一下（係咪好有經驗？）。
所以，你設定咗目標之後，模型一係完成佢，一係你嚟叫停。
冇第三條路。
續跑層： 呢個係最核心嘅部分。每一輪完結之後，系統會執行一個檢查鏈：
1. 目標功能係咪開咗
2. 當前係咪有活躍嘅目標
3. 係咪有其他輪次喺度跑
4. 係咪有待處理嘅訊息隊列
5. 續跑係咪俾人抑制咗（前一輪零工具調用）
6. 當前係咪喺 Plan 模式（Plan 模式下目標會被忽略）
全部通過之後，系統會注入一條 developer 訊息，入麪包含目標描述、預算使用情況，同埋嗰套完成審計協議。然後新一輪開始。
仲有一個小細節：token 計算只統計非緩存嘅輸入 token 加上輸出 token。 緩存命中嘅部分唔計入預算。亦即係話，預算追蹤嘅係「新增嘅工作量」，重複讀取已有上下文唔收費。
呢個功能嘅開發者係 Eric Traut，亦即係 Pyright（Python 類型檢查器）嘅作者。Felipe Coury 話佢係「每日可以一齊做嘢嘅 GOAT 之一」。
05實驗性功能
當然啦，/goal 始終係實驗性功能，暫時亦有啲限制。
目前佢淨係喺 CLI 度用到，Codex 嘅桌面應用暫時未有呢個功能。
另外，如果 API 配額用曬，/goal 會陷入一個尷尬嘅循環 BUG：不停咁發請求，不停收到配額用盡嘅錯誤，然後繼續重試……有人叫佢做「ralph loop of errors」。
喺 Plan 模式下，目標系統會自動被忽略。亦即係話，你唔可以一邊規劃一邊設定目標，兩種模式係互斥嘅。
呢個都容易理解，目標係制定好目標，有啲奇怪……
不過從實際測試睇，當前嘅目標完成判斷依然存在「過早關閉」嘅問題。模型有時會因為產出咗某個 artifact 就以為目標完成咗，即使實際上只係做咗表面功夫。
最重要嘅，係目標
/goal 嘅代碼量唔大，概念都唔複雜。但係佢代表嘅方向，我覺得可能比大多數「重大更新」更加有意義。
因為佢改變嘅唔係 AI 嘅能力邊界，而係人同 AI 嘅協作界面。
由「你講一句我做一步」，變成「你定目標我全程負責」。
由「對話」，變成「委託」。
呢個背後嘅以終為始嘅思維方式嘅轉變，比功能本身更加值得思考。
我自己而家嘅編程入面，基本上都好少親手寫代碼嘅過程。我更加多嘅時間同精力放咗喺：我到底要達成咩目標？我點樣驗證呢個目標真係完成咗？
點樣制定正確嘅目標，點樣諗清楚到底要做啲咩，呢個其實先係更加考驗人、而且更加重要嘅判斷同工作。
以前我哋習慣咗「過程導向」嘅工作模式：先規劃步驟，再逐步執行，每一步都要人睇住。
但係 AI Agent 正正將呢套邏輯翻轉咗：你只需要定義終點，條路係 Agent 自己行出來嘅。
呢個同傳統編程嘅分別，就好似導航 App 同手繪地圖嘅分別。手繪地圖時代，你要自己規劃路線、記住每個路口。有咗導航之後，你只需要輸入目的地，至於行邊條路、點樣避塞車、邊度右轉，呢啲係導航嘅事。
而 Karpathy 喺最近 AI Ascent 嘅演講入面，都表達咗類似嘅判斷。佢將呢個趨勢總結為 Software 3.0（詳見前文：軟件 3.0 時代嚟臨）：
“ 傳統軟件自動化嘅係你可以規格化嘅嘢，而 AI 自動化嘅係你可以驗證嘅嘢。
三代軟件範式嘅演進主線，其實就係人類參與方式嘅變化。
由 how（話畀機器點樣做），到 show（示範畀機器睇點樣做），再到 what（話畀機器你要啲咩）。
/goal 功能，都算係呢條主線上面最新嘅一個註腳。
你定義目標，亦即係嗰個可驗證嘅終態。Agent 自己揾路徑。你驗證結果，佢負責過程。
當 Agent 開始管理自己嘅進度，而且可以真正達成設定嘅目標，人類唯一需要做好嘅事，就剩返一件：
諗清楚，自己到底想要啲咩。
◇ ◆ ◇
• Codex CLI 開源倉庫：https://github.com/openai/codex
• Felipe Coury 嘅原帖：https://x.com/fcoury/status/2049917871799636201
• Ralph Loop 開發社羣實現：https://github.com/Th0rgal/open-ralph-wiggum
OpenAI 給 Codex CLI 加了個新命令，叫 /goal。
你給它設一個目標，它就一直跑，跨多輪不丟上下文，不達目的不罷休。
這個功能隨 Codex CLI 0.128.0 版本發佈，目前還是實驗性功能，需要手動開啓。Codex 團隊的 Felipe Coury 是這樣介紹它的：
“ 讓目標在多個回合中保持活躍。不達成，就不停。
而在我看來，這個功能背後其實藏着一個趨勢：在 AI 時代，過程正在變得不那麼重要了，重要的，是目標。
01Ralph Loop
要理解 /goal，得先聊聊 Ralph Loop。
這個名字來自《辛普森一家》裏的 Ralph Wiggum，那個「無知、執着、樂觀」的小男孩。開發者 Geoffrey Huntley 用他的名字命名了一種 Agent 循環模式：給 Agent 設定一個目標，讓它自己不斷迭代，失敗了就重來，直到目標達成。
VentureBeat 甚至寫了篇文章叫《Ralph Wiggum 如何從辛普森一家變成 AI 界最火的名字》。
在社區的原始實現裏，Ralph Loop 的做法比較「暴力」：每一輪結束後，Agent 從頭開始一個新的上下文窗口，靠 git 記錄和進度文件來保持記憶。
相當於每次換班，都交一份書面交接。
而 Codex 的 /goal ，則採取了不同的路線。
它是一個進程內的持續循環，目標在同一個會話裏跨輪次保持活躍，不需要從頭啓動新上下文。
換句話說，社區的 Ralph Loop 像是接力賽，每一棒換個新人。
而 Codex 的 /goal，更像是一個馬拉松選手，從頭跑到尾，累了可以暫停，但不換人。
如何使用
用法很簡單。
先確保 Codex CLI 版本在 0.128.0 以上，然後在配置文件 ~/.codex/config.toml 里加一段：
●●●
[features]
goals =true└
開啓後，在 Codex CLI 裏輸入：
●●●
/goal 重構所有的數據庫查詢，添加連接池└
Codex 就會開始圍繞這個目標持續工作，寫代碼、跑測試、檢查結果，一輪做完如果目標沒達成，它會自動開啓下一輪。
此外，還有幾個輔助命令：
• /goal pause：暫停當前目標
• /goal resume：恢復暫停的目標
• /goal clear：清除目標
如果你按 Ctrl+C 中斷，目標會自動暫停，下次恢復線程時會自動繼續。
一個實用的小技巧是：如果你的目標描述太長，直接寫在命令裏可能會出錯。可以把詳細的指令寫在一個 .md 文件裏，然後用 /goal follow instructions.md 來執行。
這個技巧我好早前就反覆推薦過，放在文件裏還有個好處是，不會被上下文壓縮而丟失細節。
該版本還附帶了一個 /side 命令，可以在不打斷主線目標的情況下，臨時開一個分支會話問問題。問完按 Esc 就回到主線，分支會話直接丟棄。這兩個命令配合起來，其實挺順手的。
不過……這應該為了避嫌抄襲 Claude Code，不然直接叫 /btw 不就得了，見：Claude Code 新增 /btw 功能：讓你在 AI 幹活時「插嘴」提問
不會停，但也不傻
一個會自動循環的 Agent，最讓人擔心的就是：它會不會在無意義的事情上空轉呢？
Codex 的實現裏做了一套防護機制。
零工具調用抑制。如果一輪續跑中，Agent 沒有調用任何工具（沒寫代碼、沒跑命令、沒讀文件），系統會判定它「卡住了」，自動停止循環，直到有新的輸入才會重新觸發。
預算控制。每個目標可以設置 token 預算和時間上限。當消耗超出預算時，系統會注入一條提示，告訴模型：別再開新任務了，總結一下進展，給用戶一個明確的下一步。
完成審計協議。每次續跑開始時，系統會給模型注入一條隱藏的 developer 指令，要求它執行一套「完成審計」：
1. 把目標拆解成具體的可交付物
2. 建一份檢查清單，把每個需求映射到實際證據
3. 檢查真實的文件、輸出、測試結果
4. 不能僅憑「測試通過了」就認為目標完成
也就是說，系統在機制層面防止了模型的一種常見問題：把「我產出了東西」錯當成「我達成了目標」。
測試通過了不等於功能完成了，代碼寫完了不等於需求滿足了。這種「代理證據接受」（proxy-evidence acceptance）是 Agent 循環中最隱蔽的失敗模式之一。
04源碼分析
Codex 是開源的，所以可以直接來看它是怎麼實現的。我更新了代碼後讓 AI 給我翻了一把。
功能的核心邏輯在 codex-rs/core/src/goals.rs 裏，大約 1570 行 Rust 代碼。
整個系統有三層：
持久化層： 目標狀態存在 SQLite 數據庫裏，進程重啓、線程恢復都不會丟失。目標有四種狀態：Active（進行中）、Paused（暫停）、BudgetLimited（預算耗盡）、Complete（完成）。
工具層： 系統給模型暴露了三個工具：get_goal（讀取當前目標）、create_goal（創建目標）、update_goal（更新目標狀態）。
這裏有個關鍵的設計決策：模型只能把目標標記為「完成」，不能暫停或恢復。 暫停和恢復，只有用戶能做。
源碼裏的邏輯是：
●●●
if args.status != ThreadGoalStatus::Complete {
return Err(FunctionCallError::RespondToModel(
"update_goal can only mark the existing goal complete"
));
}└
為什麼這麼設計呢？
這是為了防止模型自己「偷懶」，覺得差不多了就給自己暫停一下（是不是很有經驗？）。
從而，在你設了目標之後，模型要麼完成它，要麼你來喊停。
沒有第三條路。
續跑層： 這是最核心的部分。每一輪結束後，系統會執行一個檢查鏈：
1. 目標功能是否開啓
2. 當前是否有活躍的目標
3. 是否有其他輪次在跑
4. 是否有待處理的消息隊列
5. 續跑是否被抑制（前一輪零工具調用）
6. 當前是否在 Plan 模式（Plan 模式下目標被忽略）
全部通過後，系統注入一條 developer 消息，包含目標描述、預算使用情況，和那套完成審計協議。然後新一輪開始。
還有個小細節：token 計算只統計非緩存的輸入 token 加上輸出 token。 緩存命中的部分不算入預算。也就是說，預算追蹤的是「新增的工作量」，復讀已有上下文不收費。
這個功能的開發者是 Eric Traut，也就是 Pyright（Python 類型檢查器）的作者。Felipe Coury 稱他是「每天能一起工作的 GOAT 之一」。
05實驗性功能
當然了，/goal 畢竟還是實驗性功能，目前也有一些侷限。
目前它只在 CLI 裏可用，Codex 的桌面應用暫時還沒有這個功能。
另外，如果 API 配額用完了，/goal 會陷入一個尷尬的循環 BUG：不斷髮請求，不斷收到配額耗盡的錯誤，然後繼續重試……有人稱之為「ralph loop of errors」。
在 Plan 模式下，目標系統會被自動忽略。也就是說，你不能一邊規劃一邊設目標，兩種模式是互斥的。
這倒是好理解，目標是制定好目標，有點奇怪……
不過從實測看，當前的目標完成判斷依然存在「過早關閉」的問題。模型有時候會因為產出了某個 artifact 就認為目標完成了，即使實際上只完成了表面工作。
最重要的，是目標
/goal 的代碼量不大，概念也不復雜。但它代表的方向，我想可能比大多數「重大更新」都更有意義。
因為它改變的並非 AI 的能力邊界，而是人和 AI 的協作界面。
從「你說一句我做一步」，變成「你定目標我全程負責」。
從「對話」，變成了「委託」。
這背後的以終為始的思維方式的轉變，比功能本身更值得思考。
我自己現在的編程中，也基本不太涉及動手編寫代碼的過程了。我更多的時間和精力花在了：我到底要達成什麼目標？我怎麼驗證這個目標真的完成了？
如何制定正確的目標，如何想清楚到底要做什麼，這其實才是更為考驗人的、也更為重要的判斷和工作。
過去我們習慣了「過程導向」的工作方式：先規劃步驟，再逐步執行，每一步都要人盯着。
但 AI Agent 正在把這套邏輯翻轉了過來：你只需要定義終點，路徑是 Agent 自己走出來的。
這和傳統編程的區別，就像導航 App 和手繪地圖的區別。手繪地圖時代，你得自己規劃路線、記住每個路口。有了導航之後，你只需要輸入目的地，至於走哪條路、怎麼避堵、哪裏右轉，那是導航的事了。
而 Karpathy 在最近 AI Ascent 的演講裏，也表達了類似的判斷。他把這個趨勢總結為 Software 3.0（見前文：軟件 3.0 時代來臨）：
“ 傳統軟件自動化的是你能規格化的東西，而 AI 自動化的是你能驗證的東西。
三代軟件範式的演進主線，其實就是人類參與方式的變化。
從 how（告訴機器怎麼做），到 show（給機器看該怎麼做），再到 what（告訴機器你要什麼）。
/goal 功能，也算是這條主線上最新的一個註腳。
你定義目標，也就是那個可驗證的終態。Agent 自己去找路徑。你驗證結果，它負責過程。
當 Agent 開始管理自己的進度，並能真正達成設定的目標，人類唯一需要做好的事情，就只剩下一件了：
想清楚，自己到底要什麼。
◇ ◆ ◇
• Codex CLI 開源倉庫：https://github.com/openai/codex
• Felipe Coury 的原帖：https://x.com/fcoury/status/2049917871799636201
• Ralph Loop 社區實現：https://github.com/Th0rgal/open-ralph-wiggum