从内容推荐，到状态与服务
减少“系统想展示什么”，优先呈现用户此刻需要了解和处理的事情。
桌面首先回答：我现在需要关注什么？PROJECT PORTFOLIO · 2026
智能中屏
HomeClaw
// 云唔智能 //
2025.03–2026.07HomeClaw 是面向带屏智能音箱的 Agent 桌面应用。项目探索如何将环境线索、用户习惯与服务能力组织为可理解的交互，让设备从响应指令，逐步走向更贴近日常的主动协助。
我的角色
Product Designer / UX Designer
负责将 Agent 能力从产品需求与服务场景，逐步转化为具体的交互框架与界面体验，并协同推进方案验证与落地。
工作覆盖需求梳理、服务场景设计、Agent 交互框架、主动服务机制、零级入口、多模态交互与状态反馈，以及 UI 设计、规范定义和前端落地验证。
项目背景
Project Background
HomeClaw 的三阶段 AI 范式演进
随着 AI 能力从指令执行走向自主 Agent，HomeClaw 的体验重点也从“功能是否可用”，转向“设备能否理解场景并提供合适帮助”。
-
01
云唔精灵 1.0
基础智能硬件阶段
产品初期目标是完成智能音箱的基础能力验证与规模交付，以功能连接用户。
用户通过触控卡片与基础语音指令完成音乐播放、天气查询、闹钟设置等高频任务。
设备更像一个“功能入口”，用户需要主动寻找服务。 -
02
云唔精灵 2.0
AI Agent 探索阶段
随着大语言模型的发展，AI 开始从传统语音助手向 Agent 方向演进。
产品体验仍停留在用户提出需求、AI 完成响应的关系中，设备与用户之间的协作方式并没有发生根本变化。
能力更强，但仍需要用户先开口。 -
03
HomeClaw
主动式 Agent 阶段
随着新一代 Agent 框架出现，产品开始从“对话能力增强”进一步走向“自主执行与主动服务”。
产品目标从被动响应用户需求，转变为主动理解用户并提供服务。
从功能型智能设备，转变为主动式 Agent 系统。
核心挑战
Core Challenges
随着 AI 能力从“理解指令”向“理解场景并协助行动”演进，云唔精灵的设计目标也从提升单次交互效率， 转向探索具备主动服务能力的 Agent 系统——HomeClaw。
但在 2.0 阶段，虽然产品已经具备 AI Agent 对话能力，仍存在三个关键问题：
-
如何让设备从“响应用户需求”转变为“主动发现并满足用户需求”？
2.0 阶段通过大模型能力增强了设备的理解能力，用户可以通过自然语言完成更复杂的任务。
但交互模式本质仍未改变：
用户提出需求 AI 理解请求 系统执行反馈设备依然依赖用户主动唤醒和输入，很多发生在环境、时间和状态变化中的需求，难以及时被识别。
-
如何让 AI 从一次性的工具，变成能够持续学习用户的智能伙伴？
对话能力局限于单次会话，用户的偏好、习惯和历史行为无法沉淀。
这就导致：
每次交互需要重新建立上下文 长期使用价值难以形成 用户难以形成稳定使用预期缺少跨会话的状态延续，用户每次都要重新说明背景，难以形成“设备理解我”的感受。
-
如何从“功能入口驱动”转变为“用户意图驱动”的 Agent 交互模式？
在传统智能音箱和 2.0 阶段，产品主要通过功能入口向用户展示能力。
用户需要知道：
有哪些功能 功能在哪里 应该如何操作但随着 AI 能力增强，用户需求已经从“调用功能”转向“表达目标”。
关键设计决策
Core Design Decisions
基于前期识别出的三个核心挑战，我没有继续叠加功能，而是重新梳理人与设备的协作方式： 用户如何进入、Agent 如何理解，以及结果如何持续反馈。
01
桌面框架
从卡片式到“零级入口”
让用户表达目标，而不是先理解产品功能
当 AI 从功能执行者转向 Agent，传统的“打开设备 → 浏览功能 → 选择服务 → 执行任务”会放大用户的认知负担。 用户需要记住产品有什么能力、入口在哪里，才能完成一次交互。
设计方向：把桌面从功能目录，转变为用户与 Agent 协作的起点。
从固定桌面，到个性化桌面
把能力的组织权交给用户，让高频服务留在最熟悉的位置。
产品提供能力，用户决定自己的首页。从功能入口，到场景入口
弱化“打开某个 App”，转向“家庭健康、联系家人、生活提醒”等真实目标。
用户不需要知道哪项功能负责完成任务。交互模型
从“用户找功能”到“Agent 理解意图”
两种模式的区别不在步骤多少，而在认知负担由谁承担。
传统模式功能导向
- 明确任务用户先判断自己要什么
- 寻找入口在设备中定位对应功能
- 调用服务选择并启动功能
- 获得结果完成任务后离开
Agent 模式意图驱动
- 表达目标用户用自然语言描述需要
- 理解上下文Agent 判断真实意图
- 调度能力自主规划并执行
- 主动反馈说明结果与下一步
“零级入口”
从功能调用到意图表达
1.0阶段
告诉用户“我有什么”
2.0阶段
用户决定“我要什么”
3.0阶段
Home Claw 理解“用户需要什么”
桌面不再是功能展示区域，
而成为 Agent 存在的空间。
随着 AI Agent 能力增强，设备不应再要求用户提前理解和管理所有能力。
因此桌面从：“功能展示与管理空间”
转变为：“用户表达目标，Agent 组织能力”的协作空间。
用户只需要表达目标：
- “帮我安排明天行程”
- “最近睡眠不好”
- “提醒我联系家人”
Agent 根据上下文理解需求，并自主调度对应能力。
02
主动感知系统
从“人找服务”到“服务找人”
设备能否在用户没有主动输入时，理解用户状态并提供合适服务
在探索 Agent 产品形态时，我发现单纯提升 AI 的回答能力，并不能解决用户何时需要帮助、是否愿意被打扰的问题。
真正要解决的，是用户开口之前的那段时间。
在传统智能助手模式下，系统的运行逻辑是：
用户输入
理解意图
给出反馈
AI 的能力被限制在用户主动发起的瞬间，设备仍然需要：
- 用户主动唤醒
- 用户明确提出需求
- 用户知道该请求哪项服务
但在真实家庭场景中，很多需求出现在用户尚未开口、甚至没有意识到需要帮助的时候。
今天天气怎么样？
杭州余杭今日（7 月 8 日）天气
全天概况：多云，气温 27℃~34℃，空气质量优，午后局部短时小雨，体感闷热。
我认为 Agent 的核心价值不是：“有问必答”
而是：“在合适的时间提供合适的帮助。”
因此主动服务需要先建立边界：系统关注什么、何时出现、以什么强度介入。
- 持续获取用户状态
- 判断潜在需求
- 主动生成服务
- 根据风险等级决定干预方式
设计决策：主动性的边界
主动服务最大的挑战不是“如何主动”，而是什么情况下应该主动
过度主动，用户觉得打扰；过度被动，Agent 失去价值。因此设计三层主动等级：
晨间问候、信息推送
- 行为
- 主动反馈 + 服务协议
- 策略
- 自动触发 + 低打扰
环境调节、设备控制
- 行为
- 自动执行 + 进度反馈
- 策略
- 用户授权
跌倒检测、健康异常
- 行为
- 紧急呼叫 + 通知家属
- 策略
- 快速确认
晨间睡眠反馈的设计规则
这类反馈的重点不是把夜间数据完整播报一遍，而是把“昨晚状态如何”转化成用户早上能快速理解、愿意接收的低打扰服务。
- 触达时机放在早晨，避开夜间和工作中的高打扰场景
- 信息顺序先给结论，再用总睡眠、夜间心率、呼吸频率解释判断依据
- 正常状态保持简短和肯定，减少用户对健康数据的焦虑感
- 当连续变化或风险升高时，再展开原因说明和下一步建议
反馈结构
先告诉用户“昨晚睡得怎么样”，再呈现关键指标作为依据。
只有当状态发生明显变化时，才进一步解释原因并引导用户查看详情或调整当天安排。
主动感知案例 · Proactive Sensing
根据场景变化，触发不同服务
在起床、休闲、休息等生活片段中，Agent 根据时间、环境和用户状态判断是否需要出现，并选择日程提醒、内容播报、清洁联动或高优先级呼叫等不同反馈方式。
03
可感知的
可感知的
交互载体
从语音助手到智能伙伴
让不可见的 AI 状态变得可感知
随着 HomeClaw 从 AI Assistant 向 AI Agent 演进，设备的角色发生变化。
过去
语音助手只是隐藏在系统中的一个功能入口。用户通过唤醒词触发设备，完成一次性的指令交互。
现在
Agent 模式下，设备需要持续呈现状态、解释过程，并建立长期可理解的交互关系。
我们引入 IP 形象作为 Agent 的视觉载体，让不可见的 AI 状态变得可感知。
状态可视化
过程反馈
情绪表达
关系建立
Agent 状态反馈体系
Agent 的交互过程包含多个不可见状态，需要通过 IP 动作和表情转化成用户能看懂的反馈。
-
待机状态
保持陪伴感，同时避免过度打扰。
-
内容输出状态
通过动作反馈，让用户知道 Agent 正在进行信息播报。
-
语音接收状态
明确表达设备正在接收用户输入，降低等待焦虑。
-
理解处理中
将 AI 的处理过程可视化，增强用户对系统状态的理解。
-
异常反馈状态
通过 IP 表情变化传递错误信息，降低冰冷的系统提示感。
04
健康管理
健康管理
与主动守护
健康管理与主动守护
把健康数据转化为用户能理解、能行动的状态反馈
在家庭健康场景中，关键不是让用户看到更多指标，而是降低判断成本：今天状态如何、是否需要关注、下一步该做什么。 设计重点因此从数据展示，转向状态解释、打扰控制，以及风险场景下的后续帮助路径。
快速看懂
减少打扰
明确行动
及时响应
设计命题：如何让用户在平时少被打扰，在需要帮助时不被遗漏。
产品思路
先定义用户如何判断状态，再决定界面信息与提醒方式
如何降低理解成本
不必辨认设备
无论数据来自哪台设备，用户都从自己的健康状态进入
先看到整体结论
减少逐项比较指标的理解负担
理解对生活的影响
把数据放回睡眠、活动与日常行为中解释
如何控制介入强度
正常时安静陪伴
变化时说明发生了什么
风险出现时区分轻重
提醒时给出可执行建议
无法回应时仍能获得帮助
先帮助用户判断发生了什么，再决定是否需要行动。
健康套件
同一套健康信息，如何适配“主动查看”与“被提醒关注”两种用户时刻？
想了解时，按需查看完整状态
需要关注时，直接获得状态结论
按需查看
+
及时告知
入口不同，但都先帮助用户判断“今天是否需要关注”。
两种触达，对应两种用户意图
用户想主动了解时进入健康套件；当状态变化值得关注时，由 Agent 汇总并告知。
首页承接主动查看，巡检报告补足用户没有打开页面的时刻。先给结论，再看依据
两种触达都先回答今天是否正常，需要时再查看具体指标和变化原因。
状态组织保持一致
无论用户查看页面还是接收报告，都按熟悉的健康状态理解，不必重新学习。
触达方式随场景变化，用户理解健康状态的方式保持一致
全场景健康守护
将毫米波雷达感知转化为可理解的健康状态
整合毫米波雷达可获取的活动、呼吸、心率与睡眠等数据，并将原始感知结果转化为围绕人的可视化状态。用户不必理解传感器数据，也能先看懂当前整体情况，再按需查看细节。
将多维感知整合为可视化状态，让用户无需逐项解读，也能快速理解当下情况。
状态理解
让用户看到有意义的健康事件，而不是传感器信号
久坐事件
只有静止状态持续达到条件才形成久坐事件，避免短暂停留带来不必要的提醒。
起夜事件
结合离床时间与持续清醒状态，避免正常翻身被误判为起夜。
活动轨迹
把分散的位置记录整理成一天的活动路径，帮助用户回顾生活状态。
跌倒事件
姿态变化后继续观察活动情况，减少误报带来的不必要惊扰。
用户无需理解传感器如何工作，只需知道发生了什么、是否需要关注。
风险分级
什么时候该提醒，提醒到什么程度？
静默守护
提示强度
低
状态稳定
用户无需操作
主动提醒
提示强度
中
出现轻度变化
用户可以自行调整
紧急协助
提示强度
高
可能无法自行处理
需要及时获得帮助
风险越高 → 信息越醒目 → 确认越明确 → 帮助越及时
每一次打扰都应对应明确的用户风险和下一步行动。
主动健康干预
怎样提醒，既能推动行动，又不会制造长期负担？
用户长时间保持同一坐姿
持续达到 50 min
判断为需要活动
通过屏幕 + 语音轻提醒
建议：起身活动 5 分钟
久坐属于用户可以自行处理的低风险事件，因此提醒应允许关闭或稍后处理，建议也要容易完成；避免把所有监测结果都升级为强提醒，降低长期使用中的提醒疲劳。
好的主动提醒不只是告知异常，也要让用户保有是否立即行动的选择。
紧急事件
当用户无法及时回应时，如何保证帮助不中断？
发现高风险
先确认用户是否安全
全屏提示，便于及时回应
保留 10 秒响应窗口
无人回应时联系紧急联系人 / 120
高风险场景里，用户真正需要的不是一条“异常”提示，而是在无法自行处理时，帮助仍能继续。
风险判断由专业规则支撑；我的设计关注如何把风险转化为用户看得懂、来得及回应，并能继续推进帮助的体验路径。
05
设计总结
设计的不再只是界面，而是人与智能系统之间的协作关系
HomeClaw 并不是一个已经商业化发布的最终产品，而是一次围绕 AI Agent 智能硬件体验的完整设计探索。 从产品定义、交互框架到主动反馈与健康守护，我尝试回答一个持续思考的问题：
当 AI 从工具走向 Agent，产品设计应该如何随之改变？
“零级入口”
人与 Agent 如何开始交流
主动感知
Agent 什么时候应该主动
IP
Agent 以什么身份出现
健康守护
当用户无法自行处理风险时，Agent 如何让帮助继续？
过去我们设计的是功能如何被使用，而在 Agent 产品中，更重要的是设计用户如何理解系统、信任系统，并在关键时刻愿意让系统介入。