当 AI 开始写代码，谁来为事故买单：34 起“氛围编程”翻车事件背后的真问题

过去一年，科技圈最流行的几个字，恐怕少不了“vibe coding”。大意就是：别太纠结底层实现，先让 AI 把东西做出来，能跑、能演示、能上线，气氛到了就行。

这套方法在黑客松、原型验证、个人项目里确实很迷人。几句自然语言，一个登录页、一套后台、一个支付流程，好像真能在一杯咖啡的时间里长出来。问题在于，软件工程从来不是只靠“长出来”就完事的行业。它还需要审计、回滚、权限边界、依赖治理、故障预案，甚至需要一点点无聊但关键的偏执。

最近，Crackr AI 做了一个名为《Vibe Coding Failures》的事故目录，收录了 34 起已有公开来源的 AI 代码事故，时间跨度覆盖 2025 到 2026 年。这个页面像一面不太体面的镜子：它把许多公司不愿意正视的事实摆到了台面上——AI 生成代码不是单纯“偶尔写得差一点”，而是在生产环境里真实造成了宕机、泄露、漏洞和供应链污染。

从“写得快”到“死得快”，AI 事故已经不是个别案例

如果只看个别新闻，这些事故看起来像孤立事件；可一旦被并列放在一个清单里，味道就变了。页面统计显示，这 34 起事件涉及 630 万条以上受影响记录、35 个以上 CVE，以及至少 69 个发现的漏洞。事故类型也很有代表性：既有生产宕机，也有数据暴露、工具级漏洞和供应链攻击。

最扎眼的案例之一，是 DataTalks.Club 的生产数据被 Claude Code 执行 terraform destroy 后“核平”：2.5 年积累的数据、约 194 万行记录，瞬间蒸发。另一类事故更像现代软件供应链的噩梦。比如 LiteLLM 在 PyPI 上被投毒，攻击面覆盖到每月 9500 万下载量；又比如 npm 生态里，攻击者专门利用 AI 幻觉出的包名布设恶意包，等开发者或 AI 助手自己撞上去。

这类新闻真正让人背后发凉的地方，是它们不再只是“模型答错了一道题”，而是“模型接管了一条真实的执行链路”。一旦 AI 可以读代码、改配置、调用终端、操作云资源，它犯的错就不再停留在聊天框里，而会一路扩散到数据库、CI/CD、密钥仓库和线上服务。以前实习生删库，至少还要先拿到权限；现在，一个被过度信任的 AI Agent，也许在深夜里就把这些步骤全做完了。

为什么今年格外危险：AI 不只是建议者，而是行动者

这波风险集中爆发，并不是因为 AI 突然“变笨”了，恰恰相反，是因为它开始“变能干”了。过去的代码助手主要负责补全和建议，人类还坐在驾驶位上。如今的 Claude Code、Cursor、Copilot、Gemini CLI、Amazon Q Developer 这类工具，已经越来越像拥有手和脚的自动化代理：它们会读仓库、跑命令、安装依赖、改配置文件、提交代码，甚至直接接入云环境和开发者终端。

危险也因此发生了质变。一个会胡说八道的聊天机器人，顶多浪费你一点时间；一个会胡说八道还能执行 shell 命令、访问环境变量、操纵 Terraform 和 Kubernetes 的系统，就成了基础设施风险。Crackr 收录的案例里，很多问题都指向同一个结构性矛盾：人们把“语言模型擅长生成像样答案”误解成了“语言模型具备稳定可靠的工程判断”。这中间差着好几层安全设计。

你会发现，事故不只来自模型本身，也来自围绕模型构建的工具链。像 Cursor、Windsurf、Copilot 等 AI IDE 被曝出多项漏洞，甚至出现“所有主流 AI IDE 都有漏洞”的尴尬局面；提示注入、规则文件后门、命名空间劫持、依赖投毒、DNS 外传，这些老问题经过 AI 重写一遍，杀伤半径反而更大了。因为 AI 工具的默认设计目标往往是“顺滑”和“少打扰”，而不是“多怀疑”和“强约束”。用户觉得方便，攻击者也觉得方便。

这和云计算早期很像。云不是不安全，而是“把安全责任重新分配”了。AI 编码工具也一样：它不是天然危险，但它会把很多过去需要资深工程师才能踩到的坑，变成普通团队几小时就能撞上的坑。

“氛围编程”真正暴露的，不是技术不行，而是工程纪律被嫌麻烦

我并不反对用 AI 写代码。说到底，大多数开发者已经离不开它了，正如没人会拒绝自动补全、单元测试生成、文档整理和重构建议。问题不在于“该不该用”，而在于“拿它做什么、在哪个边界内用”。

“Vibe coding”之所以让人上头，是因为它迎合了一个很真实的时代情绪：大家都在追速度。创业公司想压缩人力，产品团队想加快实验，大厂想证明自己没有落后，投资人也爱听“10 倍效率”的故事。于是很多本应经过设计评审、权限分层、安全测试的东西，被包装成一句轻飘飘的话：先让 AI 搭起来再说。

问题是，软件行业吃过太多“先上线再补票”的亏。十多年前是 PHP 时代野蛮生长带来的 SQL 注入和弱口令，后来是移动互联网时期 API 暴露和越权泛滥，再后来是云原生时代的对象存储裸奔、CI 密钥外泄。今天轮到 AI 了，本质并没有变：每一轮效率革命，都会有人把工程常识当成旧时代的繁文缛节，然后在下一次事故复盘会上重新学一遍。

页面里有个让我印象很深的案例：有创业公司被曝将关键安全逻辑都放在客户端，最后直接走向关停。很多人看到这种故事会笑，说这不是 AI 的锅，是团队太草率。没错，但这恰恰是重点。AI 不是凭空制造草率，它会放大草率。一个原本能力一般但做事谨慎的团队，用 AI 可能仍然可控；一个本就轻视审查、迷信速度的团队，用上 AI 后，风险会指数级增长。

接下来该怎么管：不是禁用 AI，而是把它拉回“副驾驶”

行业现在最需要的，不是继续争论“AI 会不会替代程序员”，而是认真回答另一个问题：当 AI 已经能改动生产系统时，谁来承担可验证的责任？

我倾向于把 AI 编码工具分成三层看。第一层是低风险辅助，比如解释代码、生成测试、写脚手架，这部分几乎已经不可逆。第二层是受限执行，比如在沙盒中跑命令、修改特定目录、访问最小权限资源，需要严格审计与审批。第三层是高风险自动化，比如直接触碰生产数据库、云控制面、密钥和财务系统，这类场景现在普遍跑得太快了，快到治理机制还没跟上。

未来两年，真正有竞争力的 AI 编码平台，拼的恐怕不只是模型能力，而是“工程护栏”能力。谁能把权限隔离、操作回放、可追责日志、策略审批、依赖来源校验、敏感命令拦截做扎实，谁才更可能进入企业核心流程。光会生成代码，已经不够了；能证明这段代码和这次动作不会把公司送上热搜，才值钱。

这也是为什么我觉得这份事故目录很有价值。它不只是一个“AI 翻车墙”，也像一个行业病历本。它告诉我们，当前 AI 开发工具的竞争，某种程度上正在重演浏览器和云服务的老路：先疯狂铺量，再被安全研究员和真实事故逼着补课。浏览器后来长出了沙箱、站点隔离、权限控制；云服务后来有了 IAM、审计日志、零信任。AI Agent 也迟早会走到这一步，只是代价最好别总由用户数据和线上服务来付。

说到底，代码世界从来不奖励“看起来很聪明”，它奖励的是“在最糟糕的时候也别出事”。如果 AI 想成为真正的工程伙伴，而不是一个会写诗、会删库、还会一本正经甩锅的实习生，它必须先学会受约束地工作。

而对企业来说，一个更刺耳但更现实的问题是：当你把生产权限交给 AI 的那一刻，你到底是在拥抱效率，还是在把内部控制流程悄悄外包给一个概率模型？这个问题，今天不回答，明天多半要在事故报告里回答。