實驗收尾
不再加新測試。Day 29 的要煮，就是這次原型的停點。

這張是收尾意象圖。
從冰箱、規則、記憶到下一餐的方向都在，但「下一餐自動讀取更新庫存再推薦」這件事，這次還沒有完整驗證到端。

1. 30 天留下什麼

30 天後，至少有幾件事留了下來。

冰箱變成一張能改的表。
規則會先看過敏、預算、時間、設備。
Gemini 不再從整份菜單亂挑，而是在合法候選裡選，或寫一句理由。
有記憶的回放會帶前一餐庫存。
結果卡留過六格。
Day 29 的 Alpha 在按下「要煮」後，會直接執行食材結算並更新 Firestore。

但有些事情，我沒有把它寫成已完成。

採用和完成還沒分開。
下一餐也還沒真的讀扣完的庫存再跑一次。
真人有沒有因此少丟菜、比較省力，這 30 天也沒有連續使用資料可以算。

16 題的 Hard，A 是 6，B1 和 B2 是 13，C 是 16。
這張表證明的不是「模型忽然變聰明」，而是多一層規則與多一份上下文之後，系統比較能守住限制。

C 的 16/16 同時受到額外 Context 與生成前候選過濾的影響。
這次沒有拆開量化兩者的貢獻，所以不能把它當成模型單獨的能力提升。

五天回放是同一格冰箱跑一次。
有記憶 7 點，沒記憶 12 點。
這裡的點數不是新的台幣，也不是家裡真的少丟了多少菜。它只是固定情境下的單次回放，表示同樣一段過程，帶著前一餐的庫存狀態，可能比較少買。

2. 用了哪些 Google 技術

這 30 天不是只在試一個模型。
比較像是把 UI、程式、資料和 AI 推薦，接成一個真的能跑的小原型。

前面實際用過的，主要是這幾個：

Gemini Structured Output。
候選與理由走同一份 JSON。模型不是直接碰整份冰箱，而是在已經合法的候選名單裡做推薦、寫理由。這次主要請求的是 gemini-3.5-flash。

Function Calling。
Day 16 讓模型回「我要讀冰箱」。真正讀資料的是程式。模型知道要查什麼，但碰不到資料庫本身。

Firebase Authentication。
Google 登入之後，每個人的記錄都寫在自己的 users/{uid} 下面。實驗資料不是混在一起。

Cloud Firestore。
回放、結果卡、Golden、Day 27 的按鈕紀錄、Day 29 的 day29_meals 和 fridge/current，都留在這裡。這也是我把冰箱狀態、操作結果和原型痕跡接起來的地方。

Stitch。
在前期幫我把 DishFlow 的頁面雛形想清楚。不是直接交付整個產品，而是先把 UI 的方向整理出來。

Antigravity。
把前端操作、規則流程和資料更新串起來。到後面真正讓原型能跑，靠的是程式、規則與資料一起接起來，而不是只畫出畫面。

如果只講一句話，我的感想其實很簡單：

Google 全家桶真的很適合快速開箱、快速試做，也很適合把一個還在摸索的點子，先變成可以操作、可以驗證、可以留下記錄的原型。

3. 遺珠之憾

這次最值得留下來的，不只是做到了什麼，還有沒做到什麼。

決定要煮，還不代表已經煮完。
這個版本把兩件事收成同一下。採用沒有單獨留著，也沒有先不扣庫存。

下一餐還沒讀扣完的冰箱再推薦一次。
所以端到端的「明天記得今天」，這次只證明到庫存有寫回去，沒有證明下一份名單真的會跟著變。

少買、先用快過期，沒有改寫 Hard 的過關名單。
合規的菜仍可能把預算花滿，也不保證先用快到期的。

大約到期是今天加上剩餘天數，和包裝上的日期可能不同。
熱量和時間也沒有精確實測。
真人有沒有因此省力、滿意、少丟菜，也沒有連續使用資料能算。

如果還有下一個 30 天，我會先做兩件事。

第一，把採用和完成真正拆開。
決定要煮的時候先記錄，確認煮完才更新庫存。

第二，讓下一餐直接讀取更新後的冰箱，再跑一次推薦。
只有這樣，我才能確認今天留下的食材，真的會影響明天的菜單。

其他像 Soft Ranking、效期、營養和真人使用驗證，就留到這條流程接通之後再處理。

最後，回到那台冰箱

最後有點感慨
畢竟最後我完成這邊很像是做完一篇論文的感覺

從最初Day 0 的時候，我只是站在冰箱前面，不知道今晚要吃什麼。

寫到最後，我做了一張能記錄庫存的表、一套會先檢查限制的 Rule Engine，還有一個能從合法候選裡選菜的 Gemini 推薦流程。

它沒有替我把生活全部安排好。

Day 27 勾了少買，Gemini 還是選了要花四點買蛤蜊的菜。
Day 29 系統提醒我豆腐和青江菜快到期，我最後卻選了花椰菜米蛋炒飯。

有時候，知道什麼比較好，不代表今晚就想那樣做。

但至少現在，我可以看見每個選擇背後的條件。

哪些菜因為過敏不能選，哪些超過預算，哪些食材快要放不住。
模型選了什麼、為什麼選，最後由我決定。

我也終於理解，讓 AI 記得昨天，不是多存幾筆聊天紀錄就好。

推薦不代表採用，採用不代表煮完。
這個版本還沒有完全分開這些狀態，所以我不會說 DishFlow 已經完成了真正的生活閉環。

這是這次留下的遺憾，也是如果繼續做下去，我最想先完成的事情。

回頭看這段時間，最有價值的收穫也許不是多學會一個模型 API，而是開始知道：

哪些判斷可以交給 AI，哪些限制必須由程式守住，以及哪些決定應該留給真正要吃這頓飯的人。

30 天前，我希望 AI 幫我決定晚餐。

現在，我比較希望它讓我更容易做決定，也能在下一餐記住真正發生過的事。

至於今晚吃什麼？

我還是得打開冰箱。

鍋子，也還是要自己洗。