目录

一、MicroDuck真正值得研究的，是身体表达如何成为产品价值

1. 先认清产品，才能谈借鉴

2. 能够接受调试的人，未必代表准备购买陪伴的人

3. 身体的价值，要落实到具体动作

4. 持续陪伴，不能只用聊天时长衡量

二、从动作到整机，真正困难的是把每一种状态接住

1. 大模型负责什么，运动控制负责什么

2. 仿真能够帮助试错，迁移仍需要面对真实差异

3. 执行器选型，不能只盯着扭矩和单价

4. 从第一台样机到可交付产品，要补上恢复与一致性

三、把硬件卖出去以后，经营问题才真正开始展开

1. 售价减去零件钱，剩下的并不都是利润

2. 云服务不是一张固定不变的账单

3. 利润表没有告诉经营者，钱什么时候回来

四、如果以MicroDuck为起点做产品，下一笔投入应该买到什么证据

1. 先把业务问题写清楚，再决定工程问题做到多深

2. 概念验证要隔离差异，不能把完整度差异当产品偏好

3. 安全进入真实使用后，观察完整的生活过程

4. 工程门禁与商业门禁，各自回答不同的问题

5. 小团队需要的是责任闭合，不是照搬组织规模

作者简介

---

一只售价399美元的双足机器鸭，把身体动作、开源软件与AI开发放进了同一个产品。本文从用户价值、工程实现、经营成本和验证路径四个层面，分析它值得借鉴的设计，以及消费级陪伴产品仍要回答的问题。

作者｜卫朋

一只25厘米高、装有15个电机的机器鸭，能够走路、坐下、蹲下，还可以安装滚轮。

把这样一个产品放到面前，讨论很容易围绕两个问题展开：

它是怎么做出来的，自己能不能做一只？

但站在硬件产品负责人的位置，还有一个问题需要提前回答：当这些动作不再新鲜，它凭什么继续留在用户的生活里？

MicroDuck由Pollen Robotics推出。

按官方截至2026年9月4日的发布资料，它于8月27日开启预售，入门价格为399美元，不含税费和运费，首批交付目标是2026年圣诞节前。

笔者对它的兴趣，集中在一个交叉点：

当身体可以被软件持续训练和更新，硬件团队如何把技术上的可实现，转化为用户愿意购买、企业能够长期交付的产品？

这个问题需要同时看价值、工程、经营和验证，单独拿出任何一项，都容易得到过早的结论。

图1｜MicroDuck产品化判断全景：价值、工程、经营必须同时闭合

一、MicroDuck真正值得研究的，是身体表达如何成为产品价值

1. 先认清产品，才能谈借鉴

MicroDuck的官方表达包含可玩性、学习与开发属性。

软件开源范围覆盖控制、仿真、训练和部署相关工具；

机械和电子设计文件并不包含在这项开源声明中。

把它直接称为「开源硬件机器鸭」，会让后续判断从起点就发生偏移。

这处边界为什么重要？

对于学习者，可以研究软件怎样组织、动作怎样训练；

对于准备商业化的团队，还需要解决结构设计、电路、制造文件和使用权利。

获得一套代码，与获得一套可以采购、装配、测试并销售的整机方案，是两种不同的交付物。

前者提供了研究入口，后者需要一整条产品证据链。

也不宜把MicroDuck提前限定成某一种消费陪伴产品。

官方产品有自己的目标与使用方式，笔者在这里讨论的，是从它出发构思消费级陪伴产品时，需要补充哪些判断。

这个延伸分析不代表厂商已经承诺本文提出的全部能力，更不能将延伸方案的缺口倒过来当成官方产品的缺陷。

从产品设计看，MicroDuck的一个可借鉴之处，是把动作能力和进一步开发的入口放在同一件硬件上。

使用者可以先理解一个具体动作，再去接触背后的控制与训练。

相较于直接面对代码或抽象的模型输出，一个转头、蹲下或行走的结果，给了开发活动一个容易辨认的目标。

这里的价值判断是降低理解门槛，不能据此推断实际学习效果或市场规模。

同一件硬件，也可能承载两套不同的价值主张。

开发者购买的是可探索的空间，消费者购买的是可以直接获得的体验。

如果不把两者分开，团队很容易把开发者愿意折腾的过程，误认为普通消费者也愿意承担的使用成本。

2. 能够接受调试的人，未必代表准备购买陪伴的人

假设一位机器人爱好者购买设备，是为了修改动作策略。

他愿意查看日志、调整参数，甚至接受某次试验后重新恢复系统。

失败过程本身也能提供学习价值。

再假设一位消费者购买同样的设备，是希望工作间隙得到一个简短回应。

他未必愿意为一次点头研究网络配置，更不会把恢复系统视作购买目的。

这两个假设场景的差别，不在用户是否聪明，而在购买任务不同。

前者关心能改到什么程度，后者关心不改的时候能否顺利使用。

产品团队必须据此决定默认体验做到哪里、开发功能藏在哪里，以及出了问题由谁承担恢复工作。

把技术社区里的认可直接用于证明消费需求，会漏掉这层转换。

消费场景还要继续拆。

成年自购、家庭共玩和赠礼，并不是同一个购买过程。

• 自购者通常同时作购买与使用判断；

• 家庭场景需要区分付款、设置和实际互动的人；

• 赠礼场景则可能由一个人选购，另一个人承担摆放、充电和使用。

产品介绍若只让购买者觉得有趣，却没有让接收者理解怎样开始，交易完成后仍会留下体验缺口。

因此，笔者更愿意从一个窄问题开始：

在日常什么时刻，哪一类人愿意让这个机器人参与进来？

比如工作间隙的短暂互动，或在固定位置观察它的动作变化。

这些都是候选场景，需要验证。

用「全年龄」「全场景」「满足情感需求」覆盖它们，只会让产品定义失去可以检验的对象。

3. 身体的价值，要落实到具体动作

怎么理解身体表达的价值？

可以把陪伴任务拆成三种：朝向一个人，对一个动作作回应，以及主动改变与人的空间关系。

前两种不一定需要行走，第三种才开始要求自主位移。

继续往下，走近一个人，与用某种步态走近一个人，也可能提供不同体验。

这里需要对照产品，而不只是对照电机数量。

• 卡西欧Moflin的官方规格列出头部旋转与倾斜两轴；

• Loona列出两个轮部无刷执行器，以及四个用于身体和耳部的有刷执行器。

它们提供了低位移复杂度表达和轮式移动的具体参照，但这些规格本身不能证明哪一种更受欢迎，或哪一种单位成本更低。

对MicroDuck的双足路线，笔者建议拆开看三项增量。

• 第一项是移动，机器人能改变所在位置；

• 第二项是姿态，身体能够蹲下、坐下或调整朝向；

• 第三项是角色表达，步态和动作节奏参与塑造这只鸭子的辨识度。

用户若只需要其中一项，未必需要为另外两项承担同等代价。

这并不意味着应该立即去掉双腿。

产品价值也可能来自形态本身：一个人喜欢它的身体比例、动作方式和把玩过程，即使没有每天让它长距离行走，也可能愿意购买。

要验证的是这份增量是否真实，以及能否支撑相应成本，这项判断应给身体形态本身的购买价值留下验证空间。

反过来，轮式路线也不能只按「电机更少」作结论。

若要求机器人自主跟随、绕开障碍并回到充电位置，就需要处理轮子、环境感知和路径决策之间的协同。

原地表达减少了自主移动任务，却也放弃了主动接近的体验。

三种路线应当围绕同一个使用任务比较，明确各自保留了什么，又放弃了什么。

笔者会把这项比较落到一个具体问题上：

如果保留相近的角色、声音和回应方式，只改变运动形态，消费者愿意为哪一处差异多付钱、多留空间或多花照料时间？

这样才能把「喜欢这只鸭子」逐步拆成可以做产品取舍的依据。

4. 持续陪伴，不能只用聊天时长衡量

如果一个陪伴机器人每天只发生短暂互动，是否说明它没有价值？

不能直接这样判断。

需要区分三件事：

用户主动使用了多久，它安静地在场时是否仍有意义，以及用户为了维持它可用付出了多少劳动。

把三者揉成一个活跃数字，可能看不见真实的体验差别。

举一个待验证的场景：

用户工作时不希望被打扰，休息时才看它一眼、摸一下或发起一段游戏。

如果设备在工作期间保持安静，用户愿意继续把它留在手边，低互动时长不一定是失败。

相反，如果用户反复进入App，是为了重新连接、处理报错或调整音量，操作次数增加也不能直接解释为陪伴价值提高。

长期使用还需要避免另一个过早判断：新鲜感过去，需求就一定消失。

从产品分析角度，持续价值至少要同时记录获得与付出。

• 获得可能是放松、把玩、角色熟悉感或某项重复活动；

• 付出则包括充电、摆放、清理、恢复故障和回应设备的要求。

哪些获得足以覆盖哪些付出，需要在目标用户身上验证，无法从一个产品宣传片里读出来。

这里还涉及主动性的边界。

机器人主动回应，不等于必须不断发起互动。

笔者建议把拒绝、暂停和安静状态当作正常使用方式设计。

例如用户连续没有回应时，应该怎样降低打扰，怎样让下一次互动自然发生？

这些问题可以变成具体脚本，比笼统增加「更主动的AI」更接近体验本身。

消费陪伴的核心，在于找到值得反复发生的关系与活动。

MicroDuck提供了一种有辨识度的身体表达起点；

产品团队接下来的工作，是识别哪些表达值得长期保留，并据此限定需要投入的动作能力。

二、从动作到整机，真正困难的是把每一种状态接住

从动作成功到整机可交付：失效传导链01物理条件偏离训练假设质量、摩擦、间隙、响应与接触面发生差异02状态判断与执行保护缺口高层意图没有被稳定性、电量、速度与位置边界接住03异常无法被用户恢复断网、升级中断、搬动或关节偏差没有清晰回归路径DIAGNOSIS动作成功只是起点；可恢复、可追溯、可维护才接近交付卫朋卫朋

图2｜从动作到整机：技术成功并不自动等于可交付

1. 大模型负责什么，运动控制负责什么

MicroDuck的公开代码仓库提供了一个有价值的观察入口：README描述了运行在机载计算平台上的50Hz策略控制环，由神经网络策略驱动15个执行器，并关联到使用MuJoCo、PPO训练及导出ONNX的工作流程。

50Hz换算成名义周期是20毫秒。

这个数值说明了所描述策略环的时间尺度，不能把它当成云端对话延迟，也不能进一步认定执行器内部所有控制环都工作在同一频率。

产品讨论若只剩下「接入哪个大模型」，就会把动作执行所需的独立问题遮住。

从系统设计角度，笔者建议把这类产品分成三个职责层。

高层理解用户想做什么，动作层决定如何用已有能力完成任务，执行保护层判断当前状态是否允许动作。

比如用户要求机器人靠近，系统仍需处理路径是否可走、身体是否稳定、低电状态能否支持行动等问题。

下面的分层是设计建议，不代表官方整机已经逐项采用相同实现。

这种分工的关键，是让开放表达与受约束动作之间有明确接口。

高层可以给出目标或选择动作，底层不能因为一句自然语言指令就失去速度、位置和安全条件。

网络中断时应该怎样停，用户拿起机器人时应该怎样处理，必须在系统中有具体定义，而不能寄希望于对话模型临时理解现场。

这也解释了为什么模型回答正确，与机器人动作正确之间存在距离。

回答可以在屏幕里等待补充，动作已经作用在物理空间。

要把一次任务做完整，需要把感知结果、当前状态、允许动作和失败后的处理连起来。

语言能力可以扩展交互入口，却不能替代运动与安全设计。

2. 仿真能够帮助试错，迁移仍需要面对真实差异

公开训练工具的意义，在于为动作开发提供可重复修改和比较的环境。

团队可以调整训练设置，观察策略是否朝目标变化，再研究怎样部署到硬件。对一个准备学习机器人开发的团队，这条路径比只有一段演示视频更有研究价值，因为它提供了追踪动作形成过程的入口。

但虚拟机器人与实际装配出来的机器人，不能仅凭外形相似就视作同一个系统。

这里可以列出一组需要实测或建模的差异：部件质量和重心、关节摩擦与间隙、执行器响应、通信延迟，以及脚与接触面的关系。某项差异是否足以影响动作，取决于策略和工况，不能用一个统一的误差比例替所有项目作结论。

怎么理解这件事？

假设一种策略在训练中根据预期响应调整姿态，实际执行器却在当前负载下更慢，身体的下一次状态就可能偏离原先预期。

需要检查的是整条反馈关系，而不只是确认「指令发出去了」。

这是假设性的工程解释，不是对MicroDuck发生过某种失稳的描述。

换执行器也应沿着这条关系检查。价格更低、外形近似、安装孔能对上，只能回答部分问题；输出能力、传动特性、反馈信息和时延是否匹配，还要继续核对。

若改变了关键动力学条件，控制参数或策略可能需要重新评估。把替代件塞进原来的结构，再把同一程序烧进去，并不能自动继承原平台的动作表现。

因此，笔者看待开源训练资源时，会同时保留两种判断：它能提供学习和复用的起点，具体硬件适配仍然是一项需要证据的工作。

软件资产越容易取得，越需要清楚标记它验证过的硬件条件，避免在传播过程中只留下「代码可以直接用」。

3. 执行器选型，不能只盯着扭矩和单价

以一款公开组件作例子：ROBOTIS的XL330-M288-T手册列出3.7～6.0V输入范围、推荐5.0V，并给出5.0V下0.52N·m和1.47A的堵转工况。

这里只用它解释选型方法，不确认它就是现款MicroDuck整机采用的具体料号。

这组数字需要连着条件读。堵转数据不应直接写成可以长期持续输出的工作能力；电压范围也不能因为某条线能够插接，就被外形或接口名称替代。

产品评审要追问实际动作需要什么负载，允许持续多久，怎样识别异常，以及供电路径在对应工况下是否合适。

对多执行器整机，还需要把瞬态与平均值分开。只看平均耗电，可能漏掉动作切换时的供电要求；把所有执行器的堵转电流简单相加，又不能直接当成正常运行耗电。两种算法都缺少真实工况。可执行的做法，是先定义动作和异常状态，再用测量与分析支持电源、线缆、保护和热设计。

电源问题还与机械后果相连。对于需要姿态支撑的机器人，低电时关闭某个输出，可能改变身体状态；继续维持输出，又要考虑电池和温升。因此「电量不足就停止」还不够具体，需要说明停成什么姿态、在哪个阶段进入限制，以及用户能否安全搬动。这里没有一条可以脱离结构和控制方案单独批准的通用上电指令。

这正是硬件产品里容易被参数表掩盖的工作：部件各自符合规格，只能说明各自的边界。

整机是否可靠，要看它们连接之后，在定义的环境和任务中怎样共同工作。

对消费产品，还要继续考虑使用者不会按照研发人员的思路摆放、拿取和维护设备的情形。

4. 从第一台样机到可交付产品，要补上恢复与一致性

一台设备在熟悉它的研发人员手中运行，与一批设备交给不认识研发团队的使用者，交付条件不同。

前者可以有人调整零位、检查线缆并解释异常；后者需要依靠出厂一致性、说明、诊断和售后把这些工作接住。本节讨论的，是从样机转向批量交付需要补充的工作。

对于双足路线，值得列进生产策划的项目包括关节标识与安装方向、零位校准、传感器对应关系、固件与策略版本，以及测试结果如何关联到整机。某个动作失效时，团队需要知道这台设备是什么配置，而不能只知道它属于「同一款产品」。

恢复性也应成为可验收的能力。网络断开、更新被打断、设备被搬离原位，分别允许保留哪些功能、怎样提示、怎样回到可使用状态？这些问题若没有进入需求，就容易在研发任务表里无人负责。一次异常是否让消费者放弃设备，不只取决于异常本身，也与恢复过程是否能被理解有关；实际影响仍需用户研究验证。

可维护性则会反过来影响结构。

假设一个关节需要更换，应当拆开哪些部件，更换后是否需要重新校准，由售后还是用户完成？如果一处局部故障只能通过整机往返解决，那么包装、运输和服务工时就不能在成本表里按零处理。是否值得设计成模块化，应根据故障与维护需求判断，不能把可拆卸本身当成万能答案。

MicroDuck把动作开发呈现得很具体，产品化则要求团队把动作之外的状态也定义清楚。能够完成一次动作，是验证的起点；能够在不同设备、不同状态中重复交付，并在异常后恢复，才是下一层工程任务。

三、把硬件卖出去以后，经营问题才真正开始展开

售价减零件钱 ≠ 真实经营结果VS直觉算法经营算法×售价 − BOM漏掉装配、校准、履约、售后服务、获客与付款时点✓净收入 − 全部可变支出制造 + 履约售后 + 持续服务+ 获客 = 单位贡献再叠加固定投入与现金顺序看起来有利润库存、预售被误当成现金能否持续兑现服务期、退款、维修同步建模双足的增量成本，最终要由增量价值或经营效率支付卫朋卫朋

图3｜售价差额与真实单位贡献，是两套完全不同的算法

1. 售价减去零件钱，剩下的并不都是利润

看到399美元的售价，直觉上容易去查主控、电机和电池价格，再估算还能剩下多少空间。

这个动作可以帮助发现采购压力，但它还算不出产品的经营结果。

零售采购价、批量制造成本和整机履约成本，分别来自不同交易条件，需要拆开处理。

笔者建议把一台设备的单位贡献按五项要素计算：

制造成本、履约与售后成本、持续服务成本、获客成本，以及对应的收入。

制造端除了部件，还要按实际口径计入装配、校准、产测和包装；

持续服务端则不能只填一个模型接口价格。

前期研发、工装和固定人员费用另列，避免在不同位置重复扣除。

可以用一个纯教学算例说明，下面的数字均非MicroDuck或任何竞品的真实成本。

假设每台设备取得净收入1000元，制造支出400元，履约与售后预期支出100元，约定服务期内的可变服务支出100元，平均获客支出200元，那么单位贡献剩下200元。它还需要覆盖未计入以上项目的前期与固定费用。

如果这些前期与固定费用合计20万元，在上述假设全部成立、没有其他遗漏和口径变化的条件下，需要1000台净销量才能覆盖。

这个数值不是项目销量预测，只是说明：看上去有600元「售价与制造成本差」，并不等于每卖一台就能拿走600元。

收入、费用、服务期与销量的定义不一致，结果就会被算得过于乐观。

继续问一个更贴近MicroDuck的问题：

双足比原地表达多出的支出，由谁支付？

如果多出的身体体验能够带来更高净收入，或者有证据支持更低获客成本，就有进一步比较的依据。

如果只增加执行器、校准和维护负担，却没有对应的用户增量价值，那么扩大销量之前需要先回到产品定义。

这项比较不能只看多买了几颗电机。换一种运动形态，可能同时改变结构、产测、包装、维修和开发投入。要判断双足值不值得做，应该比较整条路线的贡献与资金需求。若两种路线的目标用户、销量和服务期限本就不同，也应分别建模，保留两种路线的销量与服务责任差异。

2. 云服务不是一张固定不变的账单

若产品使用云端语音或模型服务，支出会受到交互方式、上下文、模型、活跃情况和服务期限影响。对项目而言，需要明确的是哪些功能依赖外部服务，哪些可以在本地完成，以及服务受限时还保留什么体验。不能把一段标准对话的费用乘以想象中的次数，就直接当成完整生命周期成本。

例如，保留更多历史内容，可能改变输入与存储需求；增加语音、视觉或诊断服务，也会改变资源和治理工作。并不是每一次增加都没有价值，但每一次都应当对应具体任务。若所谓长期记忆只是把信息越存越多，却不能让用户理解、修改或删除，产品价值与数据负担就可能往不同方向走。

这里需要区分两种费用。随实际使用增长的部分，可以按对应的用量与服务期估算；为了让服务持续可用而维持的固定能力，则需要按经营周期考虑。日志处理、故障排查、用户请求和版本管理由谁承担，应当进入工作量分析，即使它们没有独立列在API报价页上，也应另行估算。

假设团队在销售时作出长期免费服务承诺，那么设备收款与后续支出的时间分布就不同。未来还会卖出多少新设备，不能替代已经售出设备对应的服务责任。笔者建议在销售前明确承诺期限、功能边界和退出安排，让收入模式有能力覆盖相应责任。

对用户而言，服务结束也不应只是一条后台状态。哪些动作还能运行，账户和历史如何处理，设备能否转赠，哪里可以得到清晰说明，都影响产品结束一个阶段的方式。对于被赋予角色与关系意义的硬件，这些安排更需要在设计时认真考虑，不能只讨论怎样让用户第一次喜欢它。

3. 利润表没有告诉经营者，钱什么时候回来

即使单位贡献为正，团队仍需要观察现金发生的顺序。

供应商何时收款，产品何时入库，渠道何时结算，以及退款、返修和服务支出何时出现，会共同决定某个时点需要准备多少资金。

把这些时间点压成一个年度利润数字，不能看清中间的缺口。

沿用前面的教学假设，若准备1000台设备、每台制造支出400元，对应制造货款为40万元。

若某个假设采购合同要求先付一半，预付款就是20万元。这笔钱在设备交付和销售回款之前发生。它不是在制造成本之外又多出20万元利润损失，而是同一笔制造货款提前占用了现金。

这个例子说明了预算与现金计划为什么要同时存在。

研发和测试支出、备货付款、平台回款、预计退款分别记录发生时点，再看累计余额。还没有卖出去的库存不能被当作现金，预售收入也不能直接视为可以任意使用的利润，因为对应的制造与交付工作尚未完成。

对于陪伴机器人，返修也需要特别拆开。

如果故障设备需要跨地区往返，支出可能涉及检查、运费、替换件和再次校准；实际采用哪一种路径，要结合维修网络与当地规则。

没有这些条件，单凭海外挂牌价高于国内，就判断某地区更赚钱，依据是不完整的。

因此，首发地区选择需要同时看可服务用户、成交条件、交付能力与现金周期。

产品能够以什么语言解释自己，出现异常后由谁支持，退货和维修怎样处理，这些问题应与市场研究并行。所谓全球市场，不能只是在一张表中把不同币种的售价换算成同一个数字。

四、如果以MicroDuck为起点做产品，下一笔投入应该买到什么证据

下一笔投入，要购买哪一种证据？CORE可决策证据概念与购买理由为什么选择／拒绝≠ 真实支付真实场景体验价值、负担、恢复≠ 规模结论工程制造验证稳定、追溯、维护≠ 需求判断商业现金验证价格、渠道、回款≠ 安全放行四类证据相互约束，不能互相替代卫朋卫朋

图4｜四类证据相互约束，但不能互相替代

1. 先把业务问题写清楚，再决定工程问题做到多深

分析走到这里，最容易出现一种偏移：

因为需要补的工作已经很清楚，就开始逐项安排开发。可执行的工作清单并不能自动证明方向值得投入。

对于尚在研究的项目，笔者更关心下一笔钱和下一段时间能够消除什么关键不确定性。

可以把业务计划压缩成六个问题：

为什么做，做成什么，什么时候需要达到什么状态，怎样实现与销售，需要投入多少，由谁承担。

它们分别对应价值、范围、节奏、路径、经济性和责任。六项内容需要相互约束：承诺的范围变了，实现路径、投入与责任也要同步调整。

例如，

• 「为什么做」不能只填AI硬件正在发展，应具体到目标人群与重复场景；

• 「做成什么」需要包含默认体验和不承诺的能力；

• 「怎样实现」应同时考虑自研、复用和服务依赖。

如果这几项尚未确定，却已经写出精确上市日与量产数量，计划中的确定性就超过了现有证据。

对于本文讨论的方向，可以把待证命题写成：面向某类成年自购者，一个低照料、回应清楚的实体角色，在某种日常场景中是否具有购买价值；双足身体又能增加多少价值。这样的命题仍需要收窄，但它至少允许出现反证，也能区分「陪伴需求成立」和「必须采用双足」两个判断。

2. 概念验证要隔离差异，不能把完整度差异当产品偏好

在没有安全实机之前，可以先研究概念表达。

笔者建议对照双足、原地表达和专用轮式三条候选路线，但这并不意味着同时启动三款硬件。

现阶段可以用完成度接近的故事板、动作示意或受控演示，解释同一个任务怎样完成，再观察参与者理解了什么。

这里有一个具体陷阱：

双足方案使用成熟产品的精彩演示，对照方案只有一张粗糙草图。

参与者更喜欢前者，究竟是偏好双足，还是偏好更完整的表达？

如果研究材料没有控制这个差异，结果就难以支持运动路线选择。

宣传素材适合帮助理解产品，未必天然适合做公平比较。

提问也应围绕取舍。

除了愿不愿买，还要讨论不买的原因、替代选择、放置位置，以及对充电、声音和服务条件的接受范围。

介绍价格时，必须说明包含哪些内容、哪些支出另外发生。

只展示机器人的正面动作，再问是否觉得可爱，得到的回答难以支撑制造投资。

研究结果还需要区分说法与行动。有人表达喜欢，但不愿为它留出位置；

有人对动作评价平淡，却能提出一个想反复使用的场景。

这些假设性的结果分别指向不同问题，不应急着合成一个平均满意度。概念阶段要找的是购买理由和拒绝条件，反对意见同样需要完整保留。

3. 安全进入真实使用后，观察完整的生活过程

当硬件满足相应试用条件，并具备必要授权与保护安排后，才能进一步研究真实使用。

观察范围应包括开始、日常、被打断、恢复以及停止使用。

只安排一场有人指导的体验，能帮助发现理解问题，却不足以回答设备在无人提醒时会怎样进入生活。

对于陪伴产品，可以分别记录主动互动、被动在场与维护操作。

• 用户主动叫它，是为了娱乐还是因为刚才没有响应；

• 一段时间没有互动，是已经失去兴趣，还是它安静在场就足够；

• 设备被放进柜子，是摆放不合适、出了故障，还是生活节奏变化？同一个表面行为，需要通过上下文作区分。

• 同时记录版本和事件。若试用期间更新了声音、动作或记忆方式，前后的反馈不能不加说明地混算。

某位参与者在故障后停止使用，既不能直接算成没有陪伴需求，也不能把这段失败从体验评价中删掉。

产品面对的是包括故障在内的完整使用过程，两类原因都需要保留。

关系感的研究还应有伦理边界。

不能通过制造内疚、暗示离开会伤害机器人来追求更长互动。

笔者更愿意把能否自然结束一次互动、能否理解机器人能力、能否在需要时得到回应，作为体验检查项。

具体指标和通过条件，应在试验前按风险与业务问题确定，同时说明哪些结果会否定当前假设。

4. 工程门禁与商业门禁，各自回答不同的问题

为了让投入有边界，可以把验证分成四类证据。

下表是笔者对本类项目的工作建议，不是所有机器人都应照搬的统一流程，也不代表相关测试已经完成。

证据类型	主要回答的问题	不能代替什么
概念理解与购买理由	对象是否理解价值，为什么愿意或不愿意选择	不能代替实际使用和支付
真实场景体验	在限定时间与环境内，价值、负担与恢复怎样发生	不能代替规模市场与长期安全结论
工程与制造验证	确定版本是否满足要求，能否稳定生产、追溯和维护	不能代替需求与盈利判断
商业与现金流验证	实际价格、渠道、成本和回款能否支撑经营	不能替不安全的硬件放行

例如，概念偏好很高，电源和运动保护仍有未关闭问题，就不能用用户喜欢来批准上电或家庭试用。

反过来，样机能够稳定完成定义动作，也不能据此宣布消费者愿意支付足够价格。

两种验证都重要，但它们处理的是不同的不确定性，不能互相借用结论。

投入顺序也应随最大缺口变化。

如果目标用户都说不清，可以继续做价值研究；

如果价值理由已经具体，关键瓶颈转成某个动作能否可靠实现，就应集中做对应的最小工程验证。

每次投入都要说明它会支持哪一种决策：继续、修改、暂停或停止，并为不利结果预留处理路径。

预算尚未确定时，也能把工作包继续拆清楚。

需要哪些专业、依赖哪些输入、产出什么证据、什么条件下不能继续，这些内容都可以先研究。

• 无法报出可信总价，不妨碍说明报价所需的条件；

• 没有条件却给出精确金额，反而会把后续执行绑在一个缺乏依据的数字上。

图5｜下一笔投入，应换回支持继续、修改或停止的证据

5. 小团队需要的是责任闭合，不是照搬组织规模

执行层面，产品、结构、电子、控制、服务软件、质量、供应与售后之间需要有人完成交接。

一个人可以承担多个角色，但某项责任不能因为团队小就自动消失。

比如谁确认执行器替代后的影响，谁维护版本与测试记录，谁把返修现象反馈到设计，应该在任务开始前说清楚。

交接内容也要足够具体。

• 把「结构已经完成」改成明确的装配版本、材料与待验证事项；

• 把「软件已经跑通」改成对应硬件、固件、策略和测试条件；

• 把「成本没问题」改成带数量、税运、付款条件和有效期的报价。

这样的信息才能让下一位接手者知道哪些可以依赖，哪些仍须验证。

AI在这条链路中可以承担资料检索、版本比对、断言整理、测试草案和记录检查等工作。

对MicroDuck这类公开资源较丰富的对象，这些工作有明确的输入与输出。

至于具体节省了多少时间，需要有前后数据才能评价，不能因为产出了文档就宣布研发效率提升。

笔者坚持的边界是：AI生成的描述，必须回到来源或实物上核对；涉及电源、执行器与安全动作的判断，仍要由有责任的人结合测试确认。

一项AI建议要进入采购或生产，仍须经过对应的来源核验和责任确认。

回到开头的问题，这只机器鸭为什么值得持续研究？

笔者看重的是它把身体动作、训练工具和产品表达联系在了一起，让关于AI硬件的讨论有了具体对象。

但准备做自己的消费陪伴产品，仍要独立回答用户价值、工程可靠与经营承诺的问题。

归根结底，产品负责人要负责的是下一次投入能换来什么证据。

先找到值得反复发生的体验，再确定承载它的身体；

把交付责任与资金需求算清楚，再决定投入到哪一步。

机器鸭能够迈出第一步之后，团队更需要知道自己为什么继续往前走。

作者简介

卫朋，《硬件产品经理》作者，人人都是产品经理受邀专栏作家，CSDN认证博客专家、嵌入式领域优质创作者，阿里云开发者社区专家博主。