Dify 高级实验06自动化报告——如何让系统定时自动生成周报Dify 实验系列 · 高级 06/10 | 实验编号DIFY-103-06基于 Dify 1.16.1 实测2026-081. 业务场景先讲一个我们实际遇到的场景。一家电商公司的运营部每周一早上 9 点都要开周会会前必须有一份上周运营周报——营收、订单、客服满意度、活跃用户还要算环比、标异常。这份周报一直由数据分析师手动做从三个后台系统分别导出数据粘到 Excel 里算环比再复制进 Word 模板最后手动发到群里。一套流程下来大半天而且经常漏算某个指标或者把上周的数据标成本周。运营总监最常说的一句话是「周报能不能周一早上我睁眼就能看到」我们第一次接这个需求时第一反应也是「写个 Python 脚本定时跑不就行了」。后来把流程拆开一看才发现——取数、算数、送数每一段都有自己的坑三个系统数据格式不一、环比计算会除零、推送要对接各渠道。脚本越写越像一锅粥而 Dify 工作流把这些环节都做成了可视化节点改一处、重跑一次全流程跟着变。这不是个例。任何「定期要出报表」的场景都是这个模式运营周报、财务日报、销售月度复盘、SRE 巡检报告——数据来源多、格式固定、周期重复人工做既慢又容易错还挤占了分析师真正该做的专题分析。2. 场景痛点这个流程的痛点在数据分析师身上体现得最直接采集耗时三个系统分别导出数据格式还不一样光对齐口径就要一小时——数据在系统里躺着取出来却要手动搬。算环比易错环比公式手写在 Excel 里分母为 0 时直接报错或者算出来的数没人核对——周报里的数字错了周会上的决策就跟着错。异常靠人盯营收环比下降 15% 这种信号要人一眼扫出来才写进报告——漏看一次管理层就晚一周才知道业务出问题了。推送靠手动报告生成后还要手动复制到群、邮件、文档——忘了发、发错版本都是常有的事定时推送的需求天然存在。本质上周报的痛点不在「写报告」而在「取数、算数、送数」这三段机械环节——数据、计算、推送都是确定性的唯独靠人每天重复这是自动化收益最直接的场景。3. 方案为什么是这套自动化报告流水线Dify 工作流里的「并行数据采集 → 变量聚合 → 指标计算与异常检测 → LLM 分析结论 → 模板转换生成报告 → Webhook 推送」链路把周报全流程搬上自动化。选它的理由我们实际对比过并行采集 变量聚合省时间销售/客服/用户三路数据互不依赖、同时拉取多分支输出用变量聚合器确定性合并替代手写代码拼接——节点编排就把采集并行化不用自己写并发指标计算代码化异常不漏看环比、满意度、活跃用户的计算和异常检测全部代码化除零有保护、异常有标记——计算稳定可复现异常自动进报告模板转换 可开关推送同一个模板按output_format输出 Markdown 或 JSONpush_enabled开关控制是否推送企业微信/飞书机器人——格式和渠道都配置化。这篇文章我们就用它搭一个「运营周报自动生成器」三路数据并行采集自动算环比、检异常、生成报告一键推送到群。4. 整体架构开始report_week / output_format / push_enabled销售数据采集Code客服数据采集Code用户数据采集Code变量聚合合并三路 JSONCode 指标计算与异常检测环比/满意度/活跃用户 anomaliesLLM 分析结论300 字以内直接输出正文模板转换Markdown/JSON 双格式报告Code Webhook 推送模拟 HTTP 200结束链路很清晰三路并行采集 → 聚合 → 计算检测 → LLM 分析 → 模板出报告 → 推送。变量聚合和模板转换是这个架构的关键——聚合把三路数据确定性合并模板把同一份数据渲染成多种交付格式。5. 模块设计5.1 三路采集cd_sales / cd_customer / cd_support每个采集节点同时输出两份object结构数据sales给下游代码节点与模板消费json字符串sales_json给变量聚合器合并defmain():return{sales:{current:{total_revenue:1285000,total_orders:342,avg_order:3757},previous:{total_revenue:1150000,total_orders:310,avg_order:3709},daily:[{date:周一,revenue:185000,orders:48}]},sales_json:{current: {...}, previous: {...}}# json.dumps 序列化}5.2 变量聚合va_mergevariables是[[节点id, 字段], ...]嵌套数组格式output_type: string-data:output_type:stringtitle:变量聚合合并数据type:variable-aggregatorvariables:-[cd_sales,sales_json]-[cd_customer,customer_json]-[cd_support,support_json]5.3 指标计算与异常检测cd_analyze环比计算必须除零保护has_anomaly展平为字符串boolean 在变量选择器不可见defmain(sales,customer,support):issues[]salessalesor{};customercustomeror{};supportsupportor{}cursales.get(current)or{};prevsales.get(previous)or{}prev_revprev.get(total_revenue)or0rev_change(cur.get(total_revenue,0)-prev_rev)/prev_rev*100ifprev_revelse0ifrev_change-10:issues.append(f营收环比下降{abs(rev_change):.1f}%需关注)# 客服满意度 4.0、活跃用户环比 -5% 同理检测……return{revenue_change_pct:round(rev_change,1),anomalies:issues,has_anomaly:trueifissueselsefalse,summary:...,analysis:{...}}5.4 分析结论 LLMlm_analysis你是一个运营数据分析师。根据以下本周{{#start.report_week#}}运营数据生成中文分析结论。 核心指标摘要{{#cd_analyze.summary#}} 环比变化营收 {{#cd_analyze.revenue_change_pct#}}%客服工单 {{#cd_analyze.ticket_change_pct#}}%活跃用户 {{#cd_analyze.user_change_pct#}}% 异常项列表{{#cd_analyze.anomalies#}} 要求 1. 分析营收、订单、客服、用户四个维度的环比变化趋势 2. 指出异常项如有 3. 给出 2-3 条可执行的行动建议 4. 控制在 300 字以内 5. 直接输出正文不要输出任何解释性文字5.5 模板转换tmpl_report模板开头一组{% set %}做空值保护计算处全部if prev else 0除零保护所有输入走variables映射模板内用{{ var }}引用{% set s sales if sales else {} %} {% set cur s.current if s.current else {} %} {% set prev s.previous if s.previous else {} %} {% set issues analysis.anomalies if analysis and analysis.anomalies else [] %} {% set rev_pct analysis.revenue_change_pct if analysis and analysis.revenue_change_pct is defined else 0 %} {% if output_format json %} { report_week: {{ report_week }}, revenue: {{ cur.total_revenue | default(0) }}, anomalies: [{% for issue in issues %}{{ issue }}{% if not loop.last %}, {% endif %}{% endfor %}] } {% else %} # 运营周报{{ report_week }} ## 核心指标 - 营收¥{{ cur.total_revenue | default(0) }}环比 {{ rev_pct }}% - 订单{{ cur.total_orders | default(0) }} 单 ## 趋势分析 {{ llm_analysis }} ## 异常预警 {% if issues | length 0 %}{% for issue in issues %}- ⚠️ {{ issue }}{% endfor %} {% else %}- 无异常各项指标正常 ✅{% endif %} {% endif %}5.6 推送cd_pushpush_enabled为 true 时模拟调用企业微信机器人真实场景换http-request节点URL 指向机器人 Webhook。6. 运行验证输入期望行为实测report_week上周output_formatmarkdownpush_enabled关输出完整 Markdown 周报核心指标/趋势分析/异常预警三节与预期一致output_formatjson输出 JSON 结构报告report_week/revenue/anomalies/analysis 字段与预期一致push_enabled开push_status 已推送到企业微信机器人模拟 Webhook 调用成功HTTP 200与预期一致三路数据置空冒烟测试模板空值保护生效输出空报告而不是运行报错与预期一致{% set %}兜底7. 实战坑坑现象修复模板变量为 null/空时直接计算{{ x | length }}、x | map(...) | sum / (x | length)运行报错0/0 除零、None 切片冒烟输入空数据直接崩溃模板开头{% set %}兜底默认值 计算处(sum / length) if (length) 0 else 0dify102 全量验证实测长报告text返回空字符串DeepSeek 把内容写进思考部分或思考与输出共享 max_tokens 预算被挤空报告类节点max_tokens提到 4000-8000 prompt 明确「直接输出正文不要输出任何解释性文字」dify103_09 lm_format 实测has_anomaly用 boolean 类型输出下游 LLM 模板{{#cd_analyze.has_anomaly#}}取不到值boolean 变量选择器不可见代码输出true if x else false字符串模板语义不变2026-07-31 dify-103 实测模板里直接写{{#node.field#}}引用 code 的 object 字段validate_dsl.py 模板正则扫描报错或跨节点引用不可见字段所有输入走variables映射value_selector模板内用{{ var }}引用dify102-2 21 实证8. 实验文档及源码获取实验文档完整操作步骤DIFY-103-06自动化报告生成.md源码可直接导入dify103_06_自动化报告生成.yml文章聚焦核心配置与采坑点实验的完整分步操作节点搭建/参数表/调试指引见实验文档原文。下一篇Dify 高级实验07智能审批——如何让机器自动完成流程审批 你在这个实验的场景里踩过什么坑欢迎评论区分享你的实战经验。