计算机视觉这几年热度一直居高不下，从目标检测到语义分割，从图像分类到姿态估计，开源模型一个接一个，榜单上的精度数字也越刷越好看。但我做了这么多年 CV 项目，一个越来越强烈的感受是：当模型精度不再是瓶颈的时候，真正卡住项目脖子的，反而是那些模型之外的东西。
前阵子和一个做工业质检的朋友吃饭，他跟我说了个挺典型的案例：他们团队花了三个月把缺陷检测模型的准确率从 92% 刷到了 98.5%，实验室指标非常漂亮，结果一到产线实测，每天误报几千次，现场工人直接把系统给关了。原因不是模型不行，而是训练数据和产线实际工况有偏差——光照角度不一样、产品型号换了、传送带速度变了。模型还是那个模型，但环境一变，之前刷上去的精度全成了纸面数字。
这个例子让我想明白一件事：计算机视觉落地，本质上是一个系统工程问题，而不是一个算法问题。模型只占整个项目的一小部分，真正决定项目成败的，是数据工程、评测基准、部署运维、迭代机制、成本核算，甚至还有跨部门协作。这篇文章我就从自己的实操经验出发，把模型之外那些真正决定落地效果的关键环节掰开揉碎讲清楚，希望对正在做 CV 项目的小伙伴有参考价值。
1. 从“能跑通”到“能落地”：被低估的数据工程
很多团队立项之初就会陷入一个思维定式——先把模型跑通再说。模型当然重要，但在 CV 落地项目里，数据工程的工作量通常占到整个项目 60% 以上，这个比例一点都不夸张，而且越往后期越明显。
1.1 数据量不是关键，数据裂缝才是
我在多个项目里验证过一件事：单纯堆数据量对模型效果的提升非常有限，真正决定上限的是数据质量和数据分布是否贴合真实场景。
很多团队一上来就到处扒公开数据集，ICDAR、COCO、ImageNet 轮番上阵，数据量堆到了几十万张，模型在验证集上表现也不错。但一部署到现场就露馅。为什么？因为训练数据的分布和实际场景之间存在一道“数据裂缝”——现场的光照条件、相机角度、目标形态、背景复杂度，和公开数据集里那些精心标注的图片根本不是一回事。
比如我做车牌识别项目时，公开数据集里大多是白天的、正面的、清晰的车牌。可到了实际停车场，有逆光的、有倾斜的、有被泥挡住一半的、有夜间红外补光的。模型在公开数据集上测试精度 99%，到了现场直接掉到 80% 出头。后来我花了两周时间专门去现场采集数据、做数据清洗、按场景分布重新划分训练集，模型精度才慢慢回到 95% 以上。这两周做的事不涉及任何算法改进，纯粹是数据工程，但效果立竿见影。
所以做 CV 落地项目，第一优先级永远是去现场采集业务数据，而不是在实验室里堆已有数据集。特别是那些容易被人忽视的异常场景、极端工况、边界情况，哪怕数量少，也一定要覆盖到。
1.2 标注一致性：最容易被忽略的精度杀手
数据工程里还有一个非常隐蔽的坑——标注一致性。打个比方，一个缺陷检测项目，A 标注员觉得这条划痕算缺陷，B 标注员觉得太轻微了不算，C 标注员只标了明显的那一段。三个人标出来的标签分布完全不同，模型在训练的时候就不知道该学哪个标准，结果就是精度上不去。
我踩过这个坑之后，总结了一套标注规范流程，可以有效减少这类问题：
- 写一份带图例的标注规范文档：每条规则都配上“是/否”的示例图。注意一定要求标注员只看标答的那张图，不要看训练集里的全量数据，避免标注员被整体分布影响。
- 做一轮试标 + 评审对齐：先把全量数据的 1~2% 发给标注员试标，收回来之后逐条对比，把所有有分歧的样本挑出来，开会讨论统一标准。
- 设置校验集做抽检：抽检比例建议不低于 5%，重点看边界样本和模糊样本，而不是看那些一眼就能判定的常规样本。
- 对标注结果做交叉验证：至少两名标注员对同一批数据背对背标注，计算一致率，一致性低于 90% 的类别，说明标准定义还有问题，要回过头去改标注规范。
这一步很枯燥，但请相信我，很多项目精度上不去，根子不在模型结构，而在标注数据本身就是乱的。数据干净了，哪怕用最普通的 ResNet 骨干，精度也会有肉眼可见的提升。
1.3 长尾场景：10% 的场景消耗 90% 的精力
还有一个做 CV 落地无法回避的问题——长尾分布。现实中，大部分业务数据都集中在少数几个常见场景上，而真正体现系统价值的，往往恰恰是那些低频但高风险的尾部场景。
比如一个安全生产监测项目，最常见的违规行为是“未戴安全帽”，可能占了 80% 的样本。但真正让客户觉得系统有价值的，可能是在夜间、雨雾天、强逆光、遮挡等复杂场景下还能准确识别未穿反光衣的行为。这些场景样本极少，但一旦漏报就是安全事故。
我处理长尾场景的思路是：先做场景聚类，再按场景配额采集数据。拿到一批数据后，先用聚类或人工梳理把所有场景分成几大类，然后检查每类的样本量占比。如果某个关键场景样本量低于 5%，就得额外去采集或做针对性增广，而不是把数据直接丢进训练集完事。
模型侧也有对应的长尾处理方法，比如重采样、重加权、解耦训练等经典策略，这些可以直接加在训练脚本上。但前提是，你得先意识到“长尾问题存在”这件事。很多团队连场景分布分析这一步都没做，就指望模型自己学出对长尾场景的鲁棒性，这是不现实的。
2. 评测基准的断层：离线指标漂亮，现场一塌糊涂
模型训完，下一步就是评测。而评测环节恰恰是很多 CV 项目翻车的地方——离线指标和在线表现之间存在巨大的断层。我在无数个项目里见过这种情况：验证集 mAP 0.98，到了现场被客户喷得狗血淋头。
2.1 测试集和真实场景的分布偏移
问题出在哪？出在评测集的构建思路上。很多团队评测模型用的是随机划分出来的测试集，这个测试集和训练集来自同一个数据源，分布高度一致。模型在这样测试集上的分数，本质上只是验证“它记住了训练数据的规律”，而不是验证“它能应对真实场景的变化”。
真正有效的做法，是把评测集和训练集明确分开，刻意让评测集包含以下内容以提高真实性：
- 不同光照条件、不同时间段的数据
- 不同设备、不同分辨率的数据
- 不同地域、不同环境背景的数据
- 训练集中出现频率极低的边界场景
如果你的评测集在这种“故意刁难”的数据分布下，准确率还能稳定在 90% 以上，那部署到现场才有底气。反之，如果模型在新场景数据上明显掉点，那就说明是数据覆盖的问题，要回到数据侧去解决，而不是调模型。
2.2 标签体系脱节：算法指标无法映射业务指标
离线评测还有个容易忽略的问题——指标体系和业务语言对不上。
算法工程师习惯性报 mAP、F1-score、IoU，但业务方关心的是漏检率、误报次数、处理效率、人力成本节约了多少。这两套语言如果不做映射，项目就会陷入一种尴尬局面：模型效果明明“很好”，但客户觉得“不可用”。
举个例子，工业质检场景里，业务方真正关心的是“百万分之几的漏检率”，因为一个缺陷漏过去流到客户端，可能要赔几十万。而算法侧如果单纯追求“准确率”，很可能会牺牲召回率、多放过去几个漏检。反过来，如果追求召回率过高，又会大量误报，导致产线停机检修次数增多，比漏检更让人崩溃。
所以我建议在项目评估阶段，就和业务方一起把指标分层定义清楚：
- 算法层指标：mAP、召回率、精确率、F1 等，用于内部技术评估
- 业务层指标：漏检率、误报率、单件检测耗时、人工复核率等，用于客户验收
- 经营层指标：人力节约、停产损失、客户投诉率等，用于衡量项目真实价值
定义清楚之后，模型调优的目标才不是“把 mAP 刷高”，而是“在满足漏检率指标的前提下，尽量降低误报率”——这是完全不同的两种优化方向。
2.3 验收口径：谁来定义“做完了”
还有一个现实问题——“做完了”这件事到底由谁来定义？
在 CV 落地项目里，算法工程师、项目经理、客户三方对“完成”的理解经常是不一样的。算法工程师认为“模型精度达标”就算完成；项目经理认为“系统能上线稳定运行”才算完成；客户可能认为“用了它之后能省人、能省心”才叫完成。这三个“完成”之间差距非常大，如果不提前对齐，项目末期大概率会产生扯皮。
我现在的做法是，项目启动时就直接定义验收标准做三方评审。用最少三方共同签字的量化值定义验收标准，例如每个班次的识别量、在特定光照下的准确率、现场连续运行多少天不出重大事故。有了这个基线，开发、测试、验收就有了一致的方向，不至于到最后互相甩锅。
3. 部署与运维里的硬骨头：模型跑起来只是第一步
模型训练好了、评测过关了，下一个真正考验工程能力的环节就是部署。“模型在服务器上能跑”和“模型在客户环境里稳定跑一年”是两个完全不同的概念。
3.1 硬件选型不止看算力，还要看功耗和散热
很多算法工程师对硬件的理解停留在“GPU 显存有多大、算力有多高”上，但实际项目里，硬件选型要考虑的维度要复杂得多。
比如在工业产线场景，设备往往被塞在不通风的机柜里，环境温度可能到 40 度以上。你选了一块高算力的 GPU，模型推理速度确实快，但散热跟不上，跑半小时就开始降频甚至死机。这种场景下，算力不是瓶颈，散热和功耗才是。
我做过一个边缘盒子项目，一开始选了某款大算力 GPU 模块，实测推理速度 300ms/帧，看起来完全达标。但装到现场运行两天就发现频繁重启，排查半天发现是机柜温度过高，引入了热降频保护机制。后来换了一款功耗只有原来 1/3 的低算力模组，把模型做轻量化、把推理框架做精简，单帧耗时 500ms，稳定跑了大半年没出过事。
所以选型阶段一定要考虑部署环境的物理约束，常用的几个维度是：工作温度范围、整机功耗上限、峰值功率、无风扇被动散热的可行性和防护等级。别光看算力，现场跑不稳，什么精度都白搭。
推理延迟和吞吐量还只是性能指标的一部分，更重要的往往是稳定性。这类问题上，以我在嵌入式侧比较熟悉的 RK 系列（瑞芯微）平台为例，量化工具链的成熟度差异很大，后训练量化裁减（PTQ）对敏感算子的支持程度、新增算子的适配难度，会直接决定你落地周期是两周还是两个月。另一个选择是华为 Atlas 平台，它在算子库和推理框架上积累比较深，如果团队有昇腾方向的技术储备也值得考虑。相比之下，CUDA 生态的成熟度固然高，但部署环境一换，技术栈往往需要推倒重来。
3.2 推理优化是被严重低估的一环
模型部署时的推理优化，是能拉开开发效率差距的关键环节。别被“优化”这个词吓到，实际做起来没那么玄乎，核心思路就是做减法和换引擎。
我自己的项目里，常用的优化手段优先级如下：
- 精简模型结构：换轻量骨干（如 MobileNet、EfficientNet-lite）、剪枝、蒸馏。有时候师生蒸馏的收益非常可观——大模型做 Teacher，小模型做 Student，精度损失控制在 1% 以内，推理速度提升好几倍。
- 量化：INT8 量化能把模型体积缩小到 1/4，推理速度提升 2~3 倍。但要注意，量化对敏感算子（如某些注意力模块、LayerNorm）有精度损失，需要逐层验证。用 INT8 量化时务必先跑量化前后的精度对比、敏感性分析，不能直接无脑量化。
- 换推理引擎：同一个模型在不同推理框架上的速度差距可能超过 2 倍。TensorRT、OpenVINO、ONNX Runtime 各有各的优势场景，选对了立竿见影。
- 计算图优化：算子融合、常量折叠。现在的模型转换工具大多内置了这些能力，基本不需要手写，但开启和关闭效果差异显著，值得花时间研究参数。
之前一个字符识别项目，原始模型在 GPU 上单帧推理 12ms，看起来挺快。但客户要求部署到 CPU 服务器上，直接用 PyTorch 跑，单帧 180ms，完全不可用。我只做了两件事：转 ONNX、换 OpenVINO 引擎，单帧直接降到 30ms。这还是在没做量化和剪枝的情况下。很多项目性能不达标，其实不是模型的问题，是推理引擎没选对、优化Pipeline没打通。
3.3 模型版本管理与灰度发布
模型部署不是“一次上线，永久使用”。业务场景在变，数据分布在变，模型肯定也要迭代。但如果每次更新都“全家桶”式替换，风险极高——万一新模型在某个场景上表现不如旧模型，你连回滚都来不及。
我现在比较推行的做法是灰度发布。简单说就是让新旧模型同时跑一段时间，按比例切流：先切 10% 的流量到新模型上跑着，观察几天核心指标，没问题再逐步扩大到 30%、50%、100%。一旦发现异常，立刻回滚到旧模型，影响面可控。
配套的还要有模型版本管理机制，最核心的一条底线是：每次模型更新，必须记录当时的训练数据版本、预处理脚本版本、训练参数、评测结果和已知问题。否则出了事故，你根本不知道线上这个模型是用哪批数据训出来的，复现都无从下手。
我用的是轻量级方案：每个模型包内置一个 version.json（JSON），固定包含模型文件 hash（MD5）、训练数据集的版本号或快照 ID、预处理脚本 commit ID、关键超参数和新增/修复的问题描述这些字段。同时用一个统一命名规范管理目录，例如yolov5s_defect_v3.2.1_20250210，这样看起来还是比数不清的final_final_v2靠谱得多。上线前校验 hash、版本号必读，省得部署时抱错包。
4. 数据漂移与模型失效：藏在“稳定运行”背后的暗雷
模型上线只是下半场的开始，真正有挑战的事情是我称之为“暗雷期”的阶段——系统稳定跑了一两个月，突然某天准确率跳水。这种问题很难排查，因为模型代码没变、推理环境没变，但是数据变了。
4.1 数据漂移：你没变，但世界变了
数据漂移这个概念，在 CV 领域尤其现实。产线换了新批次原料，表面纹理和之前不一样；商场上新了季节款，服装款式和训练数据完全不同；停车场装了新的路灯，夜间光照色温变了。这些变化肉眼几乎不可察觉，但模型的输入分布已经悄悄变了，精度会迅速下降。
我之前做过一个农作物病虫害识别项目，春季做的模型，到了秋季客户反馈准确率明显下降。排查下来发现，光照角度变了、叶片颜色从嫩绿变成深绿、病害形态也有季节性差异——这些不是模型的错，是数据本身已经迁移了。
应对漂移的手段，主要靠监控。我强烈建议任何上线的 CV 系统都要配套数据监控模块，实时统计推理结果和置信度分布。一旦发现某几类样本的置信度持续下降，或者低置信度样本占比明显升高，预警机制就要触发，需要人为介入做数据重采样和模型更新。
4.2 置信度阈值：一把双刃剑
很多 CV 部署系统里都有一个置信度阈值参数，默认取 0.5 或 0.7。这个参数是做什么用的？模型输出置信度低于阈值的样本，系统会拒绝自动判断，转人工处理或直接告警。
阈值设高了，误报少了，但漏报多了——大量真实目标被拒之门外；阈值设低了，漏报少了，但误报多了，人工复核量暴增。阈值不是模型参数，是业务参数，必须和业务方一起调，不能算法自己拍脑袋定。
我的实操方法是画一条“阈值-误报率/漏检率”曲线（本质上就是在不同阈值下计算这两个指标），拿给业务方看，让他们基于成本和风险的权衡来定阈值。比如工业质检场景，他们宁愿多复核 20% 的图片，也不愿意漏掉一个真正的缺陷——那就把阈值调低。如果是安防监控场景，误报太多会消耗保安的耐心，导致真告警也被忽略，可能就需要更高的置信度要求。
4.3 定期重训与模型自愈机制
应对数据漂移的另一只手是定期重训。但重训不是说“每周跑一遍训练脚本”就完事，关键要看清楚了再训——如果不做数据筛选就把所有新数据都塞进来，模型反而可能被脏数据带偏。
我现在惯用的节奏是：
- 周级统计：每周统计一次线上推理置信度分布、各类别召回率趋势
- 月级评估：每月用固定的评测集做一次回归测试，对比新旧模型指标
- 触发式重训：当某项核心指标连续 7 天低于基线阈值，或新增数据积累到一定规模时，才触发重训
重训的输入数据也不是“新老混合直接训”，而是做分层采样：离线的历史核心数据（保证不忘本）+ 近期新增数据（适应新分布）+ 人工修正过的错分样本（补齐短板）。三者按比例混合，才能做到既适应新场景，又不牺牲历史能力。
5. 成本与 ROI：算不清账的项目做不大
做 CV 落地项目，除了技术，还要懂成本意识。很多看起来技术很炫酷的项目，最后没做成，根本原因是算不过账来。
5.1 成本不只是 GPU 的账单
之前在和同行交流时，发现有人会把“一张 A100 卡 8 小时训练成本”算成项目的核心成本，这其实属于典型的“把账算小了”。CV 项目的真实成本结构比这复杂得多，除了算力，还包含以下多项：
- 数据成本：现场采集的人力、标注外包费用、数据清洗工时
- 人力成本：算法、前后端、嵌入式、部署运维、项目经理的工资分摊
- 试错成本：模型方案每次推翻重来的沉没成本
- 维护成本：上线后的监控值守、定期重训、故障响应
算完这笔账再回头看，你会发现算法的算力成本往往只占项目总成本的一小部分。这就是为什么我一直强调数据工程重要——因为数据是 CV 项目里成本占比最大、也最容易失控的部分。
5.2 什么项目不值得碰
作为从业者，我越来越认同一个原则：不能只看技术可不可行，还要看投入产出比。遇到下面这类需求，我会很谨慎地评估到底接不接：
- 准确率要求 99.99% 以上的“绝对可靠”场景——这种项目往往不是算法问题，是物理极限问题
- 目标本身就是模糊定义的场景——比如“识别图片里有没有隐患”，隐患是什么连业务方自己都说不清
- 替代成本极低的场景——比如人工每小时能处理 1000 张图，且准确率已足够高，AI 化之后收益不明显
- 数据获取在合规或隐私层面有硬约束的场景——数据问题解决不了，模型就是无米之炊
好的 CV 项目应该是一个降本增效的故事：用 AI 把原来需要 10 个人的活压到 2 个人，或者把原来 1 秒的检测时间压到 100 毫秒，或者把原来做不到的实时检测变成可能。这些故事的 ROI 是能算清、能讲明白的。作为技术人员，我们要让技术的注意力对准真正有价值的业务问题上，而不是因为“能做”就做。
5.3 提效率的关键在流程再造，不在模型替换
还有一个容易被忽视的点——AI 系统的价值，往往不在于“单点识别”有多准，而在于它能不能嵌入业务流程、改变业务流程。
举个例子，仓库里做包裹破损检测，如果只是把原来人工目检换成摄像头+AI 识别，那提升有限。但如果把检测环节前置到分拣线，让系统在包裹掉落瞬间就完成检测、自动分流、联动记录系统做数据归档，那整个流程的效率就完全不同了。
算法团队在做项目时，建议多和业务方聊“流程”而不是只聊“需求”。搞清楚这个识别结果用在哪里、谁在用、怎么用，远比反复打磨模型精度更能创造价值。有时候把流程重排一下，比把准确率再刷高 0.5 个点有意义得多。
6. 组织与协作：跨部门的沟通成本才是最大的成本
最后一个想聊的话题，可能很多技术文章不会去写，但在我心里它和模型一样重要——项目组织与跨部门协作。
6.1 需求翻译：把业务问题翻译成算法能做的事情
做 CV 项目最常遇到的情况是，业务方提了一个模糊要求，算法团队凭自己的理解开干，干完发现根本不是一回事。
比如业务方说“我们要做一个智能监控系统，能自动识别违规行为”。这句话落到算法侧，可以拆出好几十个问题来：
- “违规行为”具体指哪些动作？要不要识别危险区域闯入、离岗睡岗、未按规定路线巡视这三级场景？
- 需要处理的是历史视频还是实时流？
- 摄像头角度是固定的还是可变的？
- 检测到违规之后，系统要做什么？弹窗告警、短信通知、还是联动门禁？
- 准确率要求多高？漏掉一次和误报一次分别会被追责到什么程度？
这些问题不在一开始问清楚，后面做的所有工作都可能是在往错误的方向用力。我的习惯是项目启动前拿一份调研问题清单去和业务方逐条过，包括业务目标、使用场景、硬件部署环境、异常处理流程、性能指标要求、数据现状这六类。宁可前期多花一周时间把需求对齐，也不要后期花一个月返工重做。
6.2 产线现场参与：坐在办公室做不出能落地的产品
还有一个非常朴素的建议：做 CV 落地的算法工程师，一定要去现场。
去看产线实际的运行节奏，去看真实场景里的光照噪声，去和现场操作工人聊聊天。你会发现很多实验室里完全想象不到的问题——相机安装高度不合适、目标物体运动速度太快导致运动模糊、金属反光造成高光过曝、雨天玻璃上的水渍影响画面清晰度。这些问题的答案都不在论文里，只在现场。
我每次做新项目，至少在项目初期跑 2-3 趟现场。说真的，在现场待一天得到的信息量，比开着文档开三天的会还要大。去了现场，你才能知道数据该采什么、模型该优化什么、系统该怎么设计。什么“给算法一个 KPI 就在工位上刷 mAP”，纯属自欺欺人。
6.3 多方共识：让业务方、算法、工程在同一条船上
最后聊一下项目推进会里的共识管理。做 CV 落地项目，你面对的利益相关方可能包括业务负责人、产线主管、算法同事、硬件工程师、运维团队、外包标注团队、客户 IT 部门……每个人的诉求和考核目标都不同。
算法团队想拿高精度指标发论文；产线主管想的是别耽误产能；运维团队怕的是新系统增加他们的维护负担；客户 IT 部门担心的是数据安全和系统兼容性。这些诉求之间天然存在摩擦。
我的经验是：
- 定期例会不能省：至少每两周一次，让各方同步进度和风险
- 关键决策要留痕：需求变更、验收标准调整、数据口径变化，全部书面记录，避免事后扯皮
- 要有一个“翻译官”角色：最好是既懂技术又懂业务的人，负责把算法团队的技术语言翻译成业务方听得懂的收益描述，反过来把业务方的需求翻译成算法团队能做的工作项
很多技术项目死在最后，不是死在技术上，而是死在组织协作的内耗里。这不是鸡汤，是血泪教训。
7. 几点实操建议：给正在做或准备做 CV 项目的人
聊了这么多，最后基于我自己的实操经验，整理几条最直观给到各位的小建议，不用长篇大论，每一条都能直接用。
第一，把数据工程等价于模型工作来排期。如果项目经理给算法排了 4 周，数据只有 1 周，这个项目的上限就已经被定死了。数据采集、清洗、标注、质检的工时一定要留够，且这些工时最好在项目规划阶段就定下，不要等模型效果不好才开始补。
第二，评测集一定要隔离管理。评测集从第一天就单独锁起来，任何人都不能拿它做训练或调参。我见过太多团队拿测试集做早停、选模型，最后线上效果一塌糊涂，因为模型已经间接“记住”了测试集的内容。评测集隔离的管理，是 CV 项目里一条非常基本的项目纪律，必须写入研发规范。每次训练前，训练脚本强制只读取训练数据目录并锁定评测集校验哈希，踩过坑的团队自然会明白这条的意义。
第三，预测结果的保存比推理结果本身重要。上线初期，把每一条预测结果（包含图片 hash、模型版本、置信度、原始输出）完整保存至少 30 天。这些数据是后续做数据分析、模型迭代、事故回溯的最重要素材。很多团队觉得保存预测结果占存储就随手删了，等出了问题后悔都来不及。
第四，和业务方建立一条直接沟通的通道。算法工程师有条件的话直接和业务方对接，不要所有信息都经过项目经理转述。信息在传递过程中会衰减、会变形，一级级传下来，需求可能已经完全不是原来的样子了。定期到现场演示互动，看看实际效果，听听反馈，这是最快的学习方式。
第五，不要一上来就追最新模型。新模型虽然看起来很吸引人，但在落地项目里成熟稳定是第一优先级。用经过大量生产环境验证的经典模型（如 YOLO 系列、RT-DETR、经典语义分割模型）先做出基线版本，跑通整个链路、建立评测和监控机制之后，再考虑引入新结构。做好端到端质管的全流程，拿经典模型的基线和可靠性收益，比什么都强。
提示：这最后一条不是反对技术进步，而是想提醒各位——在落地项目的语境里，稳定压倒一切，可维护性比先进性更重要。新技术可以用，但要有充分的验证周期和回退预案，而不是直接把整条业务线绑在一个未经生产检验的新模型上。
写在最后
偶尔还是有朋友会问我：现在做 CV 还要不要钻研模型？我的答案一直是：要，但这是基本功，不是胜负手。当整个行业都在用近乎相同的开源模型和训练范式时，模型能力本身已经趋同，你的差异化竞争力只能来自模型之外的能力——对数据的理解深度、对业务场景的洞察、工程化的严谨度、以及把多方资源组织起来推进落地的综合能力。
这几年做下来的一个体会是：计算机视觉的“下半场”，不是拼谁的模型结构更新、谁的榜单数字更高，而是拼谁能把算法嵌进业务流程，并且在现场各种干扰下稳定运行、持续创造价值。这种能力没有现成的开源代码可以直接用，只能靠一个个项目慢慢磨出来。
如果你正在做 CV 项目，遇到“模型精度上不去”“现场效果不好”这类问题时，我真心建议先别急着改模型结构，回到数据、评测、部署、监控、成本、协作这些环节里找找原因——很多时候，答案就在模型之外。
