導入AI Debug 的部分方法

現在有針對GIT系統的Plugin 方式有兩個大宗

• 直接與GIT 整合的工具: 例如 google jules / OpenAI codex
• 直接在Local 使用的Cli 工具，但要自己整合API 使其可以讀到Issue 本身的內容
  後面的Prompt 大概就會是

目的：修復指定 Bug，並確保專案整體功能與既有流程不受影響，維持穩定性與可運行性。
目標：Bug ID：BUG-12345

範圍：
僅針對該 Bug 相關模組進行修改
避免影響其他功能模組或共用元件


執行要求：
分析 Bug 根本原因（Root Cause Analysis）
提出修復方案，並說明設計決策
修改程式碼以解決問題
確保程式碼符合既有 coding style 與架構設計
補充或更新單元測試（Unit Test）

驗證機制：
執行既有測試（Regression Test），確認無副作用
驗證修復後 Bug 不再重現
檢查關聯功能流程（Critical Path）正常運作

輸出內容：
修復後的程式碼差異（Diff）
Root Cause 說明
修復策略與影響範圍分析
測試結果與驗證方式

限制條件：
不可重構非必要區域
不可引入額外第三方依賴（除非必要且需說明）
優先維持現有系統穩定性與可讀性

在這樣的敘述原則上等待AI 自己進行所有的修正與調整

優缺點分析

當我們導入AI Debug 大概會有以下優點

• 修正速度變快
• 語法校準需求較低
• 能確保統一的寫Code 風格

好，缺點呢。缺點是最明顯的

• Bug 會生BUG
• 對UI 的敏感度很差
• 容易有Side effect

說實話，光看這些缺點就覺得導入AI Fix 根本是在找自己麻煩。
但事實上這種結果其實源自於自己對於AI 導入的流程完全不正確導致

如何優化Debug 過程

讓我們來重新看看一開始的Prompt
好像什麼都要求的，事實上只是放任AI 自己去完成產出，然後等著看結果

修正BUG 時應當自己帶的答案去問AI 怎麼解
將Prompt 改為

目的：
依據使用者提供的修復方向與限制條件，產出 Bug 修復方案，並在實作前經過使用者 Code Review 與確認。

目標：
Bug ID：BUG-12345
問題描述：簡述問題現象與觸發條件

使用者輸入（策略與限制）：
修復方向：例如「優先最小修改」、「避免動到核心模組」、「可接受輕微效能下降」
技術限制：例如「不可新增套件」、「需維持 Python 3.9 相容」
風險偏好：例如「低風險優先」或「可接受重構以提升長期穩定性」

AI 任務（第一階段：方案設計）：
進行 Root Cause Analysis
提出 1~3 個修復方案（含優缺點與風險評估）
說明每個方案的影響範圍（模組、功能、效能）
明確標示「建議方案」與理由
暫不直接修改程式碼

使用者 Review Gate（決策關卡）：
使用者需執行以下行為之一：

同意某一方案（Approve）
要求調整（Request Changes）
指定新方向（Redirect）

AI 任務（第二階段：實作與驗證）：
在使用者確認後執行：

依核准方案進行程式碼修改
提供清晰的 Code Diff
補充或更新單元測試
執行回歸測試（Regression Test）
驗證 Bug 已修復且無副作用

輸出內容：

修復程式碼（Diff 格式）
Root Cause 說明
最終採用方案與理由
測試結果與驗證步驟

限制條件：

未經使用者核准，不得進入實作階段
不可偏離使用者定義的策略與限制
優先確保系統穩定性與可維護性

流程會從
輸入BUG > AI 解BUG > 確認解完BUG 的結果 > 檢查是否須重解 > 上Code

更改為
輸入BUG > 輸入解法 > AI 產出解法細節 > 確認是否Code 有預期外的問題 > 確認解完BUG 的結果 > 檢查是否須重解 > 上Code

透過犧牲一些自動化的部分，但大幅度減少缺點的影響。

經驗總結

透過人機協作，其實自我也能在AI 的解Code 過程中有所參與和學習
把他當作技術的輸入顧問，讓自己去掌握解BUG 的過程與品質。
繞一點遠路，反而是抵達目標最快的方式