定义产品心智
把“AI 硬件能做很多事”收敛为用户能理解的核心心智：它能被唤醒、能看见上下文、能理解意图、能推进任务，也必须能被停止和接管。
Zipone：为端侧 AI 硬件定义可信、可控的 UX 系统
PROJECT POSITIONING
项目定位
Zipone 是一个端侧 AI 助手项目，硬件载体是一台方形设备。它不是把手机 App 缩小到硬件屏幕里，而是探索当 AI 能常驻在用户身边、理解本地上下文、感知真实世界时，人应该如何表达意图、获得反馈，并放心地把任务交给它执行。
MY UX WORK
我承担的 UX 工作
搭建交互架构
梳理语音、视觉、文本、实体控制、屏幕与灯效之间的优先级和兜底关系，避免新硬件变成入口混乱的功能集合。
设计 AI 状态系统
将 AI 的聆听、识别、思考、搜索、执行、失败、确认和中止转译成可见状态，让用户知道系统正在做什么，以及自己何时可以介入。
输出高保真方案
完成 onboarding、主界面、视觉识别、任务卡片、主动建议、历史任务与多模态输入等关键流程的界面与原型表达。
UX Foundation / Problem Framing
问题定义：把“做一个 AI 硬件”拆成可设计的问题
Zipone 最大的不确定性不是某个页面怎么画，而是用户为什么需要一个独立 AI 设备，以及它和手机、智能音箱、App 助手的边界在哪里。所以我先把项目从“能力清单”拆成一组 UX 命题，用来指导后续的信息架构、状态反馈和任务流程。
更快把意图变成行动
用户不是为了和 AI 多聊天，而是希望把“我要做什么”快速交代出去，并且知道任务是否被正确理解和推进。
端侧上下文成为差异化
独立硬件的价值不只是入口更近，而是能结合视觉、位置、设备状态和历史任务，让 AI 更懂当下情境。
AI 自动性带来失控感
当系统能主动搜索、推荐、执行时，用户会担心它越界。因此状态、确认、取消和恢复机制必须前置设计。
小屏幕不能承载复杂菜单
方形硬件屏幕面积有限，不能照搬手机 App 层级。界面必须围绕当前任务和下一步动作组织，而不是展开完整功能树。
我设定的 UX 成功标准
- 可理解：用户第一次看到设备时，能知道它可以被唤醒、可以看见上下文、可以推进任务。
- 可控制：用户在聆听、理解、规划、执行阶段都能停止、修改、确认或取消。
- 可恢复：识别失败、权限不足、任务不明确时，系统能给出清楚原因和下一步。
- 可延续：复杂任务不会消失在对话里，而是沉淀成可继续、可追踪的任务卡片。
UX Foundation / User Journey
用户旅程：我关注的是跨情境任务，而不是单个页面
端侧 AI 硬件的体验会跨越现实环境、语音输入、屏幕反馈和任务续办。为了避免只停留在“主界面好不好看”，我把用户旅程拆成 6 个阶段，每个阶段都对应不同的 UX 风险和设计回应。
阶段
用户在想什么
UX 风险
设计回应
建立心智
这个设备和手机助手有什么不同？
不知道能做什么，第一次使用成本高。
用 AI 形象、自然语言样例和轻量状态建立“可交流、可执行”的心智。
表达意图
我该说什么？它听懂了吗？
语音识别不确定，用户担心表达失败。
实时字幕、键盘修正、prompt 样例共同降低表达压力。
补充上下文
我指的就是眼前这个东西。
语音无法完整描述真实环境。
用视觉输入补充上下文，并把识别对象反馈给用户确认。
等待理解
它是在想，还是卡住了？
模型延迟被感知为系统失效。
用思考态、搜索态、规划态解释等待，让用户知道系统正在推进。
决策确认
我能不能改？会不会直接执行？
AI 越过用户做决定，造成不信任。
高影响任务必须进入确认卡，展示关键字段和可修改项。
后续追踪
这个任务后来怎么样了？
对话结束后任务丢失，无法继续。
任务板承接进度、历史和下一步操作，让任务跨时间延续。
UX Foundation / IA & Object Model
信息架构：我把产品组织成“任务优先”的系统
小屏 AI 硬件不适合做复杂导航，所以我没有按传统 App 的“首页、发现、我的”来组织，而是按任务生命周期建立信息架构：输入、理解、确认、执行、沉淀。这样每个界面都服务于用户当前最需要知道的下一步。
常驻 AI 层
待机、唤醒、状态反馈、基础信息。
输入层
语音、视觉、字幕、键盘、实体按键。
理解层
意图识别、上下文合并、信息缺口、风险判断。
任务层
方案卡、确认卡、执行进度、外部结果。
记忆层
历史任务、偏好、可继续操作、提醒。
Task Card
30 分钟内送达的清淡晚餐
状态：等待确认
依据：距离、配送时间、历史偏好
修改条件
确认执行
任务卡片字段定义
- 用户意图：用户最初表达的目标，保留自然语言语义。
- 上下文依据：AI 使用了哪些视觉、位置、历史或设备状态作为判断依据。
- 当前状态：正在搜索、等待确认、执行中、已完成或需要恢复。
- 关键操作：确认、修改、取消、稍后继续等可见控制点。
- 后续提醒：任务完成后的追踪、提醒或再次打开入口。
UX Artifact 01 / Interaction Architecture
交互架构：我先定义系统如何接住一个任务
这个项目不是先画几个漂亮界面，而是先把“用户给 AI 一个任务”拆成完整链路：用户怎么触发、系统怎么采集上下文、AI 怎么判断任务类型、什么时候需要确认、结果如何沉淀。这样硬件、模型、前端和交互反馈才能围绕同一套规则工作。
用户触发
- 语音唤醒
- 摄像头指向
- 继续历史任务
- 实体按键中止
意图采集
- 语音转写
- 视觉上下文
- 文字修正
- 本地状态
AI 理解
- 意图分类
- 信息缺口
- 风险判断
- 任务拆解
任务代理
- 搜索与调用
- 方案比较
- 用户确认
- 执行与续办
可见反馈
- AI 状态动画
- 字幕解释
- 任务卡片
- 历史沉淀
用户控制点
停止思考
修改条件
确认执行
取消任务
稍后继续
输入优先级
语音负责表达意图，视觉负责提供上下文，文字负责修正与兜底，实体按键负责快速中止。每一种输入都有明确职责，避免多入口互相抢夺注意力。
任务风险分级
查询、总结、推荐可以直接给结果；涉及消费、发送、预订、外部调用的任务必须进入确认态，让用户在关键节点保留最终决策权。
状态必须可见
只要 AI 正在听、看、思考、搜索或执行，界面就要给出明确反馈。用户不能面对一个沉默的小屏幕猜测系统是否还在工作。
结果必须可续办
复杂请求不以一段回答结束，而是沉淀为任务卡片。卡片承载进度、外部结果、下一步操作和历史回溯，让 AI 从聊天走向行动。
UX Artifact 02 / AI State System
AI 状态系统：把模型黑箱拆成用户能理解的状态
AI 产品最容易让用户不安的地方，是它“好像在做事，但用户不知道它在做什么”。所以我把 Zipone 的状态定义成一套可见系统：每个状态都有触发条件、屏幕反馈、用户可做的动作和失败兜底。
待机
聆听
看见
理解
规划
确认
执行
结果
状态
触发条件
界面反馈
用户控制
待机 Idle
用户未输入，设备处于可唤醒状态
日期、电量、AI 形象轻量存在，降低信息噪音
语音唤醒、点击进入、继续历史任务
聆听 Listening
检测到唤醒词、按住说话或点击输入
实时字幕、麦克风反馈、底部灯效提示正在收音
停止、切换键盘、重新说一遍
视觉感知 Seeing
用户举起设备、打开摄像头或指向物体提问
相机画面、识别对象、视觉上下文标签
关闭相机、重新识别、补充语音说明
理解 Thinking
系统合并语音、视觉、文本与本地上下文
思考动画、字幕解释、必要时展示“还需要什么信息”
补充条件、打断、停止思考
规划 Planning
任务需要搜索、比较、拆步骤或调用能力
展示正在搜索/比较/生成方案，而不是长时间空白等待
跳过、缩小范围、中止任务
确认 Confirm
涉及消费、发送、预订、外部执行等高影响动作
确认卡片展示关键字段、风险和可修改项
确认、修改、取消
执行 Acting
用户授权后，AI 开始调用能力或推进任务
任务卡片展示进度、当前步骤和预计结果
查看详情、暂停、撤回可撤销动作
恢复 Recover
理解失败、权限不足、网络失败或结果不可信
说明失败原因，给出重试、键盘输入或缩小任务范围
重试、改写、手动完成
UX Foundation / Error & Recovery
异常兜底：把失败状态当成主流程的一部分设计
AI 硬件不能假设每一次识别、理解和执行都成功。相反，越是 AI 产品，越要提前定义失败时用户看到什么、能做什么、系统如何恢复。这里我把常见失败场景整理成恢复策略，确保体验不是在错误发生时才临时补救。
不要让用户整段重说
展示实时字幕与可编辑文本，允许用户只改错词；同时保留“重新说一遍”和“键盘输入”。
先暴露不确定性
展示系统识别到的对象或区域，让用户重新对准、补充语音或手动选择，避免 AI 假装确定。
追问最小必要信息
只追问完成任务所需的关键缺口，例如时间、预算、对象或地点，不把用户拖回表单式填写。
强制进入确认态
支付、发送、预订、删除、外部调用必须展示确认卡片，明确关键字段、影响范围和取消入口。
说明原因和替代路径
告诉用户失败原因，并提供重试、稍后继续、切换本地能力或手动完成的路径。
让用户能回看依据
在结果卡里展示关键依据和可修改条件，让用户知道 AI 为什么给出这个建议。
CORE UX CHALLENGES
核心 UX 挑战
1. 新硬件没有成熟心智，用户不知道该如何使用它
Zipone 既不是手机，也不是智能音箱。它需要在第一次使用时就让用户理解：可以直接用自然语言交代任务，也可以通过视觉、语音和文本共同表达复杂意图。
2. 多模态输入不是越多越好，必须建立优先级
语音、摄像头、字幕、键盘、实体按键、点阵灯效和屏幕状态同时存在。设计需要明确每一种输入的默认场景、兜底方式和可见反馈。
3. Agentic AI 的“自动执行”需要可信边界
AI 可以搜索、推荐和推进任务，但用户必须知道它依据什么做判断、正在执行哪一步、什么时候需要确认，以及如何取消或接管。
4. 小屏硬件的信息空间有限，但控制感不能缺席
AI 不是传统确定性界面。即使屏幕很小，用户仍然需要看见状态、进度、结果、确认点和中止入口，否则就会觉得系统不可控。
DESIGN SOLUTION
设计解法：把 AI 硬件拆成 5 个 UX 系统
1. 产品心智系统：让用户先理解“它是谁”，再理解“它能做什么”
- 主界面保留一个持续存在的 AI 形象，让用户把它理解成“可以被唤起、可以交流、可以执行任务”的助手，而不是一组菜单入口。
- 电量、日期、思考动画、眼神变化和底部点阵灯效共同构成状态语言，让硬件具备存在感，同时保持小屏信息密度克制。
2. 学习成本系统：用自然语言样例替代功能说明书
- Onboarding 不做传统功能罗列，而是给出“可以直接说出口”的 prompt，让用户通过尝试理解能力边界和表达方式。
- 语音作为默认入口，键盘和字幕作为兜底输入，保证在嘈杂环境、隐私场景或语音识别失败时仍然可以继续完成任务。
3. 多模态输入系统：明确语音、视觉和文本各自承担的职责
- 用户可以把设备对准一本书、一张图片或当前环境，再用一句话提问。系统需要把“看见的内容”和“用户说的话”合并成完整意图。
- 相机负责提供上下文，语音负责表达意图，字幕负责增强可理解性，键盘负责兜底修正，停止按钮负责保留用户控制权。
4. 任务代理系统：将对话转化为可继续、可确认的任务卡片
- Zipone 的目标不是生成一段回答就结束，而是把打车、旅行计划、点外卖、生成图片等请求沉淀成可追踪、可继续、可确认的任务卡片。
- 任务板把对话历史、执行进度、外部结果和下一步操作放在同一层级，让 AI 从“聊天界面”走向“行动界面”。
5. 主动建议系统：让 AI 的主动性有依据、有边界、可拒绝
- 端侧 AI 的优势不只是“更快”或“更隐私”，而是能理解用户当下状态。设计中将任务切换、打断次数和疲劳表达等本地上下文转译为建议触发条件。
- 主动建议不做泛泛安慰，而是提供可行动的微任务，例如散步、开启勿扰或回家后提醒准备物品。所有建议都需要保持低打扰、可忽略和可取消。
UX Artifact 03 / End-to-End Task Flow
任务流：从一句自然语言到可继续执行的任务卡
我把 Zipone 的关键体验定义为“不是回答用户，而是推进任务”。下面是一个典型任务如何经过输入、理解、确认、执行和沉淀。每一步都对应一个 UX 决策点，而不是让模型自由发挥。
“帮我点一份清淡一点的晚饭，30 分钟内送到。”
-
01
捕捉意图
语音作为主入口，实时字幕降低识别不确定性。用户可以在识别错误时直接改字，避免整段重说。
-
02
补齐约束
系统从表达里抽取“清淡、晚饭、30 分钟”三个约束，并结合位置、时间、历史偏好判断是否需要追问。
-
03
搜索与比较
AI 进入规划态，展示正在筛选商家和配送时间。用户看到的是任务进度，而不是不可解释的等待。
-
04
生成方案卡
结果不是一句推荐，而是 2 到 3 个可比较方案：餐品、预计送达、价格、健康理由和可替换项。
-
05
确认后执行
涉及下单和支付时必须进入确认态。用户可以修改口味、地址、预算，也可以取消任务。
-
06
沉淀为任务
执行后的结果进入任务板，保留进度、订单信息和后续提醒，方便用户稍后继续查看。
任何支付、发送、预订、外部调用都不能直接执行，需要用户确认关键字段。
在聆听、理解、规划、执行阶段都保留停止入口，让用户随时夺回控制权。
复杂任务不能散落在聊天记录里，必须沉淀为可继续操作的任务卡片。
CORE DESIGN OUTPUT
核心设计产出
- 从模糊概念到清晰产品模型：将“端侧 AI 硬件”拆解为唤醒、感知、理解、执行、确认、续办等可设计的用户时刻。
- 从功能集合到交互规则：建立语音、视觉、文本、实体控制、屏幕和灯效之间的输入输出关系，避免多模态能力互相抢占用户注意力。
- 从 AI 黑箱到可解释状态：用聆听、看见、思考、搜索、执行、停止和确认机制，让用户知道 AI 正在做什么，并随时可以接管。
- 从聊天体验到任务体验：通过任务卡片、历史任务和可继续执行的结果面板，把对话沉淀为真实任务流。
DESIGN REFLECTION
设计复盘
设计端侧 AI 硬件时，最重要的不是把更多能力塞进小屏幕，而是先定义用户与 AI 协作时的秩序：用户在什么时刻表达意图，系统如何反馈自己正在理解什么，哪些动作需要确认，以及任务如何跨时间继续。
这个项目让我将 AI 的不确定性转译为一套可见、可控、可继续的体验语言：用多模态输入降低表达门槛，用状态系统回应等待与失败，用任务卡片承接行动，用主动建议保持分寸。这些原则也成为我后来处理复杂 AI 产品体验时的基础方法。