谷歌工程師埋了道支付題：47個AI模型集體踩了同一個坑

去年全球支付故障造成的直接損失超過118億美元。這個數字背后，往往不是代碼寫錯了，而是工程師沒想到"同一筆錢會被扣兩次"。

一位前Stripe工程師最近干了件事：他在VibeCode Arena（一個AI編程挑戰平臺）發布了一道看似簡單的支付防重題。結果47個AI模型參與測試，真正通過并發場景的不到4個。

題目看起來像個送分題

系統邏輯白紙黑字：先檢查這筆訂單是否已支付，沒付就扣款，付了直接返回。人類工程師掃一眼就能寫出的代碼，AI卻集體翻車。

問題藏在兩個AI"看不見"的角落。網絡超時后自動重試——這是支付系統的標配，但多數模型把它當成"不可能發生"的邊緣情況。更隱蔽的是并發窗口：兩個請求同時讀到"未支付"，同時扣款，用戶賬戶瞬間被劃走雙倍金額。

這位工程師把這種現象叫做"偽安全"——代碼跑起來沒問題，測試環境也正常，一上生產環境就埋雷。

AI的盲區，恰恰是人類的日常

測試結果顯示，AI模型在單線程場景表現穩定，但一旦引入并發壓力，失敗率飆升到89%。最典型的一類錯誤：模型加了數據庫鎖，卻鎖在了錯誤的位置——檢查狀態和扣款動作之間仍有縫隙。

另一位支付架構師在評論區補刀：「我們生產環境去年處理過230萬次重試請求，其中1.2%觸發了競態條件。這個數字聽起來小，乘以日均交易量就是真金白銀。」

真正懂支付的工程師會設計"冪等鍵"（idempotency key，即唯一標識符）——每筆交易帶一個不會重復的令牌，系統憑這個令牌拒絕重復處理。但測試中只有不到8%的AI模型主動實現了這一機制。

為什么AI學不會"怕"

訓練數據可能是元兇。GitHub上開源的支付代碼大多展示" happy path "（理想流程），異常處理、熔斷降級、冪等設計這些臟活累活，往往躺在公司的私有倉庫里。

AI學到的更多是"代碼能跑"，而非"系統能扛"。一位參與測試的Claude用戶反饋：「它給我寫的代碼邏輯自洽，但我追問'如果網絡抖動導致重試呢'，它才恍然大悟地補上一段補丁。」

這種"追問才修復"的模式，在支付場景里等于讓用戶當小白鼠。

人類還在哪些環節不可替代

Stripe、Adyen這些支付巨頭的工程師有個共同習慣：寫代碼前先畫"故障樹"——窮盡所有可能出錯的節點，再針對性設計防御。這種逆向思維，目前仍是AI的短板。

那位出題工程師最后放了一句話：「我不會用AI生成直接對接資金系統的代碼，但會用它快速生成測試用例——尤其是人類容易遺漏的并發場景。」

這道題的鏈接至今掛在VibeCode Arena首頁，通過率從4%緩慢爬升到11%。最新一條評論來自某金融科技公司的QA負責人：「我把這題丟給團隊里的初級工程師，三個人里兩個踩了同樣的坑。」

如果AI暫時學不會"怕"，那人類工程師的怕，該由誰來兜底？