整理一个网站的资料，不必逐页复制：Firecrawl 先找页面再取内容

研究一个产品，资料常常散在官网不同角落：功能页讲用途，文档页讲限制，更新日志里又补了一个关键变化。逐页打开、复制、粘贴，做完以后还得重新标注每段来自哪里。

Firecrawl 的价值在于把这些步骤拆开。Map 用于发现站内地址，Scrape 处理一个页面，Crawl 则组织多页抓取；输出可以是适合继续阅读的 Markdown，也可以是后续程序处理的结构化数据。它更适合需要稳定收集一批公开材料的人，而不是偶尔复制一段网页文字。官方项目

先列页面，避免把首页当成整个产品

官网首页通常擅长告诉你“能做什么”，却未必包含账户条件、接口边界和导出限制。Firecrawl 的 Map 会返回页面地址及相应信息，也能按主题寻找相关路径。它做的是建立候选资料清单，不是自动证明这些页面已经覆盖了全部事实。

例如为一份工具资料表收集“团队协作、导出、私有部署”三类信息，可以先定位相关页面，再决定哪些值得读取。这是教学情境。比起对整个网站无差别抓取，先收窄范围更有利于判断哪些内容新鲜、哪些只是营销文案的重复。

如果还要人工读文档，Markdown 能减少菜单和页面装饰的干扰；如果后续要填入固定资料表，可以依据明确字段提取结构化结果。例如分别记录功能名称、相关条件和对应 URL，而不是把一长段产品介绍直接当成数据库记录。

结构化并不意味着事实自动正确。页面没有写“是否支持某格式”，空缺就应该保留，而不是让后续模型凭类似产品的常识补一个答案。保存来源地址和实际读取内容，才能在信息冲突时回头检查。

Firecrawl 的抓取结果包含来源等元数据，多页任务还会返回任务状态。这让批量处理可以区分“页面已提交”和“内容已经拿到”，避免把一个成功的提交响应误当成整批资料收集完成。Map与Crawl示例

需要登录、动态交互或有访问限制的网站，仍可能产生缺页和不完整内容。工具支持的交互与抓取能力，不能扩成“任何网站都能读”。对于要支撑文章判断的关键页面，最终仍应确认返回的确实是正文，而不是登录提示、错误页或旧缓存。

官方提供托管 API 和自部署说明，但两者不应默认等价。托管服务需要相应账户与额度，自部署则要承担依赖和运行维护；主项目主要采用 AGPL，部分 SDK 与组件另用 MIT。部署说明

当收集工作从“一次复制”变成需要反复执行的资料整理，页面发现、读取和字段整理分开才更有意义。它替你接起采集环节，最终哪些内容足以支持结论，仍是资料使用者的判断。