文章摘要
在一次创业尝试中，一支技术团队利用 ChatGPT 生成代码进行开发，结果导致订阅功能崩溃，给业务带来了重大损失。尽管 ChatGPT 等 AI 工具在编程领域具有潜力，但它们并不总是能够提供完美或适用于特定场景的解决方案。团队在时间压力下依赖这些工具，最终导致了不乐观的结果。
去年5月，团队首次尝试通过初创业务赚钱，发布后不到一个小时就迎来了第一位客户。然而，第二天早上，他们收到了40多条用户投诉，问题集中在用户无法订阅。团队在不知所措的情况下，开始了艰难的排查过程。
团队的项目最初采用全栈 NextJS，后来迁移至 Python/FastAPI，并在 ChatGPT 的帮助下实现了 Stripe 的全面集成。然而，问题爆发后，他们花了五天时间进行修复。这五天里，他们每天都收到大量投诉邮件，用户抱怨订阅时加载图标不停旋转。团队尝试各种方法验证问题，但始终无法重现。
经过数天的努力，团队终于发现问题出在数据库模型的迁移过程中。作为后端迁移的一部分，他们将数据库模型从 Prisma/Typescript 转换为 Python/SQLAlchemy。ChatGPT 在执行这类转换时表现出色，团队几乎全程使用它生成的代码。然而，他们忽略了一个关键问题：所有模型中的 ID 生成方式出了问题。具体来说，第56行代码中，团队传入了一条硬编码的 ID 字符串，而非使用函数或 lambda 来生成 UUID。这导致每个新用户订阅时，都会遇到唯一 ID 冲突的问题。
团队在亚马逊云科技上运行了8项 ECS 任务，每项任务运行5个后端实例。每个实例有40个唯一 ID 的资源池，用户能够成功订阅的最高上限也是40个。工作日期间，日均提交次数在10到20次，触发新的后端部署操作，为客户提供新的 ID。然而，到了晚间，当不再执行提交时，这些服务器上的可用 ID 很快耗尽，导致所有后续订阅遭遇 ID 冲突。
最终，团队发现并修复了这个问题，终于能够安心睡觉，不再担心第二天被用户投诉邮件吵醒。尽管期间还发生了其他几次事故，但这次经历成为他们永远无法忘怀的一段创业经历。团队总结道，他们本该多做测试、不该贸然照搬 ChatGPT 生成的代码，更需要在提交之前多加考量。这次经历教会了他们在创业过程中，谨慎和细致的重要性。
原文和模型
【原文链接】 阅读原文 [ 2265字 | 10分钟 ]
【原文作者】 AI前线
【摘要模型】 gpt-4o
【摘要评分】 ★★★★★
