保存，不应该悄悄取消提醒
区分未改期保存与时间修改；仅在应取消时取消，并明确反馈下一步。
CASE 01 / 微信生态 AI 产品
让记录安排，
像聊天一样简单。
小苔 · Tidybot / 把零散信息变成日程与待办。
真实截图 / 已裁去系统栏01 / PRODUCT OVERVIEW为什么做小苔
收到一条安排之后，
不该还有一串录入动作。
通知、临时安排和待办，常常先出现在聊天里。小苔从这类场景出发，尝试缩短“收到信息”与“整理为可管理事项”之间的路径。
01自然输入文字 / 语音 / 图片
→02结构化提取事项 / 时间 / 地点
→03核对与管理日历 / 待办 / 编辑
→04授权提醒用户选择提前量
问题源于实际记录与管理场景的观察，并通过功能测试持续验证。
02 / REAL SCREENS看得见的产品能力
从输入，
到有条理地管理。
点击任意界面放大，查看记录、编辑与提醒中的实际操作细节。
系统状态栏及系统手势条已裁去；微信导航、真实业务内容保留。公开素材中的第三方联系方式和用户头像已做处理。部分截图来自不同测试事项。
03 / IN THE PRODUCT真实产品演示
NO MOCKUPS. REAL MOMENTS.
不是概念图。
是正在使用的产品。
从真实操作里，看到记录、编辑、管理与提醒。
所有产品画面均来自实机截图或录屏。
已静音、裁去系统栏；部分片段加速并在画面标注。演示时长不代表 AI 处理耗时，提醒通知来自独立测试事项。
查看视频内容说明
0–16 秒：图片识别结果与事项详情、文字和语音结果回看。16–33 秒：年月切换、事项编辑与保存。33–41 秒：待办完成及恢复。41–55 秒：公众号消息、查询与帮助。55–61 秒：提醒时间选择及微信服务通知截图。
04 / WHY IT WORKS产品决策与边界
功能背后，
是可解释的产品判断。
保留明确的能力边界，
比包装“万能 AI”更重要。
01
MVP / 范围管理
先完成一个可以反复使用的闭环。
首版聚焦记录、解析、管理、提醒，而不是扩展为复杂协同工具。公众号承担轻量输入与查询，小程序承担日历、编辑及提醒管理。
- 取舍
- 暂不扩展多人协作和自动跨账号合并，优先让基础路径可用。
- 验证
- 通过真机记录、查询、编辑与提醒测试逐项验收。
02
AI EXPERIENCE / 意图分流
“今日安排”不是一条新日程。
测试中，相近表达曾落入 AI 记录队列。后续为明确查询建立同义指令和自然表达分流，同时保留真正的记录输入。
“我今天有什么安排？”查询现有日程“明天下午三点开会”提取并记录事项
- 取舍
- 不把所有话语都交给生成式模型；规则仅覆盖明确的意图。
03
ONBOARDING / 数据安全
独立使用，不必先理解账号关系。
将小程序独立注册与公众号关联解耦，让新用户先完成记录任务。老用户保留原有数据关系。
- 取舍
- 不同账号之间的数据自动合并暂未开放，不以便利性换取错绑风险。
- 反馈
- “未绑定公众号”不等于“无法使用小程序”。
05 / BUILD · TEST · LEARN迭代与证据
在真实使用里，
把问题一个个关掉。
技术为体验服务。
不把小样本或静态检查包装成业务增长。
给等待和结果一个清楚的位置
帮助按任务分组；识别结果结构化，提升信息获取效率与交互体验。
不让 AI 任务堵住提醒
异步任务采用有限并发，提醒独立轮询；通过隔离测试与生产任务回看验收。
不对外宣称未经同口径验证的性能提升率。已验证与待验证，分开说。
已完成核心流程真机验收，本页提供实机界面与录屏佐证。尚未建立公开用户规模、留存率或严格对照实验数据；下一步是持续收集真实试用反馈与任务成功率。
展开产品与技术协作视图
公众号 / 小程序→API + 意图分流→AI / 语音 / 图片解析→事项与任务存储→管理 / 授权提醒
后端使用 Python、FastAPI、PostgreSQL 与 Docker，支撑事项管理、异步识别及提醒状态同步。