第三篇 · 进阶系统与 AI 员工
第 25 章 自动化工作流怎样保持可靠
把一条已经手动跑顺的流程，做成一个每天定时自动跑、出问题会停会告警、还能续跑的可靠任务——而不是"跑起来就不管了"。
贯穿案例：每天的选题聚合
这一章用一个做内容的经营者每天都要干的活贯穿始终：每天从好几个平台里，把当天值得写的选题捞出来。手动一个个翻，费时又容易漏。一个典型的需求长这样：
我做 AI 商业 / 获客方向的内容，帮我找今天值得写的选题。 来源： - 公众号近期爆款文章 - 全网热搜里的 AI 相关条目 - GitHub 今日热门 AI 项目 - 多引擎 AI 新闻聚合 - AI 热点追踪
手动跑一次，AI 员工会同时调这五个源，整合成一份当天的热点清单，供你快速筛。本章要解决的，是把这件"能跑一次"的事，变成"每天早上自动跑、还跑得住"。
自动运行不等于可靠
自动化只是减少你重复点击。它到底可不可靠，要看两件事：有没有在正确的时间用当前的资料，遇到缺口和冲突会不会停下来。跑得顺，不代表跑得对。
自动化前的三个门槛
不是所有任务都适合马上自动化。过了这三关再上：
- 同一套提示词已经手动跑过至少三次，输出的质量和格式基本稳定；
- 触发条件、输入来源、验收标准都清楚：什么时候跑、依赖哪些源、输出什么格式；
- 有 owner、有告警、有停用方法：出错谁处理，怎么临时停掉又不影响别的流程。
频繁改提示词、或者数据源还不稳的任务，先手动跑，别急着自动化。另外有几类动作，哪怕自动化了也默认保留人工确认：
生成底稿、整理提醒、汇总资料、准备草稿——这些做错了也容易改回来。
内容发布、客户发送、价格变更、合同生成、权限调整——一旦发出去就收不回。
在 WorkBuddy 里设成定时任务
手动确认过效果之后，在同一个对话框里直接说一句：
把这个任务设成自动化，每天早上 9:00 跑， 结果发到 [指定飞书群 / 邮件 / 企微通知]。
它会把当前的提示词和数据源配置存成定时任务，到点自动执行。你打开通知，直接开始筛选，不用每天手动触发。
把它设计成一台"状态机"
自动化不是"跑起来就行"。真实环境里，每次跑都可能撞上：某个源超时、当天没有相关热点、GitHub 被限流、推送目标连不上。所以要把任务拆成一个个状态，每个状态都有明确的"成功往哪走、失败往哪走"：
关键一条：部分源失败，不该把整个任务卡死——标记缺失后继续；推送失败，要保住已生成的结果并告警，别把内容弄丢。
数据源就绪检查
定时到点，不等于数据源就绪。每次开跑前，先挨个检查各源可不可用：
| 数据源 | 检查项 | 不可用时 |
|---|---|---|
| 公众号爆款搜索 | 搜索可达、返回非空 | 标记缺失，继续其他源 |
| 全网热搜榜 | 当日热搜列表可获取 | 标记缺失，继续其他源 |
| GitHub 热门 | API 未限流、热门列表正常 | 退避重试一次，再失败则标记缺失 |
| 多引擎搜索 | 搜索引擎可达 | 标记缺失，继续其他源 |
| AI 热点追踪 | 热点服务正常 | 标记缺失，继续其他源 |
五个源里至少三个正常，才输出清单；全挂了就进"阻塞"、推送告警、次日重来。
内容质量门禁
源可达，不代表内容有效。聚合完还要过一道筛：
- 相关性：真的属于你的方向吗（排掉泛科技噪音）；
- 时效性：是当天的吗（别把过期热点又推一遍）；
- 重复性：同一件事在多个源都出现，合并展示；
- 最低数量：有效条目少于 5 条，就当"今天热点不足"，在输出里标注。
于是每次跑完有三种质量状态：pass（正常输出）、warning（部分源缺失，在顶部说明）、blocked（有效条目不足，不推正文、只推说明）。
输出结构固定下来
聚合完，输出一份格式固定的清单，你才能扫一眼就判断，而不是每次重新理格式：
📋 AI 选题日报 — 2026-07-10 【今日概况】有效条目：18 条 | 来源：5/5 | 运行时间：09:02 🔥 高热度（适合快速蹭） 1. [模型名] 发布，[核心能力] — 来源：AI热点 + GitHub 热度：★★★★★ | 建议角度：功能测评 / 使用教程 📈 潜力方向（适合深度分析） 2. [话题] 引发讨论 — 来源：公众号 热度：★★★ | 建议角度：观点分析 / 案例拆解 ⚠️ 来源说明：热搜正常 | GitHub 正常 | 公众号正常 | 多引擎正常 | AI热点正常
— 上面的条数、时间、星级只是格式示意，不是实测数据。
推送目标与"不重复推"
每次的输出要推到固定位置。常见几种，各有注意点：
| 推送目标 | 适用 | 注意 |
|---|---|---|
| 飞书群消息 | 团队共享选题 | 记 message ID，避免重复推 |
| 个人飞书通知 | 自己用 | 同上 |
| 飞书文档（追加） | 留历史、方便回溯 | 每日一条按日期追加，不覆盖历史 |
| 邮件 | 跨平台通知 | 记发件 ID |
不重复推原则：如果某次因为推送失败而重试，别把已经推成功的又发一遍。每次跑生成一个唯一批次 ID（如 选题-2026-07-10），推成功就记状态，重试时跳过已完成的步骤。
超时和重试策略
| 失败类型 | 重试吗 | 策略 |
|---|---|---|
| 数据源超时 | 是 | 等 10 秒重试一次，再失败则标记缺失 |
| GitHub 被限流（429） | 是 | 按返回的等待时间退避，最多等 2 次 |
| 认证失效（401/403） | 否 | 转人工处理，不自动重试 |
| 推送目标连不上 | 是 | 指数退避重试 2 次，失败则告警并保留结果 |
| 聚合结果为空 | 否 | 进"阻塞"，推说明，次日重来 |
重试只针对临时性故障；输入错了、配置错了，不该靠重试硬撞。
断点续跑
每次跑生成一个状态文件，记下已经完成到哪一步、产出了什么：
{
"批次": "选题-2026-07-10",
"触发时间": "09:00",
"当前状态": "推送中",
"已完成": ["抓取", "聚合", "筛选"],
"各源状态": { "公众号":"ok","热搜":"ok","GitHub":"ok","多引擎":"ok","AI热点":"ok" },
"有效条目": 18,
"最后错误": null
}
推送失败后重试，从"推送中"这一步接着跑，不重新抓取和聚合。
告警要"可行动"
任务失败时，告警里得有足够信息，让收到的人立刻知道怎么办——"任务失败，请查看"这种没用：
⚠️ 选题任务告警 批次：选题-2026-07-10 ｜ 状态：阻塞 ｜ 触发：09:00 失败原因：所有数据源均返回空或超时 影响：今日清单未生成、未推送 建议处理： 1. 检查各数据源状态 2. 若是临时故障，手动触发一次重跑 3. 若今天跳过，确认后标记已处理 恢复入口：自动化任务 → 手动运行
降级交付
部分源挂了，不该干等全部就绪再输出，而是按可用数量降级，并显式标清楚：
- 3 个及以上源正常 → 输出清单，顶部标注哪些源缺失；
- 2 个源正常 → 输出简化清单，标注"数据不完整"；
- 1 个或 0 个正常 → 不输出正文，只推说明和告警。
降级结果必须显式标记来源覆盖情况，不能伪装成一次完整运行。
日志：记什么、不记什么
每次跑，记这几项，方便回头排错和看趋势：
- 批次 ID、触发方式（定时 / 手动）；
- 各源的响应状态和耗时；
- 聚合条数、筛选后条数；
- 推送目标和结果（成功 / 失败 / message ID）；
- 总耗时、错误信息、这次的运行成本。
日志不记热点正文（避免越滚越大）。
给它设个成本预算
自动跑的东西，成本主要来自这几块：调用次数、外部 API 调用、模型推理、推送服务。
| 成本项 | 说明 |
|---|---|
| 调用次数 | 每次跑要调几个源，按平台计费规则算 |
| 外部 API | GitHub、热搜等数据源的调用费 |
| 模型推理 | 聚合和筛选阶段的推理 |
| 推送服务 | 飞书等推送接口的调用 |
设个预算上限：单次超过就记告警、这次照跑完，但下次跑之前要人确认。
把它写成一张"任务定义卡"
把整条自动化任务，落成一张说清楚的定义卡，交接、排错、复用都靠它：
任务名称：AI 选题日报
触发方式：每天 09:00（工作日）
触发条件：无前置检查，定时直接跑
提示词：[完整提示词文本]
数据源：公众号 / 热搜 / GitHub / 多引擎 / AI热点
质量门禁：有效条目 ≥ 5；可用源 ≥ 3
输出格式：结构化清单（含来源、热度、建议角度）
推送目标：[飞书群 / 个人通知 / 飞书文档追加]
不重复推：批次 ID = 选题-{日期}，推成功后标记
重试策略：源超时重试 1 次；推送失败退避 2 次；其他转人工
告警接收：[个人飞书通知]
owner：[你本人]
停用方式：自动化任务管理页 → 暂停
上线前先演练几种"出事"
正式开定时之前，手动模拟几种糟糕情况，确认它的反应跟你预期一致：
| 模拟场景 | 预期行为 |
|---|---|
| 所有源正常 | 输出完整清单，推送成功 |
| GitHub 被限流 | 退避重试，仍失败则标记缺失、继续其他源 |
| 当天没有相关热点 | 有效条目不足，输出说明，不推空清单 |
| 推送目标连不上 | 重试 2 次，失败则告警并保留结果 |
| 手动和定时同时触发 | 检测批次 ID，跳过重复执行 |
都演练通过了，再开定时。
稳定后要盯的运行指标
- 按时触发率：9:00 是不是准时触发；
- 一次成功率：不用重试就成功的比例；
- 各源可用率：每个源单独的可用比例；
- 有效条目趋势：热点信息量的波动；
- 推送成功率 和 单次运行成本 的趋势。
某个指标持续下滑，就去查对应的源或推送配置是不是变了。
从"个人自动化"到"团队服务"
个人任务跑稳了，可以扩成团队共享——但要补几样东西：
| 维度 | 个人使用 | 团队服务 |
|---|---|---|
| 推送目标 | 个人通知 | 团队飞书群 |
| 选题方向 | 单一方向 | 多方向分类推送 |
| 审核流程 | 个人判断 | 主编确认后分发 |
| 故障处理 | 自己处理 | 有 owner 和备份处理人 |
上线不是终点，要持续迭代
任务上线后，按真实使用反馈接着调：
- 提示词：看哪类条目真被你采用、哪类被忽略，调整筛选维度；
- 数据源：某个源长期质量差 / 可用率低，就换掉或降权重；
- 输出格式：按你的筛选习惯改（比如加"本周已覆盖"标记，避免重复选题）；
- 触发时间：按你的作息挪（比如改 8:30 或 10:00）。
每次改动都走"改 → 手动验证三次 → 重新保存"，别直接在定时任务上做实验。
完成检查
- 这条流程手动至少跑顺过三次，输出稳定；
- 设计成了状态机：每个状态都有成功条件和失败出口；
- 做了数据源就绪检查 + 内容质量门禁（pass / warning / blocked）；
- 有批次 ID 防重复、有断点续跑、有可行动的告警；
- 高风险动作仍然人工确认；
- 写了任务定义卡，上线前演练过几种"出事"场景。