我們將資料庫模型從 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美金