机器人产品设计怎么做？场景驱动的五步功能定义法

我见过不少做机器人的团队，一上手就开始画外观图、选底盘、写导航算法，忙了几个月才发现连最基础的场景都没搞清楚。机器人产品设计和普通智能硬件不一样的地方就在这：你得先想明白“它要在什么样的环境里、替什么人、完成什么任务”，否则后面做出来的功能定义全是空中楼阁。这篇文章我想分享一套我自己反复用过的流程——从场景到功能定义的5个步骤，核心解决“机器人产品设计怎么做”这个问题。无论你是想给公司立项的负责人，还是刚转来做机器人产品经理，或者纯粹是想知道机器人产品是怎么被定义出来的工程师，这套方法都能直接拿来用。

1. 为什么机器人产品的成败，往往在画原型图之前就定了

1.1 机器人产品不是“APP加轮子”

很多人觉得机器人产品就是普通智能硬件加一个可移动底盘，把APP那套产品方法论搬过来就能做。实际做下来你会发现完全不是一回事。

APP产品面对的是屏幕里的确定性逻辑：按钮放在哪里、跳转规则是什么、接口返回什么，这些在发布前都能穷尽测试。而机器人产品面对的是一个物理世界：地面材质不同、光线变化、充电桩对接偏差、轮子打滑、网络抖动、突然有人走过来挡住路。每一个变量都可能让同一个功能在真实场景里表现完全不同。

我做过的一个室内巡检机器人就是典型例子。实验室里导航定位精度能做到±2厘米，一放到写字楼走廊，地毯、大理石、金属踢脚线交替出现，视觉里程计在纯色地毯上疯狂漂移，激光雷达又会被玻璃幕墙干扰，最终实际精度掉到±15厘米。而且这些偏差不是算法团队不努力，是场景本身的复杂性决定的。

所以我现在的习惯是：机器人产品设计的起点不是功能列表，不是硬件选型，而是场景。场景定义清楚，功能定义才有依据；场景定义错了，后续所有工作都是在给一个错误前提打补丁。

1.2 场景定义错，后面全是修补

举一个我踩过的坑。之前给一个商场做迎宾机器人，前期访谈时商场经理说“希望机器人能在门口跟顾客打招呼、做导引”。我们把功能方向定在语音交互、人脸识别、路径引导上，做了大量开发。结果实测时发现几个致命问题：商场门口是落地玻璃，阳光直射时摄像头逆光，人脸识别率掉到60%以下；背景音乐的噪声让人机语音交互完全听不清；地面是大理石，机器人急停时会往前滑出30厘米，差点撞到顾客。

这些问题没有一个是因为技术不过关，全是因为场景约束没提前拆出来。如果当时先花一周时间去商场门口蹲点，记录光照变化、噪声分贝、地面材质、人流密度，我们根本不会把语音交互作为核心功能，至少会加一个“安静时段才启用语音”的限制条件。

场景就是机器人的生存环境。你让一条鱼去爬树，怪鱼不够努力是没有意义的。机器人产品经理最重要的工作，是在定义功能之前先把场景这颗钉子钉牢。

1.3 五步法的整体思路

这套方法是我在几个项目里逐步总结出来的，一共五步：

• 场景拆解：明确人物、环境、任务、边界四个要素，输出场景约束清单。
• 任务链建模：把场景里的用户故事拆成可执行的动作序列，输出任务树。
• 功能定义：从任务链反推机器人必须具备的感知、决策、运动、交互、运维能力，输出功能清单和规格。
• 优先级排序：根据价值、频率、成本、风险四个维度砍掉伪需求，确定MVP范围。
• 场景回归验证：用原型机和真实场景做闭环测试，让功能定义回到现实接受检验。

下面我按顺序把这五步展开讲，每一步都会用一个“写字楼夜间巡检机器人”的案例串起来，方便你理解整套流程怎么落地。

2. 步骤一：场景拆解，先回答“它要在什么样的世界里活着”

2.1 场景四要素：人物、环境、任务、边界

场景拆解不是写一段“在某商场，机器人进行导引”这种描述就完了。我习惯用一个四要素模型把场景拆到“可输入给技术团队”的颗粒度。

人物，指的是和机器人产生交互的所有人，不只是最终用户。做送餐机器人时，你会以为用户是吃饭的顾客，但真正天天操作机器人的是传菜员；做巡检机器人时，你以为用户是保安队长，但实际上每天看后台的是值班员。维护人员、路过行人、甚至熊孩子，都算场景里的人。

环境，包含物理环境和数字环境。物理环境包括地面材质、空间尺寸、光照条件、噪声水平、温度湿度、是否有台阶和斜坡；数字环境包括WiFi覆盖、网络带宽、4G/5G信号、是否有GPS信号、私有协议对接条件。很多机器人项目挂在环境上，不是因为机器人不行，而是因为环境参数根本没被调研过。

任务，就是机器人要完成的具体事务。要把任务分清楚：高频任务是什么、低频任务是什么、紧急任务是什么、绝对不能出错的守护任务是什么。巡检机器人高频任务是沿固定路线巡查，低频任务是临时去指定点位看异常，紧急任务是火警或漏水时优先响应，守护任务是不能撞人。

边界，是“不能做什么”和“做不了的怎么办”。比如轮式机器人上不了楼梯，这是物理边界；安防机器人不能拍摄洗手间等隐私区域，这是合规边界；机器人权限不足，不能远程开关消防门，这是系统边界。边界定义清楚，功能定义才不会被无限放大。

2.2 用“写字楼夜间巡检机器人”做一次完整拆解

下面是我虚构但非常典型的一个案例：给一栋18层的写字楼做夜间巡检机器人，核心目标是辅助夜班保安定时巡检公共区域，发现漏水、烟雾、未关闭的门窗、可疑人员并上报。

按照四要素模型，我是这么拆的：

这一步做完，团队内部对“要做一个什么东西”就有了完全一致的画面感。注意，这个阶段我还完全没有提任何具体功能，但后面每个功能都能从这张表里找到依据。

2.3 场景约束清单：后续所有设计的输入文档

场景拆解完，下一步是把四要素翻译成约束条件。我建议用一张清单把所有约束按类别列出，这张清单就是后续所有设计工作的输入。

还是以巡检机器人为例：

• 移动类约束：轮式底盘不能上楼梯，因此巡检范围限定单层平层，跨楼层必须调用电梯；地毯区域行进阻力大，底盘扭矩需要冗余。
• 感知类约束：凌晨走廊灯光暗，部分区域路灯关闭，因此视觉传感器必须带补光或者用红外；玻璃隔断和镜面会干扰激光雷达，需要融合IMU和轮式里程计。
• 通信类约束：楼梯间WiFi信号弱，机器人进入前要降级为本地缓存模式，出楼梯间后补充上传。
• 安全类约束：夜间可能有加班员工突然走出工位，机器人速度必须限制在0.8米/秒以内，接近转角要减速。
• 运维类约束：凌晨没有现场技术人员，机器人必须能自诊断故障并远程上报，充电桩对接失败时要有自动重试机制。

这些约束写的越具体，后续技术选型就越省力。很多团队在这里偷懒，直接跳到“我们要做一款自主导航机器人”，结果后面选型时发现方案根本落不了地，又回头补调研，相当浪费时间。

3. 步骤二：任务链建模，把“巡检”变成一行行可执行动作

3.1 从用户故事到任务树

场景拆解解决的是“世界是什么样的”，任务链建模解决的是“机器人要一步一步做什么”。

我习惯先把用户故事写出来，再拆成任务树。比如夜班保安的需求可以写成：“凌晨1点，保安希望机器人能替他去看一下7层东侧走廊有没有漏水。”听起来很简单，但机器人要真正完成这件事，背后是一长串动作：

• 从充电桩自主脱离，确认电量充足；
• 沿导航路径行驶到电梯口，申请电梯权限；
• 进入电梯，切换到7层，出电梯后重新定位；
• 沿7层走廊行进至东侧区域；
• 在目标区域原地停留，打开补光灯和云台，朝地面拍摄多角度图像；
• 调用漏水检测模型分析图像，判断是否有积水或渗水；
• 判断为异常后，拍摄现场照片，记录坐标和时间；
• 通过即时通信通道把告警推送到值班室，同时语音提示附近可能存在的加班员工；
• 继续执行下一个巡检点，或根据指令返回充电桩。

这个任务链看起来繁琐，但把它画出来之后，你才知道机器人需要哪些基础能力。

3.2 任务粒度怎么把握

任务链建模最常被问的问题是：拆到多细才算合适？

我的经验是，产品经理的任务粒度应该停留在“可验证价值”的最小动作级别。比如“沿走廊行进到东侧”这个粒度就合适；再往下拆“左轮转速300转/分钟”“PID输出0.5”就过度了，那是机械和算法工程师的活。反过来，“替保安检查漏水”又太粗，无法转化为任何功能设计。

判断粒度是否合适的标准很简单：看到这个任务，你能不能明确说出“机器人需要什么传感器、什么算法、什么执行机构”来支撑它。能说清，粒度就对了；说不清，继续往下拆；拆到机械层面还在纠结，说明你越界了，停下来。

3.3 把任务链转成能力需求

任务树建完后，我通常会做一张“任务—能力”映射表，把任务链里每个动作对应的机器人能力列出来。这是从场景侧迈向功能侧的关键一跳。

以刚才的巡检任务为例：

看到这张表，你应该能感受到：场景驱动和功能驱动最大的区别，是场景驱动能让你发现很多“隐藏功能”。如果只从功能出发，你大概率会列“导航、避障、拍照”，但不会想到“电梯对话”和“回充失败重试”——这些恰恰是实际运行中最耗时间的部分。

4. 步骤三：功能定义，从能力需求生成功能清单

4.1 功能模块的五大类

有了能力需求表，功能定义就水到渠成了。我习惯把机器人的功能分成五大类，每一类都从能力需求里自然生长出来：

• 感知类：机器人和环境之间的信息通路。包括激光雷达、超声波、视觉、红外、防跌落、碰撞检测、里程计、陀螺仪等传感器的数据采集与融合。
• 决策类：机器人的“大脑”。包括任务调度、路径规划、异常决策、重试策略、地图管理、业务逻辑判断。
• 运动类：机器人在物理世界里的执行能力。包括底盘驱动、转向、速度控制、精确停位、云台控制、机械臂动作。
• 交互类：机器人和人及其他系统的接口。包括远程告警、移动端查看、语音提示、按钮显示、API对接。
• 运维类：让机器人能长期活下去的能力。包括自检、诊断日志、远程升级、低电量管理、自动回充、卡死救援、断网恢复。

很多团队做功能清单只覆盖前四类，把运维类完全漏掉，导致产品交付后运维成本高到离谱。我见过一个项目，机器人平均每三天卡一次，每次都要工程师到现场手动搬回充电桩，运维团队都快疯了。运维类功能从一开始就要进入功能清单，不能等出问题了再补。

4.2 用能力需求反推功能项

能力需求到功能项，是一对多的关系。比如“室内定位”这项能力，在功能清单里会展开成：

• 地图构建与加载：支持至少5张楼层地图的存储与切换；
• 全局定位：开机后2分钟内完成初始定位；
• 实时位姿跟踪：运行中定位频率不低于20Hz；
• 丢失后的重定位：失锁后30秒内自动恢复或上报；
• 定位置信度输出：关键决策点必须输出置信度，低置信度时降速并重定位。

“自动回充”这一项能力，同样会展开成几个可验证的功能项：

• 电量阈值设置：默认设置为30%，可在后台调整；
• 回充路径规划：电量到达阈值后自动规划回充路线；
• 对接机制：充电极片物理对接、弹簧补偿、允许误差范围；
• 回充失败处理：对接失败后自动后退重试，最多5次，仍失败则原地驻留并告警；
• 再次上线：充满电后根据任务表决定继续巡检还是待命。

这样反推出来的功能清单，每一项都能追溯到具体的场景任务。以后如果有人问“这个功能为什么存在”，你随时能说出它服务的是什么场景。

4.3 功能规格不是写作文，是可测试的句子

功能定义阶段最忌讳的就是写含糊的需求，比如“机器人可以自动导航”“机器人应该识别异常”。这种写法等于没写，因为验收时根本说不清什么情况下算通过。

我要求团队里所有功能规格必须写成可测试的句子。一个好规格应该包含四样东西：触发条件、具体行为、量化指标、异常处理。

举个对比：

差：“机器人可以自动导航到达指定位置。”

好：“当后台下发巡检任务时，机器人在已加载地图区域应从当前位置自主规划路径至目标点，定位精度±5厘米，单次规划成功率不低于99%；若连续3次规划失败，则原地驻留并通过后台推送告警。”

这类规格写多了以后，你会发现它同时帮助了三个角色：

• 开发知道该实现到什么程度，不会“自由发挥”；
• 测试知道怎么验收，不会凭感觉打勾；
• 管理层知道产品当前真实水平在哪，不会被演示PPT误导。

我习惯给每条功能规格都加一个编号，比如F-NAV-01、F-DOCK-02，这样后续测试、返修、变更管理都会方便很多。这不算什么高科技技巧，但在项目沟通里极其好用。

5. 步骤四：优先级排序，把“想要”和“必需”分开

5.1 排序的四个维度

功能清单出来后一定是超量的，三个月做不完，所以必须排序。我用的排序维度有四个，简单直接：

• 价值：这个功能对核心场景的解决程度有多高。高价值是指没有它，核心任务根本无法完成。
• 频率：在典型使用周期里出现多少次。高频率功能值得优先优化，低频功能可以先用简化方案。
• 成本：实现它需要的综合成本，包括人力、硬件、算法难度、时间。
• 风险：技术风险和安全风险。有安全风险或者技术无人验证过的功能，要格外谨慎。

每个功能在这四个维度上打分，然后落进一个优先级矩阵。矩阵的结果通常分为三档：P0（不做没法交付）、P1（做了体验完整，可以第二版再上）、P2（锦上添花，没做也不影响核心价值）。

5.2 用优先级矩阵砍掉伪需求

回到巡检机器人案例，我列几个当时讨论比较久的功能，你看看怎么排序：

人脸识别为什么被砍到P2？不是技术上做不出来，而是这个场景里“遇到人的概率”本来就低，而且夜间安防涉及隐私合规风险，一旦出问题影响面极大。语音播报看起来不酷，但夜班保安说“突然背后冒出一台机器还挺吓人的”，于是我们保留了一个简单的语音提示功能，成本很低，体验提升明显。这就是场景驱动带来的判断力。

5.3 MVP怎么定，预埋怎么留

优先级排完后，MVP的定义就清晰了。巡检机器人的MVP并不是“能跑起来看点画面”，而是真正打通一个最小完整闭环：自动上线、按路线巡检、发现异常并上报、低电量自动回充。这四个环节全部走通，才算一个“能用”的机器人。

在定MVP时，我还要做一件重要的事：预留扩展能力。这里说的预留不是功能开发，而是在硬件、结构、接口上留位置。比如：

• 现在MVP不需要5G模块，但主板上要预留通信接口和天线位置；
• 现在不打算做机械臂，但底盘强度、载重余量要按将来加装机械臂来设计；
• 现在只要单线激光雷达，但结构上要预留顶部多线雷达的安装平面和线束通道。

为什么强调预埋？因为改结构比加功能贵得多。功能可以后续通过OTA升级，但结构上的洞、算力上的缺口、电源上的余量，是产品定义阶段就定死的。我见过太多项目，第二版想加一个轻量机械臂，结果发现底盘电池仓小了、控制器算力不够、结构承重不达标，等于重新做了一遍产品。这些问题的根源都在第一版定义时没有把“可生长性”放进优先级排序的考量。

6. 步骤五：场景回归验证，让功能定义回到现实

6.1 用最小代价验证高风险功能点

功能定义做得再漂亮，最终都要在真实场景里过一遍。但我不建议等整机做完了再去现场测试，那时候发现问题，返工成本太高。我习惯在功能定义阶段就挑出“高风险高不确定”的功能点，提前做单项验证。

什么是高风险高不确定？以巡检机器人为例：电梯对接、回充对接、低光照下的视觉检测、不同地面材质下的定位稳定性、断网续传。这些功能都是典型的“实验室环境表现好、真实场景翻车”重灾区。

验证方法其实不需要太豪华。我常用的方式是找一套现成的开源底盘和工控机，装上现成的开源导航框架，把传感器布局和运行速度按目标规格配置，然后直接在目标场景里跑一天，记录关键指标。这个阶段的目标不是让功能达标，而是验证“技术路线本身成不成立”。如果现成方案跑下来定位精度完全不可接受，那就要及早调整传感器方案或算法路线，而不是在自有代码上硬啃三个月再发现路线错了。

6.2 回到真实场景做闭环测试

当单点验证通过、原型机拼出来之后，一定要回到真实场景做闭环测试。实验室里再完美的测试方案，也替代不了真实环境的随机性。

这里我有一条铁律：至少连续运行7天，每天24小时跑真实任务，并且测试日期要覆盖工作日和周末。为什么？因为工作日的电梯使用频率、走廊人员密度、灯光状态和周末完全不同。我们之前有一版机器人，平时表现稳定，但一到周末保洁用拖地机洗地，走廊地面反光率突然提升，机器人的视觉辅助定位连续四天在同一个位置迷路。这种问题只有真实场景、真实时间跨度才暴露得出来。

闭环测试时重点记录三类数据：

• 任务完成率：下发10次巡检任务，成功完整跑完几次，失败在哪一步；
• 异常分布：把每次异常按类别统计，看是不是集中在某个传感器或某个行为；
• 人工干预次数：从上线到充电全流程里，需要人介入的次数和原因。

人工干预次数尤其重要。哪怕干预的原因只是“机器人卡住拖了一下轮子”，也算产品不合格。真正的产品级机器人，应该能让非技术背景的保安轻松处理99%的日常状况。

6.3 功能定义文档随验证迭代

实测定会打脸，所以功能定义文档不是写完就锁死的，它需要随验证结果迭代。但迭代过程里有一个容易犯的错：动不动就推翻功能，而不是调整验收条件。

举个例子。我们最初定义回充对接允许误差是±3毫米，实测发现底盘到充电桩附近时，由于地面轻微不平整，反复对接成功率只有60%。这时候有两种处理方式：一种是要求自己继续死磕定位精度，另一种是做结构上的改进，把充电接口改成“漏斗式”引导结构，允许±1.5厘米的对接偏差。我们选了后者，结果一次对接成功率提到了95%，效果立竿见影。最后功能定义文档里，“对接允许误差”从±3毫米调整成了±1.5厘米，“漏斗式引导结构”成为一条明确的设计约束。

功能定义迭代时，我建议用版本号管理文档，每次修改注明变更原因和验证数据。这样整个团队都能看到“为什么定义变了”，而不是稀里糊涂地跟着改。等产品量产后，这份文档会成为最有价值的资产之一，因为它记录了一台机器人是怎么一步步从理想设计被真实场景磨出来的。

7. 几个项目趟完之后，我对机器人产品设计的几条执念

前面五步讲完了，最后聊几条我在实际项目里被反复教育过的经验，不一定只适用于机器人产品经理，做硬件和做系统的朋友应该也有共鸣。

第一，需求调研要蹲点，别只看PPT。访谈对象往往只会说“希望机器人能更智能”，但真实场景里藏着大量反常识的信息。你得自己去数人流量、测噪声分贝、拍地面材质、记录一天里灯光变化、试着走一遍网络死角，这些数据比任何访谈记录都有说服力。我第一次做巡检机器人时，就是蹲了一晚上保安室，才发现交接班的高峰期根本没人看手机告警，于是我们把告警方式从“APP推送”硬生生改成了“室内语音广播加闪灯”。

第二，“演示能跑”和“量产稳定”之间隔着一个太平洋。原型demo跑通，大概只占整个项目30%的工作量。剩下70%都是在解决可靠性和工程化问题：电池衰减怎么监测、连接器松动怎么预警、粉尘和潮气怎么防护、长时间运行后传感器漂移怎么校正、静电怎么防。这些问题任何一个都能让一台机器人从“次日上线”变成“三天一小修五天一大修”。

第三，给运维和异常场景留够功能余量。机器人真正的使用者，其实是运维团队。远程诊断、日志回传、硬件自检、安全急停、卡死救援，这些功能必须在第一版就定义，否则产品交付后你会被现场电话打爆。异常场景也一样。机器人被椅子腿卡住、轮子悬空、断网、电量耗尽还没回到充电桩、半夜被人推了一下——这些事发生的概率远比你想象的高。

第四，场景库是团队最值钱的资产。每做完一个项目，把场景拆解表、约束清单、功能定义文档、验证数据全部归档，这比代码和硬件图纸更能决定团队的天花板。下一次做类似方向的机器人，第一天就能调出完整的基础资料，整个团队的起步速度会非常不一样。

说回最开始那个问题，“机器人产品设计怎么做”？我的答案就是先把“它要在什么样的世界里活着”这十几个字写清楚，然后用场景拆解、任务链建模、功能定义、优先级排序、场景回归验证这五个步骤把它夯实。这条路不性感，但走过的人都知道，它比任何捷径都靠谱。