国外创业公司 Reworkd 分享了他们从 ChatGPT 直接复制代码，并因此“踩坑”的经历。
根据描述，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设置为常量值，而不是唯一的标识符。
相关阅读
这是python经典的设计失误之一。