「issue 分類交給 AI、PR review 有清單幫忙、bug 定位 AI 先查、文件 AI 順手修、依賴升級 AI 跑流程——聽起來維護者好像沒事做了？」
這是我在整理這個系列前 26 天內容時，自己也問過的問題。答案不是「工作變少了」，而是工作的性質整個換了一種：這 26 天裡幾乎每一篇的結論，都指向同一個模式——AI 承擔了越來越多「先生成一份候選方案」的工作，維護者的時間被重新分配到「審核這份候選方案能不能用」。今天要把這個模式講清楚：這不是「維護者變閒」，而是「維護者的核心技能變了」。
回頭看這個系列走過的路：Day 03 讓 AI 做 issue 第一輪 triage，人做最終判斷；Day 05 讓 AI 產生 PR 審查清單，人核准合不合用；Day 09 讓 AI 從 issue 回報定位問題方向，人確認根因；Day 13 讓 AI 跑依賴升級流程，人看 changelog 判斷風險；Day 19 讓 AI 產生 release 的 changelog 草稿，人核准要不要發版。
這些任務表面上分散在不同工作類型裡，但拆開看都是同一個兩階段結構：AI 先產出一份「初稿」，人負責判斷這份初稿夠不夠好。 維護者從「第一個動筆的人」變成「最後一個把關的人」，順序整個反過來了。
「從零寫出一個功能」跟「快速看出一份候選方案裡的問題」，聽起來都是技術能力，實際上動用的是不同的認知過程。
從零寫需要的是建構能力：從一個模糊的需求，一步步組織出具體的實作。這個過程裡，思考的主線是「接下來要做什麼」。
審核候選方案需要的是拆解能力：看著一份已經成形的東西，快速定位「這裡哪裡可能有問題」。這個過程裡，思考的主線是「這個選擇背後藏著什麼沒被講出來的假設」——例如 AI 說「這個 issue 是重複回報」，維護者要能立刻反問「它比對的依據是描述文字相似，還是真的查過重現步驟？」
用一組對照來看這個差異：
❌ 用「從零寫」的心態審核 AI 產出：
維護者收到 AI 整理好的 issue triage 結果，
覺得「反正分類看起來合理」就直接採用，
沒有具體檢查 AI 判斷「這是重複回報」的依據是什麼
→ 審核淪為形式，等於沒有把關
✅ 用「拆解」的心態審核 AI 產出：
維護者看到 AI 判斷「issue #X 跟 #Y 重複」，
第一個反應是「它比對的是症狀描述，還是重現步驟？
環境條件（本機/Docker/SSH）有沒有考慮進去？」
→ 針對 AI 判斷背後的具體依據提出質疑，
而不是照單全收「結論看起來合理」
維護者的核心價值，正在從「我比 AI 更會寫」轉移到「我比 AI 更會挑毛病」——後者需要的經驗，其實不比前者少，只是形式不同。
這個轉變帶來一個容易被忽略的壓力：當 AI 生成候選方案的速度變快，如果維護者審核的速度沒有跟上，候選方案就會在還沒被真正審過的狀態下被放行。
這不是危言聳聽——這個系列裡好幾個案例都在講同一件事：Day 12 AI 修文件時順手改壞了別的東西、Day 20 發版前漏掉的檢查項、Day 25 AI 漏看了 edge case——這些案例的共同根源，都不是 AI 能力不夠，而是「審核」這一步沒有真的發生，或者發生得太倉促。
AI 讓生成端的產能大幅提升，如果審核端的品質沒有跟著提升，整個系統的瓶頸只是從「誰來寫」換成「誰來審」而已，風險並沒有消失，只是換了個地方藏起來。
如果你也在考慮讓 AI 更深度地參與你的專案維護，一個實用的自我檢查是：你現在花在「審核 AI 產出」的時間，有沒有比你原本花在「自己動手做」的時間更少？如果答案是肯定的，那省下來的時間，究竟是因為效率真的提升了，還是因為審核被你悄悄跳過了？
這個問題沒有標準答案，但誠實回答它，是判斷這整套協作模式對你的專案究竟是幫助還是隱患的關鍵。
回想你自己在工作或專案裡，有沒有哪個環節已經悄悄變成「AI 先生成、我來把關」的模式？你花在把關上的時間，跟你原本自己動手的時間相比，是真的更有效率，還是只是更快而已？
明天要把視角拉得更遠：AI 深度參與 open source 維護，對整個 OSS 生態帶來的是什麼樣的好處與隱憂——不只是這個專案，而是整個社群層面的影響。
iThome鐵人賽
看影片追技術