你有没有算过，每天早上为了整理行业动态要花多少时间？我以前雷打不动地刷十多个信息源，再把觉得重要的链接手工粘进共享文档，折腾下来大半个早上就没了。后来我用 FastGPT 搭了个自动化流程：系统定时任务每天早上触发 AI 工作流，自动采集新闻、生成日报，再推到企业微信和邮箱，实测跑了小半年，累计稳定发送 180 多份日报，几乎没有断档。这篇文章就把整套方案的架构、配置、踩坑过程完整写出来，给想用 FastGPT 做定时任务自动化、又不想把时间耗在重复手工操作上的人做个参考。
1. 先想清楚再动手：日报自动化的整体架构怎么搭
很多人一听说"用 AI 生成日报"，第一反应是打开大模型网页版把链接粘贴进去让它总结。这条路单独用几次没问题，但要一天不落、每天 8 点准时产出，纯手动一定坚持不了两周。所以核心不是"AI 能不能生成日报"，而是"定时触发"和"主动推送"这两个环节谁来管。
1.1 为什么选 FastGPT 而不是裸 API 调用
我最早是用 Python 脚本直接调大模型 API 来生成日报。优点是最少依赖，一个脚本加一个 crontab 就能跑；缺点是每次调整提示词都要改代码，日报里如果要用自己积累的行业知识，还得自己在脚本里拼上下文，越往后越难维护。后来我把 FastGPT 接进去，相当于把"AI 应用"和"调度脚本"拆开了，改日报模板只需要在 FastGPT 工作台里改工作流和提示词，调度脚本完全不动。
| 维度 | 裸 API + 自研脚本 | FastGPT 工作流 |
|---|---|---|
| 提示词维护 | 改代码，重发脚本 | 可视化编辑，即时生效 |
| 知识库接入 | 自己写检索逻辑 | 内置知识库节点，直接关联 |
| 会话/上下文管理 | 自己维护状态 | 工作流节点自动管理 |
| 团队协作 | 代码仓库 | 团队空间/应用市场 |
| 失败处理 | 完全自己写 | 多节点组合实现 |
我个人的建议是：如果只是给自己用、日报内容也不需要知识库，直接用脚本调用 API 更轻量；但如果你想做成团队基础设施、让非技术人员也能调整 AI 行为，FastGPT 这类平台是更划算的投入。
1.2 日报流程的四个环节
日报自动化表面上是一个"定时任务"，实际拆开是四个环节：定时触发、数据采集、内容生成、结果推送。任何一个环节断掉，日报都不会按时出现。
定时触发器（系统 Cron） ↓ 调用 FastGPT 应用 API FastGPT 工作流：数据采集 → 知识库检索 → LLM 生成日报 → 输出文本 ↓ POST / SMTP 企业微信 / 钉钉 / 邮件在定时触发环节，我用的就是系统 crontab，因为它是所有方案里最不容易出问题、也最容易排查的。数据采集环节放在 FastGPT 工作流内部，用 HTTP 请求节点去抓 RSS 和公开信息源；如果你想要的数据有反爬或者需要复杂登录，我建议写一个独立采集脚本，把结果写进知识库或数据库，再由工作流节点读取，不要把所有压力都压在工作流里。
内容生成是 FastGPT 的强项，用 AI 对话节点配合提示词模板完成。最后的推送环节，可以完全放在工作流里用 HTTP 节点实现，也可以在外部脚本里推。我的经验是：一开始先把推送放在工作流里，一条链路从触发到交付全部打通，确认每天都稳定出报之后，再把重试、多通道推送这类复杂逻辑挪到外部脚本。
2. FastGPT 部署与日报工作流核心配置
要跑通整个流程，第一件事是把 FastGPT 环境准备好。
2.1 本地化部署：Docker 一键启动与模型接入
FastGPT 官方推荐用 Docker Compose 跑一套完整环境。我自己的服务器是 4C8G 的 Linux 机器，单机部署 FastGPT 主服务、MongoDB、向量数据库这些组件，跑一个个人日报应用绰绰有余；如果团队并发量高，再把数据库单独拆出去。
本地化部署的好处，一是数据完全在自己的服务器上，涉及内部知识库时更放心；二是可以自由接入各种模型渠道，不受某个 SaaS 平台的绑定。部署的常规步骤是：从 GitHub 拉取 FastGPT 项目，复制一份 .env 环境变量文件，在环境变量里填写大模型 API 的 Key 和地址，然后用 Docker Compose 一键拉起。等容器日志显示服务启动完成后，访问 3000 端口进入控制台，创建应用。
这里有一个新手的常见误区：FastGPT 本身不内置大模型，它只是一个"AI 应用编排器"，模型能力需要你提前配置好某个模型供应商的 API。日报场景对模型要求不高，只要上下文长度够、中文输出稳定就行，不需要一上来就追最强最大的模型。
2.2 工作流里的核心节点怎么编排
进入 FastGPT 控制台，新建应用时选择"工作流"模式，你会看到画布上有多种节点。做日报我实际用到的是这几种：
- 数据采集节点：一般用 HTTP 请求节点，定时去抓取 RSS 或信息源接口，把返回内容作为后续节点的输入。
- 知识库检索节点：连接已经建好的知识库，检索和你行业相关的背景资料。这一步决定了日报是"纯新闻复读"还是"有观点的分析"。
- AI 对话节点：核心节点，把采集到的数据和检索结果一起放进提示词，让模型按模板输出日报。
- 文本拼接/代码执行节点：对生成内容做二次格式化，比如把 Markdown 标题补全、去掉多余空行。
- HTTP 请求节点：把最终日报 POST 到企业微信或钉钉的 Webhook。
- 文本输出节点：把结果返回给 API 调用方。
整个工作流的顺序大体是：HTTP 请求节点拿原始信息 → 知识库检索节点拿长期知识 → 拼进 AI 对话节点 → 输出到文本拼接节点 → 再通过 HTTP 请求节点推送。我第一次搭建时总想把所有事情放在一个节点里完成，这是不对的，每个节点只做一件事，后续排查和修改才能精准定位。
另外，FastGPT 工作流支持逐步调试。我习惯先把每个节点手动跑一遍，确认返回结构符合预期，再串联整条流。尤其是 HTTP 请求节点，返回的字段名差一个字母，后面拼提示词时就可能整段空白，这种低级错误在工作流里很常见。
3. 定时触发：Cron 表达式与三种调度方案
日报要求"每天早上 8 点"，落到调度系统里就一句话：cron 表达式。
3.1 每天 8 点的 Cron 表达式，拆开给你看
Cron 表达式有五个字段，顺序是分、时、日、月、周。每天 8 点整的表达式写出来是：
0 8 * * *拆开看：分是 0，小时是 8，日、月、周都是通配符*，含义就是"时钟走到 8 点 0 分、无论日期星期几，都执行"。
工作中常用到的还有这么几个变体：
| 表达式 | 含义 |
|---|---|
0 8 * * 1-5 | 工作日（周一至周五）早晨 8 点 |
30 8 * * * | 每天 8:30 |
0 9 * * MON | 每周一 9 点 |
*/10 * * * * | 每 10 分钟一次 |
0 2 * * * | 每天凌晨 2 点（适合做数据备份） |
如果你用 Linux 的 crontab，内容可以直接写：
0 8 * * * /usr/bin/python3 /opt/daily-report/run.py >> /var/log/daily-report.log 2>&1注意脚本路径最好用绝对路径，日志也要单独存一份，后面排查问题时没有日志寸步难行。
3.2 Linux Cron、Windows 计划任务、云函数定时触发器怎么选
定时调用 FastGPT 的方式，我实际用下来有三类可选：
- Linux 系统 crontab：最直接，一个文件搞定，谁都能查，只要服务器不宕机，执行很可靠。
- 云函数定时触发器：不用维护服务器，但调试不如本地方便，冷启动偶尔会造成几十秒延迟。
- Jenkins 等 CI/CD 工具的定时构建：适合已经上了 Jenkins 的团队，可以把"生成日报"当成一个流水线任务来管，还顺带保留历史构建记录。
如果没有特殊原因，我个人推荐第一类，也就是单纯在服务器上配 crontab。原因很简单：定时任务这种场景，"稳"比"炫"重要。crontab 已经存在几十年，语法简单、行为明确，所有服务器运维人员都能接管。你是在给自己搭一个每天都依赖的基础设施，选最朴素可靠的方案，别引入没必要的外部依赖。
3.3 最容易出错的时区与错峰问题
这是我实际踩过的坑，专门拿出来说。第一次配置时，我在 crontab 里写了0 8 * * *，结果日报中午 12 点才到。排查半天，发现是服务器的系统时区是 UTC，它执行的 8 点其实是北京时间下午 4 点，而我中午看到的那封其实是凌晨跑的另一个测试任务。
解决办法是先统一时区：
timedatectl set-timezone Asia/Shanghai同时给 crontab 带上环境变量也可以，但直接改系统时区是一劳永逸的做法。
另一个经验是错峰：如果你的 FastGPT 是多人共用的，或者模型 API 有并发限制，没必要把时间钉死在 8:00:00。我把定时任务设在 8:05，也就是5 8 * * *，这样既满足"早上到公司能看见"，又避免和整点报时类任务挤在同一个时间窗口。
4. 让日报"可读"而不是"流水账"：提示词与数据源设计
定时触发解决了"准时"的问题，但真正决定日报价值的，是 AI 生成内容的质量。很多人的 AI 日报不好看，问题不出在模型，而出在提示词和数据源。
4.1 一套可以直接抄的提示词模板
行业日报最常见的死法，是生成结果像"新闻标题列表"。为了避免这个，我给日报设定了三个结构块：今日要闻、值得关注的数据、我的看法。同时明确要求只使用给定信息源，禁止编造。模板如下：
你是我的行业情报分析师。下面是今天采集到的原始信息： {{rss_results}} 请在严格依据上述信息的前提下，按以下格式生成日报： ## 今日要闻（3-5 条） 每条包含： - 标题 - 来源 - 一句话摘要 - 影响点评（不超过 30 字） ## 值得关注的数据 列出你发现的关键数据并说明其隐含趋势。 ## 我的看法 用 100 字总结今天值得重点跟进的一件事。 要求： 1. 禁止编造内容、来源和数据； 2. 语言直接、口语化，避免标题党； 3. 全文字数控制在 800 字以内。这个模板的核心逻辑是：把"摘要+影响分析"拆成两个动作，避免 AI 只输出标题复读。你在 FastGPT 工作流里，把{{rss_results}}替换成上一个节点传来的实际数据就行。如果日报是给团队看的，我会建议增加一条"对团队的影响"字段，让日报从"新闻汇编"变成"工作指引"。
提示词的迭代也要像代码一样有版本感。我一般先在 FastGPT 应用页手动跑几次，看输出有没有幻觉、结构是否稳定；改提示词时，不要推翻重写，而是逐条增加约束，因为一次性改动太多你很难判断是哪条规则真正起了作用。
4.2 数据源接入与知识库的配合
采集环节决定日报的天花板。如果你喂给模型的信息只有三五个过时链接，提示词写得再漂亮也出不了好内容。我目前的做法是两条腿走路：RSS 直接抓 + 知识库补背景。
RSS 抓取用工作流里的 HTTP 请求节点就能实现，请求返回的 XML 先经过代码节点解析成纯文本，再把纯文本塞给 AI 对话节点。一个需要注意的细节是：RSS 源要定期维护，很多小网站写着写着就断更了。建议在采集节点后加一个判断，如果返回内容为空，直接跳过这个源，不要让它把"空数据"喂给模型。
知识库在日报场景里容易被忽略。日报不只是今天有什么新闻，更要紧的是"这条新闻对谁有什么影响"。我把过去半年的行业报告、政策解读、竞品动态都整理进了 FastGPT 知识库，工作流里用检索节点取得相关段落，再和当天新闻一起交给大模型。这样生成的日报就有了记忆：它能写出"这条政策和上个月那次调整一脉相承"这种话，而不是孤立地复述新闻。
当然，知识库检索也有坑：检索结果太杂会把日报带偏。我的实践经验是限制检索返回条数，只取 3-5 条最相关的内容，并且在提示词中明确"知识库内容只作为背景参考，不作为当日信息主体"。
5. 推送落地：企业微信/钉钉 Webhook 与邮件发送
日报生成出来，最后一步是把它送到该出现的地方。
5.1 Webhook 推送的通用套路
企业微信群机器人、钉钉群机器人、飞书自定义机器人，它们的 Webhook 推送方式大同小异：往一个 URL 发 POST 请求，body 是固定格式的 JSON。比如企业微信机器人：
curl 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=这里填机器人的Key' \ -H 'Content-Type: application/json' \ -d '{ "msgtype": "markdown", "markdown": { "content": "# 7月12日 行业日报\n\n**今日要闻**\n\n> 1. 某某公司发布新政策" } }'钉钉机器人也是类似的 POST，body 里把msgtype换成markdown即可，不过钉钉自定义机器人有个安全限制：消息里必须包含你设置的关键词，否则会被拒绝。我第一次对接钉钉时就因为日报文本里没有触发关键词，推送一直失败，后来把日报标题固定加了一个"行业日报"关键词才算解决。
如果想把推送放到 FastGPT 工作流内部，只需要在 HTTP 请求节点里配置同样的 URL、请求头和请求体，把日报变量拼到 content 字段里。工作流内置推送的好处是，触发、生成、发送全在一个应用里管理，少一个外部脚本就少一个故障点。
5.2 邮件推送与多通道并行
有些场景不适合群机器人，比如日报要发给外部顾问、或者你想自己在邮箱里归档。邮件推送我通常用 Python 的 smtplib 实现，外层还是 cron 调用。关键代码很短：
import smtplib from email.mime.text import MIMEText msg = MIMEText(report, "html", "utf-8") msg["Subject"] = "今日行业日报" msg["From"] = sender msg["To"] = receiver with smtplib.SMTP_SSL("smtp.qq.com", 465) as server: server.login(sender, auth_code) server.sendmail(sender, [receiver], msg.as_string())有一点容易踩坑：这里的 password 不是邮箱登录密码，而是邮箱服务商生成的"授权码"。QQ 邮箱、163 邮箱都在设置里能找到生成入口，我第一次用真实密码登录直接被拒。
多通道并行也是常见需求：团队看企业微信、自己收邮件、领导可能在飞书。最省事的做法是在外部脚本里推多个 Webhook，或者在工作流里并列两个 HTTP 请求节点。我现在的配置是 FastGPT 工作流先把日报生成好，再通过两个 HTTP 请求节点分别推企业微信和邮件，邮件走的是自定义邮件服务封装好的接口，整体稳定后基本不用管。
6. 运行半年踩过的坑：完整排查链路
自动化流程最怕的不是搭建，而是某天它突然不干活了，你还不知道它死在哪一步。下面这几个排查场景，是我这半年真实遇到过的。
6.1 任务没触发，先查这三层
日报某天没按时出现，我的排查顺序永远是三层：先看定时任务有没有执行，再看脚本有没有报错，最后看 API 调用是否被拒绝。
第一层，用grep CRON /var/log/syslog看 crontab 是否真的发起了任务。我曾经遇到过服务器在凌晨因为系统更新自动重启，重启后 cron 服务没有正常拉起，导致任务静默失败。这属于"基础设施级"故障，日志里能看到 cron 进程异常，重启服务就能恢复。
第二层，看脚本日志。我的 crontab 里始终挂着>> /var/log/daily-report.log 2>&1，排查时tail -n 100看一眼，如果是 Python 语法错误、依赖缺失，日志会直接给出堆栈。没有日志的定时任务等于裸奔，强烈建议从一开始就把日志留好。
第三层，看 FastGPT 侧的应用日志。如果外部脚本请求返回 401 或者 4xx，多半是应用 Token 失效；如果是 5xx，大概率是大模型服务超时或工作流内部报错。FastGPT 的管理后台可以看到对话记录，把对应时间点的记录点开，能直接看到是哪一步节点出了问题。
6.2 日报内容重复、过时和编造
内容问题的排查往往比任务不触发更隐蔽。有段时间日报连续一周都在复述同一条旧消息，我一开始怀疑是 RSS 源坏了，后来发现是采集节点做了缓存，旧的 XML 一直没清理。解决办法是在代码节点里给每条新闻加时间戳过滤，超过 24 小时的内容直接丢弃。
编造问题也遇到过。模型在信息不足时喜欢"脑补"，尤其是让它总结"值得关注的数据"时，它可能会编出根本不存在的百分比。我的对策是双管齐下：提示词里把"禁止编造数据"这条规则放到最前面，同时在知识库检索节点后面加一个校验节点，没有命中数据就不允许输出具体数字。
6.3 频率限制、失败重试与告警
调度脚本本身写得再健康，也扛不住上游限流。企业微信机器人对单个机器人每分钟的消息频率有限制，虽然日报一天一次不会触发，但如果你后续做了"日报 + 午间摘要 + 晚间复盘"一日三推，就要考虑错开发送时间。
大模型 API 侧也会有并发和速率限制。我在外部脚本里给请求加了重试机制：捕获异常后等待 5 秒重试，最多 3 次，间隔逐步拉长到 10 秒、20 秒。实测这个策略能把绝大多数瞬时故障稀释掉，但重试次数也不能太多，否则故障时期反而会堆积请求。
另外建议增加失败告警：万一日报真的没发出去，至少要在运维群或者个人邮箱收到一条"今日日报发送失败"的通知。我的做法是在脚本末尾判断发送结果，失败时再调用一次企业微信机器人，发一条单独的告警消息。这样即使日报断了，人还醒着。
最后再分享一个小技巧
日报跑得越久，价值越体现在"历史沉淀"上。我现在除了每天早上推给团队，还会把每天生成的日报按日期存档到一个数据库表里，月底用脚本汇总成月度回顾。定时任务加 AI 工作流这套框架，一旦跑通，你很容易往里面加新东西：比如晚间版、只看重点版、针对某个客户的定制版。建议你先从"每天 8 点一份日报"这个最小闭环开始，跑稳了再一步步加复杂度。这个自动化的复利，比你想的要大得多。
