外界一直流傳著一個關於 Crawl4AI 的說法：它好像有某種自我適應的智慧，網站一改版就能自動找回資料、修復失效規則。其實沒有。那是另一個工具的本事（如果你好奇，是 Scrapling）。Crawl4AI 的定位更具體，也更值得直接理解：它就是把一個無頭瀏覽器接上 Markdown 轉換器，再外掛一個 CSS/XPath 擷取器。
我實際跑了一輪測試，涵蓋靜態頁面、JavaScript 渲染的目錄、刻意做壞的 500 頁面，以及一個小型深度爬取。它的核心功能真的不錯。那些常被輕描淡寫帶過的部分——安裝負擔、深度爬取的行為、以及一個容易誤導的錯誤訊息——正是這篇評測要深入談的。以下內容都只是依據我真正跑過的測試得出的初步結論，不是最終版基準結果。我也會標註哪些沒測，免得有人拿我沒碰過的東西來引用。
Crawl4AI 到底是什麼（以及它不是什麼）
把包裝話術拿掉之後，Crawl4AI 本質上就是三個東西疊在一起。
第一，是真正的瀏覽器。底層它透過 Playwright 以及一個名為 Patchright 的隱匿修補版本來載入頁面，行為就像 Chrome 一樣——執行 JavaScript、建立 DOM、如果你有指定就等待內容出現。這一點很重要。它不是那種單純把 HTML 抓下來就結束的 HTTP client，而是直接啟動了一個實際的渲染引擎。
第二，是 Markdown 產生器。頁面渲染完成後，Crawl4AI 會把 DOM 轉成 Markdown；而這正是 LLM 與 RAG 流程最常吃的格式。維護者把整個專案定位成一個 LLM 友善的爬蟲，原因也正是如此——丟入一個 URL，回傳模型可以理解的文字。
第三，是結構化擷取器。如果你想要的是乾淨的 JSON，而不是敘述文字，只要提供 schema——也就是把 CSS 或 XPath 選擇器對應到欄位名稱——透過 JsonCssExtractionStrategy 丟進去，它就會回傳資料列。（它也有基於 LLM 的擷取路徑，但那需要 API key，而且我沒有測，所以不會假裝知道它實際表現如何。）
真正關鍵、也最容易被「自我修復智慧」這種說法誤導的是：這個 schema 是靜態的，而且得由你手動撰寫。你告訴 Crawl4AI 商品名稱在 .product-card h3，價格在 .price；如果網站明天把 class 名稱改掉，你的選擇器就會失效，而且會一直失效。它不會自動修復，也沒有模糊重配對。它就是瀏覽器、轉換器，再加上你自己維護的選擇器——僅此而已。先把這點搞清楚，就不會期待一個根本不屬於這個 repo 的功能。
你實際會接觸到的幾個核心元件命名也很合理：AsyncWebCrawler 是執行引擎，BrowserConfig 負責設定瀏覽器，CrawlerRunConfig 控制單次執行（包含我稍後會提到的 wait_for）。這是一套以 async 為主的 Python API，只要名稱對上了，讀起來其實相當順。
補充一下，截至 2026-07-07，這個 repo 顯示 71,259 顆星、7,326 個 fork、Apache-2.0 授權（unclecode/crawl4ai），版本是 v0.9.0。星星數會變動，所以請把它當作快照，不要當成即時數據——但至少能看出這是一個使用者很多、授權也很寬鬆的專案，而不是週末玩票作品。
安裝：兩套完整瀏覽器堆疊一起落到你硬碟上的時刻
Crawl4AI 真正開始不像輕量函式庫的地方，就是安裝。這也是幾乎沒什麼文章會講清楚的一段。
單純的 pip 安裝其實很平順。pip install -U crawl4ai 安裝得很乾淨——而且值得注意的是，它甚至能裝在 Python 3.14.2 上，雖然官方文件表面上寫的是 >=3.10，而且我的機器上剛好也沒有 3.10–3.13 的 runtime。對於使用最新 Python 版本的人來說，這是個好消息。
但接著你要跑 crawl4ai-setup，那才是硬碟開始膨脹的地方。
這個 setup 步驟不是只抓一個瀏覽器，而是抓兩整套堆疊——Playwright 和 Patchright；而且安裝紀錄還顯示它額外拉下了 Chrome for Testing、FFmpeg 和 Headless Shell。這就是「真實瀏覽器工具」的代價：瀏覽器總得放在某個地方，而在這裡，它們會直接落到你的電腦上，而且還是兩套。如果你用的是 SSD 很吃緊的筆電，或是在做一個極簡容器映像檔、每個 MB 都很寶貴，那就得先把這件事算進去。這不是純 HTTP 解析器的體積，也永遠不會是。
值得稱讚的是，這套工具對自己的狀態相當誠實。crawl4ai-doctor 跑起來通過了，還實際抓取 https://crawl4ai.com，用 14.65 秒證明瀏覽器路徑從頭到尾都可用。內建一個會真的渲染即時頁面的 doctor 指令，這點很不錯——至少「我安裝成功了嗎」不再只是聳肩帶過，而是有明確答案。
所以安裝結論很分裂：Python 端很順、很友善；瀏覽器端則很重。這兩件事同時都成立，而你在決定要不要用之前，最好都先知道。
實測：哪些地方真的撐住了，以及實際數字
我先建立了一個本機測試站，裡面有已知答案：靜態商品、JS 渲染商品、一篇刻意塞滿模板內容的文章、一個壞掉的 500 頁面，以及一個小型連結圖。接著我把 Crawl4AI 丟上去，再加上兩個公開 demo 網站。以下是成績單。
靜態頁面：全數命中。 官方 quickstart 對 example.com 的測試在 1.81 秒內回傳 Markdown。針對我本機的靜態商品目錄，Markdown 成功保留了 6/6 個預期商品名稱；而 CSS schema 擷取也把 6 筆記錄完整抓出來，包含名稱、分類、價格、評分與詳細頁 URL，欄位一個不少。整體很穩。
動態頁面：只要設定正確，也一樣穩。 這裡有個很重要的前提。對我那個 JS 渲染的商品目錄，只要在 run config 裡加上 wait_for="css:.product-card"，Markdown 與 schema 擷取都能達到 8/8 的商品召回率。再拿公開的 quotes.toscrape.com/js 測試時，它也確實把 JavaScript 注入的引言渲染出來，並且成功存下螢幕截圖，證明瀏覽器真的有把內容畫出來。這裡的「dynamic」不是口號——瀏覽器真的會渲染。只是你得告訴它要等什麼。不加 wait_for 的話，你抓到的通常只是還沒長完的頁面。
批次處理：穩。 對六個本機商品 URL 使用 arun_many()，結果一次併發跑完，6/6 全部成功，狀態碼都是 200。樣本不大，但並行路徑的確照它宣稱的方式運作。
真實網站的 Markdown 量。 針對公開的 Books to Scrape 首頁，Crawl4AI 在一次呼叫中就從即時頁面產生了 13,476 個字元的 Markdown——這很具體地展示了，從真實商品目錄爬一輪能拿到多少 LLM 可用文字。
接下來是幾個比較粗糙的地方——也就是只有在你超出舒適圈之後才會浮現的問題。
原始 Markdown 本來就會很廣。 在我的文章測試頁上，Crawl4AI 抓到了標題和全部 3/3 段正文，同時也把導覽列文字、相關連結區塊、假訂閱文案和頁尾一起帶進來。這不是 bug，而是原始 Markdown 轉換的本質：整個渲染後頁面都會變成 Markdown，模板內容也不例外。如果你要的是乾淨的文章，官方文件建議你啟用內容過濾器——PruningContentFilter 會根據文字／連結密度來評分並剔除雜訊，BM25ContentFilter 則會依據查詢來排序。我這一輪沒有實測這些過濾器，所以不會替它們打乾淨度分數——但概念很清楚：原始 Markdown 是大範圍預設值，乾淨 Markdown 則是你要主動開啟的過濾結果。不要期待零設定輸出就像編輯過的文章一樣漂亮。
500 頁面告訴了我一個小謊。 我餵給 Crawl4AI 一個刻意做壞、回傳 HTTP 500 的頁面。它的確回報了 success=false 和狀態碼 500——但錯誤訊息卻寫著「Blocked by anti-bot protection: Structural: minimal_text on small page.」。問題是，現場根本沒有 anti-bot 阻擋。那只是一個很小、幾乎沒有可見文字的錯誤頁，而 Crawl4AI 的結構性判斷看見頁面太薄，就直接把它標成 anti-bot。對任何要大規模使用的人來說，重點很明確：不要把「anti-bot」這種字面描述當成定論。先看狀態碼和實際上下文，再決定網站是不是在跟你作對。有時候，它只是頁面很小。
深度爬取不會自動繼承你的等待條件。 這點是我在串接 crawl 流程前最想先知道的事情。對動態頁面直接爬取、並明確加上 wait_for 的情況下，結果完美：8/8。可是當我讓 BFS deep crawler 從首頁去找連結並一路追下去時，它找到 5 個頁面、成功 3 個、失敗 2 個。其中一個失敗頁面，正是那個可以用明確等待正常運作的動態商品目錄。深度爬取看到的只有 45 個字元的預渲染文字，覺得頁面太薄，就在 JavaScript 還沒跑完之前，帶著同樣誤導性的「anti-bot」訊息退出了。
這個教訓很精準：「Crawl4AI 支援動態頁面」是真的；但「深度爬取會自動替你等待所有新發現的動態頁面」則不是。這其實是兩個分開的功能——每頁等待與深度爬取策略——它們不會自動融合。如果你的深度爬取要處理大量 JS 頁面，你就必須把等待邏輯明確寫進爬取設定裡。這不是 bug，而是設定現實；但如果你以為 happy path 可以無痛擴展到所有新連結，它絕對會咬你一口。
優缺點，不模糊帶過
它為什麼值得這麼多星星：
- 一套函式庫涵蓋很多場景：渲染後 Markdown、結構化 JSON 擷取、螢幕截圖、批次爬取、深度爬取，不需要把四個工具黏在一起。
- 靜態擷取非常穩——我測到 Markdown 召回率 6/6，結構化記錄 6/6，速度快而且無損。
- 動態渲染真的有效，因為背後確實有一個真瀏覽器在渲染——加上明確等待時達到 8/8，還有截圖佐證。
- Apache-2.0 授權，對商業使用很友善，而且這是一個持續更新中的專案（v0.9.0），背後社群也很大。
- 內建
crawl4ai-doctor，會真的渲染頁面來確認安裝是否正常。
它會讓你付出什麼代價：
- 初次安裝很重：磁碟上會落下兩套瀏覽器堆疊，再加上 FFmpeg 和 Headless Shell。對資源受限的機器來說，摩擦感很明顯。
- 原始 Markdown 會包含模板內容，除非你主動啟用內容過濾器——乾淨路徑不是預設值，而是你要刻意打開的選項。
- 深度爬取不會自動套用你對動態頁面的等待設定；爬到中途才遇到的 JS 頁面，可能會在沒有額外配置下直接失敗。
- 錯誤訊息有時會誤導你——我那個很薄的 500 頁面就被標成「anti-bot protection」，但實際上沒有任何阻擋。
- 沒有自我修復選擇器。你的 CSS/XPath schema 是靜態的，網站版面一改，你就得自己維護。
誰適合用 Crawl4AI，誰應該直接跳過
如果你是這類人，就很適合： 你正在為 RAG 或 agent 流程做開發，希望有一個工具能同時給你適合 LLM 的 Markdown 和同頁面的結構化 JSON。如果你的目標站點大多是 JavaScript 密集型，而且你不介意自己寫明確等待條件，並且能接受在自家基礎架構上跑一個真正的無頭瀏覽器，那 Crawl4AI 會是個很強、也很成熟的選擇。Markdown 給模型、schema 給資料庫，兩者都包在同一個 Apache-2.0 函式庫裡，確實很方便。
如果你是這類人，就先別碰： 你想要的是那種超輕量的 HTTP parser，只要在幾毫秒內把靜態 HTML 抓下來、完全不碰瀏覽器。Crawl4AI 刻意比那重，光是瀏覽器下載就會讓你覺得煩。若你磁碟或頻寬很緊，或是要部署到一個極簡容器，兩套瀏覽器堆疊會直接成為致命問題。還有，如果你是衝著自我修復選擇器來的，那更是別想——這真的是一項功能，只是不是這個工具的功能。
託管 API 的位置——Thunderbit 的角度
前面講的所有內容，都是建立在你想自己運行瀏覽器的前提上。這當然是合理的選擇，而且對不少團隊來說也是正解——完全掌控、每次呼叫零成本、整個程式碼鏈路都在你手上。不過還是值得把這個取捨講清楚，因為在 Thunderbit 我們的開發者產品，走的是相反的路：把瀏覽器、反爬處理和 JavaScript 渲染全部從你的機器上移走。
兩者的對應其實很接近，也很容易比較。我們的 POST /distill 端點，做的就是 Crawl4AI 的 Markdown 路徑會做的事——丟入頁面，輸出乾淨、可供 LLM 使用的 Markdown——差別只是 JS 渲染與反爬層都在我們這邊處理，不需要你自己裝瀏覽器。我們的 POST /extract 端點則對應結構化擷取，依你定義的 schema 回傳 JSON，並提供 renderMode 切換（none、basic、full），而不是要你手動調 wait_for。兩者也都有批次版本。我們還有 MCP 伺服器——thunderbit_distill、thunderbit_extract，以及免費的 thunderbit_suggest_fields——讓 Claude 或 Cursor 裡的 agent 可以直接呼叫；另外也有 npx @thunderbit/thunderbit-cli，可用於終端機、CI 與 cron。
真正的差別，回到誰來扛這些重量。Crawl4AI 是免費、開源、可自架的，而操作負擔——瀏覽器下載、深度爬取設定、運行這一切的機器——都由你承擔。我們的開發者堆疊則是託管 API，這些重量由我們負責，而成本則轉成按次使用計費。沒有哪個絕對更好。如果你想掌握每一層、又不想為每次請求付費，那就用 Crawl4AI。如果你想把瀏覽器維運的麻煩交出去，直接呼叫端點，那就是託管方案的價值。我們 API 背後的引擎，和支撐我們超過 10 萬用戶擴充功能的是同一套，所以它不是玩具級服務。
如果你想更全面比較這個類別，我們自己寫的 AI 網頁爬取 與 我們實測的開源 GitHub 爬蟲橫評，會比這裡更深入；否則這篇就要變成另一篇文章了。
結論：你該用 Crawl4AI 嗎？
可以——如果你是開發者，想要從同一個渲染後頁面同時拿到適合 LLM 的 Markdown 和結構化 JSON，正在做 RAG 或 agent，而且你能接受在自己的基礎架構上跑一個真正的無頭瀏覽器。在我的測試裡，它的核心表現完全符合承諾：靜態擷取 6/6、動態頁面在明確等待下 8/8、從即時商品頁拿到 13,476 個字元的 Markdown，以及穩定的批次爬取。這是一個授權清楚、維護活躍、而且真能做事的好工具。
只要你對三件事有清楚認知，就不太會踩雷：安裝時會把兩套瀏覽器堆疊丟到你的磁碟上、深度爬取不會自動替你等待新發現的動態頁面、而且很薄的錯誤頁面可能會被貼上誤導性的「anti-bot」標籤。這些都不是致命缺陷，但它們正是「以為會有奇蹟」與「真的會用工具」之間的差別——而這個工具說到底，就是瀏覽器、Markdown 轉換器，以及你要自己維護的選擇器。只要你把它理解成這樣，它就是把即時網頁轉成模型可用文字的最佳方式之一。
以上只是我單次測試後的暫時觀察。我沒有拿它跑上千頁的爬取，沒有實測內容過濾器，也沒有碰 LLM 擷取路徑或 Docker 伺服器模式。把我腦中的評分先當成「表現很強，但還有功課要做」，而不是最終成績；而且在引用任何 metadata 之前，記得再確認一次星數和版本，因為這些數字都會變動。
試試 Thunderbit 做網頁資料擷取 Get Started Free
常見問題
Crawl4AI 有自我修復或自適應選擇器嗎？
沒有。這是大家最常誤會的一點。Crawl4AI 使用的是你自己撰寫與維護的靜態 CSS/XPath schema——如果網站改名了你依賴的 class，擷取就會失效，直到你把 schema 修好為止。會自動重新定位的自適應選擇器，是另一個工具（Scrapling）的功能，不是 Crawl4AI。
跑 Crawl4AI 一定要有完整瀏覽器嗎？
基本上是。它的核心價值就是用真實瀏覽器渲染 JavaScript，所以 crawl4ai-setup 會下載兩套瀏覽器堆疊（Playwright 和 Patchright），再加上 FFmpeg 和 Headless Shell。如果你要的是完全不碰瀏覽器、只處理靜態 HTML 的小型 HTTP parser，那 Crawl4AI 不是對的選擇，你會需要更輕量的框架。
為什麼 Crawl4AI 在沒被封鎖的頁面上還說「anti-bot protection」？
因為它的結構性判斷會把可見文字很少的頁面標記出來，而訊息裡會提到 anti-bot protection。在我的測試中，一個刻意做成 HTTP 500、內容幾乎沒有的頁面也被這樣標記，儘管它根本沒有被擋。判斷網站是不是在跟你作對之前，一定要先看狀態碼和真實上下文——有時候只是頁面很薄，或是已經壞掉了。
Crawl4AI 的深度爬取會自動處理 JavaScript 頁面嗎？
不會自動處理。直接爬取並明確設定 wait_for 時，我的動態頁面表現很好，達到 8/8；但 BFS 深度爬取在發現同一頁面時就失敗了——找到 5 個頁面、成功 3 個、失敗 2 個——因為它在 JavaScript 還沒渲染完前，就先根據頁面太薄做了判斷。如果你的深度爬取要涵蓋動態頁面，就必須自己明確設定等待條件。
Crawl4AI 跟 Thunderbit 這種託管擷取 API 有什麼不同？
Crawl4AI 是免費、開源、可自架的——瀏覽器和基礎設施都由你自己運行與維護，而且沒有每次呼叫的成本。Thunderbit 的開發者產品（/distill 做 Markdown、/extract 做結構化 JSON，再加上 MCP 與 CLI）則是託管 API，渲染、反爬處理和瀏覽器維運都由我們負責，你則按次付費。差別就是：你要完全掌控、且每次請求零成本，還是把運維重量外包出去。
