我把產品 Wiki 餵給 LLM 讓它產測試案例，第一次失敗，第二次成功

我把產品 Wiki 餵給 LLM 讓它產測試案例，第一次失敗，第二次成功 「LLM 的輸出品質，上限是你給它的 context 品質。」這句話聽起來像廢話，但真的要讓 AI 輔助 QA 測試案例設計有效落地，這句話幾乎是一切的根本。把隨機撈出的 spec 貼給 LLM，你得到的是通用模板；把結構化的知識庫餵給它，你才可能得到有業務脈絡的測試案例。 目錄 1. 第一次嘗試：把 spec 貼給 ChatGPT 2. 問題不在 LLM，在 Wiki 的結構 3. Karpathy 的 LLM Wiki 概念改變了我的做法 4. 我的 QA Wiki 現在長什麼樣子 5. 實際展列測試案例的流程 6. 結尾 第一次嘗試 我們用 Confluence 維護產品文件。功能說明、API spec、歷史決策紀錄都在上面。 有一天我想試試看：把某個功能的 spec 複製貼上給 ChatGPT，叫它生成測試案例。 它給我的東西看起來完整，但有幾個問題： 它不知道這個功能和另外三個模組之間的依賴關係 它不知道這個功能過去出過哪些 bug，什麼情境是高風險的 它不知道我們團隊的測試風格：我們傾向 happy path + 邊界值，不寫太細的 UI 步驟 給它的 context 只有一頁 spec，它只能在那一頁的範圍內發揮。結果就是：通用的測試案例，不是我們產品的測試案例。 問題在哪裡 我當時以為問題是 LLM 不夠強。 後來我理解到，問題是 我給 LLM 的 context 結構太差 。 把一頁非結構化的 spec 貼給 LLM，它能做的就是把那頁 spec 換個格式重新整理一遍。它沒有能力推斷「這個功能跟 X 模組有依賴、歷史上曾在 Y 情境出 bug、我們團隊的測試標準是 Z」——因為你根本沒有給它這些。 LLM 的輸出品質，上限是你給它的 context 品質。 LLM Wiki 概念 今年 Andrej Karpathy 提出了一個叫 LLM Wiki 的概念，讓我重新思考這件事。 傳統 RAG 的做法：每次查詢時，從原始文件裡撈相關段落，實時丟給 LLM。 LLM Wiki 的做法不同： 先讓 LLM 把原始資料「編譯」成結構化的 wiki 頁面 ，之後的查詢都從這份已整理好的 wiki 讀，而不是每次重新解讀原始資料。 就像程式語言的 interpreter vs compiler： RAG 是 interpreter：每次執行都重新解讀原始碼 LLM Wiki 是 compiler：先編譯一次，之後執行都快 這個概念在 QA 知識管理上特別關鍵——ISTQB 的 AI 測試研究同樣指出，AI 輔助測試案例生成的品質，與輸入資料的結構化程度高度相關；缺乏結構的文件只會產出缺乏脈絡的案例。 對 QA 來說，這個概念的意思是： 不要每次產測試案例時才把 spec 貼給 LLM，而是維護一份 LLM 看得懂的 QA Wiki，讓它從那裡生成。 QA Wiki 結構 我現在維護的 QA Wiki 是 Obsidian，每個模組一個資料夾，結構固定： 每個 overview.md 的格式是固定的： risk areas.md 是最關鍵的一份： 展列測試案例的流程 有了這份結構化 Wiki，我展列測試案例的方式變成這樣： Step 1：給 LLM 指定的 Wiki 頁面 不是貼整個 Wiki，是指定哪幾個檔案： Step 2：LLM 輸出的結果 因為有了 risk areas.md 的歷史 bug 和高風險情境，它生成的案例會包含： 連結帳號首次種樹的硬幣入帳驗證（來自 BUG 2341） 計時中斷後重啟的邊界情境（來自 BUG 1892） 訂閱狀態改變後樹種解鎖同步（來自高風險清單） 這些是它上次（只給 spec）不會生成的。 Step 3：人工審閱 + 補充 LLM 的輸出我還是會過一遍： 刪掉重複或明顯不需要的案例 補上 LLM 不知道的隱性規則（通常是跟 RD 口頭確認過的東西） 標記哪些需要手動探索，哪些可以自動化 整個流程大概花 30 分鐘，比我自己從頭設計省了 60–70%。 但我中途踩了一個坑：案例亂列、不準確 這個流程不是一次就順的。 剛開始用的時候，我拿到的 LLM 輸出常常有兩個問題： 問題一：案例順序亂，沒有邏輯 LLM 生成的案例有時候像是隨機排列的，正常流程和邊界值混在一起，異常情境插在 happy path 中間。你要花很多時間在看「這個案例是什麼層級、跟上面的有沒有重複、這邊為什麼突然跳到錯誤情境」。 問題根源：我的 prompt 只說了「生成測試案例」，沒有指定分組方式。 問題二：預期結果不準確 LLM 對某些步驟的預期結果會寫得很模糊，例如「系統應該正確處理」、「顯示適當的錯誤訊息」。這不是測試案例，是廢話。或者更糟的是：它把預期結果寫反了，說「應該顯示種植成功並入帳硬幣」，但步驟描述的是一個沒有完成計時就中斷的流程。 問題根源：Wiki 裡的 test case format.md 沒有給夠多的範例，LLM 不知道「準確的預期結果」長什麼樣子。 我怎麼修正這兩個問題 修正問題一：在 prompt 裡要求分組結構 加了這段之後，輸出結構清晰很多，審閱時間從 30 分鐘降到 15 分鐘。 修正問題二：在 test case format.md 加具體範例 我在 Wiki 的格式規範裡加了一個「好的預期結果 vs 差的預期結果」的對比： 給 LLM 看具體範例之後，它產出的預期結果精準很多，因為它知道「準確」的標準是什麼。 這兩個修正加起來其實只是幾行 prompt 和幾行 Wiki 內容，但效果差很多。 核心發現是： LLM 不是不會寫好的測試案例，是它沒有標準可以參照 。你給它的格式規範越具體，它的輸出越符合你的需求。這跟教一個新人沒有太大差別——你說「寫好一點」，他不知道好是什麼樣子；你給他一個好例子，他下次就知道了。 讓 Wiki 自我維護 這個做法還有一個我很喜歡的延伸： 讓 LLM 幫你更新 Wiki 。 每次發現新的 bug，我的 checklist 是： 1. 把 bug 的詳細描述、觸發條件、影響存進 risk areas.md 2. 如果是新的隱性規則，更新 overview.md 的注意事項 3. 下次用這份 Wiki 產測試案例時，這個 bug 自然就會被覆蓋到 這不是自動化，是習慣。但這個習慣讓 Wiki 越來越有用，而不是越來越過時。 跟直接貼 spec 的差距 | | 直接貼 spec | 用 LLM Wiki | | | | | | 生成速度 | 快 | 快（前期建 Wiki 需要投資） | | 案例品質 | 通用，缺乏脈絡 | 包含歷史 bug 和高風險情境 | | 業務知識 | 沒有 | 有（你寫進 Wiki 的） | | 維護 | 每次重新貼 | Wiki 累積，越來越好用 | | 適合場景 | 全新功能初稿 | 有歷史的功能 regression | 結尾 第一次貼 spec 給 LLM 失敗之後，我曾經覺得「LLM 用在 QA 測試案例根本沒什麼用」。 後來發現問題不是 LLM，是我沒有把知識整理成 LLM 能用的格式。 LLM 很擅長從結構化的資料裡生成有組織的輸出。你給它結構化的 QA Wiki，它能給你有根據的測試案例。你給它一頁沒有脈絡的 spec，它只能給你通用的測試清單。 現在我維護 Wiki 的心態改了：這不只是給人看的文件，也是給 LLM 用的 context。這個心態讓我在寫每一個 risk areas.md 條目的時候，多想一句：「如果 LLM 讀到這個，它能生成正確的測試案例嗎？」 這個問題讓我的 Wiki 比以前好讀很多。 參考資料 AI Tester Certification — ISTQB World Quality Report 2024–25 — Capgemini Andrej Karpathy on LLM OS / LLM Wiki concepts — Lex Fridman Podcast transcript Obsidian Knowledge Base What is RAG? — Ministry of Testing