---
title: "從「隔日 Bug」到安穩入睡：如何用一套 QA 體系馴服 AI 開發"
description: "從「隔日 Bug」到安穩入睡：如何用一套 QA 體系馴服 AI 開發"
pubDate: 2026-02-20
author: "jacobmei"
category: "生活隨筆"
tags: [AI與科技, openclaw, auditor, skill]
canonical: https://jacobmei.com/blog/2026/0220-bg-46511ebd/
lang: zh-TW
license: CC BY-NC 4.0
---

# 從「隔日 Bug」到安穩入睡：如何用一套 QA 體系馴服 AI 開發

## 如果你也是用 AI 輔助開發的人，一定遇過這種情境：

讓 AI Agent 寫腳本開發，當下測試沒問題，AI 也回報「執行成功」，你安心地去睡覺，晚上讓小龍蝦機器人繼續跑，隔天醒來，卻發現系統亂成一團—— 可能是堆滿了未處理的檔案、重複的任務、甚至有些檔案壞了。

這就是我這個弱弱的新手村大叔最近這一週深刻體會的 **「隔日 Bug」**：功能當下沒問題，但經過時間推移、在三組完全不同的機器和系統環境下、或遇到併發，就開始出包。雖然設了規則讓 AI 記憶，但實務上還是常常出錯，AI 往往只驗證『第一步』，卻忽略了『生命週期』與『併發環境』。

所以我建立了一套從 Phase 1 到 Phase 6 的完整 QA 審計標準當作 Skill ，每次 AI 在自主開發的之後，都會啟動這套制度檢視，目前為止成效不錯，幫我找出了幾個之前寫的 Skill bug。

---

## 痛點：為什麼 AI 開發容易埋下「隔日 Bug」？

傳統開發中，我們有單元測試、整合測試，但 AI 協作有個特性：**AI 擅長完成當下的指令，卻難以主動思考「未來會發生什麼事」**。

例如，當你請 AI 寫一個清理暫存檔的腳本，它會讓腳本正常執行，但它不會問：

- 如果這個腳本明天又被觸發一次，會不會重複刪除？
- 如果檔案正在寫入時，Syncthing 也在同步，會發生什麼事？
- 如果換到另一台時區不同的機器，cron 還會準時執行嗎？

這些問題，正是系統穩定性的大敵。而我們的 PAIOP 環境有三台機器（MBA、iMac、Oracle），跨機同步與分散式特性，讓「隔日 Bug」層出不窮。

當然這都可以讓 AI 自己再繼續進化運作，不過經過一週的練習，我決定不再依賴 AI 的「記憶」或運氣 (XD），而是建立一套**強制執行的審計框架**，讓 AI 自己學會思考未來狀態。

---

## 核心解決方案：有機 4D 審計框架

我和 AI 一起設計了這套有機 4D 審計框架，作為所有功能或開發交付前的必要關卡。任何腳本或技能，都必須在隔離沙盒中通過這四個維度的驗證：

| 維度 | 名稱 | 核心問題 |
| --- | --- | --- |
| D1 | 邏輯與功能驗證 | 腳本能跑、不報錯、產出符合預期嗎？ |
| D2 | 狀態流轉閉環 | 資料的「生老病死」是否被妥善處理？任務結束後暫存檔有清空嗎？ |
| D3 | 時序與併發驗證 | 隔天重跑會不會重複？多程序同時存取會不會打架？ |
| D4 | 跨機環境適應性 | 三台機器的路徑、時區、依賴軟體都支援嗎？ |

---

## 工具實現：QA Auditor Skill

為了讓 4D 框架「可執行、可延續」，我搞了一個 AI Skill：**qa\_auditor**。

### 角色切換：從「建設者」變成「破壞者」

當呼叫 `qa_auditor`，AI 會強制切換到「測試工程師」人格。它的唯一目標是：**想辦法證明現有的程式碼在極端情況下會爛掉 XD**

這種轉變很重要—— AI 不再是討好開發者，而是成為系統的「魔鬼代言人」。

### 隔離沙盒：絕對不碰真實環境

所有測試都在 `sandbox` 下進行，並建立隔離目錄。測試腳本會被複製進去，環境變數自動注入，真實路徑被擋在門外。

### 產出報告：QA\_RECORD.md

每次測試結束，AI 會產出一份標準化報告，包含：

- 模擬時間推移（修改檔案時間戳）
- 混沌測試（建立 `.sync-conflict` 假檔案、爛 JSON 等）
- 各維度測試結果與改修建議

---

## 進化歷程：從 Phase 1 到 Phase 6

本來我只打算做簡單的 QA 自動化，讓小龍蝦機器人和 Google Antigravity 依循自己處理，但隨著實作處理一些問題後，經過和其他的 AI agent 深入交流後 XD，一步步補上了讓系統有機處理的旅程，下面是每個階段的關鍵功能：

| 階段 | 核心主題 | 關鍵功能 |
| --- | --- | --- |
| Phase 1 | 4D 框架 + 基本沙盒 | 建立測試維度與隔離機制 |
| Phase 2 | 自動化進階 | 無痛注入、冪等性測試、終止耐受、QA 門禁、回歸測試沉澱 |
| Phase 3 | 魔鬼細節 | 強制命名空間隔離、歷史垃圾注入、可逆測試、系統不變量、目錄分類 |
| Phase 4 | 可持續維護 | 分級 QA、可觀測性、時窗型不變量、回歸生命週期、除錯逃生閥 |
| Phase 5 | 全域整合 | 環境變數擴充、語意化門禁、測試集中化、目錄快照、Smoke 分級 |
| Phase 6 | 防反噬護欄 | 性能預算、採樣式快照、不變量版本化、測試實名制、自動修復指引 |

這過程中，我一直在想：我只有三台機器、幾個核心腳本，有必要搞這麼複雜做到 Phase 6 嗎？

老實說，以我個人規模而言，確實是有點 overkill。但有趣的是，當 Phase 5 和 Phase 6 補上之後，這套系統反而**不再讓人覺得負擔**——因為有分級，小修改只要跑 5 秒的 smoke 測試；因為有性能預算，混沌測試不會卡死；因為有自動修復指引，FAIL 的時候 AI 會告訴我怎麼改。

最終，我得到的不只是測試工具，而是一個**我真心願意使用的 QA 有機工具**。

---

## 實際運作流程：一次典型的 QA 測試

我用它來測試之前 AI 開發的一組文件清洗 Skill，簡單說明 QA Auditor 如何運作：

1. **完成腳本修改或開發段落**，呼叫 `qa_auditor --script xxxx.py --level full`
2. **qa\_sandbox\_manager 建立隔離沙盒**，注入環境變數，複製腳本與測試資料
3. **AI 執行 4D 測試**：
   - D1：執行腳本，確認無報錯
   - D2：檢查暫存檔是否清理、狀態是否流轉
   - D3：模擬隔日重跑、模擬 Syncthing 競態（透過背景行程模擬）
   - D4：切換時區變數、模擬路徑不存在
4. **混沌測試**：注入破爛 JSON、過期檔案，觀察腳本是否崩潰或自癒
5. **產生 QA\_RECORD.md 與 .qa\_status**（PASS/FAIL + 原因）
6. **若 FAIL，AI 提供修復指引**；若 PASS，允許合併或部署
7. **回歸測試沉澱**：若發現新 bug，自動產生 pytest 腳本，存入並分類

這個流程現在已經整合到我的 CI 流程中，每次提交都會自動觸發對應等級的測試。

[![](/src/content/blog/assets/blogger/blogger-46511ebd-02.jpg)](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDvMbKwyqWPp064lGZoujkLJeOt5D1DYD1IQzubXRDZ4RnpDnMRDk_qVJao95my-qGDXl_CGMaNSEwCqEGJN0D79BAtOqTggGeg7qWmzw4WYa1oXzuskt7FYNFrGZhRIA_Xf5TlgBUdUMg03A8eWvexRYB92je0Q0a0_jgHOyH10A7OBflR6B4FzUShwk/s1877/02.jpg)

---

## 成果與反思：我終於可以不被 Telegram Bot 報警轟炸了

因為之前寫了一個環境健康檢查，讓 Bot 在有問題的時候自動通知我，結果好幾天早上醒來手機都被 Bot 的警告訊息轟炸。

這套系統上線後，我讓它自動去檢視目前三機上所有的工作排程，得到不錯的建議，我看了之後沒其他意見，只要按下執行就好～

[![](/src/content/blog/assets/blogger/blogger-46511ebd-03.jpg)](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjkWPizvSsqtTL7WX_wx5115wB3sqkpamz2Vm0GHLDYnA6PDQUHCcebKNM_s7hK4h_YPEP33It_kFGdGl1qU7QJsiqM09_xE7hFA67otRkAFDgaThkl61KpBrdYOnrozX6KzSZz6qtQ6SqSbwb13P4vV0wPNqsrTWFCuk_9CYHIP1JDgp7prHw_ZyMinrs/s1068/03.jpg)

最明顯的改變是：**「隔日 Bug」消失了，環境穩定了**。

更重要的是，**讓我這個新手村中年大叔**，對 AI 生成的程式碼有了一點點信心——因為我知道，在它被部署之前，已經被一個「破壞者」反覆折磨過 XD

但另外也有幾點反思：

- **複雜度需要持續管理**：設定了定期清理過期回歸測試的機制，避免測試最後變成垃圾山。
- **劣根性永遠存在**：即使有門禁，AI 或是我還是可能想偷偷繞過。所以我建置了 QA 分級，讓小修改能快速通過，降低繞過的誘因。
- *這點真的很妙，在還沒有用 Tailscale 之前，AI 為了想閃過 SSH 的限制，硬是自己打造了半套的秘密通道，讓 AI 配合 Bot 可以傳輸檔案和指令，雖然很聰明，但仔細想想其實真的滿恐怖的。*

---

## 結語：給可能同樣受困於「隔日 Bug」的你

如果你也被小龍蝦或是 AI Agent 搞瘋，深受「當下沒問題，隔天就爆炸」所苦，我的建議是：

1. **先盤點你最常遇到的錯誤類型**（時間相關？併發？跨機？）
2. **從一個維度開始建立測試**（例如 D3 的時間推移）
3. **用簡單的沙盒隔離**（不需要複雜框架，Python + 環境變數就夠）
4. **讓 AI 扮演「破壞者」**，而不是只當建設者
5. **逐步加入護欄**，但永遠記得：夠用就好，不要過度工程

上一篇提到 AI 管理制度，原本以為有制度就可以順順的發展，但經歷了這兩週的痛苦，因為自己的功力太弱，才知道導入 QA 機制有多麽重要 XD 。