什么时候 Vibe,什么时候收
前面四篇讲的都是”怎么把 Vibe Coding 做好”——写清 Spec、给对上下文、把 Prompt 当设计、用 Review 守住出口。但有一个更上位的问题一直没正面回答:
这套工程纪律,是不是任何时候都得端着?
不是。如果你写个周末玩具项目也要求自己写完整 Spec、跑 80% 覆盖率、每次改动都做五步评审,那 Vibe Coding 带来的那点爽快感就全被流程吃掉了。反过来,如果你在给支付链路加功能时还”完全凭感觉,接受 AI 写的所有代码”,那就是在给自己埋雷。
Vibe Coding 真正的关键,我想了很久,觉得就一件事:知道什么时候放开,什么时候收紧。 这一篇就专门讲这个分寸感。
从”好玩”到”负责”的那条线
很多项目的起点就是一时兴起。你看到一个有意思的想法,打开 Cursor 或 Claude Code,十分钟搭个原型出来。Vibe Coding 特别适合服务这种冲动
、反馈快,围绕一个直觉搭原型,在多轮对话中逼近问题的边界。“好玩”在软件实践里有很高的价值,别把它污名化。但兴趣驱动有它的天然边界。这个边界叫**“被依赖”**。
一个项目只要开始被别人复用、被团队接管,甚至只是被未来的你自己反复调用,它就不再是私人实验品了。一旦有人开始依赖它的接口和行为,你就得面对稳定性、可解释性、兼容性这些硬问题。
这个转变有时候发生得很快。我自己有个小工具,写完随手发到群里,没过两天就有三个同事在用,其中一个还把它嵌进了自己的自动化脚本。等我想改接口的时候才发现——改不动了,因为会影响别人的流程。一个周末项目,就这么悄无声息地变成了需要”维护”的东西。
AI 让这个转折变得更突然。生成式工具把”从想法到原型”的时间压到了极致,于是你更容易犯三个认知错误:
- 把”生成完成”当成”开发完成”
- 把”演示成功”当成”可以交付”
- 把今天为了赶速度接受的含混命名和重复逻辑,当成”以后有空再说”
而”以后有空”通常不会来。今天欠下的债,明天就是别人维护时最头疼的地方。
探索区与生产区
与其纠结”要不要上纪律”,不如先分清你现在站在哪个区。我把开发场景分成两个:探索区和生产区。同一个人、同一个项目,在不同阶段会来回横跳,关键是你得知道自己此刻在哪边。
探索区 Vibe
在探索区,目标是快速确认方向对不对,不需要一次性得到可长期维护的系统。这几类场景都属于探索区:
- 从零到一的原型验证、可行性验证、交互路径试验。代码粗糙、命名临时、局部重复都没关系,前提是你清楚这只是验证材料,后面还要重整。
- 一次性脚本和小工具、临时格式转换、专项抓取、离线统计。这类代码运行周期短、边界窄、依赖简单,过度工程化纯属浪费时间。
- 学习和技术探边 API、试用新框架、理解第三方库的行为边界。让 AI 快速生成实验代码就好,目的是”搞懂”,不是”留下”。
探索区只有一条铁律:探索代码必须和生产代码物理隔离。实验性结论未经验证,不要进主干。用独立分支、独立目录、甚至独立仓库都行,但别让”验证用的脏代码”和”要长期活着的代码”混在一起。
生产区
代码一旦进入团队协作——只要它会被他人阅读、修改、扩展——就必须回到统一规范。这时候前四篇讲的东西全部生效
要写清、上下文要喂对、Prompt 要当设计、Review 一道都不能少,AI 代码合入主干前必须过人工评审。生产区里有一类代码要格外当心:核心业务链路。支付、结算、权限、核心算法、基础数据结构——这些代码一旦出错影响巨大,必须由人主导设计,AI 只做局部实现。你可以让 AI 写这些模块的样板和测试,但”这个模块该长什么样”这个决策,必须攥在人手里。
还有排障。系统出现幽灵 Bug、并发问题、异常链路错配时,不能靠”反复让 AI 猜一猜”来排障。最有效的路径还是人主导定位
,补齐日志证据,写边界测试,逐段收敛。让 AI 在没有证据的情况下反复猜,只会把上下文烧光,还得到一堆互相矛盾的”可能是这里”。一套可操作的切换阈值
“探索区 vs 生产区”听起来还是有点虚。给你一套具体的判断标准——满足任意一条,就该从 Vibe 模式切到工程模式:
- 代码预计存活超过一周,并且会被持续修改。 活得久 + 改得频,就得为可维护性买单。
- 代码将进入主干分支,或被跨团队复用。 只要有第二个人依赖它,私人标准就不够用了。
- 代码影响资金安全、权限边界或用户数据。 这三样出错的代价,远超省下来的那点时间。
- 代码涉及并发时序或复杂状态转换。 这类 bug 最难复现、最难靠”看起来对”来判断,必须有测试和人的判断兜底。
这四条可以直接抄进你的 AGENTS.md,当成团队的共识线。它的价值不在于”精确”——一周还是十天并不重要——而在于把一个模糊的直觉变成一句能拿出来讨论的话。当有人想把一段 Vibe 出来的代码直接合进主干时,你可以指着这四条问
复杂度上限要分区设置
最后补一个和分区配套的观念:不同区域的复杂度上限应该不一样。
核心业务模块和高频变更路径,要保持更低的复杂度上限——因为这里的每一点复杂度,未来都会被反复付利息。外围适配层可以容纳一定的技术复杂度,前提是边界清楚、可替换。
我见过不少项目,团队没意识到这一点,把复杂度均匀地摊在整个代码库上。结果核心区被越堆越重,最后整个改不动,只能推倒重来。正确的做法是
,让核心区始终保持”能一眼看懂、能放心改”的状态。如果这一篇只留一句话:Vibe Coding 不是一种恒定的工作方式,而是一个需要你随时判断的档位。 探索的时候把油门踩到底,进生产区的时候老老实实挂回工程挡。会踩油门的人很多,知道什么时候松油门、什么时候刹车的人,才是真正把 AI 用明白了的人。
下一篇会从”分寸感”转向”耐力”——当你确实需要 AI 长时间干活(一个能自主跑几小时的重构、迁移或功能开发)时,怎么让它可控地跑下去,而不是跑偏、跑崩、或者停在半路等你确认。
主要参考: 本文整合自社区长文《Vibe Coding 到底是什么?》(blog.byebug.cn)第 05、06、10 节,以及《Vibe Coding 实战教学指南》的相关章节,并结合实践重写。
