目录

先把「我也能做成」交到用户手里

MicroDuck 把参与放在了收货之前

热闹起来以后，谁承担成本，谁收到钱

从下一道具体的障碍开始

作者简介

---

看到一只会蹦跳的小机器人，你可能很快就能列出需要哪些组件才能做出来了：比如，需要电机、控制板、结构件，再加上训练和控制软件。

看到一个能聊天的小设备，你也知道大致怎么实现：拾音、联网、语音识别、调用模型、播放回答。

然后一个有些令人不舒服的问题就出现了：

这些东西自己似乎也能做，为什么还是不知道该做什么？

如果继续沿着技术清单往下找，答案可能是再加一个摄像头，换一块算力更强的板子，或者接入一个更好的模型。

功能越来越齐全，最开始的问题却还在那里：

谁会想要它，为什么愿意拿走，又为什么愿意付钱？

小智 AI 和 MicroDuck 恰好提供了两个不同的观察入口。

一个让人从开发板走到能对话的设备，一个让人围绕机器人的动作进行尝试。

图1：技术清单与商业机会之间的认知断层

列零件不难，列不出"谁会要、为什么付钱"这个等式

先把「我也能做成」交到用户手里

先看小智，它的公开仓库支持多种开发板，也提供使用预编译固件的体验方式。

一条上手路径是：烧录固件，配置 Wi-Fi，在小智平台添加并绑定设备，随后唤醒对话。

项目说明和设备教程把这些步骤连接在了一起。

一条能照着走通的路径，缩短了「我有点兴趣」和「它已经能回答我」之间的距离。

对于想亲手做出一个小东西的人，设备开口的那一刻，本身就有价值。

他拿到的不只是一个能聊天的物件，还完成了一件原先不知道从哪儿入手的事。

这里容易出现一个误判：用成品用户的眼光，评价制作型用户的获得感。

如果你想买一个省心的语音设备，刷固件、配网络、绑定账号，都可能是应该被厂家消化掉的麻烦。

但如果你原本就想学着做一个 AI 小硬件，能理解并完成这些步骤，可能正是你愿意花时间的原因。

你甚至会想给它换个外壳、改一下声音，再向别人解释它是怎么工作的。

同样一块板子，对这两类人意味着不同的任务。

图2：用成品用户的眼光评价制作型用户的获得感，是这类项目最常见的误判

前者要的是拿来就能用，后者希望自己也能做出来。

把两类人混在一起，就很难解释为什么有人愿意折腾，也很难决定自己的产品究竟应该保留哪些可玩空间、替用户省掉哪些操作。

「便宜」也要放在具体任务里看。

对于想完成一个练习项目的人，除了物料价格，他还要付出找教程、判断版本、排查错误的时间。

一套多花一点钱、但零件匹配且步骤清楚的方案，可能更值得选择。

换成只想日常聊天的人，这些过程价值就未必成立：他可以拿它与手机上的语音应用比较，问自己为什么还需要单独摆一个设备。

比较对象变了，价格的含义也会变。

你不能只用「同样的芯片别人卖多少钱」理解购买决定，还要知道用户准备用它替代什么，或者完成什么。

MicroDuck 把参与放在了收货之前

MicroDuck 有趣的地方，是它进一步把「参与」与「拥有硬件」拆开了。

先把时间说清楚。

Pollen Robotics 在 2026 年 8 月 27 日发布 MicroDuck，官方页面给出的预售介绍价是 399 美元，未含税和运费，首批交付计划指向当年圣诞节前。

截至本文写作时的 9 月 6 日，它仍然是一个需要观察后续交付的项目。

但收货之前，人已经可以开始做一些事。

官方开放了 SDK、训练相关工具和浏览器仿真入口。

浏览器端运行物理模拟与已有动作策略的推理，让人先观察机器人怎样运动。

需要特别区分：

在网页里试运行一个策略，不等于在网页里完成新策略的训练。

后者还有另外的工具和计算过程，不能把两种门槛都写成「打开网页就解决了」。

这个安排给不同深度的参与留下了位置。

感兴趣的人可以先看看动作效果；愿意动手的人可以研究已有策略；

再往前走，才是训练、修改，以及拿到真实硬件后的部署和调试。

并非每个人都要走完整条路，前一步的尝试也不必以购买为前提。

一只双足小机器人，恰好能让这种尝试有一个可见的结果。

你不需要先读懂全部代码，也能看出它是在向前跑、原地跳，还是落地时没有站稳。

动作有完成与失败，有幅度和节奏，容易形成下一次修改的具体目标。

浏览器入口还有一个具体特点：

物理模拟和已有策略的推理都在本地运行，不需要为这部分体验请求后台推理服务。

这样，尚未购买硬件的人也有了一种尝试渠道。

不过，这只能说明该体验入口的计算方式，不能扩大解释为机器人训练、网站维护和后续服务都没有成本。

它的鸭子外形，也给人留出了不同于通用助手的观看方式。

看动作时，人可以关心它跳得是否轻巧、走得是否有趣，不必每次都先验证它能回答多少问题。

这是产品表达上的一种选择。

它能否进一步形成日常陪伴价值，仍然需要另一些证据。

一个具体的模型记录，能让这种参与方式变得更清楚。

Happy Hop 的模型卡记录，这个跳跃策略在 2026 年 9 月 1 日经过了 Pollen Robotics 的实机测试。

记录里还有一个很小的技术细节：

首次接入时，遗漏了训练环境中的一个控制周期，也就是 20 毫秒的动作延迟，实际跳跃幅度受到影响；恢复这一设置之后，动作表现得到改善。

比起一句「仿真成功迁移到现实」，这段记录更有信息。

它告诉后来的尝试者，训练出来的动作到了真实机器上，还要检查哪些条件有没有对齐。

跳得怎么样是一部分结果，哪里出了问题、怎样调回来，也是别人可以接着使用的内容。

这样，围绕同一个硬件，能够被分享的东西就增加了。

除了开箱和成品演示，还可以有一个动作策略、一次失败记录、一项修改方法。一个人完成的工作，可能成为另一个人继续尝试的起点。

这种接续还依赖一个条件：

大家使用的模型、接口和测试方法要有足够的共同部分。

如果每个人都换了结构、控制方式也各不相同，一个人的结果就很难被另一个人直接拿去验证。

共用一个机器人平台的意义，也在于让交流能具体到同一个动作、同一种错误，而不必每次先解释一遍自己的整套系统。

从这里可以理解开放工具为什么可能帮助传播：

参与者有机会拿出属于自己的结果，而不只是重复厂商的一段视频。这个结果也可以成为他向别人介绍项目的理由。

至于具体带来多少订单、多少人会持续贡献，需要真实数据来回答，不能从工具开放本身推导出来。

所以，评价 MicroDuck 至少要把几件事分开看。

一个动作能在实机完成，说明这次技术尝试有了结果；有人愿意训练和分享，说明它对一部分开发者有吸引力；

普通人收到后是否经常打开，是否愿意长期摆在家里，则涉及另外的使用任务。

这几件事可以相互促进，却不能相互代替。

尤其在预售阶段，把开发者的参与热情直接当成家庭用户的使用意愿，很容易过早决定产品接下来该往哪里投入。

热闹起来以后，谁承担成本，谁收到钱

沿着用户的参与往下看，迟早要遇到收入问题。

围绕一个开放项目，不同的人可以从同一件事里获得不同回报。

开发者可能在意自己的代码被使用，内容创作者可能在意有东西可讲，硬件销售方需要订单，做课程的人则需要一套能被学生完成的练习。

合作有机会发生，正因为大家不必拿到完全相同的东西。

但这也意味着，项目热闹了，并不能自动回答你能赚到什么。

小智公开固件采用 MIT 协议。

对准备做相关产品的人，公开代码能成为出发点；

而自己的销售理由，还要在具体交付中寻找。

软件入口被更多人使用，与某一位硬件销售者获得收入，是两件需要分别观察的事。

假设你把一套开发板、外壳和教程组合成商品，卖点是「照着步骤就能做出会聊天的设备」。

当另一位销售者也能提供相近组合时，用户就可能开始比较价格、做工、教程和售后。

公开方案替你省去了部分开发工作，也可能让别人的起点靠近你。

图3：估算硬件收益时常被遗漏的 5 项成本，承诺越具体、漏掉越多

这时继续强调「我接入了大模型」，能提供多少区别，就要重新判断。

你或许需要把承诺具体到：

发出去之前有没有逐台测试，教程是否与当前固件对应，第一次连接失败时能否定位原因，换了网络后用户知不知道怎么恢复。

这些工作没有新功能演示那么醒目，却与用户能不能顺利完成任务直接相关。愿意为它付费的是谁，也会更清楚：有的人就想自己排查问题，有的人只希望你替他处理好。

产品可以面向其中一种，但不能同时假定所有人都追求低价、又都愿意为省心买单。

再看一层成本。

硬件可以一次性收费，联网对话却可能涉及持续的模型、语音和服务支出。免费额度或者现成平台能降低开始尝试的负担，至于正式对外销售后的服务由谁提供、能提供多久，仍然需要有明确安排。

如果购买者理解的是「买回来就能一直用」，销售者心里想的却是「当前服务能接通」，双方对交付内容的认识就没有对齐。

问题不一定在第一次开机时出现，也可能在服务调整、账号变化、使用量增加之后才显现。

因此，估算一件硬件的收益，不能只看售价减去物料。

还要根据自己的方案，把装配测试、物流损耗、退换货、支持工时和持续服务等相关成本放进去。

这里并不是在判断小智或 MicroDuck 的实际利润，而是在检查：当你借用这些项目做一门生意时，承诺由谁兑现。

一次手把手带着用户配置成功，可以证明方案有机会跑通。如果每卖一台，都需要同样长时间的陪同，你还得决定这段服务该如何收费、哪些问题能提前消掉，以及现有团队能承接多少。

支持记录也可以反过来帮助产品选择。几位用户都在同一个步骤遇到麻烦，或许值得做成检查工具；每次都要适配完全不同的设备，就可能需要限制支持范围。暂时不接某一种需求，有时是在保护已经答应其他用户的交付。

不把这些算进去，所谓「有订单」可能只说明有人愿意买，还没有说明你能稳定地交付。产品承诺缩小一点，有时比继续加功能更有帮助：先把一类人的一件事做好，才容易弄清自己究竟在为什么工作收钱。

从下一道具体的障碍开始

技术已经可以实现，下一步到底做什么？

可以试着沿着现成方案，往它还没有解决好的地方走一小步。

假设你考虑做一套给老师使用的 AI 硬件课程产品。

小智已经提供了可利用的技术基础，但「一块板子能说话」和「老师能带着一个班完成一节课」之间，还有不少具体工作。

沿着这个假设继续推演：

• 三十块开发板同时拿进教室，老师要提前多久准备？

• 学校的网络能不能按教程接入？

• 学生操作到不同步骤时，老师怎样发现谁卡住了？

• 一台设备没有声音，能不能迅速判断是硬件、网络还是账号问题？

• 课程结束以后，这些设备由谁保管，下次使用要不要重新配置？

还有教学本身。

• 学生完成了什么，老师用什么办法判断他们理解了？

• 如果课堂只是轮流向设备提问，硬件是否真的有必要？

• 涉及语音采集时，学校和家长可能会提出怎样的说明要求？

• 这些问题不会因为设备成功回答了第一句话就自动消失。

到这里，产品才开始从「又一个能聊天的小硬件」变得具体。

你可能需要一份课前检查表、一套统一配置的工具、可以快速替换的备件、适合课堂节奏的任务说明。

最后交付的组合，取决于老师卡在哪里，而不取决于你最想展示哪项技术。

这个例子也有一个前提：

得先确认老师真的想完成这类课程，而且当前做法确实带来了困扰。

我们不能先想象出一串困难，再把它们当成已经存在的购买需求。

比较合适的起点，是找少量符合条件的人，看看他们正在怎样完成这件事。

比如先找十位目标用户，这个数字只是帮助控制试验规模，并没有统计意义上的保证。

与其问「给你一个 AI 硬件，你觉得怎么样」，不如让对方拿出正在用的课程材料，说明上一次在哪里花了时间、哪个步骤没有完成。

「老师」这个范围还可以继续缩小。

带社团活动的人，与需要按固定课时完成教学的人，准备时间和采购方式可能都不同。第一轮最好围绕相近的任务找人，否则十份反馈各自指向不同的产品，很难据此决定先改哪一处。

如果对方根本没有开展相关课程的打算，这条反馈也有用。它提醒你先检查用户选择和任务本身，而不是立即把方案做得更复杂，希望对方看见更多功能后就改变想法。

对确实存在的困难，再做一个尽量小的交付。它可以暂时使用现成开发板和普通外壳，重点是让对方完成选定的任务。首次试用时，把你介入的地方记下来：哪一步需要解释，哪个错误需要你处理，哪些操作可以由对方独立完成。

第二次使用尤其值得观察。

你不在旁边，对方还能不能继续？

如果不能，卡住的是遗忘步骤、环境变化，还是他已经没有再次使用的理由？前两种可能通过产品改进解决，最后一种则要求重新看任务发生的频率与必要性。

付费也需要单独验证。

愿意听演示、愿意免费试用、愿意支付明确费用，代表不同程度的投入。

可以把交付范围、支持方式和价格说明白，看看对方愿意为哪部分购买；也要允许对方拒绝，并弄清拒绝针对的是价格、时机，还是这件事本来就不重要。

接下来再把反馈分开处理。

有兴趣却不想试，先检查行动负担；

试过却不愿付钱，核对价值和替代方案；付过钱却不再用，回到持续任务；

愿意继续用，但每次都需要你大量支持，就检查交付方式和成本。

不同结果决定不同的下一步，不必一律回答成「再把产品打磨一下」。

作者简介

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