Vibe Coding：我们应该使用到什么程度？最佳实践、限制与风险

Source: Dev.to

请提供您希望翻译的文章正文内容，我将为您翻译成简体中文，并保留原有的格式、Markdown 语法以及技术术语。谢谢！

The High Is Real — So Is the Crash

第一次 vibe 编码真正对我起作用时，感觉像是梦一样。我用普通的英文描述了一个功能。没有 Stack Overflow。没有文档。没有上下文切换。只有流畅感。这种感觉很强大——说实话，也有点危险。几周后，我在真实项目中信任了同样的流畅感，结果在深夜回滚，因为发现自己发布了一个细微的安全漏洞。

这篇文章并不是反对 AI。我仍然经常使用 vibe 编码，但我已经学会了它在哪些方面有帮助——以及哪些方面绝对不适用。

什么是 Vibe Coding？

对我而言，vibe coding 是当你不再逐行思考，而是按意图编码：

• “生成一个基本的 CRUD API”
• “创建一个带验证的设置页面”
• “添加认证中间件”
• “将此重构为更清晰的代码”

它是一种针对动量和流畅性优化的 AI 辅助开发方式。

为什么开发者喜欢它

• 启动更快
• 减少样板代码
• 更少的空白屏幕
• 让你专注于问题本身，而不是语法

谨慎使用，它是生产力的倍增器。

Vibe 编码的适用场景

初期想法

初期想法本质上是一次性的。Vibe 编码让你能够：

• 快速验证想法
• 更快交付
• 更早淘汰坏想法

当目标是学习或演示时，速度比结构更重要。我在这里不会过度追求质量——只要确保能运行即可。

大量样板代码的部分

• 管理面板、脚本、仪表盘
• 表单、表格、布局组件、API 包装器

我现在很少手写这些。这正是 AI 发挥优势的地方。

Source: …

Vibe 编码的局限

成熟的代码库

一旦代码库拥有历史、共享抽象和多个团队，AI 就会缺乏上下文。它不知道为什么会出现怪异的情况——只知道它们的外观。

安全敏感区域

认证、权限、支付、用户数据。使用 AI 进行安全编码需要真正的纪律。AI 优化的是“能运行”，而不是“安全”。任何充满“除非…时”规则和边缘情况的代码往往会悄然失效。代码看起来整洁，却在实际中出错。

一个真实案例

我曾使用 vibe 编码为内部 SaaS 工具生成基于角色的访问层。测试通过，演示运行正常，代码看起来很扎实。

我遗漏的地方

• 一个回退路径默认设置为“允许”
• 缺失的角色检查导致数据泄露给错误的用户

虽然没有导致灾难性后果——但完全可能出现。

我学到的教训

• AI 不会进行威胁建模
• “看起来对”并不等同于“安全”
• 对关键路径的人工审查不是可选项

从此以后，所有与认证相关的工作都会刻意放慢速度。

经验教训与健康实践

我的当前准则

如果我无法解释它为何会失败，我还没有完成。

健康的编码氛围

• AI 起草，我精炼
• AI 提建议，我提出质疑
• AI 加速，我负责

不健康的编码氛围

• “它能跑，就发布”
• “AI 可能已经处理了”
• “我们以后再清理”

这些态度会导致：

• 不安全的默认设置（缺少验证、身份认证、速率限制）
• 硬编码的机密信息（API 密钥、令牌、“临时”凭证）
• 风险依赖（过时或有漏洞的包）
• 对看似整洁的代码过度自信

安全 AI 辅助开发的最佳实践

• 对任何非琐碎的代码进行强制代码审查
• 手动测试——自行破坏你的功能
• 静态分析和依赖扫描
• 对关键代码进行明确的安全审查
• 小幅提交并说明明确意图

AI 可以快速编写代码，但工程师仍需对结果负责。

结论

我并没有放弃 vibe 编码，只是不再把它当作魔法。当它被恰当地使用时，它可以：

• 加快开发速度
• 减轻认知负担
• 让编码更有乐趣

而当它被随意使用时，它会：

• 隐藏复杂性
• 产生安全债务
• 将问题推向后期

vibe 编码是加速器——它并不能取代工程本身。只有通过经验，而非炒作，才能真正弄清楚它的界限。

你呢？
vibe 编码在哪些方面对你帮助最大——或者让你吃了最大的亏？