產業別
家庭 AI 系統
飲食 · 健康管理
飲食 · 健康管理
METHODOLOGY
先設計架構，不堆功能Design the system, not the features
一個家庭的「吃」是混亂的：近百道食譜散落、產出格式不一、三個家人需求各異、且各有疾病限制。我的第一步不是急著做漂亮 App，而是先把混亂結構化成一套會運作的資料架構。
混亂 → 結構
四個設計原則
01
資料存一處
Notion 作為唯一真相來源。所有食譜、成員、菜單資料只有一份、永久保存，不散落、不重複。
02
介面只是殼
介面壞了、換了都能重建，資料不會跟著消失。先確保資料實心，再談介面好不好看。
03
結構化優先於華麗
選擇連動 Notion 的樸素介面，而非漂亮但資料會掉的空殼。能用、可信，比好看更重要。
04
安全限制內建
家人的疾病飲食禁忌寫進 AI 生成規則，成為系統的硬限制。
系統架構：五庫一線
OUTCOME
不只是想，是做出能用的東西A system that actually runs
從一個資料偏空的食譜清單，到一套連動 Notion、能排菜單、能即時算營養的家庭系統。以下是實際運作中的畫面與量化成果。
量化成果
97
道食譜結構化
5
個關聯資料庫
3
位成員營養基準
即時
營養比對
運作中的介面
食譜瀏覽器 ｜ 讀取 + 篩選
週菜單規劃 ｜ 排三餐、寫回 Notion
每日營養 ｜ 即時估算對照目標
這個案例證明的能力
PROCESS
有紀律的執行與取捨Disciplined execution
系統不是一次寫成，而是一連串「先談對、再動手」的決策與分批執行。每一步都先確認方向，才往下走。
執行軸線
資料庫設計STEP 1
先定五個資料庫的欄位與關聯，決定「資料怎麼存」，再談介面。
補類別標籤STEP 2
為 97 道食譜定分類規則，分批判斷、覆蓋寫入，建立可篩選的基礎。
家庭設定STEP 3
建立三位成員的營養基準與疾病安全資訊、家庭偏好（店家、飲食法）。
補食譜內容STEP 4
74 道空白食譜分批 AI 生成、校準風格、逐批驗收後寫回 Notion。
週菜單介面STEP 5
建立排三餐、選誰吃、寫回 Notion 的規劃介面。
營養即時檢查STEP 6
呼叫 AI 即時估算當日營養、對照每位成員目標顯示足夠與否。
關鍵決策
沒有選擇
做一個漂亮的 9 頁籤 App，但資料存在瀏覽器、換裝置就消失（華麗空殼）。
選擇
樸素但連動 Notion 的介面，資料永久、一致、可信（實心系統）。
沒有選擇
預先估算並存入 97 道食譜的營養數據（工程大、易過期）。
選擇
排完菜單時 AI 即時計算營養，永遠反映當下、不存死數字。
⚠️ 系統內的營養數字為 AI 即時粗估，非精確營養分析，不能取代專業營養師或醫師建議。家中成員如有特殊健康狀況，飲食以專業意見為準。此原則內建於系統設計中。
可複用的交付模式
「資料庫先行、介面後裝」的 AI 系統建置方法：先把混亂資料結構化進資料庫（定規則 → 分批生成 → 校準 → 驗收 → 寫入），再用介面層接上。
同一套方法可直接移植到企業：客戶的 CRM、產品資料、內容庫也是先結構化、再接 AI 介面。家庭餐桌只是最貼身的試驗場。