AOS
Agent 手机系统交互设计
独立设计手机上的 Agent 任务体验，完成任务澄清、单次授权、进度反馈、人工确认与中断恢复流程，并实现官网和可操作的前端原型。
“评审会改到彩讯科技大厦 12 楼，明天下午。”
原文留在聊天里，助手只读被委托的这一条。
个人概念项目 · 系统交互设计与前端原型实现。
关键设计判断
一次任务授权，应该允许系统做到哪一步？
- 设计出发点
- 消息转日程等任务同时涉及读取信息、后台执行和外部写入。围绕权限与任务依赖组织流程，让读取授权与写入确认各自对应明确的操作。
- 关键取舍
- 将读取授权与写入确认分开，保留进度、人工接管与中断恢复。增加必要的确认步骤，让一次读取许可不会被解释为持续或任意操作许可。
- 原型走查
- 前端原型覆盖八个场景、四十个状态，呈现任务澄清、单次授权、进度反馈、人工确认与中断恢复的操作路径。
产品逻辑
一次读取授权，不等于后续写入
我把任务澄清、单次读取、执行反馈与写入确认分开。系统需要什么权限、正在做什么，以及何时由人决定，都有明确位置。
用户 · 委托任务
先澄清任务
从当前消息明确要安排的事项。
用户 · 单次授权
确认读取范围
说明读取对象、排除范围和本次授权。
系统 · 执行任务
显示处理进度
执行过程可见，保留当前任务上下文。
用户 · 执行中介入
接管与中断恢复
需要介入时，提供人工接管和恢复入口。
用户 · 再次确认
写入前核对
查看日程内容，再确认外部写入。
系统 · 结果反馈
交代执行结果
让任务结果与对应操作保持关联。
典型界面讲解
一次授权，先说清边界
我把消息来源、读取范围和授权动作放进同一张面板，帮助用户核对这一次委托的边界。
先说明读取对象
授权围绕当前消息展开，来源与读取动作保持对应。
把排除范围写出来
聊天记录、联系人与位置历史不在这次读取范围内。
授权只针对本次
用明确的本次授权动作，区分读取与后续写入确认。
从一条消息，到一次确认
先明确任务，再授权读取；添加日程前，单独核对具体内容。三屏呈现同一任务的连续阶段，读取许可不替代写入确认。
- 01明确任务
- 02授权读取
- 03确认写入
个人概念与本地交互原型 · 完整操作保留在下方
读取授权，写入确认
先明确这次读取的对象与范围；添加日程前，再单独核对时间、地点与目标日历。
中央界面可以直接操作。四处标注对应这次授权的边界。
- 来源先说清来源消息、联系人与时间，和授权放在同一屏里。
- 范围只读这一条只读取这条通知的文字，不访问其他聊天、联系人或位置历史。
- 期限授权只对本次任务只覆盖当前任务；不保存权限，也不延续到下一次。
- 写入写入是下一次决定读取不授予写入权限。添加日程前重新展示时间、地点和目标日历。
执行中、待确认与受阻，各有明确反馈
任务卡分别交代处理进度、需要用户确认的内容，以及中断后仍可查看的结果。
等待用户的任务，要说明在等什么
“待确认”与“执行中”不能共用模糊的进度提示。我把收件人、附件数量和“核对邮件”入口留在任务卡上，让用户知道下一步需要自己处理什么。
受阻时保留原因与待处理范围
只显示失败会让用户重新猜测任务状态。我在卡片中保留网络中断和剩余数量，打开后仍可查看已完成内容，避免把局部中断误解为整项任务丢失。
断网后，区分已完成与待处理
围绕整理 8 条客户对话的场景，我设计断网保留与恢复流程。已完成的内容继续可查，剩余部分在用户确认后接续处理。
断网时，先交代哪些内容已保留
我把已完成的 5 条与待处理的 3 条分开呈现，并保留查看结果的入口。任务可以部分完成，界面需要让用户判断哪些内容现在就能使用。
网络恢复后，由用户决定是否继续
恢复连接不会直接触发剩余任务。我保留相同的完成数量与上下文，将下一步明确写成“继续剩余 3 条”，避免重复处理或未经确认继续执行。
把交互方案延展到产品官网
完成官网的信息结构、界面与演示内容，以消息转日程等场景呈现 Agent 的使用方式。官网、任务画布和交互原型复用同一组组件与状态，覆盖 8 个场景、40 个界面状态。
