Nailora 美甲情報 App 複盤｜AI BLOG

想做指甲的人翻遍社群也拼湊不出哪家店做得出想要的款式、何時有空檔，美甲師則必須在私訊裡一則一則人工排班，雙方都耗費大量時間卻難以對接。我在這件事中採取一人 AI 協作開發，從零到實機運行，打造出同時服務消費者與美甲店家的應用程式。

成果速覽

打造出提交次數約 300 次的雙邊市場應用程式，涵蓋消費者端瀏覽、投稿、預約，以及店家端管理功能。
建立嚴格的型別安全機制、先虛擬後真實的資料串接，並設計了三層資料安全防護。
沈澱出一套結合知識文件、角色分工與契約驗收的 AI 協作大專案開發法。
現況：功能已大體完成，並可在實機運行，預計近期上線。

為什麼要打造這個產品？

雙邊市場，也就是同時服務買賣雙方的平台，就像辦市集。沒攤商，客人進來只看見空地；沒客人，攤商也不想擺。這就是典型的「雞生蛋、蛋生雞」難題。

為了解決這個難題，我採取先攻供給端的策略。我優先邀請身邊認識的美甲師加入，協助他們將既有的社群作品搬遷過來，並提供工具降低加入門檻。當平台上累積了足夠的作品內容，自然就能吸引有需求的消費者前來瀏覽與預約。

note技術細節：雙邊市場的資料表設計

後端資料庫設計了數十張業務資料表，包含 designs（設計作品）、shops（店家沙龍）、bookings（預約單）、messages（聊天訊息）與 reviews（評價）。透過外鍵關聯，確保 C 端消費者與 B 端店家在預約交易與訊息互動時，資料能保持一致。圖片資源則透過雲端儲存空間進行管理。

如何在沒有後端時先寫介面？

蓋房子若非得等水泥水電全部拉好才規劃室內裝潢，一旦發現格局不合，修改就得拆除重來。聰明的做法是先用輕隔間搭建樣品屋，確認生活動線沒問題後，再接上真正的管線。

開發過程中，我採用 Mock First，也就是先用模擬資料把介面做完，確保開發不被後端進度卡住。我先用寫死的假資料把畫面上的按鈕、切換效果與流程做出來，確認點擊反應和版面配置都順暢後，才去對接真正的雲端資料庫。

note技術細節：前端架構與模擬資料規範

本專案基於 React Native 0.81 與 Expo SDK 54 開發。前端採用嚴格的 TypeScript 限制，開啟 strict 模式並嚴格禁止使用 any 型別。模擬資料統一存放於 lib/mock 資料夾中，遵循單一真相源原則，確保一份資料只有一個模擬陣列，避免後期切換真 API 時產生衝突。

怎麼保護使用者的私密資料？

這就像辦公大樓，大廳是公共區域，任何人都能自由進出；辦公樓層需要感應員工證；至於存放機密合約的檔案櫃，則只有特定主管拿著鑰匙才能打開。

我為應用程式設計了三層防護，利用 Row Level Security，也就是一種限制使用者只能讀寫屬於自己資料行的機制。這能確保一般訪客只能瀏覽公開作品，登入後的會員管理自己的預約，而店家的營業額和客戶資料，絕對不會被其他同行看見。

note技術細節：後端架構與 RLS 安全策略

後端採用 Supabase，透過 Row Level Security（RLS）設定 anon（匿名）、authenticated（已登入用戶）與 service_role（系統管理員）三種角色權限。複雜的商業邏輯如建立預約、成員管理等，透過 RPC（遠端程序呼叫）執行。使用者頭像與作品圖片上傳時，會觸發 Edge Functions 預先處理成多種尺寸後，再存入 Storage。

預約時間如何做到精準不錯位？

若你人在台北，想預約一個線上會議，系統卻自動判斷成倫敦時間，最後雙方一定會錯過。時間和日期在跨地區的系統裡，常因換算方式不同而出現偏差。

為了避免預約時段錯位，我採用了帶時區的時間戳記，也就是一種能記錄絕對時間與當地時差的格式，並在資料傳輸時進行驗證。此外，在處理登入功能時，我發現看似簡單的第三方帳號登入，背後常藏著許多不易察覺的副作用，必須透過實機測試才能抓出真正的問題。

note技術細節：時區處理與第三方登入偵錯

資料庫時區欄位一律採用 timestamptz，並於前端與後端間進行 round-trip 驗證。整合 Apple Sign In、Google OAuth 及 LINE 登入。曾遇到 Google 登入失敗，真因為回調過程汙染了 returnTo 變數（Closure 副作用），此類涉及原生橋接的機制必須使用實機測試，無法在 Expo Go 虛擬環境中完整重現。

怎麼讓 AI 幫忙開發大型專案？

帶領極度聰明但沒有長期記憶的助理工作時，若每天只是隨口交代，他很快就會丟三落四。你必須給他員工手冊，明確劃分職責，並在交辦任務前白紙黑字寫下驗收標準。

專案變大後關係錯綜複雜，AI 容易顧此失彼。為此我建立了協作架構：將知識文件分層管理以避免資訊過載，並實施角色分工與契約驗收，讓不同功能的 AI 代理互相制衡。

具體運作方式整理在以下幾篇專題中：

[[AI 協作開發：非技術 PM 的驗收閘門]]：不會讀程式碼的人，如何靠關卡守住產品品質。
[[AI 協作開發：五段式契約流程]]：如何寫出讓 AI 能夠機械化自我檢查的驗收契約。
[[AI 協作開發：多 Agent 對抗管線]]：如何讓多個 AI 角色各司其職、互相監督。
[[AI 協作開發：Context 節流與錨點術]]：當專案文件過多、吃掉 AI 記憶體時的應對策略。

note技術細節：Claude Code 與專案文件架構

專案內建 CLAUDE.md 作為執行層的紅線規範。劃分四個層級：執行層、決策層（保存決策歷史並用刪除線標示淘汰決策）、規範層（standards 子目錄為單一真相源）及歷史層（plans 與 reports）。透過 AI 代理（Agent）分工，區分為 planner（規劃）、evaluator（驗收）與 researcher（研究）角色，並利用自動化指標追蹤 token 大小。

產品家族與未來展望

這套為媒合平台設計的核心引擎，除了可以用在原本的應用程式上，也能拆解下來裝在其他工具中，解決不同的特定需求。

這個題目最後長成三個不同的產品，共同組成了解決美甲需求的家族生態：

graph TD
  A[找美甲的人] --> C[Nailora 本體]
  B[開店的美甲師] --> C
  C --> D[拆出離線筆記工具<br/>只留在自己手機裡]
  C --> E[品牌帳號的自動發文流水線<br/>機器產、人按核准]

拆出純本機運作的離線筆記工具，是因為部分使用者只想在本地記錄，不想將資料上傳雲端。自動發文流水線，則是為了解決社群帳號需要定期產出內容的重複勞動。

為了維持社群熱度，我設計了自動化流水線，由 AI 收集趨勢並撰寫草稿。關鍵在於「核准閘門」：AI 內容絕不直接發布，必須由我親自審核後才能上線。雖然此流水線目前已停運，但「機器產出、人類把關」的設計邏輯，依然是我開發自動化系統時的重要準則。

note技術細節：產品衍生與自動化架構

離線筆記工具（NailNote）從主專案拆分，移除雲端資料庫依賴，轉為純本地端儲存。自動發文流水線結合排程任務，自動偵測熱門標籤，利用大型語言模型生成排版文案，並在後台提供 Webhook 觸發審核流程。