支付系統(tǒng)的復(fù)雜度，常被界面上的"支付成功"四個字掩蓋。一位產(chǎn)品經(jīng)理在VibeCode Arena（一個AI代碼能力測試平臺）上發(fā)布了一道看似簡單的題目：防止重復(fù)扣款。結(jié)果超過80%的AI模型在并發(fā)場景下翻車——有的漏了網(wǎng)絡(luò)重試，有的干脆沒理解冪等性（idempotency，同一操作多次執(zhí)行結(jié)果一致）。這不是學(xué)術(shù)討論，是2023年Stripe因重復(fù)扣款被罰過的真實坑。

題目設(shè)計：一個"看起來對"的陷阱

挑戰(zhàn)的核心邏輯只有三步：檢查支付狀態(tài)→若未處理則扣款→標(biāo)記為已處理。單線程跑通毫無問題。但出題人埋了兩個現(xiàn)實世界的雷：網(wǎng)絡(luò)超時后的自動重試、幾乎同時到達(dá)的并發(fā)請求。

AI模型的典型死法高度一致：看到"if not paid then charge"就覺得任務(wù)完成，完全沒考慮兩個請求同時讀到"未支付"的瞬間。

測試結(jié)果顯示，部分模型能處理基礎(chǔ)的狀態(tài)校驗，少數(shù)提到了重試機(jī)制，但真正理解"分布式鎖+唯一請求ID"組合的寥寥無幾。一位通過測試的開發(fā)者評論：「這題考的不是代碼量，是吃過多少生產(chǎn)事故的虧。」

為什么AI會在這里集體失明

問題出在訓(xùn)練數(shù)據(jù)的分布。開源代碼庫里，支付相關(guān)的正確實現(xiàn)被包裹在業(yè)務(wù)層深處，AI學(xué)到的多是簡化教程里的"偽代碼"。并發(fā)控制、冪等設(shè)計這類需要工程血淚史才能內(nèi)化的知識，恰好是語料中的稀疏區(qū)。

更隱蔽的是，題目本身的描述帶有誤導(dǎo)性。"防止重復(fù)支付"被多數(shù)AI理解為"檢查一遍再操作"，而非"在分布式環(huán)境下保證原子性"。

出題人在復(fù)盤時打了個比方：「教AI寫支付代碼，就像用駕校模擬器教高速避險——場景對上了，肌肉記憶沒跟上。」

這道題的余波

挑戰(zhàn)發(fā)布后，VibeCode Arena的支付類題目參與量漲了3倍。有金融科技團(tuán)隊直接把它放進(jìn)工程師面試題庫，也有AI公司用它來標(biāo)注"需要人工復(fù)核"的高風(fēng)險生成代碼。

一個細(xì)節(jié)被反復(fù)提及：通過測試的模型中，有幾款明確引用了Stripe、Adyen等支付平臺的公開設(shè)計文檔作為推理依據(jù)。換句話說，當(dāng)AI能調(diào)用特定領(lǐng)域的工程實踐而非通用編程模式時，表現(xiàn)會躍升一個臺階。

出題人最后把挑戰(zhàn)鏈接永久開放，附了一句注釋：「如果你的AI助手要寫支付代碼，建議先讓它過一遍這題。不是信不過，是扣款短信發(fā)到用戶手機(jī)上的時候，道歉成本比較高。」

現(xiàn)在壓力給到了用AI生成代碼的開發(fā)者這邊——你會把這道測試加入自己的Code Review清單，還是賭自己的場景不會觸發(fā)那個并發(fā)窗口？