Dify 实战拆解:用“文粹 AI”做一条可交付的批量文档总结工作流

Dify 实战拆解：用“文粹 AI”做一条可交付的批量文档总结工作流

公众号：码海寻道
适读人群：Dify 新手、业务分析师、AI 应用工程师
目标：不讲空概念，完整拆一条可运行、可迭代的真实流程

一、先定义问题：为什么需要“批量文档总结”？

企业里最常见的知识处理任务，不是“问答”，而是“批量读材料并产出统一结果”。
典型输入是报告、会议纪要、论文、方案文档，典型输出是结构化摘要或决策简报。

传统做法要么人工逐篇阅读，要么把所有内容一次性喂给模型。
前者慢，后者不稳定。真正可交付的方案，需要满足四件事：

1. 支持多文件输入
2. 每个文件独立处理，避免互相污染
3. 输出格式统一，便于复用
4. 失败可定位，流程可调试

“文粹 AI——批量文档总结神器”就是围绕这四点构建的。

二、应用定位：这不是普通聊天机器人

这个案例在配置里是 mode: advanced-chat，不是纯 workflow 页面，也不是 agent-chat。
它的特征是：交互入口是对话，但核心执行逻辑是工作流图。

这类应用非常适合“用户一句触发，后台跑完整流程”的场景。

三、整体架构：一条 6 节点的分层流水线

流程主链路是：

1. Start（接收文件列表）
2. Iteration（逐文件迭代）
3. Document Extractor（提取文本）
4. LLM-1: 结构提取
5. LLM-2: 内容总结输出
6. Answer（汇总返回）

可把它理解成“两阶段总结”：

• 第一阶段先把文档结构拆清楚（章节、逻辑、作用）
• 第二阶段再基于结构做高质量归纳输出

这比“一步到位直接总结”更稳定，尤其在长文场景。

四、逐节点拆解（重点）

1) Start 节点：输入契约设计

这个节点的核心变量是 UplodFile（类型：file-list），并且：

• required: true（强制输入）
• max_length: 10（最多 10 个文件）
• allowed_file_types 包含 document

工程意义：
先把输入边界收紧，后续节点就不会被“空输入/错类型”拖垮。

2) Iteration 节点：把“批量”问题转成“单篇”问题

关键参数：

• iterator_input_type: array[file]
• iterator_selector: Start.UplodFile
• output_type: array[string]
• parallel_nums: 10
• error_handle_mode: terminated

这一步是整条流程最关键的工程设计：

• 每个文件单独处理，降低上下文干扰
• 最后统一聚合为字符串数组输出

注意点：error_handle_mode: terminated 代表一个子任务失败可能中断整批流程。
生产环境常见改法是“降级继续 + 失败标记”，后文会给改造方案。

3) Document Extractor：把非结构化文件转成可计算文本

该节点读取 iteration.item，输出 text。
它的意义不是“做总结”，而是做标准化预处理：把文档载体（PDF/Doc/图片）转成下游可消费的文本语料。

没有这一步，LLM 节点只能处理“看起来像文本的输入”，稳定性会明显下降。

4) LLM-1（结构提取）：先建骨架

模型配置：

• Provider：siliconflow
• Model：deepseek-ai/DeepSeek-V3
• Temperature：0.7
• 上下文输入：Document Extractor.text

提示词目标是“识别文章结构并逐段解释作用”，输出 Markdown。
这一步本质在做“信息重排”，不是最终摘要。

专业价值：

1. 把原文从线性文本转成结构化中间表示
2. 给第二个 LLM 减负，降低“总结跑偏”概率
3. 提升长文档的逻辑可读性

5) LLM-2（内容总结输出）：基于骨架生成结果

模型配置：

• Provider：ollama
• Model：qwen3:latest
• Temperature：0.7
• 上下文输入：LLM-1.text

该节点要求输出约 2000 字、按“引言/背景/方法/结果/讨论/结论”等结构展开。
从流程设计上看，第二个模型不是直接吃原文，而是吃“结构化中间稿”，这就是双阶段架构的核心。

6) Answer 节点：返回可消费结果

最终返回的是 Iteration.output（array[string]），即“每篇文档一条总结”。
这对后续系统对接很友好：

• 可以逐条写入数据库
• 可以逐条推送到飞书/企业微信
• 可以再做一次总汇总

五、这条流程为什么专业？核心在“分层”

很多新手会把需求写成一个大 Prompt：
“请阅读全部文档并总结”。这通常会出现：

• 漏信息
• 逻辑混乱
• 输出不一致
• 难调试

这个案例的优点是把职责拆开：

1. 输入层：文件列表约束
2. 执行层：逐文件迭代
3. 预处理层：文档抽取
4. 理解层：结构提取
5. 生成层：内容归纳
6. 输出层：统一返回

流程可解释、可测试、可替换，这就是工程化。

六、从“能跑”到“可上线”：5 个必须改造点

下面是这个案例如果要用于真实业务，建议优先改造的地方。

1) 错误策略改造

当前 error_handle_mode: terminated 较激进。
建议改为“单文件失败不影响整批”：

• 在迭代内增加 if-else/code 节点
• 失败时输出 {file, status, error} 占位结果
• 全量执行后统一汇总成功/失败比例

2) 输出结构改造

当前返回自由文本数组，适合阅读，不适合系统消费。
建议改为固定 JSON 结构，例如：

{
"title":"",
"core_points":[],
"risk_points":[],
"action_items":[],
"summary_markdown":""
}

3) 成本与时延改造

两次 LLM 调用 * 文件数会快速放大成本。
建议：

• 大文档先分块再摘要
• 同类文档可缓存第一阶段结构提取结果
• parallel_nums 按模型 QPS 与硬件动态调整，不要固定拉满

4) 质量控制改造

增加“事实一致性检查”节点：

• 约束“仅基于输入文本总结”
• 对高风险段落增加引用片段回链
• 将“无依据推断”单独标记

5) 观测与回归改造

建立最小评估集（10~20 篇标准文档），每次改 Prompt 或模型后回归：

• 完整性（关键信息是否遗漏）
• 准确性（是否出现幻觉）
• 一致性（格式是否稳定）
• 时延与成本（每篇耗时、token）

七、小白可直接照抄的落地步骤

1. 在 Dify 导入 文粹 AI——批量文档总结神器.yml
2. 先只替换两个模型节点（保证本地可调用）
3. 上传 2~3 份短文档做冒烟测试
4. 观察每个节点中间输出，确认“抽取 -> 结构 -> 总结”链路
5. 再扩到 10 份文档，测试并发、失败率和耗时
6. 最后再做输出 JSON 化和错误分支治理

不要一上来就追求“更聪明的模型”，先把链路稳定性做出来。

八、结论：这条案例最值得学的不是 Prompt，而是方法论

“文粹 AI”最有价值的地方，不是某个模型参数，而是它把复杂任务拆成了可管理的层次：
输入约束、迭代处理、结构提取、总结生成、统一输出。

这套方法可以复用于大量业务：

• 批量简历筛选
• 批量合同审阅
• 批量研报提炼
• 批量会议纪要归档

当你学会这种拆分方式，Dify 就不再是“玩具平台”，而是可交付的 AI 应用工程底座。