程式錯誤分流流程圖（bug triage）
程式錯誤分流流程圖：缺陷受理、重現、重複項檢查、嚴重程度與優先次序、呈報、修正、程式碼覆核、QA 驗證與發布上線。
甚麼是程式錯誤分流流程圖（bug triage）流程
程式錯誤分流，就是把不斷湧入的缺陷報告變成一條有序工作佇列的做法。每一份報告都會登記，有人嘗試重現，重複項會連回原始紀錄，餘下的則獲賦予嚴重程度與優先次序，讓開發團隊知道接下來該拿起哪一件。這個名稱是刻意由急症分流借來的：重點不是把所有問題都修好，而是快速判斷甚麼現在就要處理、甚麼可以等、甚麼直接結案。
缺陷處理的大部分成本，都發生在寫下第一行程式碼之前。一份沒有建置版本、沒有環境資訊的報告無法重現，於是在支援人員與報告人之間來回一個星期。一個無人做過重複項檢查的缺陷，會在兩條分支上被修兩次。由喊得最大聲的人定下的嚴重程度，會把待辦積壓變成一場談判。把流程按泳道畫出來，每一次交接都變得明確，每一條分支也都有具名的負責人。
這個範本是一個橫跨五條泳道的可用分流流程：報告人、支援、分流負責人、開發與 QA。它包含團隊通常不會寫下來的那些分支——索取更多資訊的迴路，以及最終為它收尾的「無法重現」結案；重複項連結；嚴重缺陷與生產環境停止服務的呈報通道；以及 QA 驗證不通過時重新開啟的路徑。
本流程圖涵蓋的內容
本範本包含
- 報告人與支援兩條泳道上的受理：用戶報告缺陷，隨後在缺陷追蹤系統中登記，附上建置版本、環境、準確的重現步驟，以及預期行為與實際行為的對比
- 支援泳道中的重現迴路：「嘗試重現缺陷」之後是「缺陷可以重現嗎？」這個決策，它要麼把報告送入分流，要麼把它轉入索取更多資訊
- 多數流程圖都會略過的那條死路：「報告人是否在期限內回覆？」這個決策把已回覆的報告送回再做一次重現嘗試，把無人回覆的結案為「無法重現」
- 分流負責人的兩個決策：「是否為某個未結案缺陷的重複項？」這項檢查把重複項連結到原始紀錄並結案，隨後對確屬新問題的缺陷「設定嚴重程度與優先次序」
- 「是否嚴重或生產環境停止服務？」分支：它會建立一次生產事故並把修正直接送到開發，而標準缺陷則分配給負責團隊並放入該團隊的待辦積壓
- 修正與驗證：「開發並完成單元測試」、「程式碼覆核是否通過？」這道關口把返工退回開發、在測試環境進行 QA 驗證並帶有重新開啟的分支，最後是發布到生產環境並通知報告人
何時使用本範本
- 你們第一次把分流流程寫下來，因為報告經支援工單、銷售電話和 Slack 訊息湧進來，而由誰決定修甚麼並無共識
- 你們要設定——或重設——嚴重程度與優先次序的定義，此時一張「誰在哪一步賦值」的圖，比一份無人打開的政策文件更有用
- 你們要帶新的支援工程師和分流負責人上手，他們需要看清哪些決策屬於自己，以及報告交出去之後會發生甚麼
- 你們要在 Jira、Linear 或 GitHub Issues 設定工作流程，讓工具承載一個已達成共識的流程，而不是靠狀態名稱自行發明一個
- 你們想減少那些擱置數月無人處理的缺陷，做法是把索取更多資訊的迴路和「無法重現」的結案變成明確步驟，而不是靠默契
運作方式
把泳道改成你們真實的角色
把報告人、支援、分流負責人、開發與 QA 換成你們自己的職能。小團隊常把支援與分流合併成一條泳道；沒有專職 QA 的團隊通常把驗證交給另一位工程師。按決策者劃分泳道，而不是按人劃分——否則只要有人轉職，圖就不再符合現實。
把你們的嚴重程度與優先次序定義寫在分流步驟上
嚴重程度是缺陷一旦發生所造成的影響；優先次序是它甚麼時候會被處理。為每一個級別配一個具體例子，例如最高級是資料遺失或結帳流程被阻斷，最低級是一處版面錯位。沒有例子，所有報告都會以最高級別抵達，這個欄位也就不再承載任何資訊。
設定呈報的門檻
把籠統的「是否嚴重或生產環境停止服務？」換成你們真實的觸發條件：受影響的客戶數量、被阻斷的收入路徑、面臨風險的資料。寫明誰有權宣布一次事故，以及事故流程在哪裡——分流在那一刻把缺陷交接出去，而缺陷紀錄仍然開啟，等待永久修正。
決定資訊迴路要跑多久
「報告人是否在期限內回覆？」這個決策需要一個寫明的等候期，通常還需要一次催辦。把這個數字寫在步驟上。沒有它，那些從來無法重現的報告會無限期開啟，待辦積壓也就不再反映真實的工作量。
就驗證的含義以及重新開啟的去向達成共識
寫明 QA 是對照報告人最初的重現步驟驗證、對照迴歸測試套件驗證，還是兩者都做。這個範本把驗證失敗退回同一條紀錄上的開發環節，讓歷史留在一處。如果重新開啟的缺陷應當重新排定優先次序、而不是被直接接著處理，就把它改成退回分流。
把它發布出去，並只保留一個現行版本
把圖放在缺陷報告表單旁邊和當值操作手冊裡，取得支援、開發與 QA 的簽署確認，並保留歷史版本，以便看出流程是何時改動的。每當有一個缺陷的解決時間遠超應有水平，就把它拿出來重看一次，修好它卡住的那一步。
常見問題
程式錯誤分流流程包含哪些階段？
在多數團隊裡是五個。受理，報告在這裡登記，細節要足夠支撐後續行動。重現，支援人員在這裡確認缺陷確實存在，而不是設定問題或用戶操作失誤。分流，在這裡連結重複項，並賦予嚴重程度、優先次序和負責團隊。修正，涵蓋開發與程式碼覆核。驗證，QA 在這裡對照最初的報告檢查修正，然後發布並通知報告人。上面的圖正是把這五個階段作為階段欄，其中重現與分流承載了完成大部分工作的那些決策。
嚴重程度與優先次序有甚麼分別？
嚴重程度描述缺陷造成的影響：資料遺失、工作流程被阻斷、外觀問題。優先次序描述它甚麼時候會被處理。兩者回答的是不同的問題，應當保持為兩個獨立欄位。一處已公開價格上的錯字是低嚴重程度、高優先次序；只有兩個客戶在用的功能當機，可能是高嚴重程度、低優先次序。把它們合併成一個欄位，是分流流程失去可信度最常見的原因——因為最後所有東西都堆在量表的頂端。
程式錯誤分流應該多久跑一次，誰需要在場？
對上一次之後新提出的所有內容做一次簡短的例行梳理：面向消費者的線上產品每日一次，發布周期較慢的團隊每周兩次。通常三個角色就足以作決定：一位能說清客戶影響的支援人員，一位對嚴重程度與優先次序負責的分流負責人，以及一位知道哪個團隊擁有相關程式碼的開發負責人。任何嚴重問題或生產環境停止服務都不應等到會上——這也是這張圖把它立即呈報為事故、而不是排進佇列的原因。
無法重現的缺陷應該怎樣處理？
把它結案，但必須在走完一個明確的迴路之後。就缺失的細節索取一次（建置版本、環境、準確步驟、一段螢幕錄影），在寫明的等候期內催辦一次，然後結案為「無法重現」，記下理由，並明確邀請對方在問題再次出現時重新開啟。這個範本把這條迴路畫成報告人泳道中的一個決策，而不是留給個人判斷，因為無法重現卻永遠開啟的報告，正是把待辦積壓變成無人閱讀的清單的東西。