“Vibe Coding”这个说法近来很流行：开发者只用自然语言描述想要什么，AI 生成代码，跑起来看效果，不满意就继续描述，几乎不去阅读和理解代码本身。对于快速做原型、个人小工具来说，这种方式效率惊人，甚至让不会编程的人也能做出可用的应用。但当代码要长期维护、处理真实用户数据或承担业务责任时，“不看代码”就会变成一种风险。

Vibe Coding 适合什么

  • 原型验证：快速做出可交互的演示，验证想法是否值得投入；
  • 一次性脚本：数据转换、批量重命名、临时报表等用完即弃的工具；
  • 个人工具：只有自己使用、出了问题影响有限的小应用；
  • 学习探索：了解一个陌生框架或语言能做什么。

这些场景的共同点是：错误的代价低、生命周期短、不涉及他人数据。

不适合什么

  • 处理用户隐私、支付、身份认证的系统；
  • 需要多人长期维护的业务代码；
  • 对性能、并发、可靠性有明确要求的服务；
  • 受监管行业中需要审计和合规的软件。

不看代码会带来哪些问题

不知道系统实际做了什么

AI 可能为了“让它跑起来”而采取各种捷径：关闭安全校验、吞掉异常、硬编码配置。表面功能正常，背后隐患重重。

安全漏洞

常见的问题包括密钥写在代码里、缺少输入校验、权限检查遗漏、引入了不存在或不可信的依赖包。详细分析见 AI 生成代码的安全风险。

越改越乱

每次通过描述让 AI 修改，它可能重写大段代码、引入新的抽象，或者在不同地方用不同方式解决同一问题。几轮之后，代码库变得难以理解，连 AI 自己都开始顾此失彼。

无法排查线上问题

线上出现故障时，如果团队中没人理解代码逻辑，排查只能靠反复询问 AI，效率低且容易误判。

AI 时代依然需要的工程纪律

版本控制与小步提交

每完成一个小功能就提交一次，提交信息说清楚改了什么。AI 一次改坏了，可以随时回退。

自动化测试

测试是检验 AI 代码是否正确的客观标准。核心逻辑必须有测试覆盖，每次修改后自动运行，参见 AI 生成单元测试。

代码评审

进入生产的代码至少要有一个人真正读过、理解过。AI 可以辅助评审，但不能替代，参见用 AI 做代码评审。

依赖管理

审查 AI 引入的每一个新依赖：是否真实存在、是否活跃维护、许可证是否合规。

密钥与配置分离

密钥、数据库连接等敏感配置一律通过环境变量或密钥管理服务注入，绝不写入代码。

可观测性

日志、监控和告警让你在问题发生时能快速定位，而不是两眼一抹黑。

从原型到生产的过渡

一个务实的做法是把 Vibe Coding 当作探索阶段的工具：快速做出原型、验证需求之后，再以工程化的方式重新审视代码，补齐测试、评审和安全检查，必要时重写关键模块。原型阶段追求速度，生产阶段追求可控，两个阶段用不同的标准。

小结

Vibe Coding 降低了做出软件的门槛，这是好事。但软件的价值不只在于能跑起来，还在于可靠、安全、可维护。在 AI 写代码越来越多的今天，版本控制、测试、评审和安全纪律不仅没有过时，反而更加重要。更多编码 Agent 的协作方式可参考编码 Agent 工作流。