之前寫了一篇 從「隔日 Bug」到安穩入睡:如何用一套 QA 體系馴服 AI 開發 ,提到可以在 AI Agent 或是小龍蝦環境中加上 QA Auditor Skill,這是一個特殊扮演角色。 當啟動此 Skill 時,AI 從「開發者」轉為「破壞者」與「審查員」。其唯一目的是在 不破壞真實環境的前提下 ,透過強制模擬異常與時間流逝,找出系統狀態與併發邏輯中的盲點(即「隔日 Bug」)。 自從有了這個,每次小龍蝦或是 Google Antigravity 開發時都會自動導入,我目前遇到開發上的錯誤幾乎沒有,有錯誤也會自動修補,省心不少。 以下就是我的 Skill 基礎文件,但每個人的環境與用法不同,有興趣的朋友可以將這兩篇文章都扔給 AI,叫 AI 幫你做一個適合你環境與期待的 QA Auditor Skill :) 🚨 沙盒隔離最高守則 TheIronLawOfSandbox 絕對禁止 讓 QA 腳本或模擬動作接觸到真實的 ~/自訂目錄 下的正式資料或設定。 所有測試 必須 在隔離的 自訂目錄/sandbox/ 目錄中進行。 強制規定 :使用 run <test_name> <script_path> 執行測試,確保隔離滴水不漏。 🎯 4D 審計框架 任何功能的變更或新技能的加入,在提交前必須由 AI 根據此框架自我質疑與測試: D1: 邏輯測試 腳本執行是否無報錯?預期產生的檔案/資料是否完備? D2: 狀態流轉閉環與可逆性 彈性不變量 :定義全域真理法則(例如:佇列必須在 N 個執行週期內清空),給予系統時間窗呼吸空間,避免死板驗證導致誤判。 真理版本化 :不變量應以版號管理,確保真理能隨著系統架構演進,避免過時驗證產生 False Positives。 冪等性 :強制 連續執行受測腳本兩次 ,確保第二次執行不會堆積冗餘資料或造成崩潰。 可逆測試 :執行腳本後,故意中斷重跑,檢驗暫存檔與污染狀態是否能被完美清除? D3: 時序與併發抗性 歷史垃圾注入 :必定使用注入過期 7 天的廢物檔案與殘損 JSON,測試...
如果你也是用 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 邏輯與功能驗證 腳本能跑、不報錯、產出符合預期嗎? ...