第二章 系统需求分析：功能需求、性能指标、成本约束、开发周期规划
做扫地机器人，最怕什么？
怕做到一半发现电池装不下，怕量产时发现成本超了30%，更怕用户买回去说「这玩意儿连门槛都过不去」。
所以，在动任何一个元器件之前，先把需求掰扯清楚。我个人的习惯是，花两周时间专门做需求分析。别嫌慢，这步省下来的时间，后面十倍百倍地还给你。
2.1 功能需求：用户到底要什么？
先别急着列参数。咱们得想清楚：用户买扫地机器人，核心诉求是什么？
说白了就三件事：扫得干净、跑得明白、别给我添乱。
2.1.1 核心清洁功能
- 吸尘：边刷把垃圾聚拢，主刷（滚刷）卷起来，风机吸进去。这是基本功。
- 拖地：现在没拖地功能都不好意思叫扫地机器人。水箱、拖布、下压力，这三样得配合好。
- 自动集尘：基站里配个大尘袋，机器人自己回去倒垃圾。嗯，这个功能一旦用上就回不去了。
我的经验： 早期做第一代产品时，我们只做了吸尘。结果用户反馈说「地上有水渍就废了」。后来加了拖地模块，但水箱容量没算好，拖到一半没水了……这种坑，踩一次就够了。
2.1.2 导航与避障
- 建图：激光雷达（LDS）还是视觉？LDS精度高，但怕遮挡；视觉成本低，但暗光下容易翻车。
- 路径规划：弓字形清扫是标配。但遇到复杂户型，能不能自动分区？能不能识别地毯？
- 避障：拖鞋、电线、宠物粪便……我见过最离谱的案例，是机器人把狗屎抹匀了整个客厅。避障算法不到位，就是灾难。
2.1.3 交互与智能
- App控制：远程启动、定时清扫、区域禁扫。这些是标配。
- 语音控制：接入小爱、天猫精灵？还是自己做语音？
- 自动回充：电量低于20%自动找充电座。这个功能看似简单，但充电座摆放位置不对，机器人可能绕半小时都回不去。
2.2 性能指标：用数字说话
功能需求是「做什么」，性能指标是「做到什么程度」。没有量化指标，研发和测试就会扯皮。
| 指标项 | 入门级 | 中端 | 旗舰 |
|---|---|---|---|
| 吸力（Pa） | 2000-3000 | 4000-5000 | 6000+ |
| 电池容量（mAh） | 2600 | 3200-4000 | 5000+ |
| 续航（min） | 60-80 | 100-120 | 150+ |
| 噪音（dB） | ≤65 | ≤60 | ≤55 |
| 越障高度（mm） | 15 | 20 | 25 |
| 尘盒容量（ml） | 300 | 400 | 500+ |
注意： 吸力不是越大越好。6000Pa的吸力，噪音和功耗都会爆炸。我曾经见过一个团队，为了追求参数好看，把吸力做到8000Pa，结果用户投诉说「像开飞机」。平衡，永远是工程的核心。
2.2.1 关键性能取舍
- 吸力 vs 噪音：吸力每提升1000Pa，噪音大约增加3-5dB。你想想看，用户晚上回家想开个静音模式，结果吸力不够扫不干净，是不是很尴尬？
- 电池 vs 体积：电池越大续航越长，但机身厚度也会增加。现在用户都想要「能钻进沙发底」的薄机型，这就逼着你用更高能量密度的电芯。
- 成本 vs 寿命：用有刷电机还是无刷电机？有刷便宜但寿命短（约500小时），无刷贵但能跑2000小时以上。做入门机可以选有刷，但旗舰机必须上无刷。
2.3 成本约束：每一分钱都要花在刀刃上
做产品不是做科研。你得算清楚：BOM成本多少？开模费多少？组装费多少？
我见过最惨的案例，是一个创业团队把所有预算都砸在激光雷达上，结果电机和电池只能买最便宜的。量产之后，电机一个月坏一批，售后成本直接吃掉利润。
2.3.1 BOM成本拆解（以中端机型为例）
| 模块 | 成本占比 | 说明 |
|---|---|---|
| 主控芯片（MCU/SoC） | 8-12% | STM32或国产替代，带AI加速的会更贵 |
| 激光雷达/视觉模组 | 15-20% | LDS约80-120元，视觉模组约50-80元 |
| 电机+驱动 | 10-15% | 轮子电机、风机、边刷电机 |
| 电池+电源管理 | 10-15% | 18650电芯或软包，带充放电保护 |
| 结构件+外壳 | 15-20% | 注塑模具费是大头，单件成本看量 |
| 传感器（碰撞、悬崖、陀螺仪等） | 5-8% | 红外、超声波、IMU |
| 其他（PCB、线束、包装） | 15-20% | 别小看这些，加起来不少 |
成本控制的核心原则： 功能做减法，品质做加法。去掉用户感知不到的功能，把钱花在电机、电池、传感器这些直接影响体验的部件上。
2.3.2 降本策略
- 芯片国产化：用GD32替代STM32，成本能降30%以上。但要注意，国产芯片的生态和文档可能没那么完善，调试周期会拉长。
- 模块化设计：把吸尘模块、拖地模块做成可插拔的。这样同一个底盘可以出多个SKU，模具费分摊下来就便宜了。
- 供应链谈判：量起来之后，电机和电池的单价能降20-30%。但前提是，你得先保证产品能卖出去。
2.4 开发周期规划：别把时间算得太死
做硬件开发，最忌讳的就是「乐观估计」。我见过太多团队，项目经理拍脑袋说「6个月搞定」，结果光模具修改就花了3个月。
2.4.1 典型开发周期（12-18个月）
| 阶段 | 时间 | 关键交付物 |
|---|---|---|
| 需求分析与概念设计 | 4-6周 | 需求文档、系统框图、关键器件选型 |
| 硬件设计（原理图+PCB） | 6-8周 | 原理图、PCB Layout、BOM清单 |
| 结构设计+模具 | 8-12周 | 3D模型、手板、T1/T2试模 |
| 嵌入式软件开发 | 12-16周 | 底层驱动、SLAM算法、路径规划 |
| 系统联调+测试 | 8-12周 | 功能测试、可靠性测试、EMC测试 |
| 小批量试产+认证 | 6-8周 | 试产报告、3C/FCC/CE认证 |
| 量产准备+爬坡 | 4-6周 | 产线调试、SOP、工装夹具 |
避坑指南： 我曾经在一个项目里，把软件开发时间压缩到10周，结果SLAM算法在复杂户型里频繁崩溃。最后不得不延期2个月重写路径规划模块。记住：算法和测试的时间，永远不要压缩。
2.4.2 并行开发策略
- 硬件和结构可以并行：原理图确定后，结构就可以开始建模。但要注意接口定义必须提前锁定，否则后面改结构会哭。
- 软件和硬件也可以部分并行：硬件打板期间，软件团队可以先在开发板上调驱动和算法。等PCB回来，直接移植。
- 测试要提前介入：不要等所有功能都做完了再测试。每完成一个模块，就做一轮单元测试。这样最后联调时，问题会少很多。
2.5 本章小结
需求分析这件事，说白了就是「想清楚再动手」。功能需求决定了产品能不能用，性能指标决定了好不好用，成本约束决定了能不能赚钱，开发周期决定了能不能按时上市。
这四个维度是互相牵制的。你想要旗舰级的性能，就别指望入门级的成本；你想要6个月上市，就别想着把所有功能都塞进去。
做产品，本质上就是做取舍。而取舍的依据，就是这份需求分析文档。
我的建议： 把需求文档打印出来，贴在工位上。每次做决策时，问自己一句：「这个改动，符合我们当初定下的需求吗？」如果不符合，要么改需求，要么别动。最怕的是，做着做着就忘了当初为什么要出发。