先说个有点丢人的起因我盯着后台账单翻了五分钟就为了确认一件事——某个AI工具我这个月调用了342次折下来单次成本刚好六毛钱。六毛钱掉地上都不一定有人捡可342次乘以0.6元一个月就是205块一年小两千五。我越想越不对劲当天晚上就决定动手用完全免费的平台和免费额度搭一套同样能干活的自动化工作流把这个成本直接打到0。于是就有了这套“零成本AI工作流”。现在它每天自动跑整理我的工作碎片、生成日报、定时推送到群里现金成本一分钱没有维护成本约等于周末两小时。这篇文章不卖课也不推广就把我选型、搭建、踩坑的全过程摊开讲特别适合每天都要用AI处理重复琐事、又不想持续掏订阅费的朋友。你放心不涉及任何高端操作全部是拖拽节点、填提示词、配API这种入门起步的活儿唯一的门槛是你愿意花两个晚上折腾。1. 先算账那6毛钱到底贵在哪1.1 一次6毛一个月到底烧掉多少很多人对按次计费的AI工具没概念觉得一次几毛钱不痛不痒。我当初也是这么想的直到某天瞄了一眼后台用量明细342次调用折合费用205.2元。这342次不是全是我手动点的其中一大半是“自动摘要”“每日总结”“待办整理”这类固定动作它们每天在固定时间自己跑风雨无阻账单也风雨无阻。我给自己算了一笔更扎眼的账。假设你每天只让它做10次轻量任务比如整理当日聊天记录、把零散想法变成要点、给一段文字起标题单次6毛一天就是6块一个月180块一年2160块。这还不算偶尔一次长文处理那种更贵。所以问题的本质不是6毛钱本身而是“6毛钱的固定频率”频率一旦上来小额成本立刻变成大额支出。这时候你就会理解我为什么要折腾零成本方案。它不是抠门是想把这个“每次必花的6毛”去掉让同样的流程跑在免费额度上。免费额度有上限但做日报、整理摘要、筛简历这类轻量任务只要控制好调用频率免费额度完全够用。省下来的不是一块两块是一年几千块的可持续成本。1.2 零成本不是零投入先搞清隐性成本我得先把丑话说在前面所谓“零成本”指的是现金成本趋近于0不代表你什么都不用付出。这套方案的实际投入是两个晚上大概6到8小时的学习和调试时间外加一台能开浏览器的普通电脑。如果你非要较真说时间也是成本那确实但一次性时间换每年两千多块的持续性支出这个兑换率我觉得很划算。还有一个隐性成本容易被忽略维护成本。免费平台会改版模型会升级API字段偶尔会变。我后面会专门讲踩坑记录就是因为这些平台不像付费商业工具那样“稳定如山”它时不时弄出点小变动你得愿意偶尔花十几分钟修一下。想明白这一点再动手你就不会中途因为一次报错就放弃。我建议你在开始之前先用一张纸列出自己的“高频AI动作清单”比如每日总结、信息分类、格式转换、定时提醒。圈出频率最高的前3个用这套工作流思路逐个替代。不要贪多先解决最烧钱的那个跑通之后再复制到下一个场景。2. 工具选型为什么是扣子飞书而不是Dify自部署或n8n2.1 三个方案的桌子扣子、Dify、n8n工作流搭建现在可选的工具很多但我这次的目标很明确不要钱、要快、要稳。基于这个目标我把三个主流方案摆在桌上比了一轮扣子Coze国内版、Dify自部署、n8n自部署。三者都能做自动化工作流但它们的成本结构和适用人群差异很大。方案现金成本搭建门槛维护成本适合谁扣子Coze国内版0免费额度基本够用低网页拖拽节点低平台托管个人、轻量自动化Dify自部署服务器费用至少几十块/月中高需要部署环境中高自己管服务团队、私有化需求n8n自部署服务器费用中节点多但排错难中定时任务依赖常驻进程重集成场景、已有服务器我并不是说Dify和n8n不好它们在各自的场景里都是好工具。尤其是Dify如果你有私有化部署的需求或者公司不允许数据出内网那它几乎是绕不开的选择。但“自部署”这三个字本身就意味着成本最便宜的云服务器一个月也要几十块这直接违背了“为了省6毛钱”的初衷属于为了省油钱去买辆车逻辑上就歪了。扣子这类托管平台的优势在于定时触发、模型调用、消息推送、数据库读写都在平台里托管你不用管服务器死活也不用半夜爬起来看日志。免费额度对个人轻量场景来说像日报、摘要、格式转换这类任务一天跑几十次完全在额度范围内。这才是“零成本”的真正含义——你只管业务流程本身底层的运行环境有人替你兜着。2.2 我的最终选择和数据流最终架构是“扣子工作流飞书多维表格飞书群机器人”三件套。扣子负责跑逻辑多维表格负责存原始素材和结果群机器人负责把日报推到手机上。这套组合有三个好处全免费、全中文、全在浏览器里操作。我用文字把整个数据流描述一遍不画图你跟着念就能看懂每天晚上6点扣子的定时触发器启动先从飞书多维表格里读取当天新增的所有素材行把所有素材合并成一段文本丢给大模型节点让它按固定格式生成日报日报生成后再通过飞书节点写回多维表格的“日报结果”字段同时推送一条消息到飞书群。整个过程没有人参与我从下班那一刻起就不用管它了。这里要提一个热词工作流编码。很多人一听“编码”以为要写代码其实工作流编码就是把一个流程用节点和连线表达出来本质上是“流程即代码”。你不需要会Python或者Java但要会用if-else逻辑、会填提示词、会看报错信息。这套日报工作流的全部“编码”就是5个节点和2条连线非常简单。3. 核心实现从6毛钱包月到零成本日报工作流3.1 需求定义从“每晚整理日志”开始先说清楚我到底要替代什么动作。我之前习惯在微信里给自己发各种工作碎片和同事确认的一个时间点、临时想到的方案方向、甲方随口提的一句修改意见。到了晚上这些碎片散落各处整理起来很烦。于是我用那个按次付费的工具每次都把碎片复制进去让它生成一份结构化日报单次6毛钱。拆解一下这个需求核心就三步收集碎片、交给模型整理、把结果存成日报。这三步里最值钱的是第二步也就是“把杂乱文本变成结构化清单”的能力而这一步恰恰是现在免费大模型都能做得很好的。既然模型能力免费就能拿到我只需要把收集和存储的管道搭好就行。管道本身不需要大模型用多维表格和触发器就能实现。所以需求定义清楚之后就发现真正让我每月掏钱的不是“整理日报”这件事而是“我懒得把收集和整理串起来”。工作流解决的正是这个串联问题一旦串起来那个按次付费的工具就彻底可以退掉了。3.2 第一步把素材搬进多维表格我用的数据存储是飞书多维表格它在免费版里提供的记录数足够个人用很久。我先建了一个名为“工作碎片”的表格字段包括日期、来源、内容、类型、状态、日报结果。其中“内容”字段用来存原始碎片文本“日报结果”字段用来回填生成好的日报“状态”字段用来标记这条素材是否已经被纳入当天的日报。收集方式有两种。一种是我自己手动新增记录把碎片粘贴进去另一种更省事在飞书里创建一个表单视图我直接往表单里丢内容它自动落到表格里。我实测下来最顺手的是用飞书机器人往多维表格写数据但那个要配机器人的API权限第一次配稍微有点绕。如果你只想快速跑通先用表单视图两分钟搞定。多维表格的字段类型要稍微注意一下日期字段选“日期”内容字段选“多行文本”状态字段选“单选”。为什么要用多行文本因为碎片内容经常带换行如果字段类型选成“单行文本”后半段会被截断。这个问题我后来在踩坑部分还会提到。3.3 第二步搭建日报生成主流程接下来是重头戏在扣子里创建“日报生成”工作流。工作流从定时触发器开始我把触发时间设为每天18:00并选了“工作日”重复规则周末不跑。然后添加第一个节点“多维表格查询”配置好飞书账号授权选定“工作碎片”表格查询条件是“日期等于今天且状态为空”这样能精准把当天的素材捞出来。查询出来的数据是多行记录不能直接丢给大模型。我加了一个“代码节点”或者叫“文本处理节点”把多条记录拼接成一段带序号的大文本格式类似“1. 和产品对齐了3.0版本上线时间2. 用户反馈下载页加载慢”。这个小动作很关键它决定了模型能不能把每条素材区分清楚。拼接完成之后进入“大模型节点”。模型我选的是平台内置的基础模型免费额度内可以调用。提示词我写了很久最终稳定下来的版本是这样你是我的工作日志整理助手。请把以下碎片化记录整理成一份结构化日报格式必须包含三部分【今日重点】【待办事项】【明日计划】。要求只提炼原有信息不得凭空补充每条要点控制在30字以内如果某项为空就写“无”。以下是原始碎片{input_text}这里的“{input_text}”是上一个节点传进来的拼接文本。你可能注意到我在提示词里强制规定了三要素和字数限制这是经验之谈大模型在格式自由的时候最不稳定一次一个样把格式焊死在提示词里它就没那么多自由发挥空间了。参数方面温度我调到0.2输出长度上限设了1000字。温度越低输出越稳定代价是少一点“灵性”但对日报这种结构化输出场景稳定压倒一切。3.4 第三步定时触发和消息推送大模型节点生成日报之后还需要把结果存回表格并通知我“日报已经生成好了”。这一步我加了两个节点第一个是“多维表格更新节点”条件是匹配到当天所有未被处理的记录把日报结果写入这天的空白字段里同时把状态字段改为“已生成”。这个写回动作是必须的否则第二天工作流再跑又会把这些记录当成未处理的新素材。第二个是“飞书群机器人节点”把生成的日报正文发送到我的一个私有群群只有我一个人纯粹当通知管道用。手机上飞书会弹消息我躺着划一眼就知道今天的工作收尾了。如果你不想用飞书群也可以改成发邮件、发钉钉、发企业微信扣子里都有现成节点选你日常打开频率最高的那个就行。这里多说一句关于“发布”的问题扣子里把节点全都搭好之后一定要点右上角的“发布”按钮工作流才会真正生效。我见过很多新手搭完节点后满心欢喜等推送结果啥也没来十有八九是忘了发布或者忘了在触发器里把开关打开。这是个特别蠢但又特别常见的坑。3.5 关键参数和免费额度怎么卡整套工作流跑下来每天实际消耗是这样的查询节点不计费文本拼接节点不计费大模型节点调用1次多维表格写回不计费飞书消息不计费。也就是说真正消耗免费额度的只有1次大模型调用。扣子免费版每日有几万token的基础模型额度我用掉的不到百分之一。但你要注意一个隐藏限制每分钟请求数QPS限制。有一次我改提示词时手滑不小心把工作流设成了每分钟循环调用结果直接触发平台的限流报错信息写得含糊其辞我排查了半天才发现是触发器的频率参数配错了。免费额度不是怕你用得多是怕你“忽然涌进一大波请求”。所以凡是涉及定时触发频率宁可保守一点日报这种任务一天一次足够完全不需要设成每小时。如果你嫌一天一次不够想把几个场景串在同一个工作流里那就要算好大模型节点总调用次数。我后来把“简历筛选”“文章转口播稿”这些也加上之后每天的总调用次数稳定在10次左右依然远低于免费额度下限。换句话说只要你不是拿它跑视频批量生成那种重型任务个人使用基本不会碰到配额墙。4. 同一套思路能复制到哪些场景4.1 简历筛选工作流把PDF变成排名表日报工作流跑通之后我顺手复制了一套去筛简历。我平时会帮团队看一些初级岗位的简历一份份打开PDF阅读实在太费神。于是我建了个“简历筛选”工作流流程变成把收到的简历文件拖进飞书云盘指定文件夹定时触发器每半小时检查一次新增文件解析PDF文本把文本丢给大模型提示词里提前写好岗位要求让它从“匹配度、硬技能、经验时长、风险点”四个维度打分最后把结果写入多维表格按分数排序。这个场景的本质和日报一模一样输入是零散的多份PDF处理是统一的按同一套JD标准打分输出是结构化的排名表。你也看到了换汤不换药核心还是那几步收集、拼接、模型处理、结构化回写。我唯一额外加的是一个“文件解析节点”负责把PDF转成纯文本扣子和飞书都有现成组件不用自己写解析代码。4.2 图文转口播稿一次用上三个模型节点日报和简历筛选都是单模型节点属于比较朴素的用法。文章转口播稿这个场景我用上了“多AI协作”也就是一个工作流里排了三个大模型节点各干各的像流水线一样。第一个节点负责把公众号长文压缩成核心要点避免后面处理超长文本第二个节点接收要点按口播的口吻写成逐字稿语气要求像主持人聊天不能有书面腔第三个节点把逐字稿拆成几条发布用的预告文案。三个节点串联前一个的输出是后一个的输入。你可能想问为什么不一个节点直接生成全部因为单次提示词越长模型越容易丢失前面的指令而且一旦中间某段不满意你得整篇重新生成。多AI协作的核心原则是每个模型节点只干一件事把任务拆到足够细。这就像做饭一个厨师负责洗菜切菜一个厨师负责下锅一个厨师负责摆盘每个环节都稳定整条线就不会翻车。代价是多占几次模型调用但免费额度依然扛得住。4.3 从工作流到Agent轻量级也能玩“AI Agent”这个词现在很火但很多人被各种营销文章唬住了以为Agent是什么玄乎的东西。我用这套工作流的经验告诉你当你让工作流能“根据输入内容决定下一步走哪个分支”的时候它就已经具备了一点Agent的味道。比如我在日报工作流里加了一个条件判断节点如果当天素材条数为空就不调用大模型直接结束如果素材条数超过20条先走一个“摘要压缩节点”再进入正式的日报生成节点。这个选择逻辑就是Agent最基础的雏形感知输入、做出决策、执行对应动作。扣子里也有“智能体”功能可以让你把多个工作流当成工具交给对话机器人调用那是更进阶的玩法。但我的建议是别一上来就追Agent先从固定的工作流跑起把节点和数据流吃透理解模型输入输出之间的流转再谈智能决策。地基打牢了后面加什么功能都不慌。5. 踩坑记录这些坑够你喝一壶的5.1 定时触发没反应先查这几个地方我第一次设置定时触发器之后第二天18:05打开飞书消息没来。我当时第一反应是平台出bug了骂了十分钟之后才冷静下来排查。最后发现问题是我在触发器里把“重复规则”设成了“不重复”这相当于只触发一次而那次触发发生在测试时被我手动消耗掉了。还有一次是时区问题触发器默认按UTC时间我的18:00实际上变成第二天凌晨2点。遇到定时触发不生效按这个顺序排查发布状态、开关状态、时区、频率限制、数据查询条件。把这五个地方检查完九成问题都能找到。5.2 模型输出格式飘忽不定加一层后处理就算你在提示词里写了“必须按三部分输出”模型还是偶尔会不听话比如多给你一段总结、或者把标题写成Markdown格式。第一次遇到这事我的日报推送下来带了一堆“##”、“**”符号群消息看着像乱码。后来我学乖了在模型节点后面加了一个“代码节点”做文本清理把所有Markdown符号和多余换行直接替换掉。不要指望大模型每次都不犯浑它就是个偶尔抽风的天才你只需要在后面加一个“检查员”把抽风的痕迹抹平就行。5.3 免费额度隐形墙和上下文超长有两个问题经常一起出现一是免费额度明明写着很高但一跑就触发限流二是文章太长模型报“上下文超长”错误。第一个问题的原因我在前文说过一般不是总量超了而是短时间并发请求太高。第二个问题最直接的解决方案是“分批处理”比如给长文加一个“分段节点”先按五千字切一刀再通过多个模型节点分别生成摘要最后合并。这也是为什么我在文章转口播稿工作流里特意加了压缩节点宁可多一次调用也好过长文本被模型无情截断。5.4 发布后改动不生效的“幽灵问题”还有一个很邪门的坑你改了提示词、保存了、也重新发布了但跑出来的结果还是旧版本。这种“幽灵问题”多半是多维表格里缓存了旧的测试数据。你以为工作流还在跑新逻辑其实它读取的是已经被处理过的旧记录状态字段早就不是空了自然不会再触发新一轮生成。解决方法是测试之前先把状态字段手动清空或者干脆删掉测试行重新建几条干净的记录。工作流本身没错是数据把你误导了。5.5 排查问题时的通用心法我最后的经验是遇到报错别急着改节点先把数据流从头到尾捋一遍。这个工作流本质就是“数据从A到B到C”节点之间靠字段连接只要中间任何一环的数据格式不对后面全崩。我一般先看“多维表格查询节点”有没有查出数据再看“文本拼接节点”的输出格式是不是预期那样最后才怀疑大模型节点。这个排查顺序帮我解决过无数个看似复杂的报错其实多一半都是前三步的数据就对不上。最后再分享一个小技巧这套东西跑了一个月之后我最大的收获反而不是省了那两千多块钱而是我养成了一种“拆流程”的直觉。现在我遇到任何重复性的琐事第一反应不是找工具而是想这件事能不能拆成输入、处理、输出三段放进一个工作流里。6毛钱一次的教训让我学会了从固定动作里找价值这个思维换到任何场景都好用。如果你也想动手我给一条最实际的小建议不要一上来就复刻我的全流程你先用扣子搭一个最简版本哪怕只是“每天自动运行、把一句话发给群机器人”这种最小工作流跑通一次再慢慢加节点。我第一次搭的时候也走了弯路总想一步到位结果报错连报错差点就把周末搭进去。先把最小闭环打通再往里加东西你会比我省下更多时间。