第一章：项目启动与需求分析
做AI硬件工具，最怕什么？
怕你辛辛苦苦做了个原型，结果没人用。
我见过太多团队，一上来就搞高大上的功能，结果连最基本的用户场景都没想清楚。今天咱们聊聊Reality AI工具怎么从零开始，把需求做扎实。
1.1 市场定位：别做“万能药”
Reality AI工具，说白了就是帮硬件工程师把AI模型部署到边缘设备上的工具链。但市面上类似工具不少，TensorFlow Lite、ONNX Runtime、OpenVINO……凭什么用户选你？
我个人习惯，先看三个维度：
- 痛点够痛吗？ 很多工程师卡在“模型训练完，部署到单片机就崩”这一步。我遇到过一个小团队，花了两周调一个模型，结果在Cortex-M4上跑不起来，最后发现是量化参数没调对。
- 场景够窄吗？ 别想着覆盖所有硬件。先聚焦一个细分领域，比如“基于ARM Cortex-M系列的传感器数据推理”。
- 差异化在哪？ 我们的优势是“一键部署+自动优化”，而不是让用户手动调参。
核心结论：Reality AI工具的市场定位是“面向嵌入式开发者的低门槛AI部署工具”，主打“从训练到部署，一个命令行搞定”。
1.2 用户痛点分析：那些年我们踩过的坑
我做了十年硬件原型，踩过的坑能写本书。咱们直接看用户最头疼的几个问题：
| 痛点 | 具体表现 | 频率 |
|---|---|---|
| 模型转换失败 | PyTorch模型转TFLite时，算子不支持 | 极高 |
| 内存溢出 | 模型太大，单片机RAM不够 | 高 |
| 推理速度慢 | 一帧图像处理要200ms，实时性不达标 | 中 |
| 调试困难 | 部署后不知道哪一步出问题，全靠猜 | 高 |
为什么会这样？
说白了，AI框架和嵌入式开发是两拨人做的。搞AI的用Python，搞嵌入式的用C。中间缺个“翻译官”。
我曾经帮一个客户调模型，他用的YOLOv5，目标是在STM32上跑。结果模型里有个torch.nn.functional.interpolate，TFLite根本不支持。最后只能手动重写算子，折腾了三天。
避坑指南：我曾经建议团队在项目启动前，先列一个“算子兼容性清单”。把目标硬件支持的算子列出来，训练时避开不支持的。这能省掉80%的后期调试时间。
1.3 MVP功能定义：少即是多
MVP不是“最小功能集”，而是“最核心价值集”。
我建议第一版只做三件事：
- 模型导入与转换：支持PyTorch、TensorFlow、ONNX三种格式，自动检测不兼容算子并给出修改建议。
- 一键部署：用户选好硬件型号（比如STM32F4、ESP32），工具自动生成C代码和Makefile。
- 性能预估：部署前给出RAM占用、Flash占用、推理时间预估，让用户心里有数。
你想想看，如果这三个功能做扎实了，用户还会抱怨吗？
注意：千万别在MVP里加“可视化调试”“自动超参搜索”这些花哨功能。我见过一个团队，MVP做了六个月，结果核心功能还没跑通。记住，先让用户用起来，再谈优化。
1.4 知识体系框架
下面这张图，是我做项目时常用的思考框架。它帮你理清从需求到落地的逻辑链条。
这张图其实就三句话：
- 市场定位决定了你服务谁
- 用户痛点决定了你做什么
- MVP功能决定了你第一版长什么样
嗯，这里要注意：很多团队把顺序搞反了。先想功能，再找用户，结果发现没人需要。我建议你反过来，先找用户聊，再定功能。
1.5 实战建议：如何做需求调研
别坐在办公室里拍脑袋。我一般会做三件事：
- 找5个目标用户深度访谈：问他们“你现在用什么工具？最烦什么？”
- 看竞品差评：去GitHub Issues、知乎、论坛，看用户骂什么。那些骂得最狠的，就是你的机会。
- 做个原型快速验证：用Flask搭个简单的Web界面，让用户上传模型，返回转换后的代码。哪怕界面丑得像DOS，只要功能对，用户就会给你反馈。
一个小技巧：我曾经用Google Forms做了个问卷，只问三个问题：“你用什么硬件？”“你用什么框架？”“你最大的痛点是什么？”收集了200份回复，直接决定了MVP的功能优先级。
好了，第一章就聊这么多。记住，需求分析不是一次性的，它贯穿整个项目周期。后面咱们会一步步把原型做出来，到时候你会发现，前期需求挖得越深，后期返工越少。
公众号:蓝海资料掘金营，微信deep3321