AI编程陷阱:Serverless死循环产生了一万美元账单

根本原因：AI 编写的 Durable Objects alarm 代码陷入死循环，产生了约 6 万亿次读写操作。
原始出处 : 开发者 X 账号：@shmily7。相关推文链接为：https://x.com/shmily7/status/2108060782302990699。
处理结果：Cloudflare 客服认定是代码 Bug 而非平台故障，拒绝退款，开发者最终全额支付了账单。(通过访问当事人最新动态，cloudflare已经决定退还故障期间所有产生费用！) 必须给赛博菩萨点上一个大大的赞，堪称互联网最良心企业！
10811.41 美元的账单，只是一次很直观的提醒：
我们已经进入了一个时代——创建成本大幅下降，出事成本大幅上升。
AI 让你一行行代码地构建世界变得很轻松；
但世界炸起来的时候，账单不会跟你讲算法原理，也不会理解你的心情，它只按请求次数、按调用量结算。
这不是要你少用 AI，而是要你承认一件事：
真正的工程效率，不是写得多快，而是系统在你“犯错时”还能活下来。
AI 负责快，人负责活。
如果这点不改变，下一张离谱账单，只是时间问题。
故事听起来像个笑话，但细想一下，它踩中了当下软件开发里最危险、最容易被忽略的那条线：人开始把执行权交给机器，却还沿用“人类时代”的安全假设。

事情的逻辑其实不复杂。开发者用 AI 生成了一段 Cloudflare Workers 的脚本。代码单独拎出来跑，没毛病。但一旦部署到生产环境，它开始疯狂地读写数据库——6 万亿次操作。每一次操作都被计费，账单就这样堆起来了。

Cloudflare 的态度很硬：这是你的 bug。我们没有责任。

这话听着扎心，但从平台的角度也没毛病。他们提供的就是这样的计费模型，再清楚不过的 ToS。问题的根子，确实在那段代码里。

AI 写代码为什么容易挖坑
这些年用 AI 辅助编程，我也踩过坑。不是一两个。

最常见的问题是什么？上下文盲点。

AI 看不到整个系统的约束。它不知道这个函数会被高并发调用。它不了解缓存策略。它对成本这回事儿没有概念。给它一个孤立的需求，它能编出来。但把这段代码丢进一个复杂的分布式系统，各种隐性的冲突就爆发了。

比如我们这个案例。AI 可能生成的是一个”看起来合理”的数据库查询逻辑。但它没有考虑：

这个函数被触发的频率
是否有防重复机制
请求是否可能堆积
还有一类隐蔽的问题——异常处理的缺失。当 API 超时、网络抖动、依赖服务故障时，AI 写的代码往往没有降级策略。它就一门心思重试，或者陷入某种不可控的状态。在 Serverless 这种按次计费的环境里，这就是导火索。

为什么 AI 不能想到这些
我们容易把 AI 当成一个无所不知的程序员。实际上它更像一个聪慧但没有经验的实习生。

它能学会语法，能理解”怎么写”。但”应该怎么考虑”这个问题，它缺少实战积累。那些只有在生产环境里摔过跤才能学到的东西——成本意识、容错设计、性能预算——AI 根本没有。

更关键的是信息深度的问题。AI 的输出基于统计模式，而不是对你这个具体项目的深层理解。它不知道你的业务流量什么时候会飙升。不知道哪些操作在你的架构里特别昂贵。这些都是只有人类能做的判断。

真正的危险在哪儿
现在很多团队的做法是这样的：让 AI 快速生成代码，然后人工审查。听起来合理，但实际执行中往往变成了走过场。

为什么？因为代码量太大了。AI 一下子生成 500 行，人类要逐行审查，这不现实。大多数人会扫一眼，看起来没什么明显的语法错误就过了。而那些潜在的成本陷阱、并发问题、边界情况，恰恰最容易被忽视。

还有个更隐蔽的风险——自信心陷阱。当 AI 给的代码在测试环境里正常运行，开发者会产生一种虚假的安全感。”它肯定没问题”。直到生产环境闹幺蛾子，才发现端倪。

那十多万块钱到底怎么花出去的
6 万亿次读写操作。这数字听起来像科幻，但在代码逻辑错误的情况下，一点都不夸张。

想象一个简单的场景：某个条件判断逻辑反了，导致本该执行一次的操作反复执行。如果这个函数被频繁触发，几分钟内就能积累出恐怖的操作数。Cloudflare Workers 的计费模型是透明的，但正是因为透明，很多人在部署前反而没有充分估算成本。

这个开发者可能的情况是：代码上线后，某个异常导致死循环，或者某个条件判断失效。因为是 Serverless 环境，他甚至可能在第一时间没有察觉。等反应过来，账单已经是五位数了。

过去一年多，我用 AI 的频率越来越高。但我对它的看法也在变。

开始的时候觉得它是个超级助手，能大幅提升效率。现在我的感觉是：它更像一个放大器。用得好，确实快。但如果不小心，它会把你的问题也放大。

我现在的做法是：

第一层防线：不让 AI 写关键路径。认证、支付、数据一致性相关的逻辑，还是得自己写或者代码审查得特别细致。

第二层防线：AI 生成的代码必须有测试。不是”过了一遍”的测试，而是真正考虑边界情况、异常流、高并发场景的测试。

第三层防线：对于任何可能产生成本的操作，都要有限流和告警。在 Serverless 环境尤其重要。

第四层防线：部署到生产前，必须对成本做预估。”这个函数每秒可能调用多少次？单次操作的成本是多少？最坏情况下每天要花多少钱？” 这些问题必须有答案。

说到底，AI 写代码的问题不是”代码写得烂”。现在很多 AI 生成的代码在语法层面并不差。问题是缺少系统思维。

软件工程不等于代码生成。前者是一门关于权衡、约束、成本的学问。后者只是把某种模式翻译成文本。AI 擅长后者，不擅长前者。

所以当我们说”用 AI 提升效率”时，不应该理解为”让 AI 替代人”，而是”让 AI 处理那些重复的、低风险的部分，人类在关键决策上发挥作用”。

那个被账单砸中的开发者，他学到的东西比一个月的日常工作还多。只是代价有点贵。

当代码不是一行行敲出来，而是靠复制粘贴或者一键生成时，我们对系统的直觉在退化。过去，自己手写每一行代码的过程，其实也是在脑海中完成一次系统推演的过程。而现在，面对 AI 生成的一大坨宏大逻辑，很多时候我们只能“盲信”——看一眼觉得没语法错误，跑一下能通，那就直接合入主干吧。

这种对复杂度的失控感，才是最致命的。Cloudflare 那一万多美元的账单，不过是把这种失控具象化、货币化了而已。如果没有那次惨烈的死循环，也许那段代码正潜伏在系统的某个角落，像一颗定时炸弹，等待着在流量最高峰的夜晚轰然炸裂。

所以现在每次看到 AI 顺顺当当帮我写完一个复杂功能，我心里反而会咯噔一下。效率被拉满的同时，风险其实也被按下了快进键。

安全气囊永远替代不了方向盘。在这个时代，把全盘希望寄托在 AI 身上无异于豪赌。关键的操作必须有测试拦截，关键的网关必须有限流熔断，关键的成本必须有实时告警——人，绝对不能从这个链条里退出来。

真正的编程艺术，从来都不是看谁在单位时间内生产了更多的垃圾代码，而是如何在这个充满不确定性的复杂系统中，用严谨的约束和敬畏心，让每一行落地的代码都一次对、一直对。

https://www.xpyan.com/Notes/86.html