Vibe coding的阶段性反思

目前我们team采用 vibe coding 的方式，在 Replit 平台上并行开发，整体目标是为后续 Native App 提供可快速验证的功能实现。现阶段已经完成了从 Login 到 Onboarding 的核心闭环，接下来进入大量零散但必要的功能补全阶段。

背景是：由于开发效率开始出现明显瓶颈，因此我们尝试通过多人并行、各自使用 AI Editor 进行 vibe coding 的方式，加快功能上线节奏。我们非常幸运，一开始jing同学给了一个完善的框架，起码代码结构能够保持一致。

这个策略在早期确实显著提升了速度，但在实际推进过程中，也逐步暴露出一系列问题：

0→1 阶段极快，但 1→N 阶段成本急剧上升。在功能从无到有的阶段，通过简单指令即可快速生成可运行的代码与基础 UI，效率非常高。但当进入细节完善阶段后，大量时间被消耗在 UI 微调、不同页面和状态之间的适配，以及反复的 bug 修复上。此时，vibe coding 带来的“快生成”优势明显被“慢收敛”所抵消。

随着代码规模扩大，AI Editor 的整体效率显著下降。代码量增加后，AI 在理解上下文、读取已有逻辑以及生成新内容时明显变慢；上下文越复杂，响应越迟缓，生成结果也更容易出现偏差。

代码的耦合可能存在问题。比如某个功能模块已经测试发布，达到预期状态，很有可能随着某条指令，在毫无察觉的情况下Regression Bug。后期代码管理问题。A和B分别用 AI 生成代码。由于 AI 每次生成的逻辑结构、变量命名风格都存在随机性，当两人修改同一个文件时，Git 会报冲突（merge也会存在风险）。我现在的 branch 下载已经400+M，代码库会越来越庞大。

代码高度依赖 AI 生成，导致结构认知缺失。由于代码生成速度极快，实际操作人员往往对整体代码结构、模块边界以及命名体系缺乏清晰认知，整个代码体系相当于一个黑盒。在下达指令时，容易出现前后逻辑冲突：

• 对 A 功能的描述或修改，意外影响到 B 模块
• 命名不统一，导致相似概念被重复实现
• 修改意图无法被 AI 精准定位，产生“连锁副作用”

只有“happy path”, 缺乏异常处理的逻辑。目前在 replit 测试，和真机测试效果会有明显偏差，尤其是一些UI适配、网路异常、加载问题等情况，排查问题和解决的链路也会比较久。

后期用户量增加后的管理迭代问题目前是每个人自己负责，并且还是比较轻量的代码，因为非传统的项目管理方式（跳过了版本管理、代码审查等流程和PR机制），所以可能存在一些隐患。随着用户使用，反馈的一些迭代需求和bug, 目前每个mini app owner是否有足够能力解决？目前还没有验证。

难以沉淀可复用的工程资产。在完成单个功能后，当前模式下很难将其进一步组件化、模块化，或沉淀为可复用的代码资源。成功的实现更多停留在“能跑”“能用”，而非可被复用、扩展和长期维护的工程资产，这对后续规模化开发和多人协作形成了明显制约。

工程师没有发挥出更大的价值？（technical tutor?）//我是指现在vibe coding和工程师之间是两条互相独立的线，目前是通过SDK来完成一些数据传输，在native app中提供入口和统一的页面，是否可以更深度配合？如果让工程师一直做“擦屁股”的工作，价值低且产出也低，但是在 vibe coding 的某些环节或工程师提供一些规范要求或帮助，可能会明显提高效率。

我想到的一些解决方案，并逐步在团队中使用：

我们可能要尽快建立团队规范。比如devrules 或 magic prompt、design format. 通过强制规范一些命名规范、技术栈，避免AI随机生成太过冗余的代码，也便于团队后期排查问题、进行复制。

在vibe coding前先整理 prompt 文档？包括想要实现的功能、流程、UI要求、交互等。还是先干就完了，有问题再说？这样规范化虽然看起来不错，但是真的有实际价值吗？可以建立一些简单的评审机制，因为vibe coding一旦开始，很容易陷入到AI提供的框架中，聚焦于一些小的问题一个一个去解决，可能有时候会缺乏更全局的思考。可能定期需要一起过一遍 ongoing 的mini app ，大家一起对大的方向提供一些思路。目前采用了一个中间方案，通过weekly catch up，大家可以进行一些discuss和需求评审，决定接下来一个sprint或circle的scope，这样工作更聚焦一些。

工程师提供指导，协助把分支模块化每个人在weekly doc中更新自己mini app的状态和更新情况，需要工程师定期帮忙把每个分支中的无效代码拆除，保持每个人负责的mini app在一个小而干净的状态。

提供的指令在统一平台？我个人习惯是先在gemini中新开一个chat，告诉一些context和要求，然后每次扔给AI问题或想要的状态，AI按照格式发给我，我再扔给AI。这样的好处是gemini有我丰富的上下文，能够清晰了解vibe coding，准确定位到具体的问题。但是随着对话轮数太多，也会时不时加载有问题。

最后可以看到我自己vibe coding 的工作量比例：