過去三週，我們從零開始打造了《喵語日誌》的完整應用。
第一週完成了貓咪介面、情緒分析與成就徽章牆的靜態原型；第二週接入 Gemini 多模態 AI，讓貓咪能理解文字與圖片；第三週則完成 Firebase 匿名驗證、Firestore 雲端持久化、onSnapshot 即時同步、動態情緒日曆與折線圖，以及遊戲化成就系統。
今天暫緩開發新功能，而是以全鏈路整合測試為核心，從頭檢視整套應用程式在真實操作下的流暢度，盤點目前的系統架構，並總結第三週的開發與除錯經驗。
回顧《喵語日誌》目前的完整架構，前端與雲端服務之間已經建立起即時協同的資料流。
+---------------------------------------------------------------+
| 前端 React 使用者介面 |
| [喵喵對話 Chat] [情緒分析 MoodChart] [成就徽章 Awards] |
+------------------------------+--------------------------------+
| (1. 傳送文字與圖片 Base64)
v
+---------------------------------------------------------------+
| gemini-3-flash-preview |
| 多模態 Prompt 解析 -> 產生心情回覆 + JSON 標籤分析 |
+------------------------------+--------------------------------+
| (2. 結構化資料寫入)
v
+---------------------------------------------------------------+
| Firebase 雲端後端服務 |
| - Firebase Auth: 匿名身分驗證 (取得專屬 UID) |
| - Cloud Firestore: users/{uid}/diaries 子集合 |
+------------------------------+--------------------------------+
| (3. onSnapshot 即時監聽廣播)
v
+---------------------------------------------------------------+
| App.tsx 狀態中樞 |
| - diaries 狀態更新 -> 傳入 Chart/Calendar 繪製圖表 |
| - calculateAchievements 演算法比對 -> 觸發 AchievementModal |
+------------------------------+--------------------------------+
三層架構說明：
使用者互動層（Presentation Layer）：由 React、Tailwind CSS 與 Lucide Icons 打造，涵蓋處理圖文輸入與對話展示的「喵喵對話」、渲染日曆與折線走勢的「情緒分析」，以及負責徽章展示與彈窗動效的「成就徽章」。
AI 與服務中介層（Service Layer）：由 geminiService.ts 負責結構化多模態分析與標籤解析，firebase.ts 封裝匿名登入、資料庫讀寫與 onSnapshot 即時監聽，並透過 achievements.ts 的 calculateAchievements 演算法計算成就進度。
雲端後端層（Cloud Services Layer）：結合 Google gemini-3-flash-preview 提供多模態理解能力，並搭配 Firebase Auth 進行匿名身分 UID 管理，以及 Cloud Firestore 負責 NoSQL 資料儲存與即時廣播。
這樣的分層架構讓前端介面、服務邏輯與雲端後端保持清楚的權責解耦，也為後續的擴充與維護奠定了穩固的基礎。
為了驗證系統在真實環境下的多模態識別與即時連動，我在深夜進行了一次完整的情境測試。
在「喵喵對話」中，我上傳了一張雨滴打在窗戶上的街景照片，選取「🙀 Rough」心情，並輸入：
我好難過...
送出後，前端先將圖片壓縮至 54.9 KB 送往 Gemini 進行分析。AI 成功辨識出照片中濕漉漉的窗戶雨滴與模糊燈光，並結合同理心產生極具畫面感與溫度的安撫回應：
▲ 貓咪細膩辨識雨景並給予暖心安撫；Console 清楚記錄資料壓縮、Firestore 寫入成功與 4 筆雲端日記的即時同步。
這段測試驗證了以下流程：
這段測試完整驗證了「使用者輸入圖文 → 前端壓縮 → Gemini 多模態分析 → 產生結構化回覆與標籤 → 寫入 Firestore → onSnapshot 推播最新日記」的單向資料流。
在 Firestore 寫入成功的瞬間，成就比對引擎重新計算所有成就狀態。
由於這筆日記是在凌晨 1 點多建立，系統偵測到使用者達成「夜貓族 🌙」的條件，立即觸發解鎖彈窗。
▲ 系統在資料庫寫入後即時運算，跳出「夜貓族 🌙」解鎖彈窗與確認按鈕。
這項測試確認了成就系統不僅在首次載入時運作，也能在使用者新增日記的當下即時反應。
點擊「收下徽章」後，我切換到各個分頁，確認整體系統的即時連動成果。
在情緒日曆中，本月紀錄天數上升至 4 天，22 號的日期格子正確標記出對應的 Rough 表情，點選後可完整展開當天的難過心情與日記文字：
▲ 情緒日曆即時同步第 4 筆紀錄，動態更新統計指標與當日卡片。
在情緒折線圖中，系統成功同步 4 筆雲端數據，即時重算平均分數為 3.5 / 5，並完整繪製出從 8/19 到 8/22 的真實情緒起伏曲線：
▲ 折線圖流暢繪製出 4 天來的心情起伏走勢。
在成就徽章館中，收集進度提升至 67%（4 / 6），「初來乍到」、「持之以恆」、「美食家」與剛解鎖的「夜貓族」皆呈現彩色點亮狀態：
▲ 成就徽章館動態更新，進度條推進至 67% 並點亮新解鎖的徽章卡片。
在整合全端資料流與即時監聽的過程中，我克服了幾個經典的前端與雲端協同難題。
在將 diaries 由 App.tsx 分發給 MoodChart 與 MoodCalendar 時，必須在子元件精準定義 diaries?: DiaryDocument[] 介面。
同時，在資料載入期間需要提供 isLoading 骨架與空狀態處理，避免 Chart.js 在無數據時發生渲染錯誤。
例如，當 diaries 為空陣列時，折線圖需要顯示「尚無資料」的提示，而不是嘗試繪製空數據。
onSnapshot 避免重複觸發與記憶體洩漏Firestore 的即時監聽若未妥善清理，容易在元件重新渲染時造成重複監聽，導致不必要的資源消耗與資料重複處理。
我在 useEffect 的清理函式中呼叫 unsubscribe()，確保元件卸載時取消監聽。
useEffect(() => {
if (!user) return;
const unsubscribe = subscribeUserDiaries(
user.uid,
(data) => {
setDiaries(data);
}
);
return () => unsubscribe();
}, [user]);
此外，我也利用 useRef 記錄前次已解鎖的成就清單，避免重新整理網頁時誤觸解鎖彈窗。
將成就判定抽離為純函式 calculateAchievements，讓成就系統與 UI 元件保持解耦。
這個函式只負責接收日記資料並回傳成就狀態，不直接操作 DOM 或修改 React State。
const achievements = calculateAchievements(diaries);
這樣的設計讓成就系統可以隨著日記筆數增加而靈活擴充，也方便未來新增更多成就條件。
走完一整條資料流，並看著所有元件在彈指之間即時連動，給人滿滿的成就感。
《喵語日誌》從最初的純前端切版、靜態 Mock Data，到現在串聯了 Gemini 智慧理解、Firebase 雲端同步與遊戲化反饋，已經成為一個真正具備實用意義的情緒陪伴應用。
每一次書寫不僅是情緒的抒發，更能在圖表與徽章中看見自己生活的真實軌跡。
這次實作也讓我更深刻體會到，前端工程師不只是畫面的製造者，更是資料流的設計者。
如何讓資料在不同層級之間順暢流動，如何避免重複請求與記憶體洩漏，如何在非同步環境中保持狀態一致，都是需要持續思考與實戰的問題。
第三週的圓滿總結，代表《喵語日誌》的核心骨架已完全確立。目前系統已經完整串接了前端介面、Gemini 多模態情緒分析、Firebase 匿名驗證、Firestore 雲端持久化、onSnapshot 即時同步、圖表動態渲染以及遊戲化成就系統。
明天我們將正式進入最後的衝刺階段——【第四階段：資安防護、系統部署與體驗優化】！
我們將從大型語言模型（LLM）的資安防護切入，設計穩固的系統指令以防禦提示詞注入與越獄攻擊，確保貓咪人設不會脫序，打造安全又安心的陪伴體驗！
明天見，喵～ 🐾
iThome鐵人賽
看影片追技術