我们将数据库模型从 Prisma/Typescript 转换为 Python/SQLAlchemy。这真的很繁琐。我们发现 ChatGPT 在进行这种转换时做得非常出色，因此我们几乎在整个迁移过程中都使用它。我们复制粘贴了它生成的代码，看到一切正常，在生产中试用了它，看到它也有效，然后就高高兴兴地继续一直做。
然后，我们复制的代码中生成 ID 有问题：
- 代码只是传入了一个硬编码的 ID 字符串，而不是函数或 lambda 来为我们的记录生成 UUID。
- 这意味着一旦有新用户订阅并使用此 ID，其他用户就无法再次执行订阅流程，因为这会导致唯一 ID 冲突。
在工作日，这没什么问题。我们每天可能提交 10-20 次（当然是直接提交到主服务器），这将导致新的后端部署发生，从而为我们提供 40 个可能供客户使用的新 ID。
- 然而到了晚上，当我们终于停止提交时，每个服务器中的单个 ID 都会被捕获，并导致所有新订阅发生 ID 冲突
- 用户一开始会有 40 个可能允许他们订阅的服务器，但随着夜晚的推移，很快就会接近零。
在那五天里，早上我们醒来时，发现有超过 40 条 Gmail 用户投诉通知。
我们开始害怕醒来——因为我们知道我们只会收到 30/40/50 封投诉邮件。
50 emails/day x 5 days x 40ℎ=10,000美金