要用 AI 將 Bug 報告轉成重現步驟，先給模型一個經去識別處理的證據包，讓它把報告中的事實與假設分開，並要求輸出一份附編號的操作流程，包含環境、前置條件、最少數據、預期結果、實際結果、觀察點和明確的未知項。然後由人在受控環境中執行這些步驟。AI 可以整理出一份候選重現方案，但它不能如實地說「這個 Bug 已經重現」。

這是一個範圍很窄的文件流程。較廣泛的安全使用 AI 指南介紹輸入界線和人手批准。一旦有人能夠重現故障，便可以用另一套 AI 除錯流程調查成因和修正方法。不要把這兩個階段合併：看似合理的成因不是重現步驟，精緻的流程也不能證明有人實際執行過它。

關鍵要點：

改寫之前，先保留報告者提供的證據。

把每項陳述標示為報告、觀察、推斷或未知。

明確寫出環境、狀態、數據和時間安排。

優先使用最小測試個案，而不是冗長的敘述。

在同一個觀察點記錄預期結果和實際結果。

由人執行、修訂並批准最終的重現套件。

Bug 報告證據應如何凍結和清理？

一份有用的 Bug 報告可能包含標題、文字描述、表格欄位、留言、日誌、截圖、影片或測試失敗資料。收集這些材料，但不要悄悄改寫它們。GitHub 把 issue 視為記錄工作的地方，並支援結構化的 issue 表格；表格欄位可以要求填寫重現步驟、預期行為和日誌等細節。［1］［2］結構化能改善資料收集，但不能證明每個欄位都準確。

使用 AI 工具前，刪除或替換密鑰、存取權杖、工作階段 cookie、私鑰、個人資料、客戶識別碼、私人原始碼、內部主機名稱和機密日誌。遵守所屬機構批准的資料處理政策。如某項材料不能分享給所選工具，便只在本機概括必要的事實，或使用獲批的私人環境。保留對原始材料的引用，方便覆核者比對轉換前後的內容。

建立一份小型收件登記表：

欄位	記錄內容
報告 ID	穩定的 issue 或工單編號
報告者陳述	確實的主張或簡短的引文片段
證據	獲批的日誌、圖片、影片時間點或測試輸出
來源時間	事件發生和證據產生的時間
環境	產品、版本、平台、瀏覽器或執行環境
可信類型	報告、直接觀察、推斷或未知
敏感資料	已刪除、已替換、受限或不存在

不要只因可以取得，便貼上整個程式碼庫或正式環境日誌。重現通常只需要一小組有區分力的事實，而不是盡可能大的上下文窗口。

怎樣分開事實、推斷和未知？

要求 AI 把陳述擷取到四欄：報告的事實、直接證據、候選推斷和未知。這可防止文法上的修飾把不確定變成確定。例如，「我按下儲存後頁面卡住了」是報告者的陳述；顯示按鈕動作和卡住狀態的影片是直接證據；「是資料庫鎖導致的」則是一個假設，除非有另外的證據證實。

使用以下提示：

你只負責整理 Bug 報告，而不是診斷它。

把每項陳述分類為：
1. 用戶報告的內容；
2. 附件直接支持的內容；
3. 不得作為事實陳述的推斷；或
4. 未知或互相矛盾的內容。

不要虛構動作、數值、版本、時間、帳戶狀態、網絡條件、成因或重現成功。
每項事實都引用證據 ID。每個欠缺的必填欄位，都返回相應的問題。

對照原始材料覆核擷取結果。刪除無法追溯到某項材料或陳述的事實。互相矛盾之處——例如兩個不同的應用程式版本——應放進未知項清單，而不是被綜合成一個折衷值。

列明環境和起始狀態

當隱藏的狀態不同時，重現便會失敗。記錄可能改變結果的最小環境描述：

建置、發佈、提交或介面版本；
相關時的作業系統、瀏覽器、執行環境或裝置類別；
帳戶角色、功能開關、語言地區、時區和權限；
只在有證據時記錄網絡模式或外部依賴的狀態；
數據夾具、快取狀態、之前的工作流程狀態和安裝紀錄；
測試是由全新工作階段、已知快照，還是現有狀態開始。

不要把「最新版本」變成一個版本號，而要請報告者提供實際數值。不要從截圖邊框推斷瀏覽器，從用戶名稱推斷帳戶角色，或從逾時推斷網絡問題。如某個欄位無法取得，便寫 unknown，並說明測試者如何取得它。

把前置條件寫成可以在第 1 步前檢查的斷言。「存在一個名為「示例」的項目，而且測試者擁有編輯者權限」比「開啟你的項目」更好。當狀態的重建成本很高時，引用一個去識別的夾具或準備流程，而不是嵌入機密數據。

如何用 AI 將 Bug 報告轉成重現步驟的原子動作？

每個重現步驟都應描述一個用戶或系統動作，並在有用時附上一個觀察。避免「正常設定」「再試一次」或「使用該功能」這類含糊的動詞。寫出證據中的控制項、指令、欄位、數值或事件的名稱。保持報告中的次序；改變次序可能令 Bug 消失。

一個好的步驟序列如下：

核實所述的起始狀態；
執行一個精確的動作；
當某個中間觀察能分辨不同分支時，記錄下來；
執行下一個動作；
在一個具名的觀察點比較預期結果和實際結果；
收集再次執行所需的獲批證據。

只有在有依據時，時間和重複次數才寫進步驟。如報告者說問題「有時」出現，不要把它寫成「每三次出現一次」。而應界定一個有界線的執行計劃，例如嘗試十次，並在測試者執行前把觀察到的頻率留空。

預期與實際結果應以甚麼為依據？

預期行為應來自已批准的需求、規格、測試、說明頁面或產品負責人，而不是模型覺得直觀的內容。實際行為應描述證據所顯示的內容，而不歸咎成因。

兩者使用同一個觀察點：

觀察點	預期	實際	證據
選擇儲存後	顯示確認提示，狀態變為已儲存	在錄影片段中，載入圖示一直顯示	影片 E2，00:18–00:31

如預期行為沒有權威來源，便標示為「報告者的預期」並要求確認。如實際結果有變化，便記錄每一種觀察到的變體，而不是只揀最嚴重的一種。

怎樣的測試個案才算最小？

MDN 建議在報告瀏覽器問題時提供一個最小的獨立測試個案，因為刪除無關程式碼能令缺陷更易隔離和分享。［3］最小並不表示人為造作，而是指餘下的每一項輸入都是觸發所觀察結果的必要條件。

用 AI 提出一個縮減隊列，而不是宣布縮減已經成功：

以合成夾具取代正式環境紀錄；
每次刪除一個無關的欄位、外掛、擴充功能或要求；
在保持次序的前提下縮短動作序列；
隔離一個帳戶角色、語言地區或設定；
把長程式碼轉換成最小的獲批片段；
保留一個預期不會出現故障的對照個案。

每一次縮減都必須由人執行。把它標示為 retained、removed 或 not tested，並保存觀察到的結果。絕不要發佈包含有效憑證、私人端點、真實客戶紀錄或應受限制的漏洞利用細節的最小個案。

加入觀察點和運行矩陣

當一個流程指出要觀察甚麼、而不預設成因時，之後的除錯會較容易。有用的觀察點包括可見的狀態轉變、狀態碼、安全的日誌事件、佇列計數、資料庫夾具狀態或測試斷言。只納入測試者獲授權存取的訊號。

當證據顯示存在環境界線時，建立一個小型矩陣：

變數	對照	候選變體	結果
版本	上一個獲批建置	報告中的建置	未運行
角色	檢視者	編輯者	未運行
資料	空白的合成記錄	最小填充記錄	未運行

AI 可以建議有區分力的比較，但初始結果必須保持「未運行」。避免建立包含所有瀏覽器、地區、帳戶和裝置的失控矩陣。由證據支持的變數開始，只在結果證明有需要時才擴展。

未知項和重現狀態應怎樣記錄？

Mozilla 的 Bug 撰寫指引強調清晰的步驟、實際結果和預期結果。［4］在 AI 參與時，再加入兩個特別有用的欄位：未知項登記表和可信度標籤。

使用描述證據、而非模型確定程度的可信度定義：

**草稿：**按一份報告整理；沒有獨立執行。
**候選：**欄位完整到足以進行受控執行。
**已觀察一次：**一名獲授權的測試者重現了所述結果一次。
**可重複：**在有紀錄的環境中，結果達到預先界定的執行門檻。
**未重現：**計劃中的執行已完成，但沒有出現報告的結果。
**受阻：**欠缺必需的環境、數據、權限或材料。

不要讓 AI 給出「已觀察一次」或「可重複」的狀態。這些狀態需要有紀錄的人手或自動化執行證據。語言模型再高的可信度分數也無關重要。

可複製的重現包

# 重現包

- 報告 ID：
- 範圍：
- 環境與精確版本：
- 起始狀態：
- 獲批的合成夾具：
- 前置條件：
- 已知的未知項或衝突：

## 步驟
1. [動作]
   - 觀察：
2. [動作]
   - 觀察：

## 結果
- 觀察點：
- 預期結果及依據：
- 報告的實際結果及證據：
- 重現狀態：草稿
- 執行次數 / 門檻：

## 證據
- 證據 ID、時間戳和去識別後的位置：

## 交接
- 測試者：
- 環境負責人：
- 下一項決定：
- 人手批准：

要求模型只填寫證據登記表支持的欄位。要求輸出保留空欄位，並按證據 ID 列出引用。然後把每個已填寫的欄位與來源對照。

執行並批准 Bug 重現套件

在安全、獲授權的環境中執行候選方案。記錄確實的版本、時間戳、夾具識別、步驟偏差和獲批的觀察。如測試者不得不臨場發揮，便更新流程，並由界定好的起始狀態重新執行。不要在一次成功執行後悄悄修改步驟；這會破壞審計線索。

當一位具名覆核者確認該重現套件要麼在界定的門檻下可重複，要麼在界定的測試下未重現，要麼因某個具體原因受阻時，它便離開這個流程。根因假設、修補和回歸測試屬於下一個流程。需要檢查生成的主張時，使用 AI 事實核查方法；範圍穩定後設計測試，請使用 AI 產生測試指南。

常見問題

AI 可以直接替我重現 Bug 嗎？

它可以整理證據並草擬流程。只有在連接到獲授權的環境和工具鏈時，它才能執行測試；即使如此，確立結果的也是有紀錄的執行，而不是文字。

原報告資料不足怎麼辦？

把欠缺的欄位保留為未知項，並產生有針對性的問題。不要為了令範本看來完整而虛構版本、動作、帳戶狀態或預期結果。

應否加入截圖或影片？

在獲批而且有用時使用，但要加上時間戳和文字說明。刪除個人或機密資料，也不要把視覺背景當作隱藏狀態的證據。

運行多少次才算可重複？

測試前，按影響、成本和預期的間歇程度界定一個門檻。記錄所有嘗試和環境；沒有通用的數字。

重現和診斷有何分別？

重現是在已知條件下確立一個可重複的觀察結果。診斷是評估關於它為何發生的假設。把這兩類主張和批准分開。

AI 能建立最小測試個案嗎？

它可以建議縮減方式和合成夾具。每一次縮減都必須由人或獲授權的測試系統執行，並確認故障仍然存在。

如何處理敏感日誌？

使用獲批的儲存和工具，盡量縮短摘錄，刪去密鑰和個人資料，並在政策容許時保留對原始日誌的受限引用。

何時可轉入除錯？

當重現結果、環境、證據和未知項都足夠明確，令調查者毋須改寫歷史便能評估假設時，便可以轉入除錯。

來源

Sources checked 2026 年 8 月 29 日。

GitHub Docs, “Quickstart for GitHub Issues” — https://docs.github.com/en/issues/tracking-your-work-with-issues/learning-about-issues/quickstart
GitHub Docs, “Syntax for GitHub's form schema” — https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-githubs-form-schema
MDN Web Docs, “How to file a bug” — https://developer.mozilla.org/en-US/docs/Learn_web_development/Howto/Web_mechanics/File_browser_bugs
Mozilla Bugzilla, “Bug Writing Guidelines” — https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html

用 AI 將 Bug 報告轉成重現步驟：不臆測根因，亦不捏造結果