ChatGPT “背锅”？直接复制其代码，损失 10000 美元，服务停了 5 天|python|代码|服务器|编程

编译 | 屠敏

出品 | CSDN（ID：CSDNnews）

ChatGPT 以及生成式 AI 工具快速发展的一年多时间里，有多少人使用了这些工具生成的代码来搞项目，还将其投入生产环境中？

根据 CSDN 调查数据显示，过去一年里，41% 的开发者有用过 AI 工具生成代码，29% 的人借助 AI 帮自己解释 Bug 并提供修正建议，以及 28% 的人生成过代码注释或者代码文档。

图：开发者主要使用 AI 编程辅助工具的用途，来源：CSDN《2024 中国开发者调查报告》

显而易见，AI 已经渗透到开发者日常开发工作中。但是需要注意的事，使用这类 AI 生成的代码还需留点“心思”，否则一不小心可能就会落入代码埋下的陷阱中。

此前，国外一家初创公司 Reworkd 就遇到过这样的事情，其联合创始人 Asim Shrestha 发文分享了这段一招不慎导致许多用户无法付费订阅服务的经历，最终也导致这家刚起步的初创公司损失超过 1 万美元。

商业化起步就“摔了个跟头”

正如上文所述，作为一家初创公司，Reworkd 主要专注于开发自动化业务任务的 AI 代理平台，旨在解决需要大量人力介入的业务流程的低效问题。通过使用 AI 代理，Reworkd 帮助企业简化操作并减少手工工作量。这家公司得到 Y Combinator（为初创公司提供早期风险投资、创业指导等）的支持。

时间回到 2023 年 5 月，当时 Asim Shrestha 和他的项目团队开始考虑让 Reworkd 走上商业化的道路，但他们不知道具体该怎么做，或者做些什么。

后来，他们在 YC 小组合作伙伴 Dalton 指导下，尝试“让用户付费订阅自家的服务”。

最终，经过团队商议，Asim Shrestha 将服务订阅价格定在了每位用户每月 40 美元。

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

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

那个时候，很多开发者都在使用 ChatGPT 协助日常开发工作，该初创团队也想到可以借助这款 AI 工具来帮助其完成代码迁移工作，所以，他们的确这么干了，还顺便集成了 Stripe 支付系统......

项目迁移完成之后，Asim Shrestha 表示，“我们原本的期望不高，但当我们在启动后一小时内获得第一位客户时，我们感到非常惊喜。这是一个神奇的时刻。我们给他们发去了感谢信，互相敬了一杯，考虑到我们刚花了两个深夜准备好一切，我们很快就进入了梦乡。“

没想到，第二天一觉睡醒之后，Asim Shrestha 发现他们有超过 40 条的 Gmail 用户投诉通知，全是关于用户无法订阅服务的投诉。Asim Shrestha 与其项目团队并不知道到底发生了什么，但是他们清晰认识到，商业化之路起步就“摔了一个大跟头”。

更让团队感到奇怪的是，这个问题在工作时间并没有出现，而且无法重现。所以原以为是个代码小 Bug，却花了整个团队整整 5 天的时间来排查。

每天 50 封投诉邮件，损失至少过万

在那五天里，项目团队的每一个人都开始害怕醒来，因为一醒来就会看到 30-50 封的投诉邮件。

这意味着什么？Asim Shrestha 简单地算了一笔账：

每天 50 封邮件 x 5 天 x 40 美元/月（订阅服务费用）= 每月 10,000 美元的损失

而这些只是那些愿意投诉的客户。要想想，还有很多人发现不能订阅就主动放弃这个软件的使用，这也导致这部分的客户因此流失了。

“我们每天像时钟一样定时回复这些邮件。客户抱怨点击订阅时出现无限加载旋转图标，我们会通过开设一个新账户进行调查，确认订阅在我们这边完全正常，然后带着困惑继续工作。无论我们怎么做，都无法重现这个问题，更奇怪的是，在我们的实际工作时间里，几乎没有收到任何投诉”，Asim Shrestha 郁闷地说。

ChatGPT 生成的代码引发的错误

从发现问题到真正解决问题的过程中，团队每个人都感觉度日如年。在排查问题的五天里，Asim Shrestha 表示，「无数封邮件、成百上千条 Sentry 日志（用于监控和报告软件问题的工具）、与 Stripe 工程师在 Discord 上长篇对话、花了数小时盯着五个关键代码文件后，我们终于找到了问题」。

问题就在下面这段代码里：

作为程序员的你如果仔细看，应该也不难发现。罪魁祸首是一行看似无害的代码——第 56 行，这行代码是 Asim Shrestha 团队那一周的噩梦，给他们带来了 10,000 美元的损失。

其实关于这段代码由来，Asim Shrestha 也进行了详细解释。

作为项目后端迁移的一部分，该初创团队将数据库模型从 Prisma/Typescript 转换成 Python/SQLAlchemy，其中过程非常繁琐。

Asim Shrestha 发现 ChatGPT 在进行这种转换时表现非常出色，所以他们几乎在整个迁移过程中都使用了 ChatGPT。

“我们复制并粘贴了它生成的代码，发现一切运行正常，然后在生产环境中试用，发现也没有问题，于是我们高高兴兴地继续进行”，Asim Shrestha 说。

然而，此时该初创团队仍然使用 Next API 进行所有的数据库插入操作。Python 仅仅是从数据库读取数据。

「我们第一次在 Python 中实际插入数据库记录是在我们实现订阅功能时。虽然在这个过程中我们手动创建了全新的 SQLAlchemy 模型，但最终我们还是复制了 ChatGPT 为我们现有模型编写的格式。我们没有注意到的问题是，我们正在复制的代码在生成 ID 的方式上和之前模型有冲突。」

捕捉 Bug

第 56 行的代码问题在于，default=str(uuid.uuid4()) 这一部分代码在模块加载时（而不是每次插入数据时）执行一次，生成一个固定的 UUID。因为这个 UUID 是在类定义时就确定的，所以所有新插入的记录都会使用同一个 UUID，而不是每次生成一个新的唯一标识符。这违反了数据库主键的唯一性约束，会导致插入记录失败。

这意味着在此软件的后端实例中，一旦一个新用户订阅并使用了这个 ID，其他用户就无法再次执行订阅流程，因为会导致唯一 ID 冲突。

由于该软件的后端设置，这个问题变得非常隐蔽。Asim Shrestha 透露，“我们在 AWS 上运行了八个 ECS 任务，每个任务运行五个后端实例（是的，确实有些过头了，但公平地说，我们有 AWS 积分）。这意味着每个用户有可能遇到 40 个唯一的 ID。”

在工作日，这没有什么问题，因为该团队每天可能提交代码 10-20 次（当然是直接提交到 main 分支），这会导致新的后端部署，为客户提供 40 个新的 ID 可以使用。

然而，一到晚上，当该团队不再提交代码时，每个服务器中的单一 ID 会被使用完，导致所有新的订阅发生 ID 冲突。用户一开始会有 40 个可能允许他们订阅的服务器，但随着夜晚的到来，可用的 ID 几乎被用完了，这也就是为什么一到晚上，就收到了大量投诉邮件的原因。

结论

Asim Shrestha 表示，“最终解决这个问题就像是卸下了一块重担。团队成员在发现这个问题后迅速推送了修复程序，那一周我们终于可以轻松休息了。

现在回想起来，无论那五天有多么痛苦，那都是我们永远不会忘记的创业时刻。我们很高兴现在回首往事时能开怀大笑。是的，我们应该做更多的测试。是的，我们不应该复制粘贴代码。是的，我们不应该直接推送到主程序。”

随着 Asim Shrestha 此次经历的发出，也引发了不小的争议，有人质疑道：

没有测试当然不好。在没有三重检查的情况下使用 AI 做事是很危险的。但在数据库中没有错误日志/警报？这才是疯狂的地方。
这是一个新产品，不是 20 年前的遗留代码，当时他们认为把东西直接扔到数据库是个不错的主意，并检查数据库错误以进行数据验证，所以警报很难发出，因为有太多预期错误。
老实说，如果后端是用 Go 编写的，这种情况可能不会发生。日志中的某个地方会出现一个描述性错误。
我尽可能使用 Go 的原因之一是它消除了许多经典的 Python 麻烦。如果你要用 Javascript 重写后端，为什么要用另一种无类型、容易出错的语言重写它？
我立即发现了错误。尽管对你的团队表示尊重，但这与 ChatGPT 无关，而是与你的团队使用缺乏足够专业知识的编程模型有关。即使此错误设法通过代码审查，几乎任何监控解决方案都可以发现它，其中许多解决方案的设置时间不到 5 分钟。

也有人觉得该初创团队如果再次借助 ChatGPT 帮助，也不至于需要五天的时间来排查与解决，因为如果问 ChatGPT-4o 那段代码有什么问题时，它会直接给出解释与解决方法：

随着事情的发酵，Asim Shrestha 也在个人 X 账号上表示，“写了一篇博客，遭到了 Reddit 和 HN 上网友的猛烈批评，我不得不写一个免责声明：首先，我想说的是，这里的做法是不好的、令人尴尬的（后来已经更新了），是可以/应该避免的，是超越一切的人为错误，而且事后看来是非常明显的。这是在公司成立初期的犯下的错误，在大量时间的限制下发生的。”借此，也希望让更多的人在生产环境中使用 AI 生成的代码更加小心与谨慎。