首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >2025,我的AI工作流探索:从4月入坑n8n到年底玩转Dify,这一年我用自动化解决了哪些问题

2025,我的AI工作流探索:从4月入坑n8n到年底玩转Dify,这一年我用自动化解决了哪些问题

原创
作者头像
一只牛博
发布2026-01-19 13:42:03
发布2026-01-19 13:42:03
9240
举报
文章被收录于专栏:AIAI

2025年,AI不只是聊天机器人,更是可以串联起来的自动化工作流。这一年我深度折腾了n8n和Dify两款工具,从最简单的定时推送,到知识库检索、服务器监控、智能业务查询,一步步把AI能力嵌入到日常工作中。这篇文章记录我这一年的探索历程,希望能给同样在探索AI落地的朋友一些参考。


前言:为什么要折腾AI工作流?

2025年AI工具遍地开花,但我发现一个问题:单独的AI对话很强,但和实际工作场景的结合还是有门槛的。

比如我想让AI每天早上帮我汇总热点新闻发到群里,或者让AI自动监控服务器状态、出问题就告警,又或者让业务人员用自然语言查询数据库——这些场景光靠一个聊天窗口是搞不定的。

这就需要AI工作流——把AI能力和各种服务、数据源、触发器串联起来,形成自动化的流程。

说白了,AI工作流就是让AI从"被动回答问题"变成"主动干活"。你设定好规则和触发条件,它就能自动执行,不需要你每次都去手动操作。

2025年我主要折腾了两款工具:

  • n8n:开源的工作流自动化平台,可以自己部署,节点丰富,适合做各种自动化串联
  • Dify:开源的LLM应用开发平台,擅长构建AI应用和知识库,对话体验更好

这两个工具各有所长,n8n更像是"万能胶水",能把各种服务粘在一起;Dify则更专注于AI应用本身,知识库和对话流程做得更好。这篇文章就聊聊我这一年用这两个工具做了什么,踩了哪些坑,有什么心得。


一、4月入坑n8n:从Hello World到每日新闻推送

为什么选择n8n?

在折腾n8n之前,我也看过Zapier、Make(原Integromat)这些商业产品。但它们有两个问题:一是贵,按执行次数收费,稍微用多点就要花不少钱;二是数据要经过他们的服务器,有些敏感场景不太放心。

n8n是开源的,可以自己部署在服务器上,数据完全自己掌控。而且它的节点非常丰富,基本上主流的服务都有现成的集成,实在没有的也可以用HTTP请求节点自己对接。

最早的尝试

翻了一下我的n8n后台,最早的工作流创建于2025年4月10日。

n8n开始搭建
n8n开始搭建

当时就是想试试这个工具能干什么,从最简单的Hello World开始——一个手动触发的节点,连接一个Set节点设置一些数据,再连接一个调试输出。虽然简单,但让我理解了n8n的基本逻辑:节点之间通过数据流连接,上一个节点的输出就是下一个节点的输入

第一个实用工作流:每日热点新闻推送

玩了几天后,我做了第一个真正有用的工作流——每天定时获取热点新闻,用AI总结后发送到Telegram群

这个需求的背景是:我有一个小群,大家都是技术圈的朋友,每天想看看有什么热点新闻。但手动去各个平台刷太费时间了,不如让AI帮我们汇总一下。

这个需求的逻辑很简单:

image-20260104115454441
image-20260104115454441

具体实现:

image-20250425165403192
image-20250425165403192

1. 配置计划触发器

这是n8n里最基础的节点,就是一个定时器,到点执行。可以设置每天几点触发,或者每隔多久触发一次。我设置的是每天早上8点触发,这样大家上班路上就能看到。

这个能力看起来简单,但能做的事情很多——定时打卡、定时抓取某个网站的数据、定时发送报告...凡是需要定时执行的场景都能用。

2. 配置HTTP请求获取新闻

我用的是一个公开的新闻聚合API,能获取微博、百度、虎扑等平台的热榜数据。这里有个技巧:不要只取一个平台的数据,多取几个平台然后让AI去重和筛选,这样内容更丰富。

3. 配置AI Agent处理数据

这里有个小坑:如果你的输入是一个对象,记得要用toJsonString()转换一下,不然AI可能解析不了。

我用的是OpenRouter的接口,它可以免费使用大部分主流模型,对于这种轻量级的任务完全够用。Prompt我是这样写的:

代码语言:txt
复制
你是一个新闻编辑,请从以下热榜数据中筛选出5-8条最有价值的新闻,要求:
1. 去除重复内容
2. 优先选择科技、互联网相关的新闻
3. 用简洁的语言概括每条新闻
4. 输出格式:emoji + 标题 + 一句话概括

4. 发送到Telegram

最后把AI总结好的内容发送到Telegram群聊。n8n有现成的Telegram节点,配置好Bot Token和Chat ID就能用。

这个工作流跑了大半年了,每天早上8点准时推送,从来没出过问题。群里的朋友都说挺方便的,不用自己去刷各种App了。

image-20250425173827553
image-20250425173827553

踩过的坑和经验总结

做这个工作流的过程中,我踩了不少坑,分享几个比较典型的:

坑1:AI输出格式不稳定

有时候AI会自作主张加一些开场白或者结尾语,导致消息格式不统一。解决方法是在Prompt里明确要求"直接输出内容,不要有任何开场白和结尾"。

坑2:时区问题

n8n默认用的是UTC时区,我设置的8点触发,结果实际是下午4点才触发。后来在环境变量里设置了GENERIC_TIMEZONE=Asia/Shanghai才解决。


二、进阶玩法:用n8n+AI做服务器监控告警

新闻推送只是开胃菜,真正让我感受到AI工作流威力的,是后来做的服务器监控告警系统

需求背景

作为一个经常折腾服务器的人,最怕的就是服务器出问题自己不知道。以前我用的是传统的监控工具,比如Prometheus+Grafana,但有个问题:告警信息太技术化了,一堆指标数字,有时候看半天也不知道到底严不严重

我就想:能不能让AI来帮我分析监控数据,用人话告诉我服务器现在什么情况,需不需要处理?

实现思路

image-20260104194006428
image-20260104194006428

这个工作流比新闻推送复杂一些,因为涉及到:

  1. 多台服务器的数据采集
  2. AI需要理解各种指标的含义
  3. 告警要分级,不能什么小事都通知

关键实现细节

1. 数据采集

我在每台服务器上部署了一个简单的脚本,定时把CPU、内存、磁盘、网络等指标上报到一个中心接口。n8n通过HTTP请求获取这些数据。

2. AI分析Prompt设计

这是最关键的部分。我花了不少时间调试Prompt,最终版本大概是这样的:

代码语言:txt
复制
你是一个资深的Linux运维工程师,请分析以下服务器监控数据:

{{$json.serverData}}

请按以下格式输出分析结果:
1. 整体状态:正常/警告/严重
2. 问题描述:如果有异常,用一句话描述问题
3. 建议操作:需要采取什么措施
4. 紧急程度:1-5分,5分最紧急

判断标准:
- CPU持续>80%为警告,>95%为严重
- 内存使用>85%为警告,>95%为严重
- 磁盘使用>80%为警告,>90%为严重
- 如果某个进程内存泄漏(持续增长),标记为警告

3. 条件分支处理

n8n有一个IF节点,可以根据条件走不同的分支。我设置的是:

  • 如果AI判断为"正常",不做任何操作
  • 如果是"警告",发送Telegram通知
  • 如果是"严重",除了Telegram还要打电话(用的是云通信的语音通知API)

实际效果

9-tg返回
9-tg返回

这个系统上线后,有一次真的救了我。

那天凌晨2点,我正睡得香,突然手机响了——是语音告警。AI告诉我:"服务器A的磁盘使用率已达92%,预计6小时内将满,建议立即清理日志文件。"

我爬起来一看,果然是日志文件没配置轮转,疯狂增长。清理完继续睡觉,第二天早上服务还在正常跑。

如果没有这个告警,等我第二天上班发现的时候,服务器可能已经因为磁盘满了而挂掉了。

这就是AI工作流的价值——它不只是帮你做重复的事情,还能在关键时刻帮你发现问题。


三、遇见Dify:当AI工作流需要更强的对话能力

n8n用了大半年,我发现它有一个短板:对话体验不够好

n8n擅长的是"触发-执行"这种模式,但如果我想做一个可以和用户对话的AI应用,比如让业务人员用自然语言查询数据库,n8n就有点力不从心了。

这时候我发现了Dify。

Dify是什么?

Dify是一个开源的LLM应用开发平台,可以理解为"AI应用的低代码平台"。它的核心能力是:

  1. 知识库:可以上传文档,让AI基于你的私有数据回答问题
  2. 工作流编排:类似n8n,但更专注于AI对话流程
  3. 对话应用:可以快速搭建一个ChatGPT风格的对话界面

我用Dify做了什么?

1. 公司内部知识库问答

首先我们看一下它的原理:

image-20251125100503381
image-20251125100503381

我们公司有很多内部文档——产品手册、技术规范、FAQ等等。以前新人入职要花很长时间翻文档,有问题还得问老员工。

我用Dify搭建了一个内部知识库问答系统:把所有文档上传到Dify的知识库,然后创建一个对话应用。新人有问题直接问AI,AI会基于知识库里的内容回答。

效果出奇的好。新人说比翻文档方便多了,老员工也不用天天被打扰了。

image-20251125102530033
image-20251125102530033

2. 自然语言查询数据库

这是我觉得最有价值的一个应用。

业务人员经常需要查一些数据,比如"上个月销售额最高的10个产品是什么"、"北京地区的用户有多少"。以前他们要么找开发写SQL,要么用BI工具自己拖拽,都挺麻烦的。

我用Dify+数据库连接器做了一个自然语言查询工具。业务人员直接用中文描述需求,AI会自动生成SQL并执行,然后把结果用表格或图表展示出来。

当然,这里面有很多细节要处理:

  • 要给AI提供数据库的表结构信息
  • 要限制AI只能执行SELECT语句,防止误操作
  • 要对敏感字段做脱敏处理

但整体来说,这个工具大大降低了业务人员获取数据的门槛。

ps:因为涉及到公司,这里就不过多展示图片内容


四、n8n vs Dify:什么场景用什么工具?

用了这两个工具大半年,我总结了一下它们各自的适用场景:

n8n适合:

  • 定时任务、自动化流程
  • 需要对接大量第三方服务的场景
  • "触发-执行"模式的工作流
  • 对数据流转有复杂处理需求的场景

Dify适合:

  • 需要对话交互的AI应用
  • 基于私有知识库的问答系统
  • 需要快速搭建AI应用原型的场景
  • 对对话体验要求较高的场景

两者结合:

其实最强大的玩法是把两者结合起来。比如我现在的一个工作流是这样的:

image-20260104195008381
image-20260104195008381

这样既有Dify的对话体验,又有n8n的强大集成能力,两全其美。


五、这一年的收获和思考

技术层面的收获

  1. 学会了"用AI思维"解决问题:以前遇到重复性工作,第一反应是写脚本。现在第一反应是:能不能用AI工作流搞定?
  2. Prompt工程很重要:AI工作流的效果,很大程度上取决于Prompt写得好不好。这一年我在Prompt调试上花了不少时间,也积累了一些经验。
  3. 自动化思维的培养:开始习惯性地思考"这个流程能不能自动化",效率提升了不少。

对AI落地的思考

2025年大家都在说AI,但真正把AI用起来、产生价值的,我觉得还是少数。很多人停留在"和ChatGPT聊天"的阶段,没有把AI能力和实际工作场景结合起来。

AI工作流就是一个很好的切入点。它不需要你懂机器学习,不需要你会训练模型,只需要你:

  1. 能清晰地描述你的需求
  2. 会用低代码工具搭建流程
  3. 愿意花时间调试和优化

门槛其实不高,但能解决的问题很多。

2026年的计划

新的一年,我打算继续深入探索AI工作流这个方向:

  1. 尝试更多的AI模型,看看不同模型在工作流场景下的表现差异
  2. 探索Agent的玩法,让AI能自主决策和执行更复杂的任务
  3. 把现有的工作流做得更稳定、更易用,争取能分享给更多人

写在最后

2025年是我真正开始"用"AI的一年,而不只是"玩"AI。

从最简单的新闻推送,到服务器监控告警,再到知识库问答和自然语言查询,AI工作流让我看到了AI落地的无限可能。它不是什么高深的技术,而是一种新的工作方式——让AI成为你的自动化助手,帮你处理那些重复、繁琐、但又不得不做的事情

如果你也对AI工作流感兴趣,我的建议是:不要只看教程,动手做一个自己需要的工作流。哪怕是最简单的定时提醒,做出来的那一刻,你就会理解这东西的价值。

2026年,希望能和更多朋友一起探索AI的更多可能性。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 前言:为什么要折腾AI工作流?
  • 一、4月入坑n8n:从Hello World到每日新闻推送
    • 为什么选择n8n?
    • 最早的尝试
    • 第一个实用工作流:每日热点新闻推送
    • 踩过的坑和经验总结
  • 二、进阶玩法:用n8n+AI做服务器监控告警
    • 需求背景
    • 实现思路
    • 关键实现细节
    • 实际效果
  • 三、遇见Dify:当AI工作流需要更强的对话能力
    • Dify是什么?
    • 我用Dify做了什么?
  • 四、n8n vs Dify:什么场景用什么工具?
  • 五、这一年的收获和思考
    • 技术层面的收获
    • 对AI落地的思考
    • 2026年的计划
  • 写在最后
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档