Boris Cherny 與 Jarred Sumner 的現場寫程式實錄（第 1/3 段）

🧑‍🏫 Bun 是一套用來執行 JavaScript 程式的開源工具。這段影片示範 Bun 團隊怎麼讓 Claude 接手：有人回報問題後，重現問題、修 bug、接受審查，幾乎都自動完成。值得看的是背後兩個原則：讓 AI 能自己檢查成果，以及把經驗寫成文件。這兩點在不寫程式的工作上也用得到。

• 01:02 開場介紹 Claude Code 負責人 Boris 與 Jarred Sumner。這是開發者大會，本場會講一些，但主要是現場寫程式
  ↳ 這是開發者大會上的一場。主角是 Claude Code（讓 AI 直接在電腦上寫程式的工具）的負責人 Boris，和 Bun 的作者 Jarred。重點是現場實作，不是聽簡報。
• 01:38 講者要說明 Bun 怎麼用 Claude Code 開發和維護 Bun。這套設定比目前常見的做法進階，他先開幾個 agent 去修 GitHub issues
  ↳ Jarred 要示範團隊怎麼用 Claude Code 維護 Bun。他一開始就派出幾個 agent（能自己連續做事的 AI 助手）去處理 GitHub 上的問題回報。這種用法比一般人常見的做法更進一步。
• 02:08 在 Bun 的 repo，只要有人提交 issue，Claude bot 就會自動嘗試重現。Bun 的 bot（字幕拼作 Robun／Robo Bun）重現成功後會自動送出 PR
  ↳ GitHub issue 是使用者回報的問題單。只要有人開單，Bun 的 bot（自動執行任務的程式）就會先試著重現問題。成功後會自動送出 PR，也就是「請把這段修改收進專案」的申請。
• 02:45 這些 PR 一定附測試，這是 bot 送 PR 前的硬性條件之一
  ↳ bot 送的每份 PR 都一定要附測試。測試是一段能自動檢查「問題還在不在」的小程式。沒附測試就不准送，這樣「修好了」才有證據。
• 02:45 檢查修正對不對的方法：測試要在前一版 Bun 失敗、在這個 debug branch 通過。不符合的話，bot 就不能送 PR
  ↳ 同一個測試要在舊版 Bun 失敗，證明真的抓到 bug；還要在 debug branch（放這次修改的分支版本）通過，證明修好了。兩個條件少一個，bot 就不能送 PR。
• 03:15 issue tracker 裡的每個 issue，在有人看之前 bot 就會先試著重現。因為 open issues 很多，這樣省下大量時間
  ↳ 問題單一進來，還沒有人看，bot 就先動手重現。Bun 待處理的問題很多，光是把「確認問題是真的、怎麼觸發」這一步交給 bot，就省下工程師大把時間。
• 03:15 挑戰從「修 bug、除錯」轉成「這是不是該 merge 的正確修法、品質有多好」
  ↳ 以前的難處是找 bug、修 bug。現在 AI 會修了，人的角色變成把關：判斷這個修法對不對、品質夠不夠好、該不該 merge（正式收進專案）。
• 03:50 GitHub insights 顯示近三個月 main 分支上，這個 bot 的貢獻已經比講者本人多，而且它的 PR 並沒有全部 merge
  ↳ GitHub 的統計頁顯示，近三個月在 main 分支（專案正式版本的程式碼）上，bot 的貢獻已經比 Jarred 本人多。而且它送的 PR 並不是每份都被收下。
• 03:50 判斷 PR 能不能 merge，靠的是測試
  ↳ 要不要收一份 PR，看的是測試有沒有通過。這就是前面堅持每份 PR 都要附測試的原因：測試是判斷的依據。
• 04:23 自動 code review bot 會跑：Code Rabbit 留言，Bun 的 bot 回覆，雙方來回，處理完會把留言標為 resolved。這個例子大約有 30 則留言
  ↳ code review 是程式收進去前先讓人挑毛病。這裡雙方都是 bot：Code Rabbit 留言挑問題，Bun 的 bot 回覆、修改，處理完就標成已解決。示範的例子來回約 30 則留言。
• 04:54 兩者組合使用：Code Rabbit 擅長風格問題，以及確認有沒有遵守 CLAUDE.md
  ↳ 他們兩種審查 bot 一起用。Code Rabbit（一款第三方自動審查工具）負責抓寫法風格，也檢查有沒有照 CLAUDE.md（寫給 Claude 看的專案說明書）的規定做。
• 04:54 Claude code review 擅長找出細微的 edge case，也就是本來要花約 30 分鐘讀完程式碼、掌握完整脈絡才發現得了的 bug
  ↳ Claude 的 code review 擅長抓 edge case，就是只在特殊情況才出錯、很不起眼的 bug。這種問題，人通常要花約半小時讀懂整段程式和前後脈絡才看得出來。
• 05:30 如果沒有 code review 在迴圈裡、讓 Claude 回應並修正，很難做到這整套自動化
  ↳ 講者認為審查是關鍵的一環：要有 review 挑問題、Claude 回頭修正，這個來回能自己跑起來，整套自動化才做得到。
• 05:30 以前 PR 很久才能 merge，是因為要在本地 checkout branch、修 lint error、本地跑 linter，再 push 回去，一直有切換成本
  ↳ 以前 PR 拖很久，常卡在雜事：把分支抓到自己電腦、修 lint error（寫法不合規範的警告）、跑 linter（檢查寫法的工具）再傳回去。工作一直被打斷。
• 06:04 所以這特別適合交給 LLM。Bun 是系統程式碼，很容易重現 issue、確認有沒有修好，也就是 verification loop
  ↳ 這類瑣事很適合交給 LLM（大型語言模型，例如 Claude）。Bun 是底層系統程式，問題好重現，修沒修好也好確認。這種做完能自己驗收的循環，叫 verification loop。
• 06:37 Bun 是 CLI 工具，測試不需要跑瀏覽器。其他專案也可以設定讓 agent 截圖或錄影來驗證
  ↳ Bun 是 CLI 工具（在文字指令視窗裡操作的程式），測試只要看文字結果，不用開瀏覽器。有畫面的專案，可以讓 agent 截圖或錄影來確認結果對不對。
• 06:37 Bun 目前還不需要截圖或錄影驗證，但有些前端的部分做了會不錯
  ↳ Bun 目前還用不到截圖或錄影來驗證。不過講者提到，有些偏前端（使用者看得到的介面）的部分如果加上，會更好。
• 07:08 可推廣的做法：大多數產品不是開源，起點可以換成客服工單，自動交給 Claude bot 重現問題、送 PR，再讓 code review 來回
  ↳ 大多數公司的產品不開源，沒有公開的問題回報。但做法可以照搬：從客服工單開始，自動交給 Claude bot 重現問題、送出修正，再讓審查 bot 來回把關。
• 07:39 對很多公司來說影響會更大，因為省下大量開發者時間。講者提議幫這個模式取名，例如 adversarial code review
  ↳ 對很多公司來說效益可能更大，因為能省下大量工程師的時間。講者想替這個模式取名，例如 adversarial code review（對抗式審查：一方寫、一方專門挑錯）。
• 08:10 只照上面做還不夠。第一步要先把開發環境設定好
  ↳ 只照抄流程還不夠。第一步要先把開發環境設定好，讓 AI 能順利編譯、執行、測試。環境沒準備好，後面的自動化都跑不起來。
• 08:10 CLAUDE.md 很重要，不然 Claude 會送出你不太能 merge 的 PR
  ↳ CLAUDE.md 是放在專案裡、Claude 工作時會讀的說明檔。沒寫好的話，Claude 送出的修改常常不合專案習慣，你很難直接收下。
• 08:10 Bun 的 CLAUDE.md 特別強調要用一個專用指令 build，它會 build 並執行、轉送參數。因為 Bun 需要編譯，要確保跑的是實際修改，而不是過時的 debug build
  ↳ Bun 要先編譯（把程式碼轉成能執行的檔案）才能跑，所以 CLAUDE.md 特別交代要用一個專用指令，一次完成編譯和執行。這樣才不會測到舊的 debug build（還沒包含新修改的測試版本）。
• 08:45 CLAUDE.md 也詳細寫了怎麼跑測試、怎麼寫測試、測試放哪裡，以及以前踩過的各種問題
  ↳ CLAUDE.md 也寫清楚怎麼跑測試、測試怎麼寫、放在哪裡，以及過去踩過的坑。就像給新同事的交接手冊。
• 08:45 原則：只要發現自己一直重複講某件事，大概就該寫進 CLAUDE.md
  ↳ 原則很簡單：同一件事你已經跟 Claude 講第二、第三次，就該寫進 CLAUDE.md，不要每次重講。
• 09:17 要讓很多 Claude 一直跑還能維護，就必須把東西寫下來、文件化
  ↳ 要讓很多個 Claude 長時間同時工作，而且之後還維護得了，就一定要把規則和經驗寫下來。只用講的，下一個 Claude 不會知道。
• 09:17 小細節：為了讓 Claude 看到錯誤訊息，會先印出錯誤訊息，再印資訊較少的條件
  ↳ 一個小技巧：測試失敗時，先印出真正的錯誤訊息，再印比較籠統的判斷條件。這樣 Claude 會先看到最關鍵的線索。
• 09:50 Claude 寫的測試有問題、同樣情況出現一兩次後，就叫 Claude 把它加進 CLAUDE.md，以後寫測試第一次就寫對。講者稱這有點像 compound engineering
  ↳ Claude 寫測試出錯，同樣情況出現一兩次後，就請它把教訓寫進 CLAUDE.md，下次一次就寫對。講者說這有點像 compound engineering：經驗像複利一樣越積越多。
• 09:50 在 CLAUDE.md 裡給它資料夾概覽、程式碼的配置方式，以及相依套件的說明，也很有幫助
  ↳ 在 CLAUDE.md 附上資料夾概覽、程式碼怎麼分區擺放，以及用到哪些相依套件（別人寫好、拿來用的程式庫），Claude 就不用每次重新摸索。
• 10:21 要讓 agent 讀得到 CI 錯誤和 build log，才能跑完整個迴圈：寫程式、測試程式、檢查 CI、監控 CI
  ↳ CI 是每次上傳程式後自動編譯、測試的系統，build log 是過程紀錄。agent 要讀得到這些錯誤，才能自己寫程式、測試、盯 CI 結果，把整個流程跑完。

Bun 的 bot 要自動送出修 bug 的 PR，必須先符合哪個條件？