北京
支付系統的復雜度，常被界面上的"支付成功"四個字掩蓋。一位產品經理在VibeCode Arena（一個AI代碼能力測試平臺）上發布了一道看似簡單的題目：防止重復扣款。結果超過80%的AI模型在并發場景下翻車——有的漏了網絡重試，有的干脆沒理解冪等性（idempotency，同一操作多次執行結果一致）。這不是學術討論，是2023年Stripe因重復扣款被罰過的真實坑。
題目設計：一個"看起來對"的陷阱
挑戰的核心邏輯只有三步：檢查支付狀態→若未處理則扣款→標記為已處理。單線程跑通毫無問題。但出題人埋了兩個現實世界的雷：網絡超時后的自動重試、幾乎同時到達的并發請求。
AI模型的典型死法高度一致：看到"if not paid then charge"就覺得任務完成，完全沒考慮兩個請求同時讀到"未支付"的瞬間。
測試結果顯示，部分模型能處理基礎的狀態校驗，少數提到了重試機制，但真正理解"分布式鎖+唯一請求ID"組合的寥寥無幾。一位通過測試的開發者評論：「這題考的不是代碼量，是吃過多少生產事故的虧。」
為什么AI會在這里集體失明
問題出在訓練數據的分布。開源代碼庫里，支付相關的正確實現被包裹在業務層深處，AI學到的多是簡化教程里的"偽代碼"。并發控制、冪等設計這類需要工程血淚史才能內化的知識，恰好是語料中的稀疏區。
更隱蔽的是，題目本身的描述帶有誤導性。"防止重復支付"被多數AI理解為"檢查一遍再操作"，而非"在分布式環境下保證原子性"。
出題人在復盤時打了個比方：「教AI寫支付代碼，就像用駕校模擬器教高速避險——場景對上了，肌肉記憶沒跟上。」
這道題的余波
挑戰發布后，VibeCode Arena的支付類題目參與量漲了3倍。有金融科技團隊直接把它放進工程師面試題庫，也有AI公司用它來標注"需要人工復核"的高風險生成代碼。
一個細節被反復提及：通過測試的模型中，有幾款明確引用了Stripe、Adyen等支付平臺的公開設計文檔作為推理依據。換句話說，當AI能調用特定領域的工程實踐而非通用編程模式時，表現會躍升一個臺階。
出題人最后把挑戰鏈接永久開放，附了一句注釋：「如果你的AI助手要寫支付代碼，建議先讓它過一遍這題。不是信不過，是扣款短信發到用戶手機上的時候，道歉成本比較高。」
現在壓力給到了用AI生成代碼的開發者這邊——你會把這道測試加入自己的Code Review清單，還是賭自己的場景不會觸發那個并發窗口？
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
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.
