Humanize：讓 Claude 寫、Codex 審的 RLCR 迭代迴圈

它想解決的是「單一模型自己審自己」

多數 AI 編碼流程的問題不是生成品質，而是驗證迴路只有一個模型。同一個模型寫完再自己檢查，通常會沿著同一套假設走一遍，錯誤與盲點一起被保留下來。Humanize 的 README 把這一點寫得很直白：One Build + One Review，Claude 負責實作，Codex 負責獨立審查。

它的目標讀者是已經在用 Claude Code 的開發者，而不是想找通用 agent 框架的人。專案本身是 Shell 撰寫的 Claude Code 外掛，README 說明它衍生自 GAAC（GitHub-as-a-Context）專案，當前版本標示為 1.16.0。核心概念裡有一條值得單獨看：Begin with the End in Mind，在迴圈開始前，Humanize 會先確認「你」理解自己即將執行的計畫。README 的說法是 The human must remain the architect。這句話其實是產品定位的宣告：它不打算取代你決定要做什麼，只打算接管做完之後的反覆修正。

RLCR 的兩相迴圈與嚴重度標記

RLCR 是 Ralph-Loop with Codex Review 的縮寫，README 指出它受官方 ralph-loop 外掛啟發，再疊上獨立的 Codex 審查。名稱同時也讀作 Reinforcement Learning with Code Review，對應的是「AI 產出的程式碼透過外部審查意見持續精煉」這個循環。

迴圈分成兩個階段。實作階段由 Claude 工作，Codex 審查的是摘要；程式碼審查階段則由 Codex 檢查程式碼品質，並帶有嚴重度標記。發現的問題會回饋到實作階段，直到解決為止。這裡有個容易忽略的細節：第一階段審的是摘要而非完整程式碼，第二階段才進到程式碼層級。也就是說，Codex 在早期是對「Claude 說自己做了什麼」做檢查，而不是對 diff 做檢查。這個設計能提早攔下方向錯誤，但如果 Claude 的摘要與實際改動有落差，第一階段的把關強度就會下降。

README 另外提到 Ralph Loop with Swarm Mode，迭代會持續到所有驗收條件滿足為止，並可選擇用 Agent Teams 平行化。驗收條件從哪裡來，README 沒有在這段說明，需要看 docs/usage.md。

從一句話到迴圈的實際指令順序

安裝走 Claude Code 的外掛市集。README 給的指令是先加入 PolyArch marketplace，再安裝外掛：

/plugin marketplace add PolyArch/humanize /plugin install humanize@PolyArch

如果要用開發分支的實驗功能，市集來源改成 PolyArch/humanize#dev。審查端需要 codex CLI，README 明講 Requires codex CLI for review，其餘前置條件指向 docs/install-for-claude.md。

接著是使用順序。第一步可選，從模糊想法生出草稿：

/humanize:gen-idea "add undo/redo to the editor"

輸出預設落在 .humanize/ideas/<slug>-<timestamp>.md，也可以直接傳入既有的 .md 粗略筆記讓它擴寫。--n 控制有幾條平行方向探索同一個想法，預設 6。第二步從草稿生計畫：

/humanize:gen-plan --input draft.md --output docs/plan.md

第三步在實作前處理被註記的計畫。當審查者在計畫裡留下註解，格式可以是 CMT: ... ENDCMT、<cmt> ... </cmt> 或 <comment> ... </comment>，用這道指令收斂：

/humanize:refine-plan --input docs/plan.md

第四步才進迴圈：

/humanize:start-rlcr-loop docs/plan.md

另外有一道需要 Gemini CLI 的指令 /humanize:ask-gemini，用於深度網路研究。監控要在另一個終端機執行，README 特別註明 not inside Claude Code。先 source 專案裡的 scripts/humanize.sh，或把它加進 .bashrc 或 .zshrc，然後用 humanize monitor rlcr、humanize monitor skill、humanize monitor codex、humanize monitor gemini 分別觀察迴圈、所有技能呼叫、Codex 呼叫與 Gemini 呼叫。

多了一個 CLI，就多了一條會斷的鏈

最明顯的限制是相依性。審查能力綁在 codex CLI 上，沒有它，One Build + One Review 的 Review 就不存在，整個 RLCR 的賣點會退化成單純的迭代生成。ask-gemini 同理，需要 Gemini CLI。等於說要完整使用 Humanize，你得同時具備 Claude Code、codex CLI，可能還有 Gemini CLI 三套工具與各自的額度。

第二個限制是審查的獨立性其實有邊界。Codex 是另一個模型，這降低了同源盲點，但第一階段審的是 Claude 產出的摘要，摘要本身就是被審對象自己寫的。如果實作偏離計畫而摘要沒反映出來，第一相的把關會漏。真正的程式碼層級檢查要等第二相。

第三，這套流程有前置成本。gen-idea 預設開 6 條平行方向，gen-plan 產出計畫檔，refine-plan 處理註解，然後才 start-rlcr-loop。對於改一行設定的工作，這個儀式感遠超過收益。它是為中大型、驗收條件講得清楚的工作設計的。

最後是授權資訊的不一致。README 的 License 段落寫 MIT，但倉庫中繼資料的 License 欄位是 unknown。這不必然是問題，但要發佈或商用前，請直接開 LICENSE 檔確認，不要只看 README 那一行。

跟單純用 Claude Code 或官方 ralph-loop 的差別

最直接的替代方案就是不安裝任何外掛，直接用 Claude Code 本身。差別在於審查者身分：原生用法裡，檢查程式碼的還是 Claude，或者是你本人。Humanize 把審查換成另一個模型，代價是你要維護 codex CLI 這條依賴。

另一個對照是 README 自己點名的官方 ralph-loop 外掛。Humanize 的 RLCR 是在 ralph-loop 之上加一層獨立 Codex 審查，所以如果你已經在用 ralph-loop 且滿意它的迭代行為，缺的只是外部審查，那 Humanize 的增量價值就集中在 Codex 那一相與嚴重度標記上。反過來說，如果你要的是完全自控、不引入第二個模型供應商的流程，這兩者都不適合。

還有一個方向上的差異值得一提：Humanize 的 gen-idea 與 gen-plan 把「想法到計畫」也納入管線，輸出成 .humanize/ideas/ 下的檔案與 docs/plan.md。這是把規格文件當成流程的一等公民，而不是讓 agent 直接從一句話開始改程式碼。README 的 topics 也列了 spec-coding，與這個取向一致。

維護成本與版本節奏

Humanize 目前沒有檢索到任何 release，README 只標示 Current Version: 1.16.0，更新紀錄要看倉庫本身。最後一次推送時間是 2026 年 8 月 28 日，專案未封存。README 開頭同時宣告 Humanize2 正在積極開發並徵求回饋，這意味著現在的 Humanize 之後可能出現遷移路徑，但素材裡沒有說明兩者的關係與相容性，無法判斷升級會不會需要改寫既有的計畫檔或設定。

設定方面，README 指向 docs/usage.md#configuration，說明有共享的 config 階層與覆寫規則，但具體的鍵名與優先順序不在這份素材裡，導入前應該先讀那一節。外掛是透過 /plugin marketplace add PolyArch/humanize 安裝的，日後要更新大概也走同一條市集路徑；README 另外提供 #dev 分支作為實驗功能的來源，如果你把開發分支加進市集，就要預期它會比主線更常變動。

授權是 MIT，這是寬鬆授權，但再次提醒倉庫中繼資料沒有回報授權欄位，兩者不一致時以倉庫內的 LICENSE 檔為準。這裡不構成法律意見。

編輯結論

Humanize 適合已經固定使用 Claude Code、手上又有 codex CLI 的個人或小團隊，尤其是那種「一次生成就上線」曾經出過事、願意用多輪審查換取穩定度的情境。如果你只想要一個指令生出程式碼、不想維護第二個 CLI 與外掛市集來源，或者你的流程根本不允許把程式碼送到外部模型審查，那它不適合。導入前先確認三件事：codex CLI 是否已安裝且可用、.humanize/ideas/ 與 docs/plan.md 這類產物要放在哪個目錄、以及倉庫標示 MIT 但 GitHub 未回報授權欄位，發佈前請自行核對 LICENSE 檔。

官方來源

1. Issues
2. PolyArch/humanize on GitHub
3. README