Vibe Coding 应用为何常在开发的最后阶段难以成为生产级产品？

Vibe Coding 项目常在最后阶段突然变难，不是因为剩余功能数量多，而是因为最后一小段工作集中验证了整个系统。页面能显示、按钮能点击，只证明局部正常；身份、数据、异常、并发、部署和恢复必须同时成立，应用才接近生产级。早期省略的每个约束，往往都会在这里变成跨模块问题。

为什么前 80% 看起来特别快

AI 擅长生成常见页面、表单、导航和标准组件。视觉反馈立即可见，即使数据是模拟的、权限只在前端判断、错误路径尚未实现，演示仍可能非常完整。这会让操作者把“界面完成度”误认为“产品完成度”。

早期需求也通常彼此独立：增加一个卡片、修改文案、添加一个按钮。代理只需在有限文件中匹配常见模式，不必理解系统全部不变量，因此进展迅速。

后端接入为什么改变难度

后端引入持久状态与责任边界。一次创建操作可能涉及验证、权限、事务、唯一约束、审计、通知和缓存失效。任何一步失败都需要确定哪些变化应保留、哪些必须回滚。

AI 若只按当前提示添加代码，容易在不同路由重复实现同一规则，或者让前端和后端对字段含义产生差异。错误不再局限于一个组件，而会沿数据流传播。

“最后 5%”实际包含什么

这部分通常包括空数据、重复提交、慢网络、依赖超时、权限拒绝、并发更新、时区、分页边界、文件限制、支付回调、迁移失败和部署回滚。每项代码可能不多，却要求理解之前所有决定。

还包括可观测性、备份、速率限制、安全响应头、密钥轮换、无障碍、浏览器兼容和用户支持信息。这些能力在演示截图中不可见，但真实用户遇到故障时决定产品是否可靠。

未真正连接的功能为何很晚才暴露

代理可能创建了按钮和接口，却没有保证参数一致；创建了后台页面，却仍读取模拟数据；增加了套餐限制，却只在客户端隐藏功能；展示了成功提示，却没有确认数据库提交。每个局部看起来合理，端到端路径却是断的。

因此验收单位不能是文件或页面，而应是用户结果。选择一位用户，从入口开始完成任务，检查服务端状态、数据持久化、再次登录后的结果和失败反馈。

边界条件会成倍放大组合

字段有空值和非空两种状态，用户有多个角色，订阅有试用、有效、欠费和取消状态，数据又可能新建、处理中或失败。状态组合很快超过人工逐一点击的能力。

没有明确状态模型时，AI 会为新需求添加更多布尔字段和分支，产生互相矛盾的组合。应把核心实体状态画成有限集合，定义允许的转换，并让数据库和服务端共同约束。

为什么连续提示修复会越来越慢

每个临时修复都会增加代理下次必须理解的上下文。若没有测试和架构约束，代理可能修复当前页面，却改变共享组件或复制另一套逻辑。之后再修回归，代码继续分叉。

当同一问题连续修复两三次仍复发，应停止追加提示。先要求代理复现问题、写失败测试、追踪数据流并列出根因，再做最小修改。无法解释根因的成功刷新不是稳定修复。

在项目开始时定义完成标准

每项功能都应同时包含正常路径、失败路径、权限、数据变化、日志和测试。例如“导出订单”不只是下载按钮，还要规定谁能导出、最大范围、字段脱敏、无数据结果、生成失败和审计记录。

将这些标准写入任务，而不是在最后统一补齐。AI 生成第一版时就能围绕真实边界设计，减少后期跨层返工。

按垂直切片开发

不要先生成所有页面，再统一接后端。选择一个最小用户任务，从界面、路由、业务逻辑、数据库到测试一次贯通。完成创建后再做读取，完成一种角色后再扩展权限。

垂直切片能提前暴露环境、数据和部署问题。即使项目停止，已经完成的路径仍是可工作的产品，而不是大量未连接页面。

建立四层测试门槛

单元测试保护状态转换、金额、权限等核心规则；集成测试验证数据库、队列和外部接口边界；路由测试检查请求、响应与身份；浏览器测试覆盖少量关键用户路径。每修复一个真实缺陷，都应增加能复现它的测试。

测试必须在干净环境运行，并且确实会在实现损坏时失败。只测试组件是否渲染、状态码是否为 200，无法证明数据和权限正确。

把审查放在开发过程中

原帖建议结构化工作流与代码审查。审查不应只在上线前进行，因为此时改动面最大。每个垂直切片完成后，检查重复逻辑、错误处理、权限位置、查询边界、依赖来源和测试缺口。

自动审查工具可以发现常见问题，但不能决定产品业务规则。高风险逻辑需要了解领域的人确认，安全、支付和隐私还需要相应专业审查。

设置停止编码的触发条件

出现以下情况时暂停新功能：同一错误反复出现；修改一页破坏无关页面；数据模型无人能解释；测试无法在干净环境通过；部署依赖手工操作；生产与开发配置明显不同。

暂停阶段先建立系统地图，列出入口、数据表、外部服务、权限和后台任务；删除重复实现，补充测试，再继续。短期看似减速，实际上是在降低每个后续修改的风险。

重构还是重写

如果核心数据模型正确、关键路径可测试、依赖可替换，通常可以逐块重构。先把业务规则从页面抽出，统一数据访问和错误模型，再清理组件。不要让 AI 一次性改写整个仓库。

只有当项目没有可验证行为、数据结构与需求根本冲突、依赖平台无法继续使用，或修复成本已明显高于按已知需求重建时，才考虑重写。重写前先保留验收测试，否则新版本会重复旧错误。

生产前的最终证据

核心流程应在生产相似环境自动通过；权限必须由服务端验证；数据有备份和恢复演练；外部服务有超时、重试和降级；错误能被监控；部署可回滚；依赖和密钥有明确管理方式。

再由少量真实用户完成任务，观察失败率和支持请求。没有这些证据，“最后 5%”就仍未完成，无论页面看起来多精致。

Vibe Coding 并非只能制造演示。问题来自把快速生成当作完整交付。将边界条件、垂直切片、测试和持续审查提前，最后阶段就不会突然承受所有被推迟的工程成本。AI 仍能保持速度，但每一步都要以可验证的用户结果为完成标准。