每天早晨被几十个红色未读标记唤醒公众号、行业站点、GitHub 热榜、竞品公告全部刷完一小时就没了而真正和你业务相关的可能只有两三条。长期做内容和技术跟踪的人对这种“信息过载但有效信息稀缺”的状态应该都不陌生。我受够了之后直接用 Coze 智能体平台搭了一个纯自动化的 AI 情报助手定时抓取我关心的信源内容用大模型把低价值内容过滤掉把值得看的部分整理成结构化简报直接推到工作群。全程不写后端代码、不用自己维护服务器更不需要每天手动打开任何 App 去刷一遍。整个项目从零搭建到跑通关键步骤很清晰今天把这套方案从头到尾拆开讲包含设计思路、具体配置、完整工作流步骤以及我实际跑了一两个月之后踩到的坑和排查方法。这套方案适合谁做内容选题的编辑和自媒体、需要盯竞品动态的产品和运营、想低成本体验 AI Agent 的开发者都适用。你不一定懂代码但最好对“输入 — 处理 — 输出”的基本逻辑有个概念。准备好了就从设计思路开始。1. 项目整体设计与思路拆解1.1 为什么是 Coze而不是从零写一套爬虫服务我在动手前认真对比过几条技术路线。第一条是自己写爬虫加调度任务用 Python 加 APScheduler 或者 GitHub Actions再调大模型 API 做摘要最后通过机器人 Webhook 推送到群里。这条路技术上完全通以前我确实这么干过但维护成本不低网站改版要跟着改选择器、服务器到期要迁移、API Key 要安全管理目标只是“看情报”不是“练爬虫”为这点事养一套系统不太划算。第二条就是 Coze 这类 AI 智能体平台。它最核心的吸引力不是“低代码”这个概念而是把情报助手需要的几块基础设施都集成好了定时触发、插件商店里的 RSS 采集和网页解析能力、大模型节点的自由调度、知识库和数据库以及现成的 Webhook 推送节点。换句话说它把“从零到一”变成了“把积木插好”。选 Coze 还有一个很实际的理由迭代速度快。我在搭的过程中对信源和提示词的调整非常频繁传统开发模式改一次要重新部署Coze 里就是改节点再发布的事。你不需要理解 Docker、反向代理、数据库连接池这些概念把精力全部放在“什么样的情报值得推送”上这才是这个项目的真正核心。当然它也有边界。如果单日采集量级到几十万条、需要深度定制爬虫或部署在自己内网那就不要硬套 Coze这些场景它并不擅长。但对个人和中小团队的情报跟踪场景Coze 的综合效率确实是最高的。1.2 情报助手的流水线架构像一个自动化的编辑部整个系统我习惯拆成六层来看每一层在 Coze 里都有对应的实现方式触发层定时触发器相当于编辑部每天早上的晨会闹钟。采集层通过插件或 HTTP 请求节点抓取目标信源的标题、链接、摘要。清洗层用 Code 节点做 URL 去重、字段格式整理相当于记者把素材按统一格式填入稿件模板。增强层可选把抓取到的内容在知识库里做一次背景检索补充相关历史信息。生成层大模型节点按预设提示词完成筛选、摘要、优先级排序和输出格式化。投递层把最终结果通过 Webhook 推送到飞书、钉钉、企业微信或 Telegram 群。这套分层的设计思路很重要。很多人第一次搭情报助手容易把“抓取”和“生成”混在一个节点里结果后面想调整推送格式发现明明只是改个输出却要动整个流程。分层之后每一层只干一件事调整某一层不会牵连其他层排查问题也更简单——推送没到就先查投递层内容质量差就只改提示词。这里我想多提一句情报系统不建议把完整网页内容全部保存下来应该只提取“标题来源摘要链接发布时间”这几个字段。原因很直接一是大模型按长文本处理成本随内容长度上升二是保存历史数据涉及版权合规问题三是大多数场景下读者真正需要的是“知道发生什么”和“决定要不要点开原文”摘要加链接已经足够。1.3 第一版控制范围先跑通再谈扩展搭建初期有个很容易犯的错误想一次性把所有功能都做出来多信源、多格式、自动去重、对话查询、定期报告全部塞进第一版。结果就是工作流节点越来越多测试时根本分不清是哪一个环节出的问题。我自己建议的第一版范围固定 3 到 5 个高质量信源每天定时跑一次工作流生成一份当日情报简报并推送到群仅此而已。目的是先把“定时触发—采集—清洗—生成—推送”这条完整链路跑通。链路是骨架内容质量是血肉骨架没问题了再往上加对话查询、导出报告、更多信源这些功能。2. 环境准备与核心组件配置2.1 注册账号与团队空间的选择Coze 的入口是 coze.cn 或对应国际版站点注册流程不复杂手机号或邮箱验证即可。进入控制台后第一件事是创建空间。这里要注意空间分个人空间和团队空间建议直接创建团队空间再开始搭项目。原因有几个。团队空间在成员协作、资源隔离和权限管理上更规范就算你只是一个人用后续想把项目分享给同事一起维护团队空间可以直接加成员比个人空间灵活得多。另一个原因是团队空间内的资源如插件配置、知识库、数据库在项目间复用更自然我早期在个人空间搭过一版后来切换团队空间重新整理了一遍浪费了不少时间。创建项目时平台会要求选择一个底模型这一步不用想太多按 Coze 当前提供的可用模型选一个主流款即可。物理部署在哪个区域、用哪个模型厂商这些后续都能在节点里调整不影响整体架构。2.2 插件选型采集层的关键拼图情报助手能不能抓到你想要的信息核心在插件选型上。Coze 插件商店里的插件数量不少而且不同时期有变化我按功能分了几类你在搭建时按需选取RSS 类插件适合抓取博客、技术媒体、部分新闻站的 RSS 输出。稳定、结构清晰是我的第一选择。搜索类插件按关键词抓取搜索结果适合竞品情报和品牌监控能覆盖没有 RSS 的站点。网页解析类插件输入 URL 直接抓取正文内容适合目标信源非常明确的场景。通用 HTTP 请求插件类似代码里的 requests 客户端可以对接公开 API灵活性最高但需要自己解析返回结果。实际使用中我遇到的普遍情况是插件商店不一定能精确匹配你想抓的站点。这时候不用死磕插件Coze 工作流里本身就支持 Code 节点可以写少量 JavaScript 代码用内置的 HTTP 能力直接向接口发请求然后把格式化后的数据传给下游节点。学会用 Code 节点做兜底采集层就基本不会被卡住。还要提醒一句插件在真正执行前最好先做一次单节点测试。我在配置 RSS 插件时就遇到过某个信源返回超时、某个字段解析为空的情况单节点调试可以快速定位到底是指令问题还是信源问题。2.3 定时触发器早报的“闹钟”怎么设Coze 的定时触发器支持按 Cron 表达式设定执行周期也支持简单的间隔执行。我用的是每日早上固定时间跑一次对应的 Cron 表达式类似0 1 * * *这种。这里有个必须注意的细节Cron 里的时间到底是 UTC 还是北京时间不同区域的平台处理逻辑不一样。如果你发现触发器设的是早上九点实际执行却在下午五点十有八九是时区差问题。稳妥的做法是设定好之后先看平台给出的“下次执行时间”预览确认执行时间符合预期再等待触发验证。除了每日一次还可以设计按工作日触发的表达式比如只跑周一到周五。如果情报的时效性要求高比如监控某个竞品官网公告可以缩短到每小时一次。但频率越高触发次数和资源消耗也越高建议根据实际需求设置不要一味求快——对多数信息源一天一次已经够用过于频繁反而会让群里推送变成噪音。2.4 变量和数据库去重与记忆的基础设施情报系统最容易被人忽视的是“去重”问题。定时任务每次执行都会把信源当前的文章列表拉一遍如果不做去重同一个链接会被推送很多次群里的体验会非常差。Coze 提供了两种能力来处理这类状态变量Variable和数据库Database。变量的粒度更轻适合保存“上一次已经处理过的 URL 列表”这种短期状态数据库适合保存完整的文章历史记录后面做检索和对话查询时很有用。我第一版采用的做法是用变量存一个数组记录最近一周处理过的 URL。每次工作流启动后先把当前拉到的文章列表和这个数组做对比已经存在就跳过只对新增内容做后续处理最后把新增的 URL 追加进数组并清理过期记录。逻辑不复杂但能真正解决重复推送的问题这个节点建议放在采集层之后、大模型处理之前。3. 核心工作流搭建从空项目到第一份情报简报3.1 场景设定先选定一个你愿意长期看的方向为了演示我以“每日 AI 技术情报”为例。信源我选了这么几个InfoQ 中文站的 RSS、GitHub Trending 的公开 API、某个行业媒体邮件订阅的 RSS 转地址以及内部知识库中的竞品技术文档页面。选择标准是“内容质量稳定 有结构化出口”这两个条件至少要满足一个否则后续解析会非常痛苦。如果你做的是专利相关工作可以把信源替换为专利检索平台的公开检索结果页或 RSS如果你关注竞品动态可以换成竞品官网公告页、官方公众号的 RSS 化服务。信源可以随行业变化关键是你得清楚“目标信息长什么样”这样才能在后面写提示词时定义好什么该留、什么该丢。3.2 分步搭建工作流按“输入-处理-输出”串起来在 Coze 控制台新建工作流后默认会有一个“开始节点”。我往里添加的第一个节点是插件节点选择 RSS 插件填入信源地址。这里建议把需要订阅的信源并列配置成多个采集节点而不是理想化地“一个节点抓所有”。采集节点拿到原始数据后接一个 Code 节点做字段统一和 URL 去重。Code 节点的作用很关键它把不同信源的字段名比如有的叫 title有的叫 name统一成title、url、summary、source、published_at这几个字段再和变量里保存的历史 URL 做比对输出一份过滤后的待处理列表。我写的一个轻量去重逻辑模板大致是这个思路async function main({ historyUrls, newItems }) { const seen new Set(historyUrls || []); const unique []; for (const item of newItems) { if (!item.url || seen.has(item.url)) continue; seen.add(item.url); unique.push(item); } return { uniqueItems: unique, latestSeen: Array.from(seen).slice(-200) }; }这段 JavaScript 的作用是用 Set 记录已出现过的 URL遍历新文章列表过滤掉重复项最后返回新的去重列表和更新后的历史数组。注意我做了slice(-200)限制长度避免变量无限膨胀。清洗后的数据流转到下一个节点如果只需要做简报可以直接接大模型节点如果希望后续能对话查询建议同时把结构化数据写入数据库表字段就是上面统一的五个字段。3.3 提示词是灵魂模板可以直接抄大模型节点是整条流水线的大脑提示词写得好不好直接决定推送内容质量。第一版我写过很多泛泛的提示词比如“请总结以下内容”结果模型把每篇文章都总结了一遍群里的消息又臭又长根本没人点开。后来改成了强约束的结构化输出效果好很多。我现在的模板大致是你是一名资深情报分析师。请从给定的文章列表中筛选出与目标领域强相关且对决策有参考价值的内容。 筛选规则 - 排除纯产品介绍、软文、与目标领域无关的泛行业内容。 - 优先保留新技术发布、开源项目重大更新、行业报告、竞品动态、重要论文或专利公开。 - 如果一篇文章信息量低直接丢弃宁缺毋滥。 输出要求 - 用中文输出格式为 Markdown 有序列表。 - 每条包含标题、来源、一句话摘要不超过50字、为什么值得关注不超过40字、原文链接。 - 输出前按重要性从高到低排序最多输出8条。 - 如果过滤后没有值得关注的内容只输出“今日暂无重点情报”。这段提示词的关键在于“筛选规则 输出要求 兜底输出”。筛选规则帮模型建立判断标准输出要求保证结果结构稳定兜底输出让空结果也能正常展示避免推送一条空消息。大模型节点里还有几个参数值得调整。模型选择方面我倾向于在成本和效果之间取平衡选平台提供的默认或主流型号即可temperature 建议调低放到 0.2 左右因为情报整理属于客观筛选任务不是创意写作随机性越低越好。部分平台支持输出格式预设可以选 JSON 或 Markdown选了之后模型会更严格地按格式来。3.4 推送节点把简报送进工作群生成结果后最后一步是推送。Coze 里可以添加一个 Webhook 节点把你的群机器人地址填进去把上游生成的内容作为请求体的文本字段发送。不同平台的群机器人配置方式不太一样但核心步骤大同小异在群里添加自定义机器人拿到 Webhook 地址如果平台要求加签把签名密钥填到节点配置里。第一次配置后建议先用一个极简的测试文本“这是一条测试消息”跑通节点确认消息能出现在群里再去接真实的数据流。这样做的好处是一旦最终推送有问题你至少能确认是内容生成的问题还是 Webhook 配置的问题。全部节点串联起来后保存并发布工作流。发布前记得设置好定时触发器我设的是每天早上九点执行一次。发布之后不要干等手动点一次“试运行”按钮完整跑一遍流程然后打开运行日志看每一步的输出插件有没有返回数据、Code 节点是否正常过滤、大模型输出是否符合格式、Webhook 有没有报错。第一次调试几乎不可能一次通过但日志会非常清楚地告诉你是哪一步出了问题。4. 进阶让情报助手真正“可对话、可复用”4.1 从“单向推送”升级成“可追问的 Agent”定时推送解决的是“每天按时给你一份简报”的需求。但情报工作中难免有临时追问某个事件具体什么背景上周有没有相关报道这个功能靠静态推送是满足不了的需要把助手升级成一个真正的智能体也就是 Coze 里的 Bot。创建 Bot 时关键是把前面搭好的工作流、知识库和数据库关联进去。这样 Bot 既拥有定时推送的能力又能在对话场景下直接查历史数据。在 Bot 的人设和回复逻辑里我会明确告诉模型这是一位情报助手回答时必须基于已采集的数据不能凭空编造如果用户问的事情没有采集过直接说明“数据库里没有相关记录”而不是硬编一个答案。这一步其实是很多 AI Agent 项目容易踩坑的地方模型看到陌生问题倾向于用通用知识来“圆场”结果就产生幻觉信息。轻量的对抗方法就是在提示词里先声明“数据边界”你能知道什么、不能知道什么判断不了就说不确定。4.2 用对话流实现动态查询如果要支持“按关键词查历史情报”可以再创建一个对话流。对话流和工作流最大的差别是工作流适合批量、定时执行对话流适合由用户输入触发按需返回结果。举个实际的例子用户在群里问“最近三天有没有关于大模型推理优化的文章”。对话流的处理过程是先从用户输入中提取“最近三天”和“大模型推理优化”这两个关键参数用参数去数据库表里查询筛选发布时间在时间范围内、且标题或摘要中包含关键词的记录最后把查询结果交给大模型整理成一段精炼的回答返回给用户。数据库查询这一步看起来很复杂但在 Coze 里其实就是添加一个数据库查询节点配置好表名和过滤条件就行。整体上对话流让助手具备了“主动服务”的能力而不是每天早上机械地推一条消息。4.3 输出 Markdown 文件再转 Word变成周报素材不少用户搜索过“markdown转word工作流coze”这背后其实是一个很实在的需求情报汇总之后最终要落到文档里周报、月报、专利交底材料都需要 Word 格式。Coze 工作流可以在生成内容后通过文件处理或文档转换插件把 Markdown 转为 Word。我的做法是在大模型节点输出结果时除了推送群消息同时把简报保存为 Markdown 文本内容然后在文件处理节点里指定输出格式为 Word生成.docx文件再通过插件发送到指定位置或直接作为消息附件推送到群里。这里有个细节生成的文件名最好带上日期比如AI情报简报-2026-01-16.docx不然每次都被同名文件覆盖。文件存放如果需要长期保留建议关联到云盘或数据库的文件字段不要只存在运行记录里否则时间一长就会不好找。4.4 情报源怎么持续优化信息源是整个系统的输入质量源头。只配一次信源就一劳永逸是不现实的持续优化是个常态。我自己的维护节奏是一个月过一次信源清单跑了一个月发现某个源从没产出过一条有效推送就换掉发现某个源被频繁点击率高就考虑把它放到优先采集的位置。不同行业适合的情报源形态也不一样。做技术趋势跟踪可以关注 arXiv 的公开接口和 GitHub Trending做竞品分析更依赖官网公告和招聘页面招聘信息的变动往往能反映产品方向调整做行业观察可以接行业媒体和协会网站的 RSS。如果你是做专利辅助工作还可以把公开专利检索平台的 URL 模板接进来每次运行按关键词组合生成检索地址再把结果页的关键字段抽取出来入库。另外要注意采集频率的确定性。部分网站有反爬策略和 robots 协议限制用 RSS 通常最稳妥因为它本身就是站点愿意提供的内容分发方式。如果某个站点只能用网页解析建议降低抓取频率控制抓取深度只取列表页而不是深挖每篇正文这样对你的信誉和对方的服务器压力都好。5. 常见问题与排查技巧实录5.1 定时任务不执行或者时间不对这是最常遇到也最让人头疼的问题。排查思路分两步先看 Cron 表达式再看时区设定。你可以先在平台给出的“下次执行时间”处确认比如你心里预期是北京时间早上九点如果预览显示的是凌晨一点那基本就是时区差。解决办法是按平台要求的时区重写表达式绝大多数情况下克制的做法是换算成 UTC 或用平台 UI 里自带的时间选择器不要自己凭感觉写 Cron。还有一种可能任务确实执行了但运行日志里报错只是你没收到推送。所以排查时一定要打开执行记录看工作流到底有没有被触发触发后第一步有没有执行成功。信息可能滞后但日志不会撒谎。5.2 插件抓取不到内容或者返回空定位方法很简单单独运行采集节点看返回里有没有数据、报错信息是什么。实际中常见的原因有三种目标站点改版导致解析规则失效站点有登录或反爬限制公开抓取拿不到完整内容目标站点内容靠 JavaScript 动态渲染普通 HTTP 请求拿不到渲染后的页面。应对方式按优先级排列优先看看这个站点有没有提供 RSS有就直接换 RSS没有 RSS就看有没有公开 API比如很多平台的数据接口是半公开的直接请求 JSON 比解析 HTML 稳定得多都没有再考虑用搜索插件按域名搜间接获取最新页面链接。真要解析动态页面也可以在 Code 节点手动配置带 UA 的请求头试试但成功率取决于对方站点的防护强度。5.3 重复推送刷屏群里全是同样的链接这是没做去重或去重逻辑失效导致的。检查顺序先看变量里有没有正确初始化和写入再看删重逻辑是否放在所有采集节点合并之后、大模型处理之前。失败的原因大概率是第一次调试时没有初始化 Time 节点或者把去重逻辑放在大模型节点后面——模型已经生成了内容再过滤也无济于事。另外注意去重变量本身有容量上限。如果保存的历史 URL 太多超过了变量限制超出部分会被丢弃等于旧链接会再次被当作新链接处理。所以我在前面模板里加了slice(-200)就是控制历史记录在合理的窗口期内既足够完成短周期去重又不会撑爆变量。5.4 大模型输出格式不稳定时而是表格时而是大段文字输出的稳定性直接取决于提示词的约束力度和模型的 temperature 参数。我遇到过两种情况一是提示词里没有明确指定输出结构结果模型自由发挥二是 temperature 默认值偏高模型在每次生成时都出现微小差别累积起来格式就乱了。解决方案是三层加固提示词里给出明确的输出格式示例比如“输出必须是一个 Markdown 有序列表每条包含标题、来源、摘要、链接四个字段”在模型节点里把响应格式预设调整为 JSON 或 Markdown最后把 temperature 降到 0.2 附近。如果这样还不稳就在大模型节点之后再接一个 Code 节点用正则或简单字符串处理再校正一遍。5.5 推送没到达群里或者频繁被限流推送没到多数是 Webhook 配置问题地址填错、加签方式不对、消息内容体格式和平台要求不匹配。先单独跑一次测试再跟着运行日志看实际请求的响应内容。如果地址和签名都没问题那就可能是同一条消息被频繁触发触发了群机器人的频率限制。群里推送建议合并成一条消息发出去而不是一个标题发一条既清爽又不容易被系统拦截。5.6 别忘了合规底线这一点非常重要。自动采集虽然省事但你要注意尊重目标网站的数据获取规则。优先用 RSS 和公开 API 这些站点主动提供的方式抓取频率控制好不要对目标服务器造成压力。内容分发时简报里给出摘要和原文链接不直接搬运全文。涉及未公开数据、个人隐私、受版权保护内容不要碰也不要用于商业违法违规用途。自动化只是工具使用工具的责任还是在自己手上。我在实际搭建和使用的这两个月里最大的体会是不要一开始就追求大而全。第一版哪怕只盯一个信源、每天推一份三到五条内容的简报能坚持读下来也比那种全自动但没人看的“信息轰炸”强得多。后来我甚至把推送分成了两段早上九点一份核心速报下午四点一份“值得深读”的链接合集群里点开率反而高了不少。提示词方面也别指望一次写到位。我前后改了七八版每一次改动都是因为实际推送给我的内容里出现了“毫无价值的推荐”和“错过的重点”。花在搭结构上的时间其实很少真正花时间的是教会模型“什么值得看”——这才是这套系统的灵魂所在。最后再分享一个小经验所有自动化工具都会有偶尔失灵的时候不要完全把判断力外包给模型。定时任务跑出来你要快速扫一眼觉得当天内容不对劲就立刻看运行日志。情报系统的价值不是输出多少字而是命中多少真正重要的东西这一点模型负责过滤你负责做最终决策。