北京
支付系統(tǒng)的代碼看起來永遠是對的——直到用戶被扣了兩次錢。
谷歌工程師Mishal Rahman最近在VibeCode Arena上拋出一個測試：一段看似無懈可擊的支付校驗代碼，AI能不能發(fā)現(xiàn)其中的并發(fā)漏洞？
他給出的邏輯很簡單：先檢查這筆支付是否已處理，沒有就執(zhí)行扣款。這個寫法在單線程演示里跑得通，但Mishal知道，真正的支付系統(tǒng)里藏著三個定時炸彈——網(wǎng)絡重試、并發(fā)請求、冪等失效。
測試結(jié)果顯示，大部分AI模型只做了"表面體檢"。
有的能識別基礎重復校驗，有的直接漏掉并發(fā)場景，極少數(shù)真正理解"冪等性"（idempotency，同一操作多次執(zhí)行結(jié)果一致）的設計原理。Mishal在挑戰(zhàn)說明里寫得直白：「支付不是關于成功處理一次，而是確保永遠不會意外處理兩次。」
為什么這個漏洞特別陰？
想象你在地鐵閘機前刷碼，網(wǎng)絡卡了一下，你本能地又點了一次。兩秒后，扣款短信來了兩條。
這不是用戶手賤，是系統(tǒng)沒做好"防抖"。Mishal設計的測試場景正是這類高頻事故：兩個請求同時抵達，都讀到"未支付"狀態(tài)，都執(zhí)行了扣款。數(shù)據(jù)庫最終只存了一條記錄，但用戶錢包少了兩份錢。
更麻煩的是事后追溯。銀行流水顯示兩筆獨立交易，客服系統(tǒng)里卻查不到異常標記。用戶投訴時，技術團隊得從日志海里撈針，證明這是系統(tǒng)缺陷而非惡意重復提交。
國內(nèi)某頭部支付平臺2023年Q2的故障復盤顯示，類似并發(fā)問題占支付類客訴的12%，平均解決周期4.7天——足夠用戶在社交媒體完成三輪維權發(fā)酵。
AI寫代碼的盲區(qū)在哪
Mishal的測試暴露了一個尷尬現(xiàn)實：當前AI模型擅長"代碼能跑"，但對"代碼在什么情況下會崩"缺乏體感。
它們能生成標準的冪等鍵校驗模板，卻理解不了"分布式鎖超時后要不要釋放"這種工程權衡。能識別try-catch塊，但猜不到網(wǎng)絡分區(qū)時異常拋出的時機。換句話說，AI學到了代碼的形狀，沒學到故障的氣味。
一位參與測試的工程師在評論區(qū)寫道：「我讓Claude 3.7分析這段代碼，它給出了三種修復方案，但都沒提到競態(tài)條件。直到我明確問'兩個請求同時進來會怎樣'，它才恍然大悟。」
這種"提示詞依賴癥"在關鍵系統(tǒng)里很危險。支付代碼的reviewer不能是個需要反復引導的學生。
工程師的應對策略
Mishal沒有把測試做成AI批判大會。他在挑戰(zhàn)頁面附上了防御性設計的檢查清單：數(shù)據(jù)庫唯一約束、分布式鎖、冪等鍵生命周期管理、異步對賬補償。
這些不是新概念，但組合執(zhí)行的門檻被低估了。國內(nèi)某金融科技團隊的實踐是，支付鏈路必須過三道閘——網(wǎng)關層的令牌去重、服務層的樂觀鎖、賬務層的日終對賬。任一環(huán)節(jié)觸發(fā)攔截，整條請求進入人工復核隊列。
成本是有的。這套架構讓單筆支付的處理延遲從80ms漲到220ms，但去年避免了約1.2億元的重復扣款風險敞口。
Mishal的測試鏈接目前仍開放，已有超過4000次提交。他最近更新了一條狀態(tài)：「最滿意的答案來自一個團隊，他們用形式化驗證工具證明了修復方案的正確性——不是生成代碼，是證明代碼不會錯。」
當AI能寫出通過單元測試的支付代碼時，人類工程師的價值或許正在向"定義什么才算通過"遷移。你會把支付系統(tǒng)的核心校驗完全交給AI嗎，還是堅持保留一道人工簽入的閘門？
特別聲明：以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺“網(wǎng)易號”用戶上傳并發(fā)布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
