「AI 不算營養、程式算營養」

「AI 不算營養、程式算營養」，這句話講起來簡單，卻是專案「不能妥協」的一條線。

「熱量」跟「份數」這種數字，一旦算錯，後面所有的飲食建議都會跟著歪掉——而生成式 AI 最大的弱點，就是同一個問題問兩次，答案可能不一樣，也就是可能會出現幻覺(hallucination）。如果讓 AI 自己去「算」一個人的 BMR／TDEE，或是算一份便當裡有多少份全穀雜糧，這種不確定性在營養建議上是不能接受的。

所以從一開始的設計，就把整個專案切成兩塊：

程式碼負責「一定要對」的事：
BMR、TDEE、三大營養素比例、六大類食物份數，全部用固定公式計算，甚至BMR加了一些臨床上常見的手法，適時使用”校正後體重(adjusted body weight)”來避免一些極端狀況，並且判斷的標準也都是用程式碼邏輯去篩選而非交給AI。

AI 負責「需要理解語意／需要生成內容」的事：
讀懂使用者打的自由文字（例如「早餐都超商、常常十一點吃消夜」）、依照已經算好的份數框架，生成一份貼近使用者生活習慣的菜單建議。這些才是 AI 真正擅長、程式碼反而做不到的事。

這條原則之後被驗證是對的決定。專案中期把真實的超商／連鎖店食物資料庫（近 2000 筆）接進菜單生成流程時，依然堅持：AI 只負責從候選清單裡「選」要用哪個食物，實際換算成六大類幾份，一律回頭用食物代換表的公式重新精確計算、覆蓋掉 AI 自己估的數字。過程中抓到不少「如果讓 AI 自己算，數字會悄悄跑掉」的真實案例——這些踩雷細節，會在後面講 Food DB 整合的文章裡分享。