你可能已经借助AI工具完成了页面、后台和一个能跑的演示流程。演示时一切顺利，但一想到真实客户、支付、数据和长期维护，心里就发虚。这篇文章不讨论"AI写的代码好不好"，而是回答一个更实际的问题：一个演示原型要变成能交给真实用户使用的产品，中间还缺什么。
一、先分清：你拥有的是原型，还是产品
最近半年，我们接触了不少拿着AI生成原型来找团队继续开发的客户。他们对项目状态的描述高度相似——"基本做完了，就差上线了"。但实际评估下来，"差上线"三个字背后，往往差着两三个月甚至更久的工程工作。
先说一个容易混淆的点：AI生成的软件不一定包含AI功能。它可能只是一个普通的预约系统、会员管理或后台工具，只是代码由AI辅助编写。真正调用大模型、检索知识库或执行自动化任务的软件，还有额外的运行与效果责任。
两类项目的共同基础是数据、权限、接口和可维护性；差异在于AI类软件还要管理模型账号、调用费用、提示词和知识版本。评估的时候先把这两件事分开，不然容易用普通软件的验收标准去套AI功能。
评估项目状态时，建议给每个功能模块标记三种状态：
| 状态 | 判断标准 | 对应的证据 |
|---|---|---|
| 已验证 | 在隔离环境真实跑过，数据持久化正常，角色隔离有效，失败可以恢复 | 测试记录、操作日志、数据快照 |
| 可见但未验证 | 界面能点开，但重启后数据还在不在、权限有没有生效，没人测过 | 界面截图、演示视频 |
| 仍缺材料 | 连完整源码、数据库结构或构建方法都拿不齐 | 无，只有口头描述或预览链接 |
核心区别只有一句话：界面能点开属于"可见证据"，重新启动后数据还在、失败可以恢复才属于"运行证据"。 这是两个完全不同的概念。我们评估过的项目里，十有八九的状态是"页面都能点开，运行证据几乎没有"。
很多项目看着完成了八成，实际上一测就是支付回调没处理、权限一捅就穿、数据迁移从来没试过。没有统一的验收范围时，任何"完成度百分比"都是拍脑袋。比较诚实的做法是：不说"完成了百分之几"，而是说"哪些业务闭环已经验证过、哪些还没有"。
二、一个真实的评估案例（脱敏）
讲一个具体的例子，比抽象讲原则好理解。
客户带着一个"基本完成"的会员预约系统来找我们，AI辅助开发，前后端加起来据说花了两周。演示的时候很流畅：注册、登录、选服务、约时间、取消预约，全程没有卡顿。客户的想法是"再花一两周打磨一下就能上线收费了"。
我们花了一周做了全面评估，发现的问题按严重程度列出来：
| 级别 | 问题 | 后果 |
|---|---|---|
| P0 | 数据库连接串和管理员密钥写在前端代码里 | 任何人打开页面就能拿到数据库直连权限 |
| P0 | 取消预约的接口没有校验用户身份，传个ID就能取消任何人的预约 | 恶意用户可批量破坏他人预约 |
| P1 | 预约时间冲突没有服务端校验——前端提示了冲突，但直接调接口就能绕过 | 同一时段可以重复约到多个客户 |
| P1 | 订单金额在前端计算，后端直接信任前端传过来的价格 | 改个请求参数就能0元下单 |
| P2 | 没有数据库迁移脚本，表结构靠手工建 | 换环境部署时没人能保证结构一致 |
| P2 | 无任何日志和错误监控，出错只有前端白屏 | 线上问题无法定位 |
演示流畅的原因很简单：所有流程走的是"顺利路径"——正常注册、正常预约、正常取消。一旦有人不按套路出牌，系统就露出原形。这六个问题里，两个P0不修就不能上线，两个P1不修就会直接产生业务损失。
最后客户的选择是：保留已经跑通的业务逻辑和页面（这部分AI生成的质量其实不差），由我们团队补齐权限、校验、迁移脚本和监控。总工作量六周。客户最初的预期是"两周打磨上线"，现实是六周——但这是有依据的六周，不是拍脑袋的六周。
三、接管前先保全资产，限制操作范围
如果项目要交给新团队继续开发，第一件事不是动手改代码，而是保全资产。这个顺序很重要——我们见过不止一次，新团队上来就改代码，结果把仅有的运行证据也改没了，最后谁也说不清原来是什么样。
保全清单：
- 保留代码、数据库和运行配置的当前版本快照（代码打tag、数据库做全量备份、配置文件归档）
- 记录生产环境、域名、云服务账号、第三方依赖的完整清单——谁的名字注册的、在哪个平台、能不能登录
- 确认委托方对代码、数据和商业组件都有使用授权；缺源码或授权的部分单独列为待确认，不混在整体结论里
- 测试用隔离环境和脱敏数据，不在生产数据库上反复试错
一个高频安全问题值得单独说：密钥暴露。AI生成代码时，开发者经常图省事把数据库密码、第三方API Key直接写进代码，甚至把代码截图发给别人看。处理方式不是从最新文件里删掉就完事——只要暴露过，就应该按授权流程轮换密钥，并核查历史使用范围。Git历史里的密钥也要处理（清理历史或者作废密钥，推荐后者）。
账号控制权的原则是：云服务、域名、支付商户等关键账号尽量由客户主体持有，实施人员使用最小权限的独立身份。 客户把主账号密码给外包团队是常见做法，但一旦合作结束或者产生纠纷，账号归属就是麻烦。从第一天起就分开，后面省很多事。
四、沿业务闭环查假数据和缺失校验
AI生成页面的通病前面提过：界面显示成功，不代表后端真的做了正确的事。前端写死状态、本地模拟数据、按钮点下去没调接口——这些在原型里比比皆是。检查的方法不是看代码（太多了），而是沿业务闭环逐个环节验证。
以一个订阅型产品为例，完整闭环是：注册 → 登录 → 选套餐 → 付款 → 获得权益 → 使用额度 → 取消订阅 → 核对账单和权限。每个环节要问的问题：
| 环节 | 关键问题 |
|---|---|
| 数据保存 | 数据写在真实数据库还是前端内存？重启服务后数据还在吗 |
| 支付确认 | 谁确认付款成功？有没有服务端验签，还是前端返回一个"支付成功"就算数 |
| 重复回调 | 支付回调重复推送怎么处理？用户连点两次支付会不会扣两次钱 |
| 参数篡改 | 客户端能不能自己改套餐？改价格？接口有没有服务端校验 |
| 取消订阅 | 取消后扣费真的停了吗？权益真的回收了吗 |
除了顺利路径，边界场景也要过一遍：不同用户之间数据是否隔离、并发提交会不会产生脏数据、网络中断时状态是否一致、过期链接和无权限请求能否被正确拒绝、数据为空时页面会不会崩。
两条特别容易自欺欺人的判断：前端隐藏了管理员按钮，不等于接口做了鉴权；数据库有租户字段，不等于所有查询都做了隔离。 验证方法也简单——不登录直接调接口，用A账号的token调B账号的数据接口，一试便知。
五、用模块证据决定：复用、修复还是重构
评估完之后做决策，不要走两个极端。一个极端是"AI生成的代码全部重写"——有些模块写得不错，重写纯属浪费。另一个极端是"已经花了这么多时间，凑合着用"——核心设计有硬伤的话，越凑合后面越贵。
按模块证据分类：
| 结论 | 判断依据 | 后续动作 |
|---|---|---|
| 可以复用 | 可构建、可测试、边界清楚、满足需求 | 补测试后直接使用 |
| 可以修复 | 缺少参数校验、迁移脚本、日志或错误处理，但核心逻辑正确 | 列出缺口清单，逐项补齐 |
| 需要重构 | 核心数据模型不符合业务、依赖无法授权、租户边界无法隔离 | 局部重构，保留原行为记录和迁移校验方法 |
对每个模块记录：继续使用的依据、已知缺陷、外部依赖、修复方案和测试成本。这份模块评估表有两个用途：对内，它是修复工作的排期依据；对外，它是跟客户解释"为什么还要花这么多时间"的沟通工具。客户看到的是具体模块的具体问题，而不是一句"代码质量差"的笼统结论。
六、如果产品包含AI功能，还要补这些
如果原型里真的集成了大模型能力，在前面的基础上还要加一套AI特有的工程要求：
- 密钥不外露：模型调用必须走受控后端，供应商密钥不能出现在浏览器端。AI生成代码时特别喜欢把Key写在前端——这是最先要检查的
- 调用限制：按用户或租户限制可调用的模型、工具权限、次数和预算。别让一个用户刷爆你的API账单
- 成本监控：观察超时、重试和成本异常。AI调用失败后的自动重试如果没上限，一个Bug就能跑掉几千块
- 权限继承：知识检索要继承业务权限。用户不能通过巧妙的提问方式，拿到无权查看的文档内容
- 高风险动作加审核：AI建议修改数据、对外发消息或生成正式报价时，必须有人工确认环节。不能因为"模型输出的参数看起来合法"就直接执行
- 版本化：提示词、知识处理流程、工具定义、模型选择、评测集全部纳入版本管理。AI系统的"代码"不止是代码
- 降级路径：供应商不可用时要有暂停、降级或人工处理路径，保留正在执行任务的状态
特别提醒一句：软件功能正确不代表回答质量稳定，模型答得好也不代表支付和权限可靠——两条测试线要分别验收。 见过不少项目把功能测试过了就以为万事大吉，结果上线后模型输出质量漂移，比接口报错更麻烦——接口报错至少会暴露，回答质量下降是静悄悄的。
七、上线前演练：构建、迁移、恢复
最后一个硬性要求，也是最有说服力的可维护性测试：由没有参与原型编写的人，在一个全新环境里按文档独立完成部署。
接手人照着文档能装起来、能构建、能迁移数据库、能跑通关键测试——这个项目才具备"可接管"的条件。如果只有原作者能在自己电脑上把它跑起来，那这个软件其实是"个人电脑上的临时作品"，不是"可以交付的资产"。
上线演练清单：
| 演练项 | 要求 |
|---|---|
| 从零构建 | 装依赖、构建、配置、迁移数据库、跑关键测试，全程按文档操作 |
| 配置管理 | 环境变量记录名称和用途，真实密钥不进公开文档 |
| 环境隔离 | 测试账号与生产账号隔离，日志脱敏 |
| 监控备份 | 监控告警、备份策略、故障联系人确认到位 |
| 数据恢复 | 数据库升级前先验证备份可恢复 |
| 回滚方案 | 代码回滚了数据库未必能回滚——结构变化或新写入数据时，准备恢复或向前修复路线 |
| 试运行 | 先用少量用户试运行，保留人工处理入口 |
CI通过只说明既定测试通过，测试覆盖不到的业务仍然需要人工复核。只把项目从开发电脑搬上云服务器，不叫生产化完成。
八、交接的交付物清单
一个能被独立接管的项目，交付物至少包括：
- 资产清单：代码、数据库、配置、账号、许可证的完整登记
- 构建记录和部署文档：从零构建的全过程记录
- 核心路径验证记录：哪些业务闭环已验证、哪些待验证
- 缺陷分级清单：按P0/P1/P2分级，附复现步骤和修复状态
- 修复代码和迁移脚本：本轮修复的内容和数据库变更脚本
- 测试集和回归记录：可以反复执行的测试用例
- 遗留风险说明：暂时不能处理的事项，注明责任人和补齐条件
- 含AI功能时：提示词、知识配置、工具权限、运行限制、评测配置
合同和付款节点应该对应这些可复核的成果，而不是代码行数、演示次数或"用了多少AI工具"。费用建议区分几个层次：诊断（摸清现状）、修复（补必要的工程缺口）、必要重构（高风险模块）、生产部署（上线演练）和持续维护（长期运营）。
项目结束时的最终验收动作：由接手人独立部署一次，并处理一次模拟故障，核对仓库、账号与数据的控制权全部交接。能完成这样的交接，才说明原型正在成为可持续的软件产品，而不是依赖某个开发者个人电脑上的环境。
这篇文章的框架参考了 知华科技关于AI原型接管与生产上线的完整指南，原文对诊断、修复、重构和交接的分层更细，还附了常见问题解答。如果你也有AI生成的原型想继续推进，或者需要评估现有代码的接管可行性，可以在 zhuatech.cn 找到对应的诊断服务和项目接管方案。
本文案例为脱敏示例，用于说明评估方法，不代表任何具体项目情况。
