技術 Day 28 | 前端 CI/CD：打破本機限制！Expo EAS 雲端打包與 OTA 更新

前言：前端的部署，比你想得更折磨人 昨天我們使用 GitHub Actions 搞定了後端的自動化部署。現在，讓要直行動裝置的打包與發佈。 但要先面對現實，**...

技術 Day 27 | 後端 CI/CD：用 GitHub Actions 自動部署 Cloud Run

前言 在 Day 12 時，我們手動輸入 gcloud run deploy 將 KAKERU 後端 API 推上雲端。隨著開發進入尾聲，頻繁的手動部署既費時又...

技術 Day 24 | 所以今天是幾月幾號？告別「第 X 週」，日曆對齊與打卡實戰

前言：AI 算得很開心，但跑者看得很痛苦 經過前幾天的努力，KAKERU 已經能一口氣吐出 24 週的龐大訓練計畫。但如果 UI 上只顯示：「第 13 週，週二...

技術 Day 22 | 繞過 API 授權地獄，用 Gemini 多模態看懂跑錶與跑步機螢幕

前言：為什麼要用「視覺」解決痛點？ 當跑者結束今天的訓練，最希望能把剛跑完的數據記錄下來。傳統運動 APP 為了取得使用者的里程與配速，必須去向 Garmin...

技術 Day 21 | AI 動態重算實戰：將狀態發送至雲端，智慧合併新課表並無縫刷新 UI

前言：當計畫遇上變化，展現 AI 教練的真正價值 昨天成功加入了「AI 教練診療室」，提供跑者回報「疲勞指數」與「具體狀況」的精美介面。但在真實的運動情境中，跑...

技術 Day 20 | 介面實作 (3)：打造課表診療室，實作疲勞度打卡與文字發問介面

前言：計畫永遠趕不上變化，靜態課表的死穴 昨天成功把 JSON 轉化為極具質感的課表 UI。看著 4 週訓練計畫，感覺跑者隨時都可以準備跑了。但在實際狀況裡，備...

技術 Day 19 | 介面實作 (2)：告別生硬 JSON！拆解 UI 元件並完美綁定 AI 課表資料

前言：骨架有了，現在為它注入靈魂 在 Day 17 時，我們已經勾勒出了課表頁面的基本輪廓；昨天 (Day 18) 更是透過 Zustand 成功打造了 APP...

技術 Day 18 | 打造教練的海馬迴：Zustand 與 Persist 持久化實戰

前言：資料拿到了，但 APP 重開就失憶？ 在昨天的實作中，我們成功地將「個人檔案頁」與「課表頁」的職責分離，並順利透過 Cloud Run 拿到了 AI 為東...

技術 Day 16 | 介面實作 (1)：打造跑者基本資料的專屬表單，為 AI 準備精準 Context

前言：AI 教練也需要認識你 在 Day 9 設計後端 Prompt 範本時，我們預留了 {{TARGET_RACE}}（目標賽事）與 {{CURRENT_LE...

技術 Day 15 | 導覽列與路由：實作首頁、課表頁、個人頁面的絲滑切換

前言：單頁 APP 是不夠的，我們需要導覽列！ 昨天我們完成了「KAKERU」的第一個首頁畫面。有讀者一定有發現，畫面底部出現了一個非常有質感的黑色懸浮導覽列！...

技術 Day 14 | React Native 核心觀念轉換：從 Web 元件思維走向跨平台 Mobile APP

前言：為什麼選擇 React Native？ 經過前面 13 天的奮戰，我們位於 GCP 雲端的 AI 大腦已經準備就緒，不僅能精準吐出 JSON 格式的馬拉松...

技術 Day 13 | 上線驗證與流量防護：Cloud Run 擴展限制與 API Rate Limiting 實戰

前言：別讓自動擴展變成破產機器：實作 Cloud Run 雙重防護 Cloud Run 的強大之處在於「無極限自動擴展 (Autoscaling)」，但若了解的...

技術 Day 11 | 容器化實戰：撰寫 Dockerfile，將 Spring Boot 應用程式輕量打包

前言：告別「在我的電腦上明明可以跑」 經過前 10 天的奮戰，AI 教練 KAKERU 的 API 已經具備了邏輯、記憶力與防禦機制。本地端開發也算告一段落！...