别让 Vibe 变成债：开发者如何在速度与工程责任间找到平衡点？

现在大家都在用 AI 写代码：一句自然语言，模型就能给你一堆能跑的实现，这就是所谓的 vibe coding。

舒服是真舒服，但一旦项目要进生产、要有人为系统长期负责，vibe coding 和工程责任之间的矛盾就开始冒头了。

1. Vibe Coding 带来的真实好处

先别急着批判，它确实有明显价值：

• 起步更快：不用翻半天文档、从空文件写起，AI 可以帮你生成页面、接口、样例代码，很适合做原型和验证想法。

• 学习更直接：试一个库、一个框架、新的 API，丢给 AI 几个任务，看它怎么写，比纯看文档更有感。

• 小工具很高效：内部脚本、简单自动化、一次性页面，用 vibe coding 搞定，性价比非常高。

问题不在于 vibe 本身，而在于：很多人把 “能跑” 和 “能负责” 混在了一起。

2. 工程视角在乎的那些东西

一旦你站在工程视角，关注点就变了：

• 系统性：模块怎么拆、边界在哪里、数据怎么流，出了问题有没有地方可以下手查。

• 可维护性：半年后改需求，能不能不用重写一半；新人进来，看不看得懂你现在的结构。

• 稳定性和可靠性：在高并发、有脏数据、有奇怪用户行为时，系统还能稳不稳。

• 责任：谁是最后那个对系统交付和线上行为负责的人，而不是“AI 没写好”的那个人。

这几件事，本质上是在问：你是系统的主人，还是只是一个 AI 使用者？

3. 速度 vs 可维护：冲突到底在哪里？

当我们用 vibe coding 写业务代码时，几个典型冲突会不断出现：

• 为了快，结构被压缩成一堆“勉强能跑”的实现：到处是临时判断、复制粘贴、长函数，没人愿意碰。

• 为了赶上线，测试和监控变成“回头再补”的 TODO，结果上线后才发现边缘情况压根没被考虑过。

• 为了方便改提示，把很多逻辑藏在 prompt 里，代码只是结果，这会让团队难以统一理解和复盘决策。

还有一件事，很多人一开始没有意识到：不要轻易让 AI 一次帮你改太多代码。

在理想场景里，AI 是帮你补一个函数、优化一段逻辑；但在实际使用中，它很容易一口气动好几个文件：路由、数据结构、调用链、测试，全都一起改。

如果你频繁点击“接受所有改动”，过上几轮，脑子就会跟不上整个代码库的演化节奏——你只知道“现在能跑”，却不知道“到底改了什么”。

结果就是角色错位：

• 你慢慢从“程序员”变成“测试和验收的人”，只关注报错有没有消失、页面有没有正常显示。

• AI 变成了真正的“写代码的人”，在代码库里自由发挥结构和命名，而你既来不及，也不太想去深追。

长期这样下去，代码是否合理、结构是不是烂、技术债堆到了什么程度，你可能都没有精力，也没有动力去管。

这就是为什么在工程视角下，要刻意控制 AI 的改动范围，并且每次合并前留出理解和审查的时间：不然，你只是把工程责任彻底让渡给一个不会替你值班的“同事”。

换句话说：速度是立刻看得见的好处，维护成本是慢慢长出来的代价。

如果没人刻意把工程视角拉回来，项目就会在“今天很爽、以后很痛”这条路上一路到底。

4. 一个简单的平衡框架：什么时候 Vibe，什么时候 Engineer？

为了解决这个冲突，先别急着给 vibe coding 贴标签，不如给自己定一套简单规则。

可以用两条轴来判断：犯错成本 和 时间尺度。

犯错成本低、时间尺度短

比如个人原型、内部小工具、一次性页面、低风险 UI。 在这些地方，可以大胆 Vibe Coding：

• 用 AI 快速生成实现，

• 多试几个方案，

• 用最小的工程约束兜一下底，比如基础异常处理。

这里的重点是：快验证、快学习。犯错成本低，工程就不必太重。

犯错成本高、时间尺度长

比如支付、认证、权限、订单、交易、风控、长期维护的主业务系统。 在这些地方，必须切回工程模式：

• 明确边界和模块拆分

• 认真做测试、日志、监控、告警

• 对 AI 生成的代码做有意识的审查和重构

这里的重点是：系统安全、可持续演化，你不能说“我就 vibe 一下试试”。

可以记一句很实用的话：

Vibe 用来发现和验证想法；工程用来承载和守护这些想法。

只要项目一旦从“试试”进入“要长期负责”，你的工作模式就应该从 Vibe Coding 切到工程模式。

5. 在 AI 时代，工程责任具体长什么样？

很多人觉得“工程责任”是抽象词，其实在 AI 时代，它可以被拆得很具体：

• 不再追求“每行代码都我手写”，而是追求“关键路径和关键决策我说了算”：知道系统的核心逻辑在哪里，知道出问题时往哪查。

• 把 AI 当“超级实习生”，而不是“背锅同事”：让它生成代码、补测试、给建议，但最终合并的结构和行为，要经过你的理解和判断。

• 刻意训练自己的代码审美和系统直觉：看得出什么是技术债、什么是好结构，而不是只是看语法是否正确。

• 把一部分精力投入到业务理解、架构规划和质量守护上，而不是只停留在“写代码的人”。这些才是 AI 暂时替代不了的部分。

用一句话压缩就是：AI 可以帮你快写代码，但不能替你承担工程责任。 你享受速度没问题，但你得自己决定：哪些地方只需要快，哪些地方必须稳。

6. 一个开发者可以立刻用上的 checklist

最后给一个日常可用的小 checklist，当你在用 AI 写代码的时候，可以简单过一遍：

• 这块功能，出问题的代价大不大？如果大，就别只靠 vibe。

• 半年后，这段逻辑还会有人维护吗？如果会，就从今天开始按工程方式组织。

• 如果线上炸了，我能不能解释清楚系统的行为？如果不能，就说明现在对它还不够了解。

• 这次用 AI，是为了快点试试，还是为了上生产？前者可以多一点 vibe，后者必须多一点工程。

有了这样的自我检查，你就不会在“写得很爽”的同时，把自己和团队推到“维护得很痛”的局面。