Chrome 扩展：从当前页面到可复用工作流

为什么抓取工作流需要一个 Chrome 扩展

控制台适合设计完整 DAG、配置调度与查看 Dataset。但真实工作流往往从“我正在浏览的这一页”开始：你打开一个公开目录、一篇列表、一个商品页，想立刻知道能抽出哪些字段、样本长什么样、能不能保存成以后可复跑的流程。若每次都要把 URL 拷回控制台、反复预览，上下文会断裂。

HuluFlow Chrome 扩展把分析与建流拉到侧边栏：在当前标签页上下文中发现字段、调整需求描述、保存工作流，并在需要时用后台标签执行。它不是第二套产品，而是同一账号、同一工作流与积分体系的前端入口。详细逐步说明见文档 扩展指南。

安装、登录与权限直觉

从 Chrome Web Store 安装 HuluFlow 扩展（站点与文档提供商店徽章与链接）。安装后打开侧边栏，使用与控制台相同的账号登录。扩展需要在你主动使用时访问当前页内容以便分析；它面向公开页场景，请勿用于你无权访问的内容。

登录成功后，扩展可以调用后端的扩展相关 API（例如分析、保存工作流、触发运行）。积分与计划仍以控制台账号为准：扩展里跑成功的抓取同样消耗额度。若 Free 档额度不足，应先在定价页了解升级路径，而不是反复重试失败任务。

建议第一次使用时选一个稳定的公开演示站（文档与首页常用的 books.toscrape.com、quotes.toscrape.com 一类），先跑通“分析 → 保存 → 运行”闭环，再换真实业务站点。这样可以把产品问题与目标站反爬、登录墙问题分开排查。

三步构建器：从当前页到可保存工作流

扩展侧边栏的核心体验可以概括为三步，和文档中的 beginner walkthrough 一致。

第一步：分析当前页

在目标公开页上打开侧边栏，确认 URL，填写简短需求（例如“标题, 价格, 链接”）。发起分析后，后端会结合页面内容给出建议字段与样本行，并可能提示更适合 list 还是 detail 模式。你应当把样本当成合同草案：字段名是否业务能懂、链接是否完整、价格是否含货币符号——这些决定后续 store 与 notify 是否好用。

第二步：调整字段与模式

根据样本增删字段、改名、确认列表/详情模式。列表页通常先抽多行卡片；详情页则关注单页属性。若你的真实目标是“列表进详情”，扩展生成的流可能需要你回到控制台补上第二段 detail scrape 与 store/notify——扩展擅长从当前上下文起步，复杂 DAG 仍以画布为准。

第三步：保存工作流

保存后，工作流出现在控制台的 Workflows 列表中，成为可编辑资产。你可以在画布上继续接线、加 url_gen 做分页、加 notify，或设置 interval。扩展解决的是“冷启动与页面上下文”，不是取代编辑器。

运行：后台标签与结果去向

扩展触发的运行会走与账号绑定的执行路径，常见体验是在后台标签中完成抓取相关步骤，避免打断你正在阅读的前台页。运行状态、错误与产出应回到控制台的 runs / Dataset 视图核对——以控制台为权威数据面，扩展为触发与建流面。

若运行失败，优先检查：页面是否仍公开可访问、字段是否因改版失效、积分是否耗尽、以及是否误把需要登录的内容当成公开页。改版是抓取世界的常态；工作流资产的价值在于你能快速改字段并重跑，而不是“一次写死永远可用”。

扩展运行与云端调度如何分工

扩展路径适合：探索新站点、在真实 DOM 上下文中确认字段、临时补跑、演示给同事看“这一页能抽出什么”。人在浏览器前时，反馈最快。

云端调度路径适合：价格监控、日报线索表、夜间翻页入库——人不在电脑前也要按 interval_minutes 执行。worker 轮询到期工作流，结果进 Dataset，notify 发邮件。这是产品化监控的主路径。

推荐组合：扩展建流并人工跑通一次 → 控制台补全 store/notify/分页 → 打开调度。不要指望只靠扩展完成所有运维；也不要强迫自己在控制台里从空白 URL 冷启动每一个想法。

实操建议

• 需求描述写“业务字段语言”，少写实现细节；让分析更接近你真正要入库的列。
• 先小样本验证，再提高 url_gen 范围或列表长度，避免一次耗光积分。
• 关键键字段（url/link）尽早固定，否则 store 去重与 field_change 通知会不稳定。
• 改版后先在扩展里对同一 URL 重分析，再决定是改字段还是改模式。
• 把扩展当“相机”，把控制台当“暗房与档案室”：拍摄在现场，冲印与归档在后台。

另外，团队协作时建议约定命名规范：工作流名称写清站点与用途（例如“竞品A-列表价监控”），Dataset 名称与之对应，避免半年后出现一堆“未命名工作流”。扩展保存只是起点；资产能被同事读懂，才算进入可交接状态。若你在侧边栏里反复对同一 URL 分析出完全不同的字段集，停下来检查需求描述是否在变，或页面是否对你做了个性化/实验分流——这类问题用脚本同样会踩到，扩展至少让你更快看见差异。

扩展做不到什么（有意为之）

扩展不会替你绕过登录墙，不会在本地常驻一个隐形爬虫农场，也不会取代 Dataset 权限模型。它也不会自动把每一次分析都变成已调度的生产任务——调度开关在控制台，是人为的产品决策。把这些边界写清楚，是为了避免错误预期：扩展提高的是“从页面到工作流”的速度，不是“从任意网站到任意数据”的魔法。

若你的团队已经有成熟的内部爬虫平台，扩展仍可能有价值：作为业务同学自助探索字段的入口，探索完成后再由平台团队决定是否迁到内部系统。HuluFlow 可以是生产路径，也可以是需求澄清工具；两种用法都合法，只要合规前提成立。

常见问题

扩展和工作流编辑器里的 AI 是一回事吗？ 都服务于“更快理解页面与生成可用图”，但入口不同。扩展贴近当前标签；控制台 AI chat（在配置了模型密钥时）可在画布侧分析与改图。最终都以你点击保存后的 graph 为准。

必须用扩展吗？ 不必。纯控制台与 API 也能完成建流与运行。扩展是加速器，尤其适合非工程用户。

可以抓登录后页面吗？ 产品定位是公开页。若页面需要登录或突破访问控制，不属于支持范围，也请不要尝试用扩展绕过。

扩展运行失败但控制台手动 run 成功？ 先对齐是否同一工作流版本、同一积分池，再看扩展侧网络与登录态。仍失败时，以控制台 runs 日志为准排查字段与上游节点。

下一步

安装扩展后，选一个公开列表页走完三步构建器，再到 控制台 打开刚保存的工作流，补上 store，导出一次 CSV。若你的目标是监控，请继续阅读下一篇：如何把定时价格监控、字段变更邮件与 Dataset/API 串起来。文档侧可并行阅读 扩展指南 与 工作流指南。

扩展的价值，是把“我看见的页面”变成“团队可复用的工作流资产”。当你不再用聊天窗口传 HTML 截图，而是共享一条可运行的 Workflow（在控制台内），抓取协作才真正开始像产品，而不是像临时救火。把第一次成功的扩展建流当作团队模板：复制、改 URL、改字段，往往比从零再教一遍更快。