系統大腦與藍圖：從前端框架到雲端平台流程全展開

2026 iThome 鐵人賽

DAY 2

Build on Google AI

單鐵的人生如履薄冰！AI 教練 APP 30天開發旅程，你說能走到最後嗎？系列第 2 篇

18th鐵人賽

takuyatsai

2026-08-11 20:38:44

37 瀏覽

分享至

前言：沒有設計圖，怎麼蓋大樓？

歡迎來到鐵人賽 Day 2！昨天向大家說明了這個APP的誕生，也確立了用 AI 來拯救我們破碎課表的偉大目標。

但在真正實作之前，我們需要將需求確立清楚，才有辦法讓AI知道我們的需求跟限制是什麼，避免整個專案架構太過複雜、維護成本高。

所以，今天的任務就是畫出系統藍圖！這個架構並非靠本身一己之力，而是根據經驗人士的建議、AI的協作與一些個人的想法共同協作想出。

觀念解說 / 架構說明：為什麼是這幾套武器？

前端 (Mobile App) — React Native：
為了達到雙平台的目的(iOS/Android)而選擇，撰寫 React Native 可以讓我用一套 Code 同時產出 iOS 和 Android 版本，雖然對撰寫APP沒經驗的我是個痛點，但過去有使用過TypeScript的經驗，對於下班時間寶貴的我們來說，這是 CP 值最高的選擇。
後端 (Backend API) — Java：

為了不讓學習成本持續跌高，我選擇 Java，這也是過去比較常接觸到的語言，這語言強大的物件導向與豐富的生態系，非常適合來處理複雜的商業邏輯。
雲端運算 (Cloud Infra) — GCP
GCP我也是第一次使用，但平常經常接觸另一個雲端服務商 AWS(Amazon Web Service)，因此學習成本沒有像 React Native 來得這麼高，能夠運用他服務的概念來實際運用，讓我非常期待！預計把 Java 打包成 Container 丟上 Cloud Run，一個全託管、Serverless 且自動擴展的服務，不僅不用自己管機器，還能根據需求控制預算。
AI 大腦 — Gemini API：
負責接收來自 Java 後端整理好的「使用者狀態（例如：今天又加班沒跑完）」，並進行推理，吐出全新的訓練課表。
資料庫 (Database) — Firestore：
GCP 提供的 Serverless NoSQL 資料庫，有提供免費額度。主要能讓後端 Java 整合，用來存 JSON 格式等格式。
簡易架構圖如下：

動手實作 / 程式碼時間：定義前後端的交戰守則

在藍圖確定後，我們今天先不急著把所有環境架好，而是要先定義「邊界」。我們在 Java 後端會先開出一個 API 介面（Controller），這就是未來手機端要來溝通的唯一入口。如下面範例：

@RestController
@RequestMapping("/api/v1/training")
@RequiredArgsConstructor
public class TrainingPlanController {

    // 注入處理 AI 邏輯與資料庫的 Service
    private final GeminiCoachService coachService;

    @PostMapping("/adjust")
    public ResponseEntity<AdjustPlanResponse> adjustPlan(@RequestBody AdjustPlanRequest request) {
        
        // Controller 保持乾淨，只負責接收狀態，髒活累活全交給 Service
        AdjustPlanResponse newPlan = coachService.generateAdjustedPlan(request);
        
        return ResponseEntity.ok(newPlan);
    }
}

這段 Controller 的骨架，確立了我們整個資料流的入口：

關鍵屬性 1 (統一的資料接收點)：我們定義了一個明確的 POST 路由。未來手機端不管發生什麼事（例如今天加班沒跑完），只要把使用者的最新狀態打包成 JSON 往這裡送就好。
關鍵屬性 2 (職責分離)：注意到了嗎？這段 Code 裡面完全沒有 AI 提示詞（Prompt）或資料庫讀寫的蹤影。Controller 只負責「接客」，真正與 Gemini 溝通以及讀取 Firestore 的資料，我們會抽離到 Service 層面去處理，保持架構乾淨。

踩坑與避雷指南：千萬別讓前端直接跟 AI 聊天！

所謂的不讓前端直接跟AI聊天，不是指使用者在UI介面上不跟AI聊天，而是避免透過React Native開發的前端，直接呼叫Gemini API！！

為什麼還特地規劃成從後端呼叫Gemini API，而不是直接呼叫 Gemini API？！

資安核彈：你的 API Key 會直接跟著 App 被打包。有心人士只要稍微反編譯你的安裝檔，你的金鑰就曝露在外面了，接下來就是天價帳單等著你。
更新地獄：如果你把 Prompt 寫在 App 裡，哪天想微調 AI 教練的語氣，你還得重新打包 App 送交 App Store/Google Play 審核，超級痛苦。
正確做法：永遠讓前端保持「單純」，它只負責顯示畫面。所有的運算、Prompt 組合、金鑰管理，全部交給我們的 Java 後端來處理跟串接！