联创用ChatGPT写的一行代码让公司损失上万美元！网友：老板自己写的，找不到人背锅了_生成式 AI



 写点什么



大小：1.14M时长：06:37

联创用ChatGPT写的一行代码让公司损失上万美元！网友：老板自己写的，找不到人背锅了

编者按：ChatGPT 在编程时的使用已经非常广泛。近日，一支国外技术团队在利用 ChatGPT 生成代码进行开发时遇到了严重的问题，导致了他们的订阅功能崩溃，并且给业务带来了重大损失。尽管 ChatGPT 等 AI 工具在编程领域具有潜力，但它们并不总是能够提供完美或适用于特定场景的解决方案。在这种情况下，如果技术团队过于依赖这些工具，并在时间压力下被迫做出决策，那最终的结果往往都是不乐观的。

本文作者正是上述团队中的一名软件工程师，也是 Reworkd 的联合创始人。Reworkd 是一家 YC S23 公司，从网络中提取结构化数据。他们还制作了智能化分析问题的工具 AgentGPT。以下内容由 InfoQ 整理并翻译。

作者声明：首先强调一点，本文提及的作法问题很大，本可避免。但一切都是时间紧迫之下匆忙行动下的后果。请大家在阅读时多多谅解，嘴下留情。

虽然系统仍在运行，但订阅功能却挂掉了……或者说是死而不僵……

去年 5 月，我们首次尝试靠自己的初创业务赚钱。我们的期望不高，因此在发布后不到一个小时就迎来第一位客户时，我们感到万分惊喜。那是个奇迹般的时刻，我们向用户表达了谢意。而且考虑到之前的准备工作花了整整两个晚上，所以我们信心满满地上床休息了。

第二天早上醒来时，我们收到 40 多条用户投诉的邮件通知。看似靠谱的系统似乎在一夜之间崩溃决堤，而问题只有一个——用户无法订阅。我们根本不知道是怎么搞的。

我们的货币化之路

先介绍一点业务背景。今年 5 月 YC 第 23 赛季正式启动，我们也不太确定产品发布之后该怎么盈利。我们的 YC 团队合伙人 Dalton 建议一切以付费用户为中心，并提出应该将我们预先想好的月费数字翻个倍。最终（虽然很不情愿），我们定下了每月 40 美元的价格。会议结束之后，我们立即着手设计商业模式。我们的项目最初采用全栈 NextJS，但后来打算将所有内容迁移至 Python/FastAPI。在 ChatGPT 的帮助下，我们顺利完成了工作，实现了 stripe 的全面集成……问题爆发后，我们又冲刺了整整五天时间，那也是我们整个月内最夜不能寐的五个日夜。

在这五天里，我们既难以入睡、又很害怕醒来——因为每天起床，我们都会收到好几十封投诉邮件。哪怕如今事情过去，我也不禁会想这次的问题让我们失去了多少客户。

按照每天 50 封邮件、每周 5 天、每位订户 40 美元的数字来计算，意味着单是在愿意表达意见的这部分用户中就出现了 1 万美元的销售损失。而且请大家注意，愿意发声的永远只是一小部分。我们每天都会准时回复这些邮件。大家会抱怨点击订阅时加载图标没完没了地旋转，而我们则会尝试开设新账户来亲自验证。在我们这边订阅流程顺利进行，于是一切在摸不着头脑之下继续保持原样。我们用尽了种种办法，但根本无法重现这个问题。更奇怪的是，在进入上班时间之后，几乎就不再新增任何投诉了。

价值上万美元的幻觉

单从感受出发，从发现问题到真正解决问题的那段前列时光就像是过去了好几个月。在这五天当中，我们收到了无数电子邮件、数百条监控日志、跟 stripe 工程师们在 discord 上随时交流。最终在花了几个小时盯着 5 个关键文件后，我们终于搞清了真相。线索就在以下截屏当中，感兴趣的朋友可以先别急着下翻，试试能不能自行找到答案。

如果没找到也不要紧，其中的罪魁祸首就是下面这行看似无辜的代码。这行代码也让我们遭遇到人生中最折磨的一个礼拜，并让我们确确实实损失掉了上万美元。一起来看这第 56 行：

事情是这样的：作为后端迁移的一部分，我们将数据库模型从 Prisma/Typescript 转换为 Python/SQLAlchemy。整个过程非常繁琐，而我们发现 ChatGPT 在执行这类转换时表现相当出色，于是我们在整个迁移过程中几乎随时都在使用它。

我们复制粘贴了它生成的代码，发现一切运行良好；之后又在生产中进行测试，结果也同样有效。于是我们兴高采烈地推进，却忘记了此时我们仍在使用 Next API 进行数据库插入，且 Python 代码只负责从数据库中读取。我们第一次开始在 Python 中实际插入数据库记录是在订阅功能的实现阶段，虽然我们为此手动创建了全新的 SQLAlchemy 模型，但最终却仍然照搬了 ChatGPT 为原有模型编写的旧格式代码。当时的我们根本没意识到，所有模型当中的 ID 生成方式都已经出了问题。

Bug 围剿行动

第 56 行中的问题在于，我们只是传入了一条硬编码的 ID 字符串，而非使用函数或 lambda 来为我们的记录生成 UUID。也就是说，对于我们后端中的任何给定实例，一旦单个新用户订阅并使用此 ID，其他用户就无法再次执行订阅流程，因为这会导致唯一 ID 冲突。但受我们后端设置的影响，这个问题被严严实实地隐蔽了起来。

我们在亚马逊云科技上运行有 8 项 ECS 任务，它们全都运行着我们后端的 5 个实例（这确实只能算过渡性方案，但我们手头正好有不少亚马逊积分，换作是各位肯定也会照此办理）。也就是说任何单一用户都面对着包含 40 个唯一 ID 的资源池，也是他们能够成功订阅的最高上限。

工作日期间之所以一切运转良好，就是因为我们的日均提交次数大概在 10 到 20 次（当然是直接提交至主服务器），进而触发新的后端部署操作，从而为我们提供 40 个可供客户使用的新 ID。然而到了晚间，当我们不再执行提交，这些服务器上的可用 ID 就会被快速耗尽，并导致所有后续订阅遭遇 ID 冲突。用户虽然刚开始有 40 个服务器订阅 ID，但这个数字在漫漫长夜中很快归零。在最终解决了这个问题后，我们感到如释重负。

在发现问题并迅速提出修复方案之后，我们终于能够踏踏实实睡觉、不用担心第二天被用户们骂醒了（也不尽然，期间我们还出过其他好几次事故，但这就是另外的故事了）。