Vibe Coding 能否构建已经稳定运行的真实应用？

Vibe Coding 能构建稳定运行的真实应用，但成功更取决于项目形状，而不是所用工具名称。一支团队公开复盘了十个 AI 参与项目：小范围、单一流程、全新代码库的项目表现较好；多状态、旧系统迁移和实时通信项目更容易失控。这是团队自报经验，不是行业成功率统计，却提供了有用的项目筛选方法。

先定义“稳定运行”

稳定不等于某次演示成功。应用应在目标用户和真实环境中持续完成任务，依赖短暂失败时有降级，数据保持一致，修改后不会频繁破坏旧功能，并且有人能处理故障。

内部小工具即使只有十几位用户，只要持续解决真实流程、没有反复工单，也可以是稳定产品。相反，拥有漂亮界面和大量功能但无法处理断网、重连或数据冲突的应用仍只是演示。

成功案例的共同形状

团队自报的内部报销工具只服务一个清晰流程：读取收据、识别内容、分类并导出财务可用文件。开发前写了短规格，开发者决定结构，代理完成大量样板。它服务 14 位内部用户，并被描述为连续四个月没有工单。

另一项成功是单页婚礼 RSVP：界面范围小，只有表单和一次数据库写入，113 位来宾完成提交。营销站和每日站会机器人也属于清晰边界问题。共同点是用户、输入、输出和“完成”都容易说明。

小表面面积为何重要

表面面积不只指页面数量，还包括状态、角色、数据表、外部集成和并发行为。四个页面与一个数据表的应用，组合状态远少于八个页面、离线状态、同步状态和通知平台共同存在的应用。

每新增一个连接点，代理都要同时保持两侧契约。局部代码可能正确，连接处却出现字段、时间、权限或重试不一致。项目评估应数“连接点”，而不只是功能列表。

明确规格比长提示更重要

表现较好的项目在开始前知道“完成是什么”。一页短规格应写用户、核心路径、数据、失败行为和明确不做的内容。代理可以据此生成实现，审查者也能判断是否偏离。

报销工具仍出现了一个典型问题：代理自行设计的分类不符合财务人员习惯。领域术语、分类和规则必须由真实使用者提前提供，不能让语言模型凭常见模式猜测。

全新项目通常优于旧系统改造

全新项目的约束能写进代码和文档，代理容易建立一致模式。旧系统则包含多年例外、历史字段和只存在于员工经验中的规则。即使代理能阅读整个仓库，也无法读取未记录的业务历史。

复盘中的大型 CMS 迁移要处理约 48 万篇历史内容。前 80% 的解析与搬运很快，但年代不同的作者字段、视频格式和分类合并规则导致边界不断出现，最终团队重建核心迁移方案。适合 AI 的部分是明确映射和解析器，不适合让代理独自决定历史语义。

多状态同步是高风险信号

失败的习惯追踪应用需要协调本地乐观状态、后端状态和界面状态。新功能不断引入不同同步方式，冲突处理无法组合。此类问题需要先设计单一事实来源、允许的状态转换和冲突策略，再让 AI 实现。

如果无法回答刷新、离线、重复提交、跨设备修改和恢复连接后以谁为准，就不应继续堆叠功能。先建立状态模型与测试。

实时系统需要先设计失败行为

工作坊聊天应用首日就能展示消息和表情，但移动设备休眠、网络波动与 WebSocket 重连在真实条件下暴露问题。正常连接只是一种状态，生产还要处理断开、指数退避、消息去重、顺序、丢失和恢复。

实时、离线、多设备或高并发项目不是不能使用 AI，而是必须由了解协议和状态的人先定义架构与测试。代理适合实现明确协议，不适合从一次成功连接推断全部行为。

集成工具能显著改变成本

站会机器人借助已有的官方集成工具快速完成 API 连接，说明可靠工具和文档可以缩小代理猜测空间。但它仍把摘要模型放在关键路径且没有降级，上游故障时机器人静默停止。

任何外部服务都要定义超时、重试、配额和替代输出。摘要失败时至少发布原始汇总，通常比完全无结果更好。集成成功不等于依赖故障已处理。

小步提交提高可恢复性

个人财务看板采用每项变化单独提交的方式，外部银彳响应异常时可以快速恢复到上个版本。版本控制让试验成本可控，也让审查者看到代理究竟修改了什么。

但案例同时承认缺少测试导致维护者不敢继续修改。提交能恢复代码，测试则能判断恢复或新改动是否保持行为。第二项功能开始前补测试，是合理的进入门槛。

用三色规则筛选项目

绿色项目是全新、小范围、单一路径和低故障影响，可以让代理承担大部分实现。黄色项目是旧代码但边界清晰，或包含少量关键集成，需要资深人员参与规格、架构和连接处审查。

红色项目包括历史数据复杂迁移、实时关键系统、多种同步状态、高风险支付或受监管数据。应先由人建立架构与验证方法，再把局部明确任务交给代理。

上线前验证真实条件

用目标规模的数据测试查询和列表，用慢网络、离线恢复和移动后台测试交互，用两个不同角色佼叉验证权限。模拟上游超时与限流，检查应用是否降级。让真实用户完成任务，而不是只由创建者演示。

同时建立日志、错误报警、备份和责任人。所谓长期稳定，包含故障发生后能够发现、定位和恢复，而不是永远没有错误。

如何让 AI 项目保持可维护

把规格、数据模型、架构边界和运行命令保存在仓库。明确哪些模块由人设计、哪些可以自动生成；高风险连接处要求额外审查。每次修改先添加或更新验收测试，再提交小范围差异。

季度或阶段性复盘全部项目，记录成功、返工和放弃的真实原因。团队自己的数据比网络上的成功故事更能帮助下一次选型。

结论是，Vibe Coding 已经能够交付真实、持续使用的应用，但最合适的是问题清楚、表面面积小、连接点少、故障影响可控的项目。项目越接近历史数据考古、复杂状态同步或实时关键系统，就越需要先有人负责架构。AI 能快速建好每个局部，稳定性来自人对局部之间关系的设计和验证。