AI 建站上线前，权限和表单必须验收

一个用 v0 搭建的网店，页面能打开，联系表单也显示发送成功，但数据库没有开启访问限制，客户留言实际上全丢了。店主不知道网站由 AI 构建，也不在意；他关心的是「能用」。

作者的结论是：用 AI 给小商家做网站可以接受，交付前没人检查才是问题。这篇文章值得读的地方，是把「看起来能用」拆成了几项具体、可验证的交付责任。

页面能用，为什么业务还是坏的

作者检查这个网店时，从浏览器控制台和 Network 面板入手，在不到一小时内发现 Supabase 没有开启行级安全策略（Row Level Security，RLS）。

这里容易产生一个误解：浏览器里能看到 API key，就代表密钥泄露。作者引用 Supabase 文档指出，浏览器使用的 key 原本就按公开信息设计，RLS 才负责限制它能访问哪些数据。对于暴露 schema 中的表，如果关闭 RLS，获得该表授权的角色就可以读写它。

因此，检查重点不是「有没有把 key 藏起来」，而是「拿着这个公开 key，到底能操作什么」。

这次表里只有页面内容，没有客户信息和咨询记录。作者认为这是运气好：如果下一次提示词让 AI 按同样方式新增 newsletter 表，真实邮箱就可能落入相同的访问范围。后者是风险推演，并非已经发生的数据泄露。

联系表单则是已经出现的业务故障：界面显示发出去了，消息却没有送达任何地方。对商家来说，客户询价后一直收不到回复，可能比页面样式出错更伤生意。

界面显示成功，只能证明界面走到了成功状态。

交付检查应该查到哪一步

作者给出的检查路径很短，却覆盖了几个容易被演示效果遮住的问题。

先打开 Network 面板，检查公开 key 发出的请求能返回什么，再检查数据库访问规则。接着，通过联系表单给自己发送一条测试消息，确认接收端真的收到。

两步分别回答不同的问题：数据有没有越过权限边界，业务链路有没有真正闭合。

SEO 检查也很具体：查看页面源码，再访问 /robots.txt 和 /sitemap.xml。这个网店没有 sitemap 和 robots.txt，页面标题则缺失或各页重复。作者实际修复了表单、数据库规则和这些 SEO 问题，但没有提供修复前后的流量、收录或转化数据。

原文没有展开表单为什么丢消息，也没有给出 RLS 策略、请求记录或修复代码。因此，它能提供检查方向，不能直接充当实现教程。

作者认为，这些检查应该由建站者在交付前完成。店主没有理由先学会 RLS，才能判断自己买到的网站是否合格。

用 AI 提速，谁来承担验收责任

作者自己也用 Claude Code 和 Cursor 做客户网站，并表示它们大幅缩短了构建时间。不过，方案构思和技术审查仍由他负责。这里没有具体工时数据，「大幅」是作者的个人评价。

他也没有据此给 v0 下结论：疲惫的开发者同样可能交付一个数据库开放、表单失灵的网站。

这让文章的批评对象更明确了：生成工具参与了开发，并不能成为省略验收的理由。客户看见的是页面，开发者还需要检查页面背后的权限、请求和消息去向。

AI 可以参与实现，交付责任仍需要有人承担。

我的判断

我赞同作者把责任落到交付检查上。相比争论「AI 写的网站靠不靠谱」，验证数据库权限和表单送达更有操作价值，也更容易发现眼前的问题。

但这仍是一篇单个案例的经验分享。作者没有提供 AI 建站与人工开发的缺陷率对照，也没有证据支撑「几乎没人审查」这个更广泛的判断。它说明了这个网站缺少必要检查，不能证明整个行业都如此。

检查清单也有边界。确认公开 key 能返回什么，是一个入口；它还不足以证明所有角色、数据和操作都受到了正确限制。SEO 同样如此：缺少 robots.txt 或 sitemap，不等于网站必然无法收录，补齐它们也不保证排名改善。

这套做法适合当作小型网站的交付起点。网站开始保存客户数据或承接更多业务时，验收范围也要跟着扩展。

能拿来做什么

• 接手用 v0 或其他 AI 工具搭建的网站时，先打开控制台和 Network 面板，记录实际调用的数据接口，再检查 Supabase 的 RLS 与表授权。
• 验收联系表单时，用可辨认的内容发送一条消息，并在目标邮箱或接收系统确认送达；把前端成功提示和实际送达分开验证。
• 每次让 Claude Code 或 Cursor 新增数据表，尤其是 newsletter 这类保存用户信息的表，都同时复查访问权限，不能沿用旧表的配置就算完成。
• 给客户交付前，检查页面标题、/robots.txt 和 /sitemap.xml，并留下权限检查、表单送达的验证记录，让「能用」有具体依据。