每次运行的输出需要推送到固定位置。常见推送目标：
以选题任务为示例，记录完整的自动化任务定义
提示词：
任务名称：AI 热点选题日报
触发方式：每天 09:00（工作日）
触发条件：无前置检查，定时直接运行
Prompt：[完整 Prompt 文本]
数据源：@wechat-article-search / @蜜度热搜榜 / @GitHub热门项目 / @多引擎搜索 / @AIHOT
质量门禁：有效 AI 相关条目 ≥ 5 条；数据源可用数量 ≥ 3 个
输出格式：结构化热点清单（含来源、热度、建议角度）
推送目标：[飞书群 / 个人通知 / 飞书文档追加]
幂等控制：批次 ID = ai-hotspot-{date}，推送成功后标记，不重复推送
重试策略：数据源超时重试 1 次；推送失败退避重试 2 次；其他失败转人工
告警接收：[个人飞书通知]
owner：[博主本人]
停用方式：WorkBuddy 自动化任务管理页 → 暂停在 WorkBuddy 中设置自动化任务
手动运行确认效果后，在同一对话框中直接告诉 WorkBuddy：
把这个任务设置为自动化，每天早上 9:00 运行，
结果发送到 [指定飞书群 / 邮件 / 企微通知]。把自动化任务设计成状态机
将任务设计成状态机，每个状态都有明确的成功条件和失败出口：
stateDiagram-v2
[*] --> WaitingTrigger
WaitingTrigger --> Fetching: 9:00 触发
Fetching --> Aggregating: 数据源全部响应
Fetching --> PartialAggregating: 部分数据源超时
Aggregating --> Filtering: 聚合完成
PartialAggregating --> Filtering: 超时来源标记缺失
Filtering --> Delivering: 筛选完成，有有效条目
Filtering --> Blocked: 所有来源均无有效 AI 内容
Delivering --> Completed: 推送成功
Delivering --> Blocked: 推送失败
Blocked --> WaitingTrigger: 次日重新触发关键原则：部分数据源失败不应阻断整体任务，而是标记缺失后继续聚合；推送失败应保留结果并告警，不丢失已生成的内容。
数据源就绪检查
定时触发不等于数据源已就绪。每次运行开始时，先检查各数据源的可用性：
五个来源中至少有三个正常，才输出热点清单。全部失败时，进入 Blocked 状态并推送告警，次日重新触发。
内容质量审查
🫡 数据源可达不代表内容有效。聚合后需要过滤：
- 相关性 ：条目是否真正属于 AI 领域（排除泛科技话题的噪音）；
- 时效性 ：内容日期是否为当日（排除过期热点被重新推送的情况）；
- 重复性 ：同一事件是否已在多个来源出现，合并展示；
- 最低数量 ：有效条目少于 5 条时，视为当日 AI 热点不足，在输出中标注。
质量状态： pass （正常输出）、 warning （部分来源缺失，在输出顶部说明）、 blocked （有效条目不足，不推送正文，只推送说明）。
输出结构
聚合完成后，输出一份结构固定的热点清单，方便博主快速扫描和判断：
📋 AI 热点选题日报 — 2026-07-10
【今日概况】
有效条目：18 条 | 来源：5/5 | 运行时间：09:02
━━━━━━━━━━━━━━━━
🔥 高热度（适合快速蹭热点）
1. [模型名称] 发布，[核心能力] — 来源：AIHOT + GitHub
热度指数：★★★★★ | 建议角度：功能测评 / 使用教程
2. [工具名称] 开源，[功能描述] — 来源：GitHub热门项目
热度指数：★★★★ | 建议角度：上手教程 / 对比测评
━━━━━━━━━━━━━━━━
📈 潜力方向（适合深度分析）
3. [话题] 引发讨论 — 来源：微信公众号
热度指数：★★★ | 建议角度：观点分析 / 案例拆解
━━━━━━━━━━━━━━━━
⚠️ 数据来源说明
蜜度热搜榜：正常 | GitHub：正常 | 微信：正常
多引擎搜索：正常 | AIHOT：正常输出格式固定后，博主可以在 5 分钟内完成选题判断，而不是每次重新整理格式。
推送目标与幂等
每次运行的输出需要推送到固定位置。常见推送目标：
幂等原则 ：如果某次任务因推送失败而重试，不应重复发送已成功推送的内容。每次运行生成唯一批次 ID（如 ai-hotspot-2026-07-10 ），推送成功后记录状态，重试时检查状态跳过已完成步骤。
超时和重试策略
重试只针对临时性故障，不对输入问题或配置问题重试。
断点续跑
每次运行生成状态文件，记录已完成的步骤和产物：
{
"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",
"midu": "ok",
"github": "ok",
"multi_search": "ok",
"aihot": "ok"
},
"item_count": 18,
"last_error": null,
"updated_at": "2026-07-10T09:02:14+08:00"
}推送失败后重试，从 delivering 步骤继续，不重新抓取和聚合。
告警要可行动
自动化任务失败时，告警内容必须包含足够信息，让收到告警的人能够立即判断如何处理：
⚠️ AI 热点选题任务告警
批次：ai-hotspot-2026-07-10
状态：Blocked
触发时间：09:00
失败原因：所有数据源均返回空结果或超时
已完成步骤：fetching（部分失败）
影响：今日热点清单未生成，未推送
建议处理：
1. 检查各数据源 API 状态
2. 如为临时故障，可手动触发一次任务重跑
3. 如需跳过今日，确认后标记为已处理
恢复入口：WorkBuddy → 自动化任务 → 手动运行"任务失败，请查看"不足以让人处理。
降级交付
当部分数据源失败，不应等待全部就绪再输出：
- 3 个及以上来源正常 → 输出清单，顶部标注哪些来源缺失；
- 2 个来源正常 → 输出简化清单，标注数据不完整；
- 1 个或 0 个来源正常 → 不输出正文，只推送说明和告警。
降级结果必须显式标记来源覆盖情况，不伪装成完整运行。
日志
每次运行记录：
- 批次 ID 和触发方式（定时 / 手动）；
- 各数据源响应状态和耗时；
- 聚合条目数量和过滤后数量；
- 推送目标和结果（成功 / 失败 / message ID）；
- 总耗时和错误信息；
- 运行成本（Token 消耗、API 调用次数）。
日志不记录热点内容正文（避免日志过大）。
成本预算
选题任务的主要成本来源：
设置预算上限：单次运行超过设定成本时，记录告警并继续运行，但下一次运行前需确认。
自动化任务定义模板
以选题任务为示例，记录完整的自动化任务定义：
任务名称：AI 热点选题日报
触发方式：每天 09:00（工作日）
触发条件：无前置检查，定时直接运行
Prompt：[完整 Prompt 文本]
数据源：@wechat-article-search / @蜜度热搜榜 / @GitHub热门项目 / @多引擎搜索 / @AIHOT
质量门禁：有效 AI 相关条目 ≥ 5 条；数据源可用数量 ≥ 3 个
输出格式：结构化热点清单（含来源、热度、建议角度）
推送目标：[飞书群 / 个人通知 / 飞书文档追加]
幂等控制：批次 ID = ai-hotspot-{date}，推送成功后标记，不重复推送
重试策略：数据源超时重试 1 次；推送失败退避重试 2 次；其他失败转人工
告警接收：[个人飞书通知]
owner：[博主本人]
停用方式：WorkBuddy 自动化任务管理页 → 暂停上线前演练
正式开启定时任务前，手动模拟以下场景，确认任务行为符合预期：
演练通过后再开启定时运行。
运行指标
稳定运行后，定期检查以下指标：
- 按时触发率 ：09:00 定时是否准时触发；
- 一次运行成功率 ：不需要重试的成功比例；
- 数据源可用率 ：各来源的单独可用比例；
- 有效条目数量趋势 ：监测 AI 热点信息量的波动；
- 推送成功率 ：推送不丢失的比例；
- 单次运行成本 ：追踪成本变化趋势。
指标出现持续下降时，检查对应数据源或推送配置是否发生变化。
从个人自动化到团队服务
个人选题任务运行稳定后，可以扩展为团队共享：
扩展为团队服务时，需要补充：明确 owner、建立运行手册、设置权限（谁能修改 Prompt 和推送配置）、制定变更流程（修改数据源需测试后生效）。
自动化的高级形态，不是完全没有人，而是正常路径少打扰人，异常路径能及时找到正确的人。
选题任务的迭代优化
自动化任务上线后，根据实际使用反馈持续迭代：
Prompt 优化 ：根据哪类条目真正被采用、哪类被忽略，调整过滤维度和描述。修改 Prompt 后需手动运行三次确认效果再重新保存自动化配置。
数据源调整 ：某个数据源长期质量差或可用率低，考虑替换或降低其权重。
输出格式迭代 ：根据筛选习惯调整清单格式（如增加"本周已覆盖"标记，避免重复选题）。
时间调整 ：根据实际使用习惯调整触发时间（如改为 8:30 或 10:00）。
每次调整都是一次小型配置变更，遵循"改 → 手动验证 → 重新保存"的流程，不直接在定时任务上实验。
