Vibe Coding：快速原型与工程化的平衡

过去一段时间，我确实用 vibe coding 很快生成了一些项目。
一开始看，效果很刺激。想法可以迅速变成原型，issue 可以快速推进成代码，很多以前需要几周才能堆出来的东西，现在几天甚至几个小时就能看到雏形。
但真正把项目往工程化方向推进时，问题马上就出来了：代码腐化得太快。
AI 产出真的太快了，就像玩俄罗斯方块一直按着下键，错误快速堆积，后期调整就像在仅剩的五六行里小心翼翼地调整越掉越快的方块。以前可以气定神闲地观察代码仓库逐渐演变，现在像是一瞬间给人端上来一个莫名其妙的黑暗料理，干预都来不及。

image250×459 14.1 KB

不够幸运的情况下，大片的代码很快会出现一些问题：

新功能搭建在错误的底座上
相同逻辑随地都有，哪怕一遍又一遍地约束，重构
改动影响范围越来越大，越来越无法预判
AI对契约逐渐失焦
维护成本急剧上升

最终能幸运得到的是一个 “项目”，而不是可演进的 “工程”

开始之前，先想好要怎么约束

我现在的看法是：使用 vibe coding 进行软件工程开发有严格适用范围。

它适合做三类事情：

第一类，原型验证：
先把想法跑起来，看需求是不是成立。
第二类，低风险栈搭建：
脚手架、页面骨架、简单 CRUD、测试样板、文档初稿，这些都很适合交给 AI 快速铺开。
第三类，探索式实现：
在问题空间还没收敛前，用 AI 快速试错，先把几条可能路线跑出来。

但一旦项目进入下面这些阶段，就不能继续靠 “先生成再说” 的方式往前推了：

1. 跨模块联动
2. 出现共享状态和契约
3. 开始多人协作
4. 进入持续迭代
5. 要求可测试、可回滚、可复用

一旦到了项目演进这一步，项目就必须从 生成模式 切到 治理模式。
对人类的工程约束，一样可以迁移到对 AI 上，把 AI 看成一起编码的伙伴，对成熟的开发团队来说，建立目标，编写规范，建立质量考核永远是重要的！

适时 “冻结边界”

以前在项目开始前，我们总是会拉一些冗长的会来达成共识：

本项目的功能边界是什么？
标准参数是什么？
运行于什么环境之上？

在前阵子我的一些 vibecoding 项目中，我没提前定参数，导致在网上看到一些好的点子都想加进去，最终导致整个项目的建设目标都产生偏移。
现在的大模型太聪明了，他们写的代码总是看起来正确，但我们有句老话：方向错了，做的越多越错。

所以我觉得项目一旦决定继续做，第一件事不应该是 “让 AI 接着写更多功能”，而应该是先做一件更枯燥、但更关键的事：冻结边界。

所谓冻结边界，至少包括三样东西：

哪些模块负责什么
哪些接口是共享契约
哪些状态和数据流不允许随意改写

详见 《DDD》与《DDIA》中的一些观点，仅作引读不展开讲:

模块职责对应 DDD 的 限界上下文 —— 边界之外的交互必须走显式接口；
状态保护对应 DDD 的 聚合根 —— 外部无法绕过它直接操作内部；
契约稳定性对应 DDIA 第四章的 数据编码与演化 —— 任何接口变更必须考虑上下游的存量依赖。

这些约束做完，才建议进行下一步。
很多项目最后失去复用价值，不是因为代码丑陋，而是因为系统边界从来没有稳定过。边界不稳定，任何复用都无从谈起。

达成共识，建立 “单一事实源”

VibeCoding 时特别忌讳一件事，规则生成的到处都是，有些写在 prompt ，有些写在 README，有些靠 “口述”，这么复杂的事实来源，让 AI 很难判断什么才是你当前想要的。
所以项目一旦脱离 MVP 阶段，就必须建立单一事实源。

这里做个补充说明，上一个项目我为了规则固化和多 AI 协作，我让 AI 每一个重大变更都要留下一份文档，结果在切换 session 时发现新的 session 耗费大量的时间去读各个文档，发现冲突又要去核验代码，消耗了大量的注意力，结果导致最终去实现的时候，因为上下文过多部分关键点丢失效果大打折扣。因此事实文档要集中且唯一（一个流程的事实上下文最好集中在某个文件的某一段）

需要明确划分清楚当做什么时，去哪里看规则：

产品范围看哪份文档
架构边界看哪份文档
API 契约看哪份文件

例如：

# AGENTS.md

## 产品范围
→ 见 docs/SCOPE.md

## 架构边界
→ 见 docs/ARCH.md，禁止跨层直接调用

## API 契约
→ 见 openapi.yaml，修改前必须发 PR 通知上下游

就像我之前写的一个很简单的 AGENTS.md，里面不定义任何详细规则，而是界定清楚什么事情该谁去看，规定要看哪份文档，仅仅干了这么一件简单的事情，我的项目稳定性很快就控制住了。

建好护墙，让 AI “不能乱写”

很多人遇到 AI 项目失控，第一反应是换模型、调 prompt、上更强 agent。
但这通常治标不治本。
如果 AI 生成的东西与我们的预期有偏差我以前怎么做？undo 一下呗，但是对 AI 有什么影响呢？
现阶段（AI 已经足够应对中等级开发任务）真正有效的做法，不是让 AI 更聪明，而是把软件工程经验带给 AI：

契约改动需要广播给上下游
高风险改动必须要求触发人工 review
泥球文件立马冻结并要求发起拆解，如果现在不能做它也是要列成高风险项进入高等级待办事宜
提交前必须过最低限度的验证

工程治理最有用的部分，从来不是建议，而是禁止。
治理远比堆功能难，因此治理的第一步是冻结腐烂扩散，之后再做减法

我现在更认同一种 “棘轮式治理”(周末详细展开讲)：

1. 已经超大的文件先冻结不要再堆砌
2. 已经混乱的模块先限制 blast radius
3. 已经漂移的接口先锁 contract
4. 已经脆弱的核心链路先提高 review 等级
5. 已经反复出问题的改动模式先写成 hard gate

棘轮一词出自我前两天刷抖音被科普的自行车实现单向踩踏的机械结构，这里意指只允许单方面向好

这套东西的目标不是立刻变好，而是先建立一个原则：

往正确的方向一直前进

项目腐化往往死于 “每一轮迭代都在变得更差”。
一旦没有这个棘轮，AI 的高产出会把腐化速度持续放大。

把 “代码生成” 切换成 “规则收敛”

这是我近期为了稳定项目做的最关键的转折。
项目早期，AI 的主要价值是代码生成而到了中后期，AI 的主要价值其实应该逐步转向：

补充测试
对齐契约
做局部重构
修复 CI
逻辑/组件复用
补文档和证据
发现热点和坏味道

也就是说，项目越往后，AI 越不该主要负责扩张，而应该更多负责收敛。
这是很多团队最容易忽略的地方。
大家默认 AI 就该一直 “帮我多写点”（正如以前吐槽代码行数 KPI）。
但实际上，项目一旦过了原型期，继续让 AI 主要做扩张，几乎一定会加速腐化。正确的做法是逐步把 AI 的重心从 “生长” 切到 “整理”。

换句话说：

原型期，AI 是负责功能延展。
工程期，AI 应该变成收敛引擎。

这才是一个项目能不能保住复用价值的关键。

时常评判项目

我现在越来越不关心 “AI 帮我生成了多少行代码”，而更关心另一件事：
这个项目有没有在 AI 的高产出下，快速丧失掉可维护性、可演进性和可复用性。

如果答案是 “会”，那问题就不再是 “AI 代码质量不高” 这么简单了，而是进入持续挖坑阶段
所以，真正的结论是：

单纯靠 vibe coding 只能负责把项目生出来。

项目想活下去，只需要做一件事：把 AI 的角色从 “不断扩张” 切换成 “持续收敛”。边界、规则、约束，都是这个切换的具体手段。

不加治理的 vibe coding，就是一直按着下键的俄罗斯方块 —— 速度越快，越没有思考的空间，直到游戏结束。