AI 构建的 MVP 能交给客户使用了吗？上线前的 12 项检查计划

你的第一个版本看起来很有说服力。你可以展示仪表盘、创建一条示例记录，并一路点击完成结账。更难回答的问题是：一个从未见过你应用的人，明天能否做到同样的事情。这份 AI MVP 生产就绪检查清单正是为填补这一差距而准备的，无论你最初使用的是 Lovable、Bolt、Replit、Base44 还是其他构建工具。

对 MVP 来说，“生产就绪”意味着什么？

一个生产就绪的 MVP 能够稳定地向目标客户兑现其有限的承诺，具备恰当的访问控制，并拥有可行的恢复方案。它不需要包含路线图上的所有功能，也不需要为你尚未拥有的用户规模设计基础设施。

请把以下检查项视为发布证据。对每一项，记录由谁测试、使用的网址和版本，以及测试结果。未经测试的项目标记为“未知”。界面看起来很干净，或者 AI 回复说问题已修复，都不算测试结果。

新用户能否完成核心流程？

新客户应当无需你介入就能获得产品的有用结果。请在已发布的应用上，用一个没有任何既有权限、已保存会话或示例数据的账号测试完整流程。

• 检查 1 — 首次使用：注册账号，如有要求则确认邮箱，创建第一个有用的条目，离开后再返回。记下你不得不口头解释的每一条说明，并据此改进流程或文案。
• 检查 2 — 账号找回：退出登录，在支持的情况下重置密码，点击一个已过期的链接，并在会话结束后重新进入。确认找回流程跳转到正式域名，并且客户可以继续之前的工作。

用户是否只能访问他们应当访问的数据？

身份认证用于识别用户；授权则决定该用户可以访问什么。登录功能正常，并不能证明客户记录、上传的文件或管理员操作受到了保护。

对于使用 Supabase 的应用，其行级安全文档说明了数据库策略如何限制行级访问。请对照你实际的数据归属规则审查具体实现。其他后端也需要按照各自的权限模型进行同等检查。

• 检查 3 — 客户数据隔离：创建两个普通用户，各自拥有一条私有记录。请开发者验证：修改请求中的记录标识符，无法暴露或修改另一个用户的记录。
• 检查 4 — 特权操作：在服务器端确认，普通用户无法给自己开通付费套餐、邀请管理员，或通过猜测网址访问私有上传文件。在未登录状态下再重复一次这项检查。

支付和第三方集成能否经受住故障？

可靠的集成在处理失败和重试时，既不会丢失工作成果，也不会授予错误的访问权限。请核实应用实际存储的状态，而不是凭结账动画来判断是否成功。

如果你使用 Stripe，其 Webhook 文档介绍了异步支付事件、签名验证和重复投递。你的集成应当验证传入的事件，并避免对同一事件重复履约。具体涉及哪些事件，取决于你的支付流程。

• 检查 5 — 支付状态：在支付服务商的测试环境中，测试支付成功、失败、取消和延迟的情况。确认只有在收到相应的、经过验证的服务器端事件时，访问权限才会发生变化。
• 检查 6 — 外部服务故障：在受控测试中，让邮件服务商、AI 服务或其他必需的集成发生故障。用户应当看到可以理解的结果，并有安全的方式重试，而不会产生重复扣款或重复记录。

线上应用能否保存正确的数据？

已发布的应用必须连接到预期的生产数据库，并为客户文件使用持久化存储。预览环境中有数据，并不能证明线上应用采用了相同的配置。

• 检查 7 — 环境隔离：确认每个环境分别使用哪个数据库。确保测试某项功能不会修改线上客户记录，并记录经批准的数据库结构变更如何进入生产环境。
• 检查 8 — 持久化与恢复：保存一条记录并上传一个文件，然后在一次受控的重启或部署之后检查它们是否仍然可用。明确备份由谁负责，并在依赖这套流程之前，用一份安全的副本演练恢复过程。

Replit 在文档中明确说明了开发与生产数据库相互分离。无论使用哪种构建工具，都请问同样几个实际问题：线上数据在哪里？谁可以修改它？我们要如何恢复它？请核实账号实际具备的能力，而不是假定所有平台的行为都一样。

你能否发现故障并恢复某个版本？

需要有人能察觉客户流程出现了失败，并知道下一步该怎么做。错误可见性和恢复流程会让小规模上线的运维变得轻松得多。

• 检查 9 — 有用的错误证据：触发一次无害的测试故障，并找到对应的服务器错误或失败请求。记录时间和操作，但不要记录密码、私密文档或支付凭据。
• 检查 10 — 版本恢复：确认最后一个已知可用的代码版本、谁有权限恢复它，以及它所依赖的数据库变更。恢复代码并不会自动撤销数据变更；请分别演练这两套流程。

产品离开你的演示环境后还能正常工作吗？

面向客户的版本必须能在首批用户实际使用的设备和网络条件下正常运行。请使用贴近真实的内容来检查产品，而不只是简短的示例名称和高速的办公室网络。

• 检查 11 — 日常可用性：在窄屏手机上以及仅用键盘导航的方式完成核心流程。尝试超长名称、空列表、校验错误和中断的上传。让加载状态和失败状态清晰易懂。
• 检查 12 — 预期上线负载：明确首批用户的规模，并用具有代表性的数据量和并发活动进行测试。观察响应时间和资源使用情况。在支持的情况下设置支出上限或告警，并约定在什么情况下需要有人介入排查。

邀请客户之前应该先修复什么？

在扩大用户范围之前，先修复中断的核心流程、错误的付费访问权限以及不当的数据访问。可选功能和外观优化应围绕这些优先事项来安排。

设想一个预约类应用：创始人自己预约一切正常，但新用户无法找回账号，支付失败后仍会生成已确认的预约，而且在两个标签页中可以预订同一个时段。下一个版本应当修复这些路径。增加聊天功能或重新设计仪表盘，并不能解决这些上线阻碍问题。

如果调试本身陷入了停滞，请参阅 Lovable 和 Bolt 修复死循环指南。如果下一步涉及移动端，请查看现有的 Lovable 上架 App Store 指南。如需实际动手的帮助，可以预约通话，探讨如何将你的 MVP 推向生产环境。请带上应用链接和未通过的检查项；我们可以基于这些证据来规划下一个版本的范围。