Vibe Coding 和 Vibe Engineering 的区别：一个让你翻车，一个让你起飞

最近 vibe coding 这个词火得不行。

Andrej Karpathy 一句「完全拥抱 AI，忘掉代码存在」，直接把这个概念推上神坛。于是一堆人开始跟风：不用懂代码，让 AI 写就行，出了 bug 再让 AI 修。

听起来很美好。

但现实是：大部分人 vibe coding 的结果，是一堆屎山代码 + 无尽的 debug 循环。

为什么？因为他们把「让 AI 写代码」等同于「不用管代码」。

一个反例：2 周写 5 万行高质量代码

Josh Albrecht 是 Imbue AI 的 CTO。今年 1 月，他做了个实验：用 Claude Code 重构公司产品的底层架构。

结果：

• 2 周内写了 5 万行代码
• 测试覆盖率超过 80%
• 代码质量他自己很满意

这不是 vibe coding。Josh 管这叫 vibe engineering。

区别在哪？他总结了 7 条原则。

原则 1：每次 AI 犯错，就加一条规则

Claude 会犯错，这不是问题。问题是同样的错犯两次。

Josh 的做法：每次发现 Claude 犯错，就写一条规则，程序化强制执行。

他用了一个叫「ratchet」（棘轮）的概念 — 只能往前，不能往后。配合 inline-snapshot 库，把规则变成自动化测试。

比如：「不允许在这个模块里直接调用数据库」— 这不是写在文档里的建议，而是跑测试时会直接报错的硬性约束。

核心逻辑：把经验变成代码，而不是变成记忆。

原则 2：任务大小要刚刚好

太小的任务，AI 来回切换上下文，效率低。

太大的任务，AI 会跑偏，改着改着就不知道在干嘛了。

Josh 的甜蜜点：一个聚焦的改动，大概 10 分钟能完成，刚好塞满上下文窗口。

这需要你对代码库有判断力 — 什么算「一个改动」，什么算「太大了」。

纯 vibe coding 的人没有这个判断力，所以要么让 AI 改一行代码改半天，要么让 AI 重构整个项目然后彻底失控。

原则 3：两种工作模式，不要混着来

Feature 模式：写新功能，往前冲。

Maintenance 模式：清理代码、重构、加防错规则。

这两种模式要分开。

写新功能的时候别想着「顺便重构一下」，重构的时候别想着「顺便加个功能」。混着来，AI 会乱，你也会乱。

原则 4：测试覆盖率 80%，不追求完美

为什么是 80% 不是 100%？

因为逼 AI 写 100% 覆盖率，它会写一堆垃圾测试 — 为了凑数而存在，测不出真问题。

80% 是个平衡点：足够发现大部分问题，又不会让 AI 为了凑覆盖率而写废话。

Josh 把测试当作门槛：代码必须过测试才能合并。这逼着 AI 自己修问题，而不是把烂摊子丢给你。

原则 5：重构不能省

代码写多了，结构会乱。import 变得混乱，抽象开始漂移，文件放错位置。

很多人觉得「先跑起来再说」，重构以后再做。

Josh 的态度：乱了就停下来整理，不要欠债。

因为 AI 对代码库的理解依赖于结构清晰。结构一乱，AI 的输出质量会断崖式下跌。

原则 6：你还是要看代码

不用逐行看，但要看形状。

• 这段代码放的位置对吗？
• 闻起来怪不怪？
• 测试是真的在测东西，还是在走过场？

Josh 说他每行代码都会 review。不满意的地方加个 FIXME 标记，晚上跑脚本让 AI 自动修。

他还有 worker 脚本专门找代码里的不一致，自动修复。

这不是「让 AI 写完就不管」，而是「让 AI 写，你来把关」。

原则 7：写一份真正的风格指南

不是那种「代码要简洁」「命名要清晰」的废话。

而是带可执行示例的具体规则。

比如：「好的错误处理长这样 {{EXAMPLE}}，坏的长这样 {{BAD_EXAMPLE}}」。

这样 AI 有锚点，知道你要的「好代码」具体长什么样。

Josh 甚至让 AI 自己生成这些示例 — 你写规则，AI 填示例，然后你审核。

Vibe Coding vs Vibe Engineering

现在回头看，区别很清楚：

Vibe coding 是把方向盘交给 AI。

Vibe engineering 是你握着方向盘，让 AI 踩油门。

一个有意思的细节

Josh 提到，用这套方法写代码，他能比以前写更久才觉得累。

按理说，来回切换上下文、review AI 输出，应该更累才对。但实际上他感觉更轻松。

我猜原因是：认知负担转移了。

以前写代码，你要同时想「写什么」和「怎么写」。现在你只需要想「写什么」和「对不对」，「怎么写」交给 AI。

这是一种不同的累法。

最后

Josh 说他计划开源这套方法。

但说实话，方法论已经在这了。7 条原则，每条都不复杂。

难的是执行的纪律。

大部分人 vibe coding 翻车，不是因为不知道该怎么做，而是因为懒得做。

「加规则太麻烦了，先跑起来再说。」

「review 代码太累了，测试过了就行。」

「重构以后再做吧，现在先赶功能。」

然后代码库越来越乱，AI 输出越来越差，最后变成屎山。

工具是一样的工具。用法决定结果。