Vibe Coding vs 工程判断：速度的终点与责任的起点

Source: Dev.to

引言

Vibe 编码无处不在：你向 AI 提示，保持流畅，快速生成代码，并交付看起来正确的东西。演示可以运行，测试通过，感觉很高效。经过处理真实世界的事故并审查生产代码后，有一点变得清晰：vibe 编码加速了产出，而工程判断保护系统。两者都必不可少，但它们解决的是截然不同的问题。

Vibe 编码的表现形式

• 快速的 AI 辅助代码生成
• 最少的规划
• 因为“它能跑”而信任输出
• 将动能置于结构之上

它消除了摩擦：没有空白页，没有语法纠结，没有上下文切换。对于小范围的任务，这确实是一次真正的生产力提升。

Vibe 编码的优势场景

• 一次性代码——概念验证、演示、实验，寿命不重要。
• 学习或验证——目标是探索想法，而不是保证生产环境的稳定性。
• 简单任务——CRUD API、基本 UI 布局、配置设置。

在这些情况下，错误的代价低，速度优势大于风险。

Vibe 编码的局限

必须经受多个团队、重构、扩展以及多年维护的代码往往会出现问题：

• AI 生成的结构起初看起来很整洁，但维护起来会很痛苦。
• 复杂的业务规则（认证、权限、支付、机密）往往很混乱；AI 倾向于过度简化并编码错误的假设。

一个真实案例

我使用 AI 实现了一个后台任务流，在预发布环境中运行完美，拥有干净的重试机制和良好的抽象。我忽略了：

• 重试不是幂等的。
• 部分失败导致了重复写入。
• 日志隐藏了真实问题。

一次生产事故暴露了这个问题。错误并不是 AI 的，而是缺失的工程判断导致的。

指导原则

如果你无法解释代码为何安全，就不应该交付它。

AI 可以帮助编写代码，但它应被视为：

• 一个助理
• 一个草稿工具
• 一个生产力倍增器

——而不是架构师或决策者。

未经检查的 Vibe 编码常见陷阱

• “暂时”留下的硬编码机密
• 过于宽松的访问检查
• 不安全的依赖选择
• 缺失的验证路径

一切看起来都很好，直到出现问题。尤其是安全性，需要 AI 所缺乏的怀疑精神。

有效实践

• 在边界处放慢速度（认证、数据写入、集成）。
• 像审查他人代码一样审查 AI 生成的代码。
• 询问它会如何失败，而不仅仅是它如何工作。
• 绝不跳过人工代码审查；默认将 AI 输出视为不可信。

没有纪律的速度只会把问题往后推。

在速度与责任之间取得平衡

使用 Vibe 编码来

• 探索想法
• 减少摩擦
• 在风险低的情况下快速前进

依赖工程判断来

• 保护用户
• 保障系统安全
• 为故障设计
• 对生产结果负责

速度可以交付功能。判断让系统存活。这就是经验教给我们的区别。