用 Codex 做 Bug 分診
說明如何讓 Codex 只讀掃查 Sentry、Slack、Linear、GitHub 和 logs 中的 bug 訊號。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| Bug 分診 | triage | 給一堆 bug 排優先順序和歸類。 |
| 嚴重度 | severity | bug 影響程度的分級。 |
| 復現資訊 | repro info | 分診需要的復現和環境資訊。 |
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你用 Codex 給一堆 bug 做分診（排優先順序、歸類、定位線索）。
你是 Codex Bug 分診規劃顧問，幫我用 Codex 給一堆 bug 排優先順序、歸類、給出初步定位線索。
【角色】
你知道怎麼用 Codex 做 bug 分診、按嚴重度和影響排序、從復現資訊給初步定位。
【輸入】
- 我手上的 bug 列表 / 來源：___
- 分診標準（嚴重度 / 影響面 / 頻率）：___
- 每個 bug 有多少復現資訊：___
- 團隊的處理能力：___
【工作流程】
1. 按標準給 bug 排優先順序
2. 歸類（同源 / 同模組 / 重複）
3. 據復現資訊給初步定位線索
4. 給該先修哪些的建議
【輸出規範】
▌一、優先順序排序 + 依據
▌二、歸類結果
▌三、初步定位線索
▌四、先修建議
【硬約束】
- 分診基於實際復現資訊，不憑猜斷嚴重度
- 復現資訊不足的標出來，別硬排
- 定位是線索不是結論，需驗證
- 安全類 bug 優先順序單獨提
- 不確定的標註需進一步排查Bug triage 的目標，是把散落在 Sentry、Slack、Linear、GitHub、PR checks、support tickets、logs 和 dashboards 裡的訊號，整理成可分派、可復現、可驗證的優先順序列表。
第一版 bug triage 必須只讀：不 post、不 create、不 assign、不 label、不 close、不 rerun、不 edit。
Automation bug triage
官方 bug triage 場景。
Automations
手動報告穩定後，再沉澱為 automation。
MCP and plugins
讀取外部系統前先確認許可權和資料來源。
推薦流程
flowchart LR
Sources["sources"] --> Sweep["read-only sweep"]
Sweep --> Report["P0-P3 report"]
Report --> Refine["dedupe / evidence / priority"]
Refine --> Automation["automation"]
Automation --> Drafts["draft follow-ups"]適合 Codex 的分診任務：
- 讀取多個來源。
- 合併重複報告。
- 按 P0-P3 輸出優先順序。
- 分開事實和推測。
- 給每個 bug 附證據連結。
- 起草 follow-up，但先不釋出。
不適合第一版就做：
- 自動建立 issue。
- 自動分派負責人。
- 自動關閉 bug。
- 自動重跑 CI。
- 自動給客戶或團隊頻道發訊息。
起始提示詞
請為 [repo/service/team] 做一次 bug triage sweep，覆蓋最近 [time window]。
輸入來源：
- Sentry：[project / alert link / none]
- Slack：[channel / thread links / none]
- Linear：[team / project / view / issue query / none]
- GitHub：[repo / issue query / PR checks / none]
- Other：[logs / support tickets / deploy link / dashboard / attached file / none]
輸出：
- 先說明哪些輸入來源無法訪問
- 按 P0 到 P3 返回 bug 列表
- 沒有發現時明確寫“沒有發現符合條件的 bug”
每個 bug 包含：
- Priority
- Title
- Evidence
- Recommended next action
規則：
- 不要 post、create、assign、label、close、rerun 或 edit
- 重複報告合併到同一個 bug 下
- 已觀察證據和推測分開把方括號替換成真實專案、時間視窗和資料來源。沒有接入的來源就寫 none，不要讓 Codex 猜。
輸入來源要具體
不要只說“看一下最近 bug”。寫清：
- Sentry project 或 alert URL。
- Slack channel 或 thread links。
- Linear team、project、view 或 issue query。
- GitHub repo、issue query 或 PR checks。
- deploy link、dashboard、support queue、log file 或 attached file。
如果某個內部來源 Codex 不能直接讀取，可以透過 plugins、connectors、MCP servers、repo CLIs、links、exports、attachments 或 pasted logs 提供。
調報告格式
自動化前，先把報告調到每天值得讀。一份可用報告應滿足：
- 高訊號 bug 按 P0 到 P3 排序。
- 重複報告歸併到同一個 bug 下。
- 每個 bug 都有 evidence links 或 short citations。
- 事實和推測分開寫。
- 每個 bug 都有 recommended next action。
- 無法訪問的來源明確列出。
可以在同一執行緒裡繼續要求 Codex：
- 再檢查一個來源後重新排序。
- 去掉團隊已知噪聲 alert。
- 只返回 P0 和 P1。
- 合併 Slack、Sentry、GitHub 中指向同一問題的內容。
- 每個 bug 只保留最有價值的一個連結。
何時自動化
當 on-demand report 已經有用時，不要換執行緒。繼續在同一執行緒裡讓 Codex 建立 automation，這樣它能複用剛剛調好的排序規則、來源範圍和輸出格式。
自動化前確認：
- 輸入來源穩定。
- 外掛和連線方式可用。
- 輸出格式不會太長。
- P0-P3 標準清楚。
- 只讀邊界仍然保留。
後續流轉
定時報表穩定後，再決定後續流轉。Codex 可以起草：
- 團隊 Slack update。
- 需要追蹤的 Linear issue。
- failing PR 的 GitHub comment。
- on-call handoff note。
這些動作建議先保持 draft。確認報告質量穩定後，再逐步放開建立、評論、分派或更新動作。
驗收清單
- 所有輸入來源和不可訪問來源都寫清。
- 報告只讀，沒有外部寫入動作。
- P0-P3 標準一致。
- 重複報告已合併。
- 每個 bug 有 evidence 和 next action。
- 自動化前已經手動跑過並調過報告格式。
- 任何釋出、建立、分派動作都先走草稿。