AI Team 已驗證
此流程已在日常開發中實踐，錯誤分類決策樹有效協助判斷修復策略。
錯誤修復流程
錯誤修復與新功能遵循不同的工作流程。關鍵問題：這個錯誤反映的是規格問題還是實作問題？
錯誤分類決策樹
依錯誤類型的流程
| 錯誤類型 | 規格變更 | 流程 |
|---|---|---|
| 實作錯誤 | 否 | 診斷 -> 修復 -> 測試 -> 提交 |
| 規格缺口 | 是（澄清） | 診斷 -> 更新規格 -> 修復 -> 測試 -> 提交 |
| 規格錯誤 | 是（提案） | 診斷 -> 建立提案 -> 審查 -> 修復 -> 測試 -> 歸檔 |
| 邊界案例 | 是（擴展） | 診斷 -> 新增情境 -> 實作 -> 測試 -> 提交 |
實作錯誤流程（無規格變更）
步驟
- 診斷 - 識別根本原因，定位相關規格
- 驗證 - 確認規格定義預期行為，實作偏離
- 修復 - 代理產生符合規格的修復
- 審查 - 人類驗證修復符合規格意圖
- 測試 - 驗證修復，無迴歸
- 提交 - 直接提交，不需提案
規格缺口/擴展流程（需更新規格）
步驟
- 診斷 - 識別未涵蓋的邊界案例
- 更新規格 - 新增描述預期行為的情境
- 修復 - 代理實作新指定的行為
- 審查 - 人類驗證規格新增與實作
- 提交 - 規格與程式碼一起提交（原子性）
規格錯誤流程（設計缺陷）
步驟
- 診斷 - 識別規格設計缺陷
- 建立提案 - 記錄規格為何錯誤，提議修正
- 審查提案 - 團隊驗證規格變更
- 實作 - 代理實作修正後的行為
- 歸檔 - 完整提案流程，規格更新至
specs/
代理在錯誤修復中的角色
| 階段 | 代理貢獻 |
|---|---|
| 診斷 | 搜尋程式庫、識別潛在根本原因、定位相關規格 |
| 規格分析 | 比對實作與規格、標示差異 |
| 修復產生 | 產生符合規格（或提議規格變更）的修復 |
| 測試產生 | 產生涵蓋錯誤情境的測試案例 |
| 迴歸檢查 | 識別可能受影響的區域 |
錯誤修復的關鍵原則
- 規格即真理 - 若程式碼與規格不符，程式碼是錯的（除非規格有缺陷）
- 原子提交 - 相關的規格變更與程式碼修復一起提交
- 不靜默修復 - 錯誤修復期間發現的規格缺口必須記錄
- 測試該情境 - 每個錯誤修復都應新增涵蓋失敗案例的測試
反模式
| 反模式 | 問題 | 正確方法 |
|---|---|---|
| 修復前不檢查規格 | 可能「修復」預期行為 | 永遠先定位相關規格 |
| 更新規格以符合錯誤程式碼 | 使錯誤合法化 | 規格反映意圖，非意外 |
| 跳過邊界案例的規格更新 | 缺口仍未記錄 | 即使「明顯」的修復也要新增情境 |
| 透過錯誤修復進行大型規格變更 | 繞過提案審查 | 重大變更需要提案 |
相關： 工作流程框架概覽