AI 从邮件里读出待办，给出一条可以核对、调整和确认的日程建议。
Nothing is final until you confirm it.
这张建议卡使用示例数据。你可以查看助手读到了什么、把时间加进日历，也可以撤销。
01 / 起点
目标用户假设
主要靠邮件沟通、日历又常常排满的客户工作者。
我在「邮件提出请求」和「日历真正排进去」之间加了一步核对：先回看原文、估算时长，再自己选时间。
举例任务
「这周内能把改好的报价发我吗？」
这件事要花多久，又该塞在哪？
产品参考：Gmail 里的 Gemini、从 Gmail 生成日程。
02 / 三个设计选择
01 / 上下文
冲突和建议时间都会留在周视图里，用户可以和当天其他安排放在一起比较，再决定要不要调整。
02 / 依据
我把原始邮件放在时间和时长边上，这样不用离开日历，就能核对这条建议靠不靠谱。
03 / 控制权
排期不会自动完成。用户选好时间后，日程才会加入日历，待处理数量随之更新，同时提供撤销。
03 / AI 与信任
原来的标签让推断出的截止时间看起来像邮件原文。我后来给它加上了明确的「推断」标记。
「这周内」
没有写具体时间。周五 18:00
看起来像是从邮件里摘出来的。周五 18:00 推断
这是一个假设，需要跟发件人确认。录屏和移动端截图用的还是旧写法；桌面端原型里是改过的标签。
04 / 移动端高保真
桌面端的周视图到了手机上，变成日视图加底部抽屉。当前任务和前后的日程仍然放在一起。
05 / 可交互原型
先点 Review next，看一眼邮件，选个时间，再试试撤销。
交互 / 01
选一个时长，预览这段时间，再确认加进日历。
交互 / 02
先确认「习惯排在上午」这条偏好，再把它保存成规则。历史记录和百分比使用示例数据。
交互 / 03
拖动一个已有的会议，时间随之更新，撤销也会出现。
06 / 评估与迭代
知道怎么排期是一回事，愿不愿意相信 AI 读对了邮件是另一回事。
参与者
参与者是平时会用日历和任务管理工具的学生与上班族。他们有记录日程、安排每日任务的习惯，用过 Google 日历，也用过其他规划工具。
可用性测试中观察到
参与者知道怎么把一条建议加进日历，也能分清哪些是待处理的建议、哪些是已确认的日程。
观察到的行为
有 4 位参与者回头仔细读了原始邮件，确认 AI 有没有正确理解请求。
下一轮迭代
下一版会把原文依据放得更显眼，明确标出推断的截止时间和预估时长，并把编辑和打开邮件的入口移到建议附近。这些改动还没有经过测试。
4 位参与者回看邮件，说明他们在采纳建议前需要更清楚的依据。设计目标不是阻止核对，而是让需要核对时能更快找到原文。
原型用的是模拟数据，没有接真实的邮箱和日历。这次可用性测试既没有验证后端 AI 的准确率，也没有验证真实场景里省下多少时间。
基于 Google Workspace 公开文档做的独立概念，与 Google 无关联。
