从 Lovable 和 Cursor 原型到生产：迁移清单

Lovable、Cursor、Claude Code、Bolt、v0 和 Replit 等 AI 辅助构建工具可以缩短做出可点击产品的路径。这是实在的进展，但 "demo 能跑" 并不能证明 "真实用户可以依赖它。" 生产就绪是一组独立证据，其范围取决于架构、数据、威胁、法规和潜在损害。这是原型走向生产时的首轮清单。

这不是在挑工具的毛病，工具名称也不能决定系统能否用于生产。Lovable 和 Replit 都记录了生产部署能力；Lovable 还记录了 GitHub 同步、安全审查和后端秘密信息存储。应核验确切套餐和架构。无论代码由 AI 还是人编写，这份清单中的控制都需要证据。

用 AI IDE 做了一个原型？

预约一次生产就绪评审

"生产" 到底意味着什么？

Demo 可以提供想法与交互可行的证据。生产就绪意味着定义服务和风险目标，再收集系统达到目标的证据。它不是普遍保证或单一认证。

授权。对每项受保护操作和数据对象，在可信执行点验证身份与权限。
数据完整性与恢复。需要时采用事务行为、版本化变更、明确恢复目标、受保护备份，以及经过测试的恢复与对账。
可靠性。让容量、失败处理、依赖行为、部署安全和恢复匹配明确服务目标。
安全。机密凭据远离不可信客户端，验证信任边界，维护组件，并按威胁模型设置控制。
可观测性。提供适合团队检测故障与调查的日志、指标、追踪、告警和保留策略。
支持。明确负责人、runbook、升级路径和足够审计上下文，避免靠猜。

原型可以展示有用行为，却不一定为以上所有方面提供证据。因此 demo 是生产就绪决策的一项输入，而不是终点。

第 1 步：怎么锁死认证与数据访问？

登录页证明认证流程，不证明授权。对每项受保护操作和对象，测试换成其他用户、租户、角色或标识符后是否被拒绝。客户端隐藏可以改善体验，但 OWASP 明确指出它不能成为决定性访问控制。

应在控制受保护操作或数据的可信服务层执行授权。它可以是 API、gateway、serverless function 或数据库策略，不一定是传统服务器。多租户系统应集中执行租户与行隔离，并直接测试跨租户访问。Row-level security 很有用，但仍需要正确策略和验证。

第 2 步：能否运营并恢复数据层？

不要仅因数据服务通过原型工具连接就迁走。Lovable 记录了托管后端集成与 Lovable Cloud；Replit 建议使用持久数据库或存储服务，因为已发布应用的文件系统不持久。若所有权、访问、容量、保留、导出、删除、备份和恢复满足要求，就可以保留。

在平台支持迁移时版本化 schema 变更，并为数据库、对象存储、身份配置、秘密信息和基础设施状态定义恢复目标。启用所需备份或时间点恢复，并测试恢复与对账。Supabase 明确记录数据库备份不包含 Storage 对象或全部服务配置，因此应测试完整恢复范围。

第 3 步：密钥与环境

移动凭据前先分类。公共标识符和可发布密钥可以用于不可信客户端，但特权 API 密钥、服务凭据、签名材料和 bearer token 属于机密。将机密值存入平台后端秘密信息设施或批准的管理器，授予最小权限，并使其远离 bundle、日志、构建产物、提示词和仓库历史。

按风险隔离开发、测试或 staging 与生产，并使用不同凭据和适当隔离的数据。Lovable 的 Test 与 Live 环境目前不向新 Cloud 项目开放，因此应确认确切项目是否具备，或通过后端和交付流程实现隔离。把暴露的机密凭据视为已泄露，撤销或轮换并检查下游 token、日志和缓存。工作量因凭据与依赖而异。

第 4 步：托管、CI/CD、回滚、可观测性

捆绑托管并不自动意味着不适合生产。Lovable 记录了永久发布、自定义域名、访问设置、安全检查和通过 GitHub 外部部署；Replit 记录了 Autoscale 与 Reserved VM。针对确切套餐核验容量、区域、持久存储、网络控制、部署身份、环境隔离、域名所有权、备份、回滚或向前恢复、支持、可移植性和服务目标。仅在现有平台不满足要求时迁移。

按风险自动化可重复的构建、测试、批准和部署步骤。测试失败发布及所选回滚或向前恢复路径，不要承诺未经测量的恢复时间。按调查需要增加日志、指标、追踪、错误监控、可用性或合成检查、告警和 runbook。日志可能含敏感值，因此也要保护可观测数据。

第 5 步：生成的代码什么时候保留，什么时候重建？

并非所有生成的代码都得扔掉，也并非所有都值得留下。应判断问题位于何处：有些缺口可以局部修复，另一些则跨越数据模型、安全或部署边界，需要更大范围的替换。

如果数据模型、边界、依赖、可维护性、可测试性和部署模型可通过适度变更达到目标，就保留地基。如果原地修复带来的迁移风险、重复补救或长期运营成本高于受控替换，就重建或替换核心层。应依据仓库与架构证据、依赖图、迁移计划、验收测试、回滚路径和生命周期成本决定。

"原型是有价值的证据，不是生产就绪证明。保留达到目标的部分，替换未达到目标的部分，并根据架构和测试而不是工具名称决定。"

要多久，要多少钱？

不存在可靠的统一工期或价格。范围取决于架构、代码与依赖质量、迁移约束、测试覆盖、数据敏感性、资金流、集成、法规、暴露面和服务目标。狭窄内部工具与处理付款或个人数据的公开产品需要不同证据和补救。

估算前，我们会审查仓库、已部署架构、数据流、平台配置和现有证据。首个结果应说明定向加固、部分替换还是核心重建风险更低，并明确假设与验收标准。详细工作见我们的软件 QA 服务，失效模式见AI 生成代码的 QA。

最终思考

快速原型是有价值的证据，但生产就绪是独立的风险决策。不要因构建工具名称决定保留或替换某一层。应核验授权、恢复、机密秘密信息、环境隔离、部署安全、可观测性、支持和确切平台套餐。

记录证据和未满足目标，再选择定向加固、部分替换或核心重建。涉及敏感数据、资金、特权操作或安全关键结果时应独立审查，并在架构或供应商能力变化时重新评估。