Proposal：基于历史执行数据校准下一次 AI 计划

[gac0812]

Proposal：基于历史执行数据校准后续 AI 计划（V2，NoPlan / P1）

1 功能描述

P0 显式用户画像解决“用户主动告诉系统自己的情况”；本 Proposal 解决另一个问题：当用户已经积累足够的 Feedback、Task 执行和重排选择后，系统如何发现稳定偏差，生成有证据的画像候选，帮助下一次 Goal 拆分和重排更贴近真实执行能力。

历史校准不是自动画像。确定性代码负责聚合估时偏差、有效执行容量、重复失败原因、重复受干扰时段和重排取舍；AI 只负责把这些结果解释成候选建议。每个候选必须展示样本量、时间范围和证据，经用户接受或修改后，才写入 P0 Proposal 定义的统一 UserProfile 并保留“历史校准”来源。

候选不得自动覆盖手动画像，不得自动修改现有 Goal、Task、Schedule、Todo，也不能替代用户在当前请求中明确给出的约束。

2 用户

用户分层	特征	系统行为
无历史用户	只有显式画像，没有有效执行记录	不生成候选，继续使用 P0 画像
初步积累用户	有少量 Feedback，但部分指标样本不足	只生成证据充分的候选，并显示样本量
稳定校准用户	有多日耗时、失败原因和重排选择	生成估时、容量、任务粒度和时段候选

用户故事

场景	候选能力	边界
我经常把 90 分钟任务估成 60 分钟。	估时偏差候选	数值由代码计算，不让 AI 猜测
我填写每天可用 3 小时，但历史上通常只能稳定投入 90 分钟。	执行容量候选	展示证据，由用户决定是否加入画像
我多次因为“任务太大”而未完成。	更小 Task 粒度候选	只影响后续生成，不直接拆现有 Task
我多次在同一计划时段被临时事项打断。	避让时段候选	必须有重复时段证据，不能只凭原因文本
我经常拒绝“压缩休息时间”的重排方案。	重排取舍候选	只使用用户明确选择过的方案事实
我当前明确说这个 Goal 必须早晨完成。	当前输入优先	历史候选不能静默覆盖当前约束

3 现有做法及不足

现有做法	可以解决	仍然存在的问题
只使用显式画像	冷启动可控	无法反映长期真实执行偏差
Feedback 只服务当次重排	恢复当前计划	下一个 Goal 可能重复相同估时和粒度问题
ReviewReport 只展示建议	用户能够阅读结论	稳定结论没有进入后续规划输入
每次把完整历史交给 AI	理论上信息最全	上下文长、噪声高、隐私面扩大，数字不可复现
AI 自动总结“用户习惯”并保存	操作少	容易把偶然事件或推测变成长期事实

核心问题是缺少“历史事实 → 确定性聚合 → 有证据候选 → 用户确认 → 后续规划”的安全回灌链路。

4 产品范围

历史事实来源

• 用户确认的 Schedule、Todo、Task Feedback。
• Task 的预计/实际耗时、计划时段和执行状态。
• 用户对 ReschedulePlan 的明确采纳、修改、取消和拒绝结果。
• 事实只从当前用户的结构化数据读取，不采集设备使用、App 行为或后台活动。

行为校准候选

• 估时偏差：比较有效预计耗时与实际耗时，并携带样本量。
• 日执行容量：按用户本地自然日汇总有效实际投入；没有记录的日期不能按 0 计算。
• 重复失败模式：统计用户主动选择的结构化原因，例如任务过大、临时事项打断。
• 重复受干扰时段：只使用事项原计划时段，不使用 Feedback 提交时间冒充发生时间。
• 重排取舍：只统计用户明确采纳或拒绝的方案动作，不根据未查看、未点击推断偏好。

候选展示与确认

• 达到产品阈值后生成候选；每个候选展示结论、样本量、时间范围、代表性证据、适用范围和建议用途。
• 用户可以接受、修改或拒绝候选。
• 接受/修改后写入统一 UserProfile，来源标记为历史校准；拒绝项不进入画像。
• 新候选与现有手动画像冲突时并列展示，由用户选择保留、替换或取消，不能自动覆盖。
• 新确认内容从下一次 GoalPlanDraft 或 ReschedulePlan 生成时生效，不改变当前草稿和既有正式对象。

明确不做

• P0 手动画像的查看、创建、修改和删除；这些属于独立“显式用户画像”Proposal。
• 从普通历史对话中自动提取偏好；用户明确要求保存的信息由 P0 Proposal 处理。
• 未经确认自动写入或覆盖 UserProfile。
• RAG、Embedding、向量数据库、跨用户推荐和用户分群。
• 把完整 Feedback、ReviewReport 或对话历史每次发送给 Agent。
• 让 AI 计算或修改确定性指标。
• 采集设备使用时间、App 行为或其他隐式数据。
• 根据候选自动修改现有计划。

后续可拓展

• 时间衰减、任务类型权重、异常值处理和更细的候选解释。
• 用户主动配置历史范围和候选阈值。

5 关键决策

决策点	方案	结论	理由
Proposal 边界	与 P0 显式画像合并	不选	一个 Issue 会同时出现 Accepted 和 NoPlan，排期及验收冲突
Proposal 边界	#33 只保留 P1 历史校准	采纳	能独立延期、验收和关闭范围
历史处理	完整历史直接交给 AI	不选	数字不稳定、上下文过长
历史处理	确定性代码聚合	采纳	可复现、可测试并能携带样本量
写入方式	自动更新画像	不选	可能把噪声变成长期事实
写入方式	候选 + 用户确认	采纳	证据透明且保持控制
数据组织	单独维护历史画像	不选	Goal 拆分需读取两套冲突信息
数据组织	确认后进入统一 UserProfile并保留来源	采纳	读取统一且可追溯
生效时机	立即改动现有计划	不选	违背确认边界
生效时机	后续候选生成时读取	采纳	不静默覆盖已确认计划

6 边界与异常

聚合规则

• 估时偏差只使用预计耗时大于 0、实际耗时有效的记录；展示结论必须同时展示有效样本量。
• 日执行容量按本地自然日聚合实际投入；无记录日期不等于零投入。
• 失败模式只统计用户主动选择的结构化原因；自由文本不经 AI 自动分类后当作事实。
• “任务过大”等原因至少重复达到配置阈值后才生成 Task 粒度候选。
• “被打断”只有在同一计划时段重复出现时才生成避让时段候选；缺少计划时段时只保留原因统计。
• 同一 Feedback 被编辑时只使用最新有效版本，不把新旧值当作两条样本。

异常场景与处理方式

场景	系统行为
没有历史或样本不足	不生成候选，继续使用显式画像
只有部分指标有效	只生成有效候选，不补默认值
Feedback 被编辑/删除	使用最新事实重新计算，不重复计数
候选缺少样本量或证据	丢弃，不展示、不保存
用户拒绝候选	不写入 UserProfile，后续规划不使用
新候选与手动画像冲突	并列展示并等待用户选择
候选生成失败	不影响 Feedback、重排、复盘和 Goal 规划主流程
画像写入失败	候选保持待确认/失败状态，不产生部分更新
当前规划期间画像变化	当前草稿继续使用启动快照，新画像下次生效

7 基本概念与信息结构

概念	含义
历史执行事实	Feedback、Task 执行和重排选择中的已确认事实
行为校准候选	由确定性历史聚合生成、等待用户确认的建议
证据	支撑候选的样本量、时间范围和代表性事实
历史来源	候选确认进入 UserProfile 后保留的来源类型
适用范围	全局或特定 Goal 类型/场景
规划快照	一次 Goal 拆分或重排实际使用的已确认画像版本

信息结构：系统在有足够证据时，通过 AI Tab 或下一次计划确认流程展示“根据执行历史发现的候选”。用户接受或修改后写入统一 UserProfile；不新增独立历史画像主 Tab。

8 验收标准

用例	通过标准
无历史降级	不生成候选，Goal 拆分继续使用显式画像
估时候选	使用有效记录计算，结果可重复，展示样本量和时间范围
容量候选	按有效自然日聚合，不把无记录日当作 0
任务过大	原因重复达到阈值后生成更小粒度候选，不修改现有 Task
重复打断	同一计划时段有重复证据时才生成避让候选
重排取舍	只使用用户明确采纳/拒绝动作，不根据沉默推断
候选确认	接受/修改后进入统一画像并保留历史来源；拒绝项不写入
冲突处理	与手动画像冲突时等待用户选择，不自动覆盖
生效边界	新画像只影响后续生成，不改变当前或既有计划
数据最小化	Agent 不接收完整历史反馈、报告或对话全集
功能隔离	P1 失败不阻塞 Feedback、重排、复盘和 P0 显式画像