昨天我把每天收到的大量資訊做了一次篩選，從一百則內容裡先去重、分類、評分，最後只留下真正需要看的十則，做到這裡之後，我開始想把自動化從「整理我看到的資訊」再往工作流程裡面推一點。

剛好 GitHub Issue 就是一個很適合拿來測的地方，因為只要專案開始有人使用，Issue 的寫法就很難完全統一，有人會很完整地附上版本、錯誤訊息和重現步驟，也有人可能只留一句「登入壞掉了」，最後還是得先花時間判斷這到底是 Bug、Feature、操作問題，或只是資料根本沒給完整。

這種整理工作不算難，但每一筆都要重新讀一次，數量一多就滿適合交給 AI 先處理。

先讓 AI 讀 Issue，不急著叫它修

我今天先把範圍控制得很小，新的 Issue 進來之後，AI 只負責分析內容，再整理出固定幾個欄位。

像是一個 Issue 寫：

昨天開始一般帳密都登不進去
Google 登入正常
按登入後只會一直轉圈
Chrome 跟 Edge 都試過了

我希望 AI 最後整理成類似：

{
  "type": "bug",
  "component": "authentication",
  "priority": "high",
  "missing_information": [
    "application version",
    "error log"
  ]
}

有了這層之後，後面的 Workflow 就比較好接，Bug 可以加上 bug Label，Feature Request 可以進另一個 Queue，資料不完整的 Issue 也可以先標出還缺什麼，至少不用每一筆都從頭人工分類。

Priority 比想像中難判斷

一開始我有想過直接讓 AI 分成 High、Medium、Low，後來才發現如果沒有定義清楚，AI 很容易把很多事情都判成 High。

「登入失敗」可能真的很嚴重，但如果只是單一使用者的環境問題，跟所有人都無法登入完全是不同等級，所以 Priority 不能只看 Issue 裡出現哪些字，還得考慮影響範圍、是否有替代方式、功能重要程度，以及目前資訊到底夠不夠。

所以我後來把判斷標準補得更明確，例如影響核心功能、影響多數使用者、目前沒有替代方式，可以往高優先級靠；只有單一使用者、可以繞過、資訊又不完整，就先不要急著升到最高。

這跟前面做 Email 分類時遇到的問題其實有點像，只叫 AI「判斷重要性」通常不太夠，真正需要的是一套可以重複使用的判斷標準。

我後來最喜歡的是「找出缺什麼」

原本做這個流程時，我最期待的是 AI 自動分類 Bug 和 Feature，真的跑幾筆之後，我反而覺得 Missing Information 這個欄位更實用。

因為很多 Issue 最花時間的地方，常常是來回追問。

使用者說「按鈕不能用」，但沒有 Browser；說「系統報錯」，卻沒有 Error Message；說「昨天還可以」，又沒寫目前版本，工程師看到之後還是得再問一次，等對方補完才能開始找問題。

如果 AI 可以先把缺漏資料整理出來，例如：

目前還需要：
1. 重現步驟
2. Browser / OS
3. 錯誤訊息
4. 畫面截圖
5. 發生頻率

那它就開始從單純幫我貼 Label，變成真的在減少前面的整理工作。

目前我還不讓 AI 自動回覆

做到這裡我有刻意先停一下，因為分類和建立 Label 的風險很低，就算判斷錯了，人工修掉就好，但如果下一步直接讓 AI 用專案官方身分留言，甚至承諾修復時間，事情就不太一樣了。

所以今天的版本先維持：

New Issue
AI 分析
產生分類結果
檢查缺漏資訊
加入 Label
留下紀錄

需要對外回覆的部分先保留人工確認，等前面的判斷夠穩定之後，再決定哪些步驟適合繼續往後自動化。

Day 9 自動化紀錄

今天第一次把 AI 自動化接進 GitHub Issue，我原本以為最大的價值會是自動分類，實際做完之後，反而覺得它更像是一個「進件整理員」，先把內容看過、分好類型、標出優先級，再告訴我目前還缺哪些資訊。

前幾天我一直在把 Email、文章和每天收到的資訊整理乾淨，Day 9 開始則有一點不一樣，AI 已經慢慢從整理資訊走進真正的工作流程，而接下來更有趣的問題，就是這些整理好的 Issue 到底能不能再往 Coding Agent 那邊送。