1. 从一条每日资讯说起为什么我最终选择了Coze工作流每天早上八点我手机里会准时弹出一条消息——一份排版整齐的AI行业资讯包含当天的重要动态、产品更新和值得关注的技术趋势。很多朋友以为我雇了助理在整理其实这条资讯从头到尾没有一个真人参与它是由我在Coze上搭的一套AI智能体工作流自动生成并发布的。这件事的起点很朴素我受够了每天早上花四十分钟刷各种信息源、复制粘贴、手动排版。作为一个长期关注AI智能体和工作流自动化的人我第一反应就是这事应该能自动化。但真正动手之后才发现从能跑通到每天稳定跑、内容质量还能看中间踩的坑比想象中多得多。这篇文章我想把整套东西拆开讲清楚Coze的AI智能体工作流到底是怎么运作的一条每日AI资讯从信息采集到自动发布要经过哪些环节每个环节我为什么这么设计以及那些只有真正跑过一段时间才会暴露出来的问题。不管你是完全没接触过Coze的新手还是已经搭过几个工作流但总觉得不够稳的老手应该都能从里面找到能直接抄作业的部分。先明确一下这套东西适合谁如果你每天需要处理重复性的信息整理、内容汇总、定时推送类任务或者你想入门AI智能体但不知道从哪个具体场景下手那这套每日资讯自动生成就是一个非常好的练手项目——它足够简单能跑通又足够完整能覆盖工作流的核心概念。关键词里的Coze、AI智能体、工作流这三个词基本就是整件事的全部骨架。2. 整体设计思路一条资讯流水线的拆解逻辑2.1 为什么是Coze而不是其他方案在动手之前我对比过几条路线。纯代码方案Python脚本定时任务最灵活但维护成本高改个信息源都要动代码Dify的工作流能力也很强偏向开发者编排复杂逻辑时更顺手而Coze的优势在于它的节点化编排对非纯技术背景的人友好插件生态现成尤其是发布这一环能直接对接内容平台省掉了大量对接工作。我最终选Coze的核心理由有三个。第一它的工作流是可视化节点编排每个节点的输入输出一目了然调试的时候能单独跑某个节点看结果这对排查问题太重要了。第二插件市场里有现成的信息采集和内容处理能力不用从零写爬虫和解析逻辑。第三定时触发是原生支持的我不需要额外搞一台服务器挂定时任务。当然Coze不是没有短板。它的代码节点能力相对受限复杂的数据清洗逻辑写起来不如本地Python舒服另外工作流跑长任务时偶尔会有超时问题这个后面会专门讲怎么绕。2.2 整条流水线的四个阶段我把每日AI资讯拆成了四个阶段对应工作流里的四组节点采集阶段从设定的信息源抓取当天内容做初步去重处理阶段用大模型对原始信息做筛选、摘要、归类生成阶段按照固定模板组装成一篇完整的资讯文稿发布阶段定时触发把成品推送到目标渠道这个拆法的逻辑是职责分离。很多人搭工作流喜欢把所有逻辑塞进一个大模型节点里让它又筛选又摘要又排版结果就是输出极不稳定——今天格式对明天就乱。把每个阶段拆开每个节点只干一件事出问题的时候能精确定位是哪一环坏了。提示工作流设计的黄金原则是一个节点只做一件事。节点越单一调试越容易复用性也越强。宁可多连几个节点也不要让单个节点承担多重职责。2.3 触发方式的选择触发方式我选的是定时触发每天早上七点半跑。这里有个细节值得说我没有把触发时间设成整点比如七点整因为整点是各种定时任务的高峰期平台侧的资源调度可能更紧张稍微错开一点七点半、七点二十这种实测下来稳定性更好。另外我保留了一个手动触发的入口。原因很简单有时候我想临时补一条资讯或者调试的时候想立刻看效果总不能等到第二天早上。手动触发和定时触发共用同一套工作流逻辑只是入口不同。3. 核心节点逐个拆解每个环节到底在干什么3.1 信息采集节点源的选择比技术更重要采集这一环技术实现反而是最简单的难的是采什么。我一开始贪多接了十几个信息源结果每天抓回来几百条大模型处理起来又慢又容易漏重点。后来我砍到五个核心源覆盖官方发布、行业媒体、技术社区三类质量立刻上来了。采集节点我用了Coze的插件能力来抓取配置的时候有几个参数必须注意参数我的设置原因抓取条数上限每源20条太多会拖慢后续处理太少会漏时间范围最近24小时保证是当日资讯去重策略按标题相似度同一事件多源报道很常见超时时间15秒单源超时不影响整体去重这一步特别关键。同一个AI新闻往往五六家媒体都在报如果不去重最后生成的资讯里会出现好几条内容几乎一样的条目非常难看。我的做法是在采集后加一个代码节点用标题的相似度做粗筛相似度超过阈值的只保留最早的一条。3.2 大模型处理节点提示词才是真正的核心这是整条工作流里最需要打磨的部分。同样一批原始信息提示词写得好和写得差输出质量天差地别。我前后改了十几版提示词总结出几个关键点。第一明确角色和任务边界。不要只说帮我整理资讯要说清楚你是一个AI行业资讯编辑负责从以下原始信息中筛选出最重要的5到8条每条用不超过80字概括并标注所属类别。第二给出输出格式的硬约束。我会在提示词里直接给出模板甚至给出一个示例输出让模型照着填。这一步能极大降低格式跑偏的概率。第三要求模型做取舍而不是罗列。原始信息可能有几十条但一篇资讯放不下那么多。我会明确告诉模型如果信息超过8条按重要性排序后只保留前8条逼它做判断。一个我踩过的坑早期我让模型自由发挥结果它有时候会把一条普通的产品更新写成重大突破语气夸张得离谱。后来我在提示词里加了语气约束——保持客观陈述不使用夸张词汇不添加原文没有的评价——输出立刻稳了很多。3.3 内容组装节点模板化是稳定性的保障处理完的内容是结构化的数据还需要组装成一篇可读的文稿。这一步我用的是模板拼接的方式而不是再让大模型生成一遍。原因很直接模板拼接的输出是100%可控的而让模型再写一遍格式和措辞又会引入不确定性。模板大概长这样## 今日AI资讯 · {{date}} ### 头条 {{headline}} ### 行业动态 {{industry_news}} ### 产品与技术 {{product_news}} ### 一句话速览 {{quick_roundup}}每个占位符对应处理阶段输出的一个字段。日期用工作流内置的时间变量自动填充不需要模型参与。这样组装出来的文稿格式永远一致读者每天看到的排版都是熟悉的。3.4 发布节点定时与容错发布环节我配置了定时触发同时加了一个失败重试机制。具体做法是发布节点执行后用一个条件判断节点检查返回状态如果失败就等待一段时间后重试一次。这个机制救过我好几次——有一次平台侧临时抽风第一次发布失败重试后成功了当天资讯照常发出。注意重试次数不要设太多一到两次足够。设太多如果遇到持续性故障反而会造成重复发布的风险。4. 完整实操流程从零搭起这套工作流4.1 环境准备与工作流创建先在Coze里创建一个新的工作流给它起个能看懂的名字比如每日AI资讯生成。创建后你会看到一个空白的画布左边是节点面板右边是配置区。第一步是配置开始节点。开始节点定义了工作流的输入参数。我这套工作流的输入很简单只有一个可选的date参数不填就默认取当天。虽然定时触发不需要手动传参但保留这个参数是为了手动触发时能指定日期方便补跑。第二步是拖入定时触发器。在触发器配置里设置执行时间为每天早上七点半时区选你所在的时区。这里有个细节Coze的定时触发用的是标准时间格式配置的时候注意别把时区搞错否则会出现明明设的早上七点半结果下午才跑的情况。4.2 采集节点的具体配置拖入信息采集相关的插件节点逐个配置信息源。每个源需要填的关键信息包括源地址、抓取条数、时间过滤条件。配置完采集节点后紧接着加一个代码节点做去重。代码节点的逻辑不复杂核心就是遍历采集回来的列表对标题做相似度比较。我用的是最简单的字符重叠率算法阈值设在0.7——两条标题有70%以上的字符重叠就认为是重复的。def deduplicate(items, threshold0.7): result [] for item in items: is_dup False for kept in result: if similarity(item[title], kept[title]) threshold: is_dup True break if not is_dup: result.append(item) return result这个代码节点跑完之后输出的就是去重后的干净列表直接喂给下一个节点。4.3 大模型节点的提示词工程大模型节点是整个工作流的心脏。我用的提示词结构分四段角色设定、任务说明、输出格式、约束条件。角色设定部分告诉模型它是谁任务说明部分讲清楚要做什么输出格式部分给出严格的模板约束条件部分列出所有不要做的事情。这四段缺一不可尤其是约束条件它是保证输出稳定的关键。提示词里我还会传入一个示例也就是所谓的few-shot。给一个输入输出的完整例子模型照着模仿的准确率会明显提升。这个技巧在处理结构化输出时特别管用。配置大模型节点时还要注意温度参数。资讯整理这种任务需要的是稳定和客观所以温度我设得比较低0.3左右。温度太高输出会发散同一批输入每次结果都不一样这对每日固定格式的资讯来说是灾难。4.4 组装与发布的串联组装节点用代码节点实现把大模型输出的结构化数据按模板拼接成Markdown文本。这一步没什么技术难度就是字符串替换但要注意处理空值情况——如果某个类别当天没有内容模板里对应的部分要能优雅地留空或者显示今日无相关动态而不是出现一个空的标题。发布节点配置好目标渠道后把组装好的文本传进去就行。发布成功后工作流会在日志里记录一条执行记录方便回溯。整个工作流串起来大概是这个顺序开始 → 定时触发 → 采集多源→ 去重 → 大模型处理 → 组装 → 发布 → 结束。节点数量不多但每个节点都承担了明确的职责。5. 常见问题与排查技巧实录5.1 工作流跑一半失败怎么办这是最常见的问题。工作流跑到某个节点报错后面的节点全都不执行。排查思路是从报错节点往前看而不是往后看。我遇到过的典型情况采集节点返回了空列表导致去重节点处理空数据时报错。解决办法是在去重节点前加一个条件判断如果列表为空就直接跳过后续处理发一条通知告诉我今天没采到内容。这种防御性设计在工作流里非常重要因为外部数据源的状态你控制不了。5.2 输出格式偶尔跑偏即使提示词写得很严格模型偶尔还是会不按格式来。我的应对策略是加一层格式校验。在组装节点前加一个代码节点检查大模型输出是否包含所有必需的字段如果缺字段就用默认值补上而不是让整个流程崩掉。下面这张表是我整理的常见问题速查问题现象可能原因解决方向采集为空源地址变更或超时检查源可用性加超时重试内容重复去重阈值过低调高相似度阈值格式错乱提示词约束不足加强格式约束加校验节点发布失败平台侧临时故障加重试机制执行超时单节点处理数据过多拆分节点减少单次处理量内容质量差提示词角色不清明确角色和取舍规则5.3 几个只有跑久了才知道的坑第一个坑是信息源的时效性。有些源看起来稳定但会不定期改版改版后采集就失效了。我的做法是每周抽一天手动检查一遍所有源看采集结果是否正常。这个习惯帮我提前发现过好几次源失效的问题。第二个坑是大模型的记忆问题。如果你在同一个会话里连续跑多次模型可能会受前一次输出的影响。解决办法是每次执行都用全新的上下文不要复用会话。第三个坑是时间边界。如果工作流在午夜前后跑采集最近24小时的内容可能会跨天导致资讯里混入昨天的内容。我的处理是把采集时间范围设成当天0点到现在而不是最近24小时这样边界就清晰了。提示工作流上线后不要就不管了。建议每周花十分钟看一眼执行日志很多问题在爆发前都有征兆比如执行时间逐渐变长、失败率缓慢上升。6. 关于AI智能体工作流的一些个人体会搭这套东西最大的收获不是省下了每天早上那四十分钟而是让我真正理解了AI智能体和工作流的边界在哪里。工作流擅长的是确定性流程的自动化——采集、去重、格式化、发布这些环节逻辑固定交给工作流跑得又快又稳。而大模型擅长的是需要判断的环节——筛选什么重要、怎么概括、如何取舍这些交给模型比写死规则灵活得多。把这两者结合起来才是AI智能体工作流真正的价值。纯规则的系统太死板纯模型的系统太发散而工作流把两者串起来各司其职整体就稳了。如果你也想搭一套类似的我的建议是从最小的闭环开始——先跑通采集一条、处理一条、发布一条确认整条链路通了再逐步加源、加处理逻辑、加容错。一上来就追求大而全大概率会在调试阶段就放弃。这套每日资讯的工作流我前后迭代了大概两个月才稳定下来前期跑出来的东西自己都不好意思看但每跑一次就改一点慢慢就顺了。最后分享一个我最近在试的扩展方向把生成好的资讯同时输出成不同格式一份发内容平台一份存成文档归档一份提取成纯文本推送到自己的笔记系统。同一份内容多个出口工作流稍微改几个节点就能实现。这个思路对任何内容类工作流都适用——一次生成多处复用才是自动化真正的效率所在。