第 25 章 自动化工作流的可靠性：从跑起来到靠得住

第三篇 进阶篇：把案例变成自己的工作系统 · 更新于 2026-10-20 · 作者：BuddyMe Editorial Team

一个自动化任务跑一次成功不难，难的是每天早上九点它都在——不迟到、不重复、不罢工，出状况时还知道该怎么体面地降级。

本章以「每日 AI 热点选题聚合」为贯穿案例，说明自动化工作流从手动运行到定时可靠执行之间，需要处理的所有问题：门槛、状态机、数据源检查、质量门禁、推送幂等、超时重试、断点续跑、告警与降级。

前面 28 章讲的都是「用 buddyme 干具体活」，这一章往后退一步，回答两个更根本的问题：它凭什么好用，以及怎么用才一直好用。搞懂原理不是为了当工程师，而是为了在它跑偏的时候你知道为什么、在它费点数的时候你知道省在哪里。

• 大模型是怎么「思考」的——Token、上下文窗口、温度与采样，决定了它为什么有时聪明有时糊涂；
• 指令五要素与迭代追问——同一件事，说法不同，产出质量差一倍；
• 模型为什么跑偏——问题分四类，每类有一套对应的纠偏方法；
• 技能与 Agent 的运行机制——理解了它怎么干活，你才能让它替你设计活儿；
• 自动化工作流与成本控制——让定时任务靠得住，让每一分点数花在刀刃上。

不需要任何编程基础，每一节都从「这对你用 buddyme 意味着什么」讲起。读完这一章，你再看前面 28 章的很多操作，会有「原来如此」的感觉。

新手第一步：15分钟搭一个每日选题自动化

这一节是本章的「傻瓜版」——不涉及状态机、幂等这些概念，只用 15 分钟，一步步搭出一个每天早上自动收选题的机器人。看完你会明白自动化到底是什么、怎么用，后面再读原理就不怕。

先想清楚：你要自动化的那件事长什么样

拿「每日选题」举例，它其实就三件事：

• 早上 9:00 自动去几个信息源逛一圈（微信爆款、GitHub 热点、AI 新闻）；
• 把看到的内容整理成一份选题清单；
• 把清单送到你手里（桌面通知 / 邮件 / 微信，选一个就行）。

核心原则：能自动化的不是「思考」，而是「搬运」——搜集、整理、投递这些不费脑子的重复动作交给 buddyme，你只做最后一步「挑哪个值得写」。

第 1 步：先手动跑通一次（别再幻想一步到位）

别一上来就设自动化。先把这件事手动运行一遍，确认结果是你想要的。打开 buddyme，新建任务，把下面这段直接复制进去：

你会看到：buddyme 依次访问几个信息源，整理出选题清单，存成文件。跑完检查清单内容：有没有你不需要的来源？格式方便看吗？——现在改，比设成自动化后改省事得多。

第 2 步：把「手动」变成「定时」（3 分钟）

手动跑通了，就该让它按时自己跑。进入任务的定时设置：

• 第 1 小步：在任务界面找到「定时运行」或「自动化」入口；
• 第 2 小步：选择触发时间——每天早上 9:00；
• 第 3 小步：告诉我「结果存哪」——沿用刚才的「今日选题.md」；
• 第 4 小步：保存，看到「已启用」的提示。

第 3 步：加一个「结果提示」（1 分钟）

自动跑完如果没人通知，等于白跑。在自动化任务里加一道投递：运行完把「今日选题.md」发给你的微信书签 / 桌面通知 / 邮箱，任选一个。这一步让结果真正「到你手里」。

第 4 步：验收清单（跑一次看三处）

• [ ] 到点了自己跑了吗——第二天 9 点后检查有没有新生成的今日选题.md；
• [ ] 内容还正常吗——没有报错、来源没失效；
• [ ] 通知收到了吗——你确实在手机/桌面看到了结果。

前三天多瞄一眼。自动化刚上线最容易在头几天露马脚（某个来源失效、格式变了），早发现早修，之后就能放手了。

常见误区（新手最容易踩的 3 个坑）

• 误区一：上来就想一步到位搞复杂自动化。纠正：先手动跑通 → 再定时 → 再加投递，一次只加一个环节，出了问题好定位。
• 误区二：设好就不管了。纠正：自动化不是「永动机」，前三天每天检查一次，稳定后再放宽。
• 误区三：把「思考」也交给自动化。纠正：自动化适合「搜集、整理、投递」这类确定性动作；「这篇选题值不值得写」这种判断，永远留给你自己。

为什么这套 15 分钟的流程，就是可靠自动化的雏形

手动跑通 = 确认任务本身没问题；定时 = 确认会在正确时间触发；投递 = 确认结果能到你手里。这三步其实已经埋下了后面章节讲的「数据源就绪检查」「推送目标与幂等」「告警」的种子——只是先不用那些词，先用起来。

下一节，再带你看懂这一套背后真正的工程问题。

案例背景：内容博主的每日选题任务

AI 内容领域更新极快，每天都要从多个信息源里筛出当日值得写的选题。手动逐一翻阅各平台，既耗时又容易遗漏。一个典型的 AI 博主选题需求如下：

我是一名 AI 领域的博主，主要内容方向是 AI 教程、AI 工具、AI Coding、AI 测评等。
帮我找今日的 AI 领域热点，方便筛选当天的选题内容。
来源：
- 微信公众号近期爆款文章（@wechat-article-search）
- GitHub 今日热门 AI 项目（@GitHub热门项目）
- 多引擎 AI 新闻聚合（@多引擎搜索）
- AI 热点追踪（@AIHOT）

手动运行一次这个任务，buddyme 会同时调用四个数据源，整合输出一份当日 AI 热点清单，供博主快速判断和筛选。

跑通一次后，下一步就是把它设为定时自动化任务：每天早上 9:00 自动运行，结果推送到指定位置，无需每天手动触发。

但"手动跑通"和"可靠地每天自动运行"之间，隔着一段不小的距离。手动运行时，你会盯着过程，数据源超时了你会重跑，结果不对你会换个说法再试；定时运行时，没有人盯着——任务得自己扛住各种小状况：某个来源临时挂了、当天恰好没有热点、推送的群被设置了免打扰。这些都不会每天发生，但自动化任务要跑几个月，就一定会遇到。

本章围绕这个场景，说明从"能用"到"可靠自动化"需要处理哪些问题。这些问题不是选题任务独有的——任何想交给 buddyme 定时运行的工作（日报、监控、周报、数据同步）都会遇到同一批。

自动化前的三个门槛

不是所有任务都适合立即自动化。自动化的本质是把"你盯着它跑"变成"它自己跑、出了事再叫你"——只有跑得稳定的任务，才配得上这份信任。判断标准是三道门槛：

1. 同一 Prompt 已手动运行至少三次，输出质量和格式基本稳定。三次是最低要求：第一次成功可能靠运气，第二次成功也许是巧合，第三次还成功，才算摸到了规律。若三次输出差异很大，说明 Prompt 本身还不够成熟；
2. 触发条件、输入来源和验收标准清楚：什么时候运行、依赖哪些数据源、输出什么格式——这三件事能一句话说清楚，不含"看情况"。说不清楚的部分，自动化只会把含糊固定下来，每天稳定地产出含糊的结果；
3. 有 owner、有告警、有停用方法：任务失败时谁处理（哪怕就是你自己），怎么知道它失败了（告警发到哪），如何临时停用而不影响其他流程。没有停用方法的自动化任务，出问题时会让你陷入"想关都来不及"的被动。

选题任务满足以上三点：Prompt 结构固定、每天早上 9:00 触发、输出内容为当日热点清单。

在 buddyme 中设置自动化任务

手动运行确认效果后，在同一对话框中直接告诉 buddyme：

把这个任务设置为自动化，每天早上 9:00 运行，
结果发送到 [指定飞书群 / 邮件 / 企微通知]。

buddyme 会将当前 Prompt 和数据源配置保存为定时任务，按设定时间自动执行。

设置完成后，每天早上 9:00，buddyme 自动调用四个数据源，整合结果并推送。博主打开通知即可开始筛选选题，不必手动触发。

把自动化任务设计成状态机

自动化不是让任务"跑起来就行"。真实环境中，每次运行都可能遇到：某个数据源返回超时、当日无 AI 相关条目、GitHub API 限流、推送目标不可达。

应对这些小状况的思路，是把任务设计成状态机：不是一条从起点到终点的直线，而是一组明确的状态——每个状态都有清楚的成功条件，也都有清楚的失败出口。任何一步出了状况，任务都知道自己现在在哪、该往哪去：

◉ → WaitingTrigger
WaitingTrigger —9:00 触发→ Fetching
Fetching —数据源全部响应→ Aggregating
Fetching —部分数据源超时→ PartialAggregating
Aggregating —聚合完成→ Filtering
PartialAggregating —超时来源标记缺失→ Filtering
Filtering —筛选完成，有有效条目→ Delivering
Filtering —所有来源均无有效 AI 内容→ Blocked
Delivering —推送成功→ Completed
Delivering —推送失败→ Blocked
Blocked —次日重新触发→ WaitingTrigger

关键原则：部分数据源失败不应阻断整体任务，而是标记缺失后继续聚合；推送失败应保留结果并告警，不丢失已生成的内容。

状态机的好处，要用一段时间才会真正显现：任务任何一次运行的结果，都能归入明确的状态之一。看到"PartialAggregating → Delivering"，就知道今天缺了来源但清单照常出了；看到"Delivering → Blocked"，就知道内容没问题、是推送挂了——排障时不必从头猜起，顺着状态走一遍，问题出在哪个环节一目了然。

数据源就绪检查

定时触发不等于数据源已就绪。9:00 准时开跑，可 GitHub 可能正在限流、微信搜索接口可能在抖动——任务若不假思索地开始聚合，拿到的是残缺的输入，产出的是一份看似正常、实则缺角的清单。

所以每次运行开始时，先花十几秒检查各数据源的可用性，就像出门前看一眼天气：

就绪检查的三条原则：

• 检查有超时：每个数据源的探测最多等几秒，就绪检查本身不能成为新的故障点——为了确认数据源可用而卡住两分钟，得不偿失；
• 失败是标记，不是中断：单个来源不可用就记下"今日缺失"，不阻断其他来源的抓取。整体是否继续，看下面的数量门槛；
• 数量门槛提前定：四个来源中至少有三个正常，才输出完整热点清单。全部失败时，进入 Blocked 状态并推送告警，次日重新触发。

把"至少三个"这个数字定下来很重要。不定，任务就会在"只剩两个来源，出还是不出"之间摇摆，今天出一份半成品清单、明天静默失败，行为不可预期。定了，它每天的行为就完全一致——这正是可靠性的含义。

内容质量门禁

数据源可达，不代表内容有效。接口返回 200，回来的可能是上周的旧闻、与 AI 无关的泛科技八卦，或四个来源转的同一条新闻。聚合之后，需要过一道质量门禁，把噪音挡在推送之前：

• 相关性：条目是否真正属于 AI 领域（排除泛科技话题的噪音）。判断标准写进 Prompt，比如"与模型、工具、框架、行业动态直接相关才保留"；
• 时效性：内容日期是否为当日（排除过期热点被重新推送）。热点的半衰期以小时计，昨天的消息今天推送，就是打扰；
• 重复性：同一事件是否已在多个来源出现，合并展示。四源同报一条新闻，说明它确实重要——但只该在清单里出现一次，并标注来源数；
• 最低数量：有效条目少于 5 条时，视为当日 AI 热点不足，在输出中标注。

质量状态分三档，每档对应不同的输出行为：

• pass（正常输出）：全部检查通过，输出完整清单；
• warning（部分来源缺失，在输出顶部说明）：清单照常推送，但让读的人知道数据不完整，判断时留个心眼；
• blocked（有效条目不足，不推送正文，只推送说明）：宁可不推，也不推一份"看起来正常"的空清单——空清单的害处在于，它会让人误以为今天真的没热点，从而错过该追的选题。

门禁的价值在于把判断标准前置：写一次规则，之后每一天都由它替你把关。没有门禁的自动化任务，等于把筛选噪音的活儿原样转嫁给了每天早上打开通知的你——那自动化的意义就少了一半。

输出结构：格式即体检

聚合完成后，输出一份结构固定的热点清单，方便博主快速扫描和判断：

📋 AI 热点选题日报 — 2026-07-10

【今日概况】
有效条目：18 条 | 来源：4/4 | 运行时间：09:02

━━━━━━━━━━━━━━━━
🔥 高热度（适合快速蹭热点）
1. [模型名称] 发布，[核心能力] — 来源：AIHOT + GitHub
   热度指数：★★★★★ | 建议角度：功能测评 / 使用教程

2. [工具名称] 开源，[功能描述] — 来源：GitHub热门项目
   热度指数：★★★★ | 建议角度：上手教程 / 对比测评

━━━━━━━━━━━━━━━━
📈 潜力方向（适合深度分析）
3. [话题] 引发讨论 — 来源：微信公众号
   热度指数：★★★ | 建议角度：观点分析 / 案例拆解

━━━━━━━━━━━━━━━━
⚠️ 数据来源说明
GitHub：正常 | 微信：正常 | 多引擎搜索：正常 | AIHOT：正常

输出格式固定后，博主 5 分钟内就能完成选题判断，而不必每次重新整理格式。

固定输出结构还有一个隐藏的好处：格式即健康检查。每天看到的清单结构完全一致，任何异常都会立即显眼——今天怎么没有"高热度"分区？来源说明里怎么冒出个"缺失"？人对固定格式的敏感度，远高于对自由文本的敏感度。结构稳定，异常才会被看见。

推送目标与幂等

每次运行的输出需要推送到固定位置。推送目标决定了信息到达谁、以什么形态到达：

幂等原则：某次任务若因推送失败而重试，不应重复发送已成功推送的内容。想象一下：推送超时，任务重试，群里收到两份清单；再超时，再重试，三份——团队成员很快就会把这个群静音，自动化辛辛苦苦攒下的信任，就这样耗尽了。

实现方式很朴素：

• 每次运行生成唯一批次 ID（如 ai-hotspot-2026-07-10，日期即天然键）；
• 推送成功后记录状态（推到了哪个群、message ID 是什么）；
• 重试时先检查状态，已完成的步骤直接跳过。

幂等不是什么高深的工程概念，说穿了就是一句话：同一个批次的事，做一次和做三次，结果应该一样。凡是"失败后会重试"的环节，都值得问一遍自己——如果这段被执行两次，会发生什么？答案是"群里有两条重复消息"，就还没做到幂等；答案是"第二次执行会发现已完成、直接跳过"，就稳了。

超时和重试策略

重试是自动化任务对抗临时故障的主要手段，但用错了地方会帮倒忙：对配置错误重试一百次，只会得到一百次同样的失败，还白白烧掉 Token。核心原则：只重试临时性故障，不重试确定性失败。

几条细节值得展开：

• 限流要看"对方怎么说"再等：429 响应里的 Retry-After 头写明了该等多久，照做就好。盲目立即重试等于火上浇油——限流就是因为请求太密；
• 退避要指数增长：推送失败后等 10 秒重试、再失败等 40 秒重试。间隔递增，既给对端恢复的时间，也避免自己陷入高频重试循环；
• 重试次数要封顶：任何失败类型的重试都有上限（本例均为 2 次）。到顶仍失败，就走告警或降级路径，不无限纠缠——重试是争取机会，不是死磕；
• 认证失效绝不能重试：401/403 意味着密钥过期或权限不对，这是配置问题，重试只会把失败日志刷爆。它需要的是人换一个新密钥，而不是机器再试一次。

判断某类失败该不该重试，有一个简单的二分法：再试一次，结果会不一样吗？会（网络抖动、临时限流、推送服务繁忙），重试；不会（密钥失效、参数错误、当天确实没有内容），别重试，走告警。

断点续跑：失败不从头再来

任务跑到一半失败，最不该发生的事是从头再来。抓取和聚合是整个流程里最耗时的部分，若推送环节挂了，重跑时把前面全部重做一遍，既浪费时间又多花一倍 Token。办法是每次运行生成一份状态文件，记录已完成的步骤和产物：

{
  "batch_id": "ai-hotspot-2026-07-10",
  "trigger_time": "2026-07-10T09:00:00+08:00",
  "state": "delivering",
  "completed": ["fetching", "aggregating", "filtering"],
  "source_status": {
    "wechat": "ok",
    "github": "ok",
    "multi_search": "ok",
    "aihot": "ok"
  },
  "item_count": 18,
  "last_error": null,
  "updated_at": "2026-07-10T09:02:14+08:00"
}

推送失败后重试，从 delivering 步骤继续，不重新抓取和聚合。

状态文件要拆开看三块信息：completed 数组说明哪些步骤不用重做（断点续跑的依据），source_status 保留了各来源的抓取结果（重试时不会因为某个来源恰好恢复而混入新旧不一的数据），state 标记当前卡在哪一步（排障的第一线索）。它和批次 ID 配合工作：重试先对批次 ID，再读状态文件，两道对上了才继续跑——这也是上一节幂等原则的落地。

告警要可行动：30秒内能出手

自动化任务失败时，告警内容必须包含足够信息，让收到告警的人能够立即判断如何处理：

⚠️ AI 热点选题任务告警

批次：ai-hotspot-2026-07-10
状态：Blocked
触发时间：09:00
失败原因：所有数据源均返回空结果或超时
已完成步骤：fetching（部分失败）
影响：今日热点清单未生成，未推送

建议处理：
1. 检查各数据源 API 状态
2. 如为临时故障，可手动触发一次任务重跑
3. 如需跳过今日，确认后标记为已处理

恢复入口：buddyme → 定时器 → ▶ 立即运行

"任务失败，请查看"这种告警，不足以让人处理。一条合格的告警要回答三个问题：发生了什么（状态与原因）、影响是什么（哪些人没收到什么）、我能做什么（处理建议与入口）。三问答全，收到的人 30 秒内就能出手；答不全，告警就会在"等我有空看看"中沉底，等想起来时，任务可能已经悄悄失败了两个星期。

告警的频度也值得克制：只在需要人出手时才响。数据源缺一个、走了降级交付的，可以在日报的"数据来源说明"里带一句，不必单独告警——告警报得太勤，人会麻木；麻木之后，真正要紧的那条也会被当成日常噪音划掉。

降级交付：残缺胜过缺席

部分数据源失败时，不必等全部就绪再输出。选题清单的价值随时间衰减——上午 9 点的热点清单是情报，下午 3 点的就成了旧闻。所以按可用来源的数量分档交付：

• 3 个及以上来源正常 → 输出清单，顶部标注哪些来源缺失；
• 2 个来源正常 → 输出简化清单，标注数据不完整；
• 1 个或 0 个来源正常 → 不输出正文，只推送说明和告警。

降级结果必须显式标记来源覆盖情况，不伪装成完整运行。这里的分寸很关键：降级交付的信任前提是"诚实"。一份顶部写着"今日微信来源缺失"的清单，读者会自动调低对社交平台热点部分的预期，它依然有用；一份缺了一个来源却装作完好的清单，短期省了一行说明，长期毁掉的是"看到这份清单就能信"的习惯。

分档数字（3 / 2 / 1）的意义在于让降级行为可预期：无论哪天出状况，任务的处理方式都一样。今天缺两个来源出简化版，明天缺两个来源也出简化版——稳定的行为模式，比任何单次的聪明决策都更让人放心。

日志：任务的黑匣子

自动化任务最怕的不是失败，而是"失败了却说不清为什么"。日志就是任务的黑匣子——平时没人看它，出事时，它是一切追问的答案。每次运行记录：

• 批次 ID 和触发方式（定时 / 手动）；
• 各数据源响应状态和耗时；
• 聚合条目数量和过滤后数量；
• 推送目标和结果（成功 / 失败 / message ID）；
• 总耗时和错误信息；
• 运行成本（Token 消耗、API 调用次数）。

日志不记录热点内容正文（避免日志过大）。

三个最常派上用场的日志场景

• "为什么今天清单变短了"：对比今天和上周同日的日志，一眼就能看到是来源缺失（数据源状态列）还是真的热点少（过滤前后数量列）；
• "这个任务跑一次到底多少钱"：成本列累积一个月，就能算出这项自动化的真实月成本，也能发现某个来源悄悄变贵了的异常；
• "它到底有没有在按时跑"：触发方式列能暴露"你以为它在定时跑，其实上周配置丢了、一直没跑"这类静默故障——压根没跑的任务不会触发告警，只有日志知道真相。

一个实用的习惯：每周花两分钟扫一眼最近七天的日志（聚合到一张小表即可），看有没有"没坏但不太对"的苗头——耗时缓慢上涨、某来源成功率逐渐下滑。日志的价值大多在这一眼之间：等告警响了再看，往往已经积重难返。

成本预算：给自动化一个护栏

自动化任务和手动任务最大的成本差别在于：手动任务花多少，你每一步都有体感；自动化任务在你睡觉时也在花钱，没有预算约束，它可能悄悄跑成一个无底洞。先看清成本从哪来：

设置预算上限：单次运行超过设定成本时，记录告警并继续运行，但下一次运行前需确认。这个设计的分寸值得体会——不是超预算立刻停（那会打断正常交付），而是超了要让人知道、并确认后再继续。预算是护栏，不是急刹车。

估算月成本的简单方法

看一周日志里的成本列，取平均单次成本，乘以运行频率，再乘以 1.5 的安全系数（留给重试和异常月份）：

单次平均成本 × 30 天 × 1.5 ≈ 月预算参考值
例：单次 0.8 元 × 30 × 1.5 = 36 元/月

两项值得留意的成本信号：

• 单次成本持续上涨：多半是某数据源返回内容越来越多（比如重试后抓了两遍），或聚合阶段上下文膨胀；
• 成本突然归零：先别高兴——大概率是任务根本没跑成，查日志确认，这往往比超支更需要处理。

把月预算写进任务定义（见本章模板一节），并和日志里的实际成本对一下账。一个有预算、有对账的自动化任务，才算是被真正"养"在了你的管理体系里，而不是放养。

自动化任务定义模板

把本章讨论的所有设计汇总到一张定义卡上。以选题任务为示例，记录完整的自动化任务定义——新建任何自动化任务时，照这张卡逐项填写，填完的那一刻，本章的大部分问题就都已经回答过了：

任务名称：AI 热点选题日报
触发方式：每天 09:00（工作日）
触发条件：无前置检查，定时直接运行
Prompt：[完整 Prompt 文本]
数据源：@wechat-article-search / @GitHub热门项目 / @多引擎搜索 / @AIHOT
质量门禁：有效 AI 相关条目 ≥ 5 条；数据源可用数量 ≥ 3 个
输出格式：结构化热点清单（含来源、热度、建议角度）
推送目标：[飞书群 / 个人通知 / 飞书文档追加]
幂等控制：批次 ID = ai-hotspot-{date}，推送成功后标记，不重复推送
重试策略：数据源超时重试 1 次；推送失败退避重试 2 次；其他失败转人工
告警接收：[个人飞书通知]
成本预算：单次运行上限 [金额 / Token 数]，月度上限 [金额]
owner：[博主本人]
停用方式：buddyme → 定时器 → 暂停

建议把填好的定义卡存进知识库，和任务的运行日志放在一起。它有两个长期用途：任务出问题时，它是排障的对照表（"设计上重试策略是什么来着"）；半年后想搭第二个自动化任务时，它是最现成的起点——你会发现，新任务要填的大部分格子，都能从旧卡上抄。

上线前演练：把故障先演一遍

正式开启定时任务前，手动模拟以下场景，确认任务行为符合预期。演练的思路是"把最可能发生的坏情况先演一遍"，让任务的第一次真实故障发生在你眼前，而不是你的收件箱里：

演练通过后再开启定时运行。

怎么模拟故障

不需要真的等故障发生，几个简单的办法就能逼出这些分支：

• 模拟数据源失败：临时把某个数据源的名字改错一位（或暂时移除授权），任务就抓不到它了——观察它是否按预期标记缺失、继续运行；
• 模拟无热点：把 Prompt 里的领域临时改成一个几乎不会有新闻的冷门词（如"量子打字机"），看它是否走 blocked 分支而不是硬凑清单；
• 模拟推送失败：把推送目标临时改成一个不存在的群或地址，看重试、告警和结果保留是否符合设计；
• 模拟重复触发：在定时触发前后各手动运行一次，看批次 ID 是否拦住了第二次执行。

每个场景演练两分钟，总共不到一刻钟。这十几分钟的投入，换的是上线后头一个月的安稳——多数"自动化事故"，都能在演练阶段用这种笨办法提前逮住。

运行指标：自动化任务的健康体检

稳定运行后，定期检查以下指标。指标是自动化任务的健康体征——单独看某一天没什么意义，连起来看趋势才有信息量：

• 按时触发率：09:00 定时是否准时触发。这个指标长期应该是 100%，一旦不是，优先排查（触发器的问题会让其他一切指标失真）；
• 一次运行成功率：不需要重试的成功比例。连续下滑说明环境在变（API 策略收紧、页面改版）；
• 数据源可用率：各来源的单独可用比例。哪个来源长期垫底，就是下一轮迭代要处理的对象；
• 有效条目数量趋势：监测 AI 热点信息量的波动。持续走低且排除了故障原因，可能是数据源覆盖面不够了，值得补充新来源；
• 推送成功率：推送不丢失的比例；
• 单次运行成本：追踪成本变化趋势。

指标出现持续下降时，检查对应数据源或推送配置是否发生变化。

看指标的节奏

不需要天天盯，两个时间点看就够：

• 每周一次，五分钟：扫一遍本周各指标的周均值，重点是"一次运行成功率"和数据源可用率——缓慢劣化通常在这里最先露头；
• 每月一次，十五分钟：把当月指标和上月对比，同时核对实际成本和预算。顺手问自己一个问题：这份清单最近给我带来的价值，还配得上它的成本吗？指标正常但价值衰减的任务，是该调整方向而不是继续养的。

所有指标里，最有用的往往是那个最容易被忽略的：使用率——推送的清单，你真的每天都在看吗？如果连续两周你都懒得点开它，指标再漂亮，这个任务也到了该改版或退休的时候。自动化的终点不是"跑得稳"，而是"真的被用"。

从个人自动化到团队服务

个人选题任务运行稳定后，可以扩展为团队共享。这不是简单"把推送目标改成群"就完事，而是任务身份的转换——从"我的工具"变成"团队的服务"，需要补上服务化才有的那些约定：

扩展为团队服务时，需要补充：明确 owner（以及 owner 休假时的备份处理人）、建立运行手册（把定义卡和排障经验写下来，让接手的人不依赖你脑中的记忆）、设置权限（谁能修改 Prompt 和推送配置）、制定变更流程（修改数据源需测试后生效）。

其中最容易被轻视的是变更流程。个人任务改 Prompt，影响只有自己；团队服务改 Prompt，影响的是十几个人第二天看到的东西。所以团队版的迭代要比个人版多一道门：改动先在测试环境跑三次，确认无误再上线——本章第 19 节的"改 → 手动验证 → 重新保存"流程，在团队场景下从建议升级为纪律。

自动化的高级形态，不是完全没有人，而是正常路径少打扰人，异常路径能及时找到正确的人。

选题任务的迭代优化

自动化任务上线不是终点，而是新一轮优化的起点。上线第一周，你会积累到手动阶段从未有过的东西：连续、真实的运行数据，以及最重要的——你自己每天使用它的真实感受。根据这些反馈持续迭代：

• Prompt 优化：根据哪类条目真正被采用、哪类被忽略，调整过滤维度和描述。追问几个具体问题：清单里"高热度"区的东西你从来不写？说明热度阈值该调；你总在"潜力方向"里挑中选题？说明相关性的判断标准写对了，可以加重它的权重。修改 Prompt 后需手动运行三次确认效果再重新保存自动化配置。
• 数据源调整：某个数据源长期质量差或可用率低，考虑替换或降低其权重。判断标准参考运行指标里的"数据源可用率"——一个每周挂两次的来源，即使内容再好，也在持续消耗整个任务的稳定性。替换时记得同步更新质量门禁里的数量门槛。
• 输出格式迭代：根据筛选习惯调整清单格式（如增加"本周已覆盖"标记，避免重复选题）。格式的改动最容易验证：改完第二天看清单，顺不顺眼、扫读快不快，身体最诚实。
• 时间调整：根据实际使用习惯调整触发时间（如改为 8:30 或 10:00）。一个简单的观察法：回想你最近五天是什么时候真正开始想选题的——任务应该在你需要之前一刻钟到位，而不是为了"准时"而准时。

每次调整都是一次小型配置变更，遵循"改 → 手动验证 → 重新保存"的流程，不直接在定时任务上实验。这条纪律的价值在于隔离变量：在定时任务上直接改，改坏了你分不清是改动的问题还是环境的问题；走一遍手动验证，改动效果先被确认，再进入生产，每天早上的那份清单就永远不会成为你的试验品。

自动化工作流：定时任务与可靠性

前面几节都是"你问它答"——人盯着，AI 干活。这一节往前一步：把规律性的活儿交给 buddyme 自动干，你只负责验收。日报、周报、数据汇总、定时抓取，这些"到点就该做"的事情，正是自动化的主场。但自动化也是最容易"翻车"的地方——跑一次成功不算什么，连续三十天不出错才算真本事。

为什么你的定时任务总是"第三天就坏了"

为什么要先说这个：很多人配置自动化的路径是：想到一个需求 → 写段指令 → 设个定时 → 完事。结果第二天数据源格式变了，任务静默失败；或者推送重复发了一条；或者某个网站临时打不开，整个流程中断。问题不在 buddyme，而在于你把自动化当成了"一次性配置"，而不是"一个需要维护的小系统"。

可靠工作流的三个认识：

• 认识一：模糊的指令 = 不可靠的输出。手动对话时 AI 可以反问你，定时任务没人接话——指令必须把所有情况都提前想清楚。
• 认识二：失败是常态，不是例外。网站改版、接口超时、文件被挪走，都会发生。好的工作流不是"不出错"，而是"出错后知道怎么办"。
• 认识三：交付比完美重要。数据源挂了一半时，与其什么都不交，不如交付拿到的部分，并明确说清缺了什么。

定时任务：五个要素配齐才稳

怎么做（照着做）：

• 第 1 步：手动跑通。先在对话里手动执行一遍完整任务，确认指令本身没问题。手动都不稳的任务，设成定时只会放大问题。
• 第 2 步：创建定时任务。在 buddyme 的自动化面板里新建任务，填入触发时间（支持每天、每周、cron 表达式）和任务指令。
• 第 3 步：明确触发规则。用固定的时间点（每天 06:03），不要用"每天早上"这种模糊描述。
• 第 4 步：写死交付位置。结果存到哪个文件夹、推送到哪里，必须在指令里写死，不能靠 AI 自己"看着办"。
• 第 5 步：留出机器环境余量。定时任务需要 buddyme 客户端保持运行——把任务安排在电脑开机时段内，或在常开的设备上跑。

可靠性三件套：重试、幂等、告警

为什么要做：这三件事决定了你的任务跑一个月后你是"省心"还是"心累"。

• 重试机制：网络抖动、接口超时这类瞬时错误，等 1-2 分钟再试一次通常就好了。在指令里加一句："如果某一步失败，等待 60 秒后重试一次；再失败则记录错误并继续后面的步骤。"注意：不是所有失败都值得重试——指令写错了，重试一百次也没用。
• 幂等设计：如果任务因推送失败而重跑，不应重复发送已成功的内容。最简单的做法是给每批结果一个日期编号（比如 20261020），推送前先检查"今天的是否已经发过"。没有幂等，一次故障重试就能让群里收到三份一模一样的日报。
• 告警机制：失败必须让你知道。在指令末尾加上："无论成功或失败，都生成一行执行记录；失败时额外推送一条包含错误原因的通知。"静默失败比失败本身可怕得多——你以为日报每天都在发，其实已经断了一周。

出错怎么办：发现定时任务某天没出结果，先看执行记录里的错误信息：文件不存在就去补文件，接口超时就加大重试间隔，格式变了就更新解析规则。每次修复都顺手改进指令，让同类错误不再复发。

降级交付：部分失败时怎么办

为什么重要：比如日报要汇总 5 个数据源，其中 2 个抓取失败。差的交付是"任务失败，无输出"；好的交付是"生成日报，包含 3 个成功数据源的内容，开头明确标注：数据源 B 和 C 今日获取失败，以下数据不含这两部分"。

怎么做：

• 第 1 步：在指令里把任务拆成独立的小步骤，每步单独判断成败。
• 第 2 步：某步失败时记录原因，继续执行其余步骤，不要整体中断。
• 第 3 步：最终交付物里明确写出：哪些部分完整、哪些部分缺失、缺失影响什么、建议怎么补。
• 第 4 步：如果核心步骤失败（比如连主数据都拿不到），才整体失败并告警。

上线前演练：把故障提前想一遍

怎么做（照着做）：正式开启定时任务前，手动模拟这四种情况，确认任务行为符合预期：

• [ ] 数据源正常时：任务产出完整结果，推送到指定位置
• [ ] 数据源打不开时：任务不卡死，走降级或告警，而不是静默挂掉
• [ ] 重复触发时：不产生重复推送（幂等生效）
• [ ] 结果为空时：能识别"今天确实没数据"和"抓取失败"这两种空的区别

四个场景都过关，再让它上正式时间表。之后每周花一分钟翻一次执行记录，你的自动化就能长期稳定跑下去。