前言：「AI 都能讀懂 issue 內容了，那分類不就順手的事？」

「AI 又不是不會讀英文，issue 標題、內容、留言都丟給它，它應該可以直接告訴我『這個要優先修』『這個不用理』吧？」

這是很多人對 AI 輔助 issue 管理的第一印象——既然 AI 能理解自然語言，那乾脆讓它從頭到尾把 issue 排好優先序，維護者只要照著做就好。但這個想法混淆了兩件事：判斷「這則回報講的是什麼」，跟判斷「這件事現在該不該做、該花多少資源」，是完全不同性質的工作。前者是可以拆解成固定檢查項的機械性工作；後者牽涉到專案的技術方向、维護者當下的心力、對社群的責任——這些是 AI 看不到、也不該替維護者決定的東西。

今天要做的，是把「issue triage」這件事拆成兩段，並用這個專案真實還開著的 issue，示範第一段可以怎麼機械化。

今日目標

• 理解「triage」跟「排優先序」是兩個不同階段的工作，不能混為一談
• 認識一套具體、可重複套用的 triage 檢查清單
• 用真實 open issue（#430、#420、#416）示範這套清單怎麼跑
• 看到「資訊不足」時 AI 該怎麼處理，而不是自己腦補
• 理解為什麼「這個 issue 該排第幾」這個決定，AI 給不出來

Triage 是什麼，不是什麼

「Triage」這個詞借自急診分類——來的病人這麼多，總要先分出誰要立刻處理、誰可以等。放到 issue 管理上，triage 指的是在真正動手修之前，先把一則回報整理成「維護者可以直接判斷」的狀態，具體包含四件事：

1. 這是 bug 回報，還是 feature request？
2. 嚴重程度大致落在哪個等級（會不會整個功能不能用、有沒有 workaround）？
3. 是不是已經有人回報過同一件事？
4. 回報者有沒有提供足夠的資訊讓人能重現／理解問題？

這四件事的共通點是：答案幾乎完全來自 issue 文字本身跟既有 issue 列表，不需要理解專案的技術方向或維護者的可用心力。這正是為什麼它適合先讓 AI 做——輸入是固定的（issue 內容 + 既有 issue/PR 歷史），輸出可以套一致的規則檢查，不需要「品味」或「判斷力」這種難以量化的東西。

真正需要人的，是 triage 之後的下一步：這個 bug 該排在這個週末修，還是先放著？這個 feature request 值不值得花時間做，會不會拖著專案走向維護者不想去的方向？ 這些問題的答案取決於維護者自己的技術判斷、時間分配、對專案未來的想像——AI 沒有這些脈絡，硬要它給答案，只會產出一個聽起來很篤定、但其實沒有根據的排序。

具體的 Triage 檢查清單

把上面四件事拆成可以逐條核對的檢查項，示範用的清單長這樣：

分類

• [ ] 標題/內容描述的是「原本該動作沒動作」還是「希望新增一個目前沒有的能力」——前者是 bug，後者是 feature request
• [ ] 有沒有貼錯類型的跡象（例如用 bug 的格式回報，但內容其實是在要求新行為）

嚴重程度

• [ ] 是不是核心流程完全不能用（例如「執行測試」這個核心功能完全跑不動）
• [ ] 有沒有 workaround（回報者自己有沒有提到繞過的方法）
• [ ] 影響範圍是所有使用者，還是特定環境／特定設定組合才會觸發

重複回報判斷

• [ ] 標題關鍵字有沒有命中既有 open issue
• [ ] 症狀敘述（錯誤訊息、行為描述）有沒有跟既有 issue 高度重疊
• [ ] 即使症狀像，環境是否相同——同症狀但不同觸發環境，通常代表根因不同，不能直接合併

資訊完整度

• [ ] 有沒有可重現步驟
• [ ] 有沒有標明版本（擴充套件版本、執行環境版本、相關工具版本）
• [ ] 有沒有附上實際輸出（錯誤訊息、log、截圖）而不是只有文字描述
• [ ] 缺少任一項時，是不是能明確列出「還缺什麼」，而不是含糊帶過

這套清單刻意不包含「這個問題重不重要」「值不值得修」——那些留給下一步。

拿真實 issue 跑一次

用 PHPUnit & Pest Test Explorer 目前三則還開著的 issue 實際跑一次這套清單。

#420：測試套件的狀態顯示邏輯有問題——一開始顯示綠色「PASS」，全部測試失敗後，狀態卻沒有跟著更新成「FAIL」。

• 分類：bug（原本該正確反映結果的行為沒有正確運作）
• 嚴重程度：不影響測試能不能跑，但會讓人誤判結果——中等
• 重複回報：回報者自己在內文提到「Possibly related: #286, #104, #116」，主動列出可能相關的舊 issue，這個動作本身就大幅降低了 triage 需要花的力氣
• 資訊完整度：幾乎是範本等級——附了重現步驟、VS Code／擴充套件／PHP／Pest 版本、實際輸出的 log（TeamCity 事件流），甚至附了截圖，還指出程式碼裡可疑的位置（testSuiteStarted handler 無條件套用 passedBadge，沒有在 testSuiteFinished 時重新根據子測試結果判斷）

這則 issue 光靠檢查清單就能把「這是不是重複回報」「缺不缺資訊」兩項直接判定完畢，維護者拿到的已經是可以直接看程式碼定位的狀態。

#416：docker compose 指令執行失敗，錯誤訊息是 unknown shorthand flag: 'f' in -f。

• 分類：bug
• 嚴重程度：使用者在自己的 Docker 環境下完全跑不了測試，但只影響特定的 phpunit.command 自訂設定組合，不是所有使用者
• 重複回報：跟 #417（無法執行單一測試）、#415（Pest 平行模式）標題症狀不同，內容也不同，不算重複——雖然都掛在「Docker/執行環境」這個大類下
• 資訊完整度：有標準的「重現步驟」段落、有版本、有實際設定內容（phpunit.command 的完整字串）、有錯誤輸出——齊全，跟前面 #420 一樣屬於範本等級的回報

#430：Code coverage 找不到測試結果檔案 ../coverage-00000000-0.xml。

• 分類：bug
• 嚴重程度：只影響 coverage 功能，核心的執行測試／除錯功能不受影響——回報者自己也註明「不用 coverage 或用 debugger 都正常」
• 重複回報：跟既有 coverage 相關 issue（例如已關閉的 #368、#330、#324）標題與症狀不同，屬於新的觸發路徑，不算重複
• 資訊完整度：有重現步驟、有版本、有輸出 log、還附上專案結構——齊全

❌✅ 對照：AI 該怎麼處理「資訊不足」的 issue

用一個假設情境（依這個專案性質推演，不是真實逐字 issue）示範一個常見誤區：AI 面對資訊不夠的回報時，該不該自己腦補去填空。

❌ AI 自己腦補缺漏的資訊：
「使用者說『測試跑不出來』，沒附版本號，
 但根據錯誤訊息看起來像是 Docker 相關問題，
 我猜測他用的是 Docker Compose，
 直接把這則歸類成『Docker 環境問題』並標記為
 跟 #416 重複，不用再問使用者。」
→ AI 用「看起來像」取代「使用者實際講的」，
   猜錯的話，回報者會覺得自己的問題被誤判、被合併錯地方，
   下一次回報意願直接下降

✅ AI 明確列出缺什麼，缺口留給人決定怎麼問：
「這則 issue 缺少：(1) 擴充套件版本 (2) 執行環境
 （本機／Docker／SSH／Sail，未指明）(3) 重現步驟。
 目前無法判斷是否與 #416（Docker Compose 相關）
 或 #415（Pest 平行模式）重複——兩者都需要環境資訊
 才能比對。建議請回報者補充執行環境與版本後
 再進行歸類。」
→ AI 只做它能確定的部分（缺什麼、目前判斷不了什麼），
   把「要不要現在去問」「要不要先當作低優先度擱置」
   這種判斷留給維護者

AI 在 triage 裡最大的價值不是「幫忙下結論」，而是「幫忙把不確定的地方講清楚」——這句話值得貼在檢查清單最上面。一個看起來很篤定的錯誤分類，比一個誠實說「資訊不夠」的 AI 更危險，因為後者至少不會讓維護者被誤導著走。

為什麼「排優先序」不能交給 AI

回到前言的問題：AI 讀得懂 issue 內容，為什麼不能直接排優先序？

因為排優先序需要的輸入，遠遠超過 issue 文字本身：這個功能是不是專案這一季的重點方向、修這個 bug 會不會牽動正在進行中的其他重構、這個回報者是不是長期貢獻者值得優先照顧、维護者這週有多少心力——這些脈絡活在維護者的腦子裡，不在 issue 的文字裡，AI 沒有管道去讀取。

硬要 AI 排優先序，它能做的頂多是套用表面規則（例如「有 bug 標籤的都排在 feature 前面」「留言數多的排前面」），這種規則性排序看起來像是有依據，但完全可能跟維護者真正的判斷背道而馳——留言數多可能只是因為描述模糊、大家在問問題，不代表它更急迫。把不確定的規則包裝成篤定的排序，是比誠實承認「這個我判斷不了」更糟的結果。

所以這套 triage 流程刻意停在「整理成維護者可以直接判斷的狀態」，不往下一步走。AI 交出去的是四個維度都填好的檢查表，不是一個數字化的優先序分數。

今日思考題

如果你自己維護過任何一個接受外部回報的專案，你有沒有遇過「表面資訊看起來重複，但深入看其實是不同根因」的兩則 issue？你當時是靠什麼線索分辨出來的——症狀相似度，還是環境差異？

今日重點回顧

• Triage（分類、嚴重程度、重複回報判斷、資訊完整度）跟「排優先序」是兩個不同階段，前者機械性可規則化，後者需要维護者的專案脈絡
• 具體的四維檢查清單：分類、嚴重程度、重複回報、資訊完整度，每一維都可以拆成逐條核對的檢查項
• 用真實 open issue（#420、#416、#430）示範：#420 資訊接近範本等級，#416 有重現路徑但沒有標準步驟段落，#430 齊全但不影響核心功能
• AI 面對資訊不足的 issue，該做的是明確列出缺什麼，不是腦補猜測後直接下結論
• 排優先序的決定權必須留給維護者，因為它需要的脈絡不在 issue 文字裡

老派工程師的心得

以前覺得 issue 管理是「隨手回一回」的雜事，真正花時間拿這套檢查清單去跑幾則 issue 之後才發現，光是「重複回報判斷」這一項就有很多眉角——症狀像不代表根因一樣，環境不同往往就是不同的 bug。這種細節如果沒有清單逼自己每次都檢查完整，很容易漏看，尤其是回報數量一多、人會不自覺開始抓大概。AI 在這裡的好處反而不是它比人聰明，而是它不會嫌麻煩、不會因為看多了就跳過某一項检查——這件事本身就有價值。

明日預告

明天要更深入一則具體案例：AI 判斷一個 issue 是不是重複回報，到底準不準——會拿這個專案裡「Duplicate」相關的真實 issue（包括曾經被標記為 duplicate 關閉的回報）來驗證，看看 AI 的判斷跟實際結果對不對得上。