# Problem Definition: AI Behavior Regression Testing

## Front Matter

```yaml
date: 2025-10-13T19:26:15+08:00
author: kent
git_commit: b38fd6945b09a1cde23982ff4f58c106d6035d33
branch: main
problem_id: ai-behavior-regression-testing
tags:
  [testing, ai-brain-node, regression, prompt-engineering, non-deterministic]
status: defined
method: socratic-inquiry-v4
```

## Problem Statement

**根本問題：如何建立一套機制來測試和量化 AI 的不確定性行為**

使用者需要驗證 `ai_brain_node`（基於 Claude Code SDK）在各種編譯錯誤情境下的修正能力，並能量化 prompt 改進效果。核心困難在於：

1. AI 行為不確定（同樣錯誤有時成功有時失敗）
2. 需要在真實專案結構上測試，但要避免污染開發環境
3. 缺乏明確的「測試通過」標準和 prompt 效能基準線

## Discovery Process

### 初始描述

> 我想要做測試，但是遇到了困難。我想要測試的是 ai_brain_node 的實際功能，不是 mock up。我先測試各種 build 失敗後，ai_brain_node 會如何處理。但是，ai_brain_node 底層是使用 claude code SDK，他在接收到 prompt 後，會自動針對特定的目錄底下的內容做處理，目前的內容會影響處理的方式跟結果，這部份我不知道如何測試。

### 關鍵洞察時刻

1. **Q7 突破**：問題不是「如何測試」，而是「測試什麼」
   - 從「無法預測 AI 修改內容」轉向「驗證 workflow 是否跑得通」

2. **Q10 轉折**：暴露真實需求
   - 揭露已接受 70% 成功率，有 retry 機制
   - 真正擔心的是「重構破壞現有能力」

3. **Q11 核心浮現**：環境污染問題
   - AI 需要修改真實專案 source code
   - 不知道如何處理測試後的清理

4. **Q16 重大轉折**：泛用性 vs 現實
   - 設計目標是「泛用韌體開發 agent」
   - 實際只用過「STM32 + Keil」

5. **Q19 關鍵證據**：不穩定性的實證
   - 「一個劇情，有時成功有時失敗」
   - 實際發生過「調整 prompt 後就失效」

6. **魔鬼代言人階段**：驗證嚴重性
   - 實例：AI 曾從網路亂抓不相容的 source code
   - 證實有控制變因的測試經驗
   - 確認被動防禦不足以解決問題

### 信心歷程

- Q1-Q6：探索表層問題（測試方法、預測 AI 行為）
- Q7-Q15：挖掘真實需求（重構信心、環境隔離）
- Q16-Q19：揭露核心矛盾（泛用設計 vs 單一實作、不確定性）
- Q20：信心檢查 → 8/10 分
- 魔鬼代言人挑戰：通過所有質疑，維持高信心

### 5 Whys 追蹤

1. **為什麼需要測試 ai_brain_node？**
   → 確保重構時不搞壞現有功能

2. **為什麼擔心重構會搞壞？**
   → 這是開發習慣，沒測試就不敢重構

3. **為什麼一定要自動化測試？**
   → 需要驗證 prompt 調整的效果

4. **為什麼需要驗證 prompt 效果？**
   → 實際發生過 prompt 調整後功能失效

5. **為什麼 prompt 會失效？**
   → AI 行為不確定，同樣案例有時成功有時失敗，需要基準線量化改進

### 魔鬼代言人挑戰記錄

**挑戰 1：反向假設測試**

- 質疑：是否過度追求測試覆蓋率？
- 反駁：實際需要驗證 prompt 調整效果，且需確保不同環境正常運作 ✅

**挑戰 2：證據質疑**

- 質疑：「比較好」的定義是實際測量還是推測？
- 反駁：目前案例簡單（語法修正），很容易觀察，實際發生過多次 prompt 調整導致失效 ✅

**挑戰 3：替代解釋**

- 質疑：是否有其他因素（案例單一、模型不穩定、環境不一致）？
- 反駁：有控制變因，同樣案例、簡單案例，只改 prompt 就有不同結果 ✅

**挑戰 4：影響測試**

- 質疑：問題嚴重程度如何？
- 反駁：後果可大可小，曾發生 AI 從網路亂抓不相容 source code 的嚴重案例 ✅

**挑戰 5：最簡方案**

- 質疑：有沒有更簡單的方案（prompt 約束、沙盒限制、人工抽查）？
- 反駁：被動防禦只能避免最壞情況，無法驗證 prompt 是否有效 ✅

## Real Requirement

### 真實需求（不是解決方案）

1. **回歸測試機制**
   - 確保重構或 prompt 調整不會破壞現有能力
   - 及早發現功能退化

2. **Performance Baseline**
   - 建立 prompt 效能的基準線（例如：舊版 65%，新版 72%）
   - 量化比較不同 prompt 版本

3. **安全網**
   - 及早發現 AI 危險行為（例如：亂下載檔案、修改錯誤檔案）
   - 避免污染開發環境

### 解決方案 vs 需求對照

| 使用者提到的「解決方案」 | 真實需求                     |
| ------------------------ | ---------------------------- |
| 「寫自動化測試」         | 建立回歸機制，驗證功能不退化 |
| 「預測 AI 會改什麼」     | 量化 AI 行為，建立效能基準   |
| 「準備多個測試專案」     | 在真實環境測試，避免污染     |
| 「100% 可靠的 AI」       | 接受 70% 成功率，但需可量化  |

## Success Criteria

### 可衡量的成功標準

1. **重複執行能力**
   - 能夠重複執行 N 個測試案例
   - 測試環境不會互相污染
   - 每個測試案例可獨立驗證

2. **量化結果**
   - 輸出格式：X/N 成功（例如：7/10）
   - 記錄每個案例的成功/失敗
   - 可視覺化趨勢（例如：prompt v1 vs v2）

3. **比較能力**
   - 能夠比較不同 prompt 版本
   - 有統計依據判斷改進/退化（例如：χ² test）
   - 建議最低樣本數：每個案例至少 10 次

4. **執行時間**
   - 單個測試案例 < 5 分鐘
   - 完整測試套件 < 1 小時
   - 可並行執行（如果可能）

5. **安全檢測**
   - 能檢測 AI 的危險行為（例如：網路下載、修改非目標檔案）
   - 測試失敗不會影響真實開發環境

## Context & Impact

### 影響範圍

- **直接影響**：FWAuto 的核心功能（ai_brain_node）
- **間接影響**：用戶專案的穩定性和開發效率
- **風險範圍**：STM32 + Keil 專案（目前），未來可能擴展到其他平台

### 頻率

- **Prompt 調整頻率**：開發階段頻繁（每週）
- **重構頻率**：中等（每季？）
- **新 SDK 支援**：低頻（每半年？）

### 嚴重程度

- **最佳情況**：AI 修正失敗，retry 機制兜底，延長開發時間
- **常見情況**：AI 修正方向錯誤，需人工介入
- **最壞情況**：AI 從網路下載不相容程式碼，污染開發環境

### 實際案例

- ✅ 簡單案例（function 名稱錯誤）：大多能修正
- ❌ Prompt 調整後失效：發生過多次
- ❌ 危險行為：AI 曾從網路亂抓不相容 source code

## Assumptions & Constraints

### 關鍵假設

1. **專案代表性**
   - 假設：一個代表性的 STM32 + Keil 專案足以覆蓋大部分測試需求
   - 驗證方式：已測試過 4-5 個專案，結構類似

2. **成功率基準**
   - 假設：70% 成功率是可接受的基準
   - 理由：有 retry 機制和人工介入

3. **真實環境測試**
   - 假設：需要在真實專案結構上測試（不能純 mock）
   - 理由：專案結構會影響 AI 行為

4. **環境還原**
   - 假設：測試環境需要能自動還原
   - 方案：git reset 或專案副本

### 技術限制

- **平台**：目前只支援 STM32 + Keil（Windows 環境）
- **AI 不確定性**：無法要求 100% 成功率
- **測試時間**：AI 推理需要時間，無法做到毫秒級測試
- **環境依賴**：需要實際的編譯器和 SDK

### 業務限制

- **開發階段**：FWAuto 仍在早期開發，架構可能變動
- **使用者規模**：目前主要是開發者自己使用
- **資源限制**：單人開發，測試框架不能太複雜

## Scope & Boundaries

### In Scope

**測試範圍**

- STM32 + Keil 的常見編譯錯誤
  - Function 名稱錯誤
  - 缺少 include
  - 型別錯誤
  - 變數未定義
  - 語法錯誤

**測試環境**

- 一個代表性專案（例如：跑馬燈實例）
- 多種錯誤類型（建議 10+ 個案例）

**驗證項目**

- AI 是否採取行動（有修改檔案）
- 修改後是否編譯成功
- 是否有危險行為

### Out of Scope（目前）

- 其他平台/SDK 的測試（ESP32、Nordic、Arduino...）
- 複雜的多檔案錯誤（例如：跨檔案依賴問題）
- Runtime 錯誤（只測編譯期）
- AI 程式碼品質評估（只要能編譯就好）
- 100% 成功率的要求

### Edge Cases

**需要處理**

- AI 危險行為（網路下載、修改無關檔案）
- AI 沒有任何動作（timeout 或拒絕修改）
- AI 修改後產生新的錯誤

**可以不處理**

- AI 修改的程式碼風格不一致
- AI 使用了非最佳解法
- 極端罕見的編譯錯誤

## Next Steps

### 建議的後續步驟

1. **設計測試框架架構**
   - 決定測試環境隔離策略（git 副本？Docker？）
   - 定義測試案例格式
   - 設計結果記錄方式

2. **準備測試專案和案例**
   - 選擇代表性專案
   - 收集 10+ 個常見編譯錯誤
   - 準備初始專案快照

3. **實作基礎測試流程**
   - 自動製造錯誤
   - 呼叫 ai_brain_node
   - 驗證結果
   - 還原環境

4. **建立效能基準線**
   - 每個案例跑 10+ 次
   - 記錄當前 prompt 的成功率
   - 作為未來比較基準

5. **整合到開發流程**
   - 決定何時執行測試（每次 commit？每週？）
   - 建立測試報告格式
   - 考慮 CI/CD 整合

## Reflection

### 信心程度

**目前信心：8/10**

已經清楚理解：

- 真實需求（回歸測試、效能基準、安全網）
- 實際限制（AI 不確定性、環境依賴）
- 成功標準（可重複、可量化、可比較）

### 開放問題

1. **測試環境隔離策略**
   - Git 副本 vs Docker 容器 vs 真實專案 + reset
   - 各方案的 trade-off 是什麼？

2. **統計顯著性**
   - 70% vs 72% 的差異，需要多少樣本才有意義？
   - 如何避免「假陽性」（只是運氣好）？

3. **測試案例覆蓋率**
   - 10 個案例夠嗎？需要多少才足夠？
   - 如何系統化收集真實世界的錯誤案例？

4. **長期維護**
   - 測試專案需要隨 FWAuto 更新嗎？
   - 如何確保測試本身不會過時？

5. **擴展性**
   - 未來支援其他 SDK 時，測試架構需要改多少？
   - 是否應該預留擴展點？

### 批判性思考建議

**需要進一步驗證的假設：**

1. **「一個專案就夠」的假設**
   - 建議：先用一個專案建立測試流程，收集數據後再評估是否需要更多專案

2. **「70% 成功率可接受」的假設**
   - 建議：記錄實際的 retry 次數和人工介入成本，驗證這個數字是否合理

3. **「簡單案例能代表真實世界」的假設**
   - 建議：逐步加入更複雜的案例，觀察成功率變化

**潛在陷阱：**

1. **過度追求完美測試**
   - 風險：花太多時間建立測試框架，忽略實際功能開發
   - 建議：從最小可行測試開始，逐步完善

2. **忽略 AI 本質**
   - 風險：期望 AI 行為像傳統軟體一樣可預測
   - 建議：接受不確定性，聚焦在「趨勢」而非「絕對值」

3. **測試環境與真實環境差異**
   - 風險：測試通過但真實使用時失敗
   - 建議：定期用真實專案驗證

---

## Metadata

- **診斷時間**：約 20 輪蘇格拉底對話
- **方法**：混合式蘇格拉底提問 v4.0
- **特點**：動態探索、持續挑戰、魔鬼代言人驗證
- **文件版本**：1.0
