企業(yè)級 Agents 開發(fā)實戰(zhàn)營》重磅上線，10 周帶你進行工具、對話及多模態(tài)等不同類型 Agents 工程化開發(fā)實戰(zhàn)！

編者按：ChatGPT 在編程時的使用已經(jīng)非常廣泛。近日，一支國外技術(shù)團隊在利用 ChatGPT 生成代碼進行開發(fā)時遇到了嚴重的問題，導(dǎo)致了他們的訂閱功能崩潰，并且給業(yè)務(wù)帶來了重大損失。盡管 ChatGPT 等 AI 工具在編程領(lǐng)域具有潛力，但它們并不總是能夠提供完美或適用于特定場景的解決方案。在這種情況下，如果技術(shù)團隊過于依賴這些工具，并在時間壓力下被迫做出決策，那最終的結(jié)果往往都是不樂觀的。

本文作者正是上述團隊中的一名軟件工程師，也是 Reworkd 的聯(lián)合創(chuàng)始人。Reworkd 是一家 YC S23 公司，從網(wǎng)絡(luò)中提取結(jié)構(gòu)化數(shù)據(jù)。他們還制作了智能化分析問題的工具 AgentGPT。以下內(nèi)容由 InfoQ 整理并翻譯。

作者聲明：首先強調(diào)一點，本文提及的作法問題很大，本可避免。但一切都是時間緊迫之下匆忙行動下的后果。請大家在閱讀時多多諒解，嘴下留情。

 

雖然系統(tǒng)仍在運行，但訂閱功能卻掛掉了……或者說是死而不僵……

去年 5 月，我們首次嘗試靠自己的初創(chuàng)業(yè)務(wù)賺錢。我們的期望不高，因此在發(fā)布后不到一個小時就迎來第一位客戶時，我們感到萬分驚喜。那是個奇跡般的時刻，我們向用戶表達了謝意。而且考慮到之前的準備工作花了整整兩個晚上，所以我們信心滿滿地上床休息了。

第二天早上醒來時，我們收到 40 多條用戶投訴的郵件通知。看似靠譜的系統(tǒng)似乎在一夜之間崩潰決堤，而問題只有一個——用戶無法訂閱。我們根本不知道是怎么搞的。

我們的貨幣化之路

先介紹一點業(yè)務(wù)背景。今年 5 月 YC 第 23 賽季正式啟動，我們也不太確定產(chǎn)品發(fā)布之后該怎么盈利。我們的 YC 團隊合伙人 Dalton 建議一切以付費用戶為中心，并提出應(yīng)該將我們預(yù)先想好的月費數(shù)字翻個倍。最終（雖然很不情愿），我們定下了每月 40 美元的價格。會議結(jié)束之后，我們立即著手設(shè)計商業(yè)模式。我們的項目最初采用全棧 NextJS，但后來打算將所有內(nèi)容遷移至 Python/FastAPI。在 ChatGPT 的幫助下，我們順利完成了工作，實現(xiàn)了 stripe 的全面集成……問題爆發(fā)后，我們又沖刺了整整五天時間，那也是我們整個月內(nèi)最夜不能寐的五個日夜。

在這五天里，我們既難以入睡、又很害怕醒來——因為每天起床，我們都會收到好幾十封投訴郵件。哪怕如今事情過去，我也不禁會想這次的問題讓我們失去了多少客戶。

按照每天 50 封郵件、每周 5 天、每位訂戶 40 美元的數(shù)字來計算，意味著單是在愿意表達意見的這部分用戶中就出現(xiàn)了 1 萬美元的銷售損失。而且請大家注意，愿意發(fā)聲的永遠只是一小部分。我們每天都會準時回復(fù)這些郵件。大家會抱怨點擊訂閱時加載圖標沒完沒了地旋轉(zhuǎn)，而我們則會嘗試開設(shè)新賬戶來親自驗證。在我們這邊訂閱流程順利進行，于是一切在摸不著頭腦之下繼續(xù)保持原樣。我們用盡了種種辦法，但根本無法重現(xiàn)這個問題。更奇怪的是，在進入上班時間之后，幾乎就不再新增任何投訴了。

價值上萬美元的幻覺

單從感受出發(fā)，從發(fā)現(xiàn)問題到真正解決問題的那段前列時光就像是過去了好幾個月。在這五天當中，我們收到了無數(shù)電子郵件、數(shù)百條監(jiān)控日志、跟 stripe 工程師們在 discord 上隨時交流。最終在花了幾個小時盯著 5 個關(guān)鍵文件后，我們終于搞清了真相。線索就在以下截屏當中，感興趣的朋友可以先別急著下翻，試試能不能自行找到答案。

 

如果沒找到也不要緊，其中的罪魁禍首就是下面這行看似無辜的代碼。這行代碼也讓我們遭遇到人生中最折磨的一個禮拜，并讓我們確確實實損失掉了上萬美元。一起來看這第 56 行：

 

事情是這樣的：作為后端遷移的一部分，我們將數(shù)據(jù)庫模型從 Prisma/Typescript 轉(zhuǎn)換為 Python/SQLAlchemy。整個過程非常繁瑣，而我們發(fā)現(xiàn) ChatGPT 在執(zhí)行這類轉(zhuǎn)換時表現(xiàn)相當出色，于是我們在整個遷移過程中幾乎隨時都在使用它。

我們復(fù)制粘貼了它生成的代碼，發(fā)現(xiàn)一切運行良好；之后又在生產(chǎn)中進行測試，結(jié)果也同樣有效。于是我們興高采烈地推進，卻忘記了此時我們?nèi)栽谑褂?Next API 進行數(shù)據(jù)庫插入，且 Python 代碼只負責從數(shù)據(jù)庫中讀取。我們第一次開始在 Python 中實際插入數(shù)據(jù)庫記錄是在訂閱功能的實現(xiàn)階段，雖然我們?yōu)榇耸謩觿?chuàng)建了全新的 SQLAlchemy 模型，但最終卻仍然照搬了 ChatGPT 為原有模型編寫的舊格式代碼。當時的我們根本沒意識到，所有模型當中的 ID 生成方式都已經(jīng)出了問題。

Bug 圍剿行動

第 56 行中的問題在于，我們只是傳入了一條硬編碼的 ID 字符串，而非使用函數(shù)或 lambda 來為我們的記錄生成 UUID。也就是說，對于我們后端中的任何給定實例，一旦單個新用戶訂閱并使用此 ID，其他用戶就無法再次執(zhí)行訂閱流程，因為這會導(dǎo)致唯一 ID 沖突。但受我們后端設(shè)置的影響，這個問題被嚴嚴實實地隱蔽了起來。

我們在亞馬遜云科技上運行有 8 項 ECS 任務(wù)，它們?nèi)歼\行著我們后端的 5 個實例（這確實只能算過渡性方案，但我們手頭正好有不少亞馬遜積分，換作是各位肯定也會照此辦理）。也就是說任何單一用戶都面對著包含 40 個唯一 ID 的資源池，也是他們能夠成功訂閱的最高上限。