我们搭了一个能用的预订应用——登录、一张显示空闲时段的日历、支付，以及邮件提醒——从头到尾 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% 在哪儿，你发布出来的就是真实的东西，而不是一张截图。