Proposal；AI 候选与确认

[LUPENGHAN]

Issue：AI 候选与确认

1. 功能描述

AI 生成的创建、修改、删除、Feedback、GoalPlanDraft、ReschedulePlan、画像更新等会改变业务事实的结果，都必须以候选或确认卡展示。用户确认后，主 Agent 才能调用公共数据模块落盘。

查询和即时复盘等只展示结果、不改变事实的能力，可以直接展示。

手动表单写入调用同一公共数据模块。普通创建/编辑以用户明确点击“保存 / 提交”作为确认事件，不重复增加一层弹窗；删除、批量创建 Task、批量修改和重排应用属于高风险写入，必须展示影响范围并强确认。

2. 用户 / 用户故事

目标用户：希望 AI 降低录入和规划成本，同时保留最终确认权的 TimeFlow 用户。

用户说“明天下午三点开项目会”，系统展示 Schedule 候选卡；用户可以确认、修改或取消。

用户说“帮我重排这周”，系统展示 ReschedulePlan 变更预览；用户可以部分修改、取消动作或确认应用。

3. 现有做法及不足

如果候选生成后直接写入，用户会失去对 Schedule、Todo、Goal、Task、Feedback、重排和画像的最终控制权。

确认机制需要成为全局基础能力，所有会改变业务事实的 AI 结果都应先进入候选或确认卡。

4. 本期范围

1. 定义候选卡和确认卡的通用行为。
2. 支持创建、修改、删除 / 取消、Feedback、GoalPlanDraft、ReschedulePlan、画像更新候选。
3. 支持用户确认、修改、取消。
4. 用户确认后由主 Agent 发起写入。
5. 写入前执行确定性校验。
6. 写入失败时展示错误且不产生半成品。
7. 记录用户确认/取消、数据写入、写入拒绝和安全拦截等最小业务审计事件。
8. 运行状态和派生入口可以按确定性规则产生，但不得借此改变业务事实。

5. 明确不做

• 不允许 AI 静默写业务事实。
• 不允许子 Agent 直接落盘。
• 不做无需确认的高风险删除。
• 不做候选永久历史列表。
• 不做复杂审批流。

6. 关键决策

决策点	备选方案	选择	理由
AI 写操作	静默执行 / 候选后确认	必须确认	保护用户控制权
统一组件	各模块自定义 / 候选确认卡复用	候选 / 确认卡复用	避免每个模块自定义确认规则
写入执行者	子 Agent / 主 Agent	主 Agent	与 Agent 架构约束一致
校验方式	只依赖 LLM / 确定性校验	确定性校验优先	事实数据不能只依赖 LLM 判断
取消结果	保存候选事实 / 不落业务事实	不落业务事实	未确认候选不应污染数据
手动表单	每次二次弹窗 / 保存即确认	保存/提交即确认	避免普通操作重复弹窗，同时保留确认事件
业务审计	仅 Agent 观测 / 自有业务日志	自有日志记录	Agent 观测平台不能替代业务事实审计

7. 边界与异常

• 查询型结果：isDisplayResult = true，db_action = null。
• 写操作候选：isNeedUser = true，db_action != null。
• 删除、批量创建、重排应用属于高风险操作，必须二次确认或明确展示影响范围。
• 用户修改候选后，需要重新校验。
• 写入部分失败时，批量操作应回滚或保持原状态，并提示失败原因。
• FeedbackEntry、生成中/待确认 Plan、ReviewEntry 和通知只属于运行状态或派生入口；它们不能直接产生 Feedback、Task、重排应用或复盘报告事实。
• 业务审计至少记录用户、确认/取消、目标、操作摘要、时间、写入结果和 trace_id；不得只依赖 LLM 调用日志。

8. 基本概念与信息结构

CandidateCard
├─ operation_type
├─ target_type
├─ target_snapshot
├─ proposed_change
├─ reason
├─ db_action
└─ status: pending / confirmed / cancelled / failed

9. Agent 输入输出约束

• 子 Agent 只返回建议结果和 db_action。
• 主 Agent 校验 db_action 与业务规则。
• 前端展示候选卡。
• 用户确认后，主 Agent 调用公共数据模块。
• 确认成功后刷新日程 Tab / 目标 Tab / AI 消息流。

10. 验收标准

• AI 创建 Schedule / Todo / Goal 时必须先展示候选卡。
• AI 修改或删除事项时必须展示变更前后和影响范围。
• GoalPlanDraft 确认前不创建正式 Task。
• ReschedulePlan 确认前不改变正式安排。
• Feedback 确认后状态和 Feedback 原子写入。
• 用户取消候选后不改变业务数据。
• db_action != null 且 isNeedUser = false 的响应被视为架构错误。
• 手动普通保存会产生可审计确认事件；高风险手动操作仍需强确认。
• 确认、写入、拒绝和安全拦截均可从业务审计日志追踪。