我让 AI 每天早上读日志向我汇报：自动晨报搭建实录

为什么要把记录变轻

以前的记录是零散的备忘录：有的在微信收藏，有的在某个 App，有的在浏览器标签页里「等待关闭」。月底回看的时候，经常发现自己完全不记得某个重要决定为什么这么定的。后来想明白一件事：把写记录这件事变成系统，而不是习惯。习惯会中断，系统不会。

底座：记录长什么样

现在的形态很简单：每天一个 Markdown 文件，按项目分区块，每个区块用 bullet points 列事项。谁来写就在自己的段落前署名，几个 AI 工具和我本人落在同一个文件里，先读后写、互不覆盖，谁做了什么、改了什么，段落里都留痕。写入一律走追加，禁止全量覆写——这条铁律是被事故教育出来的：早期有个工具保存时用了覆写，把当天已经写好的内容清了个干净。从那以后所有写入强制追加，再没丢过一个字。

工具没有「当然不会这样做」的直觉，规则必须写进代码。

这样的记录积累几个月，自然就成了每个项目的时间线数据源，回看某件事的来龙去脉，打开文件就有。但新的问题跟着来了：记录越勤，我读得越少。每天几百行，都是当天就知道的事，谁会回头读自己的流水账？

第一版：不聪明的摘要也是摘要

第一版晨报是纯脚本，没有一行大模型：把待办清单里的逾期项、今明到期项、高优先级项，加上昨日日志的动态和风险库里的活跃风险，格式化成一条消息。干跑验证那天数字很可观：逾期 15 条、高优先级 38 条、活跃风险 12 条。

但很快发现问题：这是清单，不是汇报。它知道哪些事悬着，却讲不出「昨天到底发生了什么、今天最该盯哪件」。日志是人写的自然语言，不是一个能被聚合的表。结构化数据可以汇总，叙述必须有读者——那就给日志找一个每天准点上班的读者。这一版不算白干：清单版后来成了整套系统的保底层，模型掉线时顶上去的就是它。

推送通道：三个方案毙掉两个

消息往哪推，比想象中曲折。先看的是微信里的官方机器人方案：装一个常驻 Agent，消息走它的机器人通道。查完果断放弃——那条通道的设计意图是双向对话，官方对机器人消息设了 24 小时会话窗口，凭证还来自用户的上一条消息，天生不适合单向定时推送；而且每条消息都要过一遍大模型，花 token 不说，还得给它开一整套系统权限，杀鸡用牛刀。社区有个第三方壳仓库看起来省事，翻了下提交记录：建仓第二天最后一次提交，弃养了。

最后选了自建：一台自己的云服务器上部署 bark-server——一个很小的 Go 二进制，systemd 常驻，只监听本机回环地址，对外由 nginx 在 cybersynth.cn 的 443 上加一段反代，注册接口直接 403 锁死，不给陌生人开抽屉。手机上的 Bark 客户端绑定自建服务器，走苹果官方推送，全链路私有。从拍板到手机收到第一条测试推送，一个晚上。中间还踩了个坑：服务器下载那个 16.8MB 的二进制，走镜像只下到 2.1MB，文件头校验都过不了——镜像把大文件截断了。教训很干脆：镜像下载必须比对官方发布的确切字节数，不符就本机下载再传上去。候选里还有企业微信和两个聚合推送服务，都留作备胎——真到了「消息必须进微信」那天再启用，主通道还是自己的。

三轮迭代：从数据清单到个人助理

通道通了，晨报本身又迭代了三轮，方向只有一个：让它越来越像个助理，而不是一块仪表盘。定稿形态是——DeepSeek 每天早上读上一个工作日的日志原文（赶上假期就往前找，最多 7 天），连同紧迫待办和高危风险，按项目分节用大白话汇报昨天干了什么、下一步是什么，末尾固定一节「今日建议优先」，必须给出理由。它开口先叫我一声「盟主」——我给自己起的花名，叫顺口了。后来结构化库里新添的提资逾期这类状态，也一并喂进素材：叙述讲进度，清单管催办，两路信息在一条推送里合流。

好几个细节是被反馈逼出来的。「时间节点强制保留」，是因为模型复述时爱把「周五前」「月底」这类信息抹掉只留结论——对汇报来说，砍掉时间等于砍掉一半信息；篇幅不设死限、以 500 到 900 字为宜，是发现硬性字数会逼它丢内容凑格式。拿历史日志试跑成稿那天，我第一次有「这活儿真有人替我干了」的感觉。

失败降级：比主链路更花心思的部分

这套系统真正花心思的，其实是「它坏了怎么办」。回头看，降级设计占了整个工程一半以上的考量：

• 模型失败退回清单版：DeepSeek 调不通或超时，自动退回第一版那套纯脚本清单——AI 版是增量，规则版是保底，每天 8:30 一定有东西到达；
• 推送截断保险丝：苹果推送单条有 4KB 上限，通道上加 3300 字节截断——宁可尾部截断，不能整条发不出去；后来又补了超长自动分条和排版锚点；
• 错过定时补推：计划任务设在 8:30，但我经常 9:30 才开机，给任务加上「错过即补跑」；再后来加了唤醒和电源限制解除，关着机也能按时到达；
• 数据源只读加跳过：晨报读的库一律只读，上游表结构一变，相关段落自动跳过而不是报错——上游改库，早报不陪葬。

主链路决定好的时候有多好，降级链路决定坏的时候它还在不在。

闭环带来的意外改变

跑稳之后最有意思的变化，不是每天省下读日志的十分钟，而是写日志这件事本身变认真了。知道明早有个「读者」要拿这份日志向我自己汇报，写的时候会不自觉把因果关系写清楚——模型复述不清的段落，几乎都是我自己写得含糊的段落。晨报成了日志质量的每日抽检：它读不懂，就是我没写明白。更实际的收获也有：逾期和风险不再躺在库里等人想起，每天被动出现在锁屏上，拖延的成本从「忘了」变成了「看得见」。

给想尝试的人的建议

不用一开始就很完善。先从「每天一个文件，每件事一个区块」开始，能坚持记就够了。想再进一步，按这个顺序加：先分清结构化待办和自由叙述两份数据，再接定时任务和一条可靠的推送通道，最后才轮到模型——而且动手接模型之前，先把它失败时的样子设计好。让记录变轻的关键从来不是少写，而是有人替你读：读的那位是 AI 也行，只要每天早上，它真的在。