Day 13 做完之後，畫面終於不是只有「看起來差不多」了。
我已經真的把 Day 12 的 Design System 丟回 Stitch，跑過三輪 Mobile First 調整：

• 第一版先把整套設計塞進 390px
• 第二輪修 Marker 跟 Bottom Sheet
• 第三輪只處理 Filter

最後我也刻意停在「夠用就好」，沒有繼續開第四輪。
但做到這裡，我反而先停下來檢查前面的東西有沒有對齊。
因為畫面可以看起來合理，不代表前面寫的 PRD、User Flow、Sitemap、資料欄位，真的跟這一版 UI 對得起來。
所以今天不加功能，也不再叫 Stitch 改畫面。

Day 14 要做的事情只有一件：把前 13 天留下來的東西全部攤開，確認它們講的是同一個產品。

先把現在真的有的東西列出來

跟前幾天不一樣，今天不是再從空白開始想。
我手上現在已經有：

PRD
User Flow
Sitemap / IA
資料欄位
DESIGN_SYSTEM.md
Day 13 最終 Mobile First UI

Day 13 最後那一版很重要。
因為今天 Review UI 時，我不會再拿 Day 10 或 Day 11 的舊畫面當準則，而是以 Day 13 第三輪完成的 Mobile UI 當目前設計基準。
也就是說，如果文件跟畫面打架，不是先叫 Stitch 再畫一版，而是先找出到底是哪一份規格過期了。

📸 圖片 1｜開發前目前真的要一起看的六份產出

我先自己走一次流程，不急著把全部丟給 Gemini

昨天已經用手機情境把主要流程走過一次，今天我想再換一個角度：

如果只看現在這些文件，我能不能清楚知道每一步到底在做什麼？

我先用最核心的路徑重新走：

打開探索頁
↓
定位或搜尋地點
↓
套用工作條件
↓
在地圖找附近店家
↓
點選 Marker
↓
先看 Collapsed 店家資訊
↓
需要時展開完整規則
↓
開 Google Maps 導航

然後每一步都問三件事：

PRD 有沒有寫？
UI 上找不找得到？
資料欄位撐不撐得起來？

這三題比「畫面漂不漂亮」重要多了。
Day 13 已經證明一件事：UI 問題不是只有尺寸，很多時候是資訊優先順序。
Day 14 要確認的是另一件事：這些畫面背後的資料跟規格，到底有沒有跟上。

這次 Gemini 不負責想功能，只負責抓矛盾

自己走完一次後，我才把資料交給 Gemini 做交叉檢查。
這次 Prompt 我刻意寫得很死，因為今天只是抓矛盾，不是請 Gemini 再幫我發明功能。

你現在是很挑剔的產品 Reviewer。

我會提供：
- PRD
- User Flow
- Sitemap / IA
- 資料欄位
- DESIGN_SYSTEM.md
- Day 13 最終 Mobile First UI

請只做「一致性檢查」，不要重新設計產品，也不要新增功能。

請找出以下問題：

1. PRD 有，但 User Flow 或 UI 沒有
2. UI 有，但 PRD 沒定義
3. UI 顯示了資料，但資料欄位沒有來源
4. User Flow 需要某個操作，但畫面上找不到入口
5. Sitemap 有頁面，但目前 MVP 流程其實用不到
6. Design System 規則與最終 Mobile UI 不一致
7. Day 13 已經砍掉或收斂的東西，其他文件還留著舊版本

請用表格輸出：
- 問題
- 出現在哪份文件
- 衝突的另一份文件／畫面
- 影響程度：高 / 中 / 低

不要直接替我改需求。
不要新增功能。
不要用你自己想像的最佳實務補規格。
如果資料不足，就標記「需要人工確認」。

這次 Gemini 的角色比較像是會一直問「所以這裡到底算哪一版？」的 Reviewer。
而不是產品經理。

Gemini 回來後，一口氣列了七個問題。
第一眼看滿像回事：高、中、低風險都有，表格也整理得很完整。
它抓到的七項大概是：

1. PRD 還有「輕量現況回報」，但 UI / User Flow / Sitemap 沒有
2. UI 顯示營業狀態與步行距離，但資料欄位沒有定義
3. UI 有收藏，但 PRD / Design System 說第一版不做
4. Sitemap 還有關於我們、部落格、會員系統
5. Filter Chip 樣式和 Design System 不完全一致
6. User Flow 還需要「套用」按鈕，但 UI 改成即時 Filter Chip
7. description 欄位在最終 UI 沒有對應展示區

如果只看輸出格式，做到這裡好像就可以收工了。
但我真的一條一條往回對，反而發現另一個更有意思的問題。

Gemini 找了七個問題，但有四個其實是它看錯版本

我原本以為前兩週果然留下不少規格債。
結果第一條就不太對。
Gemini 說 PRD 還有「輕量現況回報」，但 Day 07 我明明已經把現場微回報從 MVP 拿掉。
它又說 Sitemap 還有：

關於我們
部落格
會員系統

但這些也是 Day 09 前面的草稿。
最後留下來的 Sitemap 早就只剩：

探索頁
├─ 地點搜尋
├─ Filter
├─ 地圖／列表
├─ Cafe Card
└─ Bottom Sheet

Filter 也是一樣。
Gemini 認為 User Flow 還需要：

選條件
↓
按套用

但 Day 08 我就是因為覺得這套操作太繞，才把它改成直接在探索頁快速切換 Filter Chip。
收藏也是同一種狀況。Day 13 最後版本已經沒有把收藏留在核心流程裡，如果 Reviewer 還抓到愛心圖示，代表它很可能混到了比較早的 UI 或其他舊畫面。
做到這裡我才發現：

AI 不只會漏規格，它也可能把已經淘汰的規格重新挖出來。

有點像專案裡那種很認真的同事，翻到一份半年前的 Excel，然後跑來問：

「所以這個不是要做嗎？」
這時候不能因為 Gemini 很肯定地標成「高」，我就馬上回頭改 UI。
我得再做一次人工判定。

真的對回目前版本後，值得處理的反而只剩兩類。
第一個是資料來源。
Day 13 UI 上顯示：

營業中
今日至 21:30
步行 4 分鐘（280m）

這些不一定要全部存成資料庫欄位。
營業時間可以標成 Google Places 來源；步行時間與距離則標成根據位置計算的衍生資料。
問題不是「一定要新增三個欄位」，而是現在要寫清楚：這個畫面上的資料到底從哪裡來。
第二個是 description。
目前資料模型還留著店家介紹，但 Day 13 UI 已經沒有對應展示區，所以這一項不能只看文件名稱決定。我先標成「需要人工確認」，不硬替它找用途。
這個 Gemini 沒辦法替我決定。

這次 Review 最有用的，反而不是七個問題本身

這一輪讓我多了一個原本沒寫進 Checklist 的項目：

開發前不只要確認文件彼此一致，還要先確認 AI 讀到的是哪一版文件。

問題找到了之後，我順手把目前有效的內容整理成一組凍結版，不再把 Day 01～13 的歷史草稿混在一起。
我會整理成一組明確的凍結版：

docs/
├─ PRD.md
├─ USER_FLOW.md
├─ SITEMAP.md
├─ DATA_FIELDS.md
├─ DESIGN_SYSTEM.md
└─ MOBILE_UI_FINAL.png

我也把這次 Review 的版本規則補清楚：

以下六份資料都是目前最新版本。

不要引用、推測或恢復任何舊版需求。
如果內容中看到前後版本的敘述，
只以標記為 FINAL / CURRENT 的內容為準。

這不是在跟 Gemini 鬥智。
而是我現在已經有十幾天的修改紀錄，如果不先告訴 AI 哪份才算 Current，它真的有可能很認真地幫我把舊需求救回來。

📸 圖片 2｜Gemini 的七項問題＋人工判定結果

Day 13 讓今天多了一個很重要的檢查項目：文件有沒有跟著 UI 更新

前幾天如果做 Review，我可能只會檢查：

PRD ↔ User Flow
User Flow ↔ Sitemap
PRD ↔ 資料欄位

但 Day 13 真的跑完三輪之後，多了一個很現實的問題：

UI 已經改了，前面的文件有沒有還停在舊版本？

例如 Day 13 最後已經決定：

• Filter 維持單排，手機用橫向操作
• Selected Marker 收斂，只留必要資訊
• Bottom Sheet 有 Collapsed / Expanded
• 地圖仍然是探索頁主要區域
• 不為了修一個區塊就重做整頁

這些如果只存在文章裡，規格文件卻還留在舊版本，那今天這次 Review 就沒有做完。
所以今天 Review 不只是找 Bug，也是在做一次 文件同步。

Gemini 找到問題後，我不打算全部修

這一步我會先把 Gemini 找到的不一致整理成 Checklist，再自己分類。
我只分三種：

開發前必修
→ 不修就代表目前的核心流程還互相矛盾

可以之後修
→ 不影響目前第一版主流程，先記著就好

不處理
→ 舊版本殘留、已經被砍掉的想法，直接刪掉

這裡我反而不想用「全部變綠」當目標。
因為產品文件永遠可以繼續補。
真正要確認的是：目前還有沒有哪個核心流程，需要靠猜才能把文件跟畫面接起來。
如果還要猜，就今天先處理。
如果只是「以後可以更完整」，先不要。

📸 圖片 3｜MVP 一致性 Checklist

今天先把第一版範圍凍結下來

做到這裡，我才會真的把 MVP Freeze 下來。
這裡的 Freeze 不是「永遠不能改」，只是把今天確認過的版本先定下來。像下面這些突然冒出來的想法：

要不要加收藏？
要不要加 AI 推薦？
要不要有會員中心？
要不要讓使用者回報店家？

先不要因為「好像很簡單」就順手做進去。
今天一律先不加，全部丟進 Backlog。
因為這一輪的目的不是把產品補到沒有缺口，而是確認現在這一版到底包含什麼、不包含什麼。功能想到一個就補一個，前面兩週砍需求就白忙了。

兩週後，終於把「想做什麼」跟「畫面怎麼長」對在一起

Day 01 到 Day 07，我在處理「到底要做什麼」。
Day 08 到 Day 13，我在處理「使用者到底怎麼操作、畫面怎麼長」。
Day 14 則是第一次把這兩條線合起來。
今天真正要留下來的不是另一張漂亮 Mockup，而是：

一份沒有互相打架的 MVP 規格
一個已確認的 Mobile First UI
一份開發前必修 Checklist
一個暫時不再加戲的 Backlog 邊界

到這裡，Day 14 我想確認的事情就完成了。
不是又多做了一份文件，而是把前面散在 PRD、流程、Sitemap、資料欄位、Design System 和 UI 裡的決定重新對過一次，也順便抓出哪些內容其實早就過期。
今天最大的收穫反而很簡單：文件很多不可怕，可怕的是每一份都很完整，但講的不是同一版產品。