三小時沒解的Bug，AI三十秒找出了 race condition

「我花了3小時調試一個Bug，AI用了30秒。」——開發者Siti Aisyah Mat Zainal在OpenClaw挑戰賽中寫下了這句話。不是炫技，是困惑：為什么人類盯著代碼反復檢查，卻輸給了機器的結構化提問？

一個"隨機發作"的React組件

問題本身很典型。交易伙伴選擇功能：用戶點選后，系統自動填充買家信息。技術棧是React加異步接口，代碼層面API響應正常、后端邏輯通順、控制臺零報錯。

但下拉框就是會隨機失靈。不是必現，不是規律復現，"剛好夠煩人"。

開發者常規排查三板斧：查日志、盯網絡請求、重讀代碼。三小時過去，問題還在。這時候她換了個思路：如果像資深工程師那樣拆解問題，會怎么問？

于是用OpenClaw搭了一個調試代理（debugging agent），把故障現場翻譯成結構化輸入——不是扔給AI一堆截圖和"幫我看看"，而是明確列出：問題現象、API狀態、當前state值、effect依賴項。

AI輸出很直接：displayList為空時useEffect已經執行，race condition（競態條件）。建議把displayList加入依賴數組。

競態條件：時序錯位的經典陷阱

根因確實不在邏輯或語法，在時序。用戶選擇交易伙伴的瞬間，useEffect立即觸發，但displayList的數據還沒就位，自動填充失敗，UI狀態錯亂。

修復方案也簡單：判斷條件加上displayList.length > 0，依賴數組補上displayList。零后端改動，下拉框穩定運行。

三小時與三十秒的差距，不在于代碼復雜度，在于問題拆解的方式。人類傾向于線性排查，AI被設計成模式識別——當你把現象翻譯成結構化輸入，它就能快速定位非常規關聯。

OpenClaw的隱藏價值：調試工作流化

這個實驗里，工具本身值得關注。OpenClaw讓開發者能把調試輸入標準化、把排查過程變成可復用的系統。不是每次問AI"為什么又壞了"，而是建立一套"輸入-分析-驗證"的固定流程。

對前端工程師來說，這意味著競態條件、依賴遺漏、異步時序這類"看不見的錯誤"有了更高效的捕捉方式。對團隊來說，Debug經驗可以沉淀為模板，而非依賴個人記憶。

這次經歷改變了作者對調試的認知：從試錯走向系統化輔助排查。而系統化，恰恰是工程成熟度的一個信號。