联创用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，但这个数字在漫漫长夜中很快归零。在最终解决了这个问题后，我们感到如释重负。

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

总结 

回想起来，无论那五天过得有多么煎熬，都将成为我们永远无法忘怀的一段创业经历。如今的我们终于能以轻松的心态回顾那段日子，调侃说我们本该多做点测试、也不该贸然照搬 chatgpt 生成的代码，更需要在提交之前多加考量。

但毕竟这就是人生，这就是从无到有的创业体验。

参考链接：