1891字聊天记录，1B模型34秒排出三件事

把一周要交的东西从群聊、笔记和转发邮件里捞出来，这件事本身比做还烦。SlothDigest 的做法是：文件丢进 inbox 文件夹，跑一条命令，第二天早上拿到一份短简报——按截止时间排好的前三件优先事项，外加每个文件一句话摘要。

测试用的 inbox 里放了三份编造的文件：一封短邮件、一段约 35 行的群聊、一份笔记，合计 1,891 个字符。在作者自己的笔记本上，本地运行的 1B 参数 Gemma 模型用 34 秒给出了三条优先事项。多次运行耗时在 34 到 51 秒之间。文件内容是虚构消息，不涉及个人数据。

输出的三条任务是这样的：

• 回复供应商（周一前），来自 email.txt
• 为周一的评审准备 5 页幻灯片（周一前），来自 notes.md
• 周三晚上前填好预算表（周三前），来自 groupchat.txt

排序依据是截止日期还有几天。这次运行发生在周一，所以周一的条目算作今天到期。

一条命令跑起来的流程

整个东西是一个小的 Node 加 TypeScript 脚本。对每个文件，它向通过 Ollama 本地运行的 Gemma 3（1B）要严格 JSON：一句话摘要，加一组带截止时间的任务。Zod 校验每一个回答。所有文件的任务合并、去重、按截止时间排序，前三名写进 brief.json 和一个纯 HTML 页面。

运行方式：装 Ollama，执行 ollama pull gemma3:1b，然后 cd agent、npm install、npx tsx src/index.ts，HTML 视图再跑 npx tsx src/page.ts。

1B 模型容易演示，难被信任

作者列了五种实际翻车的情况，以及对应的处理代码：

1. 字段缺失。笔记文件里模型返回了一个没有截止时间的任务，校验连续两次拒掉整个文件，兜底逻辑又悄悄丢掉了两个真实任务。修法：缺失的截止时间记为 null，并在提示词里要求必须带上这个键。
2. 任务列表里混进非任务。模型把一个不是任务对象的东西塞进列表，校验再次失败。修法：校验前先过滤掉所有非对象，并要求只返回对象。
3. 卡进循环。Ollama 中止了一次请求，报 500 错误说触发了 token 重复上限，模型开始自我重复。修法：重试一次，再不行走纯文本兜底，保证简报总能产出。
4. 编造截止时间。对"给电工打电话，不急"这句，模型说截止时间是今天。第一版修法是检查日期词是否出现在文件任意位置，结果放过了"更新幻灯片（明天前）"，因为群里有人说"明天见"。有效的修法：日期词只有出现在与任务匹配的那一行源文本里，或出现在任务文本本身，才保留。
5. 两个请求被合并成一个。一封邮件说周五前发幻灯片、周一前回复供应商，模型把它变成一个错误任务"周一前给供应商发幻灯片"。加了一条拆分请求的提示词规则后，最后一次运行做对了。1B 模型不是确定性的，所以这算改善，不算解决。

被放弃的部分：最初想用 Mastra 搭脚手架，但在慢网络下安装器的 60 秒限制把它杀掉了，npm install 花了大约五分钟。于是直接调 Ollama 的 HTTP API。这是一个脚本，不是完整的 agent 框架。

本地跑的三个理由

文件从磁盘到 localhost 上的模型进程，没有账号、没有 API 密钥、什么都不上传。成本上，一次性下载不到 1 GB 之后，每次运行不花钱。脚本只和 localhost 通信，模型下载完成后不需要联网——不过作者注明没有在关掉 Wi-Fi 的情况下测过。模型名是一个环境变量，换别的开源模型不用改代码，但其他模型也还没测。

更大的托管模型很可能不会犯这些错，作者也没有测。但用小开源模型，每一个失败都看得见，每一个都能用普通代码修掉，这才是他信任输出的原因。

懒人收益与边界

三个文件、1,891 个字符，变成三条正确且有序的任务，用时 34 秒。局限也很清楚：摘要比任务弱，有一条还在提猫的生日；只认星期几、"今天"和"明天"，不认日历日期；只读 .txt 和 .md；只显示前三项任务；1B 模型仍会出错，简报需要人眼过一遍。目前是手动运行，下一步是用 Windows 任务计划程序做定时。

这个项目投的是 Hacktoberfest 开源 AI 挑战赛第三周"慢而稳"，同时报名 Gemma 最佳用例——整条流水线都跑在通过 Ollama 本地运行的 Gemma 3（1B）上。作者提到自己用 Claude 当结对程序员，把终端报错的照片贴回去，一个一个修，上面五个 bug 都是真实发生在他屏幕上的。