支付系統(tǒng)的代碼看起來永遠(yuǎn)是對的——直到用戶被扣了兩次錢。

谷歌工程師Mishal Rahman最近在VibeCode Arena上拋出一個測試：一段看似無懈可擊的支付校驗(yàn)代碼，AI能不能發(fā)現(xiàn)其中的并發(fā)漏洞？

他給出的邏輯很簡單：先檢查這筆支付是否已處理，沒有就執(zhí)行扣款。這個寫法在單線程演示里跑得通，但Mishal知道，真正的支付系統(tǒng)里藏著三個定時炸彈——網(wǎng)絡(luò)重試、并發(fā)請求、冪等失效。

測試結(jié)果顯示，大部分AI模型只做了"表面體檢"。

有的能識別基礎(chǔ)重復(fù)校驗(yàn)，有的直接漏掉并發(fā)場景，極少數(shù)真正理解"冪等性"（idempotency，同一操作多次執(zhí)行結(jié)果一致）的設(shè)計原理。Mishal在挑戰(zhàn)說明里寫得直白：「支付不是關(guān)于成功處理一次，而是確保永遠(yuǎn)不會意外處理兩次?！?/p>

為什么這個漏洞特別陰？

想象你在地鐵閘機(jī)前刷碼，網(wǎng)絡(luò)卡了一下，你本能地又點(diǎn)了一次。兩秒后，扣款短信來了兩條。

這不是用戶手賤，是系統(tǒng)沒做好"防抖"。Mishal設(shè)計的測試場景正是這類高頻事故：兩個請求同時抵達(dá)，都讀到"未支付"狀態(tài)，都執(zhí)行了扣款。數(shù)據(jù)庫最終只存了一條記錄，但用戶錢包少了兩份錢。

更麻煩的是事后追溯。銀行流水顯示兩筆獨(dú)立交易，客服系統(tǒng)里卻查不到異常標(biāo)記。用戶投訴時，技術(shù)團(tuán)隊得從日志海里撈針，證明這是系統(tǒng)缺陷而非惡意重復(fù)提交。

國內(nèi)某頭部支付平臺2023年Q2的故障復(fù)盤顯示，類似并發(fā)問題占支付類客訴的12%，平均解決周期4.7天——足夠用戶在社交媒體完成三輪維權(quán)發(fā)酵。

AI寫代碼的盲區(qū)在哪

Mishal的測試暴露了一個尷尬現(xiàn)實(shí)：當(dāng)前AI模型擅長"代碼能跑"，但對"代碼在什么情況下會崩"缺乏體感。

它們能生成標(biāo)準(zhǔn)的冪等鍵校驗(yàn)?zāi)０?，卻理解不了"分布式鎖超時后要不要釋放"這種工程權(quán)衡。能識別try-catch塊，但猜不到網(wǎng)絡(luò)分區(qū)時異常拋出的時機(jī)。換句話說，AI學(xué)到了代碼的形狀，沒學(xué)到故障的氣味。

一位參與測試的工程師在評論區(qū)寫道：「我讓Claude 3.7分析這段代碼，它給出了三種修復(fù)方案，但都沒提到競態(tài)條件。直到我明確問'兩個請求同時進(jìn)來會怎樣'，它才恍然大悟?！?/p>

這種"提示詞依賴癥"在關(guān)鍵系統(tǒng)里很危險。支付代碼的reviewer不能是個需要反復(fù)引導(dǎo)的學(xué)生。

工程師的應(yīng)對策略

Mishal沒有把測試做成AI批判大會。他在挑戰(zhàn)頁面附上了防御性設(shè)計的檢查清單：數(shù)據(jù)庫唯一約束、分布式鎖、冪等鍵生命周期管理、異步對賬補(bǔ)償。

這些不是新概念，但組合執(zhí)行的門檻被低估了。國內(nèi)某金融科技團(tuán)隊的實(shí)踐是，支付鏈路必須過三道閘——網(wǎng)關(guān)層的令牌去重、服務(wù)層的樂觀鎖、賬務(wù)層的日終對賬。任一環(huán)節(jié)觸發(fā)攔截，整條請求進(jìn)入人工復(fù)核隊列。

成本是有的。這套架構(gòu)讓單筆支付的處理延遲從80ms漲到220ms，但去年避免了約1.2億元的重復(fù)扣款風(fēng)險敞口。

Mishal的測試鏈接目前仍開放，已有超過4000次提交。他最近更新了一條狀態(tài)：「最滿意的答案來自一個團(tuán)隊，他們用形式化驗(yàn)證工具證明了修復(fù)方案的正確性——不是生成代碼，是證明代碼不會錯。」

當(dāng)AI能寫出通過單元測試的支付代碼時，人類工程師的價值或許正在向"定義什么才算通過"遷移。你會把支付系統(tǒng)的核心校驗(yàn)完全交給AI嗎，還是堅持保留一道人工簽入的閘門？