01项目概览
AI 微信群聊日报
让 WorkBuddy 每天整理群聊，把可参加的活动和机会带到一页日报里。
群多、消息多，真正想参加的活动很容易被聊天淹没。我把阅读规则、定时任务和本地网页连接起来：每天汇总前一天的群聊，提取活动时间、地点、费用和参加方式，保留来源，再按日期浏览和筛选。
本页截图沿用实际产品界面，群名与活动内容替换为演示数据；真实运行统计列于完成情况。
02项目目标
从消息到行动
我需要知道的是“有哪些事可以参加、什么时候、怎么报名”，而不是再读一遍群聊摘要。因此，整理单位从一条条消息改成一次活动或一个机会，把分散在文字、图片和链接中的信息放在一起。
减少查找
把多个群的线索汇总到同一页，按分类、地域、参与方式与费用筛选。先看到与当前位置有关的活动和线上活动。
保留判断依据
活动卡片保留来源群、发布时间和原消息入口。信息不明确就标记待核实，让用户能够回看依据，再决定是否参加。
03产品功能
使用过程
设置规则
群聊默认进入卡片栏，也可以改为精简或忽略。精简保留活动信息，只压缩展示；忽略需要填写原因，后续扫描会在读取正文和调用模型之前排除该群。
个人关注背景、位置关键词和默认筛选统一在设置中维护。修改群规则会影响后续整理，已经生成的日报保留当时的处理结果。
定时整理
WorkBuddy 每天 00:15 启动任务，读取最新规则，汇总前一天 00:00 至当天 00:00 的消息。例如，9 月 17 日凌晨运行，产物仍归入 9 月 16 日。
任务依次检查本地数据、准备消息、分批分析、校验结果和保存日报。完成后只回复日期、状态、条数、缺口与本机访问入口，不再把整份报告复制到任务对话里。
筛选线索
打开日报后，先按日期选一天，再按地域、分类、线上线下或费用筛选。搜索不只匹配标题，也会查找活动详情、标签、来源和注释；标题或标签命中的结果排在前面。
例如，输入“AI 产品”，可以集中看到相关交流。暂时改动筛选不会改变长期规则；点击“重置筛选”，恢复设置中保存的默认条件。
核对来源
卡片将时间、地点、费用和参加方式单独列出。展开“核对来源”可以查看支持这条活动的原消息与图片。同一活动出现多条来源时合并展示，保留各自的发布时间。
点开链接后再返回，页面恢复原来的日期、筛选条件和阅读位置，避免每次重新找刚才的活动。
04实现逻辑
调度、分析与展示
WorkBuddy 负责按时启动任务；Python 执行器负责读取、批处理与保存；模型负责理解消息；网页负责浏览和设置。日报的正式结果由执行器校验后写入，不让调度对话另写一份报告。
技术分工
| 部分 | 使用的技术 | 在项目中的作用 |
|---|---|---|
| 定时启动 | WorkBuddy 自动化 | 每天 00:15 调用同一个 Skill 入口，明确日报归属日期与完成检查。 |
| 本地处理 | Python · SQLite 读取 | 只读本机已同步数据，按群规则和时间窗口准备消息，保存处理进度。 |
| 图片识别 | 本地 Vision OCR | 提取图片文字与二维码链接，为活动提取补充材料。 |
| 模型分析 | Codex CLI · JSON Schema | 将消息转为结构化活动，输出时间、地点、来源等固定字段。 |
| 网页与配置 | HTML · CSS · JavaScript Python 本机服务 | 按日期读取日报，提供筛选、搜索、来源展开和设置入口。 |
调用顺序是 WorkBuddy → Python 执行器 → Codex CLI。WorkBuddy 负责定时启动；执行器按配置调用 Codex CLI 分析消息，再校验并保存结果。Codex CLI 是模型调用工具，当前配置未指定具体模型型号。
代码结构
scripts/run.py统一入口- 将 Skill 命令交给本机执行器，手动整理与定时任务使用同一条路径。
config/ · methods/阅读规则- 保存群处理、个人关注、模型配置，以及活动和招聘两种阅读方法。
digest_reader.py消息准备- 按日期与群规则整理本机已同步消息，保留来源标识和读取缺口。
digest_model.py模型分析- 组合阅读规则、个人背景和消息，调用模型并检查输出格式。
digest.py流程管理- 衔接读取、分析、来源校验、合并和发布，记录批次进度。
digest_web.py · assets/本地网页- 提供日报接口和页面，处理筛选、设置、图片查看及阅读位置恢复。
一条消息的去向
程序先确定消息属于哪一天、哪个群，以及该群采用什么阅读方法。文字、链接摘要和本地图片识别结果组成批次，再连同个人关注背景交给模型。
字段格式、来源编号与链接均需校验
无来源的链接不能直接进入日报
合并同一活动的来源
程序决定放入卡片栏或精简栏
模型只分析本批材料，不获得发送消息或修改配置的工具。微信数据保持只读，聊天里的指令也只作为待分析内容。
保存与续跑
每一天只有一份正式日报，保存在 days/YYYY-MM-DD/。中间材料按运行编号保存，成功批次记入进度；失败后沿原运行编号继续，避免重复处理整天消息。
9 月 16 日的一次任务中，程序拒绝了模型生成的无来源链接。续跑只重做失败批次，再合并进原日报。
网页通过本机服务读取结果，默认保留最近 30 天。它是个人电脑上的阅读工具，当前没有部署公开群聊站点。
05我的工作
把规则做成产品
我负责定义想读到什么、哪些群怎样处理，以及日报怎样帮助我作出参加决定；与 AI 协作将这些要求落实到阅读规则、执行器、定时配置和网页交互，并持续按实际使用调整。
- 确定整理目标从泛泛的聊天总结，收敛为可参加活动与机会，要求补齐时间、地点、费用和参加方式。
- 划分群处理用卡片、精简、忽略承接不同需求；忽略写明原因，精简仍保留合格活动。
- 设计阅读界面通过与 AI 反复交互，打磨简洁、美观的 UI 设计稿，沉淀为可复用的 Templates，再应用到日报界面。
- 每日浏览线索每天自动整理完成后，快速浏览日报，筛选值得参加的活动与跟进的机会。
06完成情况
连续运行
9 月 14—18 日连续运行，每天整理前一天的群聊，将消息汇总为活动与机会线索。
| 运行日期 | 处理结果 |
|---|---|
| 2026-09-14 | 1,279 条消息 → 75 条线索 |
| 2026-09-15 | 3,103 条消息 → 114 条线索 |
| 2026-09-16 | 2,836 条消息 → 109 条线索 |
| 2026-09-17 | 3,406 条消息 → 97 条线索 |
| 2026-09-18 | 2,774 条消息 → 94 条线索 |
已完成每日调度、群规则配置、图片识别、模型提取、失败续跑，以及日报浏览、搜索和来源核对。