第1章 机器人原型说明的价值

1.1 为什么需要原型说明?

在机器人产品开发中,一个清晰、结构化的原型说明是连接产品经理、研发、测试和验收的关键纽带。它不仅仅是一份文档,更是团队共同的语言和约定。本章围绕“用户场景→业务问题→用户访谈→需求拆解→方案表达→指标验证→验收标准→交付物模板”的课程主线,阐明原型说明在四个核心维度上的不可替代价值。

📌 核心观点:原型说明不是“写出来”的,而是“协作出来”的。它的价值只有在被团队真实使用时才能体现。

1.2 用户场景:谁在用原型说明?

角色典型场景使用原型说明的目的
产品经理向研发阐述机器人功能逻辑确保需求被正确理解
硬件工程师确认传感器布局与机械结构对齐物理实现边界
嵌入式开发定义控制接口与通信协议明确状态机与数据流
测试工程师设计功能与可靠性测试用例获得可量化的测试基准
项目验收方检查交付物是否满足合同要求提供客观的验收依据

1.3 业务问题:没有原型说明的混乱

  • 需求歧义:口头沟通导致“我以为”和“你以为”不一致,研发返工率高达40%+。
  • 测试无基准:测试人员凭经验判断“正确行为”,同一功能在不同版本中出现冲突判定。
  • 验收扯皮:客户或内部评审时无法证明“完成了什么”,陷入无休止的修正循环。
  • 知识流失:人员变动后,新成员需要重新探索整个机器人逻辑,成本高昂。

1.4 用户访谈聚焦:原型说明的四大价值

通过对20+机器人项目的产品经理、研发和测试负责人进行访谈,我们归纳出原型说明必须解决的四个核心价值:产品协同、研发对齐、测试基准、验收依据。它们构成了原型说明的“价值四象限”。

机器人原型说明四大价值 原型说明 产品协同 场景访谈·需求拆解 研发对齐 方案表达·接口定义 测试基准 指标验证·用例生成 验收依据 交付清单·标准检查 四大价值驱动

1.5 价值详解:从问题到方案

价值一:产品协同

解决的问题:产品、设计、市场、项目管理等多角色对机器人功能理解的碎片化。

用户访谈案例:扫地机器人项目初期,产品经理口头描述“沿墙清扫”逻辑,结构工程师设计了错误的轮子布局,导致样机无法贴墙。痛点过后,团队开始编写原型说明,明确“沿墙距离阈值5cm,触发姿态调整”。

如何实现:通过结构化场景描述(用户场景卡)和业务问题拆解表,将每个需求与真实使用场景绑定。

价值二:研发对齐

解决的问题:硬件、嵌入式、算法、云端开发各自采用不同的接口约定,集成时频繁冲突。

需求拆解示例:机器人避障模块的原型说明中需定义:

输入:激光雷达点云(频率10Hz,范围0.2-12m)
输出:避障转向角度(-30°~+30°,精度1°)
触发条件:前方障碍物距离 < 0.5m
状态机:IDLE → AVOIDING → RECOVER → IDLE

方案表达工具:状态机图、接口定义表、时序图。

价值三:测试基准

解决的问题:测试人员无法判断机器人行为是否正确,因为缺乏明确的“预期结果”。

指标验证例子:原型说明中必须包含可量化的验收指标,如:

指标名称:紧急制动响应时间
目标值:≤ 200ms
测量条件:机器人以0.8m/s直行,前方1m处放置障碍物
通过标准:连续10次测试,成功率100%

测试基准交付物:测试用例模板、指标清单。

价值四:验收依据

解决的问题:项目结项时,客户或管理层不清楚“到底完成了哪些功能”,导致反复修改。

验收标准模板:

功能模块:自主充电
验收项:
  1. 机器人剩余电量低于20%时,自动导航至充电座
  2. 对接成功指示灯亮起(LED绿色)
  3. 充电电流 ≥ 2A
  4. 充电完成自动退出并继续任务
检查人:______  日期:______  结果:☐ 通过 ☐ 不通过

💡 关键交付物模板:原型说明文档应包含:
① 版本与变更记录|② 用户场景列表|③ 需求拆解表(功能/非功能)|④ 方案表达图(状态机、接口表)|⑤ 指标验证矩阵|⑥ 验收检查清单。

1.6 本章小结