Proposal:智能时间重排
1 功能描述
智能时间重排用于在现实打乱计划后恢复可执行节奏。它不是简单把事项顺延到明天,也不负责采集执行反馈;它根据时间冲突、负载、Feedback、Goal 约束和用户主动请求,生成若干可比较、可编辑的 ReschedulePlan 候选。
重排分为两种:
- 主动重排:用户在 AI Tab 明确提出重排某天、某段时间或某个 Goal。
- 被动重排:系统检测到满足条件的偏差后,自动生成并持久化待确认方案,再发送通知。
无论哪种方式,系统都不得自动应用。用户先查看多种方案及 before/after、风险和取舍,可以修改方案、取消个别动作或要求重新生成;只有最终明确确认后,母 Agent 才调用确定性业务能力原子应用。
重排统一协调 Schedule、Todo 和 Task,但不预先给 Schedule 分类。AI 在每次排期时只根据 Schedule title 临时判断是否提出调整该 Schedule;判断不写回对象,具体移动动作必须展示并由用户确认。Task 必须继续满足所属 Goal 约束;Todo 可以加入或移动计划时间,但截止变化必须被明确展示和确认。
2 用户
| 用户人群 |
常见偏差 |
重排需求 |
| 学生 |
课程、社团或临时事务打断备考计划 |
快速恢复后续 Task 节奏 |
| 自我提升型职场人员 |
会议、加班挤占 Goal Task |
跨天协调计划并保护截止时间 |
| 日常管理型职场人员 |
Schedule/Todo 频繁变化 |
轻量调整日程和普通事项 |
| 自由职业者 |
订单、项目临时插入 |
在外部事件变化后重建可执行安排 |
用户故事
| 场景小故事 |
对应能力 |
价值 |
| 上午 Task 被临时会议打断,我反馈“未完成”。 |
被动生成恢复方案 |
不用手动逐项拖动 |
| 新增项目会议与三个计划事项冲突。 |
三类对象统一冲突分析 |
避免各自调整后产生新冲突 |
| 同一个 Task 比预估困难。 |
拆成多个同 Goal Task 或调整耗时 |
改善可执行粒度 |
| 我连续几天没有完成,计划明显过载。 |
降低任务量、保留核心 Task |
防止计划继续崩坏 |
| 我不喜欢系统给的第一种方案。 |
多方案、编辑与重新生成 |
用户决定取舍 |
| 系统自动发现问题。 |
保存候选并通知,不自动应用 |
及时但不失控 |
3 现有做法及不足
| 现有做法 |
可以解决 |
仍然存在的问题 |
| 用户手动拖动日历和任务 |
精确控制局部变化 |
成本高,无法批量恢复整体节奏 |
| 所有未完成事项顺延一天 |
实现简单 |
不理解原因,容易继续堆积 |
| Schedule、Todo、Task 分别调整 |
每个模块逻辑简单 |
调整结果可能互相冲突 |
| 只在用户主动请求时重排 |
避免打扰 |
用户可能不知道计划已不可执行 |
| 被动触发后直接应用 |
及时 |
AI 误判会直接污染正式计划 |
| 原 #17 只重排日程与子任务、排除 Todo |
聚焦重目标 |
无法恢复完整时间轴,且 Subtask 已移除 |
核心问题是需要“检测偏差 → 生成多种恢复方案 → 用户调整确认 → 原子应用”的统一闭环。
4 产品范围
本期范围
触发方式
- 用户在 AI Tab 主动请求重排。
- 被动条件至少覆盖:
- 新增或修改 Schedule/Todo/Task 造成时间冲突。
- Task 或已排期 Todo 延期超过阈值。
- 连续多个事项未完成、部分完成或延期。
- 指定时间窗口的计划负载明显超过可用时间,例如达到配置阈值。
- Goal 截止前剩余容量不足。
- Feedback 显示耗时显著超出预估、任务过大或重复受干扰。
被动条件满足时可以自动生成、保存待确认 ReschedulePlan 并通知,但不能自动改变任何业务对象。
重排对象和策略
- 统一读取 Schedule、Todo、Task、Feedback、Goal 约束和已确认用户画像。
- Schedule 不保存固定/可移动字段或标签。生成方案时,AI 根据 Schedule title 临时判断是否提出移动;未被明确列为调整动作的 Schedule 继续作为现有时间占用。
- 对 Schedule 的每个移动都必须在方案中展示原时间、新时间和理由;该判断只属于本次方案,不能写回 Schedule 成为长期分类。
- Task 可以移动、调整预计时长、降低当期数量,或将一个过大的 Task 替换为多个同属该 Goal 的 Task;任何结果仍需完整起止时间且不违反 Goal 截止。
- Todo 可以被安排到空闲时段、移动已有计划时间或保留未排期;截止时间变化作为独立动作明确展示,不得静默顺延。
- 支持的策略至少包括:顺延、换时段、调整预计耗时、降低负载、保留核心事项、拆分过大 Task、增加缓冲和建议专注。
多方案与确认
- 每次重排展示若干具有不同取舍的方案,例如“保护 Goal 截止”“最少移动事项”“降低本周负载”。
- 每个方案展示诊断摘要、动作列表、before/after、选择理由、风险和无法满足的约束。
- 用户可选择一个方案,修改动作时间或内容,取消部分动作,也可提出新约束后重新生成。
- 用户确认前,方案是派生候选数据,不改变 Schedule/Todo/Task。
- 最终应用时重新校验数据版本、时间冲突和权限;全部动作成功才提交,任一失败则全部回滚。
- 应用前保留快照,支持撤销最近一次已应用的重排;撤销同样需要用户确认并原子执行。
明确不做
- 无确认自动应用重排。
- 未经确认移动 Schedule、把排期判断写成 Schedule 分类、强行插入无空闲时段或静默修改 Todo 截止。
- 子 Agent 直接读取或写入数据库。
- 在重排模块中采集 Feedback、生成 ReviewReport 或修改用户画像。
- 跨用户、团队排期和无限历史撤销。
后续可拓展
- 更复杂的跨 Goal 优先级优化和多周容量预测。
- P1 使用经确认的历史画像候选调整估时与偏好。
5 关键决策
| 决策点 |
方案 |
结论 |
理由 |
| 触发方式 |
仅用户手动 |
不选 |
用户可能不知道何时计划已不可执行 |
| 触发方式 |
条件触发 + 用户主动 |
采纳 |
兼顾及时性和主动权 |
| 被动行为 |
先询问是否生成 |
不选 |
用户仍需额外操作,可能错过恢复时机 |
| 被动行为 |
自动生成并保存候选、通知 |
采纳 |
提前准备结果,但不改变事实 |
| 应用方式 |
生成后自动应用 |
不选 |
违背所有应用需用户确认的原则 |
| 应用方式 |
用户调整并最终确认 |
采纳 |
用户掌握取舍 |
| 对象范围 |
只处理日程和目标任务 |
不选 |
Todo 仍可能占用容量或逾期 |
| 对象范围 |
Schedule/Todo/Task 统一分析 |
采纳 |
恢复完整时间轴 |
| 方案数量 |
只给一套结果 |
不选 |
容量不足时没有透明取舍 |
| 方案数量 |
给出多种策略方案 |
采纳 |
用户可以选择优先保护的目标 |
| 部分选择 |
只能全收或全拒 |
不选 |
实际需求常需要保留个别原安排 |
| 部分选择 |
允许编辑/取消动作,最终原子提交 |
采纳 |
灵活但不产生半提交状态 |
| 回退 |
不保存应用前状态 |
不选 |
误操作无法恢复 |
| 回退 |
快照 + 最近一次撤销 |
采纳 |
MVP 复杂度可控 |
6 边界与异常
边界规则
- 母 Agent读取数据并组装最小必要上下文;重排 Agent只返回结构化候选,不直接读写业务数据。
- 被动方案和系统通知是允许自动保存的派生数据例外;正式事项变化仍必须确认。
- 同一冲突事实已有有效待确认方案时不重复生成;基础事实改变后旧方案可失效并生成新版本。
- 用户修改单个动作后必须重新执行整份方案的冲突校验。
- Task 拆分产生的是多个同级 Task,不是 Subtask。
- Todo 截止和 Goal 截止是业务约束;需要修改时必须作为显式动作展示。
异常场景与处理方式
| 场景 |
系统行为 |
原则 |
| 偏差较小,不满足被动条件 |
不生成方案,可返回“不建议重排”及原因 |
避免过度打扰 |
| 没有可行的无冲突方案 |
展示冲突、容量缺口和需要用户放宽的约束 |
不制造假计划 |
| 已有有效待确认方案 |
返回现有方案,不重复生成同事实方案 |
去重 |
| 方案生成失败或超时 |
保留正式计划不变,记录失败并允许重试 |
候选失败不影响事实 |
| 确认前对象已修改/删除 |
标记方案过期,要求重新校验或生成 |
不覆盖新数据 |
| 用户编辑后产生冲突 |
阻止确认并给出冲突位置 |
全局一致性 |
| 应用任一动作失败 |
全部回滚,方案保持可查看并标注失败 |
原子性 |
| 通知失败 |
方案仍已保存,通知独立重试 |
触达不阻断候选 |
| 撤销时后续数据已变化 |
展示冲突并阻止直接撤销,改为生成新的恢复方案 |
不覆盖后续事实 |
7 基本概念与信息结构
| 概念 |
含义 |
| 重排触发 |
判断计划偏差是否达到需要恢复的条件 |
| ReschedulePlan |
已保存但待用户确认的派生方案 |
| 方案选项 |
同一问题下采用不同取舍的一组动作 |
| 调整动作 |
对一个 Schedule/Todo/Task 的候选变化 |
| before/after |
动作应用前后的时间、状态或内容对比 |
| Schedule 调整判断 |
AI 在本次排期中根据 title 临时判断是否提出移动,不形成持久属性 |
| 应用快照 |
用户确认应用前保存、用于最近一次撤销的旧值 |
信息结构:AI Tab 或被动检测 → 诊断 → 多个方案卡片 → 方案详情与逐条编辑 → 最终确认 → 原子应用 → 可选撤销。被动通知点击进入 AI Tab 对应待确认方案,不存在独立重排 Tab。
8 验收标准
| 用例 |
操作 |
通过标准 |
| 主动重排 |
用户在 AI Tab 请求重排明天 |
返回覆盖相关三类对象的多个可选方案 |
| 被动冲突 |
新项目会议与既有计划冲突 |
自动生成并保存方案、发送通知,正式计划不变 |
| Feedback 触发 |
用户确认“未完成/超时”反馈且达到阈值 |
生成待确认方案,但不自动应用 |
| Schedule 无预分类 |
创建会议或健身 Schedule |
两者都不保存固定/可移动字段或标签 |
| Schedule 排期判断 |
重排同时包含“项目会议”和“健身”title |
AI 按 title 临时决定是否提出移动;所有移动逐条展示,未确认前原时间不变 |
| Todo 处理 |
已排期 Todo 与会议冲突 |
可移动计划时间;截止变化必须单独展示 |
| Task 约束 |
移动 Goal Task |
新时间完整有效且不违反 Goal 截止 |
| 过大 Task |
重复反馈任务过大 |
可生成多个同级 Task 候选,不产生 Subtask |
| 多方案 |
容量不足 |
至少展示不同取舍方向、风险和未满足约束 |
| 部分编辑 |
用户取消一个动作并修改另一个时间 |
整份方案重新校验,未确认前事实不变 |
| 原子应用 |
模拟一个动作写入失败 |
所有动作回滚,不产生部分应用 |
| 方案过期 |
确认前底层对象变化 |
阻止直接应用并提示重新生成/校验 |
| 撤销 |
用户确认撤销最近一次重排 |
在无后续冲突时原子恢复应用前状态 |
| 通知失败 |
被动方案保存成功但通知失败 |
方案仍可在 AI 中找到,通知单独恢复 |
Proposal:智能时间重排
1 功能描述
智能时间重排用于在现实打乱计划后恢复可执行节奏。它不是简单把事项顺延到明天,也不负责采集执行反馈;它根据时间冲突、负载、Feedback、Goal 约束和用户主动请求,生成若干可比较、可编辑的
ReschedulePlan候选。重排分为两种:
无论哪种方式,系统都不得自动应用。用户先查看多种方案及 before/after、风险和取舍,可以修改方案、取消个别动作或要求重新生成;只有最终明确确认后,母 Agent 才调用确定性业务能力原子应用。
重排统一协调 Schedule、Todo 和 Task,但不预先给 Schedule 分类。AI 在每次排期时只根据 Schedule title 临时判断是否提出调整该 Schedule;判断不写回对象,具体移动动作必须展示并由用户确认。Task 必须继续满足所属 Goal 约束;Todo 可以加入或移动计划时间,但截止变化必须被明确展示和确认。
2 用户
用户故事
3 现有做法及不足
核心问题是需要“检测偏差 → 生成多种恢复方案 → 用户调整确认 → 原子应用”的统一闭环。
4 产品范围
本期范围
触发方式
被动条件满足时可以自动生成、保存待确认 ReschedulePlan 并通知,但不能自动改变任何业务对象。
重排对象和策略
多方案与确认
明确不做
后续可拓展
5 关键决策
6 边界与异常
边界规则
异常场景与处理方式
7 基本概念与信息结构
信息结构:
AI Tab 或被动检测 → 诊断 → 多个方案卡片 → 方案详情与逐条编辑 → 最终确认 → 原子应用 → 可选撤销。被动通知点击进入 AI Tab 对应待确认方案,不存在独立重排 Tab。8 验收标准