前兩天把手機畫面和規格對完，今天終於輪到程式碼了。
我原本想把最後那張 PNG 丟給 Antigravity，請它照著做。後來才想到，Stitch 已經有可以匯出的 code，版面和樣式也能一起帶過來。
前面花了三輪才調好的 Filter、Marker 和 Bottom Sheet，總不能換個工具又從頭猜一次。
所以今天先拿這份 code 當起點，看看哪些能用，再把搜尋、Filter 和店家卡片接起來。

先把文件放進專案

目前 workcafe 資料夾裡，已經整理好這六份文件：

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

這裡放的是目前版本，手機圖也採用 Day 13 第三輪的結果。

📸 圖片 1｜目前專案裡的六份規格

至少打開專案，就找得到搜尋、Filter 和 Cafe Card 的規則，也知道哪些功能已經砍掉。
不過前面還留了一個空白：網站到底要用什麼架構？

Laravel 決定了，前端怎麼做？

我一開始考慮的是 Laravel，但前端要怎麼搭還沒想清楚。
我先讓 Antigravity 比較兩個方向：

• Laravel＋Blade，搭配少量 JavaScript
• Laravel＋Inertia＋React

我想知道哪一種比較好維護，尤其這個網站大部分時間都待在同一張探索頁裡，搜尋、篩選和店家資訊會一直互相影響。
資料庫和外部服務的分工也一起問清楚。今天先用假資料，原本提過的 Firebase 就不急著接。
我給 Antigravity 的 Prompt 是：

先閱讀 docs/PRD.md 與其他 CURRENT 文件。

目前專案尚未決定技術架構，我考慮使用 Laravel。
請依今天的搜尋、Filter、Cafe Card 與 mock data 範圍，
比較：
- Laravel＋Blade＋少量 JavaScript
- Laravel＋Inertia＋React

說明兩個方案的實作方式、維護負擔，
以及資料處理與外部服務的分工。
列出建議、理由與尚待我決定的項目。

先不要安裝、建立專案或修改檔案。
保留 docs/ 與根目錄 PRD.md。

Antigravity 的建議很明確：Laravel＋Inertia＋React，搭配 TypeScript。

📸 圖片 2｜Antigravity 的架構建議與理由

我比較在意的是，畫面狀態會不會打架

我最在意的是它提到的互動狀態。
Filter 改變後，地圖和卡片要一起更新；選到一家店，Marker 和 Bottom Sheet 要對上；關掉詳情後，也不能把剛才看的位置全部重置。
我不想修了卡片，卻忘記另一邊的 Marker。把這些狀態放在一起處理，是這次選 React 最主要的理由。
它說 Blade 加上零散 JavaScript 的維護成本會「呈指數上升」，我覺得講太滿了。Blade 當然也能做互動，只是這個專案需要同步的地方不少，我比較想用元件和狀態把它們整理好。
TypeScript 也剛好接得上前面的 DATA_FIELDS.md。插座、Wi-Fi、限時規則都有固定欄位，還帶著來源、更新時間和備註，元件和假資料可以共用同一套型別。
不過它只會幫我檢查型別，不會自動驗證 API 回傳，更不會知道某間店是不是真的有插座。「未知」和「沒有」怎麼判斷，還是得自己寫清楚。
Inertia 則負責把 Laravel 和 React 接起來，省掉為了傳頁面資料而另外拆一套 API 的工作。路由、資料驗證和外部服務還是要處理，只是現在不用再多顧一套前後端介面。
最後這一版採用 Laravel＋Inertia＋React＋TypeScript，也把方案記在 README 裡。

把 Stitch 的原始 code 一起帶過來

Stitch 的 code 要拿 Day 13 第三輪那份，才會跟 MOBILE_UI_FINAL.png 對得上。
原始匯出放在：

references/
└─ stitch/
   └─ 原始匯出檔案

這個資料夾保留原始檔，實作用的程式另外整理。改完若跟原圖差太多，還能回頭看是哪一段動到了。

📸 圖片 3｜Stitch 最終畫面與匯出內容

接著要看 code 裡到底有什麼。版面、樣式和示例資料可以先整理，Filter 有沒有真的篩選、地圖是不是只有示意畫面，則要另外檢查。
如果裡面還有舊版的收藏或回報入口，就照 CURRENT 規格拿掉。前面已經砍過了，不想在搬 code 時又撿回來。

先讓基本專案跑起來

架構確定後，就可以建立專案了。
這一步先讓基本頁面能開，不急著搬整張咖啡廳畫面。資料夾裡已經有文件和 Stitch 原始檔，初始化時也要保留。
這段 Prompt 把範圍寫清楚：

依照我已確認並記錄在 README 的技術方案，
在目前 workcafe 資料夾建立基本專案。

若方案尚未確認，先列出缺少的決定，不要自行選擇。

保留 docs/、references/stitch/、PRD.md 與其他既有檔案。
目前目錄不是空的，不要使用會清空目錄的初始化方式。
只安裝已選方案需要且版本相容的依賴。

先讓基本頁面能開啟，不實作咖啡廳功能。
檢查是否已有 Git repo；沒有才初始化。
不要自動提交或推送。

完成後列出：
- 新增與修改的檔案
- 實際安裝的版本
- 啟動方式與本機網址
- 驗證結果，以及尚未完成的部分

啟動方式和本機網址，以建立後的專案設定為準。

📸 圖片 4｜專案初始化與本機啟動

先看到初始頁面就好，接下來才處理咖啡廳介面。

把 Stitch code 拆成元件

基本專案正常後，才把 Stitch code 接進來。
規格、PNG 和匯出 code 一起交給 Antigravity，請它沿用能用的部分，整理成 React 元件。假資料也要對齊 DATA_FIELDS.md，不能每張卡片各寫一套。
整合的 Prompt 是：

先閱讀：
- docs/ 內所有 CURRENT 規格
- docs/MOBILE_UI_FINAL.png
- references/stitch/ 的原始匯出程式碼
- README 中已確認的技術方案

先檢查匯出內容的格式、依賴、素材與已有互動，
說明哪些可以沿用，哪些需要改寫。
不要假設靜態畫面已具備真正的搜尋、篩選或地圖功能。

依已確認的架構整合，這次只完成：
- App layout
- Search bar
- Filter chips
- Cafe card
- Mobile First 基本版面

沿用可用的版面、樣式與素材，不重新設計整頁。
將程式碼整理成可維護的元件。
資料依 DATA_FIELDS.md，使用明確標示的 mock data。
搜尋與篩選只作用在假資料。

不要修改 references/stitch/ 原始檔。
匯出內容若與 CURRENT 規格衝突，以規格為準，
列出差異與處理方式。
不串接真實地圖、登入、資料庫或 AI 服務。

完成後列出：
- 沿用與改寫的部分
- 修改的檔案
- 做出的假設
- 實際檢查結果與尚未實作的行為

這次只接搜尋、Filter 和卡片。完整地圖與 Bottom Sheet 先留在規格裡，不塞進同一個任務。

📸 圖片 5｜Antigravity 把匯出 code 整理成元件

縮到手機寬度，再看一次

我會把瀏覽器調到約 390px 寬，逐項看：

• Search 與卡片文字是否可讀。
• Filter 是否維持單排，能滑到最後一顆。
• 點選、取消條件後，假資料結果是否跟著變。
• 零結果時，能不能取消條件繼續找。
• Cafe Card 是否看得到插座、Wi-Fi 與限時資訊。
• 畫面有沒有清楚標示假資料。

📸 圖片 6｜本機第一版 Mobile UI

收尾還要跑專案的建置與檢查，看過 diff 再 commit。哪些通過、哪些還卡住，就照實際結果記錄。

今天先做到這裡

程式一開始長出來，前面的文件就有用了。欄位拿不準可以回頭看 DATA_FIELDS，元件怎麼排可以對 Design System，不用每次都重新問一遍。
Stitch 的 code 也多了一個用途：把已經調過的版面帶進專案，再慢慢接上資料和操作。
今天先把這一小段做好。畫面像不像、按下去有沒有反應，都要真的打開來看。