最近在做一个自动化商品采集分析的小项目要把散落在几个公开站点上的商品信息定时收拢起来清洗后交给大模型做价格带判断、卖点提炼和竞争力分析。一开始我打算沿用老写法Python 脚本加定时任务跑完写 Excel。结果越写越难受页面一改版选择器要跟着调加一个分析维度又得改代码任务挂在服务器上出了问题还得翻日志。后来我把整套流程搬进了 Dify 工作流用可视化节点把采集、清洗、分析和通知串起来整个项目从“脚本合集”变成了“一条流水线”。这篇文章就围绕这套商品采集分析工作流展开适合两类人看一类是想把爬虫加分析流程可视化、不想再维护一堆脚本的另一类是已经在用 Dify但不清楚怎么把 HTTP 请求、代码处理和 LLM 分析完整串成一个生产级工作流的。节点怎么选、数据怎么传、上下文超长怎么处理、那些常见报错怎么排查我都会从头讲一遍。1. 为什么要把商品采集分析搬进 Dify先说结论不是所有采集分析项目都必须上 Dify但如果你既要采集公开网页数据又要用大模型做结构化分析还希望这套流程能被团队里不擅长写代码的人维护那 Dify 工作流会比传统脚本舒服得多。1.1 我原本的采集脚本哪里不够用以前写采集脚本痛点是分散的。requests 或 BeautifulSoup 写起来很快但页面结构一变选择器就要跟着改。做过电商类采集的人都懂商品标题、价格、销量这些字段在不同站点里的 DOM 结构几乎没有一样的今天它能跑通明天换个站点或者对方改版脚本立刻报警。更麻烦的是分析环节。采集完了还要接 LLM API把商品数据拼进提示词里再解析模型返回的 JSON这段代码本身不难但一旦要调整分析维度比如从“只看价格区间”改成“还要看评论情感倾向”就得改代码、重新部署、再跑一轮。时间全耗在维护上了。Dify 把我从这套循环里解放出来页面结构变化只改一个代码节点分析逻辑变化只改提示词不用动整条链路的代码。1.2 为什么是 Dify 而不是 Coze 或其他工作流工具有人会问这类可视化工作流工具不少扣子、影刀、n8n 都能做类似的事为什么选 Dify我的考虑很简单商品数据属于选品信息很多团队不太愿意把这类数据和中间分析结果放到公网平台。Dify 社区版可以本地部署数据保存在自己的服务器模型供应商也可以自由切换同一个工作流今天接 DeepSeek明天换通义改一下模型配置就行。Coze 生态确实完善做点轻量级自动化很省心但数据私有化这一条就让它在我这个场景里出局了。Dify 的节点类型也够用HTTP 请求节点负责拉网页代码节点负责清洗提取变量聚合器负责把多条商品数据合并LLM 节点负责分析条件分支负责异常分流一条链路基本覆盖了采集分析场景的全部环节。1.3 这套工作流最终解决的三类问题第一是定时采集自动化。工作流可以通过 API 或外部调度定时触发输入一批商品 URL自动跑完整个流程不需要一直有人盯着。第二是维护成本降低。采集规则收拢在代码节点里分析逻辑收拢在提示词里改一个节点不影响其他环节。第三是结果可观测性。Dify 每次运行都会留下日志哪个节点失败、哪个节点输出异常在界面上可以直接看到比在服务器里翻日志文件要直观得多。这三件事单独拿出来都不算颠覆性但合在一起就让“商品采集分析”这件事从一次性开发变成了可持续运营的流程。2. 工作流骨架先画数据流再拖节点我在搭建之前先画了一张数据流草图而不是直接打开 Dify 拖节点。这张草图决定了整条工作流的结构URL 列表进来经过抓取、清洗、聚合、分析、输出最后通过通知或落库收尾。先想清楚数据从哪来到哪去后面每个节点选型会顺畅很多。2.1 输入设计URL 列表怎么进来商品采集分析的输入通常是目标商品页面的 URL。在 Dify 工作流里最简单的方式是用“开始”节点接收一个数组变量。比如外部系统调用工作流 API 时传一个 JSON 数组每个元素包含 URL 和来源站点名。如果是手动调试也可以直接把 URL 粘贴进来用逗号或换行分隔再通过代码节点转换成数组。这里有一个经验尽量保持输入规范化。我一般要求每条数据至少包含两个字段一个是网址一个是站点标识因为后续分析环节可能需要区分不同站点的价格单位和促销规则。2.2 主链路节点排布我最终跑通的链路是开始节点接收 URL 列表接 HTTP 请求节点逐个抓取页面源码抓到的 HTML 交给代码节点做字段提取提取出来的商品结构化数据送进变量聚合器合并然后喂给 LLM 节点做横向分析最后通过结束节点输出 JSON 结果。中间还挂了一个条件分支判断 HTTP 请求是否成功失败时走错误记录分支不阻塞整批数据处理。用表格看我当时的节点排布会更清楚节点类型作用关键输出开始节点接收 URL 数组和来源标识数组变量HTTP 请求节点抓取商品页面 HTML页面响应体代码节点正则或 HTML 解析提取字段商品结构化 JSON变量聚合器合并多条商品数据商品 JSON 数组条件分支节点判断请求成功与否成功/失败路径LLM 节点批量分析价格带、卖点、风险分析结论 JSON结束节点输出最终结构化结果最终 JSON2.3 失败分支怎么处理商品采集最容易出问题的地方是网络请求。目标站点偶尔超时、返回 503或者页面结构异常这都是常态。我在 HTTP 请求节点后面加了一个条件分支成功时继续往下走失败时进入另一个代码节点记录 URL 和错误码合成一个错误报告。这样整批 URL 里即使有几十个失败也不会让工作流中断最后输出的 JSON 里会同时包含成功商品列表和失败列表交给下游或者人工处理都方便。这个设计看似简单但实际使用中价值极大因为生产环境里的采集任务不可能指望每次都 100% 成功。3. 采集环节的实操细节和常见坑采集环节是整个工作流里最容易翻车的地方。Dify 的 HTTP 请求节点本质上就是帮你发了一个 HTTP 请求但网页结构复杂真正干净的字段提取还得靠代码节点。3.1 HTTP 请求节点返回原始 HTML 怎么处理HTTP 请求节点发出请求之后页面源码会保存在输出字段里通常可以通过类似{{节点ID.output.body}}的引用方式拿到。需要注意编码问题。很多中文网页是 UTF-8但也有部分站点使用 GBK 或 GB2312Dify 的 HTTP 节点对响应体编码的处理不一定总能识别对。我遇到乱码时的应对方式是在请求头里显式带上Accept: text/html;charsetUTF-8同时在代码节点里做一次编码判断把常见乱码字符替换掉。这一步看起来不起眼却能避免后续所有字段解析出来都是一堆问号。3.2 代码节点里做解析内置库的边界真正写提取逻辑时我发现 Dify 的代码节点运行在沙箱环境里能用的 Python 内置库比较全但第三方库不一定都装好了。所以我在写解析逻辑时尽量只用标准库尤其是正则和html.parser。比如提取商品价格可以先用正则定位包含price的 JSON 片段再用json.loads解析出数值。提取标题时优先找meta propertyog:title content...或者script typeapplication/ldjson里的结构化数据这类数据比肉眼盯着的 HTML 标签稳定得多。下面是一个简化版的提取思路只保留核心逻辑import re import json html body # HTTP 节点传入的页面源码 # 优先解析 JSON-LD 结构化数据 m re.search(rscript[^]*typeapplication/ldjson[^]*(.*?)/script, html, re.S) if m: data json.loads(m.group(1)) title data.get(name) or data.get(headline) price data.get(offers, {}).get(price) # 拿不到就退化为正则匹配 if not price: price_match re.search(rprice\s*:\s*?(\d(?:\.\d{1,2})?)?, html) price price_match.group(1) if price_match else None这个例子想说明的是能用结构化数据提取就别硬刚 HTML代码节点里能用标准库完成的工作就不要依赖第三方库。保存完代码节点调试时先在“运行”面板里用真实页面源码测一遍确认三个字段都能取到再往下走。3.3 页面结构变化时如何降低维护成本商品站点的页面结构几乎一定会变。我的习惯是每次都把“页面解析”和“字段规整”拆成两个步骤。页面解析代码节点只做一件事把 HTML 转成原始字段字典。字段规整另用一个代码节点完成比如把“价格¥199.00”清洗成 199.0把“已售 2.3万”转换成 23000。这样当页面改版时我只需要修改第一个节点里的选择器第二个节点完全不动。另外采集频率一定要控制住建议同一站点两次请求之间至少间隔几秒可以在 HTTP 节点前加一个延时节点或者在外部调度时把批量大小控制好。只采集公开、可正常访问的页面不碰登录后内容不绕过任何访问控制这是我一直守的底线。4. 分析环节让 LLM 输出可用的结构化 JSON采集清洗完成之后数据已经到了比较规整的程度接下来的核心就是让大模型做横向分析。这一步的关键不是模型能力强不强而是提示词设计能不能让模型稳定输出结构化 JSON。模型输出不稳定后续解析和落库就会很难受。4.1 提示词设计先给规则再给数据我采用的提示词结构分三层角色指令、输出规则、待分析数据。角色指令告诉模型它是选品分析助手输出规则明确要求只输出 JSON不解释、不客套字段命名给出枚举定义待分析数据用 JSON 数组形式直接拼接。下面是一个实际可用的模板你是选品分析助手。用户会给你一个商品 JSON 数组请对每个商品输出分析结论。 必须返回 JSON 数组每个元素字段如下 url: 原始商品链接 title: 商品标题 price_range: 价格带判断取值 low/mid/high advantage: 这个商品的核心卖点不超过30个字 risk: 潜在风险如价格竞争、口碑争议等不超过30个字 suggested_price: 建议定价数字即可 只返回 JSON不要添加任何解释。 数据 {{商品数组变量}}注意不要把这些指令放进用户输入里而是放到 LLM 节点的系统提示词部分。模型对系统提示词的遵循度明显高于用户输入里的临时规则。用这个结构之后实测输出的 JSON 基本可以直接被结束节点使用。4.2 JSON 模式与输出校验Dify 的 LLM 节点支持设置响应格式为 JSON部分模型配合这个模式稳定度会提高不少。但我的经验是即便开了 JSON 模式也不能完全信任模型输出。最好在 LLM 节点之后再加一个代码节点做二次校验尝试json.loads()解析解析失败就重新调用一次或者把失败结果标记为“分析失败”放回结果列表。这个兜底设计在批量运行时特别重要因为某个商品数据异常时模型有概率返回一段解释性文字而不是 JSON如果不去校验整个工作流在最后一步报错前面的活全白干。4.3 批量商品对比分析比单条分析更有价值商品采集分析的最终目的是指导选品或运营决策所以横向对比往往比单条分析更实用。比如同时输入 30 条同类商品数据让模型总结价格带分布、哪些商品具有差异化卖点、哪些价格有明显虚高这种结论对业务决策的帮助远超“这个商品值多少钱”的单点判断。数据合并这一步就是变量聚合器发挥作用的地方把多个 URL 的商品结构化数据聚合成数组直接作为 LLM 节点的输入。后面我会专门说变量聚合器的用法。5. 上下文控制与变量聚合器从入门到不报错工作流跑起来之后最常遇到的性能问题就是 LLM 节点报上下文超长。搜索“dify 工作流 上下文超长”的人不在少数这个坑其实是可以从设计上规避的。5.1 上下文超长的成因一个很典型的过程是HTTP 节点抓回来的页面源码有几万字符如果直接把它送进 LLM 节点再叠加提示词和商品数据很容易超出模型的上下文窗口。原始 HTML 对分析来说全是噪音真正有用的只有标题、价格、描述等几个字段。所以我在清洗环节就严格控制了传给 LLM 的数据体积只保留必要的业务字段。这里的原则是能用代码节点处理的活绝不让 LLM 干能只传字段的绝不多传一整个页面。5.2 变量聚合器的完整使用步骤变量聚合器是 Dify 工作流里处理数组合并的核心节点。它的使用步骤看起来简单但有几个细节容易踩坑。我先讲步骤再讲注意事项。在 HTTP 请求节点和代码节点跑通之后确认每个商品节点输出的是对象或数组结构而不是一长段字符串。添加一个“变量聚合器”节点放在多个商品处理路径的汇合点。在聚合器配置里变量类型选择 Array。这是最关键的一步很多人在这里选成了 String结果下游拿到的是一段拼接文本而不是可遍历的数组。点击添加变量引用上游代码节点输出的商品对象或数组。设置聚合器输出变量类型为 Array命名一个变量名比如product_list。下游 LLM 节点直接引用{{变量聚合器节点ID.output.product_list}}。我最初用这个节点时就吃过亏当时想把多个 URL 的结果合并结果选了 String 类型下游代码节点拿到一个带方括号的字符串反复调试才发现是类型选错。变量聚合器解决的是“多个分支结果汇合”的问题不是文本拼接器。5.3 三种降低上下文占用的手法就算做好了字段清洗商品数量一大LLM 节点还是可能超长。我有三种处理手法。第一种是字段白名单代码节点里只输出url、title、price、sales这几个字段模型分析不需要的评论原文、页面元数据全部丢弃。第二种是分批分析把 100 条商品按每批 20 条拆成多个批次每批次单独跑一次 LLM 节点最后再用一个代码节点合并各批次分析结果。第三种是截断重文本字段商品描述只保留前 200 个字符既保留关键信息又控制 token 消耗。这三种手法不要等到报错再想搭建初期就应设计进工作流里。6. 我踩过的几个报错与排查链路再稳定的配置也难免遇到报错。这里挑三个我真实遇到、检索频率也很高的问题把排查思路完整写出来。6.1 SSL 证书校验失败现象是调用模型供应商接口或者 HTTP 节点请求某些 HTTPS 站点时报SSL certificate verify failed之类错误。这个问题在本地部署 Dify 的环境里尤其常见。我的排查链路是先看完整报错日志确认是证书链问题还是证书过期问题再检查容器系统时间系统时间偏差过大时证书校验必挂然后检查服务器出口网络环境变量有些环境下 HTTPS 流量被网关替换了证书导致客户端不信任最后可以用curl -v单独请求该地址对比是系统层面问题还是 Dify 配置问题。生产环境必须从证书链路根上解决不要在业务里关闭 SSL 校验。6.2 unstructured API URL 未配置这个报错常出现在知识库上传 PDF 或 Word 文档时提示unstructured api url is not configured for doc file processing.。Unstructured 是 Dify 用来做文档解析的组件社区版通过 docker compose 部署时如果环境变量里没有正确配置UNSTRUCTURED_API_URL文档处理环节就会报这个错。排查时先确认部署方式再查环境变量里是否配置了该地址配置后重启相关容器。如果你的场景主要是网页内容和纯文本不想额外部署这个服务也可以绕过文件解析把内容转换成纯文本或 Markdown 再进知识库就没有这个问题。6.3 模型凭据校验期间出错模型供应商配置界面里点保存报an error occurred during credentials validation也是很常见的坑。这类问题大多不是 Dify 本身的 bug而是模型供应商 API Key 无效、网络不通或者接口地址填错。我的排查顺序是先在模型供应商官网后台验证 Key 是否有效再用代码节点或 curl 直接调一下模型厂商的接口确认返回正常最后回到 Dify 检查 Base URL 是否填成了官方地址之外的自定义地址。高版本 Dify 对模型接入的校验更严格经常是某位同事把 Key 粘贴多了空格校验就过不去。7. 落地之后可以做哪些扩展工作流主体跑通以后我陆续给它加了几个扩展能力实测都很好用在这里一并列出。7.1 定时触发与外部调度Dify 本身支持通过 API 触发工作流。我可以让外部系统每天定时调用工作流 API传入当天需要分析的 URL 列表跑完后把结果回调到自己的后端服务。这样画面就变成了早上一批商品 URL 进来中午分析结论已经出现在数据后台。这个流程完全不需要人干预出错时 Dify 日志会清楚记录哪一步异常。7.2 数据落库与二次加工工作流的结束节点不一定只能输出文本。我通常把 LLM 分析结果送进一个代码节点转成干净的 JSON再通过 HTTP 请求节点 POST 到自己的数据接口完成落库。这种设计把 Dify 当作整个流程的编排中枢而不是终点后续要做报表、做推荐数据都在自己的数据库里非常灵活。7.3 最后一点个人体会这套工作流真正用起来之后我最大的感受是Dify 的价值不在于让你完全不写代码而在于把散落各处的处理逻辑变成一个个可以单独观察、单独调整的节点。采集逻辑出问题只看采集节点分析输出不满意只改提示词上下文超长只调清洗和分批方案。所有环节都被可视化之后排查问题的效率完全不是脚本时代能比的。如果你也想做类似的事情我建议从一条商品 URL 开始先手动跑通再逐步加批量、加分支、加定时不要一上来就追求大而全的流程。自动化是叠加出来的先把最小闭环走稳后面每一步扩展都只是锦上添花。