「AI agent 都能自己寫程式了，那開源專案的維護是不是也可以整包丟給它？issue 讓它分類、PR 讓它審、bug 讓它修，維護者只要負責『簽名』就好？」
如果你也曾經這樣想過，這個系列想誠實回答這個問題——答案不是「可以」，也不是「不行」，而是「要看是哪一種工作」。
過去這段時間，我把 AI agent 真的放進一個還在真實運作中的開源專案的維護流程裡，讓它處理 issue、審查 PR、追查 bug、寫文件、跑 CI。這個系列不是紙上談兵的方法論整理，而是一份帶著真實 issue 編號、真實 PR 討論、真實踩坑紀錄的實驗筆記。
今天是系列的第一天，我想先講清楚三件事：這個實驗用的是哪個專案、為什麼選它、以及整個系列打算怎麼走。
recca0120/vscode-phpunit 是一個 VS Code 擴充套件，把 PHPUnit 與 Pest 測試整合進 VS Code 原生的 Test Explorer——在編輯器裡直接看到測試樹、單筆執行或除錯、看到失敗訊息定位到程式碼行。它同時支援幾種比較麻煩的執行環境：在 Docker 容器裡跑測試、透過 SSH 連到遠端主機跑測試、Laravel Sail 這種包一層 Docker Compose 的開發環境、ParaTest 平行測試、以及 Xdebug 中斷點除錯。
這些支援項目背後代表的是同一件事：PHP 開發者的測試環境往往不是「本機直接跑」這麼單純，而是跨容器、跨主機、跨執行器的組合，這個擴充套件要在各種組合下都正確解析測試結果、正確對應到程式碼位置。
用 gh repo view 查到的專案現況：
$ gh repo view recca0120/vscode-phpunit --json description,primaryLanguage,stargazerCount,forkCount,licenseInfo
用 gh issue list 查詢，目前（撰文當下）open 的 issue 有 5 個，累積處理過的 closed issue 至少 200 個（這是查詢上限，實際數字更多）；PR 的狀況類似，累積 close 掉的 PR 同樣至少 200 個，open 的 PR 目前是 0。這代表這不是一個放著吃灰塵、只有 README 沒有活動的展示型 repo，而是一個持續有人回報問題、持續有人送修正的活專案。
先講這個系列想避開的兩種寫法。
第一種是「純方法論」：條列式講 AI agent 該怎麼分類 issue、該怎麼寫 PR review checklist，不帶任何真實案例。這種文章讀起來像是把 prompt engineering 手冊換句話說，說服力薄弱——讀者沒辦法判斷這套流程在真實情境裡會不會翻車。
第二種是「玩具專案」：自己寫一個從沒人用過的 demo repo，讓 AI 在裡面模擬處理 issue。這種寫法的問題是，玩具專案沒有真實的社群壓力——沒有真的等待回覆的使用者、沒有真的帶著情緒或誤解的 bug 回報、沒有真的想貢獻但寫法不熟練的外部 PR。開源維護困難的地方，往往不在技術本身，而在這些人的因素。
ai-oss/系列大綱.md 裡定的路線是第三種：找一個真實存在、有真實流量、可以公開追蹤的專案，讓 AI agent 介入這個專案原本就在發生的維護工作，然後如實記錄過程——包含 AI 做對的地方，也包含它做錯、被使用者在 issue 裡糾正、或維護者事後推翻它判斷的地方。
vscode-phpunit 符合這三個條件：
這也是為什麼 ai-oss/ 這個系列跟同一批鐵人賽草稿裡的 ai-refactor/ 系列不一樣——ai-refactor/ 的素材是一套真實但必須去識別化的內部系統，ai-oss/ 的素材可以直接具名。當然，具名不代表沒有邊界：專案本身可以指名道姓，但涉及其他 contributor 的部分，這個系列不會臆測他人的意圖或私下決策動機，只描述公開可見的討論內容跟結果。
這個系列接下來 29 篇，都會回到同一句話：
AI agent 能加速 open source 維護裡機械性、可規則化的工作，但專案的技術方向、社群信任、對貢獻者的責任，終究要人來扛。
「機械性、可規則化」是關鍵字。判斷一個 issue 有沒有附上重現步驟、有沒有跟既有 issue 重複、PR 有沒有附測試、CHANGELOG 有沒有同步更新——這些工作有明確的判斷依據，AI agent 可以先做第一輪。但「這個功能該不該做」「這個 breaking change 值不值得」「該不該相信這個第一次貢獻的人」——這些判斷牽涉到專案的長期方向跟人與人之間的信任，沒有規則可以完全代勞，還是要維護者自己扛。
❌ 維護者自己一個個處理 issue
新 issue 進來 → 維護者自己讀完整個 issue
→ 自己判斷是不是重複回報（要記得或搜尋過去幾百個 issue）
→ 自己判斷嚴重程度、該不該優先處理
→ 自己回覆使用者要求提供更多資訊
→ 使用者過幾天回覆，維護者再讀一次上下文
→ 才真正開始動手排查
問題：維護者的時間全部花在「篩選」而不是「解決」，而且篩選品質會被當下的精神狀態影響——同一天收到十個 issue，跟只收到一個，判斷品質會不一樣。
✅ AI 先做第一輪分類，人做最終判斷
新 issue 進來 → AI agent 讀取 issue 內容 + 搜尋既有 issue 歷史
→ AI 標註：可能重複的 issue 編號、缺少的重現資訊、初步分類（bug/功能請求/使用問題）
→ 維護者看到的是已經分類好、附帶佐證的清單，而不是原始雜訊
→ 維護者只需要做「這個分類對不對」「要不要真的處理」的最終判斷
→ 需要回覆使用者要求更多資訊時，AI 先擬草稿，維護者確認後再送出
差別不在於「AI 有沒有參與」，而在於AI 承擔的是篩選跟草稿，最終判斷跟對外發言的責任還是回到維護者身上。這個分工在後面的 Day 03、Day 04 會用真實 issue 案例具體展開。
AI 可以幫你把雜訊排序好，但決定什麼是雜訊、什麼值得認真看待，還是要你自己判斷。
如果你手上也有一個（不管是自己維護的還是想貢獻的）開源專案，回想一下最近處理過的幾個 issue：有多少比例其實是「判斷有沒有附重現步驟」「判斷是不是重複回報」這種機械性工作？又有多少比例是真正需要你對這個專案的技術方向、社群信任做判斷的工作？這個比例，可能就是這個系列接下來要探討的「AI 能接手多少、人該守住多少」的具體答案。
gh CLI 查證了專案的真實規模，累積處理過至少 200 筆 closed issue、至少 200 筆 closed PR，是一個持續有真實流量的活專案明天要正式介紹這個專案的背景——一個 VS Code 測試擴充套件的維護者，日常到底要處理哪些事：從使用者的環境千奇百怪（Docker、SSH、Laravel Sail 各種組合），到 issue 裡常見的回報品質落差，把「維護者的日常」這幅圖畫清楚，才能看懂後面每篇案例裡 AI agent 到底幫上了什麼忙、又在哪裡幫不上忙。
延伸閱讀：本次鐵人賽同時並行的其他四個系列，會從不同角度處理相關的經驗，有興趣可以一起追：
iThome鐵人賽
看影片追技術