這幾週陸續做出了不少模組：情境生成的 Prompt、FastAPI 後端、聊天介面、n8n 自動化流程、RAG 資料庫、ngrok 對外通道。每一個單獨測試的時候，看起來都沒問題。

但我心裡其實有點發毛：每個零件單獨能動，不代表接在一起還能動。 今天不學任何新東西，也不加任何新功能，目標只有一個：用一個真正的使用者會走的路徑，從頭到尾完整跑一次整個系統，把藏在接縫處的問題全部找出來。

測試方法：當一個完全不懂系統的使用者

測試前先給自己訂了一個規則：不能用「我知道內部怎麼運作」的方式去操作。 要假裝自己是第一次使用的人，只看畫面上有什麼就點什麼，這樣才找得出「只有開發者自己才知道要怎麼用」的盲點。

完整測試的路徑是：

輸入一段中文情境描述
選擇英文程度，產生情境設定
開始跟 AI 角色扮演對話，來回幾輪
按下結束對話
等待並查看自動產生的學習報告

同時刻意設計了幾組不同的測試情境，沿用 Day 14 的分類方法，涵蓋日常型、旅遊型、正式場合型，確保不是只在「好發揮的情境」上測試。

今天找出的問題，依照位置分類

跟 Day 14 一樣，今天也把問題整理成分類，而不是一個一個亂記。這次依照「問題出在系統的哪一層」來分：

Prompt 層的問題

對話中途 AI 跳出角色

角色扮演進行到第四、五輪時，AI 偶爾會突然變成英文老師，開始解釋文法。這個現象在 Day 12 設計角色規則時就有預期過，但實際長對話測試才浮現出來。處理方式是在 Prompt 裡強化「在對話過程中，不要跳出角色做教學解釋，修正與建議留到對話結束後」這條規則，並且把它移到靠近開頭的位置。

情境生成偶爾格式跑掉

Day 14 就記下來的老問題，今天又出現一次。雖然頻率很低，但如果真的發生，後面整條流程都會因為讀不到格式而卡住。

API 與前後端層的問題

等待時間過長，使用者以為壞掉了

這是今天最有感的問題。AI 回應需要幾秒鐘，但畫面上完全沒有任何提示，我自己測試的時候都忍不住懷疑「是不是沒送出去」，連續點了兩次送出。這對照 Day 19 學的「狀態」概念：前端需要一個「思考中」的狀態，在等待期間顯示提示並暫時鎖住送出按鈕。補上之後，使用體驗差很多。

後端遇到錯誤時，前端直接卡死

故意模擬 LLM 服務沒有回應的狀況，前端畫面就一直轉圈圈，沒有任何錯誤訊息。這剛好呼應 Day 15 想過的「呼叫 LLM 失敗要怎麼處理」，當時只記下來，今天才真正補上：後端捕捉錯誤後回傳明確的錯誤訊息，前端收到之後顯示「目前暫時無法回應，請稍後再試」。

自動化流程層的問題

n8n 在 ngrok 網址換了之後就失效

這個是 Day 28 預告過的狀況，今天親身體驗。重開 ngrok 之後，網址變了，前端裡寫死的 Webhook 網址就打不到了，結果「結束對話」按下去沒有任何反應，也沒有錯誤提示。解法是把網址抽成一個可以統一修改的設定值，而不是散落在程式碼各處。

對話太短時，報告內容空洞

Day 25 就記錄過的問題，今天用完整流程再次確認。只有一兩句話的對話，產出的報告幾乎沒有價值。今天的處理是在流程前端加一個判斷：如果對話句數太少，直接提示使用者「對話內容太少，無法產生報告」，而不是硬產出一份空洞的東西。

今天最大的收穫：接縫比零件更容易出事

回頭整理今天找到的問題，發現一個有趣的現象：真正嚴重的問題，大部分不是出在某個模組「本身寫錯了」，而是出在「兩個模組交接的地方」——前端不知道後端出錯、n8n 網址跟前端對不上、Prompt 的輸出格式跟下一步預期的格式不一致。

這個發現，其實從 Day 23、Day 25 就一再出現過：「節點與節點之間的資料格式要先講好」。今天是同一個道理放大到整個系統層級——越是系統整合的階段，越要把注意力放在「交接處」，而不是各個零件內部。

一個測試方法的心得

今天也有個小心得：測試的時候，我發現我會下意識避開自己知道會出錯的操作。 比如我知道輸入太短會出問題，所以測試時自然就輸入比較長的句子。後來刻意強迫自己去做「最容易出錯」的操作——輸入亂碼、連續快速點擊送出、中途關掉頁面，才又找出幾個原本沒發現的問題。