SafeBite：為糖尿病與高風險族群量身打造的三層式 AI 飲食助理

🔗 活動專屬專案 ： 本專案係為 APAC GenAI Academy — Meet the Builders 活動特別開發。我們期望透過 Generative AI 的力量，將複雜的臨床衛教與即時外食場景相結合，為血糖管理需求者提供一個隨身、即時且可信賴的決策輔助工具。

🌟 一個無法忽視的餐桌痛點：『這個我可以吃嗎？』

每次帶媽媽出去吃飯，她都會在菜單前停下來，眼神中帶著一絲猶豫與焦慮，問同一個問題： 「這個我可以吃嗎？」

媽媽有第二型糖尿病。她非常注意自己的健康，按時吃藥、定期回診。但面對外食——在台灣，外食幾乎是日常——她真的不知道哪些食物對她安全。這並不是因為她不夠努力，而是因為資訊根本不在那裡。餐廳菜單不會標示碳水化合物或升糖指數 (GI) 。眼前的菜色和衛教手冊上那些完美的示意圖片長得完全不一樣。醫生口中叮嚀的 「少吃高糖食物、注意醣類代換」 ，在站在熱鬧的自助餐檯或精緻的餐館菜單前時，完全派不上用場。

令人遺憾的是，她在我完成這個 App 之前離開了。但那個問題留了下來，沉甸甸地壓在我的心頭。

身為一名開發者，我常常在想：科技如果不能解決我們身邊最親近的人的痛苦，那它的意義何在？也許 Generative AI 能夠成為解答。我不希望其他家庭在餐桌上面臨同樣的無助。這就是開發 SafeBite 的起點：我們不只是想做一個科技玩具，而是想為所有面臨血糖管理難題的人，在餐桌旁提供一個可以信賴的聲音。

📋 目錄

• 一、 這個問題比我的家庭更大：血糖管理的社會挑戰
• 二、 介紹 SafeBite：血糖管理者的隨身 AI 助理
• 三、 軟硬整合的核心：Flutter iOS 原生 LiDAR 與 TrueDepth 深度估算
• 四、 Google AI 三層決策架構：速度、成本與安全的完美平衡
• 五、 基礎架構與技術棧全景
• 六、 專案開發里程碑與驗收標準 (Milestones)
• 七、 上架商店降風險與合規檢查清單
• 八、 專案風險登記表與緩解策略 (Risk Registry)
• 九、 Gen AI Academy 最短路徑快速開發建議
• 十、 關於估算誤差的真誠面對：從精準計算機到決策輔助工具
• 十一、 結論與未來展望

一、 這個問題比我的家庭更大：血糖管理的社會挑戰

在台灣，血糖管理並不是少數人的問題，而是一個龐大的社會挑戰：

1. 糖尿病患者群體龐大 ： 台灣有超過 230 萬名 糖尿病患者，大約每 10 個成人中就有 1 人深受其擾。
2. 龐大的前期高風險族群 ： 根據國民營養健康狀況變遷調查，台灣約有 600 萬人 處於糖尿病前期（Prediabetes）。這群人的血糖已經偏高、胰島素敏感度開始下降，雖然還沒有正式確診，但若不在此時進行飲食干預，極有可能在數年內演變為第二型糖尿病。

這群人最迫切的需要，是在「做決定」的那一刻獲得指引。現有的市場解決方案通常分為兩大類，但都存在顯著的痛點：

• 傳統營養追蹤 App ： 需要用戶手動搜尋並輸入食材、重量與烹調方式。這非常麻煩，且外食的複雜度極高，用戶根本無法得知餐廳使用了多少油、鹽與糖。大多數用戶在堅持幾週後就因為繁瑣的流程而宣告放棄。
• 診所發放的紙本衛教手冊 ： 雖然資訊正確，但通常是靜態的原則性指引（如：一份主食等於四分之一碗飯）。當用戶面對精緻的餐廳菜單或複合式料理時，很難將手冊上的知識轉化為眼前的點餐決策。

這兩種方式都無法在用戶「做決定的那一刻」派上用場。 SafeBite 的核心使命，就是填補這段從「衛教知識」到「餐桌決策」的鴻溝。

二、 介紹 SafeBite：血糖管理者的隨身 AI 助理

SafeBite 是一款專門為血糖管理需求者設計的 AI 外食助理。它是一款以 Flutter 打造的 iOS 原生應用程式 。我們之所以選擇 Flutter 與 iOS 原生的結合，是為了解決飲食記錄中最困難的「份量估算」問題。透過 iOS 裝置的硬體特性（LiDAR 偵測器與 TrueDepth 相機），我們能夠直接讀取深度資料，輔助 AI 進行體積估算，從而大幅提升碳水化合物的估算精度。

🌟 SafeBite 的核心運作流程

個人化設定 ➔ 拍照記錄飲食 ➔ 即時菜單分析 ➔ 每日與每週總結

1. 個人化設定

當用戶首次啟動 SafeBite 時，系統不會要求用戶手動輸入複雜的每日卡路里或巨量營養素目標，而是透過五個簡單且直覺的問題來建立用戶畫像：

• 年齡與性別
• 體重與身高
• 目前健康狀況（已確診第二型糖尿病、糖尿病前期、或高風險族群）
• 目前的用藥或胰島素使用狀況
• 每日身體活動量

系統後端會自動根據醫學指南計算出個人化的 每日醣量額度（以公克為單位） 。針對已確診患者與前期高風險族群，系統會給予不同的安全範圍與警示閾值，既確保患者的安全，又給予前期族群適度的彈性。

2. 拍照記錄飲食

用戶在用餐前，不需逐一拆解盤中的食材，只需按下快門拍照。 SafeBite 就會自動辨識食物種類、估算碳水化合物含量，並即時從當天的剩餘醣量額度中扣除。在配備 LiDAR / TrueDepth 的裝置上，App 會透過平台通道（Platform Channel）擷取深度資料，藉此計算盤中食物的實際物理體積，防止 AI 因為「近大遠小」的透視誤差而做出錯誤判斷。

3. 即時菜單分析（核心功能）

當用戶在餐廳點餐時，只需將相機對準菜單拍下一張照片。 SafeBite 就會啟動其核心 AI 引擎：

1. 結構化菜單 ： 自動辨識並提取菜單上所有的可選品項與價格。
2. 對照當日額度 ： 檢索用戶今日已攝取的醣量與剩下的額度。
3. 產出具體決策指引 ： AI 會給出清晰、個人化且可執行的點餐組合建議。

例如，當一位剩餘醣量額度為 48g 的糖尿病患者在小吃店點餐時， SafeBite 的建議不是「請選擇低 GI 食物」，而是：

💡 SafeBite 建議 ： 「建議點『清蒸魚套餐』。白飯請只吃一半（約 30g 碳水化合物），燙青菜可全吃，但請店家不要淋肉燥。請避免點『玉米濃湯』，因為勾芡含有大量隱藏澱粉，會讓您的血糖超出今日額度。」

這種具體到「吃多少、怎麼改、避開什麼」的指引，才是患者在餐桌上真正需要的支援。

4. 每日與每週總結

SafeBite 不鼓勵用戶時刻處於精準追蹤的焦慮中。每天晚餐後或晚上 10 點，App 會推播一份極簡的當日總結，告訴用戶今日的控制成效，並給予一句明天的飲食建議。每週日，系統會生成一份週報，呈現七天內的血糖負荷趨勢，方便用戶在回診時向醫師或營養師展示。

三、 軟硬整合的核心：Flutter iOS 原生 LiDAR 與 TrueDepth 深度估算

在開發飲食管理應用時，業界遇到的最大瓶頸是 「單張平面照片無法提供尺度資訊」 。同樣是一盤義大利麵，拍出來的照片在畫面上可能是一樣大，但實際上可能是 8 吋的小盤子，也可能是 12 吋的大分量。如果 AI 僅依據平面視覺進行分析，醣量估算的誤差可能高達 50% 以上。

為了解決這個物理局限性， SafeBite 採用了 Flutter 軟硬整合架構 。我們在 iOS 平台上透過 ARKit 與 SceneKit 擷取點雲（Point Cloud）資料與深度圖（Depth Map）：

[Flutter Frontend] ➔ Platform Channel ➔ [Swift / ARKit iOS Native] ➔ 取得 LiDAR 3D 深度點雲 ➔ 計算食物實際體積

🛠️ 實作細節與 Platform Channel 橋接

我們利用 Flutter 的 MethodChannel 與 EventChannel 將 Dart 代碼與原生的 Swift 代碼連接。當用戶啟動相機時，原生 Swift 端會開啟 ARKit 會話（ARSession），並監聽每一影格的深度資料：

1. LiDAR 點雲擷取 ： 在支援 LiDAR 的 iPhone 12 Pro 及後續機型上，我們透過 ARFrame.rawFeaturePoints 取得物體表面的 3D 空間坐標。
2. 深度圖對齊 ： 對於不支援 LiDAR 但具備 TrueDepth 相機（FaceID 模組）的裝置，我們利用前置 TrueDepth 相機在自拍食物時獲取深度圖；或者透過後置雙鏡頭的視差計算（AVDepthData）來推估食物到鏡頭的實際距離。
3. 網格邊界計算 ： 當用戶點擊畫面上的食物時，原生端會以點擊位置為中心進行三維空間的射線碰撞檢測（Raycasting），找出食物의 邊界框（Bounding Box），並計算其寬、高與深度，從而得出物體的體積估值（立方公分）。
4. 回傳 Flutter 端 ： 將計算出的物理體積與影像資料一同打包，傳回 Dart 端，再將其作為 Metadata 隨同圖片傳送給 Google Cloud Vertex AI 模型。

這套軟硬整合的機制，讓 SafeBite 擺脫了「純平面影像估算」的盲區，為 AI 提供了不可或缺的物理尺度參考。

四、 Google AI 三層決策架構：速度、成本與安全的完美平衡

在醫療與健康管理相關的應用中，我們面臨著雙重挑戰：一是 回應速度 ，用戶站在菜單前不可能等待 30 秒才獲得建議；二是 醫療安全 ，如果 AI 給出錯誤的飲食指引（例如將高升糖的食物誤判為安全），可能導致患者面臨急性高血糖的風險。

為此，我們設計了 三層 AI 決策架構（Three-Tiered AI Architecture） ，在速度、成本與安全性之間取得了完美的平衡。

🔍 三層架構的詳細解析

1. 第一層：即時辨識層 —— Gemini 3.1 Flash Lite

• 任務 ： 快速辨識影像中的食物品項（例如：一碗滷肉飯、一盤炒空心菜、一碗貢丸湯）或將菜單圖片轉譯為結構化文字。
• 回應時間 ： 1 至 2 秒 。
• 設計意圖 ： 用戶拍照後需要即時的反饋。 Gemini 3.1 Flash Lite 的極速推理能力，能在用戶複製間完成物件偵測，在 App 畫面上框選出食物並顯示標籤。這建立了系統的第一步信任——讓用戶知道 App 「看懂了」眼前的食物。

2. 第二層：醣量估算與建議層 —— Gemini 3.5 Flash

• 任務 ： 結合第一層的辨識結果、烹調方式（例如乾煎與勾芡的升糖差異）、以及 iOS 端回傳的 LiDAR 體積數據，估算碳水化合物總量，並比對用戶今日剩餘額度，生成具體的點餐與攝取建議。
• 回應時間 ： 3 至 5 秒 。
• 設計意圖 ： 這是日常運作的核心層。 Gemini 3.5 Flash 擁有出色的多模態理解能力，並且能處理我們輸入的結構化 Prompt（包含用戶的用藥歷史與剩餘醣量限制）。它能產出結構化（JSON）的資料，方便 Flutter 前端進行 UI 渲染。

3. 第三層：高風險條件驗算層 —— Gemini 3.1 Pro

• 任務 ： 進行臨床安全合理性驗算，確保輸出建議的絕對安全性。
• 觸發條件 ：
  • 第二層模型的輸出信心度（Confidence Score）低於 85% 時。
  • 食物種類屬於「高風險混和料理」或「隱藏升糖類別」（如：羹湯、砂鍋魚頭、照燒醬汁、太白粉勾芡料理）。
  • 用戶的健康狀況為已確診糖尿病，且今日剩餘額度已低於 15g。
• 設計意圖 ： 這一層並非每次點餐都會觸發，以有效控制 Vertex AI 的 API 呼叫成本。當觸發時， Gemini 3.1 Pro 會扮演「資深營養師」的角色，對第二層產出的建議進行嚴格的邏輯審查，例如： 「這道料理雖然含有蔬菜，但其醬汁含有高比例的精緻糖，且用戶目前正使用胰島素，第二層給予『可全食用』的建議是否會引發低血糖後的高血糖反彈？」 。如果發現風險， Gemini 3.1 Pro 會在建議渲染至用戶螢幕之前，直接對建議內容進行修正，確保患者的安全萬無一失。

五、 基礎架構與技術棧全景

SafeBite 的穩定運行依賴於 Google Cloud 與 Firebase 的緊密整合。以下是整個系統的基礎架構設計與元件功能表：

六、 專案開發里程碑與驗收標準 (Milestones)

在內部工程團隊中，我們將 SafeBite 的研發劃分為五個關鍵里程碑，每個里程碑都設有嚴格的驗收標準：

🏁 M0：環境與骨架建立

• 開發時程 ： 全職開發 2 至 3 天 / 兼職開發 1 週
• 主要任務 ：
  • 初始化 Flutter 專案與設定 iOS 基礎包。
  • 建立 Firebase 專案並配置 iOS 端的 GoogleService-Info.plist。
  • 整合 Firebase Auth（重點實作 Apple 登入，以滿足 App Store 對第三方登入的安全規範）。
  • 搭建 Firebase Firestore 基本資料結構（Onboarding 模型與 Daily Log 記錄架構）。
  • 設定 Vertex AI 連線，完成 Firebase AI Logic 的通道架設。
  • 建立 GitHub Actions CI/CD 自動化實機 TestFlight 部署流程。
• 驗收標準 ： 開發者能在實機上成功登入（含 Apple 登入）、能正常讀取與寫入 Firestore 測試資料、並能成功發送 Request 給 Gemini 且收到 Response。

🏁 M1：MVP / 核心功能 Demo（關鍵展示版本）

• 開發時程 ： 全職開發 3 至 4 週 / 兼職開發 6 至 8 週
• 主要任務 ：
  • 開發五題式 Onboarding 問卷，並將使用者輸入資料同步寫入 Firestore。
  • 後端根據問卷數值自動計算個人化的「每日醣量上限目標」，且確診糖尿病患者與前期高風險族群套用不同安全範圍。
  • 串接系統相機與二層 AI（Gemini 3.1 Flash Lite 第一時間提供品項框選；Gemini 3.5 Flash 提供醣量估算與具體飲食優化建議）。
  • 實作 Daily Log 的動態扣除與累加（支援任意餐數，打破傳統三餐設計）。
  • 建立每日最後一餐或晚上 10 點的「當日回顧」畫面。
• 驗收標準 ：
  • 完成 onboarding 後，Firestore 能寫入個人醣量目標。
  • 在實機拍一張真實的台灣便當（如排骨便當）， 10 秒內 必須在 App 介面上回傳包含醣量估算及具體調整的點餐建議。
  • 累計記錄多餐後，每日剩餘醣量計算完全無誤。
  • 在 20 張預先準備好的台式餐點（便當、麵食、自助餐）測試集上， 「安全/危險」方向分類正確率必須 ≥ 80% 。（在此階段，我們驗收的是決策方向的正確性，而非精確克數的物理對齊）。

🏁 M2：三層 AI 編排與進階功能

• 開發時程 ： 全職開發 1 至 1.5 週 / 兼職開發 2 至 3 週
• 主要任務 ：
  • 實作第三層 Gemini 3.1 Pro 條件式觸發引擎。
  • 確保在高風險（如勾芡、隱藏醬汁）或第二層信心值不足時， Gemini 3.1 Pro 能在建議渲染至畫面之前完成合理性驗算並進行就地修正。
  • 實作菜單多品項 OCR 與結構化分析（點餐前預防）。
  • 開發 Cloud Functions 週報生成器，產出七天的趨勢圖。
  • 整合 Cloud Functions 與 Firebase Cloud Messaging (FCM) 以處理每日定時推播。
• 驗收標準 ：
  • 正常、成分單純的餐點絕不觸發第三層；故意輸入勾芡（羹湯）、糖醬類（照燒）食物時，必須觸發第三層臨床驗算，且修正後的建議需在顯示前完成。
  • 第三層 AI 的觸發率需控制在 < 30% ，確保大流量下的 API 成本可控。
  • 晚上 10 點或用戶標記當日最後一餐後，能準時收到 FCM 總結推播。

🏁 M3：深度感測整合（LiDAR / TrueDepth）

• 開發時程 ： 全職開發 2 至 3 週 / 兼職開發 4 至 6 週
• 設計建議 ： 強烈建議延後至 v1.5 版本 。
• 主要任務 ：
  • 使用 Flutter Platform Channel 與 iOS ARKit 原生 API 對接。
  • 在相機啟動時捕獲點雲特徵與深度視差資料。
  • 透過原生演算法估算物體的物理體積。
  • 將體積數據融入 prompt 作為 Gemini 3.5 Flash 估算份量時的輔助引導。
• 驗收標準 ： 在配備 LiDAR 的裝置上，相同餐點在「開啟深度估算」與「關閉深度估算」兩種情境下，份量估算的克數誤差應有可量測的顯著改善。
• 延後理由 ： 這是整合難度最高、調研時間最不確定的模組，且其準確度紅利需要大量本土餐點實測才能確定是否划算。

🏁 M4：產品正式化與 App Store 上架準備

• 開發時程 ： 全職開發 3 至 5 週 / 兼職開發 6 至 10 週
• 主要任務 ：
  • 處理網路中斷時的離線暫存與排隊處理機制。
  • 編寫詳盡的隱私政策，特別針對用戶上傳的相片與健康生理參數進行說明。
  • 實作符合 App Store 規範的「App 內帳號刪除與資料清除」流程。
  • 於 UI 介面上提供清晰可見的「醫療免責聲明」與「本軟體不具診斷或預防醫學用途，若有身體不適請諮詢醫師」的常駐入口。
  • 填寫 App Store 上的 Privacy Nutrition Labels。
  • 收集上百筆真實的台式自助餐與便當影像，進行高強度的邊界測試與提示詞優化。
• 驗收標準 ： 通過上架檢查清單的所有技術合規與法規項目，取得 TestFlight Beta 與 App Store 正式審查的批准。

🏁 M5：個人化記憶與 AI Agentic Analysis (v2 目標)

• 開發時程 ： 全職開發 3 至 5 週 / 兼職開發 6 至 10 週
• 主要任務 ：
  • 長記憶儲存 ： 整合 Vertex AI Agent Engine Memory Bank (GA) 與 Sessions 機制，使用 Google 官方 ADK 進行記憶的動態讀寫。在第二層 AI 給予建議前，依據使用者當前 Scope 檢索其歷史飲食偏好、過往餐後血糖波動反應以及近期用藥變化。
  • 縱向數據預測 ： 使用 Cloud Functions 將用戶的每日飲食日誌持續串流（Streaming）至 Google Cloud BigQuery，並利用 BigQuery ML 中的 AUTO_ARIMA 時間序列預測演算法，在每週報表中生成「下週可能失控的時段」預警。
  • 相似影像檢索 ： 當用戶面臨無法決策的餐點時，利用 Vector Search 2.0 (GA) 在毫秒級時間內搜尋出雲端數據庫中最相似的過往用餐影像與其餐後血糖反應。
  • CGM 數據閉環 ： 串接連續血糖監測 (CGM) 設備的 API，將真實的血糖生理反饋即時注入 Memory Bank，完成 AI 建議與生理反應的自動化校正迴圈。
• 驗收標準 ：
  • 跨多個 Session 後，系統仍能記住使用者的細節（如：該用戶不喜歡吃某種調味料，或該用戶對某類精緻澱粉的升糖反應劇烈），並主動在點餐建議中體現。
  • 當用戶執行帳號刪除時，其 Memory Bank 內的記憶碎片與 BigQuery 內對應的個人資料必須在背景被徹底且可審核地清除。

七、 上架商店降風險與合規檢查清單

將健康與飲食相關的 AI 應用送審 App Store，或者在法規嚴格的地區上線時，團隊必須落實以下防線以避免被下架或陷入 TFDA 醫療器材監管糾紛：

1. 審查策略層面

• 優先採用 TestFlight 走外部分發 ： 在 Demo 與大賽展示階段，直接透過 TestFlight 提供外部測試（最多可發布給 10,000 名使用者）。 TestFlight 的 Beta App Review 審查力度遠比正式 Store 寬鬆，能有效排除正式上架時繁雜的審查阻礙，確保展示活動的順利進行。

2. 商店文案與字彙去醫療化（極度重要）

• 禁止出現醫療宣稱字眼 ： 商店描述、宣傳圖文字、甚至 App 內的導覽語句中， 絕對禁止 出現「診斷」「治療」「降低血糖」「預防糖尿病」等具備醫療效果或宣防暗示的字彙。
• 正確的定位語氣 ： 應將 App 定位為「個人化飲食覺察的生活隨身助理」或「日常飲食日記與醣類估算輔助軟體」。
• 免責聲明入口 ： 在 Onboarding 的首頁、每次給予點餐建議的底部、以及設定頁面中，均須常駐明顯的「本軟體內容僅供健康意識提升與飲食參考，不能取代專業醫師、營養師之診斷與處方」免責聲明。

3. 技術合規死角

• App 內帳號刪除（Delete Account） ： 這是近年 App Store 審查最常退件的重災區。 App 內必須提供一個簡單直接的按鈕，且該按鈕觸發後，必須以非同步任務徹底刪除 Firestore、Firebase Auth 以及 Memory Bank 中的所有個人關聯資料，而不能僅僅是「停用帳號」。
• 強制提供 Apple 登入 ： 如果 App 內提供了第三方登入（例如 Google 帳號登入），則依據 Apple Guideline 4.8， 必須 同時且以同等明顯的 UI 提供「Sign in with Apple」按鈕。
• Privacy Nutrition Labels 與隱私政策 ： 必須提供一份公開的隱私權政策 URL，並在 Labels 中據實勾選收集「健康與健身」資料以及「多媒體照片」資料，並向使用者說明這些資料僅用於當次 AI 運算，無廣告追蹤用途。

4. 醫療器材軟體 (SaMD) 認定界線 (法規風險)

• 根據台灣衛生福利部食品藥物管理署 (TFDA) 的醫療器材認定指南，如果軟體「主動收集生理數據並提供具備處方、診斷、或用藥劑量指導（如：根據血糖值計算 insulin 施打劑量）的建議」，將會被認定為醫療器材軟體 (SaMD) ，必須取得醫療器材許可證才能上架。
• SafeBite 藉由 「僅針對食材給予替代性建議（如飯吃一半）、不干預用藥、不進行臨床診斷」 的非醫學性設計，成功站在「非醫療器材」的安全地帶，大幅降低了法規處罰風險。

八、 專案風險登記表與緩解策略 (Risk Registry)

我們在專案初期梳理了核心技術與運營風險，並制定了對應的緩解方案：

九、 Gen AI Academy 最短路徑快速開發建議

如果您是為了在大賽或 Demo 日（例如此次的 Meet the Builders 展示）中快速呈現一個高完成度、能說服評審且能在實機上完美運作的專案，我們強烈建議採用以下 「快軌開發路徑（Fast-Track Path）」 ：

[環境骨架 M0] ➔ [核心 MVP M1 (無 LiDAR)] ➔ [三層架構核心 M2 (條件觸發與 FCM)] ➔ [TestFlight 實機分發]

1. 擱置 M3 LiDAR 深度感測 ： 將 LiDAR 點雲體積計算在簡報與文章中列為「下一步規劃（Future Work）」或「v1.5 願景」。在 MVP 階段，份量部分改用畫面上提醒使用者「請確保食物旁有標準餐具作為視覺對比」來替代。這能立刻為您省下 2 至 3 週的 iOS 原生硬體調試時間。
2. 免除 Store 正式審查阻礙 ： 完全不要送審 App Store！ 專案一律透過 TestFlight 進行發布。這能讓評審與測試人員在幾分鐘內透過連結下載實機 App，直接繞過 Apple 複雜的 SaMD 醫療審查和 Guideline 退件地獄。
3. 專注於三層架構與推播的演示 ： 將精力集中在「拍下高升糖羹湯時，能看見 App 在背景呼叫 Gemini 3.1 Pro 進行安全覆核並就地修正建議」的展示。這個軟體層面的 AI 智慧編排比硬體 LiDAR 更能展現 Generative AI 的核心價值。

這條快軌路徑能讓您在 全職約 4 至 6 週、兼職約 8 至 10 週 的時間內，建構出一個兼具故事性、工程深度且能實機操作的 SafeBite 展示版本。

十、 關於估算誤差的真誠面對：從精準計算機到決策輔助工具

身為開發者，在將 AI 應用於健康照護領域時，我們必須保持極度的誠實與謙遜。我們必須承認一個事實： 「僅憑影像與深度感測，是無法做到 100% 精準的營養素計算的」 。

在實際的開發與測試過程中，我們發現了許多物理局限：

• 隱藏的調味料 ： AI 可以辨識出這是一盤清炒高麗菜，但它無法得知廚師在炒菜時是加了植物油，還是加了豬油與砂糖。
• 混和食物的內部結構 ： 面對一碗牛肉麵， AI 可以透過 LiDAR 計算出湯麵的表面積與高度，但無法確切知道湯碗下方盛裝了多少比例的麵條與牛腱肉。
• 透視盲區 ： 即使有深度感測，盤子後方被遮擋的食物依然無法被完全掃描。

如果我們將 SafeBite 定位為「精準的碳水化合物計數器」，我們將會給用戶帶來錯誤的安全感，甚至因為估算誤差而導致嚴重的後果。

🛡️ 定位的轉變：從「計數器」到「防撞護欄」

因此，我們在設計 SafeBite 的核心邏輯時，做出了關鍵的轉向： 我們將其定位為「飲食決策的防撞護欄 (Guardrail)」，而非精準的計量天平 。

1. 模糊化精準數字 ： 在 UI 上，我們不向用戶強調「這餐含有 52.4g 碳水化合物」，而是以色塊與分級（如：安全、適量、警戒）來呈現這頓飯對其血糖的潛在影響。
2. 聚焦於替代決策 ： 我們的 Prompt 設計將重點放在「如何優化」而非「如何記錄」。 AI 的目標是告訴用戶： 「這碗飯請吃一半，把炸雞排的外皮剝掉，你就能安全地享受這餐。」 這種定性大於定量的指引，對於外食族而言，不僅更容易執行，也大幅降低了因為 AI 估算誤差帶來的風險。
3. 安全邊際設計 (Safety Margin) ： 在計算剩餘額度時，我們的後端模型會主動保留 10% 的安全邊際。例如，如果用戶的實際剩餘額度是 50g，我們在 AI 推理時會將其視為 45g 來進行點餐建議，藉此容納視覺估算可能產生的物理誤差。

我們相信，這才是負責任的 AI 醫療輔助應用該有的設計態度。 AI 不完美，但透過合理的產品設計與架構防線，不完美的技術依然能提供極具價值的現實幫助。

十一、 結論與未來展望

SafeBite 的誕生，是為了回應一個極其個人卻又無比普遍的餐桌痛點。透過將 Flutter iOS 原生的硬體能力與 Google Cloud 先進的多模態 AI（Gemini 系列模型）相結合，我們向大家證明了： Generative AI 不僅僅能用來寫 email 或生成圖片，它更能走入日常生活，成為慢性病患者在餐桌旁最溫暖、最即時的依靠。

本專案在 APAC GenAI Academy — Meet the Builders 的舞台上展示，我們希望這只是一個起點。展望未來，我們計畫朝以下幾個方向繼續努力：

• 擴展慢性病支援 ： 將模型擴充至腎臟病（追蹤鉀、磷、鈉攝取）、高血壓（鈉離子控制）與痛風（嘌呤限制）的飲食管理。
• 在地化知識庫強化 ： 針對台灣本地小吃（如：黑白切、甜不辣、滷味）與亞洲特有的醬汁調味，建立更精準的 RAG (檢索增強生成) 數據庫，提升第二層與第三層 AI 的評估精準度。
• 串接連續血糖監測 (CGM) ： 與 Dexcom 或 FreeStyle Libre 等 CGM 設備的 API 進行串接。這能讓 SafeBite 形成一個閉環控制系統——當 AI 給出建議後，能夠即時追蹤用戶兩小時後的實際血糖曲線，並將其作為回饋反饋給 AI 進行個人化 Prompt 優化，實現真正的「閉環飲食自適應」。
• Android 平台的跨越 ： 雖然 Android 陣營缺乏統一的 LiDAR 標準，但我們正計畫利用 ARCore 的 Depth API 進行演算法移植，讓非 iOS 的廣大用戶也能享受到深度感測輔助飲食管理的便利。

我們深信，未來的醫療健康管理將會是高度去中心化、個人化與即時化的。而 SafeBite 會持續努力，讓每一位糖尿病患者與高風險族群，在每次翻開菜單時，都能自信且安心地說出： 「這餐，我可以放心享用。」