我們搭了一個能用的預訂應用——登入、一張顯示空閒時段的日曆、支付，以及郵件提醒——從頭到尾 30 分鐘完成，並記錄下了每一步。不是一個停在漂亮預覽上的演示。一個真實的應用，掛在真實的網域上。這裡是技術棧和用到的提示。
技術棧
你不需要太多東西，而且大部分都由 AI 建構工具替你接好：
- Supabase —— Postgres 資料庫，外加 Auth（電子郵件/密碼、magic link，以及透過 Google 或 GitHub 的 OAuth）和列級安全。這是骨架。
- Stripe —— 付費預訂的支付環節。
- Resend —— 確認郵件和提醒郵件。
Supabase 是最關鍵的那塊：它從一個控制台就給你真實的資料庫、真實的認證和儲存，這也是為什麼大多數 AI 建構工具直接整合它。
逐個提示地搭建
大約五個提示就能搞定：
- 搭鷹架 —— 「一個預訂應用。電子郵件登入。一個顯示空閒 30 分鐘時段的日曆。」幾分鐘內你就得到一個帶認證、能跑起來的應用。
- 資料模型 —— 一張
slots表和一張appointments表，加上列級安全，這樣登入使用者只能看到自己的預訂。 - 支付 —— 在某個時段被確認之前，加一個 Stripe 結帳環節。
- 通知 —— 確認時發一封 Resend 郵件，並在預約前發一封提醒。
- 管理後台 —— 一個列出今日預訂的頁面。
AI 會做錯的那一處
這就是 AI 建構工具預設每次都會發布的那個 bug：重複預訂。 天真地說，生成的程式碼會先讀出空閒時段，再寫入預訂——而如果兩個人在同一時刻點了同一個時段，兩次寫入都會成功。你把一個時段賣了兩次。
修復辦法是把這次預訂做成一次帶列級鎖的單一資料庫交易——鎖住該時段的資料列、檢查它仍然空閒、寫入預約、釋放鎖。在 Supabase 裡這是一次 Postgres 交易（在一個函式裡用 SELECT ... FOR UPDATE），而不是用戶端發出的兩次獨立查詢。除非你主動要求，AI 幾乎永遠不會想到這一招。所以要主動要求：
「把時段預訂做成一次帶列級鎖的單一 Postgres 交易，這樣兩個使用者就沒法訂到同一個時段。」
這就是一個演示和一個你願意讓真實客戶碰的東西之間的區別——而它恰恰就是那種對正確性至關重要的邏輯，AI 仍然需要人類來兜底。
發布它
一個掛在預覽 URL 上的能用應用仍然不是產品。把它指向你自己的網域——那是個 10 分鐘的活兒——然後你就上線了。
結論
30 分鐘是真的，但有一個星號：AI 很快把你帶到 95%，而最後的 5%——並行、安全規則、那些錢所依賴的邊緣情況——才是你賺到工錢的地方。知道那 5% 在哪兒，你發布出來的就是真實的東西，而不是一張截圖。