1個程序員把Claude塞進24小時流水線，代碼自己寫自己審

凌晨3點，你的GitHub倉庫還在冒綠點。不是你在加班，是一個bash腳本在替你打工。

Mario Hayashi，前Google工程師、現獨立開發者，最近公開了他的「單兵作戰」配置：用cron定時任務、tmux會話管理和Claude（Anthropic的AI助手），搭了一條能自主選題、寫代碼、開PR、處理評審意見的完整流水線。他管這叫「Ralph循環」——名字借自Geoffrey Huntley的開源方案，核心邏輯簡單粗暴：任務→實現→測試→提PR→清空上下文，周而復始。

為什么不是直接用Cursor或Devin？

Hayashi的答案是隔離。不是隔離人與機器，是隔離機器的每一步。

他把流程切成四個獨立階段：規劃、構建、測試、驗證。每個階段有明確的輸入輸出，能單獨失敗、單獨重試，不會牽一發而動全身。「Agent擅長短平快的任務，范圍一擴就崩。結構比模型大小更重要。」他在博客里寫得很直白。

這套思路和他之前做的Xero費用審計CLI一脈相承：先搭好代碼框架和規則邊界，再把模型塞進去。順序不能反。很多人反著來——先讓AI寫，再人工擦屁股——結果越擦越臟。

具體實現上，tmux負責給每個階段開獨立會話，cron負責定時喚醒，bash腳本負責串流程。Claude Code（Anthropic的終端AI工具）作為執行終端，按結構化提示詞干活。所有「記憶」存在git提交記錄和結構化文件里，不在模型的上下文窗口里。

「失敗安全」比「一次成功」更重要

Hayashi反復提一個詞：fails safely（安全失敗）。

他的流水線設計里，每個環節都能優雅掛掉。測試沒過？回滾到上一步。代碼風格不對？觸發lint檢查并自動修復。Claude生成的實現和任務描述對不上？直接拒掉，發通知等人類介入。「我負責決定做什么、合不合并。中間的一切，能自動就自動。」

這套機制跑通后，他的日常變成了：早上掃一眼Claude昨晚開的PR列表，審代碼、給反饋、點合并。復雜需求手動拆成子任務丟進隊列，簡單bug修復完全放手。相當于雇了一個不會累、不會抱怨、但偶爾會犯蠢的初級工程師——而且時薪按API token計費。

有個細節很有意思：他堅持每次迭代后清空上下文。不是舍不得token，是怕模型「記住」太多反而跑偏。git才是唯一可信的狀態源。這和當下很多「智能體」追求長記憶、多輪對話的產品路線截然相反。

單人團隊的規模悖論

Hayashi的配置暴露了一個正在被驗證的假設：小團隊的瓶頸從「寫代碼的人手不夠」轉向了「代碼寫完后誰來看」。

他的流水線解決了前半段，后半段仍卡在自己身上。PR可以批量開，但合并前的代碼審查沒法批量做。這也是他沒把這套系統叫「全自動」而是「自主」的原因—— autonomy（自主性）和automation（自動化）之間，差著一個人類判斷的縫隙。

目前這套腳本還在頻繁迭代。他每發現一次邊界情況就改一次prompt，每遇到一次幻覺就加一層校驗。用他自己的話說：「還在flux（流動狀態），這篇博客只是今天的快照。」

開源社區的反應兩極。一部分人覺得這是「 vibe coding」的終極形態——用氛圍感寫代碼，人類只負責拍板；另一部分人質疑，當調試成本超過省下來的時間，這套系統會不會變成新的技術債。Hayashi沒回應這些爭論，他的GitHub倉庫最近三個月提交了47次，全是給Ralph循環打補丁。

如果你也是一人公司，會愿意把凌晨的綠點交給一個bash腳本嗎？還是寧可自己熬著，至少知道哪行代碼為什么崩？