开发者直接复制ChatGPT生成的代码，导致公司损失10000美元

一家名为 Reworkd 的初创公司在尝试商业化过程中，通过使用 ChatGPT 生成的代码进行项目迁移，导致服务因为代码错误无法正常订阅，造成超过 1 万美元的损失和 5 天服务停机。。。

根据描述，Reworkd 公司专注于开发完成自动化任务的 AI Agent 平台，旨在解决需要大量人力介入的业务流程的低效问题。

通过使用 AI Agent，Reworkd 帮助企业简化操作并减少手工工作量。这家公司得到 Y Combinator（为初创公司提供早期风险投资、创业指导等）的支持。

当时这家公司开始了商业化尝试，初步计划是 “让用户付费订阅自家的服务”。经过团队商议，他们将订阅服务的价格定在了每位用户每月 40 美元。

规划好了商业化的方向与定价之后，团队开始着手 “更改业务代码”，集成 “支付系统” 等等。

该项目原本采用的是全栈 NextJS 技术，要实现商业化，业务代码也需要进行改变，因此团队需要在有限的时间里计划将项目从 Next.js 迁移到 Python/FastAPI。

由于迁移工作涉及到编写许多繁琐的代码，于是团队成员想到了交给 ChatGPT 完成。

具体情况如下：

作为我们的后台迁移的一部分，我们正在将数据库模型从 Prisma/Typescript 转换为 Python/SQLAlchemy。这真的很乏味且繁琐。

我们发现 ChatGPT 在这个转换过程中做得相当出色，所以我们几乎在整个迁移过程中都使用了它。

我们复制了它生成的代码，看到一切都运行正常，将其用于生产环境，发现它也正常运行，然后继续我们忙碌的生活。但此时，我们仍然使用我们的 Next API 来进行所有的数据库插入。

Python 只是从数据库中读取。在我们实际上开始在 Python 中插入数据库记录的第一次是当我们实现订阅时。尽管在此过程中我们手动创建了全新的 SQLAlchemy 模型，但我们最终还是复制了 ChatGPT 为我们现有模型所写的相同格式。

我们忽略的是，我们将生成 ID 的方式的问题也复制到了所有模型中。

出现 Bug 的代码位于第 56 行，我们只是传入了一个硬编码的 ID 字符串，而不是用于生成记录 UUID 的函数或 lambda 表达式。

这意味着对于我们的后台的任何一个实例，一旦一个新用户订阅并使用了这个 ID，其他用户就无法再执行订阅流程，因为会导致唯一 ID 冲突。

由于我们的后台设置，这个问题被很好地隐藏了起来。

我们在 AWS 上有 8 个 ECS 任务，每个任务运行我们的后台的 5 个实例（过度，是的我们知道，但公平地说我们有 AWS 额度）。

这意味着任何一个单独的用户可能遇到 40 个潜在的唯一 ID。 

白天，这没问题。我们可能每天提交 10-20 次（当然直接提交到主分支），这将导致新的后台部署发生，给客户提供了 40 个全新的 ID 供他们使用。

但到了晚上，当我们终于停止提交（我们是不是有点懒呢？）时，每台服务器中的单个 ID 都将被占用，导致所有新的订阅都产生 ID 冲突。

用户一开始有 40 个可能的服务器可以让他们订阅，随着夜晚的来临，迅速减少到几乎零。

最终解决这个问题就像从我们的肩膀上卸下一块重担。

省流总结如下：

- 公司在推出付费订阅功能后的一个小时内获得了第一个付费用户。
- 第二天早上，收到了超过 40 封用户投诉的邮件，原因不明。
- 在五天时间里，持续收到投诉邮件，但工作时间几乎没有投诉。
- 问题源于一个代码行，导致唯一 ID 冲突，使其他用户无法订阅。
- 问题五天后解决，销售额损失约 10,000 美元。（50 emails/day x 5 days x 40ℎ=10,000 美金）
- 尽管经历了痛苦的五天，公司对此并不后悔，反而将其视为创业过程中难忘的一刻。

在这个案例中，他们在数据库写入时设置了用户 ID 为一个固定值，导致每次写入都发生冲突，最终导致用户无法完成注册和付款流程。

这个错误的根本原因是他们在编写 ORM 代码时将用户 ID 设置为常量值，而不是唯一的标识符。

Reference