1. 为什么我要给 WorkBuddy 装一个“十点半闹钟”每天早上到工位第一件事不是打开编辑器而是先刷一遍各种信息源行业动态、竞品更新、社区里冒出来的新工具、昨天没看完的技术帖。刷完一圈半小时没了真正要动手的活儿还没开始。这个习惯持续了大半年直到我意识到一个问题——我每天花在“获取信息”上的时间其实大部分是重复劳动而且质量还不稳定。有时候刷到一条关键更新有时候全是噪音。WorkBuddy 这类 AI 助手工具的出现让我看到了把这套流程自动化的可能。它的核心能力是接收指令、调用模型、产出结构化内容。那为什么不干脆让它每天早上替我“读一遍”我关心的东西然后整理成一份日报直接推到我微信里这样我睁眼就能看到重点不用再手动翻。这个想法落地之后我把它做成了一个定时任务每天上午十点半WorkBuddy 自动跑一遍我预设的信息采集和总结流程生成一份 AI 日报通过微信推送给我的手机。整个过程不需要我干预也不需要我打开任何网页。这篇文章就是把这套东西从零到跑通的完整记录包括我踩过的坑、为什么这么设计、以及你如果想复现该怎么抄作业。适合谁看如果你每天也要花大量时间做信息筛选或者你已经在用 WorkBuddy、DeepSeek 这类工具但只停留在“手动问一句答一句”的阶段那这篇内容应该能帮你把它变成一个真正替你干活的“数字同事”。不需要你是自动化专家但需要你对命令行、定时任务、微信消息推送这些概念有最基本的了解。我会尽量把每一步的理由讲清楚让你不只是照抄而是知道为什么这么抄。2. 拆解需求一份“自动送进微信”的日报到底需要哪几块拼图2.1 信息从哪来日报的“原料”决定了它的价值上限在动手之前我先问自己一个问题这份日报到底要包含什么如果只是让 AI 随便生成一段“今日科技新闻”那价值几乎为零因为网上到处都是。我需要的是一份针对我个人关注点的定制化摘要。所以我列了一个信息源清单分成三类固定源我长期关注的几个技术社区、官方博客、更新日志页面。这些内容每天变化不大但一旦有更新就是重要信号。关键词源围绕我当前项目相关的技术词比如“AI Agent”“自动化测试”“微信小程序开发”等去抓取最新的讨论和文章。临时源我前一天晚上如果看到什么值得追踪的线索会手动加进一个待办列表第二天日报里要包含跟进结果。这三类信息源对应到 WorkBuddy 的指令设计上就是三个不同的采集任务。固定源用定时抓取关键词源用搜索接口临时源用文件读取。把它们的结果汇总再交给模型做总结和排序最终产出一份有优先级的日报。提示信息源不要贪多。我一开始加了十几个源结果日报长得像论文根本看不完。后来砍到五个核心源阅读体验反而好了很多。2.2 为什么选十点半时间点的选择比你想的更讲究十点半这个时间不是随便定的。我试过几个时间点最后发现十点半是最合适的原因有三个第一大部分我关注的社区和博客更新集中在早上八点到十点之间。太早跑抓不到当天的内容太晚跑我可能已经自己刷完了日报就失去了“替我筛选”的意义。第二十点半是我通常已经处理完紧急邮件、准备进入深度工作之前的一个空档。这时候收到一份日报我可以花五分钟扫一遍把重要的标记出来然后带着这些信息进入工作状态。第三从技术角度看十点半这个时间点的网络请求压力相对小一些。我试过整点跑有时候会遇到接口响应慢的情况。错开整点稳定性会好一点。这个经验是我踩了几次坑之后才总结出来的后面会详细说。2.3 微信推送的几种路径为什么我最终选了“文件传输助手”方案把内容送进微信听起来简单做起来有好几条路。我调研了三种方案方案实现方式优点缺点企业微信机器人通过 Webhook 推送稳定、官方支持需要企业微信环境个人使用门槛高公众号模板消息需要认证服务号推送体验好认证流程复杂个人开发者不友好文件传输助手通过桌面端自动化操作无需额外账号直接到手机依赖桌面端在线有封号风险我最终选了第三种但做了一些规避风险的调整。具体怎么做的在第四节会详细展开。这里先说结论不要用任何自动化工具去模拟登录或批量操作微信账号这是红线。我的做法是利用微信桌面端本身提供的文件传输能力把日报写成一个文件然后通过系统级的文件同步机制送到手机端。整个过程不涉及账号模拟只是文件流转。3. 把 WorkBuddy 变成“日报编辑”指令设计与模型调用的实操细节3.1 自定义指令的写法让模型知道“你是谁、你要什么”WorkBuddy 的核心是自定义指令。你给它一段提示词它按照提示词去执行任务。我一开始写的指令很随意比如“帮我总结一下今天的科技新闻”结果出来的东西完全不能用——要么太泛要么漏掉关键信息。后来我总结了一个指令模板包含四个部分角色设定告诉模型它是什么角色。我写的是“你是一个技术情报分析师服务于一个关注 AI 工具和自动化开发的工程师”。任务描述明确要做什么。比如“从以下信息源中提取过去 24 小时内的重要更新按重要性排序每条用两句话总结”。输出格式规定日报的结构。我要求它分成“必读”“值得一看”“可以跳过”三个板块每个板块下列条目。约束条件比如“不要包含广告内容”“如果某个源没有更新明确说明‘无更新’而不是编造内容”。这个模板我迭代了大概七八版每一版都是因为实际使用中发现了问题才改的。比如最早没有“无更新”这个约束模型会为了凑字数编一些不存在的内容这个坑后面会细说。3.2 调用 DeepSeek 做总结为什么不用更大的模型WorkBuddy 支持接入多种模型我试过几个最后日常跑日报用的是 DeepSeek。原因很实际日报这个任务对模型的推理深度要求不高但对响应速度和成本敏感。DeepSeek 在这两点上表现很好总结质量也够用。具体调用方式是在 WorkBuddy 的指令里指定模型和参数。我用的配置大概是这样的model: deepseek-chat temperature: 0.3 max_tokens: 2000 system_prompt: | 你是一个技术情报分析师... user_prompt: | 以下是今天采集到的信息源内容 {{collected_content}} 请按照以下格式生成日报...temperature 设成 0.3 是为了让输出稳定一些不要每次风格差异太大。max_tokens 设 2000 是因为日报太长没人看2000 个 token 大概能覆盖 10-15 条摘要刚好。注意不同模型对提示词的敏感度不一样。DeepSeek 对格式要求比较严格如果你在指令里写了“分成三个板块”它基本会照做。但有些模型可能会自由发挥。所以换模型的时候指令要重新调一遍。3.3 信息采集环节用脚本把“原料”准备好WorkBuddy 本身可以做一些简单的网页抓取但我发现对于复杂的采集任务还是用外部脚本更灵活。我的做法是写一个 Python 脚本负责三件事抓取固定源的 RSS 或更新页面提取标题和摘要。调用搜索接口用关键词拉取最新结果。读取本地待办文件把临时源的内容加进来。脚本跑完之后把结果写成一个 JSON 文件然后 WorkBuddy 读取这个文件作为输入。这样分工的好处是采集逻辑和总结逻辑解耦哪一部分出问题都好排查。脚本的核心逻辑大概是这样import feedparser import json import requests def collect_fixed_sources(): sources [ {name: 源A, url: https://example.com/feed}, {name: 源B, url: https://example.com/feed}, ] results [] for source in sources: feed feedparser.parse(source[url]) for entry in feed.entries[:5]: results.append({ source: source[name], title: entry.title, summary: entry.summary, link: entry.link }) return results def collect_keyword_sources(): keywords [AI Agent, 自动化测试, 微信小程序开发] results [] for kw in keywords: # 这里调用你使用的搜索接口 # 注意遵守目标站点的使用条款 pass return results def main(): all_content { fixed: collect_fixed_sources(), keyword: collect_keyword_sources(), temp: json.load(open(temp_sources.json)) } with open(daily_input.json, w) as f: json.dump(all_content, f, ensure_asciiFalse, indent2) if __name__ __main__: main()这个脚本我放在一台常开的机器上用系统的定时任务每天十点触发。跑完之后 WorkBuddy 在十点半接手读取daily_input.json生成日报。3.4 日报的格式设计让人愿意读下去的几个细节日报的格式我改了很多次最后固定成现在这个样子开头一句话今天总共采集了多少条筛选出多少条预计阅读时间几分钟。必读板块最多三条每条包含标题、来源、两句话总结、原文链接。值得一看板块最多五条格式同上但总结更短。可以跳过板块只列标题不展开。结尾一句“今天没有重大更新”或者“建议重点关注第 X 条”。这个格式的核心逻辑是分层。人的注意力是有限的如果所有条目看起来一样重要读者就会全部跳过。分层之后读者可以先看必读有时间再看值得一看没时间就直接关掉。这个设计是我从邮件摘要工具里学来的用下来确实有效。4. 微信推送的落地从文件到手机的那条“安全通道”4.1 为什么我放弃了“直接发消息”的方案最开始我想的是让脚本直接给我的微信发消息。调研了一圈发现个人微信没有官方的消息发送接口所有能实现这个功能的方案本质上都是模拟客户端操作或者逆向协议。这两条路我都不走原因很简单风险不可控。账号是我的核心通讯工具不值得为了一个日报去冒任何风险。所以我换了个思路不“发消息”而是“传文件”。微信桌面端本身支持文件传输助手我可以把日报写成一个 Markdown 文件放到一个特定目录里然后通过系统级的文件同步机制让手机端能访问到。整个过程不涉及任何微信协议的调用只是文件在本地和云端之间流转。4.2 用系统定时任务串联整个流程整个流程的串联靠的是系统定时任务。我用的是 Linux 环境所以用 crontab。如果你用 Windows可以用任务计划程序逻辑是一样的。我的 crontab 配置大概是这样# 每天上午 10:00 采集信息 0 10 * * * /usr/bin/python3 /home/user/scripts/collect.py /home/user/logs/collect.log 21 # 每天上午 10:30 生成日报并推送 30 10 * * * /usr/bin/python3 /home/user/scripts/generate_report.py /home/user/logs/report.log 21两个任务之间隔了半小时是为了给采集脚本留足时间。如果采集失败或者超时日报生成脚本会检测到输入文件缺失然后发一条“今日采集失败”的提示而不是生成一份空日报。这个容错设计很重要后面会讲为什么。4.3 文件同步的几种做法和我的选择把日报文件从电脑送到手机我试过几种方式云盘同步把日报写进云盘同步目录手机端装对应 App 查看。优点是稳定缺点是多装一个 App。邮件转发把日报作为邮件发给自己手机端邮件客户端查看。优点是通用缺点是邮件列表容易乱。本地网络共享在同一网络下通过文件共享访问。优点是快缺点是出门就用不了。最后我选的是云盘同步因为我的工作机本来就装了云盘客户端日报写进同步目录后手机端几乎立刻就能看到。而且云盘一般都有历史版本万一日报被覆盖了还能找回来。具体操作是日报生成脚本把内容写成一个 Markdown 文件文件名带日期比如daily-report-2025-01-15.md然后保存到云盘同步目录下的一个子文件夹里。手机端打开云盘 App进入这个文件夹就能看到当天的日报。提示文件名一定要带日期而且格式要统一。我一开始用“日报.md”这种固定名字结果每天覆盖前一天的想回看都找不到。改成带日期之后历史日报自动就积累下来了。4.4 实测中的稳定性问题和应对这套流程跑了一个多月遇到过几次问题这里列一下问题原因应对日报没生成采集脚本超时输入文件没写出来加超时检测失败时发提示而不是空日报日报内容为空某个信息源改版抓取规则失效加源健康检查连续失败三次就告警文件没同步云盘客户端掉线加一个本地备份目录同步失败时文件还在模型输出格式错乱提示词被意外修改把提示词存成独立文件脚本读取不硬编码这些应对措施看起来琐碎但正是它们让这套流程从“玩具”变成了“工具”。一个每天跑的任务稳定性比功能丰富更重要。5. 踩过的坑那些让我半夜爬起来改脚本的瞬间5.1 模型“编造”内容为什么我加了“无更新”约束最早版本的日报经常出现一些我根本没关注过的信息源的内容。一开始我以为是自己配置错了后来发现是模型在“补全”。当某个信息源没有更新时模型会倾向于编一些看起来合理的内容填进去而不是老老实实说“无更新”。这个问题在 AI 总结类任务里很常见。模型的训练目标是生成连贯的文本不是生成真实的文本。所以如果你不明确约束它就会为了连贯而牺牲真实。我的解决办法是在指令里加了一条硬约束“如果某个信息源在采集结果中不存在或为空必须在日报中明确写‘该源今日无更新’不得编造任何内容。”加了这条之后编造问题基本消失了。但代价是日报里会出现一些“无更新”的条目看起来有点啰嗦。后来我又优化了一下把“无更新”的源合并成一行放在结尾这样既真实又不占篇幅。5.2 时间点踩坑整点跑任务为什么容易失败前面提到我把任务时间从整点改到了十点半这里展开说一下原因。我最早设的是十点整跑采集十点半跑日报。结果发现十点整的时候采集脚本经常超时。排查之后发现两个原因第一十点整是很多定时任务集中触发的时间网络请求量大目标站点的响应速度会变慢。第二我关注的几个源本身也是在整点附近更新如果采集脚本跑得太早可能抓到的是更新前的内容。改成十点零七分跑采集之后超时问题基本消失了。这个经验说起来简单但当时排查了好几天因为超时是偶发的不是每次都出现。后来我在日志里加了请求耗时记录才定位到是时间点的问题。5.3 文件编码问题一个让日报变成乱码的小细节这个问题困扰了我一个下午。日报在电脑上打开正常同步到手机之后中文全变成乱码。排查了半天发现是文件编码的问题。我的脚本默认用系统编码写文件而云盘同步过程中可能做了编码转换。解决办法很简单写文件的时候显式指定 UTF-8 编码。with open(output_path, w, encodingutf-8) as f: f.write(report_content)这个坑很小但很典型。任何涉及文件流转的自动化流程编码问题都值得提前检查一遍。5.4 提示词版本管理为什么我把指令存成了独立文件最开始我把提示词直接写在脚本里改的时候要改代码很不方便。后来有一次我调格式改完忘了保存第二天日报格式全乱了排查了半天才发现是提示词的问题。从那以后我把提示词抽成一个独立的文本文件脚本每次运行的时候读取这个文件。这样改提示词不用动代码而且可以用版本控制工具管理改错了能回滚。with open(prompt_template.txt, r, encodingutf-8) as f: prompt f.read()这个做法看起来多了一步但长期来看省了很多事。尤其是当你需要反复调提示词的时候独立文件比硬编码在代码里方便太多。6. 让日报更“懂你”几个提升实用性的进阶调整6.1 加入反馈循环让日报根据你的阅读习惯调整日报跑了一段时间之后我发现一个问题有些条目我每次都跳过但模型还是每天推给我。这是因为模型不知道我的偏好。于是我加了一个简单的反馈机制每天看完日报后我花十秒钟在文件里标记一下哪些条目有用、哪些没用。第二天采集脚本读取这个标记文件把被标记为“没用”的来源降权。这个机制很粗糙但效果立竿见影。跑了一周之后日报里我真正关心的内容比例明显上升了。实现方式也很简单就是在日报文件末尾加一个反馈区我手动填几个关键词脚本读取后调整权重。6.2 关键词动态更新让采集跟着项目走我的关注点不是固定的。这个月在做微信小程序下个月可能就在搞自动化测试。如果关键词写死日报很快就会变得不相关。我的做法是把关键词也存成一个独立文件每周手动更新一次。更新的时候不需要改代码只需要编辑这个文件。更进一步的话可以从我的任务管理工具里自动提取当前项目的标签作为关键词但这个我还没做因为手动更新一周一次的成本可以接受。6.3 日报的“周末模式”减少噪音周末我一般不处理工作信息但日报还是照跑结果周一早上积累了三天的日报看起来负担很重。后来我加了一个判断如果是周末日报只保留“必读”板块而且只保留最重要的三条。这样周末的日报变成了一份轻量提醒不会造成信息堆积。这个调整很小但体验提升很明显。自动化流程的设计很多时候就是要考虑人的使用节奏而不是一味追求“全自动”。7. 这套东西跑稳之后我的一些真实体会这套日报系统跑到现在大概三个月了中间修修补补很多次现在基本稳定。最大的感受是自动化的价值不在于“全自动”而在于“把重复劳动压缩成一次设计”。我花在搭建和调试上的时间大概两周就通过每天节省的半小时赚回来了。但更重要的是它让我每天的信息获取变得规律了不再依赖“今天有没有心情刷”。另一个体会是AI 工具的能力边界要用约束来定义。WorkBuddy 也好DeepSeek 也好它们本身不知道你要什么。你给的约束越清晰输出就越可用。我见过很多人抱怨 AI 生成的内容没法用其实大部分时候是指令太模糊。把“帮我总结一下”改成“从以下五个来源中提取过去 24 小时的内容按重要性分三档每档不超过五条每条两句话”效果完全不一样。最后分享一个小技巧如果你也想搭类似的流程先从最小可用版本开始。不要一上来就搞五个信息源、三种推送方式、复杂的反馈机制。先跑通“一个源、一个模型、一个文件”的链路确认能稳定运行之后再逐步加东西。我最早那版就是一个 Python 脚本加一个定时任务日报就是一段纯文本。后来所有的复杂度都是在这个最小版本上长出来的。 用WorkBuddy和DeepSeek打造AI日报：每天十点半自动推送微信
1. 为什么我要给 WorkBuddy 装一个“十点半闹钟”每天早上到工位第一件事不是打开编辑器而是先刷一遍各种信息源行业动态、竞品更新、社区里冒出来的新工具、昨天没看完的技术帖。刷完一圈半小时没了真正要动手的活儿还没开始。这个习惯持续了大半年直到我意识到一个问题——我每天花在“获取信息”上的时间其实大部分是重复劳动而且质量还不稳定。有时候刷到一条关键更新有时候全是噪音。WorkBuddy 这类 AI 助手工具的出现让我看到了把这套流程自动化的可能。它的核心能力是接收指令、调用模型、产出结构化内容。那为什么不干脆让它每天早上替我“读一遍”我关心的东西然后整理成一份日报直接推到我微信里这样我睁眼就能看到重点不用再手动翻。这个想法落地之后我把它做成了一个定时任务每天上午十点半WorkBuddy 自动跑一遍我预设的信息采集和总结流程生成一份 AI 日报通过微信推送给我的手机。整个过程不需要我干预也不需要我打开任何网页。这篇文章就是把这套东西从零到跑通的完整记录包括我踩过的坑、为什么这么设计、以及你如果想复现该怎么抄作业。适合谁看如果你每天也要花大量时间做信息筛选或者你已经在用 WorkBuddy、DeepSeek 这类工具但只停留在“手动问一句答一句”的阶段那这篇内容应该能帮你把它变成一个真正替你干活的“数字同事”。不需要你是自动化专家但需要你对命令行、定时任务、微信消息推送这些概念有最基本的了解。我会尽量把每一步的理由讲清楚让你不只是照抄而是知道为什么这么抄。2. 拆解需求一份“自动送进微信”的日报到底需要哪几块拼图2.1 信息从哪来日报的“原料”决定了它的价值上限在动手之前我先问自己一个问题这份日报到底要包含什么如果只是让 AI 随便生成一段“今日科技新闻”那价值几乎为零因为网上到处都是。我需要的是一份针对我个人关注点的定制化摘要。所以我列了一个信息源清单分成三类固定源我长期关注的几个技术社区、官方博客、更新日志页面。这些内容每天变化不大但一旦有更新就是重要信号。关键词源围绕我当前项目相关的技术词比如“AI Agent”“自动化测试”“微信小程序开发”等去抓取最新的讨论和文章。临时源我前一天晚上如果看到什么值得追踪的线索会手动加进一个待办列表第二天日报里要包含跟进结果。这三类信息源对应到 WorkBuddy 的指令设计上就是三个不同的采集任务。固定源用定时抓取关键词源用搜索接口临时源用文件读取。把它们的结果汇总再交给模型做总结和排序最终产出一份有优先级的日报。提示信息源不要贪多。我一开始加了十几个源结果日报长得像论文根本看不完。后来砍到五个核心源阅读体验反而好了很多。2.2 为什么选十点半时间点的选择比你想的更讲究十点半这个时间不是随便定的。我试过几个时间点最后发现十点半是最合适的原因有三个第一大部分我关注的社区和博客更新集中在早上八点到十点之间。太早跑抓不到当天的内容太晚跑我可能已经自己刷完了日报就失去了“替我筛选”的意义。第二十点半是我通常已经处理完紧急邮件、准备进入深度工作之前的一个空档。这时候收到一份日报我可以花五分钟扫一遍把重要的标记出来然后带着这些信息进入工作状态。第三从技术角度看十点半这个时间点的网络请求压力相对小一些。我试过整点跑有时候会遇到接口响应慢的情况。错开整点稳定性会好一点。这个经验是我踩了几次坑之后才总结出来的后面会详细说。2.3 微信推送的几种路径为什么我最终选了“文件传输助手”方案把内容送进微信听起来简单做起来有好几条路。我调研了三种方案方案实现方式优点缺点企业微信机器人通过 Webhook 推送稳定、官方支持需要企业微信环境个人使用门槛高公众号模板消息需要认证服务号推送体验好认证流程复杂个人开发者不友好文件传输助手通过桌面端自动化操作无需额外账号直接到手机依赖桌面端在线有封号风险我最终选了第三种但做了一些规避风险的调整。具体怎么做的在第四节会详细展开。这里先说结论不要用任何自动化工具去模拟登录或批量操作微信账号这是红线。我的做法是利用微信桌面端本身提供的文件传输能力把日报写成一个文件然后通过系统级的文件同步机制送到手机端。整个过程不涉及账号模拟只是文件流转。3. 把 WorkBuddy 变成“日报编辑”指令设计与模型调用的实操细节3.1 自定义指令的写法让模型知道“你是谁、你要什么”WorkBuddy 的核心是自定义指令。你给它一段提示词它按照提示词去执行任务。我一开始写的指令很随意比如“帮我总结一下今天的科技新闻”结果出来的东西完全不能用——要么太泛要么漏掉关键信息。后来我总结了一个指令模板包含四个部分角色设定告诉模型它是什么角色。我写的是“你是一个技术情报分析师服务于一个关注 AI 工具和自动化开发的工程师”。任务描述明确要做什么。比如“从以下信息源中提取过去 24 小时内的重要更新按重要性排序每条用两句话总结”。输出格式规定日报的结构。我要求它分成“必读”“值得一看”“可以跳过”三个板块每个板块下列条目。约束条件比如“不要包含广告内容”“如果某个源没有更新明确说明‘无更新’而不是编造内容”。这个模板我迭代了大概七八版每一版都是因为实际使用中发现了问题才改的。比如最早没有“无更新”这个约束模型会为了凑字数编一些不存在的内容这个坑后面会细说。3.2 调用 DeepSeek 做总结为什么不用更大的模型WorkBuddy 支持接入多种模型我试过几个最后日常跑日报用的是 DeepSeek。原因很实际日报这个任务对模型的推理深度要求不高但对响应速度和成本敏感。DeepSeek 在这两点上表现很好总结质量也够用。具体调用方式是在 WorkBuddy 的指令里指定模型和参数。我用的配置大概是这样的model: deepseek-chat temperature: 0.3 max_tokens: 2000 system_prompt: | 你是一个技术情报分析师... user_prompt: | 以下是今天采集到的信息源内容 {{collected_content}} 请按照以下格式生成日报...temperature 设成 0.3 是为了让输出稳定一些不要每次风格差异太大。max_tokens 设 2000 是因为日报太长没人看2000 个 token 大概能覆盖 10-15 条摘要刚好。注意不同模型对提示词的敏感度不一样。DeepSeek 对格式要求比较严格如果你在指令里写了“分成三个板块”它基本会照做。但有些模型可能会自由发挥。所以换模型的时候指令要重新调一遍。3.3 信息采集环节用脚本把“原料”准备好WorkBuddy 本身可以做一些简单的网页抓取但我发现对于复杂的采集任务还是用外部脚本更灵活。我的做法是写一个 Python 脚本负责三件事抓取固定源的 RSS 或更新页面提取标题和摘要。调用搜索接口用关键词拉取最新结果。读取本地待办文件把临时源的内容加进来。脚本跑完之后把结果写成一个 JSON 文件然后 WorkBuddy 读取这个文件作为输入。这样分工的好处是采集逻辑和总结逻辑解耦哪一部分出问题都好排查。脚本的核心逻辑大概是这样import feedparser import json import requests def collect_fixed_sources(): sources [ {name: 源A, url: https://example.com/feed}, {name: 源B, url: https://example.com/feed}, ] results [] for source in sources: feed feedparser.parse(source[url]) for entry in feed.entries[:5]: results.append({ source: source[name], title: entry.title, summary: entry.summary, link: entry.link }) return results def collect_keyword_sources(): keywords [AI Agent, 自动化测试, 微信小程序开发] results [] for kw in keywords: # 这里调用你使用的搜索接口 # 注意遵守目标站点的使用条款 pass return results def main(): all_content { fixed: collect_fixed_sources(), keyword: collect_keyword_sources(), temp: json.load(open(temp_sources.json)) } with open(daily_input.json, w) as f: json.dump(all_content, f, ensure_asciiFalse, indent2) if __name__ __main__: main()这个脚本我放在一台常开的机器上用系统的定时任务每天十点触发。跑完之后 WorkBuddy 在十点半接手读取daily_input.json生成日报。3.4 日报的格式设计让人愿意读下去的几个细节日报的格式我改了很多次最后固定成现在这个样子开头一句话今天总共采集了多少条筛选出多少条预计阅读时间几分钟。必读板块最多三条每条包含标题、来源、两句话总结、原文链接。值得一看板块最多五条格式同上但总结更短。可以跳过板块只列标题不展开。结尾一句“今天没有重大更新”或者“建议重点关注第 X 条”。这个格式的核心逻辑是分层。人的注意力是有限的如果所有条目看起来一样重要读者就会全部跳过。分层之后读者可以先看必读有时间再看值得一看没时间就直接关掉。这个设计是我从邮件摘要工具里学来的用下来确实有效。4. 微信推送的落地从文件到手机的那条“安全通道”4.1 为什么我放弃了“直接发消息”的方案最开始我想的是让脚本直接给我的微信发消息。调研了一圈发现个人微信没有官方的消息发送接口所有能实现这个功能的方案本质上都是模拟客户端操作或者逆向协议。这两条路我都不走原因很简单风险不可控。账号是我的核心通讯工具不值得为了一个日报去冒任何风险。所以我换了个思路不“发消息”而是“传文件”。微信桌面端本身支持文件传输助手我可以把日报写成一个 Markdown 文件放到一个特定目录里然后通过系统级的文件同步机制让手机端能访问到。整个过程不涉及任何微信协议的调用只是文件在本地和云端之间流转。4.2 用系统定时任务串联整个流程整个流程的串联靠的是系统定时任务。我用的是 Linux 环境所以用 crontab。如果你用 Windows可以用任务计划程序逻辑是一样的。我的 crontab 配置大概是这样# 每天上午 10:00 采集信息 0 10 * * * /usr/bin/python3 /home/user/scripts/collect.py /home/user/logs/collect.log 21 # 每天上午 10:30 生成日报并推送 30 10 * * * /usr/bin/python3 /home/user/scripts/generate_report.py /home/user/logs/report.log 21两个任务之间隔了半小时是为了给采集脚本留足时间。如果采集失败或者超时日报生成脚本会检测到输入文件缺失然后发一条“今日采集失败”的提示而不是生成一份空日报。这个容错设计很重要后面会讲为什么。4.3 文件同步的几种做法和我的选择把日报文件从电脑送到手机我试过几种方式云盘同步把日报写进云盘同步目录手机端装对应 App 查看。优点是稳定缺点是多装一个 App。邮件转发把日报作为邮件发给自己手机端邮件客户端查看。优点是通用缺点是邮件列表容易乱。本地网络共享在同一网络下通过文件共享访问。优点是快缺点是出门就用不了。最后我选的是云盘同步因为我的工作机本来就装了云盘客户端日报写进同步目录后手机端几乎立刻就能看到。而且云盘一般都有历史版本万一日报被覆盖了还能找回来。具体操作是日报生成脚本把内容写成一个 Markdown 文件文件名带日期比如daily-report-2025-01-15.md然后保存到云盘同步目录下的一个子文件夹里。手机端打开云盘 App进入这个文件夹就能看到当天的日报。提示文件名一定要带日期而且格式要统一。我一开始用“日报.md”这种固定名字结果每天覆盖前一天的想回看都找不到。改成带日期之后历史日报自动就积累下来了。4.4 实测中的稳定性问题和应对这套流程跑了一个多月遇到过几次问题这里列一下问题原因应对日报没生成采集脚本超时输入文件没写出来加超时检测失败时发提示而不是空日报日报内容为空某个信息源改版抓取规则失效加源健康检查连续失败三次就告警文件没同步云盘客户端掉线加一个本地备份目录同步失败时文件还在模型输出格式错乱提示词被意外修改把提示词存成独立文件脚本读取不硬编码这些应对措施看起来琐碎但正是它们让这套流程从“玩具”变成了“工具”。一个每天跑的任务稳定性比功能丰富更重要。5. 踩过的坑那些让我半夜爬起来改脚本的瞬间5.1 模型“编造”内容为什么我加了“无更新”约束最早版本的日报经常出现一些我根本没关注过的信息源的内容。一开始我以为是自己配置错了后来发现是模型在“补全”。当某个信息源没有更新时模型会倾向于编一些看起来合理的内容填进去而不是老老实实说“无更新”。这个问题在 AI 总结类任务里很常见。模型的训练目标是生成连贯的文本不是生成真实的文本。所以如果你不明确约束它就会为了连贯而牺牲真实。我的解决办法是在指令里加了一条硬约束“如果某个信息源在采集结果中不存在或为空必须在日报中明确写‘该源今日无更新’不得编造任何内容。”加了这条之后编造问题基本消失了。但代价是日报里会出现一些“无更新”的条目看起来有点啰嗦。后来我又优化了一下把“无更新”的源合并成一行放在结尾这样既真实又不占篇幅。5.2 时间点踩坑整点跑任务为什么容易失败前面提到我把任务时间从整点改到了十点半这里展开说一下原因。我最早设的是十点整跑采集十点半跑日报。结果发现十点整的时候采集脚本经常超时。排查之后发现两个原因第一十点整是很多定时任务集中触发的时间网络请求量大目标站点的响应速度会变慢。第二我关注的几个源本身也是在整点附近更新如果采集脚本跑得太早可能抓到的是更新前的内容。改成十点零七分跑采集之后超时问题基本消失了。这个经验说起来简单但当时排查了好几天因为超时是偶发的不是每次都出现。后来我在日志里加了请求耗时记录才定位到是时间点的问题。5.3 文件编码问题一个让日报变成乱码的小细节这个问题困扰了我一个下午。日报在电脑上打开正常同步到手机之后中文全变成乱码。排查了半天发现是文件编码的问题。我的脚本默认用系统编码写文件而云盘同步过程中可能做了编码转换。解决办法很简单写文件的时候显式指定 UTF-8 编码。with open(output_path, w, encodingutf-8) as f: f.write(report_content)这个坑很小但很典型。任何涉及文件流转的自动化流程编码问题都值得提前检查一遍。5.4 提示词版本管理为什么我把指令存成了独立文件最开始我把提示词直接写在脚本里改的时候要改代码很不方便。后来有一次我调格式改完忘了保存第二天日报格式全乱了排查了半天才发现是提示词的问题。从那以后我把提示词抽成一个独立的文本文件脚本每次运行的时候读取这个文件。这样改提示词不用动代码而且可以用版本控制工具管理改错了能回滚。with open(prompt_template.txt, r, encodingutf-8) as f: prompt f.read()这个做法看起来多了一步但长期来看省了很多事。尤其是当你需要反复调提示词的时候独立文件比硬编码在代码里方便太多。6. 让日报更“懂你”几个提升实用性的进阶调整6.1 加入反馈循环让日报根据你的阅读习惯调整日报跑了一段时间之后我发现一个问题有些条目我每次都跳过但模型还是每天推给我。这是因为模型不知道我的偏好。于是我加了一个简单的反馈机制每天看完日报后我花十秒钟在文件里标记一下哪些条目有用、哪些没用。第二天采集脚本读取这个标记文件把被标记为“没用”的来源降权。这个机制很粗糙但效果立竿见影。跑了一周之后日报里我真正关心的内容比例明显上升了。实现方式也很简单就是在日报文件末尾加一个反馈区我手动填几个关键词脚本读取后调整权重。6.2 关键词动态更新让采集跟着项目走我的关注点不是固定的。这个月在做微信小程序下个月可能就在搞自动化测试。如果关键词写死日报很快就会变得不相关。我的做法是把关键词也存成一个独立文件每周手动更新一次。更新的时候不需要改代码只需要编辑这个文件。更进一步的话可以从我的任务管理工具里自动提取当前项目的标签作为关键词但这个我还没做因为手动更新一周一次的成本可以接受。6.3 日报的“周末模式”减少噪音周末我一般不处理工作信息但日报还是照跑结果周一早上积累了三天的日报看起来负担很重。后来我加了一个判断如果是周末日报只保留“必读”板块而且只保留最重要的三条。这样周末的日报变成了一份轻量提醒不会造成信息堆积。这个调整很小但体验提升很明显。自动化流程的设计很多时候就是要考虑人的使用节奏而不是一味追求“全自动”。7. 这套东西跑稳之后我的一些真实体会这套日报系统跑到现在大概三个月了中间修修补补很多次现在基本稳定。最大的感受是自动化的价值不在于“全自动”而在于“把重复劳动压缩成一次设计”。我花在搭建和调试上的时间大概两周就通过每天节省的半小时赚回来了。但更重要的是它让我每天的信息获取变得规律了不再依赖“今天有没有心情刷”。另一个体会是AI 工具的能力边界要用约束来定义。WorkBuddy 也好DeepSeek 也好它们本身不知道你要什么。你给的约束越清晰输出就越可用。我见过很多人抱怨 AI 生成的内容没法用其实大部分时候是指令太模糊。把“帮我总结一下”改成“从以下五个来源中提取过去 24 小时的内容按重要性分三档每档不超过五条每条两句话”效果完全不一样。最后分享一个小技巧如果你也想搭类似的流程先从最小可用版本开始。不要一上来就搞五个信息源、三种推送方式、复杂的反馈机制。先跑通“一个源、一个模型、一个文件”的链路确认能稳定运行之后再逐步加东西。我最早那版就是一个 Python 脚本加一个定时任务日报就是一段纯文本。后来所有的复杂度都是在这个最小版本上长出来的。