Day 1 的時候，手上只有一個想法：做一個能讓人輸入情境、跟 AI 練英文口說、還能自動產生學習報告的系統。那時候連 LLM 和 API 是什麼都還說不清楚，專題計畫書上列了一長串陌生的技術名詞，Dify、n8n、FastAPI、RAG、FAISS，每一個都只是名字而已。

今天是最後一天，不學新東西，也不加新功能。要做的是兩件事：把整個系統的樣子完整整理出來，並回頭看看這 30 天走過的路。

最終的系統架構

把這 30 天做出來的東西整理成一張完整的架構，從使用者操作到產出報告，整條流程是這樣：

使用者端

使用者在 React / Vue 做的聊天介面上，輸入一段中文情境描述、選擇英文程度。

核心流程

前端把資料送到 FastAPI 後端
後端呼叫 Dify 上設計好的情境生成 Workflow，LLM 根據 Day 13 設計的 Prompt，產出結構化的英文情境設定
使用者進入角色扮演，AI 依照角色設定與使用者來回對話
使用者按下「結束對話」，前端將完整對話打包成 JSON，送往 n8n 的 Webhook

自動化流程（n8n）

Webhook 觸發 Workflow
整理對話資料，標示每句話的說話者
第一次 LLM 呼叫：逐句分析使用者的英文，產出修正與更自然的說法
從 FAISS 向量資料庫檢索相關的英文片語與情境資料
第二次 LLM 呼叫：結合分析結果與檢索資料，歸納出單字、文法問題、實用片語
套用固定版型，產出個人化學習報告

輔助工具

Postman 負責 API 測試，ngrok 負責讓本機服務可以對外測試。

回頭看：這張圖跟 Day 1 的版本差在哪

把今天整理的架構，跟 Day 1 畫的簡化流程對照，發現幾個有趣的差異：

差異一：多了很多「接縫」處理

Day 1 的流程圖是一條直線，每個方塊之間用箭頭連起來就好。實際做完之後，箭頭上其實藏著大量細節：資料格式要對齊、錯誤要處理、等待狀態要顯示。Day 29 學到的那句話在這裡再一次應驗：越是整合，越要注意交接處。

差異二：LLM 呼叫的次數比想像中多

原本以為「呼叫 AI」就是一個步驟，實際上情境生成、角色扮演、逐句分析、歸納整理，各是一次獨立的 LLM 呼叫，每次的 Prompt 設計目標都不一樣。這驗證了 Day 12、Day 25 的心得：一個任務一個明確目標，穩定度比較高。

差異三：RAG 是最後才補上的，但價值不小

專題計畫書原本寫的是「若時間充足，再加入」，實際做完發現，它對「母語者自然表達」這個專題最重要的特色，貢獻其實滿大的。不過也同時體會到，RAG 的品質取決於資料庫本身，不是接上去就自動變好。