将斗鱼日报Dify工作流改为按任务类型分支

1. 在斗鱼日报 Dify 工作流中新增 if-else 节点，按 daily_report、danmu_summary、fans_daily_report 做真实业务分支。\n2. 为运营日报、弹幕总结、粉丝日报分别拆分主 LLM 与回退 LLM，减少不同文风互相污染。\n3. 更新斗鱼 Dify 接入文档，改为分支版工作流说明，明确当前推荐结构与验证方式。

docs/dify_douyu_daily_report_workflow.md

@@ -1,130 +1,148 @@
-# Dify 工作流设计：斗鱼日报最新接入说明
+# Dify 工作流设计：斗鱼日报分支版接入说明
 
 ## 1. 目标
-- 让 `plugins/douyu` 统一通过 Dify Workflow 处理三类斗鱼日报任务。
-- 保持“一个 scene + 一个 workflow” 的接法，减少插件侧和 Dify 侧的维护成本。
-- 让运营版日报、弹幕总结、粉丝向乐子日报共用一套工作流入口，但通过 `task_type` 做风格路由。
+- 让 `plugins/douyu` 继续通过一个 Dify Workflow 接收斗鱼日报任务。
+- 但在 Workflow 内部按 `task_type` 做真正的 LLM 分支，而不是让一个通用 LLM 节点同时处理三种风格。
+- 降低运营日报、弹幕总结、粉丝乐子日报之间的风格串台和幻觉风险。
 
-## 2. 当前仓库里的真实接法
-当前项目不是“多个 workflow 按业务拆开”，而是：
+## 2. 当前推荐结构
+当前推荐的是：
 
 1. 插件侧固定走场景 `douyu.daily_report`
-2. 场景路由到 `llm.backends.dify_workflow_douyu_daily_report`
-3. Dify 端使用一个 Workflow 应用统一接收不同 `task_type`
+2. 该场景路由到 `dify_workflow_douyu_daily_report`
+3. Dify Workflow 中先读取 `task_type`
+4. 通过 `if-else` 节点按业务分支
+5. 每个分支走自己的主 LLM
+6. 每个主 LLM 再各自挂一个失败回退 LLM
 
-对应文件：
-- 场景路由配置见 [config.yaml](d:/learn/abot/config.yaml:130)
-- 斗鱼插件配置见 [plugins/douyu/config.toml](d:/learn/abot/plugins/douyu/config.toml:34)
-- 最新工作流导出见 [plugins/douyu/斗鱼日报AI.yml](d:/learn/abot/plugins/douyu/斗鱼日报AI.yml:1)
+这样做的原因：
+- 每个分支 prompt 更短、更纯
+- 每个模型只处理单一输出目标
+- 更不容易把粉丝日报写成运营复盘
+- 更不容易把弹幕总结写成长日报
 
 ## 3. 项目侧输入约定
-斗鱼插件会向 Dify Workflow 发送以下输入：
+斗鱼插件传入的核心字段如下：
 
 - `task_type`
-  当前支持三个值：
   - `daily_report`：运营版完整日报正文
   - `danmu_summary`：运营版图片上半部分弹幕总结
   - `fans_daily_report`：粉丝向欢乐恶搞日报
 - `query`
-  兼容 Dify workflow 的通用输入字段，值通常等于 `user_prompt`
 - `system_prompt`
-  插件侧拼好的系统提示词
 - `user_prompt`
-  插件侧拼好的用户提示词
 - `report_payload_json`
-  结构化日报材料 JSON 字符串
 - `room_id`
-  房间号
 - `anchor_day`
-  报告日期，例如 `2026-04-27`
 - `nickname`
-  主播昵称
 - `max_length`
-  最大输出长度，项目侧当前默认传字符串
 
-说明：
-- 斗鱼插件目前默认 `include_structured_inputs = false`，见 [plugins/douyu/config.toml](d:/learn/abot/plugins/douyu/config.toml:37)
-- 所以最稳的做法是至少在工作流中保留 `report_payload_json` 这个字符串输入
+对应代码见：
+- 输入封装 [plugins/douyu/main.py](d:/learn/abot/plugins/douyu/main.py:2144)
+- 运营日报调用 [plugins/douyu/main.py](d:/learn/abot/plugins/douyu/main.py:2386)
+- 弹幕总结调用 [plugins/douyu/main.py](d:/learn/abot/plugins/douyu/main.py:2231)
+- 粉丝日报调用 [plugins/douyu/main.py](d:/learn/abot/plugins/douyu/main.py:2254)
 
-## 4. 最新工作流结构
-当前最新导出的 Workflow 结构更接近“提示词路由 + 失败回退”，不是旧版文档里的 Code 节点拼装方案。
+## 4. 工作流图结构
+最新推荐图结构如下：
 
-### 4.1 节点结构
 1. `Start`
-2. 主 `LLM`
-3. `End`
-4. 主 `LLM` 的 `fail-branch` 指向备用 `LLM`
-5. 备用 `LLM` 再输出到第二个 `End`
+2. `if-else` 节点：按 `task_type` 分三条业务线
+3. `运营日报 LLM`
+4. `弹幕总结 LLM`
+5. `粉丝日报 LLM`
+6. 每条业务线各自一个 `fail-branch` 回退 LLM
+7. 每条成功路径和回退路径各自输出到 `End.text`
 
-### 4.2 设计意图
-- 主模型先尝试生成结果
-- 如果主模型节点失败，自动切到备用模型
-- 两个 LLM 节点使用相同的输入协议和相近的提示词规则
-- 业务类型不依赖图上的条件分支，而是依赖 `task_type + system_prompt + user_prompt`
+仓库导出文件见：
+- [plugins/douyu/斗鱼日报AI.yml](d:/learn/abot/plugins/douyu/%E6%96%97%E9%B1%BC%E6%97%A5%E6%8A%A5AI.yml)
 
-## 5. 是否必须在 Dify 里做业务分支
-结论：当前这套最新版本里，不是必须。
+## 5. 为什么不用“一个 LLM + task_type 路由”
+这种旧方式能跑，但有几个问题：
 
-原因：
-- 插件侧已经针对三类任务分别构造了不同的 `system_prompt` 和 `user_prompt`
-- 工作流里也已经接收 `task_type`
-- 只要 LLM 节点提示词里明确说明三类任务的输出要求，一个 workflow 就能稳定工作
+- prompt 过于通用，模型会记住多个风格要求
+- 粉丝版容易混入“运营观察”
+- 弹幕总结容易长成“完整日报”
+- 回退模型也只能吃同一套混合规则
 
-更准确地说：
-- 现在推荐的是“提示词路由”
-- 不是“图上 condition 节点硬分叉”
+分支版的好处是：
+- `daily_report` 只看到运营日报规则
+- `danmu_summary` 只看到弹幕总结规则
+- `fans_daily_report` 只看到粉丝乐子日报规则
 
-## 6. 什么时候建议再升级成图分支
-如果后续出现下面任一情况，再考虑在 Dify 图里加 `If/Else` 或 `Code + Condition`：
+## 6. if-else 分支规则
+建议 `if-else` 节点至少包含三个 case：
 
-- `fans_daily_report` 想使用和运营日报完全不同的模型
-- 三类任务的温度、最大输出长度、后处理逻辑差异很大
-- 你希望在 Dify 控制台里直观看到每类任务的单独节点与耗时
-- 你希望未来继续加第四类、第五类斗鱼子任务
+1. `danmu_summary_case`
+2. `fans_daily_report_case`
+3. `daily_report_case`
 
-在目前这版里，先不加图分支反而更稳，改动面更小。
+推荐默认 `false` 分支回到 `daily_report`，因为项目侧默认值就是 `daily_report`。
 
-## 7. 最新工作流里必须补齐的点
-如果你使用的是本仓库里的最新版工作流导出，那么至少要确保：
+## 7. 每个分支的职责
+### 7.1 运营日报分支
+- 只输出完整日报正文
+- 重点写主线、关注点、运营观察、热点时段、高频梗
+- 不承担粉丝整活风格
 
-1. `Start.task_type` 的说明已经包含 `fans_daily_report`
-2. 主 `LLM` 的系统提示词里已经出现三类任务的路由规则
-3. 备用 `LLM` 的系统提示词也同步包含三类任务的路由规则
-4. 输出字段仍然固定为 `text`
+### 7.2 弹幕总结分支
+- 只输出图片上半部分摘要
+- 重点写现场氛围、观众情绪、高频梗、节奏变化
+- 不写运营分析
 
-本仓库已经把这些更新写进 [plugins/douyu/斗鱼日报AI.yml](d:/learn/abot/plugins/douyu/斗鱼日报AI.yml:128)。
+### 7.3 粉丝日报分支
+- 只输出单独的粉丝向乐子日报
+- 重点写欢乐、现场感、接梗、名场面
+- 不写策略、建议、转化、数据表现
 
-## 8. 推荐的 LLM 路由规则
-主 LLM 和备用 LLM 的系统提示词都建议具备这三条兜底规则：
+## 8. 回退 LLM 的设计建议
+不要把三条主分支都挂到同一个通用回退模型。
 
-- 当 `task_type=danmu_summary`
-  输出“弹幕总结”风格，偏现场氛围、观众情绪与高频梗，不写运营策略。
+推荐做法：
+- 运营日报主分支失败 -> 运营日报回退 LLM
+- 弹幕总结主分支失败 -> 弹幕总结回退 LLM
+- 粉丝日报主分支失败 -> 粉丝日报回退 LLM
 
-- 当 `task_type=daily_report`
-  输出“完整日报正文”风格，包含主线、运营观察、热点时段、高频梗等。
+这样回退时也不会风格跑偏。
 
-- 当 `task_type=fans_daily_report`
-  输出“粉丝向乐子日报”风格，整体要开心、欢乐、带一点整活气质，更像群友复盘直播间名场面；不要写运营分析，不要出现策略、转化、建议等运营词。
+## 9. 工作流导出里已经完成的优化
+本仓库里的最新版导出已经做了这些事：
 
-## 9. 项目侧对应代码位置
-如果你后续还要联调，这几个方法最关键：
+1. 新增 `if-else` 节点按 `task_type` 做真实分支
+2. 为三类任务拆分主 LLM
+3. 为三类任务拆分回退 LLM
+4. 各分支提示词单独收敛，不再共享一段总 prompt
+5. 输出仍统一为 `text`
 
-- Dify 输入封装见 [plugins/douyu/main.py](d:/learn/abot/plugins/douyu/main.py:2144)
-- 运营版日报任务调用见 [plugins/douyu/main.py](d:/learn/abot/plugins/douyu/main.py:2386)
-- 弹幕总结任务调用见 [plugins/douyu/main.py](d:/learn/abot/plugins/douyu/main.py:2231)
-- 粉丝日报任务调用见 [plugins/douyu/main.py](d:/learn/abot/plugins/douyu/main.py:2254)
+## 10. 项目配置层是否需要改
+一般不用改 scene 这一层。
 
-## 10. 上线前检查
-1. 在 Dify 中重新导入或手动同步最新工作流配置。
-2. 确认 Workflow 的 `End` 输出变量名是 `text`。
-3. 先执行 `#强制斗鱼弹幕日报 2026-04-27`，验证运营版链路。
-4. 再执行 `#强制斗鱼粉丝日报 2026-04-27`，验证粉丝版链路。
-5. 如果某类结果语气不对，优先检查 Dify 中对应 LLM 节点的系统提示词是否已经包含 `fans_daily_report` 路由规则。
+当前项目仍然是：
+- [plugins/douyu/config.toml](d:/learn/abot/plugins/douyu/config.toml:34) 使用 `scene = "douyu.daily_report"`
+- [config.yaml](d:/learn/abot/config.yaml:130) 将该 scene 路由到 `dify_workflow_douyu_daily_report`
 
-## 11. 一句建议
-当前这版最优先的不是“在图上拆很多分支”，而是保证：
-- 插件传入的 `task_type` 正确
-- Workflow 导出里的两套 LLM 提示词都同步支持 `fans_daily_report`
-- `workflow_output_key=text` 不变
+也就是说：
+- 插件入口不变
+- 场景路由不变
+- 优化点集中在 Dify Workflow 内部
 
-这样成本最低，和你现在这份“最新 Dify 配置”也最一致。
+## 11. 上线前验证
+建议至少验证这三条：
+
+1. `#强制斗鱼弹幕日报 2026-04-27`
+   目标：确认运营版只走运营正文分支
+
+2. `#强制斗鱼粉丝日报 2026-04-27`
+   目标：确认粉丝版不再混入运营分析
+
+3. 手动触发 `danmu_summary`
+   目标：确认摘要依旧短、像现场，不会拉成长文
+
+## 12. 一句结论
+你现在这个判断是对的。
+
+对斗鱼日报这种“同一份材料，多种输出风格”的任务来说：
+- 插件侧用一个 scene 保持简单
+- Dify 侧用 `if-else + 多 LLM 分支` 保持稳定
+
+这是比“一个 LLM 通吃三类任务”更稳、更高效的方案。