iT邦幫忙

2026 iThome 鐵人賽

DAY 26
0
Vibe Coding

讓 AI Agent 維護一個 Open Source Project系列 第 26 篇

Day 26:案例——長期未解決的 issue,AI 怎麼幫忙重新評估優先序

  • 分享至 

  • xImage
  •  

前言:不是每個 issue 都該立刻處理,但也不該被遺忘

「這個 issue 開了三、四個月都沒動,是不是不重要?還是只是排不進時間?」

維護一個有真實使用者的專案,這種問題每天都在發生。issue 清單越積越長,新回報進來時,舊的很容易被自然而然地往後排——不是因為不重要,而是因為沒有人重新看過它。今天用一個真實案例,講清楚 AI 在「重新評估優先序」這件事上能幫上什麼忙。

今日目標

  • 看一個開了超過三個月、還沒解決的真實 issue
  • 理解「重新評估優先序」需要哪些資訊,AI 能不能幫忙整理
  • 認識 AI 判斷「環境條件是否已經改變」這件事的具體做法
  • 建立一套「重新喚醒舊 issue」的具體流程

案例:一個跟 Pest 平行執行有關、開了超過三個月的 issue

PHPUnit & Pest Test Explorer 這個真實專案裡,issue #415「Not evaluating test results when running pest in parallel」從 2026 年 5 月中開到現在,還沒關閉。

回報內容具體:使用者在 Pest v4 的測試設定裡加上 --parallel 參數後,Test Explorer 就抓不到測試結果,全部顯示成 skipped;拿掉 --parallel 就恢復正常。回報者附了完整的輸出記錄,關鍵線索藏在裡面——當套件平行執行測試時,Pest 內部是透過動態 eval() 產生的程式碼路徑(TestCaseFactory.php(175) : eval()'d code)去執行測試,這個路徑跟編輯器裡實際的測試檔案路徑對不上,導致擴充套件用來比對測試身分的邏輯直接回報「找不到」。回報者也提到這個問題可能跟另外兩個既有 issue 相關。

AI 能幫上的忙:把累積的脈絡整理成一份可以重新決策的摘要

如果直接問 AI「這個 issue 該排多高優先序」,得到的答案通常沒什麼參考價值——因為 AI 沒有這個專案的記憶,不知道這件事已經被討論過幾次、當初為什麼沒處理。真正有用的做法,是先讓 AI 做一輪「脈絡整理」:

  • 這個 issue 跟哪些既有 issue 有關聯:回報者自己提到的兩個相關 issue,值得一併拉出來看,可能是同一個根因的不同外顯症狀。
  • 根因目前的假設是什麼、有沒有被驗證過:這個案例裡,根因線索其實已經藏在回報者附的輸出記錄裡(eval()'d code 路徑跟真實檔案路徑不匹配),只是沒有人把它明確標注出來變成一句可以直接判斷的結論。
  • 環境條件跟三個多月前相比有沒有變化:這個套件依賴的 Pest 版本、平行測試機制本身,有沒有在這段期間更新過、有沒有可能讓根因假設不再成立。

用一組對照來看這個差異:

❌ 只憑印象評估:
「這個 issue 開很久了,可能不常見,先擺著。」
→ 沒有回頭看內容,純粹用「積壓時間長」當代理指標判斷重要性

✅ 先整理脈絡再評估:
「這個 issue 影響的是 Pest 平行執行這個功能,回報內容裡已經
 有具體的根因線索(eval 路徑跟真實路徑不匹配),
 跟另外兩個 issue 可能是同一根因。
 建議:先確認這三個 issue 是不是真的同根因,
 一次修復可能比個別排優先序更有效率。」
→ 判斷依據是實際內容整理出來的結論,不是積壓時間本身

「這個 issue 開了多久」本身不是一個有意義的優先序指標——它只是「沒有人重新看過」的訊號,不是「不重要」的證據。 AI 能做的,是把重新看一遍的成本壓到最低,讓維護者可以用一份整理過的摘要做判斷,而不是要嘛完全不看、要嘛重讀所有舊留言。

這件事跟系列主題句的關係

這正是這個系列反覆出現的模式的另一個變形:「這個 issue 不重要」的判斷,如果只是因為沒有查證過內容,那就是一個查證範圍不夠、卻講得很篤定的結論。 AI 整理脈絡的價值,不是替維護者做決定,而是把「要不要重新評估」這件事的查證成本降到維護者願意花時間做的程度。

今日思考題

回想你手上專案裡有沒有一個開很久還沒處理的 issue:你上一次重新完整讀過它的內容,是什麼時候?如果現在有人問你「這個該排多高優先序」,你的答案是基於重新查證過的內容,還是基於「反正開很久了」這個印象?

今日重點回顧

  • 開了很久的 issue,不代表不重要,只代表可能沒有人重新看過
  • AI 能幫忙整理累積的討論脈絡、標注根因線索、比對相關 issue,把重新評估的成本降低
  • 這個真實案例(issue #415)的根因線索其實已經藏在回報內容裡,只是沒被明確標注出來
  • 「積壓時間長」不該是優先序判斷的直接依據,只是提醒「該重新查證一次」的訊號

明日預告

明天要往上升一層,談維護者這個角色本身在 AI 協作下的轉變:從「寫功能的人」變成「審核 AI 產出的人」,這個轉變具體是什麼樣子。


上一篇
Day 25:案例——一次 AI 漏看了 edge case,被使用者在 issue 裡糾正
下一篇
Day 27:維護者的角色轉變——從「寫功能的人」到「審核 AI 產出的人」
系列文
讓 AI Agent 維護一個 Open Source Project 共 27 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言