1. 为什么我要折腾一个“AI 日报闹钟”每天早上到工位第一件事是打开各种信息源项目群消息、待办清单、行业动态、昨天遗留的代码评审、今天要跟进的客户。信息是散的人是懵的。我试过用待办软件、用笔记工具、用各种聚合阅读器最后发现一个尴尬的事实——工具越多我越懒得打开。真正每天必看、不用刻意点开的东西只有一个微信。所以我的目标很朴素每天上午十点半让一份整理好的 AI 日报自动出现在微信里。不是让我去某个网站看不是让我打开某个 App而是像有人给我发了条消息一样直接躺在聊天列表里。这个需求听起来简单但拆开来看它其实是一条完整的自动化链路定时触发、数据抓取、内容生成、消息推送。任何一个环节掉链子日报就送不到。我给它起的名字叫 WorkBuddy定位是一个“个人工作助理”。它不处理复杂业务只做一件事把散落的信息变成一份能读的日报然后准时送到我面前。这篇文章我会把整条链路拆开讲清楚——为什么这么设计、每个环节怎么选型、参数怎么算、坑在哪里。如果你也想给自己搭一个类似的自动化助理不管是日报、周报、监控告警还是定时提醒这套思路都能直接抄。适合谁看三类人。第一类是有一定编程基础、想入门自动化的开发者第二类是用过 WorkBuddy 或类似工具、但只会点按钮不会定制的进阶用户第三类是纯粹好奇“AI 日报到底怎么自动送到微信”的产品和运营同学。不需要你是算法专家但需要你愿意动手改几行配置。2. 整体架构设计与选型思路2.1 一条日报的完整生命周期先把链路画清楚不然后面每个环节都会变成黑盒。一份日报从无到有出现在微信里要经过五个阶段定时触发每天上午十点半某个东西要主动“醒来”并启动流程。数据采集从预设的信息源拉取原始内容比如行业资讯、项目动态、待办事项。内容生成把原始内容交给 AI 模型让它压缩、归类、提炼成一份可读的日报。消息推送把生成好的内容通过微信生态的某个入口发给我。状态记录记录本次执行结果失败时能知道卡在哪一步。这五个阶段对应到具体实现就是定时任务、爬虫或 API 调用、大模型接口、微信消息通道、日志系统。每一层都有多种选型选错了后面全是坑。2.2 为什么定时选在十点半这个时间点不是随便定的。太早比如八点很多信息源还没更新日报内容会残缺太晚比如下午日报就失去了“开启一天”的意义。十点半这个位置有个好处大部分行业媒体和社区在上午已经完成了第一轮更新同时我刚好处理完早上的紧急消息有时间读一份日报。从技术角度看十点半也避开了整点任务高峰。很多定时任务系统默认在整点触发服务器负载高接口容易超时。错峰到半点成功率会明显提升。这是一个很小的经验但实测下来很稳。2.3 为什么用微信而不是邮件或 App邮件的问题是我不会及时看App 的问题是我不会主动打开。微信的独特价值在于它是“被动接收”的——消息来了会有红点我会下意识点开。对于日报这种“需要被看到”的内容被动推送比主动拉取有效得多。但微信生态有个限制个人微信没有官方的机器人消息接口直接给个人号发消息属于违规操作。所以实际落地时通常走的是企业微信应用消息或者微信服务号模板消息这两条合规路径。企业微信可以创建一个内部应用通过应用给成员推送消息服务号则可以通过模板消息推送给关注用户。两者都能实现“消息出现在微信里”的效果区别在于企业微信更适合个人或小团队自用服务号更适合对外服务。注意不要尝试用非官方手段给个人微信发消息账号风险极高得不偿失。合规通道虽然多一步配置但长期稳定。2.4 AI 模型选型为什么是 DeepSeek内容生成环节我选的是 DeepSeek。原因有三个。第一中文理解能力强日报这种场景对中文摘要和归类的质量要求很高英文模型翻译腔重读起来别扭。第二接口成本低日报每天一次token 消耗不大但长期跑下来成本差异明显。第三接口稳定响应速度快十点半触发后通常几秒内就能返回结果。当然模型不是唯一的。如果你已经有其他大模型的接口完全可以替换。关键是要选一个支持结构化输出的模型因为日报需要固定的格式比如标题、摘要、要点列表。如果模型输出格式飘忽不定后面解析会很痛苦。2.5 为什么不用现成的自动化平台市面上有不少低代码自动化平台拖拖拽拽就能连起来。我试过结论是简单场景够用但一旦涉及自定义数据处理和格式控制就会很别扭。比如我想让 AI 按特定模板输出平台提供的节点往往不支持精细的 prompt 控制再比如我想在推送前做一层内容过滤平台也不方便插入自定义逻辑。自己写代码的好处是完全可控。整条链路就是一个脚本想改哪里改哪里出问题也能精确定位。对于每天都要跑的自动化任务可控性比开发速度更重要。3. 核心环节拆解与实操要点3.1 定时触发cron 还是调度框架最简单的方案是 cron。在 Linux 服务器上写一行 crontab每天十点半执行脚本30 10 * * * /usr/bin/python3 /home/user/workbuddy/main.py /home/user/workbuddy/logs/cron.log 21这行配置的意思是每天 10:30用 python3 执行 main.py标准输出和错误输出都追加到日志文件。注意是追加是覆盖日志场景一定要用追加否则每次执行都会把之前的日志冲掉。但 cron 有个坑它不加载用户的环境变量。如果你的脚本依赖某些环境变量比如 API Keycron 执行时会找不到。解决办法有两个一是在脚本里显式加载环境变量文件二是在 crontab 里先 source 环境。我推荐第一种更可控from dotenv import load_dotenv load_dotenv(/home/user/workbuddy/.env)如果任务变多比如日报、周报、监控告警都要定时cron 管理起来会乱。这时候可以上 APScheduler 这类调度框架用 Python 代码定义任务支持更复杂的调度规则和任务依赖。但对于单一日报任务cron 足够了没必要过度设计。3.2 数据采集API 优先爬虫兜底数据源分两类。一类是有开放 API 的比如某些资讯平台、项目管理工具、代码托管平台直接调接口拿 JSON 数据稳定且合规。另一类是没有 API 的只能爬页面。我的原则是能用 API 就不用爬虫。API 返回结构化数据解析简单不会因为页面改版而失效。爬虫则相反今天能跑明天可能就挂了维护成本高。采集环节的关键是容错。任何一个数据源挂了不能让整个日报流程崩掉。我的做法是每个数据源独立 try-except失败的源记录错误但继续执行最后在日报里标注“某源今日获取失败”。这样即使部分数据缺失日报依然能送达。def fetch_source(name, url): try: resp requests.get(url, timeout10) resp.raise_for_status() return {name: name, data: resp.json(), ok: True} except Exception as e: return {name: name, data: None, ok: False, error: str(e)}超时设置很重要。默认不设超时的话某个源卡住会导致整个脚本挂起日报就送不出来了。10 秒是个合理的值超过就放弃这个源。3.3 内容生成prompt 设计决定日报质量这是整个链路里最需要打磨的环节。同样一堆原始数据prompt 写得好输出的是条理清晰的日报写得差输出的是一坨废话。我的 prompt 结构是这样的你是一个工作助理请把以下原始信息整理成一份日报。 要求 1. 按主题分类每类不超过 3 条 2. 每条用一句话概括不超过 50 字 3. 重要程度高的排在前面 4. 如果某类没有内容跳过该类 5. 输出格式为 Markdown用二级标题分节 原始信息 {raw_content}这里有几个设计考量。第一限制条数和字数防止 AI 输出过长日报要的是快速阅读不是长篇大论。第二要求分类让信息有结构。第三允许跳过空类避免出现“今日无内容”这种废话。第四指定 Markdown 格式方便后续推送时直接渲染。温度参数建议设低一点比如 0.3。日报需要的是稳定、准确不需要创意。温度太高同样的输入每次输出差异很大不利于形成固定的阅读习惯。3.4 消息推送企业微信应用消息实操前面说了合规通道主要是企业微信和服务号。我选的是企业微信因为配置简单个人也能注册企业。具体步骤注册企业微信创建一个内部应用拿到corpid、corpsecret、agentid三个参数。调用接口获取 access_tokendef get_token(corpid, corpsecret): url fhttps://qyapi.weixin.qq.com/cgi-bin/gettoken?corpid{corpid}corpsecret{corpsecret} resp requests.get(url, timeout10) return resp.json()[access_token]用 access_token 发送应用消息def send_message(token, agentid, content): url fhttps://qyapi.weixin.qq.com/cgi-bin/message/send?access_token{token} payload { touser: all, msgtype: markdown, agentid: agentid, markdown: {content: content} } resp requests.post(url, jsonpayload, timeout10) return resp.json()注意msgtype选markdown这样日报里的标题、列表能正常渲染。如果选text所有格式都会变成纯文本读起来很难受。access_token 有有效期通常是 7200 秒。不要每次发送都重新获取应该缓存起来过期再刷新。我的做法是把 token 和获取时间存到本地文件每次先检查是否过期。3.5 状态记录日志和告警日报送没送到必须有记录。我的日志分两层一层是执行日志记录每个环节的开始、结束、耗时、结果另一层是业务日志记录日报内容本身方便回溯。import logging logging.basicConfig( filename/home/user/workbuddy/logs/run.log, levellogging.INFO, format%(asctime)s [%(levelname)s] %(message)s )日志格式里带上时间戳和级别排查问题时能快速定位。如果推送失败除了记日志还应该有一个兜底告警——比如发一封邮件给自己或者调用另一个通道发一条简短提醒。日报没送到是小事但如果连续几天没送到而你不知道那就失去意义了。4. 完整实操流程与参数配置4.1 环境准备与依赖安装先准备一台能长期运行的机器。可以是云服务器也可以是家里的一台旧电脑或树莓派。关键是网络稳定、能定时开机。我用的是云服务器最低配就够日报任务对算力几乎没有要求。系统建议 Ubuntu 20.04 或以上。安装 Python 3.9然后装依赖pip install requests python-dotenv apscheduler如果要用 DeepSeek 的接口还需要装对应的 SDK 或者直接用 requests 调 HTTP 接口。我倾向后者依赖少可控。目录结构建议这样组织workbuddy/ ├── main.py # 主流程 ├── config.py # 配置加载 ├── fetchers.py # 数据采集 ├── generator.py # 内容生成 ├── pusher.py # 消息推送 ├── .env # 敏感配置 └── logs/ # 日志目录模块拆开的好处是每个环节可以单独测试。比如推送失败时我可以只跑 pusher 模块不用把整条链路重跑一遍。4.2 配置文件与敏感信息管理API Key、corpid、corpsecret 这些绝对不能硬编码在代码里。用.env文件管理DEEPSEEK_API_KEYyour_key_here WECOM_CORPIDyour_corpid WECOM_CORPSECRETyour_secret WECOM_AGENTIDyour_agentid.env文件要加入.gitignore避免误提交。代码里通过os.getenv读取import os from dotenv import load_dotenv load_dotenv() api_key os.getenv(DEEPSEEK_API_KEY)注意.env文件的权限建议设为 600只有当前用户可读。多人共用的服务器上尤其重要。4.3 主流程串联与异常处理主流程就是把各模块串起来但异常处理要细致def main(): logging.info(日报任务开始) # 采集 sources fetch_all() ok_sources [s for s in sources if s[ok]] if not ok_sources: logging.error(所有数据源均失败终止任务) send_alert(日报数据源全部失败) return # 生成 raw format_raw(ok_sources) report generate_report(raw) if not report: logging.error(内容生成失败) send_alert(日报生成失败) return # 推送 result push_report(report) if result.get(errcode) ! 0: logging.error(f推送失败: {result}) send_alert(f日报推送失败: {result}) else: logging.info(日报推送成功)这里的关键是分级失败。数据源部分失败可以继续全部失败才终止生成失败终止推送失败告警。每一级都有明确的处理策略不会出现“卡在中间不知道怎么办”的情况。4.4 参数计算超时、重试与频率几个关键参数需要根据实际情况调整参数建议值说明单源超时10 秒超过则放弃该源模型调用超时30 秒大模型响应通常 3-10 秒留足余量推送超时10 秒微信接口通常很快重试次数2 次失败后间隔 5 秒重试日志保留30 天定期清理避免占满磁盘重试要谨慎。如果是参数错误比如 token 失效重试没用应该先刷新 token 再重试。如果是网络抖动重试有效。我的做法是区分错误类型网络类错误重试业务类错误直接告警。4.5 实测记录一次完整的执行某天上午十点半cron 触发。日志记录如下2024-06-15 10:30:01 [INFO] 日报任务开始 2024-06-15 10:30:02 [INFO] 数据源 A 采集成功12 条 2024-06-15 10:30:03 [INFO] 数据源 B 采集成功8 条 2024-06-15 10:30:04 [WARN] 数据源 C 超时跳过 2024-06-15 10:30:05 [INFO] 原始内容整理完成共 20 条 2024-06-15 10:30:09 [INFO] 模型生成完成耗时 4.2 秒 2024-06-15 10:30:10 [INFO] 推送成功errcode0 2024-06-15 10:30:10 [INFO] 日报任务结束总耗时 9 秒整个流程 9 秒完成。数据源 C 超时被跳过日报里标注了“C 源今日未获取”不影响阅读。这就是容错设计的价值。5. 常见问题与排查技巧实录5.1 日报没收到怎么快速定位按链路顺序排查从后往前先看日志tail -50 logs/run.log看最后一次执行到哪一步。看 cron 是否触发grep CRON /var/log/syslog确认任务有没有被调度。看推送返回如果日志里有errcode对照企业微信错误码表。常见的是40014token 无效和45009接口调用超限。看网络curl一下微信接口确认服务器能访问外网。大部分问题出在 token 过期和网络不通这两类。token 问题加个自动刷新就好网络问题通常是服务器安全组或防火墙配置。5.2 常见问题速查表现象可能原因解决方法日报内容为空数据源全部失败检查数据源接口是否变更日报格式乱模型输出未按模板降低温度强化 prompt 格式要求推送报 40014access_token 失效实现 token 缓存与自动刷新推送报 45009调用频率超限降低频率日报一天一次不会触发cron 不执行环境变量缺失脚本内显式加载 .env脚本卡住未设超时所有网络请求加 timeout日志文件过大未清理加日志轮转或定期删除5.3 独家避坑技巧技巧一先手动跑通再上 cron。很多人直接配 cron结果失败了不知道是脚本问题还是调度问题。正确做法是先在命令行手动执行python3 main.py确认整条链路通了再配 cron。技巧二给日报加一个“心跳”。如果某天日报没来你可能是过了很久才发现。可以在日报里加一行“本日报由 WorkBuddy 于 XX 时间生成”这样你一眼就能看出是不是当天的。更狠一点可以设一个反向监控如果十一点还没收到日报就发一条告警。技巧三prompt 要版本管理。prompt 改动会直接影响日报质量改坏了很难回滚。建议把 prompt 单独放在一个文件里每次改动记录版本和效果。我吃过这个亏某次调 prompt 后日报变得又长又乱找了两天才发现是 prompt 的问题。技巧四数据源要定期体检。API 会改版页面会重构。建议每周手动检查一次各数据源是否正常别等日报内容变空了才发现。技巧五不要把鸡蛋放在一个推送通道。企业微信虽然稳定但也有抽风的时候。可以准备一个备用通道比如邮件主通道失败时自动切换。多一层保障日报的到达率会高很多。5.4 性能与成本优化日报任务本身很轻但如果数据源多、内容长模型调用的 token 消耗会上升。优化方向有两个一是采集时做初步过滤去掉明显无关的内容减少喂给模型的 token二是让模型输出精简限制字数和条数。成本方面DeepSeek 的接口价格很低一天一次日报一个月成本通常在一杯咖啡以内。如果用量大可以关注官方的计费规则选择合适的模型规格。对于日报这种场景不需要用最强的模型中等规格完全够用。6. 后续可以怎么扩展这套链路跑通之后扩展空间很大。最直接的是把日报变成周报、月报只需要改 cron 表达式和 prompt 里的时间范围。再进一步可以做成“事件驱动”的——不只是定时而是当某个条件满足时触发比如项目有新的高危告警、某个指标超过阈值立刻推送一条提醒。另一个方向是双向交互。现在的 WorkBuddy 是单向推送我收到日报后如果想知道更多细节还得自己去查。可以加一个查询入口比如在企业微信里发关键词WorkBuddy 返回对应的详细信息。这就从“日报”升级成了“助理”。我个人在实际操作中的体会是自动化的价值不在于省了多少时间而在于消除了“要不要做”的决策成本。以前我每天要纠结“今天要不要看行业动态”现在不用纠结了日报会自己来。这种确定性比省下来的十分钟更值钱。