auto_captcha：原始碼公開的 Chrome 擴充，用你自己的 OpenAI、Claude、Gemini 金鑰辨識圖像驗證碼

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

auto_captcha 是一個用 JavaScript 寫、原始碼完全公開的 Chrome 擴充功能，讓你把自己持有的 OpenAI、Claude 或 Gemini 金鑰接上網頁，用大模型辨識 img、canvas、svg 這幾類圖像驗證碼，辨識完自動填進輸入框。它不是那種把驗證碼整批丟給代解雲端的黑箱服務，而是把請求從你的瀏覽器發到你自己的 AI 帳號。但在你把讀取所有網頁的權限交給它之前，有三件事要先看清楚：它只處理圖像驗證碼，遇到滑動拼圖、點選漢字、reCAPTCHA 這類互動式挑戰完全幫不上忙；它要求 <all_urls> 的主機權限，等於能讀你開的每一個網頁；而作者雖然在 README 寫了「MIT License」，倉庫裡卻沒有實際的 LICENSE 檔案，GitHub 的自動授權偵測結果是空值。

把它放對位置很重要：這是一個給開發者、測試人員、自動化愛好者處理自己網站或自己測試流程裡圖像驗證碼的小工具，不是繞過別人網站安全防護的萬用鑰匙。本文根據 GitHub 倉庫 dxxzst/auto_captcha 的 manifest、README 與原始碼審視寫成，沒有實際安裝跑測試，所以不會替你斷言辨識成功率或速度，只把架構與能力邊界講清楚。

它的架構：你自己的金鑰，從你的瀏覽器發請求

從 manifest.json 與原始碼結構可以看出這個擴充功能的運作方式。它是 Chrome Manifest V3 架構，背景由一個 service-worker.js 負責訊息路由，內容腳本 src/content/content.js 在 document_idle 時機注入頁面。從 README 與原始碼看，流程是手動觸發的：你按下「選擇元素」啟動一個類似 DevTools 的元素拾取器，點畫面上的驗證碼圖，擴充把圖抓下來送給你設定的 AI 模型辨識，結果回來後按「填充」自動填進對應的輸入框。

Pin

它對接模型的方式是自帶金鑰（BYOK）。在設定頁填入 API 地址與金鑰後，三個介面卡 src/api/openai-compatible.js、claude-adapter.js、gemini-adapter.js 會把驗證碼圖像送到你指定的端點。README 列出的預設組合是 OpenAI 的 gpt-4o、Anthropic 的 claude-3-5-sonnet-20241022、Google 的 gemini-1.5-flash，也開放自訂任何相容 API。金鑰用 Web Crypto API 的 AES-GCM 加密後存在本機，請求一律從你的瀏覽器發出，沒有作者架設的中繼伺服器當中間人。這點與付費代解服務的營運模型有根本差異，後續會再對比。

一個減少重複操作的設計是網站規則記憶。你第一次手動選好某個網站的驗證碼元素後，這個位置會被存起來，下次造訪同一個網站就自動套用，不必每次重新點。對固定在幾個後台或測試站反覆操作的人，這能省下不少手動選取的時間。不過它不會自動掃描頁面，README 的安全說明段明講擴充僅在使用者點擊時才動作，這屬於作者宣稱，想嚴格驗證可以自己讀 content.js 確認。

只能處理圖像驗證碼，這是硬限制

README 的「已知限制」段把能做的範圍寫得很明白。能辨識的只有 img、canvas、svg 三種類型的圖像驗證碼，也就是那種把扭曲文字或算式畫成圖片、要你打字回答的類型。滑動驗證碼與點選驗證碼暫不支援，意思是網路上最常見的拼圖滑動、按順序點選漢字、reCAPTCHA 的方格選圖，這個擴充都沒辦法處理。它也不是在解 reCAPTCHA 的服務條款爭議，只是用大模型的影像辨識能力讀出簡單圖裡的字。

另一個會影響實際使用的是跨域限制。如果驗證碼圖片與網頁不同網域，且目標網站沒有開放 CORS，瀏覽器的同源政策會讓擴充抓不到那張圖，這是瀏覽器引擎層級的限制，不是擴充本身的設計缺陷。這在把驗證碼圖託管在獨立 CDN 或第三方服務的網站會遇到，裝起來能不能用，要看你目標站的具體配置。

讀取所有網頁的權限，與一個不存在的授權檔

要審視一個開源瀏覽器擴充，最該先看的是它要求的權限。auto_captcha 的 manifest.json 在 permissions 列了 activeTab、storage、scripting，而 host_permissions 設為 <all_urls>，內容腳本的 matches 同樣涵蓋 <all_urls>。換句話說，這個擴充理論上能在你開啟的任何一個網頁上讀取內容與注入腳本。這是它能用元素拾取器抓取頁面上任意驗證碼的前提，沒有這個權限它就無法在不同網站通用，但也是你安裝前要接受的信任成本。它是不是真的只在被觸發時讀取驗證碼元素、會不會把其他頁面內容往外送，只能從原始碼與作者宣稱判斷。

資料流向可以拆成兩段看。金鑰儲存與請求發起點在本機，這部分 AES-GCM 加密加上本地發請求是成立的。但驗證碼圖像本身會送到你選的 AI 端點，如果你的端點是 OpenAI、Anthropic、Google，等於圖像內容進了這些第三方的伺服器，適用他們各自的資料處理政策。所以「完全本地、隱私零外洩」這類說法對它並不準確，準確的描述是：你的 API 金鑰不出本機，但驗證碼圖像會到你設定的模型供應商那邊跑辨識。在對資料流向敏感的環境裡，這條要列入評估。

授權狀態值得單獨講。README 末段寫著「MIT License」，作者心意上是要開放授權。但實際比對倉庫內容，根目錄找不到 LICENSE 或 LICENSE.md 檔案，GitHub 的授權偵測也把這個倉庫的授權欄位判為空值。也就是 GitHub 的 licensee 自動偵測無法把這個倉庫判定為 MIT 或任何授權。在嚴格的法律意義上，沒有正式授權檔意味著預設的「保留所有權利」狀態可能仍然適用，儘管作者在 README 宣告了 MIT 心意。多數人自己裝來用、改來自己用不會有問題，但想把這份程式碼整進商業產品再散布的團隊，最好自己補上授權確認或聯絡作者補一份正式 LICENSE，免得日後爭議。把這個落差講清楚，是因為開源工具的授權狀態本來就該如實交代。

與付費代解服務的定位差異

把 auto_captcha 放在整個驗證碼解決方案的光譜上會更清楚。一端是 2Captcha、Anti-Captcha 這類付費代解服務，你把驗證碼丟給他們的 API，由他們的真人或專用模型回傳答案，論次計費，覆蓋範圍涵蓋 reCAPTCHA、hCaptcha、滑動拼圖等各種複雜類型。另一端就是 auto_captcha 這種 BYOK 工具，你自己出 AI 帳號與金鑰，用大模型讀簡單圖像驗證碼，能做的類型窄，但請求端點與成本你完全掌握。

這兩種其實對應不同需求，算不上直接競爭。付費代解的優勢在覆蓋範圍與開箱即用，代價是每次辨識都要付錢、且驗證碼內容會進代解服務的系統。BYOK 擴充的優勢在成本結構（用你自己的 LLM token，依公開的 LLM 計費推估，單次成本通常落在幾百分之一美元等級，但實際花費要看你的模型與使用量，本文沒實測所以不給具體數字）與對請求端點的完全掌控，代價是只覆蓋圖像驗證碼、需要自己設定模型。如果你的需求是處理自己網站或測試流程裡的圖像驗證碼，BYOK 路線夠用；如果要過的是大型平台的互動式挑戰，這個工具幫不上，付費代解或對應的合規方案才是那個賽道。

倉庫狀態與設定流程

從 GitHub 倉庫的後設資料看，auto_captcha 目前約 159 顆星、15 個 fork，2025 年 12 月 24 日建立，最近一次有更新活動是在 2026 年 8 月初，不是棄坑專案。主要語言是 JavaScript，預設分支是 master，_locales 同時提供簡體中文與英文介面。專案結構是標準的 Chrome 擴充目錄：src/background 放 service worker、src/content 放頁面注入腳本、src/api 放模型介面卡、src/options 與 src/popup 是設定頁與彈出視窗。這對會讀 JavaScript 的人是友善的，等於整個運作邏輯都可以自己審視。

Pin

安裝步驟很短，這類以未打包原始碼安裝的擴充都是同一套流程：把倉庫 git clone 下來，打開 Chrome 的 chrome://extensions/，開啟右上角的開發者模式，點「載入已解壓的擴充功能」，選 auto_captcha 資料夾。載入後點擴充圖示進設定頁，選一個預設模型範本或新增自訂 API，填入金鑰與端點，按「測試連線」確認接得通。使用時在目標頁面啟動「選擇元素」，點驗證碼圖，按「識別驗證碼」讓 AI 讀圖，最後按「填充」把結果填進輸入框。整個流程不需要 command line，也不需要額外架設伺服器，全部在瀏覽器裡完成。如果你已經習慣用 本機瀏覽器代理 處理網頁自動化任務，auto_captcha 的操作邏輯會很眼熟，差別在它把範圍收窄到圖像驗證碼這一個環節。

這個工具與 Magic Copy 或 Just The Browser 這類 Chrome 擴充功能一樣，都屬於把瀏覽器當成工作平台、把重複操作自動化的路線。差別在 auto_captcha 處理的是驗證碼這個特別燒手動操作的環節，而它選擇用你自己的大模型帳號來做辨識，而不是綁死某個付費服務。對已經在付 OpenAI 或 Gemini 訂閱、想把同一個帳號延伸到驗證碼辨識的人，這個設計讓成本不重複發生。

它解決的情境，以及做不到的邊界

這個擴充最明顯的受眾，是會在固定幾個自己管理的網站或測試環境裡反覆遇到圖像驗證碼的人。在維護自己後台、跑自動化測試、或做網頁爬蟲前對自己的服務做驗證流程時，圖像驗證碼常常是流程裡最沒營養卻最卡關的一步。auto_captcha 把這一步用你已有的 AI 帳號自動化，搭配網站規則記憶，能把重複操作的負擔降下來。它的定位接近開發者工具，而不是給一般使用者每天上各種網站用的全自動驗證碼機器人。

期待面要先校準幾個會直接影響使用判斷的點：

• 類型覆蓋有限：只有圖像驗證碼，遇到滑動或點選就是過不了，硬要它做超出範圍的事只會浪費 API 額度。
• 跨域圖片可能抓不到：目標網站的 CORS 配置會決定能不能用，裝之前對著你的目標站測一次比較實在。
• 權限範圍大：<all_urls> 是這類通用擴充的代價，能不能接受要看你對開源擴充功能的信任程度，好處是原始碼公開，你可以自己審視內容腳本到底讀了什麼。
• 授權狀態有落差：作者宣告 MIT 但缺正式 LICENSE 檔，個人使用無虞，商業整合前自己補確認。

如果你的情境剛好是「自己在管理的網站、圖像驗證碼、已經有 OpenAI 或 Gemini 帳號」，auto_captcha 把這三個條件接起來，是個值得裝來試的小工具，加上它原始碼公開、可以自己審、沒有中間伺服器抽成，對開發者取向的人尤其合拍。如果你的需求是要過大型平台的互動式驗證碼、或不想自己管 API 金鑰，那走付費代解服務會是更實際的選擇。把它當成開發者工具箱裡處理圖像驗證碼的一個選項，而不是通用的驗證碼繞過方案，會是用得舒服的前提。