firecrawl-crawl

firecrawl-crawl 技能概览

firecrawl-crawl 是做什么的

firecrawl-crawl 适合做网站的批量内容提取，不是抓取单个页面。它可以帮助 agent 爬取整个站点或某个指定栏目，自动跟随链接，并在一次任务中返回多个页面的内容。如果你的目标是“拿到所有文档页面”“提取 /docs 下的全部内容”或“把这个帮助中心爬到第 3 层深度”，那这个工具就是对口选择。

谁适合使用 firecrawl-crawl

firecrawl-crawl 最适合用于多页面内容采集的场景，比如文档分析、内容迁移、索引构建、QA、研究或知识入库。尤其当目标内容分布在同一域名下几十个互相链接的页面里，单靠普通 prompt 手动处理会很低效时，它的价值最明显。

firecrawl-crawl 真正解决的任务

用户采用 firecrawl-crawl，核心诉求通常不是“只把某个 URL 抓准”，而是“尽可能覆盖到目标内容”。真正的难点在于把爬取边界定义得足够清楚，让工具抓到该抓的页面，同时避免把无关栏目、重复内容，甚至整个公开网站都一起扫进去。

这个技能的差异点

firecrawl-crawl 的主要优势在于一组很实用的爬取控制能力：路径过滤、深度限制、页面数量上限、异步任务处理，以及可选的等待 / 进度显示行为。也正因为如此，firecrawl-crawl for Web Scraping 比一句泛泛的“把这个网站抓下来”更适合落地执行。

什么情况下 firecrawl-crawl 很匹配

在以下情况下，优先考虑使用 firecrawl-crawl skill：

• 你需要从同一个网站提取很多页面
• 目标页面能通过站内链接被发现
• 你希望把范围限制在 /docs、/blog 之类的路径下
• 你需要一个可重复执行的 crawl 命令，而不是一次性的临时 prompt

什么情况下不建议用它

如果你只需要一个页面、还需要先做 URL 清单盘点，或者目前还没想清楚到底哪个栏目最重要，就不要一上来用 firecrawl-crawl。这类场景通常更适合先做更简单的 search、scrape 或 map，再决定是否升级到 crawl。

如何使用 firecrawl-crawl 技能

firecrawl-crawl 的安装前提

这个技能属于 firecrawl/cli 技能集，设计上就是通过 Firecrawl CLI 来调用的。如果你的环境支持 Skills，比较实用的安装方式是：

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

另外，你还需要保证环境里能调用 Firecrawl CLI，这样 agent 才能运行 firecrawl crawl 或 npx firecrawl crawl 这类命令。

先看这个文件

优先阅读 skills/firecrawl-crawl/SKILL.md。对这个技能来说，这个文件里基本包含了最有操作价值的信息：适用场景、快速上手命令，以及控制爬取范围和运行方式的关键选项。

核心命令模式

仓库里展示了三种关键的 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>

这三种模式覆盖了大多数真实工作流：限定栏目范围的 crawl、带深度控制的更大范围站点 crawl，以及对已有任务进行轮询查看状态。

最重要的输入项

想让 firecrawl-crawl 出结果更稳，建议明确提供：

• 一个干净的起始 URL
• 如果只抓某个栏目，要写清目标站点区段
• 用 --limit 设定一个合理的页面上限
• 如果站点很大，用 --max-depth 控制深度
• 是否希望通过 --wait 同步等待完成
• 一个输出路径，方便后续检查结果

影响结果质量最大的变量，其实是爬取范围。边界定义得好，通常比后续怎么处理数据更重要。

把模糊需求改成高质量 prompt

较弱的请求：

• “Crawl this website and get everything.”

更强的请求：

• “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.”

为什么这样更有效：

• 明确点名了技能
• 给出了起始 URL
• 限定了路径范围
• 控制了成本和运行时长
• 说明了 crawl 完成后还要做什么

首次运行的最佳工作流

第一次使用时，一个实用的 firecrawl-crawl guide 可以按这个顺序来：

1. 选择尽可能窄、但仍有用的起始 URL。
2. 如果只需要某个栏目，加上 --include-paths。
3. 第一次先把 --limit 设得保守一点。
4. 如果站点分支很多，加上 --max-depth。
5. 小任务用 --wait 即可；大 crawl 可以先提交，稍后再查任务状态。
6. 用 -o 保存输出，这样你能回看实际抓到了什么。

这套顺序能减少无效 crawl，也更方便你根据首轮结果继续收紧或放宽边界。

防止爬偏的范围控制选项

这个技能里最关键的选项包括：

• --include-paths：把 crawl 限制在正确栏目内
• --limit <n>：防止页面数量失控
• --max-depth <n>：避免遍历过深
• --wait：阻塞直到完成
• --progress：等待过程中查看进度

如果这些都不设，crawl 往往会比预期更快失控，尤其是在文档站里常见的 changelog、blog 链接或大量交叉导航存在时更是如此。

异步模式与 wait 模式怎么选

如果你希望整个流程一步跑完，而且 crawl 应该现在就完成，那就用 --wait。如果你预计 crawl 会比较久，更适合走基于任务的工作流，那就不要加它。仓库也明确支持后续用 firecrawl crawl <job-id> 查看状态，这对大任务或把“提交”和“分析”拆开的 agent 流程很有帮助。

输出结果的保存与复核

只要是稍微正式一点的运行，都建议把结果写入文件，例如：

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

这样更方便你在运行后复核结果。不要在还没确认输出范围之前，就立刻让 agent 去总结或转换内容。crawl 边界一旦设错，后续的摘要、整理、分析基本都会被带偏。

好的 firecrawl-crawl 使用模式

高价值用法包括：

• 收集某个产品的全部文档页面，用于产品对比
• 提取帮助中心某个栏目，为内部搜索或 RAG 做准备
• 在重写文档前，批量提取一组 migration guide
• 对一个已知站点区段做批量抓取，而且相关页面已经通过链接连通

这些都比“在这个域名下随便找点有意思的内容”更适合 firecrawl-crawl。

firecrawl-crawl 技能 FAQ

firecrawl-crawl 对新手友好吗？

是的，前提是你已经理解“抓取单页”和“多页 crawl”之间的区别。它的命令面并不复杂，但新手最好从窄路径、低页面上限开始，避免第一次就跑出过大的任务。

firecrawl-crawl 和普通 prompt 的区别是什么？

普通 prompt 只能描述目标，但 firecrawl-crawl 给 agent 的是明确的操作路径：提交 crawl 任务、控制深度和数量上限、按需等待完成，并把结构化结果保存下来。这样能显著减少猜测空间，也让重复执行时更稳定一致。

什么时候应该用 firecrawl-crawl，而不是 scrape？

当目标内容分布在许多互相链接的页面上时，用 firecrawl-crawl。如果你只需要一个已知 URL，就用 scrape。如果你还没确定哪些页面真正重要，那么在 crawl 之前先用 map 或 search，往往是更合理的上一步。

firecrawl-crawl 适合做整站提取吗？

有时可以，但前提是你能接受较宽的覆盖范围，并且设好了足够好的限制条件。对于大型站点来说，“整站”通常不是一个好的首次运行策略。相比从首页松散地往外爬，先 crawl 某个 docs 子栏目通常更实际。

firecrawl-crawl 适合抓 docs 栏目吗？

适合。仓库示例就明确强调了像 /docs 这样的栏目级提取场景，这也是 firecrawl-crawl for Web Scraping 最强的用法之一。

什么因素会阻碍结果质量？

常见问题包括：范围描述含糊、缺少路径过滤、没有页面数量上限、起始 URL 选错。这些都不是小细节，而是直接决定输出到底有用还是充满噪音的关键因素。

如何改进 firecrawl-crawl 技能使用效果

给 firecrawl-crawl 设定更紧的爬取边界

想提升 firecrawl-crawl 输出质量，最快的方法就是把爬取边界定义得更精确。明确起始 URL、栏目路径、页面上限和目标深度。“抓取 /docs 下最多 2 层深度的文档”明显比“把这个站点爬一下”更好。

先小范围验证，再逐步放大

为了更顺利地采用 firecrawl-crawl，也为了减少浪费，建议先做一次小规模验证 crawl：

• 较低的 --limit
• 更窄的 --include-paths
• 适中的 --max-depth

如果输出看起来正确，再逐步提高 limit。这样能在任务变得耗时或昂贵之前，先把范围错误揪出来。

写 prompt 时，把 crawl 后任务一起说清楚

firecrawl-crawl install 只是成功的一部分。你还应该明确告诉 agent，提取完成后要做什么。例如：

• “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 skill 常见问题包括：

• 明明只需要某个栏目，却从首页开始
• 在大型站点上省略 --limit
• 导航结构很密集时省略 --max-depth
• 忘了加 -o，失去一个很容易复核的落点
• 只说“把所有内容都抓下来”，却没定义业务相关性

基于输出结果迭代，不要靠想象

第一次运行后，先检查实际抓到了什么。如果无关页面太多，就收紧 --include-paths 或降低深度；如果重要页面缺失，就增加深度，或换成更相关的入口 URL。最好的 firecrawl-crawl guide 一定是迭代式的：先 crawl、再检查、再调整、再重跑。

让 firecrawl-crawl 回到它最擅长的角色

把 firecrawl-crawl 用在内容收集阶段，然后再交给总结、分类、对比或索引步骤去处理。试图让 crawl 这一步一次性解决所有下游任务，通常只会让流程变得不清晰。这个技能最强的地方，是先把正确的语料集合起来。