支付系統(tǒng)的崩潰往往始于一行"看起來正確"的代碼。VibeCode Arena創(chuàng)始人最近放出一道測試題：檢查訂單是否已支付，若否則扣款。邏輯無懈可擊，但47個參測AI模型中，絕大多數(shù)都栽在同一個坑里——它們沒看懂并發(fā)請求。

一道題，拆穿AI的"偽安全"

測試場景并不復雜：用戶點擊支付，網(wǎng)絡(luò)抖動觸發(fā)重試，兩筆請求同時抵達服務(wù)器。人類工程師的噩夢在此——第一筆請求檢查"未支付"，第二筆請求也檢查"未支付"，兩筆都通過了。結(jié)果是用戶被扣兩次錢。

參測模型表現(xiàn)分化明顯。部分能識別基礎(chǔ)狀態(tài)校驗，少數(shù)提及重試機制，但真正理解冪等性（idempotency，指同一操作執(zhí)行多次與執(zhí)行一次效果相同）設(shè)計的寥寥無幾。更諷刺的是，有些模型的回答讀起來像安全手冊，代碼里卻留著明顯的競態(tài)條件窗口。

出題人把這道題命名為"雙重扣款風險"。命名很直白，但AI們似乎更擅長解釋概念，而非識別代碼里的時間縫隙。

為什么支付是AI的盲區(qū)

支付系統(tǒng)的危險不在于業(yè)務(wù)復雜，而在于失敗模式隱蔽。正常流程走一萬次都通，異常邊界只要觸發(fā)一次就是資損。AI訓練數(shù)據(jù)里充斥著"正確"的代碼示例，卻鮮少包含生產(chǎn)事故的尸檢報告。

更深層的問題在于上下文缺失。模型看到的是一個孤立函數(shù)，看不到網(wǎng)關(guān)超時配置、看不到數(shù)據(jù)庫隔離級別、看不到下游渠道的異步通知延遲。這些才是決定"檢查-扣款"兩步操作是否原子化的關(guān)鍵變量。

有模型在回答中自信地寫下"此方案已考慮并發(fā)安全"，附帶的代碼卻連事務(wù)邊界都沒加。這種自信比無知更麻煩——它可能讓審查者放松警惕。

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

測試發(fā)起人沒有公開點名哪些模型表現(xiàn)最差，但數(shù)據(jù)足夠說明問題：當問題從"寫一段支付代碼"變成"找出這段代碼哪里會賠錢"，AI的勝率斷崖式下跌。

這指向一個被忽視的評估維度。行業(yè)熱衷用LeetCode風格題目測試模型，但生產(chǎn)環(huán)境的bug往往藏在"看起來對的邏輯"里。支付、庫存、資金劃轉(zhuǎn)——這些領(lǐng)域容錯率為零，卻極少出現(xiàn)在基準測試集中。

出題人在挑戰(zhàn)頁底部留了一句話："支付不是關(guān)于成功處理一次，而是關(guān)于確保永遠不會意外處理兩次。"這句話被47個模型中的大多數(shù)引用或改寫，但只有個位數(shù)真正在代碼層面實現(xiàn)了它。

測試仍在開放，新的模型版本陸續(xù)加入。一個值得觀察的細節(jié)是：那些在第一輪失敗的模型，經(jīng)過針對性微調(diào)后，能否識別出同一類問題的變體？還是說，它們只是學會了回答"并發(fā)安全很重要"，而非真正理解時間片交錯時的狀態(tài)機？