1. 陪伴机器人最容易犯的错误先买硬件再想需求我见过不止一个团队拿到AI陪伴机器人这个选题后第一反应是去选底盘、选屏幕、选麦克风阵列甚至先把外观手板打出来再回头想这玩意儿到底要陪谁。这个顺序一旦定下来后面百分之八十的坑都已经埋好了。做一个老人陪伴机器人和做一个儿童陪伴机器人底层逻辑完全是两回事。老人的核心痛点是怕出意外没人知道和子女不在身边的孤独感儿童的核心痛点是需要符合认知发展规律的互动和家长希望有人能陪孩子但不希望被屏幕绑架独居者的核心痛点则是日常秩序感的维系和情绪需要有一个安全出口。这三种需求如果扔到同一套需求文档里最后做出来的东西大概率是谁都不满意的四不像。所以我在这类项目里坚持一条原则先把需求建模做透再做任何技术选型。需求建模不是画几张用户画像就完事而是要回答几个非常具体的问题——目标用户每天在什么场景下会用到它每次使用时长多久用户最不能接受的失败是什么如果机器人的某功能做错了后果有多严重这些问题没有答案的时候所谓的产品定义都是拍脑袋。这篇文章我就围绕AI陪伴机器人-三类用户三种陪伴这个项目把老人、儿童、独居者三类用户的需求建模完整拆解一遍。从三类用户各自的真实陪伴诉求开始到如何把抽象诉求转化成可落地的功能需求和技术指标再到交互设计和隐私边界的处理最后聊聊实际落地时踩过的坑。文章会比较长但每一步都是可以直接抄走的方法。2. 三类用户的陪伴诉求本质上是三个完全不同的需求模型很多产品经理喜欢把陪伴当成一个通用需求来处理这是一个认知上的根本性偏差。同样是陪伴老人要的是安全感加情感回流儿童要的是发展性互动独居者要的是秩序感和情绪出口。这三种诉求不仅在功能层面不同在交互逻辑、数据敏感度、失败容忍度上都有本质差异。2.1 老人群体被看见的安全感比聊天本身更重要老人的陪伴需求经常被简化成陪聊。但实际调研做下来你会发现老人真正在意的是两件事一是身体出状况时能被及时发现二是自己的存在感被确认。很多老人每天愿意跟机器人说话并不是因为机器人聊得有多好而是因为机器人会记得他早上吃了什么、会提醒他按时吃药、会在他按下紧急按钮时第一时间联系子女。这些行为的本质是被看见。所以在对老人做需求建模时我不会把话术丰富度放在需求优先级第一位而是把健康监测的可靠性紧急事件的响应链路日常关怀的持续性放在前面。老人对机器人的信任建立在这三件事不出错的基础上。一旦出现一次紧急呼叫没响应或者血糖数据明显异常却没有提醒这个设备在老人心里的信任感会瞬间归零之后再怎么优化聊天内容都很难补救。另一个很容易被忽略的点是老人对技术失败的归因方式。年轻人遇到设备没反应会认为设备出bug了很多老人会认为自己按错了搞坏了然后产生强烈的挫败感甚至会因此放弃使用。所以对老人场景来说需求建模时必须把失败兜底作为一个独立需求来设计语音没唤醒时必须设备端有明显的光效或声音反馈触摸无效时要有备用的物理按键识别错误时要有温和的纠错引导。这些在需求文档里不能只是一句话而要有明确的触发条件和交互路径。2.2 儿童群体陪伴的本质是发展性互动不是简单地哄儿童用户和老人用户最大的区别在于儿童用户的需求是动态变化的。一个三岁孩子和一个七岁孩子对陪伴机器人的需求差异非常大。三岁阶段更看重语音交互的容错、情绪安抚和安全边界七岁阶段则开始需要知识问答、创意表达和一定的挑战性任务。我在做儿童陪伴机器人需求建模时会先把儿童发展心理学里的几个关键维度拉进来语言发展、社会情感发展、认知发展、动作发展。机器人的每一项功能都能对应到一个发展维度上。比如读绘本功能对应语言发展和认知发展角色扮演游戏对应社会情感发展声控小游戏对应动作协调和反应能力。这样做的价值在于每一个需求条目都能说清楚为什么要有而不是因为竞品有这个功能。儿童的陪伴还有一个特殊之处就是对重复的容忍度极高。成年人会觉得同一个故事听三遍很烦但儿童恰恰是通过重复来学习和获得安全感的。这意味着需求建模时内容运营策略和推荐算法都要调整不能照搬成人内容平台的去重逻辑。我曾经在需求评审时遇到过算法同学坚持要做个性化推荐去重结果被产品团队否掉了——在儿童场景里重复播放同一个熟悉的故事本身就是情感需求的一部分。另外儿童场景的交互节奏必须放慢。成年人语音交互的响应时间在500毫秒以内感觉是流畅的但儿童需要更多的思考时间响应太快反而会造成压迫感。需求建模时要把响应延迟区间作为一个明确的交互参数写进需求不是越快越好而是要匹配目标年龄段的信息处理节奏。2.3 独居群体陪伴感来自秩序感的维系而不是高频打扰独居者的陪伴需求表面上看起来很矛盾他们既希望有陪伴又讨厌被打扰。一个人住久了会形成自己的生活节奏严格的、可预期的、不突兀的互动才是他们最能接受的陪伴形式。那些一天到晚主动搭话的机器人对独居者来说不是陪伴是骚扰。我在做独居群体的用户访谈时发现他们提到最多的陪伴场景其实非常琐碎下班回家时有一句欢迎回来、睡前有人提醒明天降温记得加衣服、连续加班三天后有人问一句要不要早点休息。这些场景的共同点是低频、轻打扰、有温度。独居者并不需要机器人无时无刻地刷存在感他们需要的是在某些关键节点上机器人能像一个细心的室友一样出现一下。所以对独居者的需求建模我会把用户活动状态感知和介入时机判断作为核心能力来建。机器人需要理解用户当前处于什么状态——是在沙发上刷手机、是在厨房做饭、还是在门口换鞋——然后判断当前是否适合发起互动。这个能力的技术实现并不容易需要麦克风阵列的声源定位、视觉传感器的姿态估计、甚至环境传感器的开关门信号做多模态融合但它是独居陪伴场景里体验和骚扰的分水岭。独居场景的另一个需求特征是情绪出口的私密性。很多人不愿意让朋友家人知道自己状态不好但对一个机器人反而能放下戒备。这意味着需求建模时情绪倾诉相关功能必须设计成绝对隐私模式——数据默认不上云、对话内容不做分析、甚至不保留记录。这个需求和商业化的数据收集诉求天然冲突但在产品定义阶段必须给用户一个明确的选择权。3. 把抽象的陪伴需求转成可落地的技术需求需求建模的具体流程前面说的是三类用户的需求长什么样接下来聊怎么把需求转化成开发团队能执行的需求条目和功能优先级。这部分我以自己实际做过的建模流程为例步骤不一定适用于所有团队但思路可以复用。3.1 第一步建立用户场景卡片而不是写用户画像很多团队做需求建模时喜欢写那种35岁女性独居养猫喜欢看脱口秀的人物画像然后就没有然后了。这种画像看起来很生动但对开发没有指导意义。我习惯用的是场景卡片把用户画像还原到具体的时间、空间、事件和情绪中。举个例子独居用户李女士的场景卡片可以这样写时间晚上十点左右空间客厅沙发状态刚结束加班到家吃了外卖有点疲惫触发事件听到窗外下雨声想起今天没收衣服潜在陪伴需求如果这个时间机器人主动说一句外面下雨了阳台的衣服要不要收一下用户会感到被关心但如果机器人只说你回来啦今天累不累用户可能敷衍回应甚至不想理每张场景卡片都包含足够具体的信息才能拆解出真正的需求条目。上面这个例子里机器人要能在晚上十点的客厅环境下识别出下雨声这一环境事件并判断用户处于刚到家且疲惫的状态还需要选择恰当的时机发起提醒。这些可以分别转化为声音事件识别、状态推断和主动交互时机的技术需求。老人和儿童也同样需要做场景卡片而且要做得更细。老人的场景要覆盖作息规律用药安排身体不适的表现社交活动的频率这几个维度儿童的场景要覆盖在园时间家庭活动情绪波动时刻屏幕使用时长。每个场景卡片背后都对应着具体的环境声音、交互频率和内容需求。3.2 第二步构建需求-功能-技术映射矩阵场景卡片做完之后接下来是把每条需求映射到功能模块和技术方案上。我习惯用一个三列的矩阵表格来做这个动作左边是用户需求中间是功能设计右边是技术依赖。这个矩阵不仅是需求文档的骨架也是后续研发排期的依据。用户需求来自场景卡片功能设计技术依赖老人独居时摔倒能被及时发现跌倒检测 自动呼叫紧急联系人视觉姿态识别 / 毫米波雷达 / 运动传感器儿童想听同一个故事很多遍重复播放 互动提问式阅读内容管理系统 / 语音交互状态机独居者深夜情绪低落时想找人说话隐私模式对话对话内容本地处理本地小模型推理 / 端侧数据加密老人忘记是否吃过药用药提醒 服药确认多模态交互确认流程 / 结构化日程儿童用语言表达不清楚时不被挫败容错对话流程 视觉辅助意图确认NLU 意图改写 / 屏幕可视化点选独居者加班到家希望有轻问候场景感知式主动问候声纹识别 / 环境事件检测 / 时间规则引擎这张表看着简单但每一条背后都需要跟研发团队逐项对齐。特别是技术依赖这一列往往会改变功能设计的形态。比如跌倒检测如果采用视觉方案就要求机器人必须处于一个能看到全屋关键区域的固定位置这跟能移动跟随的需求会冲突如果改成毫米波雷达又会增加硬件成本。需求建模做到这一步产品和技术的矛盾就开始浮现了这正是建模流程的价值所在——在编码之前就暴露矛盾而不是等到开模后才发现。3.3 第三步用失败成本和频率来确定优先级而不是用户投票需求优先级排序是需求建模里最容易产生争议的环节。很多团队喜欢用用户需求强烈程度来排优先级但用户反馈强烈的需求不一定是技术风险低的需求。我自己的习惯是用两个维度来判断失败成本和发生频率。失败成本是指这个需求如果做得不好用户会因此遭受到什么损失。对老人场景来说跌倒检测失灵的失败成本极高可能直接危及生命对儿童场景来说内容审核漏掉一条有害信息的失败成本极高对独居者场景来说隐私模式失效的失败成本同样极高。这些需求即使发生频率不高也必须放进最高优先级。发生频率则决定了需求的体验权重。老人每天都会使用的吃药提醒发生频率很高虽然每次失败可能只是错过一顿药但长期来看频繁的小失败会摧毁用户信任。儿童每天要听的故事播放功能同理。发生频率高的需求宁可功能简单也要保证稳定。我用这两个维度把三类用户的所有候选需求排进一个优先级矩阵然后和团队逐条讨论。这个讨论过程往往比最终的优先级清单更重要因为它逼着每个团队成员说出自己为什么认为某件事重要也逼着产品经理用数据和场景来说话而不是凭感觉拍优先级。3.4 第四步定义MVP边界坚决砍掉锦上添花需求需求建模到了最后一定要有一个收敛动作否则需求列表永远只会膨胀而不会收缩。我把这个收敛动作叫做MVP边界定义。MVP不是把需求做简单而是把需求做少但每一条都做到闭环。拿老人陪伴机器人举例一个可能的MVP切法是吃药提醒和服药确认、跌倒检测和紧急呼叫、语音问候和天气播报、视频通话调用。这四个功能看起来普通但它们各自覆盖了老人场景最核心的被看见的安全感健康管理的可靠性情感连接的入口。至于健康数据周报、亲友远程查看状态、语音游戏等全部放到MVP之外。儿童场景的MVP切法会是语音互动故事播放、定时故事时间管理、简易角色扮演对话、家长端远程控制。独居场景的MVP切法则是场景感知轻问候、隐私模式情绪对话、日常日程语音备忘、天气和环境信息主动提醒。我每次定义MVP边界时都会逼团队回答一个问题如果用户只能用到这四个功能他还愿意继续使用这个产品吗如果答案是犹豫的说明MVP的切法有问题如果答案是肯定的那MVP之外的需求就勇敢扔掉留给下一个迭代。4. 交互设计约束三类用户在同一个硬件上如何各取所需需求建模落地过程中交互设计是承上启下的关键环节。很多团队把交互设计理解成语音话术和界面布局但在陪伴机器人场景里交互设计实际上要回答的是这个设备在不同用户面前应该表现出什么样的性格和反应方式。4.1 老人端的交互必须是低门槛高容错物理兜底老人使用智能设备最常见的挫败感来源是不知道当前处于什么状态。语音助手没反应时老人会以为设备坏了触屏操作误触后老人会陷入一个自己不认识的新界面而不知道如何返回。所以老人端的交互设计第一原则是状态透明。我在需求文档中对老人端交互提出过几个硬性要求设备在聆听、思考、回复、执行四个状态下要有截然不同的光效和声音反馈屏幕上的信息层级不超过两层任何界面都允许通过一个物理按键回到首页语音唤醒失败后必须有文字和声音的双重提示告诉用户你可以再试一次或者请靠近一点说。这些要求看着琐碎但它们决定了老人愿意不愿意把一个机器人长期放在家里。另外一个关键设计是离线可用。老人家里的网络状况并不总是稳定如果核心功能全部依赖云端断网时设备就变成一个摆设对用户信任的打击是致命的。所以老人端需求建模时我会把关键词唤醒、计时提醒、基础问答、本地日志存储这四项能力划为离线必需至少保证断网时设备最基础的功能不瘫痪。这个要求会增加端侧计算资源的投入但从需求优先级来看这是值得的。4.2 儿童端的交互必须是内容安全优先节奏匹配家长可控儿童端的交互设计难度在于不能照搬成人语音助手的一问一答模式。低龄儿童的语言表达往往不完整、不准确如果机器人每次都按照成人的逻辑去理解并纠正孩子很快就会产生挫败感。我在儿童端的交互需求里会专门加一条意图宽容策略当儿童请求的信息不完整时机器人优先给出猜测确认的交互而不是直接回答我不明白。比如孩子说我要听那个小兔子如果机器人存储的故事里有多个包含小兔子的内容应该回答你是想听《小兔子乖乖》还是《兔子先生的菜园子》呢而不是我没有听懂请再说一次。这个策略能把儿童交互的完成率提升很大一截。内容安全在儿童端是比功能丰富度更高优先级的需求。这里的内容安全包括三层一是对话内容中不能出现暴力、惊悚或不适合儿童年龄的信息二是突发场景下比如听到儿童哭声或者呼救机器人要能切换到紧急响应流程三是语音合成的声音要亲切自然不能有机械感和恐怖谷效应。这三层需求每一项都需要单独的技术方案和测试用例来保障。家长可控也不能忽略。儿童端不能做成一个完全封闭的系统家长需要知道孩子每天和机器人互动了什么内容、获得哪些信息、语音交互的时长有多少。但家长端的设计要克制不能把儿童使用情况做成行为监控的样子而是以成长记录的角度来展示。4.3 独居者端的交互必须是低打扰倡议场景感知私密性独居者场景的交互设计最容易犯的错误是把主动交互当成产品卖点。很多团队认为独居者就是因为孤独才需要陪伴机器人所以机器人应该多主动说话。这个判断在需求建模阶段就被我的用户访谈推翻了。独居者真正接受的主动交互一定是跟当下的场景和事件强相关的。比如早上起床后天气预报提醒晚上如果工作到很晚听到一句注意休息这些是借事陪伴但那种一天三次的问候关怀式主动聊天会让用户觉得被打扰甚至是负担。所以独居端的需求建模里我会把重点放在事件驱动的主动交互机制上而不是时间驱动或随机驱动。私密性对独居者来说是信任的根源。我在需求文档里会做这样一个设计当用户说出我想一个人待会儿或者你别说了这类表达时机器人必须立刻停止主动交互并且进入静默模式。静默模式期间只保留必要的安全监测能力不记录任何对话内容。这个设计传递的信号是这个设备尊重用户的空间而不是一个无孔不入的话痨。独居端的另一个交互难点是情绪感知的边界。机器人不应该随便去分析用户的情绪状态一旦在需求设计上加入情绪识别并显示在屏幕上用户会产生被窥探的不适感。我在实际项目中会把情绪理解为引导用户倾诉的触发信号而不是贴标签的结果。机器人只要知道用户此刻需要被倾听不需要知道用户处于轻度抑郁还是中度焦虑这种标签对用户没有任何帮助反而可能造成心理负担。5. 隐私安全和伦理边界需求建模中最容易翻车的部分隐私安全在陪伴机器人项目里不是合规部门单独操心的事而是需要写死在需求建模阶段的硬约束。很多团队把隐私当成上线前的合规检查项结果就是功能做完了再返工那是最贵的改法。5.1 三类用户的数据采集边界差异巨大老人、儿童、独居者三类用户各自的数据敏感级别完全不同。老人场景会涉及健康数据和用药记录这些数据的采集边界要和医疗健康领域的通用规范对齐每一份数据都必须有明确的采集目的、保存期限和访问权限。儿童场景涉及未成年人个人信息对数据的处理要求更高包括监护人授权、数据最小化、禁用个性化广告等。独居者场景虽然用户是成年人但涉及的是私密对话和行为习惯同样需要严格保护。我在需求建模阶段会直接定义好三类数据的分级体系哪些数据只允许设备端本地保存哪些允许上云但必须匿名化哪些必须由用户主动选择才能开启采集。这个分级表在需求评审时跟法务、安全、产品、研发一起过一遍能省掉后面大量的扯皮。5.2 陪伴和监视只有一线之隔陪伴机器人的本质是感知用户但感知到什么程度这是需求建模阶段必须划清的伦理红线。老人房间里的摄像头如果一直开着确实能实现跌倒检测但也会让老人产生被监视的感觉儿童机器人如果记录孩子在客厅的所有对话家长也许安心了但孩子的隐私和自主性就受到了侵害。我的处理原则是用最少的感知能力实现最核心的陪伴目标。能依靠麦克风声音事件判断场景的就不开摄像头能用毫米波雷达做跌倒检测的就不用视觉方案能在设备端完成的数据处理就不上传云端。感知能力的每一步增加都要在需求文档里写明它的不可替代性否则砍掉。拿老人房的跌倒检测来说一套设计合理的毫米波雷达方案完全可以在不做图像记录的前提下感知到跌倒事件。这就不需要把整间屋子都拍下来。5.3 用户对数据的知情权和撤回权必须前置设计在需求建模阶段就要考虑用户如何撤回已经授权的数据。这个撤回不是上线后补一个退款页面而在交互流程里要有明确入口。老人用户可以语音要求把今天的录音删掉独居用户可以在隐私模式下清除全部历史对话儿童用户家长可以一键关闭所有数据采集。这些能力都要在需求优先级里排到靠前的位置。我见过太多陪伴机器人项目隐私设置藏在App的三级菜单里老年用户根本找不到最后变成一纸空文。所以在需求建模时我给团队定的要求是隐私设置必须支持语音直达用户说我不想让你记住了设备必须立刻回应并给出确认删除的界面。这个功能在需求文档里叫隐私授权反悔机制它表面上只是一个交互流程实际上决定了用户对设备的信任天花板。6. 从需求建模到产品落地几个值得提前知道的坑流程和方法论讲完最后聊几个我在实际项目中反复踩过的坑。这些坑如果不提前知道踩进去之后返工成本都很高。第一个坑是老人语音唤醒率永远比实验室低。实验室环境下唤醒率做到98%很容易但放在老人家里电视声、厨房噪音、老人说话含糊、方言口音都会让唤醒率大幅下降。需求建模阶段如果只写语音唤醒准确率≥95%这种指标测试阶段一定会被翻车。我会给老人端单独定义一套兜底唤醒需求比如设备上放一个明显的物理按键告诉老人实在叫不醒它就按这个键。老人需要的是永远有退路而不是理论上的高精准度。第二个坑是儿童内容审核的误杀会比漏判更影响体验。内容安全系统为了不放过任何有害信息往往会把大量正常内容一起拦截掉。比如孩子问什么是死亡这种问题很多审核模型会直接拒绝回答。需求建模阶段就要把这类敏感但正常的话题单独建立处理策略不能一刀切。我对儿童内容的期望是有害内容零漏判但正常内容也要尽可能有回答路径哪怕回答方式是这个问题的答案很复杂等你再长大一点我们一起找书看看好吗也比冷冰冰的我不能回答这个问题要好得多。第三个坑是独居者的陪伴感需要时间积累不能靠功能堆砌。很多团队为了快速让用户觉得被陪伴拼了命地加主动聊天、加表情互动、加情绪分析结果用户用了一周就腻了。独居者的陪伴感其实来自机器人对用户习惯的记忆比如记住用户每天喝咖啡的时间、记住用户最近在准备考试、记住用户说过不喜欢下雨天。这种记忆能力需要做专门的数据结构来支撑也要求对话引擎具备长期记忆存储和检索的能力。需求建模阶段如果不把用户长期记忆作为一个独立模块来设计后期再想加会非常痛苦。回到需求建模这件事本身。我始终认为陪伴机器人项目的成败在项目启动的第一周就已经决定了。那一周如果大家都在讨论底座选型、屏幕尺寸、芯片算力这个项目大概率会在半年后发现做了一台什么都能干一点但什么都陪伴不好的设备。反过来如果那一周的讨论是从老人最怕什么儿童最需要什么独居者最讨厌什么开始的后面所有的技术选型都会自然地对齐到真实需求上。技术层面现在的多模态大模型、端侧推理芯片、语音交互方案都已经成熟到足以支撑陪伴机器人的核心体验了真正的瓶颈不是技术而是对陪伴这两个字的理解深度。陪伴不是话术的堆砌不是拟人化表情的模仿而是对一个具体的人在具体场景下真实需求的准确回应。这个理解只有在需求建模阶段扎扎实实地做进去才能在最终的产品体验里长出来。
