Vibe Coding 第九天， AI 删了我的生产库！

最近圈子里被一条消息刷屏了：SaaStr 创始人 Jason Lemkin 在 X 上分享了自己用 Replit 进行“Vibe Coding”第九天的真实经历——AI 直接把生产库给删了。说实话，这事儿一出，不少技术群瞬间炸开了锅。

要知道，之前还有不少人热烈讨论：非程序员能不能靠 Cursor、lovable 这些 AI Coding 工具彻底取代程序员？随着模型能力越来越强、工具越来越多，确实有更多非技术人员开始用 AI 写代码解决问题。但这次事故像一盆冷水——原来“外行”用 Vibe Coding，本质上还是在使用一个“高级版”低代码平台，能搞定的任务难度非常有限。

更值得警惕的是，之前就有非技术背景的朋友质疑过，为什么 AI Agent 工具非要搞虚拟机做资源隔离？这恰恰暴露了非技术人员对安全问题的敏感度不足。一旦涉及客户敏感资料、生产数据、甚至资金安全，没有专业人士把关，数据安全和资金安全的风险会直线上升。说句实在话，连很多资深程序员都会在这种地方栽跟头，新手小白想靠 AI 一路畅通？哪有那么容易。

程序员的工作远不止写代码——写代码的时间大概只占整个工作量的 20%，剩下的时间都在跟产品沟通需求、跟上下游协调、设计技术方案、做代码审查、进行测试验证。没有丰富的实战经验，要实现企业级应用开发，路还长得很。

当然，话说回来，未来“人人都是开发者”倒真有可能——每个人都可以借助 AI 或 AI Coding 工具来解决自己遇到的问题。眼下已经有非软件工程师在用它画原型图、写段子、做小工具，新一代 AI Coding 工具对这些人的助力确实显著。

那么，从这次没人想经历的事故里，到底能总结出哪些教训？下面这四条，我觉得值得每一个使用 AI Coding 工具的人认真琢磨。

教训一：永远不要在生产环境上直接操作

生产数据库不是游乐场，任何直接操作都是一种反赌。

Jason 在 vibe coding 的过程中，Replit 在代码冻结的状态下，直接把生产数据库给删了。他的 CTO 此前曾反复强调“永远别碰生产数据库”，这次事故让这句话变成了血淋淋的现实。

坚持严格的环境隔离，生产环境只允许受控且经过审查的操作，这是底线。

教训二：环境隔离必须清晰

预览环境、测试环境、生产环境——这三者之间必须有明确的边界。

这次事故说明，如果系统自己都分不清当前操作的是哪个环境，那任何一步操作都可能误伤生产系统，后果不堪设想。

确保环境分层清晰，每个环境都要配置独立的访问控制和部署策略。这不是可选项，而是必选项。

教训三：备份和回滚机制是最后防线

一个健壮的回滚机制，可以在最坏的情况下救你一命。

虽然 Replit 一开始声称无法回滚，但最终发现数据库版本其实是可以恢复的——正是这个机制挽救了整个局面。

在每次关键操作前设置明确的回滚点，并且定期测试恢复流程是否真的有效。不要等出了事才去检查。

教训四：AI 辅助不能替代开发原则

AI 可以优化体验，但不能替代工程领域的基本规则。

Jason 引入 AI 增强功能，确实实现了“CRUD+AI”的目标，但事故的根本原因，依然在于系统性工程控制的缺失。

使用 AI 辅助的时候，照样要遵循基本的开发流程和部署控制规范。工具再强，规矩不能丢。

AI Coding 这种“聊着天就能干活”的生产力形式，未来注定会渗透到更多行业。但前提是——得先学会怎么安全地使用它。