Skip to content

Proposal:智能时间重排 #17

Description

@yyy-router

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 中找到,通知单独恢复

Metadata

Metadata

Assignees

No one assigned

    Labels

    FullSpec完整规格提案:影响面较大,需要写清楚动机、范围、不做、备选方案、接口/数据结构、原型、验收标准Proposal-Acceptedproposal

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions