兩款工具，目標一樣，出發點卻完全不同。Thunderbit 直接給你一個瀏覽器擴充功能，然後跟你說：「點一下就能用。」Firecrawl 則交給你一組 API 金鑰，並說：「自己寫請求。」
這種「無程式碼」與「API 優先」的拉鋸，正是當前網頁爬取市場的縮影。全球網頁爬取市場 持續成長，競爭產品也明顯分成兩派：一派是視覺化、適合商務使用者的平台；另一派則是以開發者為核心、為 AI 管線打造的上下文引擎。如果你正在猶豫 Thunderbit 和 Firecrawl 該選哪個，其實你真正要決定的是：哪一派更符合你的工作流程、技能背景與預算。我花了很多時間深入研究這兩款工具——包括文件、定價頁、社群討論，以及實際產品介面——這篇文章就是我當初最希望有人整理給我的版本。我們會從功能、流程、定價計算、AI/LLM 整合一路講到最後的決策框架，幫你真正做出選擇。
你是哪一類爬取使用者？這比功能更重要
在比較任何功能之前，先問自己一個問題：你是誰？
我不是在問哲學上的「你是誰」，而是很實際地問：你是行銷人員，需要在中午前把競品價格整理到試算表裡？還是開發者，正在為正式環境中的 LLM 建置 RAG 管線？答案會影響一切——哪個工具更快、更省錢，也更不讓你抓狂。
我通常把使用者分成兩種主要類型：
| 面向 | 類型 A — 商務使用者 | 類型 B — 開發者 / AI 工程師 |
|---|---|---|
| 主要操作介面 | 瀏覽器擴充功能（Thunderbit） | API / CLI / MCP（Firecrawl 或 Thunderbit API） |
| 常見任務 | 將名單、價格、商品列表匯出到 Excel | 爬取整個網域、把 Markdown 餵進 RAG、透過 n8n 自動化 |
| 技能假設 | 不會寫程式，也不碰終端機 | 熟悉 Python、cURL、CI/CD |
| 成功指標 | 盡快把資料送進試算表 | 吞吐量、每頁成本、Markdown 還原度 |
下方每一部分都會用這兩種視角來評估。如果你是類型 A，可以快速略過偏開發者的內容；如果你是類型 B，請特別留意 AI Agent 和大規模定價的部分。
Thunderbit 是什麼？
Thunderbit 是一個具備代理能力的網頁爬蟲與自動化平台。它的主介面是一個 Chrome/Edge 瀏覽器擴充功能，專為不寫程式的人設計。核心流程很簡單：打開頁面，點一下 One Click Extract。系統會自動偵測、閱讀並分析頁面；Run Now 可以立即啟動，否則也會在匯出到 Excel、Google Sheets、Airtable、Notion 或其他支援的目的地之前，自動開始擷取。
但 Thunderbit 不只有瀏覽器介面。它也提供 Open API（包含 Distill 與 Extract 端點）、可供 Claude 和 Cursor 等 AI Agent 主機使用的官方 MCP Server，以及適用於終端機流程的 CLI。因此它同時涵蓋兩種族群——無程式碼商務使用者，以及想要程式化存取的開發者。
你需要知道的重點：
- One Click Extract 會自動提議語意化的輸出欄位；Field AI Prompts 可進一步進行轉換、分類、翻譯或清理數值。
- 在相容頁面上，支援分頁、無限捲動與子頁面補充資料。
- Browser Mode 使用你的登入工作階段；Cloud Mode 則適合公開、排程或平行處理。
- API 提供 Markdown（透過 Distill）與結構化 JSON（透過 Extract），並支援非同步批次、webhook 與渲染控制。
Firecrawl 是什麼？
Firecrawl 稱自己為 AI Agent 使用的網頁上下文 API。它以開發者為中心、API 優先，目標是把網頁轉成適合 LLM 使用的資料——乾淨的 Markdown、結構化 JSON、截圖、連結、媒體等等。
它的產品範圍不只是「抓資料」而已。現有端點包括：
| 端點 | 功能 |
|---|---|
| Scrape | 單一 URL → Markdown、HTML、JSON、截圖、連結、媒體等 |
| Crawl | 遞迴探索並爬取整個網站的頁面 |
| Map | 快速發現 URL，不抓取內容 |
| Search | 網頁／新聞／圖片搜尋，可選擇附帶爬取結果 |
| Agent | 由提示驅動的自主搜尋／導航／擷取（研究預覽） |
| Interact | 由提示或程式碼驅動的瀏覽器工作階段延續 |
| Parse | PDF／文件解析 |
| Monitor | 排程式變更監控 |
| Batch Scrape | 針對已知 URL 清單進行非同步處理 |
Firecrawl 現在也不再只是「只能寫程式用」。它有 Playgrounds 可試用 Scrape、Crawl、Map 與 Agent，並且與 n8n、Zapier、Make 都有官方整合。Agent Playground 甚至支援類似 CSV 的格狀輸出。這些仍然和在瀏覽器擴充功能中直接選欄位不同，但「Firecrawl 一定得寫程式」這個說法，已經不能再當成絕對命題。
我研究時看到 Firecrawl 的 GitHub repository 大約有 166K stars——這代表開發者關注度與社群能見度很高，但不等於可靠度或品質保證。
Thunderbit vs Firecrawl：逐項功能比較
以下是從兩種使用者視角出發，最重要的功能對照：
| 功能 | Thunderbit | Firecrawl |
|---|---|---|
| 主要介面 | 瀏覽器擴充功能（Chrome/Edge）＋ Web App | REST API / SDK / CLI / Playgrounds |
| 設定方式 | 安裝擴充功能，基本使用不需 API key | 註冊取得 API key，安裝 SDK 或使用 Playground |
| 欄位定義 | One Click Extract，可在 UI 中編輯 | JSON schema、LLM 推斷或 Markdown 輸出 |
| JS 渲染 | Browser Mode（使用當前工作階段）或 Cloud | 內建渲染與動作控制（等待、點擊、輸入、捲動） |
| 分頁處理 | 在相容頁面支援 | 透過 Recursive Crawl 並可控制深度與篩選 |
| 整站爬取 | 分頁＋子頁面＋API 發現／批次處理 | 第一級支援的 Recursive Crawl 與 Map 端點 |
| 輸出格式 | 內建表格、Excel、CSV、JSON、Google Sheets、Airtable、Notion | Markdown、HTML、JSON、截圖、連結、媒體、摘要、查詢結果 |
| 排程 | 以儲存設定建立重複執行爬蟲 | Monitor 端點進行排程檢查 |
| 反爬處理 | 受控渲染／代理（Browser 與 Cloud 模式） | 基礎與 Enhanced 代理模式（Enhanced：每頁 +4 credits） |
| 開源 | 否 | 核心為 AGPL-3.0；部分 SDK 為 MIT；自架版本缺少部分 Cloud 功能 |
設定與學習曲線
Thunderbit：安裝擴充功能、打開頁面、點擊。你通常在一兩分鐘內就能開始擷取資料。沒有 API key、沒有終端機、沒有 schema 檔。
Firecrawl：建立帳號、取得 API key（或在試用階段使用 Playground／無 key 的 MCP 路徑），然後寫請求或設定自動化節點。Playground 確實降低了門檻，但思維模型仍然是「設定 API 呼叫」，而不是「指向一個頁面」。對開發者來說很自然；對只想快速拉名單的業務代表來說，則像是另一個世界。
結論： 類型 A 的使用者，Thunderbit 勝出。類型 B 的使用者，Firecrawl 是標準工具。
資料擷取與欄位定義
Thunderbit 的 One Click Extract 會分析你所在的頁面並提議欄位——產品名稱、價格、評分、URL，或頁面上出現的任何欄位。系統會自動準備輸出，而必要時仍可使用欄位控制來做特殊轉換。Field AI Prompts 讓你可以為每一欄加入指令，例如：「分類為 Electronics 或 Apparel」、「翻譯成西班牙文」、「只擷取數字價格」。全程不需要寫程式。
Firecrawl 的結構化擷取則透過你在 API 呼叫中定義的 JSON schema 完成（或透過 Agent 的提示驅動方式）。使用 Scrape 的 jsonOptions 參數，可以指定欄位與型別。Agent 則可以根據自然語言提示，自主導航並擷取資料。兩者都很強大，但前提都是你得習慣用 JSON 或提示詞來表達資料需求，而不是在視覺化表格裡直接檢視。
輸出格式與匯出目的地
真正的分野在這裡最明顯。
Thunderbit 可以直接從擴充功能內，把資料匯出到 Google Sheets、Airtable、Notion、Excel、CSV 和 JSON，只要幾下點擊即可。結果表格在匯出前就能直接看到並檢查。對商務使用者來說，這就是全部。
Firecrawl 則是透過 API 回傳資料。Markdown、清理後的 HTML、原始 HTML、結構化 JSON、截圖、連結、圖片、品牌資訊、音訊／影片、摘要，以及自然語言查詢結果都可以取得。要把這些資料放進試算表，通常需要額外寫一層整合程式，或搭配自動化平台（n8n、Zapier、Make）。對要餵給 LLM 管線的開發者來說，API 回應本身就是目的地；對行銷人員來說，這代表多了一步。
爬取與分頁
Firecrawl 在整站爬取上明顯更有優勢。它的 Crawl 端點 可以遞迴探索並爬取整個網域，支援 include/exclude 路徑篩選、深度控制、子網域設定，預設請求上限為 10,000 頁。Map 則能在不抓內容的情況下發現 URL——每次呼叫只算一個 credit，不是每個 URL 都算一次。
Thunderbit 則透過擴充功能，支援相容頁面上的分頁、無限捲動與子頁面補充資料。它的 API 也支援先發現連結，再進行篩選後的批次處理；官方文件也描述了如何編排 10K+ URL 集合。不過，它沒有像 Firecrawl 那樣單一、第一級的 Recursive Crawl 或 Map 端點。互動模型不同：Thunderbit 是先發現、再批次 Distill/Extract，把多頁工作組合起來；Firecrawl 則把這件事包進單一 API 呼叫裡。
重點： 如果你的主要需求是「抓整個網站」，Firecrawl 的 Crawl/Map 抽象更直接；如果你是要從特定頁面或分頁清單中擷取結構化資料，Thunderbit 的擴充功能流程更快上手。
同一個任務，兩款工具：流程對照實作
我找不到一篇比較文章同時示範兩款工具做同一個擷取任務，所以這裡直接來：從公開的電商分類頁中擷取商品列表（名稱、價格、評分）。
如何使用 Thunderbit 擷取商品資料
- 在 Chrome 中打開頁面 —— 前往包含商品列表的分類頁。
- 點擊工具列上的 Thunderbit 擴充功能圖示。
- 點擊「One Click Extract」 —— Thunderbit 會分析頁面並建議欄位：Product Name、Price、Rating、Image URL 等。
- 可選的微調 —— 系統已經自動準備好擷取流程；只有在需要特殊輸出時，才加上欄位指令。
- 讓它自動執行，或按 Run Now —— 如果你沒有進行第二個動作，任務會自動開始，並把結果填入擴充功能內的表格。
- 匯出 —— 點擊「Export to Google Sheets」（或 Excel、Airtable、Notion、CSV）。
預估時間：2～5 分鐘。沒有程式。沒有終端機。沒有 schema 檔。
如何使用 Firecrawl 擷取商品資料
- 從 Firecrawl dashboard 取得 API key。
- 安裝 Python SDK（
pip install firecrawl-py）或使用 cURL。 - 撰寫擷取呼叫：
from firecrawl import FirecrawlApp
app = FirecrawlApp(api_key="your-api-key")
result = app.scrape_url(
"https://example.com/category-page",
params={
"formats": ["json"],
"jsonOptions": {
"schema": {
"type": "array",
"items": {
"type": "object",
"properties": {
"product_name": {"type": "string"},
"price": {"type": "string"},
"rating": {"type": "string"}
}
}
}
}
}
)
- 執行腳本並解析 JSON 回應。
- 把資料載入你的目的地——再寫一些程式，把資料送到試算表、資料庫或向量儲存庫。
預估時間：5～30 分鐘，視你對 SDK 與 schema 定義的熟悉程度而定。
流程比較摘要
| 步驟 | Thunderbit（瀏覽器擴充功能） | Firecrawl（API） |
|---|---|---|
| 設定時間 | 安裝擴充功能，基本使用不需驗證 | 取得 API key，安裝 SDK 或使用 cURL |
| 欄位定義 | AI 建議，可在 UI 中編輯 | JSON schema 或 LLM 推斷 |
| 執行方式 | 瀏覽器內或雲端 | 雲端 API 呼叫 |
| 輸出 | Excel、Google Sheets、Airtable、Notion 等 | JSON / Markdown 回應 |
| 學習曲線 | 低（點選即可） | 中等（需要程式，或用 Playground 試用） |
Thunderbit 的路徑，最適合「我現在就要把這些資料放進試算表」。Firecrawl 的路徑，最適合「我需要把這些資料放進應用程式管線」。
Thunderbit vs Firecrawl：真實規模下的定價
定價通常是大多數比較文章最偷懶的地方——只列出方案名稱就結束了。但這兩款工具的 credit 機制差異很大，所以「每頁成本」根本不是一個簡單數字。我查過兩者的官方定價頁（驗證日期：2026-08-13），整理出更有參考價值的版本。
重要提醒： 兩款工具的定價都可能變動。做決定前，請先確認最新方案：Thunderbit Pricing / Thunderbit API Pricing 與 Firecrawl Pricing。以下數字反映的是研究當下的公開資訊。
Thunderbit 定價拆解
Thunderbit 的無程式碼擴充功能與 Open API 是分開計價的，不要混在一起看。
擴充功能 / Web App 方案：
| 方案 | 月費 | 每月額度 |
|---|---|---|
| Free | $0 | 6 頁/月（每頁最多 30 credits） |
| Starter | $15 | 500 |
| Pro Tier 1 | $38 | 3,000 |
| Pro Tier 2 | $75 | 6,000 |
| Pro Tier 3 | $125 | 10,000 |
| Pro Tier 4 | $249 | 20,000 |
一般來說，1 個 credit 大約等於 1 筆輸出資料列；如果有子頁面補充資料，每筆會消耗 2 個 credits。年繳方案有明顯折扣。
Open API 方案（另計）：
| 方案 | 價格 | 年度單位數 | Distill 頁數 | Extract 頁數 |
|---|---|---|---|---|
| Free | 一次性 $0 | 600 | 600 | 30 |
| Starter | 年繳 $16/月 | 60,000/年 | 60,000 | 3,000 |
| Pro 1 | 年繳 $40/月 | 600,000/年 | 600,000 | 30,000 |
Distill 每頁 1 單位；Extract 每頁 20 單位。這些單位不能和擴充功能的 credits 混用。
Firecrawl 定價拆解
Firecrawl 採用 credit 制，但不同端點與選項的耗用方式不一樣。
標準方案：
| 方案 | 月費 | 每月 credits |
|---|---|---|
| Free | $0 | 1,000 |
| Hobby | $19 | 5,000 |
| Standard | $99 | 100,000 |
| Growth | $399 | 500,000 |
| Scale | $749 | 1,000,000 |
但要注意： 每頁 1 credit 只適用於基本 Scrape/Crawl，且不加任何額外功能。若加入 JSON 輸出，每頁會再加 4 credits（總共 5）。若再加 Enhanced 代理模式，又會再加 4（JSON + Enhanced 總共 9）。Interact 工作階段、Agent 執行、Extract（依 token 計費）、PDF 解析、PII 遮罩與媒體擷取，全部都有自己的計量方式。修飾項目會疊加。
另外補充關於按用量付費：研究當下，Firecrawl 的即時定價介面顯示有一張一次性 $5、1,000 credits 的卡片，但其 FAQ 同時寫明目前並未提供 pay-per-use。結帳前請再次確認。
未使用的方案 credits 通常不會累積到下個月（Scale / Enterprise 層級則有少數例外）。
成本情境：僅做基本抓取
下表假設 Firecrawl 只做成功的單頁基本 Scrape，不加 JSON、Enhanced 或其他修飾，而 Thunderbit 擴充功能則以每頁一筆輸出資料列 來估算：
| 規模 | Firecrawl 方案 | 估計成本 | Thunderbit 方案 | 估計成本 |
|---|---|---|---|---|
| 約 100 頁/月 | Free（1,000 credits） | $0 | Free（有限）或 Starter | $0–$15 |
| 約 1,000 頁/月 | Free（1,000 credits） | $0 | Starter（$15）或 Pro T1（$38） | $15–$38 |
| 約 10,000 頁/月 | Standard（100K credits） | $99 | Pro T3（$125）或 Pro T4（$249） | $125–$249 |
但如果照字面解讀，這些數字會誤導你。因為一個分類頁可能產出 50 筆商品資料，對 Thunderbit 來說大約耗用 50 credits，但對 Firecrawl 來說可能只耗用 1–9+ credits（取決於輸出格式與代理模式）。而詳細頁的 Markdown 工作負載又是另一回事。兩者的計量單位——輸出資料列 vs. 輸入 URL——本質上不同。
誠實的答案： 不能只看「頁數」來判斷哪個更便宜。你必須清楚你的實際工作量：有多少 URL、每個 URL 會產生多少輸出列、需要什麼輸出格式、是否需要遞迴爬取，以及是否要用代理／渲染模式。
AI Agent 與 LLM 管線：給開發者看的 Thunderbit vs Firecrawl
現在越來越多爬取需求，來自正在建置 RAG 系統、自主 Agent 與 LLM 資料管線的開發者。兩款工具都能服務這類需求，但強項不同。
| 能力 | Firecrawl | Thunderbit |
|---|---|---|
| 用於 RAG 的 Markdown 輸出 | 核心功能；品質評價高 | Distill 端點提供精簡 Markdown |
| LangChain / LlamaIndex 整合 | 有文件化的 loader 與教學 | API + MCP 可發揮類似作用；研究當下沒有專用 loader |
| 給 AI Agent 使用的 MCP Server | 有提供（已文件化 keyless/OAuth 路徑） | 官方 @thunderbit/mcp-server |
| 給程式化 Agent 使用的 CLI | 有官方 CLI | 官方 @thunderbit/thunderbit-cli |
| 結構化 JSON 擷取 | 透過 Scrape JSON 和 Agent，以 schema 為基礎 | One Click Extract + API Extract |
| 建立語料庫用的整站爬取 | 第一級的 Crawl/Map 端點 | 透過發現 + 批次處理組合（模型不同） |
Firecrawl 的 LLM 友善輸出
Firecrawl 的 Markdown 輸出普遍被視為 LLM 消費的優質選擇。它是預設格式、很乾淨，而且也是許多 LangChain 與 LlamaIndex 整合教學的基礎，這些教學在整個 RAG 生態中都很常見。如果你的主要流程是「爬網站 → 分塊 Markdown → 嵌入向量資料庫 → 用 LLM 查詢」，那 Firecrawl 已經有一條成熟且文件完備的路徑。
Agent 則把這件事再往前推一步：它可以根據提示，自主搜尋、導航與擷取，對於「還不知道確切 URL」的探索型 RAG 工作流特別有用。
Thunderbit 的 API、MCP 與 CLI：為 Agent 工作流而生
Thunderbit 的 Open API 提供 Distill（URL → 節省 token 的 Markdown）與 Extract（URL + schema → 結構化 JSON），並支援非同步批次、webhook、渲染控制與國家／地區目標設定。文件中也明確討論了 RAG 與 Agent 管線。
MongoDB MCP Server 將 Thunderbit 工具暴露給相容的 AI 主機——像是 Claude、Cursor、Windsurf、Claude Code。CLI 則支援終端機與 coding-agent 工作流。這些都是真實、文件齊全的功能，不是行銷口號。
Thunderbit 真正不同的地方在於：它是同一個平台，同時也給你無程式碼瀏覽器擴充功能。也就是說，一套系統、一家供應商——擴充功能用於臨時性的商務擷取，API/MCP 則用於開發者管線。
你的 AI 工作流適合哪個工具？
- LangChain / LlamaIndex 的 RAG 管線： 現階段 Firecrawl 的整合路徑更成熟、文件更完整。
- 透過 MCP 讓 Agent 觸發擷取（Claude Code、Cursor）： 兩者都有 MCP Server；Thunderbit 是官方且有文件，Firecrawl 則提供 keyless/OAuth 路徑。
- 整站語料庫建置： Firecrawl 的遞迴 Crawl/Map 更直接。Thunderbit API 也能透過「發現 + 批次」組合出類似結果，但互動模型不同。
- 同時要無程式碼與 API 的單一平台： 這裡只有 Thunderbit 符合。
老實說，如果你的世界是 LangChain loader 與 RAG 教學，那你更常會看到 Firecrawl。如果你的世界是「銷售團隊要 Sheets 裡的資料，工程團隊也要 MCP 端點」，那 Thunderbit 能一次滿足，少了很多接線麻煩。
整合與自動化：資料最後要流向哪裡？
Thunderbit：直接匯出到 Sheets、Airtable、Notion 等
Thunderbit 的擴充功能可直接匯出到 Google Sheets、Airtable、Notion、Excel、CSV 與 JSON。這是原生、內建於產品中的體驗——不需要中介層、不需要程式碼、不需要第三方自動化。對商務使用者來說，這往往是最重要的功能。
對自動化建置者而言，Thunderbit 的 API 可透過 n8n、Make 或 Zapier 的 HTTP request 節點呼叫。這不是一鍵整合，但對熟悉設定 HTTP 呼叫的人來說相當直觀。
Firecrawl：API 回應、Webhook 與自動化節點
Firecrawl 透過 API 回應、工作任務、SDK、CLI、MCP 與 webhook 傳回資料。若你要把資料送進試算表或 CRM，通常就是寫程式，或用自動化平台處理。
Firecrawl 在 n8n 有官方整合節點（支援 OAuth 與 API key 路徑），也有經驗證的 Make 整合與官方 Zapier 應用程式。這些都是真正可以走無程式碼路線的商務目的地；但起點仍然比較像「在自動化平台裡設定一個 API 式操作」，而不是「在瀏覽器擴充功能裡按 Export」。
Webhook 支援對非同步 Crawl 工作特別有用：先啟動爬取，完成後收到通知，再把結果往下游處理。
| 整合需求 | Thunderbit | Firecrawl |
|---|---|---|
| 直接匯出試算表 | 原生支援（Sheets、Excel、CSV） | 透過程式或自動化節點 |
| Airtable / Notion 匯出 | 原生支援 | 透過程式或自動化節點 |
| n8n / Make / Zapier | 可透過 HTTP 節點呼叫 API | 有官方節點 |
| Webhooks | API 支援 webhooks | 原生 webhook 支援 |
| LangChain / LlamaIndex | API + MCP | 有文件化 loader |
Thunderbit vs Firecrawl：根據你的流程選對工具
現在來到真正會幫你選邊站的決策框架。
決策矩陣
| 如果你是… | 建議選擇 | 原因 |
|---|---|---|
| 今天就要把資料放進試算表的行銷／營運人員 | Thunderbit（擴充功能） | 不用寫程式、代理式擷取、可原生匯出到 Sheets/Excel/Airtable/Notion |
| 要建置 LLM 資料管線的開發者 | Firecrawl（API） | Markdown 優先、LangChain loader、遞迴 Crawl/Map、文件深度高 |
| 使用 AI Agent / Claude Code / Cursor 的人 | 兩邊都看 MCP | Thunderbit 有官方 MCP Server；Firecrawl 有 keyless/OAuth MCP 路徑 |
| 用 n8n / Make 做自動化的人 | 比較整合節點 | Firecrawl 有官方 n8n/Make 節點；Thunderbit API 可透過 HTTP 節點使用 |
| 需要同時有無程式碼與 API 存取的團隊 | Thunderbit | 單一平台就涵蓋瀏覽器擴充功能、API、MCP 與 CLI |
| 需要遞迴抓整個網域的人 | Firecrawl | 第一級的 Crawl/Map 端點；Thunderbit 的模型是發現 + 批次處理 |
| 預算敏感、量又不大的使用者 | 兩者皆可（都有免費方案） | Firecrawl Free：1,000 credits；Thunderbit Free：有限頁數 |
什麼時候兩個都用
有些團隊確實會同時使用兩者，而且很合理。Thunderbit 用於快速、臨時性的商務擷取——像是業務拉名單、產品經理抓競品價格。Firecrawl 則用於大規模開發者管線、RAG 語料庫建置與整站爬取。雖然我在研究中沒有找到可信的真實案例說明「同一團隊兩個都用」的具體實作，但從架構上來看完全說得通：它們在主要工作流程上的重疊其實很少。
Thunderbit vs Firecrawl：快速參考總表
| 面向 | Thunderbit | Firecrawl |
|---|---|---|
| 目標使用者 | 商務使用者＋開發者 | 開發者＋AI 工程師 |
| 主要介面 | 瀏覽器擴充功能（Chrome/Edge） | REST API / SDK / CLI / Playgrounds |
| 設定方式 | 安裝擴充功能，不需 key | API key 或 Playground／無 key 試用 |
| 欄位定義 | One Click Extract（視覺化介面） | JSON schema / LLM 提示詞 / Markdown |
| 遞迴網站爬取 | 沒有對應 Crawl/Map 端點；採發現 + 批次處理 | 第一級支援 Crawl 與 Map |
| 輸出格式 | 表格、Excel、CSV、JSON、Sheets、Airtable、Notion | Markdown、HTML、JSON、截圖、連結、媒體、摘要、查詢 |
| 定價模式 | Credits（擴充功能）＋ Units（API）— 分開計算 | Credits，會因端點／選項而倍增 |
| 免費方案 | 6 頁/月（擴充功能）；600 units（API） | 1,000 credits/月 |
| AI/LLM 整合 | Distill Markdown、Extract JSON、MCP、CLI | Markdown 優先、LangChain/LlamaIndex loader、MCP、Agent |
| MCP Server | 官方 @thunderbit/mcp-server | 有提供（keyless/OAuth 路徑） |
| CLI | 官方 @thunderbit/thunderbit-cli | 官方 CLI |
| 排程 | 以儲存設定建立重複執行爬蟲 | Monitor 端點 |
| 反爬機制 | 受控渲染／代理（Browser + Cloud） | 基礎 + Enhanced 代理（+4 credits/page） |
| 開源 | 否 | 核心為 AGPL-3.0；自架版本缺少部分 Cloud 功能 |
| 原生匯出試算表 | 有（Sheets、Excel、Airtable、Notion） | 沒有（需透過程式或自動化） |
常見問題：Thunderbit vs Firecrawl
Thunderbit 或 Firecrawl，哪個更適合非技術使用者？
Thunderbit 的瀏覽器擴充功能與 One Click Extract 流程，就是為沒有程式背景的人設計的。你打開頁面、點 One Click Extract，讓系統自動分析並啟動，最後直接匯出——全都在瀏覽器內完成。Firecrawl 的主介面是 API，不過它現在也提供 Playground 與自動化平台整合（n8n、Make、Zapier），降低了使用門檻。如果你要的是最純粹的無程式碼、點一下就能用的體驗，Thunderbit 更清楚。
Firecrawl 可以直接匯出到 Google Sheets 或 Excel 嗎？
原生不行。Firecrawl 是透過 API 回應（JSON、Markdown 等）回傳資料。若要把資料放進 Sheets 或 Excel，你需要寫程式，或搭配像 n8n、Zapier 這類自動化工具與 Firecrawl 的官方節點。Thunderbit 則支援在產品內直接匯出到 Google Sheets、Excel、Airtable 和 Notion。
Thunderbit 有給開發者用的 API 嗎？
有。Thunderbit 提供 Open API，包含 Distill（Markdown）與 Extract（結構化 JSON）端點、非同步批次、webhook 與渲染控制。它也有給 AI Agent 主機使用的官方 MCP Server 與適用於終端機流程的 CLI。API 有獨立的計價方式，和擴充功能分開。
哪個工具更適合抓整個網站？
Firecrawl 就是為這個場景打造的。它的 Crawl 端點可以遞迴探索並爬取整個網域，並支援深度、路徑與子網域控制。Map 端點則能在不抓取內容的情況下發現 URL。Thunderbit 雖然支援分頁、子頁面補充與基於 API 的發現＋批次處理，但沒有對應的單次呼叫遞迴 Crawl 端點。若你的需求是「把這個網域的每一頁都給我」，Firecrawl 更直接。
我可以同時使用 Thunderbit 和 Firecrawl 嗎？
可以，而且對需求多元的團隊來說很合理。Thunderbit 的擴充功能適合快速、臨時性的商務擷取（名單、價格、列表 → 試算表），Firecrawl 的 API 則適合大規模開發者管線、RAG 語料庫建置與遞迴網站爬取。兩者在主要工作流程上的重疊很小，因此在混合場景下更像是互補，而不是正面競爭。
延伸閱讀與資源
- Thunderbit：開始使用 — 首頁與快速上手指南
- Thunderbit Open API 文件 — Distill、Extract、批次、webhook
- Thunderbit MCP Server — 為 Claude、Cursor、Windsurf 提供 Agent 整合
- Thunderbit CLI — 終端機與 coding-agent 工作流程
- Thunderbit YouTube 頻道 — 影片教學
- Firecrawl 文件 — 完整 API 參考
- Firecrawl 定價 — 最新方案與 credit 細節
- 什麼是網頁爬取 — 基礎概念
- 最佳 AI 網頁爬蟲 — 更廣泛的市場比較
- 無程式碼網頁爬取 — 無程式碼做法解析
- AI 網頁爬取 — AI 如何改變擷取流程
了解更多
