如果你也是用 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 如何運作：
- 完成腳本修改或開發段落，呼叫
qa_auditor --script xxxx.py --level full - qa_sandbox_manager 建立隔離沙盒，注入環境變數，複製腳本與測試資料
- AI 執行 4D 測試：
- D1：執行腳本，確認無報錯
- D2：檢查暫存檔是否清理、狀態是否流轉
- D3：模擬隔日重跑、模擬 Syncthing 競態（透過背景行程模擬）
- D4：切換時區變數、模擬路徑不存在
- 混沌測試：注入破爛 JSON、過期檔案，觀察腳本是否崩潰或自癒
- 產生 QA_RECORD.md 與 .qa_status（PASS/FAIL + 原因）
- 若 FAIL，AI 提供修復指引；若 PASS，允許合併或部署
- 回歸測試沉澱：若發現新 bug，自動產生 pytest 腳本，存入並分類
這個流程現在已經整合到我的 CI 流程中，每次提交都會自動觸發對應等級的測試。
成果與反思：我終於可以不被 Telegram Bot 報警轟炸了
因為之前寫了一個環境健康檢查，讓 Bot 在有問題的時候自動通知我，結果好幾天早上醒來手機都被 Bot 的警告訊息轟炸。
這套系統上線後，我讓它自動去檢視目前三機上所有的工作排程，得到不錯的建議，我看了之後沒其他意見，只要按下執行就好～
最明顯的改變是：「隔日 Bug」消失了，環境穩定了。
更重要的是，讓我這個新手村中年大叔，對 AI 生成的程式碼有了一點點信心——因為我知道，在它被部署之前，已經被一個「破壞者」反覆折磨過 XD
但另外也有幾點反思：
- 複雜度需要持續管理：設定了定期清理過期回歸測試的機制，避免測試最後變成垃圾山。
- 劣根性永遠存在：即使有門禁，AI 或是我還是可能想偷偷繞過。所以我建置了 QA 分級，讓小修改能快速通過，降低繞過的誘因。
- 這點真的很妙，在還沒有用 Tailscale 之前，AI 為了想閃過 SSH 的限制，硬是自己打造了半套的秘密通道，讓 AI 配合 Bot 可以傳輸檔案和指令，雖然很聰明，但仔細想想其實真的滿恐怖的。
結語：給可能同樣受困於「隔日 Bug」的你
如果你也被小龍蝦或是 AI Agent 搞瘋，深受「當下沒問題，隔天就爆炸」所苦，我的建議是：
- 先盤點你最常遇到的錯誤類型（時間相關？併發？跨機？）
- 從一個維度開始建立測試（例如 D3 的時間推移）
- 用簡單的沙盒隔離（不需要複雜框架，Python + 環境變數就夠）
- 讓 AI 扮演「破壞者」，而不是只當建設者
- 逐步加入護欄，但永遠記得：夠用就好，不要過度工程
上一篇提到 AI 管理制度，原本以為有制度就可以順順的發展，但經歷了這兩週的痛苦，因為自己的功力太弱，才知道導入 QA 機制有多麽重要 XD 。
留言