Vibe Coding 的隐藏成本：多人协作时代码一致性问题

场景

周五下午。一名开发者打开 Cursor，输入三条 prompt 迭代，构建出一个精致的控制台 Dashboard，包含流畅的图表、筛选和动画。

周一到来。另一名开发者进入代码仓库，用 Bolt.new 添加一个用户设置模块。

到了周三，又有人重构了导航。

两周后，每个独立功能单独看都正常运作，但整个项目却出奇地割裂。每个页面的按钮加载状态各不相同，验证流程各行其是，间距也不协调。

AI 生成的代码并不差。问题在于，没有人能两次生成同一个应用。

Vibe coding 无疑是有趣的、赋能的，对快速原型开发具有变革性意义。但当你从快速验证转向构建生产软件时，依赖 prompt 会引入隐藏成本，这些成本会在日后拖累团队的velocity。

Vibe Coding 追求速度，而非一致性

当使用 Cursor、Lovable、GitHub Copilot 或独立的生成式工具进行 AI 编程时，模型并不会自然地针对你的长期软件架构做优化。它只针对你 prompt 中的下一个最合理的实现做优化。

没有严格约束的情况下，AI 生成的代码会产生：

• 不同模块间的文件夹结构各异；
• 碎片化的命名规范；
• 不一致的组件组合；
• 分歧的状态管理方式（例如：无差别地混用 Zustand、React Context 和本地 state）；
• 不同的 UX 假设。

虽然采用 AI 辅助开发方法在初期原型速度上带来了不可否认的提升，但研究也揭示了其中的权衡。

虽然 AI 加速了即时输出，但它大幅增加了代码更替和重复，同时减少了有意义的重构。例如，DORA 报告中关于 AI 辅助软件交付的研究表明，如果没有强有力的架构控制，AI 开发可能会造成"加速的混乱"，从而降低发布稳定性。

架构不会在一夜之间崩塌

生产就绪的软件很少因为某一次灾难性的 PR 就崩溃。它是缓慢地漂移的。考虑一个典型的现代 React 和 TypeScript 项目在快速 AI 辅助编码下的情况：

• 页面 A：AI 用浮动 Modal 渲染编辑详情。
• 页面 B：AI 对同样的交互模式实现了一个 slide-over Drawer。
• 页面 C：AI 将用户路由到一个独立页面来处理同样的流程。

三个页面都解决了底层的业务需求。但你的 UI/UX 已经碎成了碎片。

LLM 没有犯错。它只是对之前在不同文件中做出的决策没有架构记忆。

在 Google 担任工程负责人 14 年的 Addy Osman 把这种现象称为理解债（Comprehension Debt）：我们部署的生产中 AI 生成代码量与开发者实际理解其结构关系的深度之间，差距越来越大。当团队积累了工程师所说的意图债（Intent Debt）时，他们便丢失了为何做出特定前端架构选择的线索，使长期软件可维护性变得极具挑战。

隐藏成本是 UX 碎片化（实战案例）

当你继承在早期验证热潮中构建的遗留代码库时，vibe coding 的问题变得痛苦而明显。

在一个真实场景中——某医疗管理软件现代化项目——一个早期阶段用轻量级 AI 工作流快速构建的医疗平台。目标是经典的 vibe coding 对阵生产开发：快速验证想法，将可用的界面放到关键干系人面前。

起初，速度看起来令人惊叹。但随着平台增长，微妙的不一致结构开始累积：

• 相似操作在不同屏幕上产生了完全不同的行为。
• 导航模式在不同功能团队间独立演化。
• 相同的数据对象使用了完全不同的布局规范。
• 组件样式逐渐分化，导致严重的 CSS 膨胀。

这些问题都没有严格意义上让应用崩溃。但它们一起造成了严重的 Technical Debt。

当现代化工作开始时，工程团队大部分时间不是在写全新的逻辑，而是在恢复基本结构一致性。这意味着要引入统一的设计系统、提取共享组件库，并建立连贯的交互规则。

讽刺的是，原始代码运行良好。缺失的软件工程架构才是真正的瓶颈。

生产软件需要共享规则

如果你想知道如何安全地使用 vibe coding，秘诀在于界定 AI 生成从何处开始、人为架构从何处接管。为了交付生产就绪的 AI 代码，模型必须在定义的 guardrails 内运行，而不是在每次 prompt 时都发明新规范：

• 强制执行设计系统：要求 AI 消费现有的 UI 组件，而不是从头开始为内联元素设置样式。
• 建立严格规范：使用自动化 linter、严格的 TypeScript 配置和清晰的 file-tree 标准。
• 维护架构决策记录（ADR）：在 prompt 上下文中输入明确的定义，说明状态管理和 API 获取在整个代码仓库中如何处理。
• 实施严格的代码审查：对 AI 的 PR 采用与任何不可信外部代码提交同等的审查标准。

像对待初级开发者一样使用 AI

有效 AI 开发工作流的一个有用的心智模型很简单：把 AI 工具当作一个极其快速、超级积极的初级开发者。

AI 适合做的事：

• 生成初始样板代码和功能脚手架；
• 探索替代算法实现；
• 重构重复代码片段；
• 编写基线单元测试。

人类工程师必须掌控的事：

• 定义整体软件架构和系统边界；
• 建立直观、统一 UX 模式；
• 强制执行长期代码一致性；
• 审查边界情况、安全性和性能；
• 为生产可靠性负责。

Vibe coding 非常适合探索你的产品可以变成什么。软件工程则是在决定它应该变成什么。

像 Cursor、Claude Code 和 Copilot 这样的工具让创建原始功能变得显著更快。但这种速度将软件创建的主要瓶颈从打字速度转移到了架构一致性上。

归根结底，用户体验的不是你的 prompt。他们体验的是一个统一的应用程序。