什么是葫芦流：把网页抓取做成可复用的产品资产

为什么需要把抓取做成产品，而不是再写一个脚本

网页抓取在很多团队里长期停留在“临时脚本”阶段：某次活动需要一份列表，工程师写一段爬虫；两周后页面改版，脚本失效；再过一个月，业务又要定时监控价格，于是再开一个仓库、再配一套定时任务。结果是脚本散落、环境难复现、字段定义不一致、通知靠人工转发表格。更棘手的是，运维与合规责任也跟着分散——谁负责代理、谁负责限速、谁保证只抓公开页、谁把数据落到可查询的表里，往往没有清晰答案。

一次性脚本并非没有价值，它适合探索和验证。但当需求变成“每周跑、字段稳定、结果可导出、变更可通知、下游系统可 API 拉取”时，脚本就会变成技术债。HuluFlow（葫芦流）正是为这条产品化路径而建：把抓取描述成可编辑、可调度、可计费的工作流，把结果沉淀为 Dataset，把权限与积分放在同一控制台里管理。

HuluFlow 是什么

HuluFlow 是面向公开网页的抓取 SaaS。站点默认英文路径在 /，中文在 /zh/。产品本体覆盖账号与计划、可视化工作流编辑器、Dataset、定时任务、邮件通知、REST API，以及 Chrome 扩展；底层抓取引擎由外部 crawld-web 提供，本应用负责编排、配额与交付。

你不需要自己部署无头浏览器集群，也不需要在业务仓库里维护选择器脚本。典型路径是：粘贴或生成 URL → 发现字段并预览样本 → 在画布上连接节点 → 保存后手动运行或按间隔调度 → 行数据进入 Dataset，必要时邮件提醒，再用 API Key 把数据接到内部系统。

文档入口在 产品文档，场景化说明见 用例。控制台从注册后的 /app 进入，工作流与 Dataset 是日常使用的两个中心。

工作流里的四个核心节点

一个 Workflow 是以 graph_json 存储的节点 DAG。编辑器基于 Drawflow，节点类型刻意收窄为四类，降低学习成本，也让计费边界清晰。

1. url_gen：生成待抓 URL

url_gen 没有上游输入。它用 range 模板（例如分页页码）或粘贴的 list 产出 URL 列表，默认有数量上限（例如 500），用来避免一次任务失控膨胀。价格监控、目录翻页、固定一批店铺页，都从这里起步。

2. scrape：抓取列表或详情

scrape 通过 crawld-web 拉取页面，支持 list（列表多行）与 detail（详情单页）模式。它可以吃上游的 URL，也可以对上游 items 中的 url/link 做扇出。成功产出的行会消耗积分；详情页通常按更高倍率计费。字段发现与预览帮助你先看样本再定稿，而不是先写死选择器。

3. store：写入 Dataset

store 把行数据 upsert 进逻辑表 Dataset，默认用 url、link 等键字段去重。Dataset 可在控制台浏览，也可导出 CSV/JSON，或通过 API 分页读取。这让抓取结果从“一次下载的文件”变成“可持续更新的表”。

4. notify：在新行或字段变化时发邮件

notify 可在 when=new（新行）或 when=field_change（监视字段变化）时发邮件。价格监控场景里，常见组合是列表抓取 → 详情抓取 → store → 价格字段变化通知。业务同学不必每天打开控制台对比表格。

一条常见流水线是：url_gen → list scrape → detail scrape → store → notify。节点配置与连线规则见文档 工作流指南。

积分、计划与调度

HuluFlow 用 URL/页面请求积分衡量消耗：一次成功的 scrape 请求消耗积分，计划按月（或年付）提供额度。公开档位大致从 Free 的少量月度积分，到 Starter / Pro / Business 更高额度。免费档适合验证工作流与扩展；正式监控与批量列表建议升级，以免任务中途因额度中断。

调度侧，工作流可设置 interval_minutes 与 next_run_at。进程内 worker（也可独立运行 python -m app.worker）会轮询到期任务并执行。云端调度适合“人不在浏览器前也要跑”的监控；Chrome 扩展则适合“我正在看这个页面，立刻分析并保存工作流”的交互路径——两者互补，而不是互相替代。

控制台还提供 API Key（Bearer hulu_…）。你可以用 REST 触发运行、查询 runs、读写 Dataset，把 HuluFlow 嵌进内部 ETL 或报表管道。细节见 API 参考 与 API 优先指南。

对比一次性脚本与自建爬虫平台

自写脚本的优势是完全可控：任意解析逻辑、任意存储、任意调度器。代价是你要自己维护浏览器/HTTP 客户端、失败重试、字段变更、密钥、告警与多人协作。自建内部爬虫平台则更重——队列、沙箱、权限、多租户计费几乎是另一条产品线。

HuluFlow 选择中间位置：抓取引擎外包给 crawld-web，产品层专注工作流图、Dataset、积分与 API。你换来的是更快上线与更低运维面；你交出的是“任意自定义解析代码”的自由度。若业务需要复杂登录态、验证码对抗或深度反爬，本产品明确不是替代方案——它面向你有权采集的公开页，以及可用字段发现与工作流表达的结构化需求。

对多数增长、运营、情报与数据团队而言，这个边界刚刚好：列表变表、价格变动提醒、目录分页入库、再用 API 同步到仓库，不必为每次需求开一个爬虫项目。

适合谁、不适合谁

适合：需要定期从公开网页拿结构化数据的运营与分析同学；希望少写选择器、多用预览与工作流的工程师；要把抓取结果当 Dataset/API 消费的内部工具团队；想在浏览页面时用扩展快速建流的个人与小团队。

不适合：需要大规模对抗反爬或绕过访问控制的场景；要求在本地完全离线跑浏览器农场的团队；以及任何违反目标站点条款或当地法律的采集意图。产品与商店说明都强调：只采集你有权访问的公开信息。

合规与责任边界

技术能力不等于合法授权。使用 HuluFlow 前，请确认目标页面可公开访问、你的用途符合站点条款与适用法律，并合理控制频率。Dataset 中可能包含业务敏感字段，请用好账号权限与 API Key 轮换。邮件通知会触及真实收件人，请避免把测试地址写成生产告警风暴。

我们在文档、定价页与扩展商店文案中反复强调合规，不是套话，而是产品默认立场：公开页、可复用工作流、可审计的积分消耗，而不是“万能破解工具”。

控制台与 AI 辅助建流

在 /app/workflows 打开编辑器后，你可以拖拽节点、连线、预览 scrape 样本，再保存 graph。配置了模型密钥时，工具栏 AI / 右侧 AI chat 可协助分析页面或校验图结构，并通过流式交互更新画布——最终仍需你确认并保存。AI 是加速器，不是绕过合规与字段验收的借口：样本行是否业务可用，始终由人签字。

对非工程同学，建议路径是：先用首页公开分析或扩展得到字段直觉，再在编辑器里补 store 与 notify；对工程同学，可以直接从 API 创建工作流，或用 node presets 复用常用 scrape 配置。无论入口如何，权威状态都是已保存的 Workflow 与 Dataset，而不是某次聊天记录。

下一步

若你想快速建立直觉：打开 首页 的公开分析演示，粘贴一个公开列表页；或阅读 入门 与 API 速通。下一篇文章会专门讲 Chrome 扩展如何把“当前正在看的页面”变成可保存、可复跑的工作流；再下一篇则把价格监控、Dataset 与 API 串成一条落地路径。

HuluFlow 的目标很具体：让团队停止为每个抓取需求重写脚本，转而维护一条清晰的工作流资产——可调度、可计费、可导出、可通知。若这正是你卡住的地方，从免费档跑通第一条流水线，往往比再开一个爬虫仓库更省时间。把“抓取”从项目制改成资产制，是本产品最想帮你完成的那一次组织习惯升级。