第一章：算法原型与产品定义

从学术论文到产品需求的转化

说实话，我见过太多团队死在「论文很漂亮，产品没法用」这个坎上。我自己也踩过这个坑——当年做惯性导航融合时，一篇顶会论文的算法在仿真环境里跑得飞起，结果一上实车，十分钟就飘到隔壁省去了。

为什么会这样？因为学术论文和产品需求之间，隔着一道巨大的鸿沟。今天我们就来聊聊怎么跨过去。

第一步：读懂论文的「潜台词」

拿到一篇导航相关的论文，别急着看公式。我习惯先问三个问题：

1. 这个算法在什么条件下成立的？ 比如，它假设GPS信号始终良好？还是假设载体运动是平滑的？
2. 它解决了什么问题？ 是精度问题？鲁棒性问题？还是计算效率问题？
3. 它没解决什么问题？ 论文的「未来工作」部分往往藏着关键限制。

举个例子。一篇关于视觉惯性里程计（VIO）的论文，可能在室内纹理丰富的场景下表现优异。但你想想看，如果产品要跑在夜间、或者空旷的停车场，这算法基本就废了。

第二步：定义MVP的功能边界

MVP不是「最小功能集」，而是「最小可交付价值集」。我个人的经验是，先砍掉所有「锦上添花」的功能，只保留「没有它产品就废了」的核心。

对于导航系统，MVP通常包含：

• 基本定位能力： 至少能在典型场景下输出位置（误差在可接受范围内）
• 状态切换逻辑： 比如GPS信号丢失时，能平滑切换到惯性推算
• 异常处理： 传感器故障时，不能直接崩溃，要有降级策略
• 输出接口： 至少能输出经纬度、航向、速度这三个基本量

我曾经帮一个团队做AGV导航的MVP定义。他们一开始列了20多个功能点，包括路径规划、避障、多车调度……我说停，咱们先只做一件事：让车能沿着一条直线走，误差不超过10厘米。就这一个功能，他们花了三个月才搞定。但搞定之后，客户愿意付钱了。

第三步：建立需求转化矩阵

把论文里的技术指标，翻译成产品需求，需要一个转化矩阵。我常用的格式是这样的：

论文指标	产品需求	约束条件
定位精度 0.1m (RMS)	典型场景下定位误差 ≤ 0.3m (95%)	考虑多径、遮挡等实际因素
更新率 100Hz	输出频率 ≥ 50Hz，延迟 ≤ 20ms	嵌入式处理器资源有限
初始化时间 1s	冷启动 ≤ 30s，热启动 ≤ 5s	考虑传感器上电时序
鲁棒性测试（仿真）	连续运行 72 小时无故障	需覆盖温度、振动等环境

你看，论文里的0.1米精度，到了产品里我敢放宽到0.3米。为什么？因为实际环境中的误差源太多了，你不可能复现论文里的实验室条件。放宽指标，反而能让系统更稳定。

第四步：识别「不可妥协」的硬约束

产品量产化过程中，有些约束是刚性的。我总结了几条：

• 成本约束： 传感器选型、处理器算力、内存大小，每一样都跟钱挂钩
• 功耗约束： 尤其是电池供电的产品，算法再牛，跑十分钟就没电了也不行
• 实时性约束： 导航算法必须在规定时间内输出结果，不能有随机延迟
• 安全约束： 功能安全等级（如ISO 26262）会直接影响算法设计

举个例子。论文里用EKF（扩展卡尔曼滤波）做融合，状态向量可能有30维。但产品级的MCU可能只有几百KB的RAM，你算算看，30维的协方差矩阵就要900个浮点数，再加上中间变量，内存直接爆了。这时候就得降维，或者改用更轻量的滤波方法。

第五步：输出MVP功能定义文档

最后，把以上思考整理成一份文档。我习惯用这样的结构：

1. 产品概述： 一句话说清楚产品做什么
2. 核心使用场景： 列出1-3个必须支持的场景
3. 功能列表： 分「必须有」、「最好有」、「未来有」三档
4. 性能指标： 每个指标都要有测试方法和验收标准
5. 约束条件： 成本、功耗、尺寸、安全等硬限制
6. 风险清单： 已知的技术难点和可能的替代方案

嗯，这里要注意一点：文档别写得太完美。MVP阶段，文档是「活的」，后面肯定会改。我见过有人花了两周写了一份50页的PRD，结果第一轮测试就发现核心假设错了，全白费。所以，先写个5页的，够用就行。

下一章，我们会聊聊怎么把MVP的功能拆解成具体的算法模块，以及如何设计模块间的接口。到时候我会分享一个我踩过的坑——关于IMU和GPS时间同步的，那叫一个惨烈。