前言：為什麼要拿一個真實在跑的專案做實驗，而不是寫一份方法論清單

決定寫這個系列時，其實有個更省事的選項：整理一份「AI 怎麼協助維護 open source 專案」的條列式清單，issue 怎麼分類、PR 怎麼審、release 怎麼放，寫完收工，不用擔心素材夠不夠、不用擔心哪天查證的 issue 內容變了。

但那樣的文章我自己讀過很多篇，讀完常常記不住——因為沒有一個真實案例撐著，那些條列建議聽起來都對，卻沒有一條讓人真正相信「這是有人真的做過、真的踩過坑」。所以這個系列從 Day 01 就定了一條比較累但比較誠實的路：不寫方法論清單，改成把 AI agent 真的放進 recca0120/vscode-phpunit 這個還在真實運作的專案裡，讓它處理真實的 issue、真實的 PR、真實的 CI 設定，然後把過程如實記下來——包括查不到真實案例、只能誠實標注「這是示範情境」的那幾天。

四部回顧

第一部（Day 1-7）：為什麼要做這個實驗。 從介紹 PHPUnit & Pest Test Explorer 這個專案本身開始——TypeScript 開發、支援 Docker/SSH/Laravel Sail/ParaTest/Xdebug 多種執行環境的 VS Code 測試擴充套件，一路講到 issue triage、PR review 清單設計、e2e 測試環境的坑。這幾天立下的主題句——AI 能加速機械性、可規則化的工作，但技術方向跟社群信任要人來扛——後面 23 篇沒有一天偏離過這條線。

第二部（Day 8-16）：AI 處理 issue/PR 的具體工作流。 這是全系列查證最多真實素材的一段：從 CI workflow 重構（PR #424）、真實 bug 的定位過程（issue #417）、還在未解決狀態的 coverage 路徑問題（issue #430）、文件維護的真實案例（PR #422/#425）、依賴升級（PR #426，真實查到 TypeScript 6 升級踩到的三個相容性問題）、一路到功能開發的完整歷程（issue #427 到 PR #428）。現在回頭看，這段最有價值的不是任何單一案例，而是同一個查證動作重複了九次——每次都是先假設「這裡應該有個好案例」，再去 gh issue view／gh pr view 核對，有時候假設是對的，有時候不是。

第三部（Day 17-23）：社群協作與維護者角色的邊界。 從「AI 能不能代替回覆 issue」開始，一路講到授權判斷、release 流程、多環境測試矩陣（PR #423 的 macOS socket 路徑限制）、外部貢獻者協作。這段的核心是畫一條線：AI 擅長補「資訊落差」，不擅長也不該做「評判性判斷」——這條線在具體案例裡（尤其 Day 17、18、23）反覆被驗證，不是空談出來的原則。

第四部（Day 24-29）：實戰案例與總結。 用 issue #410 完整生命週期（issue → PR #412 → PR #413 → PR #414）走了一次真實的除錯與修正循環，也誠實記錄了一次「查不到符合的真實案例，改用示範情境」的過程（Day 25）。第四部收尾的幾天把視角拉高——從案例回到「維護者角色怎麼變」「AI 對整個 OSS 生態的影響」「哪些決定的授權邊界不該讓」這幾個更大的問題，把前面 23 天的具體經驗收攏成一套判斷框架。

個人心得：查不到真實案例，本身就是這個系列最誠實的部分

要老實講一件事：這 30 天裡，不是每一篇都查到了完美對應主題的真實案例。有幾天（例如講「文件改動意外波及程式碼」、講「發版前漏掉的檢查項」、講「AI 漏看 edge case 被糾正」）我花了不少時間翻 issue/PR 歷史，想找一個逐字對應的真實事件，結果找不到，只能誠實標注「這是基於這個專案性質推演的示範情境，不是逐字對應的真實紀錄」。

一開始覺得這是這個系列的缺陷——別人的鐵人賽文章讀起來每天都有真實故事，我卻要在幾篇裡承認「這篇沒有」。但寫到後來想法變了：如果我為了讓每篇都有「真實案例」而硬套一個不完全吻合的 issue，或者悄悄把示範情境包裝成真實事件，那才是真正的缺陷。一個真實專案的維護歷史，本來就不會剛好把每個教學主題都配好一個完美案例，勉強湊，反而是在騙讀者。誠實標注「這裡沒有查到、改用示範情境」，其實比每天都端出一個看起來完美的真實故事更接近這個系列一開始承諾的東西——用真實素材做實驗，而不是用真實素材當包裝。

另一個誠實的觀察：這 30 天下來，PHPUnit & Pest Test Explorer 本身的 star 數（168）、fork 數（72）沒有變化——這不是一次「靠寫系列文章帶動專案成長」的故事，這個系列做的事，從頭到尾都是在既有的、持續運作的維護流程裡做實驗，不是製造一個行銷案例。

回到主題句：一個可以帶走的判斷框架

30 天下來，AI agent 能加速機械性、可規則化的工作，但技術方向、社群信任、對貢獻者的責任要人來扛這句話，可以拆成一個更具體的判斷框架：

• 問「這件事有沒有明確、可驗證的判斷依據」：issue 有沒有附重現步驟、PR 有沒有測試、依賴升級有沒有 breaking change——這些有客觀依據的工作，AI 先做第一輪沒問題。
• 問「這個決定的後果，誰要承擔」：接受一個爭議性功能請求、拒絕一個第一次貢獻的 PR、决定這個版本要不要延後發——這些決定的後果最終落在維護者身上，AI 只能呈現選項，不能拍板。
• 問「這是不是能被逐字追溯、可以被反駁的宣稱」：這個系列每一篇引用真實 issue/PR 時都先查證過內容，查不到就誠實說查不到——這條紀律不只適用於 AI 的產出，也適用於這篇文章本身。

給讀者的實用建議

如果你也想讓 AI 參與維護一個你手上的開源專案：

• 先從 issue triage 開始，這是投資報酬率最高的第一步——判斷重複、判斷缺漏資訊，機械性高、風險低，容易看到具體效果。
• 不要讓 AI 代替你發言，草稿可以讓 AI 寫，但送出前的確認要留給自己。
• 把「查不到真實案例」當成正常結果,不是失敗——不管是寫維護日誌還是設計 AI 協作流程，誠實面對「這裡沒有素材」比硬湊一個更有長期價值。

結語

回到 Day 01 那個問題：「issue 讓它分類、PR 讓它審、bug 讓它修，維護者只要負責『簽名』就好？」寫完這 30 天，答案沒有變得更簡單，但變得更具體了——不是「可以」或「不行」，而是一份可以逐項核對的清單：哪些工作有客觀依據可以先交出去，哪些決定的後果沒有人能替你承擔。

PHPUnit & Pest Test Explorer 這個專案不會因為這個系列結束就停止維護，issue 還會繼續進來，PR 還會繼續等 review，這 30 天做的實驗某種意義上也還沒有「結束」——只是這個系列的記錄，先停在這裡。謝謝陪我走完這趟真實案例的旅程。

範例參考

系列裡引用過的真實 issue/PR：#410、#412、#413、#414、#415、#416、#417、#420、#422、#423、#424、#425、#426、#427、#428、#430，都可以在 recca0120/vscode-phpunit 上公開查證。