第3章：业务需求与技术可行性分析

说实话，我见过太多项目死在「需求不清晰」这个坎上。

有一次，客户说「我要一个能检测工人是否戴安全帽的系统」。听起来很简单对吧？结果一聊才发现，他们厂区有20个摄像头，光线条件各不相同，有的在户外暴晒，有的在室内昏暗角落。更麻烦的是，安全帽有红黄蓝三种颜色，有些工人还把帽子挂在腰间而不是戴在头上。

你看，这就是典型的「业务需求没拆透」。今天我们就聊聊怎么把这类模糊需求，变成可落地的技术方案。

3.1 业务目标拆解：从「一句话」到「一张表」

我个人习惯，拿到需求后先做三件事：

• 明确核心指标：准确率要多少？延迟能接受多少？
• 梳理边界条件：什么场景下系统必须工作？什么场景可以忽略？
• 定义失败标准：什么情况下算「系统不可用」？

举个例子，还是安全帽检测。我一般会拉一张表：

维度	需求描述	技术约束
检测目标	工人头部是否佩戴安全帽	需区分帽子与背景中的圆形物体
环境条件	室内外、白天黑夜	需支持低光照、逆光场景
性能要求	实时检测，延迟<200ms	需边缘端部署，模型需轻量化
异常处理	多人遮挡、帽子颜色变化	需数据增强+多尺度训练

你想想看，这张表一出来，技术选型的方向就清晰多了。不会出现「模型精度99%但跑不动」的尴尬局面。

3.2 技术栈选型原则：别追新，要追稳

我踩过最大的坑，就是选了一个刚发布两周的框架。

当时觉得「哇，这个新框架性能提升30%」，结果文档不全、社区没人、遇到bug连个问的地方都没有。最后不得不回退到老版本，白白浪费两周时间。

所以我现在选技术栈，遵循三个原则：

具体到计算机视觉项目，我常用的组合是：

• 模型训练：PyTorch（生态好，调试方便）
• 模型部署：ONNX + TensorRT（推理速度快）
• 边缘端：NVIDIA Jetson 或 Intel OpenVINO
• 后端服务：FastAPI（轻量、异步支持好）

3.3 可行性评估报告：别等做完了才发现不行

我曾经接手过一个项目，客户要求「用手机拍一张照片，就能检测出皮肤病的早期症状」。听起来很酷对吧？但仔细一分析：

• 数据获取：皮肤病图像涉及隐私，公开数据集极少
• 标注难度：需要专业医生标注，成本极高
• 模型风险：误诊可能导致医疗事故，法律风险巨大

最后我们给出的结论是：技术上可行，但商业上不可行。客户听完反而松了口气——至少没把钱扔进水里。

所以，可行性评估报告应该包含三个部分：

3.3.1 技术可行性

说白了就是「能不能做」。我一般会问自己几个问题：

• 现有公开数据集够不够？不够的话，自采数据成本多少？
• 模型精度能否达到业务要求？有没有类似场景的SOTA参考？
• 推理速度能否满足实时性？边缘端还是云端？

3.3.2 资源可行性

「有没有人、有没有钱、有没有时间」。

我见过一个团队，三个人想三个月做一个自动驾驶感知系统。嗯，结果可想而知。我一般会按人月估算：一个中等难度的CV项目，至少需要1个算法工程师+1个工程开发，干3-6个月。

3.3.3 风险可行性

这部分容易被忽略，但恰恰是最关键的。

举个例子，人脸识别项目。技术上完全可行，但如果你要部署在公共场所，就得考虑隐私合规问题。欧盟有GDPR，中国有《个人信息保护法》，搞不好是要吃官司的。

3.4 实战案例：一个智能质检项目的可行性分析

去年我带团队做了一个「手机屏幕缺陷检测」的项目。需求很简单：在产线上用摄像头拍屏幕，自动识别划痕、气泡、亮点等缺陷。

我们做了这么几步：

1. 需求拆解：客户要求检测速度<1秒/片，缺陷检出率>99%，误报率<1%
2. 技术选型：选了YOLOv8做检测，因为速度快、精度高，而且社区成熟
3. 数据评估：客户提供了500张缺陷样本，但缺陷类型分布不均。我们建议先做数据增强，再补充2000张真实样本
4. 硬件评估：产线已有工业相机，但分辨率不够。建议升级到500万像素，并加装环形光源
5. 风险分析：最大的风险是「缺陷样本太少导致模型过拟合」。我们设计了主动学习策略，先跑一轮，把不确定的样本挑出来让人工标注

最终报告写了20页，客户看完直接拍板：「干！」

嗯，这就是可行性分析的价值——让所有人对「能不能做成」有一个清晰的预期。

3.5 总结：别让需求成为「空中楼阁」

说了这么多，其实核心就一句话：业务需求必须能翻译成技术指标，技术指标必须能落地执行。

我见过太多项目，需求文档写得天花乱坠，一到开发就发现「这个做不了」「那个数据没有」。与其这样，不如一开始就把丑话说在前头。

下一章我们会聊「数据采集与标注策略」，这是整个项目的地基。地基打不好，上面盖什么都白搭。