从散料到成稿,3步用 Dify 搭好一条内容自动化流水线
从散料到成稿,3步用 Dify 搭好一条内容自动化流水线
【免费下载链接】difyBuild Agentic workflows, RAG pipelines, with rich AI model and tool support on one collaborative workspace. Deploy on cloud, VPC, or self-hosted, so teams move from prototype to production without rebuilding the stack.项目地址: https://gitcode.com/GitHub_Trending/di/dify
周五晚上,你还要把这周散在各处的材料整理成一份能交差的东西:数据在表格、结论在聊天记录、背景在共享文档里,光是找齐就得花一小时。Dify 是一个开源的 AI 应用构建平台,核心能力是让你在工作流画布上拖拽"知识库检索、LLM 调用、代码"等节点,把"读资料 → 整理 → 出稿"这件事变成一条可反复运行的流水线。这篇文章带你从零搭到跑通,目标是把每周这类整理活从半天压缩到半小时以内。
整理材料最耗时间的 3 个时刻,你有没有中招
- 同样的流程每周重跑一遍:导出数据、贴进模板、删掉不该出现的内容。活本身 30 分钟能干完,格式对齐和来回修改却能吃掉 2 小时。
- 材料分散在多处:结论在群聊、数据在报表、背景在文档,收集这一步就要 1 小时起步,还没开始写。
- 产出质量看当天状态:这次语气太随意,下次漏了关键数字,"再改一版"成了固定反馈。
Dify 的思路恰好对应这三点:把流程固化成节点,材料统一进知识库检索,输出要求写死在提示词里,跑一次就是一条稳定可复用的流水线。
Dify 是怎么把散料变成成稿的
可以把它理解成一条装配线。知识库是原料货架:文档上传后自动切分、建索引,随时取用。工作流是传送带:按你连好的顺序一个个节点处理。LLM 节点是工位上的工人:拿着提示词里的说明书,把原料加工成你要的结构。
三条要点说清核心模块:
- 工作流引擎:按节点连线顺序执行,每个节点只做一件事,源码在
api/core/workflow/下,想改行为可以深入这里看 - 知识库(RAG):文档自动向量化,工作流里用"知识库检索"节点按相似度取回相关段落
- LLM 节点:可接不同厂商的大模型,负责总结、改写和结构化输出
从零到跑通,3 步就够了
准备:把环境部署起来
- 安装 Docker 和 Docker Compose(需要 v2.24.0 及以上版本)
- 获取项目代码并进入 docker 目录
- 复制环境配置模板,再用一条命令启动全部服务
下面这段命令一键完成部署:
git clone https://gitcode.com/GitHub_Trending/di/dify cd dify/docker cp .env.example .env docker compose up -d执行后约几分钟,所有容器就绪,浏览器打开访问地址注册账号即可进入控制台。
⚠️ 首次启动要等数据库初始化,页面打不开时先看容器日志,别反复重启。
配置:搭第一条工作流
- 控制台新建一个"工作流"类型的应用
- 先建知识库:把周报素材(Markdown、DOCX 均可)上传,等待索引完成
- 在画布上按顺序拖入节点:知识库检索 → LLM → 结束
- 在 LLM 节点写清楚输出要求,例如"按本周数据、问题、下周计划三段输出,每段不超过 3 条"
部署完成后的各服务分工如下,调试时用得上:
| 服务 | 作用 | 端口 |
|---|---|---|
| web | 控制台界面 | 3000 |
| api | 应用接口,调试请求先看它 | 5001 |
| postgres | 业务数据存储 | 5432 |
| redis | 缓存与任务队列 | 6379 |
| weaviate | 知识库的向量索引 | 8080 |
⚠️ 最容易犯的错是把所有要求塞进一段提示词。检索归检索、生成归生成,拆成两个节点,出问题才知道该修哪边。
验证:跑起来并修好
- 点"运行",给一次真实输入,别用测试话术糊弄
- 点开每个节点看调试面板:输入、输出、耗时、token 数都有,先定位是哪一环偏了
- 结果不对时,先看检索节点取回的段落对不对,再回头改提示词
- 稳定后发布,以后每周只需填输入点一次运行
✅ 建议留 2~3 条"标准答案"输入,每次改完提示词先跑标准答案,确认没变差再上线。
两个真实场景:前后能差多少
场景一:每周业务周报
| 维度 | 旧做法 | 接上 Dify 工作流后 |
|---|---|---|
| 耗时 | 3~4 小时 | 约 30 分钟(含人工校对 5 分钟) |
| 覆盖 | 手工只做一份主报 | 主报与分部门版本一次生成 |
| 结构 | 每周格式不一 | 固定三段,可直接归档 |
场景二:客户反馈归类
| 维度 | 旧做法 | 接上 Dify 工作流后 |
|---|---|---|
| 耗时 | 半天人工通读 | 上传即自动跑完 |
| 覆盖 | 抽样 20 条 | 全量处理 |
| 产出 | 零散备注 | 分类汇总 + 高频问题清单 |
常见坑位与解决办法
- 检索不准,输出答非所问→ 先查检索节点调试面板里取回的段落,段落不对就调相似度阈值和返回条数,别急着改提示词。
- 输出格式时好时坏→ 提示词里贴一个完整的格式示例,比描述"要求简洁"有效得多。
- 文档更新了,知识库还是旧的→ 修改文档后要对知识库触发重新索引,否则检索拿到的永远是旧版本。
- token 消耗涨得比预期快→ 通常是检索返回条数太多、段落太长,把返回数砍一半,并在提示词里限定"仅依据检索内容作答"。
Dify 把"收集—整理—输出"这段最重复的活变成了可复用的流程资产,你省下的是每周实打实的数小时。现在就可以按上面的三步走一遍:先部署环境,再建一个最小知识库,用一条真实素材跑通第一个工作流。
【免费下载链接】difyBuild Agentic workflows, RAG pipelines, with rich AI model and tool support on one collaborative workspace. Deploy on cloud, VPC, or self-hosted, so teams move from prototype to production without rebuilding the stack.项目地址: https://gitcode.com/GitHub_Trending/di/dify
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
