Vibe Coding 的隐藏代价：如何在 AI 编程中保留乐趣又不制造混乱

Vibe coding 让人上瘾：你描述需求，AI 直接生成代码，整个过程像施法一样畅快。但这种「感觉对了就写」的模式有个后遗症——问题总在事后才浮现。

原文作者一针见血地指出：vibe coding 在全新项目里所向披靡，因为没什么可破坏的；一旦 AI 进入已经承载业务逻辑的代码库，风险就陡增。AI 不知道哪些文件是承重墙，不了解你的代码约定，它的优化目标是「让提示词跑通」而非「让系统保持健康」。结果是：代码能跑，但不合身。而且你越沉迷 vibe，这类代码堆积得越多。

问题出在哪：AI 不懂你的「承重墙」

原文列出了三个关键盲区：

• 分不清关键文件：AI 无法判断哪些文件是系统核心，哪些是边缘代码，修改起来一视同仁。
• 不了解项目约定：命名规范、目录结构、错误处理模式——这些隐性知识不在提示词里，AI 自然无从遵守。
• 目标错位：AI 优化的是「让这次提示成功」，而不是「让系统长期健康」。

这三条叠加，产出的代码往往「能跑但不对味」。更麻烦的是，vibe coding 的流畅体验会让人放松警惕，不合身的代码越积越多，技术债在不知不觉中膨胀。

技术债（Technical Debt） 是理解本文风险的关键概念。它由 Ward Cunningham 提出，指为了短期速度而做出的次优技术决策，会在未来以额外的维护、修改和修复成本「连本带利」地偿还。技术债并不总是坏事——原型阶段有意欠债是合理策略；危险的是无意中累积的隐性债务。vibe coding 的流畅体验恰恰容易制造后者：AI 生成的代码「能跑」，测试可能也过，于是没人去审查它的结构是否合理、命名是否符合约定、是否重复实现了已有逻辑。这类债务不会立刻报错，而是潜伏下来，直到某次看似无关的改动引发连锁故障。判断债务是否在膨胀，一个实用信号是：每次让 AI 改一处，它动到的文件数量是否越来越多、越来越出乎意料。

保留乐趣的四个护栏

作者并不主张放弃这种高效的创作流，而是建议加几道低成本护栏：

1. 审查 diff，而不是凭感觉

接受变更前，花 10 秒看一眼实际改了什么。作者称这一步能拦住 90% 的「等等，它为什么动了这个文件？」时刻。diff 审查是性价比最高的防线。

diff（差异对比） 是版本控制系统的核心输出：它逐行展示两个版本之间新增、删除和修改的内容，通常以 + 标记新增行、- 标记删除行，并附带变更所在的文件路径与行号上下文。在 AI 编程场景中，diff 的价值在于它把「AI 声称做了什么」和「AI 实际做了什么」摆在一起对照——模型的自述可能遗漏或美化改动，而 diff 是文件系统层面的客观事实。审查时应优先关注三类信号：一是改动范围是否超出预期（例如只想改一个组件，却动了配置文件或依赖清单）；二是删除行，任何未经你要求的删除都值得追问；三是非代码文件的变动，如锁文件、环境变量、CI 配置，这些往往是事故的起点。多数 AI 编辑器和 CLI 工具都支持在应用变更前预览 diff，养成先看后批的习惯即可。

2. 大动作前先打检查点

如果你准备说出「重构所有东西」，先确保自己能一键回滚。检查点让激进操作变得可逆，这是放开手脚的前提。

检查点（Checkpoint） 与 Git 提交不是一回事，值得区分。Git commit 是语义化的历史节点，需要你组织信息、决定粒度，本身带有「这是一次有意义的变更」的宣告意味；而检查点是一个轻量的、近乎无感的快照，目的是让「刚才还好好的」这个状态可以被一键找回。在允许 AI 执行大范围重构前打检查点，本质是把不可逆操作转化为可逆操作。实践上有几种形态：编辑器的自动快照功能、独立的 stash 或临时分支、乃至简单地复制一份工作目录。关键不在于用哪种机制，而在于在执行前就确认回滚路径可用——很多人是在出问题之后才去找恢复手段，那时往往已经被后续改动覆盖。检查点的成本只有几秒，但它决定了你敢不敢让 AI 放开手脚，这正好呼应了按可逆性分配速度的原则。

3. 对破坏性操作收紧缰绳

写新文件是低风险，删文件或执行 shell 命令是高风险，两者应区别对待。给 AI 的操作分级授权，而不是一刀切放行。

破坏性操作（Destructive Operation） 指那些一旦执行就难以或无法通过撤销恢复的动作。典型例子包括：删除文件或目录、覆盖已有文件内容、执行 rm、git reset --hard、git push --force 等命令、修改数据库结构或执行批量更新、安装或升级依赖（可能引入不兼容变更）、以及任何触及外部系统的网络请求。与之相对，新建文件、新增函数、添加测试属于加法型操作，即使做错也容易识别和回退。分级授权的落地方式通常有两种：一是在工具配置中为命令设置白名单或确认规则，二是用自然语言在项目说明里约定「执行删除或 shell 命令前必须先询问」。两种方式可以并存。需要提醒的是，风险等级取决于上下文而非命令本身——同样是删除文件，清理临时产物与删除迁移脚本的意义天差地别，因此授权规则应保留人工确认的余地。

4. 允许 AI 提问

最好的 AI 助手在做不可逆操作前会暂停确认。这个暂停是特性而非摩擦——它给了你最后一次说「不」的机会。

平衡之道：可逆处快，不可逆处慢

原文的结论很清晰：vibe coding 和严谨工程并不对立。关键在于按「可逆性」分配速度——可逆的事让 AI 飞快推进，不可逆的事让它慢下来。

「快在安全处，慎在关键处」，这就是全部心法。这一框架也解释了为什么 diff 审查和检查点如此重要：它们把更多操作变成可逆的，从而扩大了可以放心 vibe 的空间。

对于 Windows 用户，原文顺带提及 Arcwright 这款围绕该理念构建的 AI 编辑器，可免费起步。

常见问题

Vibe coding 适合什么样的项目？

全新项目、原型验证、无关键依赖的场景最适合。涉及生产系统或核心业务逻辑时，需要配合审查与回滚机制。

diff 审查真的有必要吗？

有必要。它成本极低（约 10 秒），却能捕捉 AI 误改关键文件的大部分情况，是投入产出比最高的习惯。

如何判断哪些操作该收紧？

按可逆性判断：新建文件、新增函数可放行；删除、覆盖、执行命令应收紧并确认。