firecrawl-crawl

firecrawl-crawl skill 概覽

firecrawl-crawl 的功能是什麼

firecrawl-crawl 是用來做網站的大量擷取，不是單頁抓取。它可以協助代理程式爬取整個網站或某個特定區段、沿著連結往下走，並在一次工作中回傳多個頁面的內容。如果你的目標是「抓出所有文件頁面」、「擷取 /docs 底下的全部內容」或「把這個 help center 爬到第 3 層深度」，這就是合適的工具。

哪些人適合使用 firecrawl-crawl

firecrawl-crawl 最適合需要蒐集多頁內容的人，例如做文件分析、搬遷、索引、QA、研究或知識匯入。當目標內容分散在同一個網域下數十個彼此連結的頁面，而一般提示詞做起來太手動時，它特別有用。

firecrawl-crawl 真正要解決的工作

使用者採用 firecrawl-crawl，重點通常不是只求單一 URL 的精準度，而是要有足夠覆蓋率。核心工作在於把爬取邊界定義得夠清楚，讓工具抓到正確頁面，同時避免把不相關區段、重複內容，甚至整個公開網站都一起掃進來，白白浪費時間。

firecrawl-crawl 與其他方式有何不同

它的主要差異在於實用的爬取控制能力：路徑篩選、深度限制、頁數上限、非同步工作處理，以及可選的等待／進度行為。也因此，firecrawl-crawl for Web Scraping 比起泛泛一句「把這個網站抓下來」，更偏向可操作、可重複執行的流程工具。

什麼情況下 firecrawl-crawl 特別適合

在以下情境中適合使用 firecrawl-crawl skill：

• 你需要從同一個網站取得很多頁面
• 目標頁面可透過站內連結被發現
• 你希望用 /docs、/blog 或類似路徑限制範圍
• 你需要可重複執行的 crawl 指令，而不是一次性的臨時提示

哪些情況不適合用 firecrawl-crawl

如果你只需要單一頁面、還需要先盤點有哪些 URL，或目前還不確定哪個網站區段才重要，就不要一開始直接用 firecrawl-crawl。這種情況通常先做較簡單的 search、scrape 或 map 會更合適，之後再升級到 crawl。

如何使用 firecrawl-crawl skill

firecrawl-crawl 的安裝脈絡

這個 skill 屬於 firecrawl/cli skill set，設計上是透過 Firecrawl CLI 工具來呼叫。如果你的環境支援 Skills，實際上的安裝方式通常是：

npx skills add https://github.com/firecrawl/cli --skill firecrawl-crawl

你也需要讓環境能使用 Firecrawl CLI，這樣代理程式才能執行像 firecrawl crawl 或 npx firecrawl crawl 這類指令。

先讀這個檔案

先從 skills/firecrawl-crawl/SKILL.md 開始看。對這個 skill 來說，這個檔案包含了大部分真正有操作價值的內容：什麼時候該用、快速上手指令，以及控制爬取範圍和執行行為的關鍵選項。

firecrawl-crawl 的核心指令模式

這個 repository 展示了三種關鍵的 firecrawl-crawl usage 模式：

# Crawl a docs section
firecrawl crawl "<url>" --include-paths /docs --limit 50 --wait -o .firecrawl/crawl.json

# Full crawl with depth limit
firecrawl crawl "<url>" --max-depth 3 --wait --progress -o .firecrawl/crawl.json

# Check status of a running crawl
firecrawl crawl <job-id>

這三種模式已涵蓋大多數實務流程：限制在特定區段的爬取、帶有深度控制的較大範圍網站爬取，以及輪詢既有工作狀態。

哪些輸入最重要

想讓 firecrawl-crawl 跑出好結果，建議提供：

• 乾淨明確的起始 URL
• 目標網站區段（如果有）
• 合理的頁數上限 --limit
• 當網站很大時，設定深度上限 --max-depth
• 是否要用 --wait 同步等到完成
• 一個輸出路徑，方便後續檢查結果

影響品質最大的槓桿就是爬取範圍。大多數情況下，邊界定得好，重要性比後續任何處理都還高。

把模糊需求改寫成有效提示

較弱的需求：

• 「把這個網站全部爬下來。」

較強的需求：

• 「Use firecrawl-crawl on https://example.com, restrict to /docs, cap at 50 pages, wait for completion, save output to .firecrawl/crawl.json, and summarize the main product setup pages after extraction.`

這樣寫有效的原因：

• 明確點出 skill 名稱
• 提供起始 URL
• 限制了路徑範圍
• 控制成本與執行時間
• 指定 crawl 完成後要接著做什麼

第一次使用 firecrawl-crawl 的最佳流程

第一次上手時，實用的 firecrawl-crawl guide 可以照這樣做：

1. 選擇範圍最小、但仍有用的起始 URL。
2. 如果只需要某個區段，就加上 --include-paths。
3. 第一次先把 --limit 設得保守一些。
4. 如果網站分支很多，就加上 --max-depth。
5. 小型工作用 --wait；大型爬取則可先提交，之後再查工作狀態。
6. 用 -o 把輸出存起來，方便確認實際收集到了什麼。

這個流程能減少無效爬取，也更容易根據第一次結果微調邊界。

能避免 firecrawl-crawl 失控的範圍控制

這個 skill 裡最重要的選項包括：

• --include-paths：把爬取限制在正確區段
• --limit <n>：避免頁數一路暴增
• --max-depth <n>：防止往太深層遍歷
• --wait：阻塞直到完成
• --progress：等待期間查看進度

如果忽略這些設定，爬取範圍往往會比預期更快失控，尤其是在文件站上有 changelog、blog 連結或大量交叉導覽時更常見。

Async 模式與 wait 模式怎麼選

如果你希望整個流程一步完成，而且 crawl 應該現在就跑完，就用 --wait。如果預期爬取時間較長，或你偏好以工作為單位的流程，就不要加它。repo 也明確支援稍後用 firecrawl crawl <job-id> 查詢狀態，對大型工作或把提交與分析拆開的代理流程很實用。

firecrawl-crawl 的輸出處理與檢查方式

正式執行時，建議一定要寫入檔案，例如：

firecrawl crawl "https://example.com" --include-paths /docs --limit 50 --wait -o .firecrawl/crawl.json

這樣會讓執行後檢查容易很多。在要求代理程式進一步摘要或轉換結果之前，先確認輸出是否真的包含你要的區段與頁數。crawl 邊界如果設錯，後面的整理與綜合通常也會跟著失真。

好的 firecrawl-crawl 使用情境

高價值的用途包括：

• 蒐集某產品的所有文件頁面來做比較
• 抓取 help center 某個區段，供內部搜尋或 RAG 前處理使用
• 在改寫文件前，先擷取一整組 migration guide
• 對已知網站區段進行大量抓取，而且相關頁面已經透過連結串在一起

這些都遠比「幫我找出這個網域上任何有趣的內容」更適合 firecrawl-crawl。

firecrawl-crawl skill 常見問題

firecrawl-crawl 對新手友善嗎？

算是友善，前提是你已經理解單頁 scraping 和多頁 crawling 的差別。它的指令面不算大，但新手最好先從狹窄路徑和較低頁數上限開始，避免一次跑得過大。

firecrawl-crawl 和一般提示詞有什麼差別？

一般提示詞可以描述目標，但 firecrawl-crawl 會提供代理程式一條明確的操作路徑：提交 crawl 工作、控制深度與上限、視需要等待完成，並把結構化輸出存下來。這能減少猜測空間，讓重複執行時的結果更一致。

什麼時候該用 firecrawl-crawl，而不是 scrape？

當目標內容分布在許多彼此連結的頁面時，應該用 firecrawl-crawl。如果你只需要一個已知 URL，就用 scrape。若你還不確定哪些頁面才重要，那在 crawl 之前，map 或 search 往往是更好的前一步。

firecrawl-crawl 適合做整站擷取嗎？

有時候可以，但前提是你能接受較廣的覆蓋範圍，而且限制設得夠好。對大型網站來說，「整站」通常不是第一次執行的好選擇。比起從首頁用很寬鬆的控制開始跑，通常先爬文件子區段更實際。

firecrawl-crawl 很適合抓 docs 區段嗎？

是的。repository 範例就明確強調像 /docs 這種區段式擷取，這也是 firecrawl-crawl for Web Scraping 最強的使用情境之一。

哪些因素最容易讓結果變差？

常見阻礙包括範圍定義模糊、缺少路徑篩選、沒有頁數上限，以及從錯的 URL 起跑。這些不是小細節，而是直接決定輸出到底有用還是雜訊很多的關鍵。

如何改進 firecrawl-crawl skill 的使用效果

給 firecrawl-crawl 更精準的爬取邊界

想改善 firecrawl-crawl 的輸出，最快的方法就是把爬取邊界定清楚。請明確指出起始 URL、區段路徑、頁數上限與預期深度。像「爬 /docs 底下的文件，最多 2 層深」就遠比「把整個網站爬一下」有效得多。

先小跑，再逐步擴大

如果想提高成功率並減少浪費，先做一次小型驗證 crawl：

• 較低的 --limit
• 較窄的 --include-paths
• 中等的 --max-depth

如果輸出看起來正確，再把上限放大。這能在成本或時間變高之前，先抓出範圍設定錯誤的問題。

提示裡要寫出 crawl 完成後的任務

firecrawl-crawl install 只是成功的一部分。你也應該明確告訴代理程式，擷取完成後要做什麼。例如：

• 「Use firecrawl-crawl to extract /docs up to 50 pages, save to .firecrawl/crawl.json, then identify onboarding, auth, and API reference pages.`

這樣能提升端到端的實用性，因為 crawl 與後續分析從一開始就是對齊的。

避開 firecrawl-crawl 常見失敗模式

firecrawl-crawl skill 常見問題包括：

• 明明只需要某個區段，卻從首頁開始
• 在大型網站上省略 --limit
• 導覽很密集時沒有設定 --max-depth
• 忘了加 -o，失去最容易檢查結果的落點
• 要求抓「全部」，卻沒有定義商業上真正相關的內容

依據輸出迭代，不要只靠猜測

第一次執行後，先看實際收集到了什麼。如果無關頁面太多，就收緊 --include-paths 或降低深度；如果重要頁面缺漏，就提高深度或改成從更相關的入口 URL 開始。最好的 firecrawl-crawl guide 是一個迭代流程：crawl、檢查、調整、重跑。

讓 firecrawl-crawl 扮演正確角色

把 firecrawl-crawl 用在蒐集階段，之後再交給摘要、分類、比較或索引流程處理。若想在 crawl 這一步就一次解決所有下游任務，通常只會讓流程變得更混亂。這個 skill 最強的地方，是先幫你收集到正確的內容語料。