Rhythm & Routine

为什么做

Gap 期间，我同时在推进求职、学习、运动和多个个人项目。真正困难的不是“列出待办”，而是让长期目标穿过每天变化的时间约束：今天临时多了一件事，原计划如何调整；一个任务没完成，是继续、改期还是拆小；一周结束后，系统如何依据真实投入修正下一步，而不是重复给出理想化建议。

大多数计划工具擅长保存任务，大多数 AI 助手擅长生成一份看起来合理的清单，但两者都很难维护计划形成之后的状态。于是我开始构建 Rhythm & Routine：让 Agent 进入“目标—计划—日历—执行—复盘”的完整循环，同时把最终控制权留给用户。

查看 GitHub 仓库

我如何定义这个产品

这个产品不是 AI 日历，也不是聊天式 TODO。它的核心对象有明确分工：

• Goal / Milestone / Task 表达想达成什么，以及下一步可以执行什么。
• Routine 表达需要重复维持的节奏，不与一次性任务混为一谈。
• ScheduleBlock 把任务和现实时间连接起来，同时允许会议、通勤和休息等个人占位存在。
• ExecutionRecord / RhythmFeedback 记录真正发生了什么，而不是只看计划或打勾数量。
• Review 将日、周事实重新投影为进展、偏差与下一步建议。

我希望用户进入首页时，不需要在五个模块之间拼信息。“今天”页面因此同时呈现日历、完成进度、此刻建议、节奏发现与本周轨道，让用户能判断下一步该做什么，也能看见建议所依据的事实。

Agent 应该怎样参与计划

最初的实现容易把任何日程请求都升级为完整 Agent Loop：加载历史、读取目标、评估全天计划，再调用多个工具。流程虽然“智能”，但一个简单请求也可能产生冗长链路和高延迟。

我把问题从提示词上移到路由和执行策略：先判断这是单条固定日程、有界多事项，还是需要历史个性化的开放式全天规划，再选择对应的 Operation Profile。只有开放式规划才加载 Schedule Memory 与整日质量评估；明确的单条日程走短路径。Profile 同时定义允许调用的工具，Runtime 不会向模型介绍当前无权使用的能力。

这个设计带来三条产品原则：

1. 少步骤不能牺牲正确性。 冲突检查、权限、幂等、审计和失败恢复必须保留。
2. 计划变更必须可确认。 Agent 先生成 ChangeSet 草案，用户确认后才写入。
3. 个性化必须有证据。 节奏记忆只从已完成日程和实际投入中形成；显式时间与固定承诺始终优先。

最难的不是生成，而是状态正确

日程看似只是开始和结束时间，实际会跨越时区、改期、取消、重复 Routine、历史记录与 Review 统计。一次改期不能删除原始事实，但复盘又不能把新旧日程重复计算；Agent 会话刷新后需要恢复执行历史，但不能重复提交旧的变更草案。

这些问题让我把“界面是否看起来正确”追溯到完整数据链路：UI 展示、服务层投影、数据库历史和 Agent 合约必须对同一事实达成一致。它也促使我把评测从“回复像不像”扩展到 Router 命中、工具选择、工具非调用、安全不变量、上下文与工具批处理性能。

我学到的技巧

1. Agent 产品首先是状态机和控制系统

Prompt 只能影响一次生成，可靠产品还需要确定性路由、能力边界、工具权限、确认屏障、幂等与恢复。模型负责语义判断，系统负责守住事实和写入边界。

2. 用真实执行证据定义个性化

用户曾经计划在晚上学习，不等于晚上真的适合学习。Schedule Memory 必须区分计划、完成、取消、改期与实际投入，并允许显式要求覆盖历史推断。

3. 把评测放到具体失败层

“Agent 表现不好”无法指导迭代。只有把问题定位到意图识别、Profile 选择、上下文构建、工具调用、质量评估或最终写入，团队才知道应该修改哪一层，也能避免靠加 Prompt 掩盖结构问题。

4. AI 产品经理可以把日常问题推进成工程验证

这个项目让我持续跨过产品与实现的边界：从产品对象和交互规则，到数据库关系、时间语义、Agent Runtime、评测用例与浏览器验证。我不是为了证明“能写一个日历”，而是在验证如何让 AI 在复杂、长期、可变的个人场景中可靠地参与决策。

它证明什么

Rhythm & Routine 展示的是我处理 AI 产品复杂性的方式：从真实场景定义问题，把开放式智能拆成确定性的状态、权限和评测，再通过持续使用发现边界并推动下一轮迭代。

口径说明：独立项目，仍在持续构建；页面中的功能以当前本地版本为准，测试数字对应 2026-07-31 的已记录验证，不代表所有后续未提交改动均已完成验收。