做「AI 日省待办」这段时间，被问得最多的一个问题大概是：
既然是 AI 待办，怎么小程序里连对话框都没有？
打开小程序，确实只有提醒、日历、联系人这些常规列表，没有「帮我记一下」的输入框，也没有内置助手。这不是还没做，而是从一开始就不打算做。
先说说我自己踩过的坑
我日常用 Claude Code、OpenClaw 处理邮件和文档。流程往往是：把邮件贴进去，让它帮忙提炼待办——这一步很顺。麻烦出在「然后呢」。
复制到系统提醒里，字段对不上，也没有「这封邮件对应哪条待办」的记录；丢进飞书待办，对个人来说客户端偏重，脚本也不好接；先记在笔记里，到期不会推，第二天还得自己翻。
来回试了几轮之后，我需要的其实不是「又一个能聊天的 App」，而是一块 专门存待办、能对接现有工具、能在微信里提醒 的小服务。AI 日省待办就是按这个缺口做的。
为什么不在小程序里做对话框
现在不少 App 一上「AI 能力」，就先加一个聊天入口。待办、日历、笔记莫不如此。用户也习惯用「有没有对话框」来判断是不是 AI 产品。
我的看法比较简单：理解人话这件事，交给离上下文最近的工具去做就够了——比如正在读邮件的 Claude Code，或者挂着 Skills 的 OpenClaw。待办小程序只要把数据存稳、字段写清楚、提醒发出去，不必再养一套对话能力。
如果在小程序里再做一遍自然语言解析，至少有三处不划算：
- 每个 App 各做一套，质量和维护成本都一般，还和外面的 Agent 抢同一段上下文。
- 「AI 帮我记了」不好追溯，出了问题很难核对是谁、什么时候、记了什么。
- 用户搞不清到底是 Agent 在编排，还是小程序内置模型在猜，排错更痛苦。
所以产品边界写得很死：不做内置聊天，不做自然语言输入，以后也不打算加。 不是反 AI，而是不想在一个该「存数据」的地方再塞一个「聊天」。
三块东西，各干各的
我把分工拆成三块，用起来反而清楚：
| 谁 | 干什么 | 你怎么接触 |
|---|---|---|
| 外面的 Agent | 读邮件、会议纪要，决定记成提醒还是日历 | Claude Code、OpenClaw、Cursor 等 |
命令行 ai-todo | 把标题、时间、联系人写成结构化数据 | npm i -g @xiaolinstar/ai-todo-cli |
| 微信小程序 | 查看、改一改、勾完成、开微信提醒 | 微信搜索 AI 日省待办 |
可以把它想成：Agent 负责理解，服务负责存储，小程序负责确认。 人最后点一下「完成」，比在一堆对话记录里找待办踏实。
举个真实的用法
领导邮件里写：「这周五前把 Q2 报销单交给财务。」
Agent 读完邮件，在终端里创建一条提醒（示意）：
ai-todo reminder create \
--title "提交 Q2 报销单给财务" \
--due "2026-07-04T18:00:00+08:00" \
--source email \
--external-id "<邮件 Message-ID>" \
--json我打开小程序，能看到这条提醒；需要的话在编辑页打开微信订阅提醒。邮件后面如果还有来回，Agent 用同一个 external-id 先查再改，不会堆出一排重复的「报销报销报销」。
全程没有在小程序里打字聊天，但该记的记了，该提醒的也能推到微信。
那小程序还重要吗
重要。Agent 写错标题、时间偏了半 hour，总得有个地方改；事情做完了，也得有个勾。这些操作不需要对话，列表 + 表单就够了。
另外，微信订阅提醒只能在小程序里授权。通过命令行创建的待办，默认不会自动推微信；要推送，得进小程序编辑页打开开关。这是微信的机制，不是偷懒。
适合谁，不适合谁
比较适合：
- 已经在用 Claude Code、OpenClaw 等，希望待办能接进现有工作流；
- 愿意用命令行或 Skill，而不是在 App 里反复聊天；
- 只要个人提醒、日历、联系人，不要项目看板那一套。
可能不适合：
- 只想打开 App、说一句话就记待办，完全不想碰 Agent 或 CLI；
- 需要团队协作、OKR、复杂排期——飞书、Notion 一类更合适。
我刻意把产品做小，不是能力不够，而是 个人轻办公 这条线，做大了反而和飞书、钉钉正面撞。
小结
AI 日省待办没有 AI 对话框，是因为我认定：对话发生在 Agent 那边，存储和提醒发生在数据层这边。 小程序做好查看、修改、完成和微信触达，比再做一个「迷你 ChatGPT」有用。
如果你也在邮件和 Agent 之间缺一块「待办落库」的拼图，可以微信搜索 AI 日省待办 试一条提醒；开发者见 快速上手，接 Agent 见 Agent 接入。产品背景见 产品介绍。