去年雙11，某電商平臺凌晨2點(diǎn)爆發(fā)重復(fù)扣款投訴。用戶剛付完尾款，銀行卡又被劃走一筆。技術(shù)團(tuán)隊復(fù)盤發(fā)現(xiàn)：一段"看起來正確"的支付校驗(yàn)代碼，在并發(fā)請求下形同虛設(shè)。

這不是孤例。支付系統(tǒng)的并發(fā)漏洞，每年讓全球商戶損失超120億美元。更麻煩的是，這類問題在代碼審查時極難發(fā)現(xiàn)——單線程測試永遠(yuǎn)通過，高并發(fā)場景瞬間崩盤。

我設(shè)計了一個陷阱，AI集體踩坑

最近我在VibeCode Arena發(fā)布了一道支付安全挑戰(zhàn)題。規(guī)則很簡單：一段基礎(chǔ)支付校驗(yàn)邏輯，要求AI找出重復(fù)扣款風(fēng)險。

代碼邏輯看起來無懈可擊：先查詢訂單狀態(tài)，若未支付則扣款并標(biāo)記。但這里藏著經(jīng)典的競態(tài)條件（Race Condition，多線程/多進(jìn)程爭搶同一資源導(dǎo)致的數(shù)據(jù)混亂）陷阱——兩個請求同時讀到"未支付"，會各自執(zhí)行扣款。

測試結(jié)果顯示：主流AI模型對基礎(chǔ)校驗(yàn)的識別率約60%，但能理解并發(fā)風(fēng)險的不足15%。更少的模型考慮到網(wǎng)絡(luò)重試場景——用戶點(diǎn)擊支付后斷網(wǎng)，重連時觸發(fā)二次請求，這在移動端支付中占比高達(dá)7.3%。

冪等性（Idempotency，同一操作執(zhí)行多次與執(zhí)行一次效果相同）設(shè)計是支付系統(tǒng)的核心防線，但多數(shù)AI輸出里這個詞只是被"提及"，而非被"實(shí)現(xiàn)"。

為什么AI搞不定？

支付系統(tǒng)的復(fù)雜性不在代碼行數(shù)，而在狀態(tài)機(jī)的時序博弈。人類工程師的經(jīng)驗(yàn)在于：見過2點(diǎn)47分的生產(chǎn)事故，知道"理論上不會發(fā)生的"場景每周都在發(fā)生。

AI的訓(xùn)練數(shù)據(jù)里不缺正確的代碼示例，但缺少"錯誤的代碼如何導(dǎo)致凌晨被叫醒"的上下文。它能把冪等性鍵（Idempotency Key，用于標(biāo)識同一筆請求的唯一令牌）的定義背得滾瓜爛熟，卻想不到要在數(shù)據(jù)庫層加唯一索引——因?yàn)楹笳呤沁\(yùn)維教訓(xùn)，不是文檔知識。

一位支付架構(gòu)師曾向我吐槽：面試時讓候選人手寫防重邏輯，10個里有7個漏掉分布式鎖。AI的表現(xiàn)，大概相當(dāng)于這7個人里代碼寫得最工整的那個。

人機(jī)協(xié)作的邊界在哪

挑戰(zhàn)發(fā)布后，有開發(fā)者嘗試用AI輔助生成支付代碼，再人工審計并發(fā)場景。這種"AI寫初稿+人類找坑"的模式，效率提升約40%，但審計時間不能壓縮——省下的編碼時間，必須全額投入邊界條件排查。

另一個發(fā)現(xiàn)是：當(dāng)提示詞明確要求"考慮網(wǎng)絡(luò)超時、重試、并發(fā)"時，AI輸出質(zhì)量顯著提升。但這恰恰暴露了問題——如果使用者不知道要防什么，AI也不會主動提醒。

支付系統(tǒng)的終極安全，依賴的是"防御性編程"的肌肉記憶。人類工程師看到查詢語句，本能地想到加鎖；看到異步回調(diào)，本能地想到超時兜底。這種直覺來自被坑過的經(jīng)驗(yàn)，而非算法優(yōu)化目標(biāo)。

目前VibeCode Arena的這道題，通過率仍低于20%。評論區(qū)最高贊的反饋是："我以為AI懂支付，直到我看到它用Redis緩存當(dāng)唯一性校驗(yàn)。"

你會把核心支付鏈路交給AI獨(dú)立完成嗎？還是說，有些代碼注定需要人類親手寫下第一行？