零成本AI工作流搭建：用Dify+Ollama+n8n替代按次付费API

那6毛钱的故事，得从一张账单说起。某天我核对某商业AI工具的月度消费记录，发现“文章摘要”这一项居然出现了两百多笔，每笔6毛。金额其实不大，总共一百来块，但真正让我别扭的是——我明明只是想把十几篇技术文章自动整理成要点存进笔记，结果每天都要为这个机械动作交一次钱。更烦的是，这件事的流程完全固定：抓网页、抽正文、写摘要、存文档。既然每一步都能被规则描述出来，为什么还要按次付费？

于是我做了一个在旁人看来很“抠门”的决定：彻底停掉这个付费入口，用一台吃灰的旧笔记本，搭一套完全零成本的AI工作流。整套方案跑下来，API费用是零，用的是本地开源大模型、开源工作流编排平台和定时任务。省钱只是起点，整个过程真正让我上瘾的是“把一件重复劳动彻底交给机器”的控制感。如果你想搭类似的东西，或者正在纠结“花钱省事”还是“自己折腾”，这篇文章应该能帮你省下不少试错时间。

1. 那6毛钱是怎么冒出来的：一个让人不舒服的账单

1.1 每天重复的机械活：从“手动做”到“花钱做”

先交代背景。我这人有个习惯：每天会浏览一批科技类和技术类的长文，把核心观点整理成三五行摘要，归档进自己的知识库。最开始完全靠手动，复制标题、粘贴链接、读一遍、写摘要，一篇下来少说七八分钟，二十篇就是一个多小时。后来觉得太蠢，就开始用在线AI工具代劳，把链接贴进去，它自己抽正文、写摘要，一篇收费6毛。当时心里还觉得挺值——毕竟省了时间。

但问题在于，我高估了自己的文章量，也低估了这类“小额高频”支出的威力。一旦把每日阅读变成固定动作，次数就上去了。半个月后我查账单，发现光这一项就花掉将近一百块。说实话，一百块不至于肉疼，但那个“单次6毛”的定价逻辑让我非常不舒服：它本质上只是把一段本该自动化的流水线，拆成了按次零售。

1.2 一算账不淡定了：6毛钱背后的隐性成本

更让我警醒的，是这6毛钱背后其实还藏着三笔隐性成本。

第一笔是“重复配置成本”。每次往在线工具里贴链接，它虽然能记住部分偏好，但我还是得在输出格式、摘要长度、是否保留原文链接这些选项上反复确认。尤其是批量处理时，经常发现某几篇的摘要风格不对，又要单独返工。第二笔是“平台锁定成本”。用某家的工具时间一长，我的历史摘要、处理记录全堆在它的系统里，哪天想迁移，导出格式还不一定顺手。第三笔最隐性，是“流程不可见成本”。工具到底是怎么抽正文的？遇到反爬页面为什么失败？模型有没有把原文没写的观点脑补进摘要里？这些通通看不到，只能被动接受结果。

想明白这三点之后，我的目标就不只是“省掉6毛钱”，而是“把流程的每一个环节都拿回自己手里”。零成本只是顺手的结果。而且我给自己定了条规矩：先不充任何AI平台的费用，全程用开源方案跑通。这条规矩很重要，它逼着我彻底拆解需求，而不是继续依赖别人封装好的“一键总结”。

2. 从“花钱省事”到“免费折腾”：工具链选型的心路历程

2.1 先排除掉“看似免费实则受限”的选项

决定自建之后，第一步是选工具。市面上贴着“免费”标签的AI工作流方案不少，但真用起来各有各的坑。

一类是云端零代码平台的免费版。上手确实快，拖拖拽拽就能搭出一个“抓链接→写摘要”的工作流，但免费层通常按月限次数、限节点数、限模型种类，一旦文章量大一点就处处碰壁。更关键的是，数据全在别人服务器上，哪天平台调整策略，工作流可能直接就废了。这种方案更像“体验装”，不适合当长期基础设施。

另一类是各种所谓“免费额度”的API服务。注册送额度、拉新送额度，听着大方，但额度消耗得非常快，而且这种模式本质还是按量计费，只是把付费时间点往后挪了挪。我要的是真正的零成本，不是“先用后付”，所以在起跑线上就筛掉了这两类。

剩下可选的，就是开源自托管这条路。它的门槛比云端方案高，需要自己找机器、装环境、处理运维问题，但好处也实打实：没有调用次数限制，数据完全在自己手里，工作流里的每个节点都能改成自己想要的样子。最关键的是，它没有“按次收费”的心理压力——装好之后，使劲跑。

2.2 我的最终组合：Dify社区版 + Ollama本地模型 + n8n定时触发

经过一周的对比测试，我定下了最终组合，三件套分工明确：

• n8n负责“什么时候干活”和“干完活怎么通知”。它是开源的工作流自动化工具，自带定时触发器（Cron），能按时往流程里塞入URL，也能在流程结束时把结果推送到我的通知渠道。
• Dify社区版负责“怎么编排AI逻辑”。它把抓取、正文提取、大模型摘要、结果格式化这些节点可视化地串起来，还能通过API对外暴露整个工作流，方便n8n来调用。
• Ollama + Qwen2.5-7B负责“真正动脑子的部分”。它在本地跑开源大模型，不产生任何API费用。摘要这类任务，7B参数的量化模型完全够用。

为什么选这三样而不是一个平台大包大揽？因为“编排”和“触发”在Dify里虽然能实现，但n8n的定时和通知更灵活；“AI总结”如果交给云端模型又会引入费用，所以必须本地化。三件套各管一段，职责清晰。

2.3 为什么不用“全家桶式”的云端工作流平台

可能有人问：Dify也有云版，Coze这类平台也能定时触发，为什么非要自己部署一套？我用一张表格说清楚：

这张表想表达的核心判断是：如果你的工作流只需要“偶尔跑一次”，按次付费最优；如果你每天都要跑，而且处理的是自己长期积累的资料，那自托管虽然前期麻烦，但能把边际成本直接打到零。我这人有个习惯，遇到“每周都要重复三次以上”的任务就条件反射地想要自动化，所以答案毫无疑问是自托管。

3. 工作流拆解：先把“人怎么干活”翻译成“机器怎么干活”

3.1 需求翻译：从人脑步骤到机器节点

很多人搭工作流失败，不是因为工具不行，而是因为没把“人怎么干活”讲清楚。人看一篇链接，下意识就会做四件事：打开页面、跳过广告和导航、扫一遍正文、提炼要点。但机器不会“下意识”，你得把这四步翻译成明确的节点命令。

我最后拆出来的流程长这样：

1. 触发：n8n定时任务启动，读取一个“待处理URL清单”（这个清单可以来自RSS订阅，也可以是我手动往指定文件夹丢链接）。
2. 抓取：对每个URL发起HTTP请求，拿到原始HTML。
3. 清洗：用正文提取库（Trafilatura）去掉导航、广告、页脚等噪声，只保留标题、正文和发布日期。
4. 总结：把清洗后的正文切成合适的长度，喂给本地大模型，让它按指定格式输出摘要。
5. 归档：把摘要和原文链接写入本地Markdown文件，按日期和分类存放。
6. 通知：流程跑完后，n8n给聊天工具推一条“今日已处理N篇，其中2篇失败待复查”的消息。

每一步都很朴素，但“想清楚再动手”的价值会在后面出现。尤其是第四步“喂给大模型”的输入质量，完全取决于前两步做得好不好。我见过很多朋友在Dify里纠结提示词怎么写，结果正文里全是导航菜单，大模型再聪明也总结不出个所以然。所以我对“正文提取”这个环节的重视程度，远超“模型提示词”。

3.2 本地大模型的选型：Qwen2.5-7B到底够不够用

选模型是零成本路线的关键一步。当时我对比了Llama 3.1 8B、Qwen2.5 7B、Mistral 7B和Phi-3.5，最后选了Qwen2.5 7B的Q4_K_M量化版。原因有三点。

第一，中文能力。我的资料来源大部分是中文技术博客和资讯，Llama和Mistral的中文表现在这个参数量级上确实稍逊一筹，而Qwen系列在中文长文本理解和摘要上明显更稳。第二，硬件门槛。Q4量化后的7B模型占用显存约5GB到6GB，我那台旧笔记本是8GB内存加4GB显存的老显卡，刚好能塞进去；如果用14B模型，CPU推理会慢到让人怀疑人生。第三，社区生态。Qwen在Ollama库里直接有量化好的标签，拉下来就能跑，不需要自己折腾转换工具。

实测下来，单篇两三千字的中文技术文章，Qwen2.5-7B生成的摘要质量已经能达到我人工摘要的七八成水平。偶尔它会把次要信息写进“核心观点”里，但这类问题可以通过提示词和参数调整大幅缓解，后面讲踩坑时会细说。总之，摘要任务完全不需要追求“最强模型”，够用、免费、跑得动才是自托管的第一性原理。

3.3 一个关键设计：失败降级与人工抽查

任何自动化流程都必须默认“会出错”，而不是默认“会成功”。这套工作流上线之前，我专门设计了两条兜底机制。

第一条是“失败降级”。当某个URL抓取失败、正文提取为空、或者大模型输出格式跑偏时，工作流不中断，只是在该条目上打一个failed标记，把原始URL单独落在一个“待复查”清单里。这样既不会因为一个坏链接拖垮整批任务，又不会静默丢掉任何一篇资料。

第二条是“人工抽”。我给自己定的规矩是每天只看处理结果的十分之一，随机抽几篇对比原文和摘要，确认没有出现明显的“幻觉式总结”或“关键信息丢失”。一开始抽得勤，后来模型输出稳定了就放宽到每周。说到底，“零成本”不等于“完全无人值守”，而是“把人的精力从重复劳动中省出来，花在更值得复核的地方”。

4. 搭建实录：从零跑通第一条自动化工作流

4.1 环境准备：一台常开的旧电脑就够

我用来跑这套系统的是三年前淘汰下来的笔记本，配置很普通：i5处理器、16GB内存、4GB显存的GTX 1650。系统装了Ubuntu 22.04，Docker用docker compose统一管理容器。整台机器的角色就是“家里的一台小服务器”，每天至少开12个小时，反正原本也是吃灰，电费几乎可以忽略。

服务安装没什么神秘，三个主要服务依次起来：

# 安装 Ollama 并拉取量化后的 Qwen 模型 curl -fsSL https://ollama.com/install.sh | sh ollama pull qwen2.5:7b-q4_K_M ollama serve # Dify 社区版通过官方 docker compose 启动 git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d # n8n 直接单独起一个容器 docker run -d --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n n8nio/n8n

三个服务启动后，Dify的管理界面跑在8080端口，n8n跑在5678端口，Ollama的API运行在11434端口。这套环境就绪之后，剩下就是在一个可视化画布里把节点一个一个拖出来、连起来。

4.2 核心节点逐个配：抓取、清洗、总结、归档

Dify工作流模式下，我按这个顺序配置了六个节点：

1. 开始节点：接收一个输入字段url。
2. HTTP请求节点：对url发起GET请求，请求头里伪造常见浏览器的User-Agent，避免被部分站点直接拒绝。
3. 代码执行节点：跑一小段Python，用Trafilatura从HTML里提取正文和标题：

import trafilatura html_content = args["html"] downloaded = trafilatura.extract( html_content, include_comments=False, include_tables=False, no_fallback=False, ) if downloaded: return {"title": trafilatura.extract_metadata(html_content).title, "content": downloaded[:6000]}

4. LLM节点：模型选择Ollama里跑着的qwen2.5:7b，提示词走“摘要专家”路线（下面细说）。
5. 模板转换节点：把大模型输出的JSON转成Markdown格式，拼上原文链接和日期。
6. 结束节点：把最终结构化文本返回给调用方n8n。

n8n侧的工作流更简单：一条定时触发器（每天早上7点），读取存放待处理URL的文本文件，逐行拼接上Dify工作流的API地址，调用后把返回的Markdown追加到指定目录下的归档文件，最后发一条通知消息。整个链路里没有一条商业API调用，模型跑在本地，自动化跑在本地，数据也留在本地。

4.3 让大模型输出稳定：摘要提示词的设计要点

提示词直接决定摘要质量，这里分享我改过七八版之后稳定下来的模板：

你是一名技术编辑助理。我会给出一篇文章的正文，请完成以下任务： 1. 用三句话概括文章核心内容，第一句讲背景/问题，第二句讲方法/观点，第三句讲结论/价值。 2. 列出文章中出现的2到4个关键术语，并各用一句话解释。 3. 判断这篇文章是否值得深入阅读，只回答“值得”或“不值得”。 4. 所有输出必须基于提供的正文，禁止补充任何外部知识或猜测。 输出格式如下（严格按此格式，不要额外输出）： 核心内容：<三句话> 关键术语：<术语1>（<解释>）；<术语2>（<解释>） 阅读建议：<值得/不值得>

这个模板解决了三个常见问题：一是把“摘要”从一段话拆成结构化字段，方便归档时直接作为Markdown列表呈现；二是加了“禁止外部知识”这条约束，显著减少模型脑补；三是让输出格式固定，后续解析处理几乎不用再清理。提示词不是写得越花哨越好，而是要把“结果长什么样”规定得越死越好。

5. 踩坑记录：免费方案真正麻烦的不是钱

5.1 正文提取翻车：反爬、动态渲染与登录墙

自托管方案上线第一周，我就在“正文提取”这个环节吃了大亏。第一批二十几个URL里，有三篇返回的内容明显不对：一篇提取到了评论区，一篇提取结果是空字符串，还有一篇直接把网站的404页面当成正文喂给了模型。

排查下来原因各不相同。评论区那篇是Trafilatura对页面结构判断失误，把评论区节点当成了正文的一部分，解决办法是在HTML解析之前先用正则把comment相关的<div>区块粗暴删除。空字符串那篇是目标网站启用了简单的反爬，对非浏览器请求返回空壳页面，给HTTP节点加上完整的浏览器头就解决了。404那篇最坑，是URL本身过期了，页面自动跳转到了一个无关页面。

这个阶段的教训是：别指望单一策略通吃所有网站。我的处理策略是分层：先用Trafilatura做标准提取，失败或为空就退回用BeautifulSoup按article、content、main这些常见正文类名去猜，再失败就标记为“需人工处理”。让一小部分页面“投降”并不可耻，反而比为了覆盖它们引入全套无头浏览器、把系统搞成庞然大物要划算得多。

5.2 本地模型的“幻觉式总结”怎么治

本地大模型的“幻觉”问题比付费API更明显，因为它参数量小，更倾向于“顺着话说”。有一篇讨论PostgreSQL索引优化的文章，我的人工摘要根本没有提“云数据库”，结果Qwen的摘要里冒出一句“并建议用户评估云数据库的迁移收益”。原文里完全没有这个信息，纯粹是模型自己补的。

治这个问题的组合拳有三招。第一招是提示词里明令“只基于给定文本”，这比默不作声有效得多。第二招是降低解码温度，我把Ollama里跑这个模型的temperature参数从默认的0.8降到了0.2，随机性大幅下降，生成内容更贴原文。第三招是加一层“事实复核”的后续节点——让模型先输出摘要，再要求它从原文中找出摘要里每句话的对应片段，找不到对应片段的句子直接丢弃。三招下来，幻觉内容减少了一多半，偶尔还会漏网，但已经进入“可接受且能靠抽检兜住”的范围。

5.3 定时任务半夜挂掉：日志、重试与幂等设计

自托管系统的另一个大坑是稳定性。头一个月里，n8n的定时任务出现过三次深夜静默失败：一次是目标网站改了页面结构导致提取出来全是空，一次是Dify容器被系统OOM杀掉了，还有一次是网络波动导致某个请求超时。

对付这类问题，我的经验是把“可观测性”做进去。首先，n8n里每一个关键节点都加了Error Workflow分支，失败时不仅记录日志，还要推一条带错误信息摘要的通知，避免“静默失败”。其次，Dify容器加了内存限制和自动重启策略，保证它不会长期处于僵死状态。最后，整个归档流程设计成幂等的——同一篇URL如果重复处理，直接覆盖旧记录而不是追加新记录，这样即使某天重复触发也不会在知识库里产生一堆垃圾副本。

这些工作在付费API方案里完全不用管，因为平台帮你扛了。但自托管就得自己扛，这恰恰是“免费”的隐含代价。我的心态是：把运维本身当成项目的一部分，前期多花点时间，后期就能一直安稳地跑。

6. 省下的不只是6毛钱：这套工作流的隐性收益

6.1 从“省小钱”到“攒能力”

整套系统跑通到现在，已经有几个月了。那个6毛钱的账单彻底消失了，但更让我高兴的是周围人对这个系统的使用方式发生了变化。朋友推给我一篇长文，我不再是“有空再看”，而是直接把链接丢进工作流的收件箱，几分钟后笔记库里就多了一条带摘要的条目。遇到特别长的行业报告，我甚至会在本地模型出摘要之后，让工作流额外生成一份“十分钟阅读版”，列出结论、数据和可以跳过的章节。

这种变化的核心是：我从“为单次内容付费”变成了“为内容处理管道付一次搭建成本”。后者省下的不是6毛钱，而是每次面对长文时的决策成本。以前看到一篇好文章，我会想“要不要花时间读完”“要不要记笔记”，现在这个决策直接被工作流消解了——扔进去，自动变成知识卡片。

6.2 从“6毛钱思维”到“工作流优先思维”

这个项目带给我最大的收获，其实是一种思维转变：遇到重复性任务时，第一反应不再是“这个活多少钱能外包”，而是“这个活能不能拆成可编排的步骤”。简历筛选、竞品监控、读书笔记、甚至家里的水电费账单整理，本质上都是同一个模式：收集数据、清洗、让模型总结、归档通知。这套工作流里的每个节点单独拆出来，都能复用到其他场景。

比如我把“正文提取”节点抽出来，配了一个新的工作流，专门把PDF合同里的条款提取成结构化表格；把“定时触发”和“LLM总结”节点组合，做成了一个每天早上自动汇总前一天行业动态的简报机器人。核心能力是同一个，换的是输入和输出格式。

6.3 对“零成本”的重新认识

最后说点实话。这套方案说是“零成本”，其实只是“零API费用”。真正的成本是学习时间、调试时间以及偶尔半夜爬起来排查故障的运维精力。如果你本来就对这类技术没兴趣，或者手上并没有成规模、成批量的重复任务，那继续花那6毛钱反而是最理性的选择，因为你的时间成本可能远比6毛钱贵。

但如果你和我一样，对“流程可掌控”这件事本身有执念，那这套工作流能带给你的不仅是零账单，还有一种“所有环节都在自己手里”的安全感。这套东西现在还在我笔记本里跑着，每天早上7点准时开始干活，偶尔还是会有一两个链接需要我手动处理，但整体上它已经成了我信息处理体系里最踏实的一环。省下的不多，但省得很安心。