1. 为什么我要给 WorkBuddy 设一个“十点半闹钟”每天早上到工位第一件事不是打开编辑器而是先刷一遍昨天夜里各个渠道冒出来的消息项目群里有没有人 我、待办列表里有没有逾期任务、昨天提交的几份材料有没有反馈、几个正在跑的数据任务有没有异常。这套动作熟练之后大概要花十五到二十分钟问题是它完全靠人肉记忆驱动一旦哪天起晚了或者被会议打断就容易漏掉关键信息。我用的协作工具是 WorkBuddy它本身有工作台、任务流、消息聚合这些模块日常协作够用。但它有个让我一直不太舒服的点信息是被动推给我的我得主动去看。工作台不会在早上主动告诉我“今天有三件事卡在你这里”也不会把散落在不同项目里的动态汇总成一份可读的简报。于是我就想能不能让 WorkBuddy 每天上午十点半自动把一份整理好的 AI 日报送到微信里我打开微信就能看完当天要处理的事。这个想法落地之后实际效果比我预期好很多。整条链路是定时触发 → 拉取 WorkBuddy 数据 → 调用大模型生成日报 → 推送到微信。核心关键词就是WorkBuddy、AI日报、微信小程序、deepseek-v4-flash、自动化。它解决的问题很具体把“人找信息”变成“信息找人”把分散的协作动态压缩成一份三分钟能读完的日报。适合谁来参考如果你也在用 WorkBuddy 或者类似的协作平台手头有基本的脚本能力想让日常信息流自动化起来这套方案可以直接抄。哪怕你完全没写过自动化脚本跟着下面的步骤走一遍也能跑通一个最小可用版本。我踩过的坑、参数怎么定、为什么这么选都会在下面讲清楚。2. 整体方案设计与技术选型拆解2.1 为什么是“定时 拉取 生成 推送”这条链路先把整件事拆成四个动作每个动作对应一个独立的问题。第一个动作是定时触发。日报要每天上午十点半送达那就需要一个可靠的定时器。可选方案有三种本机 crontab、服务器上的定时任务、以及云函数自带的定时触发器。我最终选的是服务器上的 crontab原因很直接——WorkBuddy 的数据拉取需要保持登录态或者调用接口放在一台长期在线的机器上最省心本机可能关机云函数冷启动和依赖管理反而更麻烦。第二个动作是拉取 WorkBuddy 数据。这一步是整个链路里最需要小心的地方。WorkBuddy 有网页端和工作台数据来源可以是页面接口也可以是它开放出来的数据出口。我的做法是优先走稳定的数据接口把当天需要关注的任务、消息、动态拉下来存成一个结构化的 JSON。这里不追求拉全量只拉“跟我相关且今天需要处理”的部分否则日报会变成流水账。第三个动作是调用大模型生成日报。原始数据是一堆字段直接推给人看没有意义。需要一个大模型把 JSON 转成自然语言简报按“今日重点、待办提醒、风险提示”这样的结构组织。模型选的是deepseek-v4-flash选它的理由后面单独讲。第四个动作是推送到微信。这里有个关键决策是推送到个人微信还是推送到微信小程序个人微信推送受限于平台规则稳定性和合规性都不好把握而微信小程序是我自己可控的载体用户打开小程序就能看到日报还能做历史归档和已读标记。所以我最终把日报落在一个自建的微信小程序里通过订阅消息或者小程序内的消息中心触达。提示整条链路的设计原则是“每个环节都可单独测试”。定时器能单独跑、拉取能单独跑、生成能单独跑、推送能单独跑。任何一环出问题都不会把整条链路拖死。2.2 模型为什么选 deepseek-v4-flash 而不是更大的模型日报生成这个任务本质上是一个“结构化数据转自然语言”的活不需要模型有很强的推理能力但对响应速度和成本很敏感。每天一次调用看起来量不大但如果日报要分多个板块、每个板块单独生成调用次数就会上去。deepseek-v4-flash 的定位就是快和便宜。我实测下来一份包含二三十条原始记录的日报生成耗时在几秒级别输出质量足够把“任务 A 逾期两天、负责人是某某、建议今天跟进”这种信息说清楚。更大的模型当然能写得更漂亮但在这个场景里属于杀鸡用牛刀而且延迟会让整个链路变慢。还有一个考虑是输出稳定性。日报需要固定结构模型如果太“聪明”容易自由发挥把格式打乱。flash 版本在指令遵循上反而更听话我给一个明确的输出模板它基本能照着填。这一点在实际跑自动化的时候非常重要格式一乱小程序端解析就会出问题。2.3 微信小程序作为载体的几个现实考量把日报放进微信小程序而不是直接发消息主要是三个原因。第一是可归档。日报是每天一份时间长了就是一个信息库。小程序里可以做一个列表页按日期倒序排列想看上周三的日报随时能翻。如果只是发一条消息翻历史记录很痛苦。第二是可交互。日报里的任务条目可以做成可点击的点进去跳到对应的详情或者标记已读。这种交互在纯消息里做不到。第三是合规和稳定。小程序的消息触达走的是平台提供的订阅消息能力用户主动订阅之后才能收到这个边界很清楚。相比之下直接往个人微信推消息的方案稳定性和可持续性都要打问号。当然小程序也有它的成本需要注册、需要年审、需要处理顶部导航栏高度这类适配问题。这些在后面实操部分会具体讲。3. 核心细节解析与实操要点3.1 WorkBuddy 数据拉取的三个关键点拉数据这一步我总结了三个必须处理好的点。第一是身份认证。WorkBuddy 的接口通常需要登录态直接裸调会被拒。我的做法是在服务器上维护一份有效的凭证定期刷新。这里要注意凭证不要硬编码在脚本里放在环境变量或者单独的配置文件里脚本只读不写。如果凭证过期脚本要能检测到并发出告警而不是静默失败。第二是数据范围。一开始我拉的是全量数据结果日报里塞了几百条记录根本没法看。后来改成只拉三类今天到期或已逾期的任务、过去 24 小时内 我的消息、我负责的项目的状态变更。范围一收窄日报的可读性立刻上来了。第三是字段清洗。接口返回的原始数据里有很多冗余字段比如各种内部 ID、时间戳、状态码。在送给模型之前我会先做一轮清洗把时间戳转成“今天/昨天/三天前”这种人类可读的表述把状态码转成中文描述。清洗做得越干净模型生成的质量越高也越省 token。# 数据清洗的简化示例 def clean_task(raw): return { title: raw[title], owner: raw[assignee_name], due: humanize_time(raw[due_at]), status: STATUS_MAP.get(raw[status], 未知), overdue_days: calc_overdue(raw[due_at]) }3.2 日报提示词的设计结构比文采重要给模型写提示词很多人一上来就追求“写得像人话”。但在日报这个场景里结构稳定比文采重要得多。我的提示词分三部分角色设定、输出结构、约束条件。角色设定很简单“你是一个协作助理负责把原始任务数据整理成简洁的日报。”输出结构我会明确给出模板比如固定三个板块今日重点、待办提醒、风险提示。约束条件包括每条不超过两行、不要编造数据、没有内容的板块直接省略。这里有个实操心得把输出格式写成 JSON 比写成 Markdown 更稳。因为小程序端要解析JSON 解析失败会直接报错而 Markdown 格式乱了不容易发现。我让模型输出 JSON字段固定小程序端按字段渲染出问题的概率大大降低。注意提示词里一定要加一句“如果某条数据缺失输出空字符串而不是猜测”。模型在信息不全的时候很容易脑补日报里出现编造的内容是很严重的问题。3.3 微信小程序端的两个适配细节小程序端看起来简单但有两个细节如果不处理体验会很差。第一个是顶部导航栏高度。小程序的顶部导航栏在不同机型上高度不一样如果直接用固定像素做布局在某些机型上内容会被挡住。正确做法是用wx.getSystemInfoSync()拿到状态栏高度和导航栏高度动态计算内容区的起始位置。这个坑我踩过日报标题被导航栏遮住了一半排查了半天才发现是高度写死了。第二个是缓存时间设置。日报数据每天更新一次但用户可能一天内多次打开小程序。如果每次都重新请求既浪费流量又慢。我的做法是设置一个合理的缓存时间比如 30 分钟在这个时间内直接读缓存超过之后再请求新数据。缓存 key 里带上日期避免跨天读到旧数据。// 小程序端缓存示例 const CACHE_KEY daily_report_${today}; const cached wx.getStorageSync(CACHE_KEY); if (cached Date.now() - cached.timestamp 30 * 60 * 1000) { return cached.data; }3.4 定时任务的可靠性设计crontab 看起来简单但有几个坑必须提前想到。时区问题。服务器如果是 UTC 时间crontab 里的“十点半”就是 UTC 十点半对应北京时间是下午六点半。我第一次跑的时候就是这个问题日报晚上才到。解决办法是在 crontab 里显式指定时区或者把服务器时间调成东八区。失败重试。网络抖动、接口限流都可能导致某天的拉取失败。我的做法是脚本内部做三次重试间隔递增。如果三次都失败就发一条告警到我的备用渠道而不是让这一天静默过去。日志留存。每次执行都要写日志记录开始时间、结束时间、拉取条数、生成耗时、推送结果。日志不用复杂一个文本文件按天切分就够。出问题的时候日志是唯一能还原现场的东西。4. 完整实操流程与关键环节实现4.1 环境准备与依赖安装先说一下我的运行环境一台长期在线的 Linux 服务器Python 3.10Node.js 18小程序端开发用。如果你用 Windows整体流程一样只是 crontab 换成任务计划程序。Python 侧需要装的依赖不多主要是 HTTP 请求库和 JSON 处理。我习惯用requests做请求用标准库的json处理数据。如果要做更复杂的调度可以引入schedule库但既然用 crontab就不需要了。pip install requests小程序端需要安装微信开发者工具这个去官方渠道下载即可。新建项目的时候选择“不使用云开发”因为我们的后端逻辑都在服务器上小程序只负责展示。4.2 拉取脚本的编写与调试拉取脚本是整个链路的地基我建议单独写、单独测不要和生成、推送混在一起。脚本的核心逻辑是读取凭证 → 请求接口 → 清洗数据 → 输出 JSON 文件。输出到文件而不是直接传给下一步是为了方便调试。你可以随时打开这个 JSON 看看数据对不对而不用每次都跑完整链路。import requests, json, os from datetime import datetime def fetch_workbuddy_data(token): headers {Authorization: fBearer {token}} resp requests.get(API_URL, headersheaders, timeout15) resp.raise_for_status() raw resp.json() cleaned [clean_task(t) for t in raw[tasks]] return cleaned if __name__ __main__: token os.environ[WORKBUDDY_TOKEN] data fetch_workbuddy_data(token) with open(raw_data.json, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) print(f拉取完成共 {len(data)} 条)调试的时候先手动跑一次看输出的 JSON 里字段对不对、时间格式对不对、有没有空值。这一步花十分钟能省掉后面大量的排查时间。4.3 调用 deepseek-v4-flash 生成日报生成脚本读上一步的 JSON拼提示词调模型拿到结果后做一次校验。提示词我放在一个单独的模板文件里方便调整。模板里用占位符标记数据插入的位置。调用的时候把 JSON 转成紧凑的字符串塞进去。def generate_report(tasks): prompt PROMPT_TEMPLATE.format(datajson.dumps(tasks, ensure_asciiFalse)) resp requests.post( MODEL_ENDPOINT, json{model: deepseek-v4-flash, messages: [{role: user, content: prompt}]}, timeout60 ) content resp.json()[choices][0][message][content] return json.loads(content) # 校验 JSON 合法性这里有个细节模型返回的内容可能带 Markdown 代码块标记比如 json 开头结尾。直接json.loads会失败。我的做法是先做一次字符串清洗把代码块标记去掉再解析。这个坑很常见第一次跑大概率会遇到。4.4 推送到微信小程序的实现推送这一步我走的是小程序的消息中心方案服务器把生成的日报写入一个数据存储小程序端通过接口拉取。同时如果用户订阅了通知就发一条订阅消息提醒。数据存储我用的是最简单的方案服务器上一个按日期命名的 JSON 文件小程序端通过一个只读接口访问。这个方案的好处是零依赖坏处是不适合高并发。但对于个人日报这种场景完全够用。# 保存日报 def save_report(report): today datetime.now().strftime(%Y-%m-%d) path f/data/reports/{today}.json with open(path, w, encodingutf-8) as f: json.dump(report, f, ensure_asciiFalse)小程序端做一个列表页和一个详情页。列表页展示历史日报的日期和摘要详情页展示完整内容。顶部导航栏高度用动态计算缓存用前面说的 30 分钟策略。4.5 crontab 配置与整链路联调所有环节单独测通之后用 crontab 串起来。# 每天上午 10:30 执行 30 10 * * * cd /path/to/project /usr/bin/python3 main.py /var/log/workbuddy_daily.log 21注意这里用了绝对路径因为 crontab 的环境变量和登录 shell 不一样用相对路径容易找不到文件。日志重定向到文件方便排查。联调的时候我建议先把时间设成几分钟后跑一次看整条链路通不通。通了之后再改成十点半。第一次联调大概率会在某个环节卡住这时候日志就是你的救命稻草。5. 常见问题与排查技巧实录5.1 拉取失败凭证过期与接口限流最常见的两个拉取失败原因一个是凭证过期一个是接口限流。凭证过期的表现是接口返回 401 或者类似的未授权状态。解决办法是脚本里加一个检测遇到 401 就触发凭证刷新流程刷新失败就告警。不要等到日报没收到才发现。接口限流的表现是返回 429 或者响应变慢。解决办法是控制请求频率拉取的时候加一个小的间隔不要短时间内连续请求。如果数据量大分页拉取每页之间 sleep 一下。问题现象可能原因排查方法解决方式返回 401凭证过期检查 token 有效期刷新凭证并更新配置返回 429请求过于频繁查看请求日志频率增加请求间隔分页拉取响应超时网络或服务端问题检查网络连通性增加超时时间加重试数据为空接口参数错误对比接口文档修正查询参数5.2 生成质量差数据太脏或提示词太松模型生成质量差九成问题出在输入数据或者提示词上。如果日报里出现“未知任务”“无负责人”这种内容说明输入数据里有空值没清洗干净。回到拉取脚本把空值处理掉该给默认值的给默认值。如果日报结构混乱、板块缺失说明提示词约束不够。检查提示词里有没有明确输出结构有没有加“不要编造”的约束。我一般会把提示词改到模型连续三次输出都符合预期才算稳定。提示模型输出不稳定的时候不要急着换模型。先把提示词和数据质量排查一遍大部分问题都能解决。5.3 推送延迟时区与调度问题日报没在十点半到先查时区。服务器时间是不是东八区crontab 里的时间是不是按服务器时间算的。这个问题我遇到过两次都是时区没对齐。如果时区没问题查 crontab 有没有正常触发。看日志文件有没有当天的记录没有记录说明任务根本没跑检查 crontab 配置和脚本权限。还有一种情况是任务跑了但很慢导致实际送达时间晚于预期。这时候要看生成环节的耗时如果模型响应慢可以考虑把提示词精简一下减少 token 数。5.4 小程序端显示异常缓存与适配小程序端最常见的问题是缓存导致的数据不更新。用户看到的是昨天的日报因为缓存没过期。解决办法是在缓存 key 里带上日期跨天自动失效。另一个是布局适配问题。不同机型导航栏高度不同内容被遮挡或者留白过多。用动态计算的方式解决不要写死像素值。问题现象可能原因解决方式显示旧日报缓存未过期缓存 key 带日期内容被遮挡导航栏高度写死动态计算高度列表空白接口返回异常检查接口和数据结构点击无响应事件绑定错误检查 bindtap 配置5.5 几个我踩过的坑和独家技巧坑一把凭证写进代码。一开始图省事token 直接写在脚本里。后来 token 过期要改代码改完还要重新部署非常麻烦。现在全部走环境变量改配置不用动代码。坑二日报内容太多。第一版日报把所有任务都列出来结果每天几十条根本没人看。后来砍到只保留“今天必须处理”的条数控制在十条以内阅读率立刻上来了。技巧一给日报加一个“一句话摘要”。在日报最顶部放一句模型生成的总结比如“今天有三件逾期任务需要优先处理”。用户扫一眼就知道今天什么情况不用往下翻。技巧二失败告警走独立渠道。日报推送失败的时候不要指望日报本身来通知你。我单独配了一个告警渠道链路任何一环失败都会收到提醒。技巧三保留原始数据。生成的日报存一份拉取的原始数据也存一份。有时候日报生成有问题回头对比原始数据就能快速定位是数据问题还是模型问题。6. 后续可以怎么扩展这套方案跑通最小版本之后我陆续加了一些扩展这里分享几个我觉得比较有价值的。第一个是周报自动生成。日报的数据攒一周周五下午自动生成一份周报按项目维度汇总。这个只需要在生成脚本里加一个分支读取过去七天的数据换一套提示词。第二个是异常主动提醒。日报是被动的但有些情况需要主动提醒比如某个任务逾期超过三天。我在拉取脚本里加了一个判断命中条件就立即触发一次推送不等日报。第三个是多端适配。现在日报只在小程序里看后面可以考虑同步一份到其他常用的协作工具里。核心逻辑不变只是多一个输出通道。这套方案的核心思路其实很简单把重复的信息整理工作交给自动化把人的精力留给真正需要判断的事。WorkBuddy 负责产生数据脚本负责搬运和加工模型负责翻译成人话小程序负责呈现。每个环节都不复杂串起来就是一个每天准时送达的 AI 日报。我在实际使用中最大的体会是自动化的价值不在于省了多少时间而在于消除了“忘记看”这个风险。以前靠人肉记忆总有漏的时候现在每天十点半准时到看不看是我的事但信息一定在那里。这种确定性比省下来的十几分钟值钱得多。
WorkBuddy自动化实践：用deepseek-v4-flash生成AI日报并推送微信小程序
1. 为什么我要给 WorkBuddy 设一个“十点半闹钟”每天早上到工位第一件事不是打开编辑器而是先刷一遍昨天夜里各个渠道冒出来的消息项目群里有没有人 我、待办列表里有没有逾期任务、昨天提交的几份材料有没有反馈、几个正在跑的数据任务有没有异常。这套动作熟练之后大概要花十五到二十分钟问题是它完全靠人肉记忆驱动一旦哪天起晚了或者被会议打断就容易漏掉关键信息。我用的协作工具是 WorkBuddy它本身有工作台、任务流、消息聚合这些模块日常协作够用。但它有个让我一直不太舒服的点信息是被动推给我的我得主动去看。工作台不会在早上主动告诉我“今天有三件事卡在你这里”也不会把散落在不同项目里的动态汇总成一份可读的简报。于是我就想能不能让 WorkBuddy 每天上午十点半自动把一份整理好的 AI 日报送到微信里我打开微信就能看完当天要处理的事。这个想法落地之后实际效果比我预期好很多。整条链路是定时触发 → 拉取 WorkBuddy 数据 → 调用大模型生成日报 → 推送到微信。核心关键词就是WorkBuddy、AI日报、微信小程序、deepseek-v4-flash、自动化。它解决的问题很具体把“人找信息”变成“信息找人”把分散的协作动态压缩成一份三分钟能读完的日报。适合谁来参考如果你也在用 WorkBuddy 或者类似的协作平台手头有基本的脚本能力想让日常信息流自动化起来这套方案可以直接抄。哪怕你完全没写过自动化脚本跟着下面的步骤走一遍也能跑通一个最小可用版本。我踩过的坑、参数怎么定、为什么这么选都会在下面讲清楚。2. 整体方案设计与技术选型拆解2.1 为什么是“定时 拉取 生成 推送”这条链路先把整件事拆成四个动作每个动作对应一个独立的问题。第一个动作是定时触发。日报要每天上午十点半送达那就需要一个可靠的定时器。可选方案有三种本机 crontab、服务器上的定时任务、以及云函数自带的定时触发器。我最终选的是服务器上的 crontab原因很直接——WorkBuddy 的数据拉取需要保持登录态或者调用接口放在一台长期在线的机器上最省心本机可能关机云函数冷启动和依赖管理反而更麻烦。第二个动作是拉取 WorkBuddy 数据。这一步是整个链路里最需要小心的地方。WorkBuddy 有网页端和工作台数据来源可以是页面接口也可以是它开放出来的数据出口。我的做法是优先走稳定的数据接口把当天需要关注的任务、消息、动态拉下来存成一个结构化的 JSON。这里不追求拉全量只拉“跟我相关且今天需要处理”的部分否则日报会变成流水账。第三个动作是调用大模型生成日报。原始数据是一堆字段直接推给人看没有意义。需要一个大模型把 JSON 转成自然语言简报按“今日重点、待办提醒、风险提示”这样的结构组织。模型选的是deepseek-v4-flash选它的理由后面单独讲。第四个动作是推送到微信。这里有个关键决策是推送到个人微信还是推送到微信小程序个人微信推送受限于平台规则稳定性和合规性都不好把握而微信小程序是我自己可控的载体用户打开小程序就能看到日报还能做历史归档和已读标记。所以我最终把日报落在一个自建的微信小程序里通过订阅消息或者小程序内的消息中心触达。提示整条链路的设计原则是“每个环节都可单独测试”。定时器能单独跑、拉取能单独跑、生成能单独跑、推送能单独跑。任何一环出问题都不会把整条链路拖死。2.2 模型为什么选 deepseek-v4-flash 而不是更大的模型日报生成这个任务本质上是一个“结构化数据转自然语言”的活不需要模型有很强的推理能力但对响应速度和成本很敏感。每天一次调用看起来量不大但如果日报要分多个板块、每个板块单独生成调用次数就会上去。deepseek-v4-flash 的定位就是快和便宜。我实测下来一份包含二三十条原始记录的日报生成耗时在几秒级别输出质量足够把“任务 A 逾期两天、负责人是某某、建议今天跟进”这种信息说清楚。更大的模型当然能写得更漂亮但在这个场景里属于杀鸡用牛刀而且延迟会让整个链路变慢。还有一个考虑是输出稳定性。日报需要固定结构模型如果太“聪明”容易自由发挥把格式打乱。flash 版本在指令遵循上反而更听话我给一个明确的输出模板它基本能照着填。这一点在实际跑自动化的时候非常重要格式一乱小程序端解析就会出问题。2.3 微信小程序作为载体的几个现实考量把日报放进微信小程序而不是直接发消息主要是三个原因。第一是可归档。日报是每天一份时间长了就是一个信息库。小程序里可以做一个列表页按日期倒序排列想看上周三的日报随时能翻。如果只是发一条消息翻历史记录很痛苦。第二是可交互。日报里的任务条目可以做成可点击的点进去跳到对应的详情或者标记已读。这种交互在纯消息里做不到。第三是合规和稳定。小程序的消息触达走的是平台提供的订阅消息能力用户主动订阅之后才能收到这个边界很清楚。相比之下直接往个人微信推消息的方案稳定性和可持续性都要打问号。当然小程序也有它的成本需要注册、需要年审、需要处理顶部导航栏高度这类适配问题。这些在后面实操部分会具体讲。3. 核心细节解析与实操要点3.1 WorkBuddy 数据拉取的三个关键点拉数据这一步我总结了三个必须处理好的点。第一是身份认证。WorkBuddy 的接口通常需要登录态直接裸调会被拒。我的做法是在服务器上维护一份有效的凭证定期刷新。这里要注意凭证不要硬编码在脚本里放在环境变量或者单独的配置文件里脚本只读不写。如果凭证过期脚本要能检测到并发出告警而不是静默失败。第二是数据范围。一开始我拉的是全量数据结果日报里塞了几百条记录根本没法看。后来改成只拉三类今天到期或已逾期的任务、过去 24 小时内 我的消息、我负责的项目的状态变更。范围一收窄日报的可读性立刻上来了。第三是字段清洗。接口返回的原始数据里有很多冗余字段比如各种内部 ID、时间戳、状态码。在送给模型之前我会先做一轮清洗把时间戳转成“今天/昨天/三天前”这种人类可读的表述把状态码转成中文描述。清洗做得越干净模型生成的质量越高也越省 token。# 数据清洗的简化示例 def clean_task(raw): return { title: raw[title], owner: raw[assignee_name], due: humanize_time(raw[due_at]), status: STATUS_MAP.get(raw[status], 未知), overdue_days: calc_overdue(raw[due_at]) }3.2 日报提示词的设计结构比文采重要给模型写提示词很多人一上来就追求“写得像人话”。但在日报这个场景里结构稳定比文采重要得多。我的提示词分三部分角色设定、输出结构、约束条件。角色设定很简单“你是一个协作助理负责把原始任务数据整理成简洁的日报。”输出结构我会明确给出模板比如固定三个板块今日重点、待办提醒、风险提示。约束条件包括每条不超过两行、不要编造数据、没有内容的板块直接省略。这里有个实操心得把输出格式写成 JSON 比写成 Markdown 更稳。因为小程序端要解析JSON 解析失败会直接报错而 Markdown 格式乱了不容易发现。我让模型输出 JSON字段固定小程序端按字段渲染出问题的概率大大降低。注意提示词里一定要加一句“如果某条数据缺失输出空字符串而不是猜测”。模型在信息不全的时候很容易脑补日报里出现编造的内容是很严重的问题。3.3 微信小程序端的两个适配细节小程序端看起来简单但有两个细节如果不处理体验会很差。第一个是顶部导航栏高度。小程序的顶部导航栏在不同机型上高度不一样如果直接用固定像素做布局在某些机型上内容会被挡住。正确做法是用wx.getSystemInfoSync()拿到状态栏高度和导航栏高度动态计算内容区的起始位置。这个坑我踩过日报标题被导航栏遮住了一半排查了半天才发现是高度写死了。第二个是缓存时间设置。日报数据每天更新一次但用户可能一天内多次打开小程序。如果每次都重新请求既浪费流量又慢。我的做法是设置一个合理的缓存时间比如 30 分钟在这个时间内直接读缓存超过之后再请求新数据。缓存 key 里带上日期避免跨天读到旧数据。// 小程序端缓存示例 const CACHE_KEY daily_report_${today}; const cached wx.getStorageSync(CACHE_KEY); if (cached Date.now() - cached.timestamp 30 * 60 * 1000) { return cached.data; }3.4 定时任务的可靠性设计crontab 看起来简单但有几个坑必须提前想到。时区问题。服务器如果是 UTC 时间crontab 里的“十点半”就是 UTC 十点半对应北京时间是下午六点半。我第一次跑的时候就是这个问题日报晚上才到。解决办法是在 crontab 里显式指定时区或者把服务器时间调成东八区。失败重试。网络抖动、接口限流都可能导致某天的拉取失败。我的做法是脚本内部做三次重试间隔递增。如果三次都失败就发一条告警到我的备用渠道而不是让这一天静默过去。日志留存。每次执行都要写日志记录开始时间、结束时间、拉取条数、生成耗时、推送结果。日志不用复杂一个文本文件按天切分就够。出问题的时候日志是唯一能还原现场的东西。4. 完整实操流程与关键环节实现4.1 环境准备与依赖安装先说一下我的运行环境一台长期在线的 Linux 服务器Python 3.10Node.js 18小程序端开发用。如果你用 Windows整体流程一样只是 crontab 换成任务计划程序。Python 侧需要装的依赖不多主要是 HTTP 请求库和 JSON 处理。我习惯用requests做请求用标准库的json处理数据。如果要做更复杂的调度可以引入schedule库但既然用 crontab就不需要了。pip install requests小程序端需要安装微信开发者工具这个去官方渠道下载即可。新建项目的时候选择“不使用云开发”因为我们的后端逻辑都在服务器上小程序只负责展示。4.2 拉取脚本的编写与调试拉取脚本是整个链路的地基我建议单独写、单独测不要和生成、推送混在一起。脚本的核心逻辑是读取凭证 → 请求接口 → 清洗数据 → 输出 JSON 文件。输出到文件而不是直接传给下一步是为了方便调试。你可以随时打开这个 JSON 看看数据对不对而不用每次都跑完整链路。import requests, json, os from datetime import datetime def fetch_workbuddy_data(token): headers {Authorization: fBearer {token}} resp requests.get(API_URL, headersheaders, timeout15) resp.raise_for_status() raw resp.json() cleaned [clean_task(t) for t in raw[tasks]] return cleaned if __name__ __main__: token os.environ[WORKBUDDY_TOKEN] data fetch_workbuddy_data(token) with open(raw_data.json, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) print(f拉取完成共 {len(data)} 条)调试的时候先手动跑一次看输出的 JSON 里字段对不对、时间格式对不对、有没有空值。这一步花十分钟能省掉后面大量的排查时间。4.3 调用 deepseek-v4-flash 生成日报生成脚本读上一步的 JSON拼提示词调模型拿到结果后做一次校验。提示词我放在一个单独的模板文件里方便调整。模板里用占位符标记数据插入的位置。调用的时候把 JSON 转成紧凑的字符串塞进去。def generate_report(tasks): prompt PROMPT_TEMPLATE.format(datajson.dumps(tasks, ensure_asciiFalse)) resp requests.post( MODEL_ENDPOINT, json{model: deepseek-v4-flash, messages: [{role: user, content: prompt}]}, timeout60 ) content resp.json()[choices][0][message][content] return json.loads(content) # 校验 JSON 合法性这里有个细节模型返回的内容可能带 Markdown 代码块标记比如 json 开头结尾。直接json.loads会失败。我的做法是先做一次字符串清洗把代码块标记去掉再解析。这个坑很常见第一次跑大概率会遇到。4.4 推送到微信小程序的实现推送这一步我走的是小程序的消息中心方案服务器把生成的日报写入一个数据存储小程序端通过接口拉取。同时如果用户订阅了通知就发一条订阅消息提醒。数据存储我用的是最简单的方案服务器上一个按日期命名的 JSON 文件小程序端通过一个只读接口访问。这个方案的好处是零依赖坏处是不适合高并发。但对于个人日报这种场景完全够用。# 保存日报 def save_report(report): today datetime.now().strftime(%Y-%m-%d) path f/data/reports/{today}.json with open(path, w, encodingutf-8) as f: json.dump(report, f, ensure_asciiFalse)小程序端做一个列表页和一个详情页。列表页展示历史日报的日期和摘要详情页展示完整内容。顶部导航栏高度用动态计算缓存用前面说的 30 分钟策略。4.5 crontab 配置与整链路联调所有环节单独测通之后用 crontab 串起来。# 每天上午 10:30 执行 30 10 * * * cd /path/to/project /usr/bin/python3 main.py /var/log/workbuddy_daily.log 21注意这里用了绝对路径因为 crontab 的环境变量和登录 shell 不一样用相对路径容易找不到文件。日志重定向到文件方便排查。联调的时候我建议先把时间设成几分钟后跑一次看整条链路通不通。通了之后再改成十点半。第一次联调大概率会在某个环节卡住这时候日志就是你的救命稻草。5. 常见问题与排查技巧实录5.1 拉取失败凭证过期与接口限流最常见的两个拉取失败原因一个是凭证过期一个是接口限流。凭证过期的表现是接口返回 401 或者类似的未授权状态。解决办法是脚本里加一个检测遇到 401 就触发凭证刷新流程刷新失败就告警。不要等到日报没收到才发现。接口限流的表现是返回 429 或者响应变慢。解决办法是控制请求频率拉取的时候加一个小的间隔不要短时间内连续请求。如果数据量大分页拉取每页之间 sleep 一下。问题现象可能原因排查方法解决方式返回 401凭证过期检查 token 有效期刷新凭证并更新配置返回 429请求过于频繁查看请求日志频率增加请求间隔分页拉取响应超时网络或服务端问题检查网络连通性增加超时时间加重试数据为空接口参数错误对比接口文档修正查询参数5.2 生成质量差数据太脏或提示词太松模型生成质量差九成问题出在输入数据或者提示词上。如果日报里出现“未知任务”“无负责人”这种内容说明输入数据里有空值没清洗干净。回到拉取脚本把空值处理掉该给默认值的给默认值。如果日报结构混乱、板块缺失说明提示词约束不够。检查提示词里有没有明确输出结构有没有加“不要编造”的约束。我一般会把提示词改到模型连续三次输出都符合预期才算稳定。提示模型输出不稳定的时候不要急着换模型。先把提示词和数据质量排查一遍大部分问题都能解决。5.3 推送延迟时区与调度问题日报没在十点半到先查时区。服务器时间是不是东八区crontab 里的时间是不是按服务器时间算的。这个问题我遇到过两次都是时区没对齐。如果时区没问题查 crontab 有没有正常触发。看日志文件有没有当天的记录没有记录说明任务根本没跑检查 crontab 配置和脚本权限。还有一种情况是任务跑了但很慢导致实际送达时间晚于预期。这时候要看生成环节的耗时如果模型响应慢可以考虑把提示词精简一下减少 token 数。5.4 小程序端显示异常缓存与适配小程序端最常见的问题是缓存导致的数据不更新。用户看到的是昨天的日报因为缓存没过期。解决办法是在缓存 key 里带上日期跨天自动失效。另一个是布局适配问题。不同机型导航栏高度不同内容被遮挡或者留白过多。用动态计算的方式解决不要写死像素值。问题现象可能原因解决方式显示旧日报缓存未过期缓存 key 带日期内容被遮挡导航栏高度写死动态计算高度列表空白接口返回异常检查接口和数据结构点击无响应事件绑定错误检查 bindtap 配置5.5 几个我踩过的坑和独家技巧坑一把凭证写进代码。一开始图省事token 直接写在脚本里。后来 token 过期要改代码改完还要重新部署非常麻烦。现在全部走环境变量改配置不用动代码。坑二日报内容太多。第一版日报把所有任务都列出来结果每天几十条根本没人看。后来砍到只保留“今天必须处理”的条数控制在十条以内阅读率立刻上来了。技巧一给日报加一个“一句话摘要”。在日报最顶部放一句模型生成的总结比如“今天有三件逾期任务需要优先处理”。用户扫一眼就知道今天什么情况不用往下翻。技巧二失败告警走独立渠道。日报推送失败的时候不要指望日报本身来通知你。我单独配了一个告警渠道链路任何一环失败都会收到提醒。技巧三保留原始数据。生成的日报存一份拉取的原始数据也存一份。有时候日报生成有问题回头对比原始数据就能快速定位是数据问题还是模型问题。6. 后续可以怎么扩展这套方案跑通最小版本之后我陆续加了一些扩展这里分享几个我觉得比较有价值的。第一个是周报自动生成。日报的数据攒一周周五下午自动生成一份周报按项目维度汇总。这个只需要在生成脚本里加一个分支读取过去七天的数据换一套提示词。第二个是异常主动提醒。日报是被动的但有些情况需要主动提醒比如某个任务逾期超过三天。我在拉取脚本里加了一个判断命中条件就立即触发一次推送不等日报。第三个是多端适配。现在日报只在小程序里看后面可以考虑同步一份到其他常用的协作工具里。核心逻辑不变只是多一个输出通道。这套方案的核心思路其实很简单把重复的信息整理工作交给自动化把人的精力留给真正需要判断的事。WorkBuddy 负责产生数据脚本负责搬运和加工模型负责翻译成人话小程序负责呈现。每个环节都不复杂串起来就是一个每天准时送达的 AI 日报。我在实际使用中最大的体会是自动化的价值不在于省了多少时间而在于消除了“忘记看”这个风险。以前靠人肉记忆总有漏的时候现在每天十点半准时到看不看是我的事但信息一定在那里。这种确定性比省下来的十几分钟值钱得多。
