「這個 issue 開了三、四個月都沒動,是不是不重要?還是只是排不進時間?」
維護一個有真實使用者的專案,這種問題每天都在發生。issue 清單越積越長,新回報進來時,舊的很容易被自然而然地往後排——不是因為不重要,而是因為沒有人重新看過它。今天用一個真實案例,講清楚 AI 在「重新評估優先序」這件事上能幫上什麼忙。
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「這個 issue 該排多高優先序」,得到的答案通常沒什麼參考價值——因為 AI 沒有這個專案的記憶,不知道這件事已經被討論過幾次、當初為什麼沒處理。真正有用的做法,是先讓 AI 做一輪「脈絡整理」:
eval()'d code 路徑跟真實檔案路徑不匹配),只是沒有人把它明確標注出來變成一句可以直接判斷的結論。用一組對照來看這個差異:
❌ 只憑印象評估:
「這個 issue 開很久了,可能不常見,先擺著。」
→ 沒有回頭看內容,純粹用「積壓時間長」當代理指標判斷重要性
✅ 先整理脈絡再評估:
「這個 issue 影響的是 Pest 平行執行這個功能,回報內容裡已經
有具體的根因線索(eval 路徑跟真實路徑不匹配),
跟另外兩個 issue 可能是同一根因。
建議:先確認這三個 issue 是不是真的同根因,
一次修復可能比個別排優先序更有效率。」
→ 判斷依據是實際內容整理出來的結論,不是積壓時間本身
「這個 issue 開了多久」本身不是一個有意義的優先序指標——它只是「沒有人重新看過」的訊號,不是「不重要」的證據。 AI 能做的,是把重新看一遍的成本壓到最低,讓維護者可以用一份整理過的摘要做判斷,而不是要嘛完全不看、要嘛重讀所有舊留言。
這正是這個系列反覆出現的模式的另一個變形:「這個 issue 不重要」的判斷,如果只是因為沒有查證過內容,那就是一個查證範圍不夠、卻講得很篤定的結論。 AI 整理脈絡的價值,不是替維護者做決定,而是把「要不要重新評估」這件事的查證成本降到維護者願意花時間做的程度。
回想你手上專案裡有沒有一個開很久還沒處理的 issue:你上一次重新完整讀過它的內容,是什麼時候?如果現在有人問你「這個該排多高優先序」,你的答案是基於重新查證過的內容,還是基於「反正開很久了」這個印象?
明天要往上升一層,談維護者這個角色本身在 AI 協作下的轉變:從「寫功能的人」變成「審核 AI 產出的人」,這個轉變具體是什麼樣子。