一個真實的場景
打開 Bun（oven-sh/bun）的 Pull Request 頁面，你會看到一件過去不可能發生的事：最近一週的 open PR 裡，九成以上出自同一個帳號 robobun。它不是人，是 Bun 團隊用 Claude Code 跑起來的自動化開發 agent。每個 PR 都自動貼上 claude 標籤、分支名以 claude/ 開頭、描述裡明寫「Generated with Claude Code」，然後指派給 Jarred Sumner 或其他核心成員 review。
它做的事情非常具體：bundler 的邊界情況、bun test 的 reporter 旗標、bun install 連結 bin 的順序、node:fs 的時間戳精度、WebSocket 握手時重複的 header。一天十幾筆，全年無休。截至 2026 年 9 月，Bun 的 open PR 已超過 5,600 筆，closed PR 接近 17,000 筆。
這是目前公開專案中，把「AI 大量產 PR、人類只負責 review」推到最極致的案例之一。它值得看，不是因為它成功或失敗，而是因為它把好處、代價和後遺症全部攤在陽光下。
這樣做的好處
Issue 到 PR 的延遲被壓到接近零。 過去一個 bug report 從被看到、被理解、被修好，通常以天或週計算。現在使用者早上開 issue，中午 robobun 的 PR 就掛在上面等 review。對於「有明確重現步驟、影響範圍小、修法直觀」的 bug，這是實實在在的速度提升。
長尾問題終於有人做。 每個成熟專案都有一大堆「重要但不緊急」的小問題：Windows 上的邊界情況、跟 Node.js 行為的細微差異、錯誤訊息的 UTF-8 邊界。人類工程師永遠排不到它們，agent 卻不挑食。robobun 修的絕大多數就是這種題目，而它一度是 Bun 合併 PR 數量最多的貢獻者。
團隊的隱性知識被迫顯性化。 為了讓 agent 不再犯同樣的錯，Bun 的 CLAUDE.md 累積了大量規則：debug build 怎麼開、分支怎麼命名、什麼情況下「保守堆疊掃描器絕對不是你的 bug 根因」。這些原本只存在資深工程師腦中的東西，現在變成專案的一部分。這件事本身對新人 onboarding 就有價值。
每個修正都附帶回歸測試。 從 PR 內容可以看到，robobun 幾乎每次都會加上 test/regression/issue/<編號>.test.ts。這是人類貢獻者經常偷懶的地方，agent 卻做得很一致。
這樣做的代價
「合併」不等於「修好」。 這是 Bun 案例中最刺眼的一條。有使用者回報 Windows 上的 GC bug（issue #26625），robobun 很快送出修正並被合併，issue 隨之關閉；使用者下載 canary 版驗證，bug 原封不動，只好再開一個 issue（#26660）說明「已合併的 PR 沒有解決問題」。另一位使用者在 issue #27664 裡直接質問：為什麼沒有經過嚴格 review 就合併？這不就是用 AI 產出的幻覺去掩蓋品質問題嗎？
Review 容量成為真正的瓶頸。 5,600 筆 open PR 不是產能的證明，是消化不良的證明。當一個人一天要看幾十筆 agent 產出的 PR，他能做的只剩三種選擇：仔細看（然後看不完）、快速掃過（然後品質下降）、或者信任 CI（然後把品質押在測試套件上）。Bun 的軌跡顯示它們選了後兩者。
測試套件變成唯一防線，而它撐不住。 隨著 Bun 使用者變多，回報的問題也跟著變多，其中一個 bug 甚至牽涉到 Claude Code 原始碼外洩事件。今年 7 月，Jarred Sumner 用一群平行的 Claude agent 花了 11 天、約 16.5 萬美元的 API 費用，把 Bun 從 Zig 移植到 Rust，理由之一正是 bug 越來越多。Zig 作者 Andrew Kelley 的回應很直白：如果測試套件連 Zig 程式碼裡的 bug 都攔不住，憑什麼相信它能攔住一百萬行未經 review 的 Rust 程式碼？
專案開始需要「防禦 AI 的基礎建設」。 Bun 的 GitHub Actions 裡出現了一個叫「Close AI Slop PRs」的 workflow，CLAUDE.md 也加進「要謙虛誠實，絕不誇大你完成了什麼或什麼真的能動」這條規則。這些都是被燙過之後才會長出來的東西。它們有用，但也代表團隊正在花力氣管理一個自己製造出來的問題。
社群信任在流失。 當使用者發現 issue 被「AI 修好了」但其實沒修好，下一次他還會花時間寫詳細的重現步驟嗎？Issue 品質下降會反過來讓 agent 的修正品質下降，這是一個負向循環。
從 Bun 身上看到的現象
把時間軸拉開，Bun 這一年的變化其實有一個清楚的模式。
第一階段：agent 是加速器。 robobun 上線初期，它處理的是人類排不到的長尾 bug，合併數量快速攀升，社群的觀感大致是正面的——終於有人理那些小問題了。
第二階段：agent 是主要貢獻者。 PR 頁面上人類的 PR 變成少數，review 開始積壓。「合併了但沒修好」的案例開始出現，使用者的抱怨從個案變成對流程的質疑。
第三階段：agent 製造的問題需要更多 agent 來解。 團隊的回應不是減少 agent 的使用，而是加上更多自動化——auto-label、issue 去重、找 PR 對應的 issue、關閉 AI slop PR，最後乾脆用一群 agent 把整個 codebase 換一種語言重寫。每一步在當下都合理，但整體方向是把驗證的責任越推越遠。
這個模式有一個共同點：每一次的決策都是在「產出很快」的前提下做的，沒有一次是回頭問「我們的驗證容量跟得上嗎」。
後續的影響
瓶頸從產出移到驗證，而且不會移回去。 這是整個現象最根本的結構性改變。當程式碼產出的邊際成本趨近於零，專案的產能上限就完全由「有多少人能認真 review、有多好的測試能自動驗證」決定。Bun 用一次昂貴的重寫證明了一件事：你可以用 AI 把程式碼從一個語言搬到另一個語言，但你搬不走驗證的責任。
「誰定義正確」變成第一順位的問題。 當 AI 同時寫程式碼和測試，測試通過只證明 AI 對自己的理解是自洽的，不證明它理解對了。那個「合併了但沒修好」的 GC bug 就是典型：agent 寫了一個能通過的回歸測試，但那個測試測的並不是使用者遇到的問題。這把壓力推回上游——issue 的重現步驟、驗收條件、範例，這些東西的品質決定了 agent 的天花板。
專案需要新的量測。 合併率、PR 數量、修復速度這些指標在 agent 時代全部失真。更有意義的可能是：合併後被重開的 issue 比例、每筆 PR 的人類 review 時間、canary 版的回報率、需要人類補刀的比例。這些數字才會告訴你 review 到底有沒有在發生。
維護者的角色在改變。 從「寫程式碼的人」變成「定義規則、設計防線、決定什麼該合併的人」。CLAUDE.md 會變得跟 CONTRIBUTING.md 一樣重要，甚至更重要。這對維護者的要求不是降低，是提高——你需要更清楚自己專案的邊界在哪裡，因為你的 agent 只會照你寫的做。
社群契約需要重新協商。 開源的隱性契約是「你回報 bug，有人會認真看」。當回應者變成 agent，這個契約需要明說：哪些類型的 issue 會由 agent 處理、合併不代表關閉、使用者的驗證回饋會被如何對待。沒有這些，使用者會用腳投票。
一個被忽略的前提：大部分 RD 沒有驗證的知識
前面說瓶頸移到驗證，但這裡有一個更尷尬的事實：大部分的研發人員，本來就沒有測試與驗證的知識，也沒有那套思維。
這不是責備。過去的分工讓 RD 可以只負責「寫出來」，驗證是 QA 的事、是 CI 的事、是上線後使用者的事。這套分工在 AI 時代崩掉了，因為寫出來的人變成 agent，剩下的人類只剩一件事可做——判斷這東西對不對。而這件事，多數人沒有被訓練過。
Bun 的 GC bug 案例把這件事看得很清楚。robobun 每次都附上回歸測試，測試也都是綠燈，但那個測試測的是 agent 自己理解的問題，不是使用者遇到的問題。Review 的人看到「有測試、有通過」就合併了。他缺的不是時間，是看穿「這個測試到底驗證了什麼」的能力：測試的輸入有沒有涵蓋使用者的情境？邊界在哪裡？失敗的路徑有沒有被走到？如果把修正拿掉，這個測試會不會紅？這些是測試設計的基本功，但它們從來不在多數 RD 的養成裡。
於是就出現一個常見的誤解：既然 agent 會寫測試、CI 會跑測試，那驗證就自動化了。不是。Happy path 的測試能自動化，是解決不了問題的。 Agent 最擅長產出的，恰好是「正常輸入、正常輸出」的那種測試——因為它寫程式碼的時候腦中就只有這條路。真正會出事的是邊界、是異常、是使用者根本不會照你想像的方式去用的那些情境。這些測試需要有人先想到，才寫得出來；想不到，再多的自動化也只是把同一條路重複走一萬次。
Bun 的 5,600 筆 open PR，每一筆都是綠燈。這個數字本身就說明了：綠燈不是品質。綠燈只證明「有人想到要測的地方沒有壞」，至於沒有人想到要測的地方，它一個字都沒說。
所以真正的功課不在工具，在人。讓 RD 學會怎麼從使用者的角度定義「什麼叫對」、怎麼從一個需求推出邊界和異常情境、怎麼判斷一個測試是在驗證行為還是在驗證實作、怎麼看一個綠燈就知道它證明了什麼又沒證明什麼——這些能力，在 agent 出現之前是加分項，在 agent 出現之後是生存條件。
結語
Bun 的案例不是「AI 不能寫程式」的證據，也不是「AI 可以取代工程師」的證據。它證明的是一件更樸素的事：軟體品質從來不是由寫程式碼的速度決定的，而是由驗證的能力決定的。 AI 把前者放大了一百倍，後者卻沒有同步放大，於是所有的壓力都擠到了同一個地方。
如果你打算讓 AI 成為專案裡最多產的貢獻者，你要先回答的問題不是「它寫得夠不夠好」，而是「誰來驗證，用什麼驗證，驗證的容量跟得上嗎」。
答不出這三個問題，就先不要把 agent 常駐上線。
參考資料：oven-sh/bun GitHub repository（PR 列表、issue #26625、#26660、#27664、CLAUDE.md、GitHub Actions workflows）；The Register（2026-07-14）關於 Bun Rust 移植與 Zig 作者回應的報導。
發表迴響