AI Bug Triage 實戰：BA／PM 用 AI 分類、排查同寫 Bug Report 嘅 5 步工作流

2026-09-09 · BA × AI 實戰 · Eric Cheung

Bug Triage 唔係 Developer 專利：BA／PM 先係第一道閘

「呢個 bug 好 urgent 呀，可唔可以盡快 fix 咗佢？」——做 BA／PM 嘅你，一個禮拜總有幾日係咁開始。用家唔會幫你分 severity，CS 轉過嚟嘅 message 得一句，Developer 就話「repro 唔到，唔關我事」。喺呢啲時候，第一個要做判斷嘅人通常唔係寫 Code 嗰個，而係你。

Bug Triage（缺陷分類排查）借咗戰場醫療嘅概念：傷者太多，醫護要按傷勢決定邊個先救。軟件開發都係同一道理——唔係叫你整 bug，而係叫你對每一單缺陷快速做三個決定：呢單係咩事？有幾嚴重？應該點處理？本文用 5 步工作流示範 BA／PM 點樣用 AI 將「亂晒籠」嘅 bug 報告，變成 Developer 一睇就明、一開工就 fix 到嘅清晰任務。

快速結論（TL;DR）

• Triage ＝ 分類＋排序＋指派，唔係整 Bug；BA／PM 係天然嘅 Triage Owner，Developer 反而等你畀方向
• 5 步：標準化收集 → 分類排序 → 重現排查 → 撰寫指派 → 追蹤驗收，每一步都有 AI 幫手位
• AI 最叻：將「用家亂嗡」整理成結構化報告、計影響範圍、草擬重現步驟、寫 Ticket、出老化清單
• 紅線：AI 只出草稿同建議，Severity 政策同最終決定一定要人做；客戶資料同 Production 數據入 Prompt 前一定要清洗
• 落地門檻好低：一張 Triage Template ＋ 五條 Prompt 就開到工，隨時可以開始試

Step 1 — 標準化收集：將「亂嗡」變成結構化報告

Bug 報告九成都係咁樣嚟：WhatsApp 語音、Email 三行字、CS 轉述、甚至 meeting 入面一句「好似有啲嘢壞咗」。第一步唔好急住判斷，先將所有嘢變成同一種格式——呢樣正正係 AI 天生好手：將語音轉文字、抽走情緒字眼、按固定欄位重組。

• 固定 Template 欄位：發生時間、環境／版本、重現步驟、實際結果、預期結果、影響範圍（邊個功能、幾多用戶）、有冇 Log／截圖、報告人聯絡
• 先建立單一入口：一個試算表或一張 Board，所有 incoming bug 統一入呢度——睇唔晒就 triage 唔到

每次收到新報告，用同一條 Prompt 叫 AI 整理（以下為示範格式，可直接複製改寫）：

將以下用家報告整理成 Bug Report 草稿，用呢啲欄位：發生時間、環境／版本、重現步驟（逐步）、實際結果、預期結果、影響範圍。
規則：唔好加料、唔好猜測，缺資料就寫「未提供」；最後用一句話判斷：呢單同清單入面邊單最似（如果冇就寫「冇明顯重複」）。
用家報告：＿＿＿＿＿＿＿＿＿＿＿＿

Step 2 — 分類同排序：Severity 同 Priority 唔好靠感覺

分類係 Triage 嘅核心，但好多人將兩樣嘢撈埋：Severity（影響有幾大）係缺陷本身嘅性質；Priority（幾急要處理）係你嘅商業判斷。AI 可以幫你計「影響有幾大」，但「幾急」一定要由你按而家嘅 Release 計劃同資源決定。

• Severity（影響度）：Sev 1 核心功能癱瘓／直接金錢損失；Sev 2 主要功能壞但有 Workaround；Sev 3 次要功能或邊緣情況；Sev 4 外觀／體驗小問題
• Priority（急切度）：P1 即刻停低手頭工作處理；P2 今個 Sprint 內；P3 排入 Backlog；P4 有時間先算
• 快速判斷問題：有冇 Workaround？影響幾多用戶？阻唔阻到收款／營運流程？係咪 Regression（以前得，而家唔得）？

將上面幾個問題連埋報告一齊畀 AI，叫佢建議 Severity／Priority 同理由；跟住你用 30 秒覆核——AI 啱嘅機會好高，但最終簽名嘅係你。

Step 3 — 重現同排查：AI 幫你問啱問題、讀啱 Log

Developer 最經典嘅回覆係「Repro 唔到」。喺 Triage 階段做多少少，慳返成個團隊嘅時間：最值錢嘅產出係「穩定嘅重現步驟」同「清晰嘅影響範圍」。AI 呢度有兩個實際用途——第一，對住 Error Message／Stack Trace 幫你問問題：呢個錯誤通常由咩引起？要確認呢個假設仲要攞啲咩資料？第二，幫你諗點樣引導用家補資料。

• 問用家嘅問題要具體：「最後一次正常係幾時？」「淨係你部機，定全部同事都係？」「有冇試過重開／更新？」——AI 可以按個案幫你生成追問清單
• Log 唔使識讀晒：將 Error Message 貼畀 AI（記得先刪走個人資料），叫佢用一句話解釋，再列最可能嘅 3 個原因
• 唔好自己落 Production 亂試：你嘅角色係收窄範圍同準備問題，實際驗證交返畀 Developer 喺 Staging 做

Step 4 — 撰寫同指派：一張 Developer 唔會鬧嘅 Ticket

Triage 嘅產出唔係會議紀錄，而係一張可以直接開工嘅 Ticket。好 Ticket 嘅標準好簡單：Developer 睇完唔使再捉你問三次。標題寫「咩功能＋咩情況＋實際點＋預期點」，Body 跟 Template，附件（截圖／錄影／Log）齊全——AI 可以由 Step 1 嘅整理結果一鍵生成 Ticket 草稿，格式直接對應 Jira／Linear／GitHub Issues。

• 標題公式：［功能］喺［情況］下會［實際結果］，預期係［預期結果］——例如「［結帳］用 PayPal 畀錢時［一直轉圈冇反應］，預期［5 秒內完成］」
• Body 必備：重現步驟（編號列表）、實際 vs 預期、環境、影響範圍、相關 Log／截圖、邊個做咗 Triage 決定
• 指派唔等於負責 Fix 嗰個人：跟專案 RACI，Triage 可以指派「負責調查」嘅人，調查完再轉「負責修復」——兩者唔一定要同一人

文末附咗一條「Ticket 生成 Prompt」，連埋你嘅 Template 一齊用就得。

Step 5 — 追蹤同驗收：唔好畀 Ticket 黑洞吞咗

Triage 做得幾好，冇追蹤都係白做。BA／PM 嘅價值就係令件事「有頭有尾」：定期（每星期一次係好開始）用 AI 出一份 Triage 健康報告——邊啲 Ticket 超過 7 日冇郁過、邊個 Component 嘅 Bug 最多、Reopen 率有冇升——然後喺例行會議用 15 分鐘清一次。

• 老化清單：超過 7 日冇更新嘅 Ticket 自動浮面，逐張決定：繼續等／升級／關閉
• 驗收唔好齋信「Fixed」：Developer 話修好之後，對返原始報告嘅重現步驟行一次 Acceptance，先好 Close
• Reopen 係寶：同一單 Bug 反覆 Reopen，通常代表 Root Cause 未斷——呢啲先係值得升級做正式小專案處理嘅嘢

紅線同私隱：AI 做草稿，你做決定

• Severity 政策唔可以交畀 AI：AI 可以建議，但「幾急」係商業決定，一定要有人負責
• 入 Prompt 之前先脫敏：客戶個人資料、Production 真實數據、內部系統截圖——用假名、遮號碼、刪 Log 嘅用戶欄位，先至可以入 AI
• 留低 Audit Trail：邊個喺幾時做咗咩 Triage 決定，寫低喺 Ticket 度——出事先有得追溯
• AI 唔會幫你問用家：Triage 最關鍵嘅一步永遠係你直接同報告人對清楚——AI 只係令你問得更準

總結：一張 Template 就開到工

成個工作流唔需要新工具、唔需要識寫 Code：一張 Triage Template（試算表就夠）、五條 Prompt、每日朝早 15 分鐘——已經贏過九成「收到 Bug 就喺 IM 群組亂嗌」嘅團隊。記得一個原則：AI 所有產出都係草稿，你嘅判斷先係專業。由你睇到呢篇文嗰日開始，將每一單 incoming bug 都行一次呢個流程——一個月後，你會發現 Developer 返嚟問你「呢單點跟」嘅次數明顯少咗。