
我們大概都遇過這種場景:登入一個網站,先點一下「我不是機器人」,然後頁面彈出九宮格,讓你選出所有包含紅綠燈、摩托車或公車的圖片。點完一輪,又來一輪。有時候明明選對了,系統還是讓你重試;如果你所在的網路環境比較特殊,驗證甚至會一輪接一輪地出現。
驗證碼本來是用來給機器製造麻煩的,但是技術發展到現在,機器可能已經比人更擅長做這些題了。
2024 年,研究者針對 Google reCAPTCHA v2 做了一組實驗。他們沒有使用 GPT,只是用經過訓練的 YOLOv8 圖像模型識別驗證碼中的目標圖片,再配合瀏覽器自動化完成操作。論文報告的 100 次測試全部通過。
到了 2025 年,研究開始從單一驗證碼轉向更系統化的評估,把文字、圖片選擇、滑塊、旋轉等多種 CAPTCHA 放在同一套 benchmark 中測試視覺語言模型。有些已經接近普通視覺識別任務,有些仍然需要精確定位、空間推理和連續互動,成功率明顯下降。
而到了 2026 年,變化又向前走了一步。問題開始不再只是「AI 能不能看懂驗證碼」,而是「AI 能不能自己開啟網頁,看懂驗證碼,然後完成點擊、拖動、糾錯,再繼續做原來的事情」。
答案正在變成:可以。
這就是為什麼今天我想重新討論 CAPTCHA。驗證碼作為安全防控的關鍵一環並沒有消失,但它最初依賴的安全假設正在變化。在 2026 年,我們需要重新理解 AI 識別驗證碼究竟到了什麼水平。
CAPTCHA 最初賭的是一件事:人會,機器不會
CAPTCHA 的核心思路其實很簡單:找到一種人類很容易完成、機器卻很難完成的任務,然後拿這件事區分人與機器。
早期最典型的是扭曲文字。字母會被旋轉、黏連,背景裡加入雜訊和干擾線。對人來說,瞇著眼睛通常還能認出來;對早期 OCR 來說,卻是一道很困難的題。後來 OCR 越來越強,驗證碼開始換題,Google reCAPTCHA 逐漸轉向圖片,讓使用者判斷哪些圖裡有汽車、紅綠燈或摩托車。
本質上還是同一個遊戲:找一種人類擅長、機器暫時不擅長的感知能力。
問題在於,過去二十年 AI 進步最快的恰恰就是這些能力。OCR、圖像分類、目標檢測、語音識別,再到今天的視覺語言模型,CAPTCHA 不斷尋找新的「機器盲區」,而機器不斷追上來。
所以到了 2026 年,如果還只問一句「AI 識別驗證碼的準確率是多少」,其實已經不夠了。更準確的分析至少應該分成三個層次:
- Recognition:AI 能不能看懂驗證碼、知道正確答案;
- Interaction:它知道答案以後,能不能真的在網頁裡點擊、拖動和完成多輪互動;
- Acceptance:即使驗證碼做對了,伺服器端的風控系統最終會不會接受這次請求。
這三個問題現在已經越來越不同。

文字驗證碼基本已經退化成一個 OCR 問題
傳統文字 CAPTCHA 今天已經很難承擔核心安全邊界。原因不複雜,它本質上就是一個 OCR 問題。
如果一個網站仍然使用固定字體、固定雜訊分布、固定長度的文字驗證碼,攻擊者一旦能收集到足夠樣本,訓練一個專用模型並不是什麼前沿研究。甚至很多時候根本不需要大模型。
談 AI 破解 CAPTCHA 時,人們很容易想到 GPT、Gemini、Qwen 這樣的通用模型,但對固定題型來說,越專用的模型反而可能越便宜、越快。一個針對特定驗證碼訓練好的 OCR 或輕量視覺模型,可以直接在本地運行,單次推理成本非常低。
九宮格驗證碼越來越像普通目標檢測
圖片 CAPTCHA 曾經明顯提高過攻擊門檻。「請選擇所有包含公車的圖片」這種題,對早期機器視覺並不容易。但今天再看,它的任務定義已經非常熟悉:這就是目標檢測和圖像分類。
2024 年的論文 Breaking reCAPTCHAv2 使用 YOLOv8 識別 reCAPTCHA v2 圖片挑戰中的目標類別,再結合自動化程式完成點擊,報告了 100 次測試全部通過的結果。
這裡的「100%」並不是說「reCAPTCHA 已經沒有用了」,而是說明在那套特定實驗條件下,圖片挑戰本身已經不能可靠地區分機器和人。reCAPTCHA 背後依然還有 cookie、瀏覽器環境、存取歷史和風險評分等其他機制,這些並沒有因為圖像識別成功而消失。
但過去那層最直觀的安全假設——「機器應該認不出紅綠燈」——正在失效。
攻擊者已經不一定需要專門訓練模型
YOLO 破解 reCAPTCHA 仍然是一種比較傳統的思路:先收資料,再標註,再針對特定 CAPTCHA 訓練一個 solver。它的優點是便宜、快、穩定,但缺點也很明顯:比較依賴題型。
如果驗證碼突然從「找汽車」變成「選擇兩個用途相同的物體」,一個只為汽車、公車、紅綠燈訓練的模型就很容易失效。
視覺語言模型改變的正是這一點。Qwen、Gemini、GPT 這一類模型,不是只認識某個固定類別,而是能夠同時理解圖片、文字指令和空間關係。
2025 年的 MCA-Bench 專門研究了這個問題:它把多種 CAPTCHA 統一放到視覺語言模型框架下測試。結果顯示,經過訓練的 Qwen2.5-VL 在部分扭曲文字和 3×3 圖片選擇任務上已經能達到很高成功率,但面對滑塊、旋轉和複雜空間推理時,表現會明顯下降。
這個差異說明 CAPTCHA 的難點正在變化。以前主要考的是「看不看得懂」,現在開始考「看懂以後,能不能準確地做出互動動作」。

滑塊驗證碼為什麼曾經更難
滑塊驗證碼就是一個很典型的例子。頁面上有一張圖片,中間挖掉一塊,使用者需要拖動滑塊,讓拼圖恰好對齊缺口。
這比九宮格多了一層要求。九宮格只需要回答「紅綠燈在哪裡」,滑塊還要回答「缺口在哪裡」「應該拖多遠」「軌跡是不是合理」。 它同時包含視覺識別和行為互動。
不過,這類驗證碼也沒有形成長期穩定的安全邊界。2024 年發表的 The robustness of behavior-verification-based slider CAPTCHAs 針對五種廣泛部署的行為驗證型滑塊 CAPTCHA,報告的攻擊成功率為 87.5% 到 100%。
這再次說明,如果攻擊者願意針對某一種驗證碼客製演算法,單純把圖片換成滑塊並不能永久解決問題。缺口檢測本身已經是成熟的電腦視覺任務,真正更難模擬的部分逐漸變成滑鼠軌跡、時間間隔、頁面環境、歷史 session 和 IP reputation 這些外圍訊號。
到 2026 年,GUI Agent 開始自己做驗證碼了
真正讓我覺得這一輪變化和過去不一樣的,是 GUI Agent 開始把驗證碼當成普通網頁互動來處理。
2026 年的論文 CAPTCHA Solving for Native GUI Agents 提出了 ReCAP,一種專門增強 CAPTCHA 能力的原生 GUI Agent。它不再使用傳統的「截圖交給識別模型,再由腳本解析結果、執行點擊」流水線,而是讓模型直接看截圖並輸出 GUI 操作。模型可以自己識別目標、找到位置、點擊、觀察下一幀、判斷是否出錯,再繼續修正。
研究者使用資料訓練 Qwen3-VL 系列模型。32B 模型在論文動態 CAPTCHA benchmark 上的總體成功率約為 81%,平均約 1.54 次模型呼叫,端到端執行時間低於 3 秒。 這些是特定測試集中的實驗結果,不能直接等同於所有真實網站的通過率。
趨勢已經很清楚了:CAPTCHA solving 正在從一種專門的安全攻擊技能,逐漸變成通用 Computer Use Agent 的一個副能力。

過去要破解驗證碼,需要有人專門寫破解器。未來更可能出現的情況是:一個 Agent 在執行訂票、購物或填寫表單任務時,走到一半遇到驗證碼,它看一眼,自己完成,然後繼續原來的任務。
能做題,不等於能過系統
如果只看到前面的研究資料,很容易得出「CAPTCHA 已經死了」的結論,但現實沒有這麼簡單。
假設一個 AI 可以 100% 準確地找出所有紅綠燈,它開啟 reCAPTCHA,九張圖片全部點對,Google 仍然可能不讓它通過。因為現代 CAPTCHA 早就不只是在檢查答案。
伺服器能看到的東西遠比驗證碼截圖多。它可以觀察這個 IP 來自哪裡、是不是資料中心 ASN、裝置是否出現過、cookie 有沒有歷史、瀏覽器環境是否正常、請求頻率是多少、一個 session 裡連續做了多少次挑戰、帳號是否剛剛建立,以及行為模式是否偏離正常使用者。
這也是為什麼評價 CAPTCHA 時,要把 Recognition、Interaction 和 Acceptance 分開。某個模型在離線 benchmark 中達到 98% 識別率,並不意味著它就有 98% 的端到端通過率。識別只是其中一層。

攻擊成本也發生了變化
過去人們會認為,驗證碼最重要的攻擊成本來自機器算不出來。現在這部分成本正在快速下降。
傳統 OCR、YOLO 這類專用模型可以完全本地部署。視覺語言模型也在不斷開放權重,對固定任務來說,純推理的邊際成本已經可以壓得很低。
公開 CAPTCHA solving 市場的價格也能從另一個側面說明問題。以 2026 年 8 月公開頁面為例,普通圖片驗證碼和 reCAPTCHA v2 的報價已經低至每 1000 次約 0.5 至 2.99 美元。這類第三方報價會變化,也可能混合人工與自動化能力,但它至少說明「得到答案」本身已經高度商品化。
也就是說,現在真正做大規模自動化時,更貴的東西往往不再是「識別驗證碼」本身,而是代理 IP、乾淨的 reputation、真實瀏覽器環境、裝置身分、帳號資源、session 維持和失敗重試。
於是最新 CAPTCHA 的防禦目標也跟著變了。
以前希望做到的是:讓機器做不出來。
現在更現實的目標是:讓機器批次做這件事不划算。
Google 已經不再把重點放在題目上了
順著這個變化去看 Google,會發現 reCAPTCHA 自己也已經走得很遠了。
今天 Google 已經把 reCAPTCHA 放進更大的 Fraud Defense 體系裡。它關注的不再只是「這道題有沒有答對」,而是整個請求的風險。伺服器端可以得到 0.0 到 1.0 的風險評分,1.0 代表請求很可能合法,0.0 代表很可能不合法,開發者再根據業務場景決定下一步動作。Google 的評估介面還包含 verifiedBots 欄位,用於回傳已驗證身分的 Bot。
比如登入場景中,低風險請求可以直接通過,中風險請求觸發電子郵件驗證,更高風險觸發 MFA,再高則直接拒絕。
以前 CAPTCHA 本身負責做決定:題做對了,就通過。現在則是:請求進入系統以後,先收集一系列訊號,再計算風險,最後由業務決定是放行、升級驗證還是拒絕。
Cloudflare 更進一步:最好根本不要讓使用者做題
Cloudflare Turnstile 的思路更有代表性。它表面上仍然是 CAPTCHA 的替代品,但設計目標很早就從「讓使用者完成挑戰」變成了「盡量讓使用者無感通過」。
Turnstile 官方文件 說明,它會在瀏覽器裡運行一系列非互動式 challenge,並結合客戶端和瀏覽器環境中的多種訊號判斷,包括 proof-of-work、proof-of-space、Web API 探測、瀏覽器 quirks 和行為訊號。Managed 模式會根據客戶端訊號和風險水平選擇驗證方式,低風險使用者可以直接通過,只有需要進一步檢查時才會出現 checkbox。
即使前端顯示風險檢驗通過,Cloudflare 仍然要求伺服器端繼續校驗 token。官方文件明確強調,一個 challenge 被 solve,並不能自動說明訪問者就是可信的人類請求。
這句話其實非常能說明 2026 年 CAPTCHA 的真實狀態。
會做題,已經不再等於通過安全判斷。
hCaptcha 沒有完全放棄出題
hCaptcha 的路線和 Google、Cloudflare 又不完全一樣。它仍然保留了更多主動視覺 challenge,同時也提供 invisible 模式和 risk score。 Invisible 模式可以在背景運行,只在達到挑戰條件時向使用者顯示題目;純被動模式則依賴企業版風險評分。
這種策略背後的邏輯也很直觀:即使某一類 CAPTCHA 被目前模型攻破,仍然可以透過更換題型、增加互動複雜度和動態輪換,重新拉開一段時間的人機差距。
過去兩年,學術界也在不斷嘗試類似思路,例如視覺錯覺 CAPTCHA、音訊錯覺 CAPTCHA 和複雜空間推理 CAPTCHA。
2026 年的論文 Robust CAPTCHA Using Audio Illusions in the Era of Large Language Models 提出的 IllusionAudio,在論文測試的 LALM 與 ASR 攻擊中實現了 0% 繞過率,同時在使用者實驗中實現了 100% 的人類通過率。
這是一個很漂亮的實驗結果,但它依然有一個熟悉的問題:一旦題型公開,攻擊者就可以開始專門收集資料、生成樣本和微調模型。
CAPTCHA 二十多年的歷史,本質上一直在重複這個循環:找到新的 human-easy / machine-hard task,部署,機器學習,攻破,再增加複雜度,再尋找新的任務。
生成式 AI 沒有終結這個循環,只是讓它轉得越來越快。
真正麻煩的可能不是 Bot,而是合法的 AI Agent
這裡還有一個 CAPTCHA 最初根本沒有考慮過的問題:未來的機器流量,不一定都是壞流量。
過去網際網路裡的 Bot,通常很容易被理解成爬蟲、垃圾註冊、撞庫、刷票、刷庫存或自動廣告點擊。於是可以簡單地把 Human 理解成 Good,把 Bot 理解成 Bad。
Agent 時代不是這樣。
一個 AI Agent 幫我訂飯店,它當然是 Bot,但它應該被阻止嗎?未必。一個 Agent 幫我填寫公司報銷系統,一個無障礙 Agent 幫視障使用者操作網頁,一個購物 Agent 幫使用者比價和下單,一個企業內部自動化 Agent 操作 SaaS,這些都是自動化程式,但也可能擁有真實使用者的授權。
Google 目前的風險分析介面已經出現 verified bot identity 這樣的概念,這其實很能說明問題。未來的網站可能不應該再簡單地問「你是不是機器人」,而應該問「這個 Agent 是誰、是誰授權它來的、它準備做什麼、允許執行多大的動作、它過去的 reputation 怎麼樣、它一分鐘發三個請求還是三萬個請求」。

常見問題
2026 年 AI 能破解驗證碼嗎?
能破解相當一部分,但「識別正確答案」和「被伺服器端接受」不是一回事。文字和常見圖片驗證碼已經高度可解,滑塊、旋轉及多輪動態互動仍更困難;現代風控還會結合 IP、裝置、瀏覽器、帳號和行為訊號判斷請求。
reCAPTCHA v2 的圖片驗證還安全嗎?
圖片題本身已不能被視為穩定的人機分界線。2024 年已有研究在特定實驗條件下實現 100 次全通過,但 reCAPTCHA 的整體安全性還依賴風險評分、cookie、瀏覽器歷史等其他訊號。
GUI Agent 為什麼改變了 CAPTCHA 的威脅模型?
因為它把識別、定位、點擊、拖動、觀察回饋和糾錯連接成了端到端過程。驗證碼求解因此可能從專用破解器的能力,變成通用網頁 Agent 執行任務時順帶完成的一步。
網站應該如何應對 AI 破解驗證碼?
不要把一道視覺題當作唯一安全邊界。更合理的做法是分層使用風險評分、速率限制、裝置與工作階段訊號、帳號信譽、MFA 和伺服器端 token 校驗,並為獲得授權的合法 Agent 設計可驗證的身分與權限機制。
寫在最後
把 AI 快速發展的這三年研究放在一起,會看到一條很清楚的變化。
文字 CAPTCHA 首先失守,圖片 CAPTCHA 逐漸變成普通目標檢測,視覺語言模型開始解決以前需要專用模型才能處理的不同類型驗證碼,GUI Agent 又把「識別」和「操作」連接起來。
接下來真正比較難的部分,越來越集中在動態、多步驟、精細定位,以及真實伺服器環境中的風險判斷。
所以在 2026 年,最先進的 CAPTCHA 產品越來越不像 CAPTCHA。Google 在算 risk score,Cloudflare 在觀察瀏覽器和客戶端環境,hCaptcha 把主動 challenge 和被動訊號結合起來。
最終目標顯然已經不是找到一道 AI 永遠做不出來的題,因為這件事越來越難保證。更現實的目標是,讓一次正常訪問幾乎沒有成本,讓一次大規模自動化攻擊不斷增加成本,直到它不再划算。
參考資料
- Breaking reCAPTCHAv2
- MCA-Bench: A Multimodal Benchmark for Evaluating CAPTCHA Robustness Against VLM-based Attacks
- The robustness of behavior-verification-based slider CAPTCHAs
- CAPTCHA Solving for Native GUI Agents
- Robust CAPTCHA Using Audio Illusions in the Era of Large Language Models
- Google Cloud reCAPTCHA risk analysis reference
- Cloudflare Turnstile documentation
- hCaptcha Invisible Captcha documentation