第一幕 · 拆成多引擎（规则 + LLM 混合）
最初把能力拆成独立引擎：T02 拆解 / T03 排程 / T04 反馈解析 / T05 重排 + Orchestrator 路由。优点是职责清楚、易单测、易定位。
代价开始显现：跨模块数据结构必须严格一致，中间任一层格式偏一点，用户看到的就是「整个计划都不对」，但根因藏在任意一层的缝隙里。
SYSTEM · CASE STUDY
灵活规划（Replan）
从实际行为而不只是计划中学习的个人工作流优化系统。
它观察我真正做了什么，理解执行与计划的偏差，并用这些证据改进之后的排期与自动化；完整优化闭环仍在开发中。
正在形成的闭环
Plan → Observe → Interpret
计划任务，捕获真实行为，并把活动转成可比较的证据。
↓
Compare → Learn → Replan
比较计划与执行，学习个人时长和工作模式，再调整未来安排。
↓第二条未来回路
发现重复工作 → 自动化候选
从反复出现的手工操作中识别可以建议或执行的自动化。
当前运行中的证据
- ActivityWatch 已在本地持续捕获行为，并按约 5 分钟片段汇总。
- 本地模型每小时分类活动：专注、相关但偏移、分心与 AFK。
- 测试过不截屏、不持续轮询的 macOS 前台传感器原型；实时探针已捕获 ChatGPT → Chrome → Finder → 微信等应用切换。
- 频繁切换两个并行项目时，多个阶段可能被合并摘要。这被保留为产品与算法问题，而不是当作噪声隐藏。
界面正在补充「上次汇总 / 下次汇总」的可见性，以及日、周、月时间使用视图。当前重点是证据驱动的自我优化，而不是通用日历助手。
Demo
展示输入一个大任务、生成七天计划，并在周视图中反馈任务进度的当前原型。
一句话
一个面向学生 / 个人效率场景的对话式规划原型。系统已分别实现自然语言任务拆解、排期、周视图与反馈重排模块；目前仍在联调这些模块在同一真实交互中的状态传递和冲突处理。
为什么做（问题）
普通日历只能存「事件」，不理解「任务」。真实痛点不是「记个时间」，而是：有个目标（写论文 / 学课程），却不知道怎么拆、每天做什么、做不完怎么调整。
所以目标不是「做个日历」，而是做一个能理解任务、安排时间、并在进度变化后自动重排的系统。
定位
不是聊天机器人
目标是围绕「任务状态」运转：计划相关输入应改变当前计划，而非只返回一段文字。
目标闭环：任务-时间双向更新
目标路径是任务理解 → 时间安排 → 状态更新 → 自动重排；当前仍在解决跨模块状态同步与冲突处理。
架构 · 语义层 vs 正确性层
整个项目最关键的一条分界：让 LLM 只做它擅长的语义理解，把排期的正确性交给确定性引擎。
自然语言输入
「帮我七天学完一门课」 · 「今天只做了一半」
↓
语义层 · LLM（只做它擅长的）
意图理解
6 个纯语义意图 + 状态机解析（LLM 判语义，状态定动作）
语义拆解
目标 → 可执行子任务（few-shot + 抽象↔具体对照）
↓结构化任务
确定性层 · 规则引擎（处理排期约束）
按 deadline 反推均摊排期
排不下时溢出而非丢弃
时间槽统一收口
find_available_slot · validate_no_overlap
↓
周视图计划 · 任务状态
接收反馈并尝试重排剩余日程
成长主线 · 一次「从选框架到分层」的转变
第二幕 · 怀疑架构，做 A/B 实验
复杂度上来后我开始问：「是不是直接全交给 AI 更简单？」我没停在想法，而是真做了两条实验链路（langgraph-practice 分支）：LangGraph 编排 / 单次 LLM JSON。
结论很关键——三条路单独都不行：
- 纯规则：稳，但死板，不懂自然语言的灵活诉求。
- 全 LLM / 单次 JSON：灵活，但不稳——拆解抽象、排期会重叠 / 把任务丢掉、结果不可控。
- LangGraph：让编排更清晰，但没解决真正的问题（问题不在编排形式）。
第三幕 · 转变——不是「选一个框架」，而是「分层 + 评测驱动」
真正的顿悟是：卡点根本不在「用规则还是 LLM 还是 graph」，而在 ① 领域建模和确定性排程算法本身；② 没有可信的评测。于是两个决定：
- 分层：让 LLM 只做语义理解，把排期、冲突检测与状态更新交给确定性模块。这个设计降低了单点不确定性，但跨模块数据契约仍需要继续收束。
- 评测驱动：我发现原本「全绿」的评测与真实链路脱节，于是开始重建端到端场景、质量评测与覆盖矩阵。当前评测能暴露问题，但尚未形成稳定的端到端验收基线。
这一幕是整个项目最有价值的部分：我从「加功能 / 修 bug」进入到「系统设计 + 评测文化」。
具体难点 & 怎么解
| 难点 | 现象 | 解决 |
|---|---|---|
| 拆解「像对了」但抽象 | LLM 输出「学习监督学习基础」这类占位 / 大块 | 加入 few-shot、抽象↔具体对照与调用重试，并继续用真实任务校准拆解粒度 |
| 排期堆在同一天 | 贪心塞满，「7 天计划」3 天排完 | 从「正向贪心」改为按 deadline 反推均摊；排不下溢出而非丢弃 |
| 新旧任务重叠 | 每个入口各写避让 → 失控 | 时间槽后处理统一收口：共享 find_available_slot + validate_no_overlap |
| 模糊反馈难 | 「做了一半」要定位任务、算剩余、重排 | 统一 task_id / slot 结构，反馈与重排复用同一套时间表管线；补范围序数 / 取消 / 模糊澄清 |
| 跨模块隐藏问题 | 单个模块测试通过，接到真实交互后仍出现异常 | 针对时长塌缩、分数小时冲突、意图误判与状态不同步逐项定位 |
项目结果
该项目尚未形成稳定上线版本，但通过实际开发暴露了 Agent 系统中「局部模块通过不等于端到端可用」的问题，也促使我重新设计评测、验收与变更管理流程。
我的思考（成长 / 反思）
这个项目最有价值的不是把页面做出来，而是让我从「功能开发」进入「系统设计」：
- 任务状态该用什么结构贯穿全链路？
- 规则编排什么时候会失控？纯 LLM 什么时候更划算？成本边界在哪？
- 怎么判断「它真的对了」——而不是「看起来对了」？
我没停在「怀疑架构」，而是真做了 LangGraph 和单次 LLM 两种实验去比较稳定性 / 灵活性 / 维护成本；最后想明白答案不是二选一，而是分层，并用评测持续暴露端到端问题。这让项目从一个产品原型，变成了一个「AI 应用编排方式」的实验场。
当前状态与下一步
当前状态：原有的任务拆解、排期与反馈重排模块继续保留；新的行为观察与分类链路已在本地运行，但「观察 → 学习 → 重排」还不是完成态。
下一步：先改善跨项目切换的分类边界，补齐汇总时效与时间使用视图，再把行为证据稳定接回重排决策。
技术栈
React / Vite 前端 · Python HTTP API 后端 · LLM + 本地规则兜底 · 确定性排期与重排模块 · 单元测试 / 场景评测脚本。