我不小心用 Claude Code 寫出了人生第一個分叉炸彈

背景

這篇文章描述了一位開發者在 2026 年初嘗試將 Claude Code 整合進其代理型工作流時，意外引發的技術災難。作者在設定 SessionStart 掛鉤時，不慎讓每個啟動的實例又觸發了兩個新的背景實例，導致電腦陷入 1 變 2、2 變 4 的指數級「分叉炸彈」循環。這場意外不僅讓硬體因過熱與記憶體耗盡而當機，更在短短一晚內產生了高達 3800 美元的 API 帳單，引發社群對於 AI 工具自動化風險與資源消耗的熱烈討論。

社群觀點

針對這起意外，Hacker News 的社群討論呈現出技術懷舊與現代風險交織的有趣對比。許多資深開發者紛紛分享自己早年的分叉炸彈經驗，有人回憶起 90 年代在校園透過開放的 Telnet 協定惡作劇，甚至有人指出即便是在微軟官方的開發者文件中，也曾出現過會導致類似崩潰的範例代碼。這些討論反映出一個共識：無論技術如何演進，遞迴邏輯錯誤始終是程式開發中經典且致命的陷阱。

然而，現代 AI 工具的特性為這個老問題注入了新的變數。有留言者指出，這起案例中最令人感到諷刺且驚悚的發現是，即便軟體運行效率再差，其自動化執行的速度仍遠超人類的反應極限。作者之所以能「逃過一劫」，避免產生更天文數字的帳單，竟然是因為 Claude Code 本身基於 Bun、React 與 TUI 的架構極其耗費記憶體，導致電腦在 API 刷爆之前就先因為資源枯竭而鎖死。這種「以臃腫對抗失控」的黑色幽默引起不少共鳴，社群認為這反映了當前 AI 工具在開發效率與資源管理之間的失衡。

在技術實踐層面，社群對於「為何需要同時啟動多個 AI 實例」感到好奇。作者解釋其初衷是為了彌補對話紀錄掛鉤未觸發的缺陷，但其他開發者則提出了更穩健的替代方案。例如，有觀點建議利用 Git worktrees 搭配 macOS 原生的沙盒執行環境，可以在不影響系統資源的情況下，安全地同時運行數十個對話視窗。此外，也有人提醒，與其依賴不穩定的啟動掛鉤，不如採用批次處理任務。整體而言，社群雖然對作者的慘痛教訓表示同情，但也藉此強調了在代理型工作流中建立資源配額與隔離機制的重要性，以防止自動化工具在無人值守時造成不可挽回的經濟損失。

延伸閱讀

在討論中，有使用者分享了關於如何像專業開發者一樣配置 Claude Code 的參考案例，提到可以參考 Boris 的設定方式來優化多實例運作的效率。此外，針對多任務處理的需求，社群也推薦研究 macOS 的 sandbox-exec 指令，這對於需要在隔離環境中運行大量 AI 代理程式的開發者來說，是比直接在主系統運行掛鉤更安全的選擇。