那個缺口先被看穿了：滑塊驗證碼，是一張被 AI 讀懂的圖

10 月 19 日，V2EX 使用者 bybyte 發了一則分享：他想讓某個網站自動登入，卡在滑塊驗證碼這一關，於是裝好 MCP 工具、把帳號密碼交給 AI，隔天醒來，AI 留下一句「其實很好破」，任務確實完成了。他在原文裡的措辭很樸素：自動分析缺口，做圖像識別，非常不錯。

這則帖子的趣味不在「AI 又打敗了什麼」，而在它意外攤開了滑塊驗證碼的設計底牌。

一張挖了坑的圖，和一張沒挖坑的圖

留言區裡最有價值的一條來自 OceanZH。他說早年手寫程式破解某主流滑塊驗證碼時，打開瀏覽器的開發者工具就會發現頁面裡其實載入了兩張圖：一張挖了缺口，一張完好。把兩張圖的像素逐點比對，缺口座標就出來了，剩下的只是把滑塊移到那個 x 位置。他也補了一句，新一代的滑塊已經會「挖假坑」來幹擾這種老辦法。

這段描述把滑塊驗證碼的本質講得很清楚：它是一個建立在像素差異上的謎題。畫面上那道看似要靠人眼與手感完成的拖曳，在資料層面是一道可以靜態求解的座標題。缺口的位置從一開始就寫在圖裡，只是賭你讀不出來。

bybyte 後來在回覆裡也證實，這次破解的滑塊屬於簡單版本，後端沒有驗證滑軌痕跡，只要把正確範圍的 x 座標 post 過去就算過關。換句話說，被繞過的環節只有「找缺口」這一步，連「怎麼拖」都不用演。

防線的設計，是被成本決定的

串起來看，這則帖子裡的眾聲其實拼出了一張滑塊驗證碼的防禦層級表。最底層是缺口本身，靠像素差異就能被定位。上一層是行為痕跡，檢查滑軌的速度、抖動與加速度，讓腳本不能一步到位。再往上是幹擾設計，例如假缺口與背景雜訊。留言裡也有人回報，公司用的商業滑塊方案後臺日志能看到腳本呼叫痕跡，說明防禦方看得到異常，只是攔不攔得住是另一回事。

每多一層，都是開發成本的堆疊。而 AI 帶來的變化，是把最底層那道「圖像識別」的門檻直接拆掉了。以前要寫比對程式、外掛 OCR，留言裡就有人提到早年用不帶圖像識別的模型加 OCR，效果很差；現在把工具裝好、下一句指令，缺口座標就交出來了。另一則留言提到本地部署的模型辨識圖形驗證碼幾乎不會錯，也有人試過讓 AI 過九宮格選圖，同樣輕鬆通過。

這個介面從來防的就不只是人

留言區有一句半開玩笑的話流傳得很自然：「其實這個驗證碼是防人的。」玩笑歸玩笑，它指向一個設計上的尷尬：滑塊驗證碼的互動形式是擬人的，拖一條滑桿、對齊一個缺口，看起來像是只有人才會做的事。但它的可解性從一開始就寫在實作裡，對能讀像素的對手而言，這道防線的材質是透明的。

當讀圖的成本趨近於零，剩下的防禦就只剩行為層與後端驗證。帖末有人直接給出結論：必須上簡訊驗證碼。這不是什麼新鮮答案，卻是這場討論自然抵達的終點。

值得留意的還有 bybyte 的使用方式。他用的是無審核版本的模型，可以直接下命令破解。同一個模型能力，接上 MCP 工具後，一次指令就能完成分析、定位與提交。工具鏈的設計讓「破解」這件事的介面變得和「請幫我縮圖」一樣平淡，這大概是整則帖子裡最值得設計者警惕的部分：當一個防禦機制的弱點可以被一句自然語言觸達，它的失效速度就不取決於防守方更新多快，而取決於好奇的人有多少。

那個缺口最後還是被看穿了。滑塊驗證碼接下來要證明的，已經不是機器會不會玩遊戲，而是它在行為痕跊與後端驗證上，還願意投入多少設計成本。