Part 3｜第 10／30 篇
今日要做的事： 用 Google Stitch 把 DishFlow 收成 Today、Strategy、Result 三頁——拍照、最多兩題確認、手動後門都塞進 Today，不另開第四頁。
今天要解決的目的： 欄位已經夠多了；今天練習刪。60 秒是目標線，有碼表才准寫「過了」。

Day 8 門衛裝好了，照片也能進私有 Storage。
可是如果畫面還是工程師表單，使用者會先累死，資料根本活不過隔天。XDD
Stitch 只負責設計期把流程畫出來——不進 Runtime、不寫 Firebase、不接 Gemini 推薦。

今日任務卡

路線圖

欄位太多沒人填
  → 一頁只做一個決定（Today / Strategy / Result）
  → 拍照＋兩題確認＋手動後門收進 Today
  → Stitch 出稿
  → 碼表走一輪（登入不算進 60 秒）
  → 明天才用 Antigravity 接到 Firebase

1. 問題：資料完整，不代表有人願意填

LifeFlow 已經有預算、時間、food_source、餐點 tags、庫存、策略。
全部攤開就是一張很完整的工程師表單，也是一個很慢的 DishFlow。

A 很快，因為只問一句話；B 要你反覆貼條件；C 不該靠「欄位最多」贏——固定資料留在系統，人只處理今天真的變的。

如果這系列只剩資料串接，讀到這裡的人會有兩種感覺：一是無聊（又一個 users/{uid}），二是沒感覺——規則通過了，晚餐還是不知道怎麼點下去。

我真正想服務的是已經累完的人：上完班、上完課，腦袋不太想再開伙研究。
Eat-Cost Balance 在這一刻很具體——要快（不要填一張工程師表單）、要有效（看得到時間跟大概多少錢）、還要能消庫存（家裡剩料先被用掉，而不是又外帶一份回來放冰箱）。三頁就是為了把這三件事壓進一分鐘裡。

介面就是把「我懂這套契約」翻譯成「我累的時候仍願意按三下」。UI／UX 不是裝飾，是資料願不願意被填完的那一哩。
Google Stitch 幹的就是這件事：設計期把工程師 schema 畫成正常人看得懂的畫面，而且不進 Runtime。明天才接線。

所以今天不比配色細節、不接模型，只回答：

三頁能不能少重填、少回頭，而且我敢拿碼表量？

2. 設計：一頁只做一個決定

2.1 Today：只改今天不同的事

• 預算、可用時間：帶 profile 預設，要改才展開
• food_source：home／convenience_store／supermarket／eat_out 四選一
• 已吃的那一餐：拍照 或 手動（Day 8 後門）——label＋粗 tags，不填營養數字
• 模型不確定時：最多兩題（Day 5），問完就停

外食只記餐、不扣家裡庫存。選 home 也不代表食材已經沒了——煮完、送出 Outflow 才扣。
這兩句要寫在畫面上，免得「採用推薦」被看成「冰箱已經少一盒豆腐」。

2.2 Strategy：今天只留位置，而且可以略過

chips、Preset、「沿用預設」。
可以放「剩料優先」「少洗鍋」這種人話標籤，但今天不建 Strategy 文件、不宣稱已寫入 active_strategy_ids——那些是後面才定的 hard／soft／compile。

所以這頁必須能直接略過。它不是每天必填問卷，更不能出現「關掉過敏限制」這種開關。你總不會希望一顆 Preset 就把蝦過敏關掉吧。

2.3 Result：看決定，不看模型履歷

兩到三張卡，每張只要：

• 大概多久
• 大概多少錢
• 會用到哪些 pantry
• 一句為什麼
• 採用／不採用

今天內容是 mock，畫面要寫「示意資料」。採用只記選擇，不扣庫存。
API key、模型名、token、卡路里環——刪掉。那是開發者的事，不是下班決定晚餐要扛的步驟。

3. 交給 Stitch 的 brief（短的就夠）

不要下「做一個健康 App」。限制寫清楚，它比較不會自己加聊天室：

設計 DishFlow 的行動版網頁（不是原生 App、不上架），直向三頁：Today、Strategy、Result。繁體中文。
用瀏覽器開，不要底部 Tab 列、不要 App Store 風格。
下班後 60 秒內：改今天條件 → 可略過策略 → 看到下一餐方案。
預設值優先；非必要欄位折疊。
Today：預算/時間、food_source 四選一、拍照或手動記一餐、不確定最多兩題。
外食文案：「只記錄，不改家中庫存」。
Strategy 可略過；不可關閉過敏。
Result：2～3 張示意卡（時間、成本、用到庫存、一句原因），標「示意資料」。
採用按鈕不可暗示已扣庫存。
不要：卡路里環、聊天首頁、社交、API key、模型設定、第四頁、原生 App 導覽列。
每頁一個主按鈕。

貼進去之後，Stitch 一次吐出三頁初稿：Today、Strategy、Result。旁邊的色票是它附的風格板，不是第四頁。三支畫面才是重點：

Stitch 用手機外框預覽，看起來像 App，其實我要的是直向網頁：下班用手機瀏覽器打開，不上架、不開模擬器。外框留著沒關係，三頁責任已經看得到。桌面寬版以後 demo 再拉寬就好。

這版是初稿，不是終稿。重點是終於看得到「今天／策略／結果」，而不是只看到 JSON。

4. 60 秒怎麼算（不是 Stitch 畫圖的速度）

這 60 秒量的是使用者在畫面上走路：Today 打開 → 改今天的條件 → 略過 Strategy → 看到 Result 第一張卡。
不是量 Stitch 幾秒生出三頁。

我開預覽自己走了一輪：沿用預算、改時間、選一種來源、略過策略，停在 Result。碼錶大約 21 秒（20.75）。
這是原型能點的速度，不是已上線網頁，登入也還沒算進去。至少這三頁有機會壓進一分鐘。

起點是 Today 已經打開，終點是第一張卡看得完。開 Stitch、等它畫完，都不算進這 60 秒。

畫面上卡片標了示意資料，外食那張也寫「只記錄、不改家中庫存」。累的時候要的就是：快、看得懂時間和錢、順便把冰箱剩料銷掉。

5. 今日結論

1. 三頁責任先鎖死：Today 收今天的差異（含拍照／兩題／手動）、Strategy 可略過、Result 幫人決定。
2. 預覽主路徑我走了約 21 秒到 Result。這是原型，不是正式網頁；但方向對：累的時候要快、要看得懂成本，還要能消庫存。
3. 外食與「採用」都不扣 pantry。
4. Stitch 畫完就停。接到 Firebase 是明天 Antigravity 的事。

下一篇： 用 Antigravity 把這三頁接到 Firebase，先驗 Auth、daily 與 pantry——推薦可以先 mock。

附錄：完整 brief

產品：DishFlow。資料：LifeFlow。
形式：行動版網頁（瀏覽器直向），不是原生 App、不上架。繁體中文。只要三頁。

1. Today
   - 預算與時間：profile 預設、預設收合、可改。
   - food_source：home / convenience_store / supermarket / eat_out。
   - 一筆已吃餐點：拍照或手動；label + 粗 tags；不填熱量。
   - 不確定時最多兩個確認題。
   - 外食：「只記錄餐點，不變更家中庫存」。
2. Strategy
   - chips、Preset、「沿用預設」。可略過，非必填。
   - 不能關掉過敏／硬限制。
3. Result
   - 2～3 張 mock 卡：時間、成本、uses pantry、一句 why。
   - 標「示意資料」。採用 ≠ 已扣庫存。

不要：聊天首頁、卡路里環、運動／體脂、社交、API key、模型名、第四頁。
每頁一個主按鈕。風格簡潔。