用 Vibe Coding 快速撸 30 个 App 后的血泪教训：AI 降低了代码门槛却没降低产品门槛
在这种纯靠 Prompt 堆砌的开发模式下，项目在初期验证阶段速度快得惊人，但一旦用户量稍微增加或功能复杂度提升，代码库就会迅速崩塌。因为 AI 在生成代码时，经常会在不经意间引入一些难以察觉的逻辑漏洞，这些漏洞在简单的 Happy Path 测试中根本发现不了，但到了生产环境下就是致命的 Bug。
为了让后续的项目不再重复踩坑，我总结了三套在 Vibe Coding 模式下必须强制执行的实战准则。
首先是必须强制 AI 编写测试用例。很多开发者习惯于让 AI 写完功能后直接运行，只要界面没报错就认为完成了。这其实是最大的误区。我现在的流程是：在让 AI 实现任何核心逻辑之前，必须先让它写测试脚本。比如在处理订阅过期逻辑时，我会强制它生成 Jest 测试代码，像这样：test('should calculate subscription expiration correctly', () => { const date = new Date('2023-01-01'); expect(calculateExpiry(date)).toBe('2023-02-01'); });。只有通过了测试用例的代码才允许进入主分支，否则 AI 告诉你“这段代码没问题”这句话完全没有参考价值。
其次是坚决拒绝“单文件巨兽”。AI 非常倾向于为了方便展示而把所有逻辑写在一个文件里，这导致很多项目在迭代到中后期时，文件长度轻松突破 500 行。在这种结构下，你让 AI 修改一个 Bug，它可能会在不经意间破坏另外三个原本正常的功能。为了避免这种情况，我在提示词中加入了极其严格的约束：要求每个组件代码绝对不能超过 100 行，且必须强制执行逻辑层与 UI 层的分离。所有的 API 调用必须统一封装在 services/ 目录下，禁止在组件内直接写 fetch 或 axios 请求。
最后是关于状态管理的陷阱。在快速迭代的 Vibe Coding 过程中，AI 为了追求速度，往往会倾向于使用最简单的全局变量或者通过 Prop 深度传递数据。在我的 30 个项目中，这种做法导致了无数次难以追踪的状态同步问题。现在的经验是，无论项目规模多小，只要涉及跨组件的状态共享，必须强制要求 AI 使用 Zustand 或 Pinia 这样的状态管理库。只有这样，在追踪数据流向时才不会陷入混乱。
总结这次经验，Vibe Coding 极其适合用来快速验证产品原型（MVP），但如果你的目标是让项目进入 Production 环境，绝对不能完全交给 AI。在 AI 生成代码后，开发者必须扮演“架构审计师”的角色，手动介入并对代码结构进行审视，否则你构建的不过是一座随时会坍塌的沙堡。
