Day 29 完成了 WorkCafe 的 Cloud Run 部署，並記錄首頁、篩選、零結果畫面與服務日誌。實作到這裡告一段落，最後一天就回頭看看，這個網站是怎麼一步步做出來的。
一開始，我想做的是一個幫帶筆電工作的人找咖啡廳的網站。真正開始整理需求後，才發現「適合工作」很難用一個標籤說完：有插座不代表插座多，有 Wi-Fi 不代表穩定，平日下午安靜也不代表週末適合開會。
這些問題一路影響了欄位、篩選、介面與 AI 測試，最後也決定了這次網站能做到哪裡。
| 階段 | 當時處理的問題 | 留下的成果 |
|---|---|---|
| Day 01～07 | 誰需要這個網站、第一版要解決什麼 | 需求整理、競品比較、使用情境、資料欄位與 PRD |
| Day 08～14 | 使用者怎麼找店，手機上怎麼呈現 | User Flow、資訊架構、Stitch 畫面、Design System 與範圍確認 |
| Day 15～22 | 把設計接成能操作、能讀資料的網站 | Laravel＋Inertia＋React、Firestore、登入與收藏實作、Google Maps、Places 測試與篩選 |
| Day 23～26 | AI 輸出與工作分數能不能對回依據 | 條件解析、情境排序、評論摘要與 Work Score 的本機測試紀錄 |
| Day 27～29 | 網站怎麼啟動、離線時怎麼呈現、怎麼公開 | 基本 PWA、Android 模擬器啟動紀錄、REST 讀取改版與 Cloud Run 部署 |
| Day 30 | 整理成果與限制 | 這篇回顧 |
下面四張圖依序是 Day 01 的需求整理、Day 10 的 Stitch 設計、Day 15 的第一版網站，以及 Day 29 部署後的首頁。一路做下來，找店成了首頁的重點，使用者可以先看地圖和店家，再決定是否登入。AI 功能則留在本機測試，繼續核對輸出的內容。
📸 圖片 1-1｜Day 01：先整理需求，決定哪些功能值得做
📸 圖片 1-2｜Day 10：第一次用 Stitch 呈現探索頁
📸 圖片 1-3｜Day 15：把設計接成第一版可執行的網站
📸 圖片 1-4｜Day 29：WorkCafe 部署後的公開首頁
這 30 天用到的工具，各自負責不同的工作。
| 工具或服務 | 在這次專案裡的用途 |
|---|---|
| Gemini | 整理需求、檢查文件，以及測試條件解析、排序與摘要 |
| Stitch | 探索介面版型，調整手機畫面 |
| Antigravity | 讀取專案、修改程式、執行檢查與查看差異 |
| Firebase Authentication、Firestore | 處理登入身分、店家資料與收藏資料 |
| Google Maps JavaScript API | 顯示地圖與店家標記 |
| Places API | 在獨立測試中核對店家基本資料 |
| Cloud Build、Artifact Registry、Cloud Run | 建置映像、儲存映像與執行網站 |
| Secret Manager | 保存正式環境 APP_KEY，供服務執行時使用 |
實際使用時，我會把 Gemini 整理的需求和原始內容對照，用手機尺寸檢查 Stitch 的畫面，再查看 Agent 改了哪些程式、測試結果如何。部署後，也要打開網站、查看 Cloud Run 版本和日誌，才知道網站是否真的跑起來。
📸 圖片 2｜WorkCafe 的工具分工：規劃、設計、開發、資料與部署
前兩週整理了不少文件，但文件多了以後，同一個功能可能在不同地方有不同說法。Day 14 的檢查就遇到 AI 把舊版本當成現況，提出其實已經處理過的問題。
後來每次交付任務，我都會先確認使用哪一版規格、這次要改什麼，改完再同步更新相關文件。否則決定只留在對話裡，下次修改時又可能用回舊設定。
Day 23 的條件解析有十筆請求通過格式檢查，但逐句核對後，仍有 OR 組合、越權指令與否定語句的問題。
Day 24 的情境排序會省略店家的限時條件；Day 25 的評論摘要則曾把「適合工作」拿來當成會議適用性的依據。連協助核對的 Agent，也可能轉述錯誤或下太肯定的結論。
這幾天的測試讓我開始保留輸入、候選資料與原始回應，逐句核對摘要，再拆開分數看計算方式。這樣遇到問題時，才找得到是哪一段文字被誤解，或是哪個權重影響了排序。
Day 28 的建置卡在 gRPC 編譯，延長到一小時仍然逾時。最後調整成 Laravel 透過 Firestore REST API 讀取資料，正式映像不再編譯 gRPC。
原本一直在處理建置逾時，回頭看網站的需求，才決定換成 REST 讀取。調整後的檢查重點也跟著改變：資料分頁、欄位型別、讀取權限，以及請求失敗時的處理，都要重新核對。
📸 圖片 3｜開發過程中的取捨：需求範圍、AI 測試與部署調整
公開網站已有地圖與示範店家卡片。Day 29 的紀錄顯示，選取「插座多」後剩下兩間店，搜尋不存在的文字時會出現零結果提示。Cloud Run 修訂版本承接 100% 流量，日誌也記錄了首頁與靜態資源的 200 回應。
截至 Day 29，各項功能的實作與驗證狀態整理如下：
| 項目 | 這次系列留下的狀態 |
|---|---|
| 公開首頁、插座篩選、零結果畫面 | Day 29 已有截圖紀錄 |
| 登入與收藏 | 前面已有實作與測試紀錄；正式網域仍出現 OAuth 授權警告，不能直接當成正式環境驗證完成 |
| 自然語言解析、情境排序、評論摘要 | 保留在本機測試頁，已記錄輸出問題，沒有當成正式首頁功能 |
| Work Score | 本機固定資料可對上手算；權重是否符合使用者需求未驗證 |
| PWA | 已有本機離線提示與 Android 模擬器啟動紀錄；正式來源的完整離線、恢復與更新流程未驗證 |
| 其他驗證 | /up、測試路由 404、導航、實體手機及用量，仍缺完整紀錄 |
下面依操作順序放上三張畫面：先開啟首頁，再選取「插座多」，最後查看搜尋不到店家時的提示。首頁與前面的圖片 1-4 相同，這裡再次放上，方便一起看完整的操作畫面。
📸 圖片 4-1｜公開首頁：地圖與示範店家卡片
📸 圖片 4-2｜選取「插座多」：清單顯示兩間店家
📸 圖片 4-3｜搜尋不到符合條件的店家：顯示零結果與清除入口
這次用 Google AI 工具整理想法、嘗試介面和修改程式，讓我有機會把原本停在腦中的點子做成網站。過程中沒有記錄工時對照，所以無法量化省了多少時間；網站是否真的符合找店需求，也還沒有足夠的使用紀錄可以判斷。
我能確定的是，自己走過了一次從需求、設計、資料、程式到部署的流程，也留下了每個階段的判斷依據。
如果要把這 30 天的工作方式濃縮成幾句話，我會留下這四點：
30 天結束時，WorkCafe 已經有了可以開啟的公開網址。文章裡也記下了走過的彎路、測試發現的問題，以及還沒驗證的部分，讓這次開發留下的紀錄更完整。
謝謝一路看到這裡的人。從第一天的「想找一間能好好工作的咖啡廳」，到現在能打開網站看見店家、地圖與篩選結果，這次挑戰就在這裡收尾。
iThome鐵人賽
看影片追技術