走到第 30 天，終於順利完賽了！
說實話，這 30 天的開發過程跟原本想像的不太一樣。原本規劃得非常完美，想著要把即時語音同傳、動態字典、記帳、提醒、周邊整理全部做到 100% 完美的實測展示。
但現實總是充滿意外，到了開發中後期，我的 OpenAI API Token 額度直接沒！ 因為Token不夠，後續幾天我無法開著直播進行長時間的端到端實測與數據採樣，只能聚焦在程式碼架構的實作、模組封裝、離線資料庫（Hive/SQLite）設計以及 Clean Architecture 的封裝上。
不過回頭來看，這反而是一次非常寶貴的體驗。它讓我深刻體會到，在開發 AI 應用時，「API 成本」與「資安/額度限制」本身就是軟體架構必須考量的一環。

30 天成果盤點：我們做了什麼？

雖然因為 API 額度限制讓後半段的測試比較偏向純程式碼實作，但整套「追星工具箱」的基礎架構已經完全搭建起來了：

1. Clean Architecture 架構定型：
   將專案劃分為 Data、Domain、Presentation 三層，讓翻譯、記帳、提醒、整理各個模組相互獨立，不會改了 A 壞了 B。

2. AI 即時同傳與動態 Prompt 注入邏輯：
   完成了 Whisper STT + GPT-4o-mini 的調用邏輯，並成功實作將本地 Hive 字典資料動態拼接進 System Prompt的機制（讓 LLM 認識偶像暱稱）。

3. 成本與效能防禦（雖然 Token 爆了，但程式寫好了:)）：
   RMS VAD靜音過濾演算法、Debouncer防連擊，以及全域 AppException 與退避重試機制。

4. 追星生活模組：
   完成了行程提醒（本地推播）、追星專屬記帳（SQLite/圖表）與小卡周邊整理的介面與邏輯。

坦白與反思：這 30 天學到的教訓
如果重新來一次，有幾個工程上的點我會處理得更好：
在開發 AI 專案時，應該一開始就寫好 MockTranslationService，用預設的 JSON 模擬 API 回傳，這樣就不會因為 API 額度用完而影響測試流程。

結語：完賽只是開始
雖然這次因為 API 額度的問題，後半段大部分都做得不是很好，但這 30 天累積下來的架構、Flutter 模組化經驗以及對AI串流應用的理解，都是非常扎實的收穫。
感謝這 30 天關注這個系列文章的大家！追星工具箱專案正式完賽，接下來有額度的時候，我會再把實測部分補齊！下個專案見！