来源会议：2026-06-02 AI 项目实战课 · AI 小秘需求对齐，参与人 左橘长 / 淇淇。本方案把一场需求对齐会的多方分析汇编成给团队看的方案文档，综合产品定位、人群分层、MVP 边界、需求拆解、UI 设计、技术架构、商业判断与待决策项。
先把产品是什么钉死，再谈功能。
| 对比对象 | 用它记日程的真实体验 | 本产品差异是否成立 |
|---|---|---|
| 飞书 / 系统日历 | 录入要填表单五步（点新建、填标题、选日期、设时间、存），重 | 成立 · 一句话搞定 |
| 记事本 / 备忘录 | 不提醒、不结构化、事后查不回 | 成立 · 结构化+提醒 |
| 微信记事 / 文件传输助手 | 信息流里很快被淹没，找不回 | 成立 · 独立结构化存储 |
| Keep 等打卡类 | 太正式，要专门进 App 打卡，三分钟热度留不住 | 成立 · 聊天即记录 |
这四项里唯一真成立的差异点只有一个：录入摩擦从五步降到一步。其余都是这一点的延伸。
P0 是最痛、最该先服务、最有付费力的那一类。目前样本只有淇淇一人，正式立项前需补充验证。
边界比功能更重要。三栏分别是必做、二期、不做，明确不做的部分多数是用户当场否决或偏离秘书定位的畅想。
来自 product-manager。4.1 是 6 个核心实体的生命周期与牵连，4.2 是 18 条边界与异常清单（含淇淇两条红线）。
| 编号 | 场景 | 处理要点 |
|---|---|---|
| E1 | 语音转文本失败 | 提示重试 / 转文字输入，不静默吞掉 |
| E2 | 解析超时 | 淇淇红线不能记半天记任务必须快，超时给明确反馈 |
| E3 | 字段缺失 | 追问补全（缺时间 / 缺内容） |
| E4 | 时间模糊（下午 / 这周） | 追问或给默认值并标注 |
| E5 | 阴历换算失败 | 闰月兜底，换算不出时提示人工指定 |
| E6 | 写入数据库失败 | 淇淇红线禁止假成功必须如实报失败 |
| E7 | 落库成功但提醒排期失败 | 补偿重排，不让日程裸奔无提醒 |
| E8 | 提醒触达失败 | App 内未读兜底，下次进入即见 |
| E9 | 提醒触发前日程已变 | 触发前校验日程状态，已取消则不触发 |
| E10 | 多标签页同时编辑 | 乐观锁，冲突时提示刷新 |
| E11 | 同时段多个日程 | 不拦截，允许重叠 |
| E12 | 草稿未确认又来新消息 | 草稿覆盖策略（覆盖 vs 排队待决策） |
| E13 | 取消重复日程后续全部 | 二次确认，防误删 |
| E14 | 删除被引用的记忆 | 提示引用关系，确认后处理 |
| E15 | 日程长文本 | 格子内 2 行截断，滑动 / hover 查看全文 |
| E16 | 通知权限未授予 | 不阻塞主流程，降级到 App 内提醒 |
| E17 | 记忆未命中 | 直接问用户，不瞎编 |
| E18 | 放弃 / 超时的草稿 | 定期清理，不污染日程库 |
来自 ui-designer，下面把关键线框落成 HTML 可视化，让团队直接看到设计而非读文字描述。
64px 窄导航侧栏（Logo + 聊天 / 日程按钮 + 底部 [+] 二期占位）+ 380px 可折叠对话区 + flex 日程主区。宽屏（≥1280）同屏并存，点［日程］折叠对话区；窄屏（<1024）互斥切换。
不确定态与重要程度正交，靠形态区分：虚线边框 + 85% 不透明 + 右上 ◔ info 图标。这样一个事项块既能表达重要程度（颜色+点阵+竖条），又能独立表达确定与否（虚线+图标），两套编码互不干扰。
左橘长点名要看的项目最终架构。网页端单端，分五层，主链路用箭头串起：用户说话 → Agent 解析 → 调记忆补全 → 生成确认草稿 → 用户确认 → 工具写库 → 提醒排期 → 到点触达。
用户语音 / 文字 进入对话模块 → 聊天入口 Agent 解析 意图与字段 → 先 调记忆模块补全上下文（例如某人偏好、过往约定）→ 生成 确认草稿 回显给用户 → 用户 确认（或修正 / 放弃）→ 经工具层 写入日程库，同时 提醒排期入调度器 → 调度器到点扫描后经触达通道 到点触达。任何一步失败都如实反馈，禁止假成功。
来自 product-strategist。把命与噪声分开：值得做的是产品的命，不值得做的当场就该砍。
立项前必须拍板。第①项是最高优先级，直接决定提醒能否真用；第⑫项决定整个需求样本是否可信。
| 优先级 | 待决策项 | 选项 / 说明 |
|---|---|---|
| 最高 | ① 提醒触达通道 | 网页端无原生推送。选项：仅 Web Notification / 加邮件短信微信兜底 / 仅 App 内未读。直接决定提醒能否真用 |
| 高 | ② 记忆删除 | 软删 vs 硬删 |
| 高 | ③ 回收站保留期 | 保留多久后清理 |
| 高 | ④ 不确定态 | 是否提前提醒用户确认 |
| 高 | ⑤ 已发生日程 | 能否事后改时间（篡改历史问题） |
| 中 | ⑥ 一个日程多提醒 | MVP 单提醒 / 二期多提醒 |
| 中 | ⑦ 草稿未确认来新消息 | 覆盖 vs 排队 |
| 中 | ⑧ 草稿过期清理 | 清理策略与时长 |
| 中 | ⑨ 重复规则改时间 | 已手动改的例外：保留 vs 重置 |
| 中 | ⑩ 重复日程滚动生成窗口 | 提前生成多少实例 |
| 中 | ⑪ 记忆写入判定 | AI 自主 / 用户显式 / 混合 |
| 最高 | ⑫ 用户验证 | 正式立项前需再访谈 5–8 个 P0 用户验证（目前仅淇淇单样本） |