工业AI项目敏捷开发落地：以可验证模型交付为核心

做了几年工业AI项目的落地我一听到“敏捷开发”四个字第一反应不是白板、站会、冲刺而是“这个迭代到底交付了什么可验证的东西”。工业AI项目和互联网产品有一个本质区别代码写完不算数模型训练完也不算数它必须跑到现场设备上在真实光照、真实噪声、真实生产节拍里证明自己有用。敏捷开发在工业AI项目里落地的过程因此更像是在给“迭代”重新下定义。如果你直接照搬互联网团队那套“两周一个冲刺、每周末演示功能”的做法大概率会变成每天站会、每两周汇报、模型却永远上不了线。这里把我这几年在视觉质检、预测性维护、工艺参数优化项目里反复调整后的框架和经验拆开讲适合项目经理、算法工程师、工厂数字化负责人一起看。核心只有一个让每一次迭代都产出一个可以在现场被验证的模型增量而不是一堆代码提交记录。1. 为什么工业AI项目会让敏捷“水土不服”很多人失败的原因不是团队不够努力而是把敏捷当成了一套固定动作站会、计划会、回顾会、评审会每个会都开了项目还是不断返工。真正的矛盾在于工业AI的反馈回路和互联网产品的反馈回路完全不在一个量级上。1.1 工业现场的反馈回路比互联网长得多互联网产品改一个按钮代码发出去后台立刻能看到点击率变化一个迭代的反馈周期可能是半小时。工业AI项目完全不是这样。一个视觉检测模型要上线前置条件包括相机安装位置、光源稳定性、PLC通讯、产品换型规则、缺陷样本采集每一步都跟物理设备和生产计划绑定。举个我实际遇到的例子某个质检工位要识别一种表面缺陷这种缺陷平均每生产两小时才出现一次而且只在特定型号、特定光照角度下才明显。算法团队再敏捷也不可能在一个两周冲刺里凭空变出几千张有效缺陷图。两周冲刺能完成的往往只是数据采集方案、标注规范、或者一个可以跑通的服务骨架。所以在工业AI里敏捷迭代的“完成”不能以日历时间为唯一标准而要以模型成熟度、数据版本、现场验证结果共同决定。否则团队会陷入一种很尴尬的状态每次评审会都是同一个模型换了一个新界面。1.2 团队里的“目标函数”不一致工业AI项目的团队构成比互联网项目复杂得多。算法工程师关心准确率是不是又涨了一个点生产部门关心的是别因为测试模型导致停线设备科关心的是别整天报假警让维修师傅白跑质量部门关心的是千万别漏检项目经理关心的是能不能在季度节点拿出一个可展示的成果。这些角色的目标天然冲突如果敏捷流程只是把大家拉到一个房间里开会并不能解决冲突。真正的解决办法是把“目标函数”统一成业务指标。比如当前产线的漏检率、误报率、单件检测耗时、每天可处理的样本量。所有迭代任务都围绕这四个指标展开需求池里的每一项都必须能回答“它到底影响哪个指标”。1.3 照搬互联网敏捷的典型症状我见过太多团队把敏捷做成了“形式敏捷”几个典型症状非常明显。站会开了但数据没有人同步。算法工程师昨天改了什么代码、今天准备改什么对项目其实帮助不大。大家最需要知道的是这个迭代的数据版本有没有更新新采集的故障样本有没有纳入训练集现场试运行跑了多久误报集中出现在哪一类产品需求拆成了开发任务但没有人校核数据可行性。产品经理对着生产线提需求写出来的是“识别并报警所有缺陷”听上去很清晰实际落到数据上却发现五种缺陷里有两种样本量不够还有一种是现场老师傅都很难确认的模糊形态。这种需求就算拆成小任务做完也是废的。验收评审只演示PPT。把几组模型的AUC、准确率、召回率摆出来看着很专业实际上这些数字绑定的测试集可能早就被参与训练的人看过了。验收必须拿现场抽取的真实样本在目标设备上跑给所有人看。2. 我的落地框架把“可验证的模型交付”当成迭代单位既然照搬不行那工业AI项目到底应该怎么跑敏捷我的做法是把传统敏捷里的“用户故事”换掉改成“可验证的模型交付”。一个业务需求能不能进入迭代不取决于它能不能拆成两周一上的功能而取决于它能不能在迭代结束时用数据和指标证明自己有效。2.1 迭代节奏按模型成熟度而不是日历日期我在项目里一般把节奏分成两个阶段冷启动阶段和数据飞轮阶段。冷启动阶段通常是项目开始的前两个月目标是从0到1跑通一条最小链路。这个阶段迭代周期会放慢到三到四周因为要解决的是数据采集、标注规范、基础模型选型、边缘设备适配这些基础问题。硬套两周冲刺会把团队逼疯。数据飞轮阶段则是当模型已经有一个可接受的低配版本并且数据通路稳定后迭代可以收缩到一到两周。此时每次冲刺的目标很明确在固定数据版本上训练一个新模型用离线指标加上现场影子运行结果判断是否比上一版好。好就发不好就退回。关键是不要为了迭代而迭代。如果这个迭代没有带来新的有效样本、新的特征思路、新的现场验证结论那这个冲刺名存实亡。2.2 需求拆解数据、建模、集成、验收分开拆传统敏捷把需求拆成“用户故事”描述方式是“作为质检员我希望系统能自动识别划痕以便减少漏检”。这种描述在工业AI里完全不够。我现在要求每个业务需求至少拆成四类任务数据任务、建模任务、集成任务、验收任务。数据任务要写明需要采集哪个工位、什么型号、大致多少样本、缺陷类型分布、是否需要标注复核。建模任务要写明用哪个数据版本训练、评估指标是什么、和哪个基线模型对比。集成任务要写明模型要部署到边缘盒子还是服务器、推理时延要求、报警结果怎么回传PLC或质量系统。验收任务要写明现场试运行多久、对比人工判定的标准、出现争议时谁来仲裁。这样拆的好处是团队可以并行推进而且不会出现“算法做完了才发现数据没准备好”的情况。所有任务同样进入同一个需求池只不过在排期上必须保证数据任务提前启动。2.3 定义完成从“代码上线”变成“效果达标且可复现”工业AI项目的Definition of Done不能只是“代码提交并部署”。我自己的检查清单是这样训练所使用的数据集版本已经固定且记录在案训练过程可以被同一环境完整复现不是靠某个人电脑里的某个临时脚本离线评估报告已经生成包含准确率、召回率、误报率、各类缺陷的细分指标模型已经打包成可在目标设备运行的镜像或文件推理时延满足产线节拍现场试运行结果已经记录至少包含一次真实验证而不是只在测试集上算指标已知风险列表已更新比如“换型时误报上升”“暗光样本不足”等。我经常对团队说一句话如果下周一跑不出上周五的结果这个迭代就等于没有完成。可复现性是敏捷迭代的底线。提示不要只看平均指标务必看分型号、分缺陷类型、分时段的细分指标。工业数据的分布极不均匀某类缺陷可能占90%平均准确率再高也掩盖了少数类几乎全错的问题。2.4 混合使用固定节奏和拉式看板纯Scrum和纯看板在工业AI项目里都不够用。我通常混着来对数据标注、模型发布、现场验证这类可预期、有明确完成标准的任务用固定节奏的迭代管理对算法实验、特征探索、异常样本分析这类结果不可预期的任务用看板做拉式管理。算法工程师最讨厌的是被要求“两周内一定把某个模型结构跑通”。他可能试了十种参数组合最后发现当前数据条件下没有哪一种有效。强行动态调整计划反而比死守冲刺更有价值。看板列我一般只设五列数据就绪、训练实验、离线评估、现场验证、已发布。每个任务卡片都绑定一个数据版本和一个模型实验记录。卡在某一列的时间过长就是问题的信号。卡在“数据就绪”说明采集或标注出问题了卡在“现场验证”说明现场条件不支持需要第一时间协调资源。3. 让每次迭代都端到端跑通数据、训练、评估、发布敏捷开发在工业AI项目里能否落地表面上取决于团队协作实际上取决于工程基础设施。没有一条能端到端跑通的数据-模型-发布流水线再好的敏捷流程都是空中楼阁。3.1 数据版本管理先于代码版本管理很多项目一上来只做代码版本管理对数据则是“放在共享文件夹里谁改谁知道”。这是工业AI项目最大的隐患。训练数据每天都在更新删掉的坏样本、新增的现场样本、标注修正都会直接影响模型效果。如果没有数据版本管理你会经常遇到“昨天还是95分今天不知道为什么变成了89分”的问题。我要求每个项目都建立数据清单至少包含原始数据目录、标注数据目录、分割好的训练集和验证集、每个数据版本的变更说明。每次实验必须在实验记录里写清楚用的是哪个数据版本。一个最小实验记录文件大概长这样experiment: id: exp-2025-03-01 dataset_version: dataset_v2_20250228 model_config: cnn_v3 train_params: epochs: 60 batch_size: 32 learning_rate: 0.001 metrics: recall: 0.934 false_alarm_rate: 0.027 inference_time_ms: 180 edge_pilot: line1_trial_20250304不要小看这个文件。有了它你才能在迭代评审时说清楚这一个迭代硬指标提升了多少是靠数据多了、模型改了、还是单纯阈值调了。3.2 自动化训练与评估流水线模型的训练结果要能自动跑出来而不是靠算法工程师手动截图发到群里。我推动每个项目尽早搭一条最简单的自动化流水线数据准备、数据增强、训练、评估、生成指标报告。工业AI的数据增强尤其要小心。通用的旋转、翻转、颜色扰动在一些场景有效但在零部件检测里可能制造出不符合物理规律的特征。比如字符识别场景字符倒过来本身并没有实际意义划痕检测里旋转90度可能合理旋转45度就不合理。所以自动化流程里必须包含人工审核增强样本的环节。自动化评估报告建议固定格式每次模型实验结果都包含四个部分整体指标、分缺陷类型指标、失败案例分析、资源消耗训练时长、模型大小、边缘推理时延。没有失败案例的报告都是缺少决策价值的。3.3 发布策略离线评估、影子模式、小范围灰度工业现场不能接受“随便发一版试试”。但敏捷又要求快速试错怎么平衡我的做法是三段式发布。第一段是离线评估。在固定测试集上跑不看单点指标重点看漏检的样本能不能被合理解释。如果漏检的样本是光线太暗、缺陷形态极端可以放进下一轮数据采集计划。第二段是影子模式。模型并行部署在边缘设备上但预测结果不真正参与控制或报警只记录日志。让模型和现有的人工判定或旧系统同时在真实产线上运行一两天甚至一周积累一批对比数据。影子模式是工业AI项目里成本最低、价值最高的验证手段能让你在完全不打扰生产的情况下知道模型在真实数据流上到底行不行。第三段是小范围灰度。选择一条产线、一个班次、一类产品型号把模型结果真正显示给操作员或接入报警流程但仍保留人工复核。灰度时间至少覆盖一次产品换型或一次班次交接因为工业数据最容易在边界条件下崩。3.4 现场验收检查单现场验证不是把模型丢到设备上等结果就行。我整理了一个固定检查单每次现场试运行前逐项确认少一项都可能白跑一趟。检查项具体确认内容典型坑图像输入相机分辨率、曝光参数、拍摄角度是否与训练数据一致现场相机被调过角度画面比例和训练集不一致触发条件光电传感器、PLC信号是否正常触发拍照信号线松动拍出来都是空图或重影标注对齐现场记录的产品状态是否和图像一一对应标签滞后模型学习到错误的对应关系推理时延单张图像从拍照到结果返回的耗时是否满足节拍边缘设备负载高时延从150ms涨到500ms报警回落报警结果能否正常写入到操作员界面或数据库数据格式不匹配系统报错但没人看日志长期运行日志是否记录每张图的结果、置信度、原图路径只记录了报警结果无法复盘失败样本4. 团队怎么组需求怎么评会怎么开工业AI项目的敏捷转型难点不在方法而在人和信息流的组织方式。没有合适的角色参与敏捷会变成研发团队自嗨。4.1 五类角色必须出现在同一个项目组第一类是数据负责人负责采集方案、标注规范、数据质量审核第二类是算法工程师负责模型训练、评估、实验记录第三类是系统集成工程师负责边缘设备、相机、PLC、网络和部署环境第四类是工业领域专家最理想的就是一线老师傅或工艺工程师负责判断模型结论是否符合现场逻辑第五类是产品/项目经理负责把业务需求翻译成可执行的任务并盯住指标闭环。这五类人可以不是全职投入但必须在同一个需求池里对齐。尤其是工业领域专家不能当作“验收时叫过来看一眼的顾问”而要从数据标注规则、需求评审到灰度发布全程参与。4.2 需求池里必须同时存在四类工作我在迭代计划会上会检查需求池里是不是同时有数据、建模、集成、验收四类工作。如果所有任务都是“训练模型”“调参优化”那下一步必然卡在数据或集成上。我一般按一个大致的比例做排期参考数据类占三成建模类占三成集成验证类占三成复盘和流程改进占一成。比例可以浮动但数据类只多不少。工业AI项目真正缺的通常不是算法灵感而是高质量数据。4.3 迭代评审不要放PPT放现场样本工业AI项目的迭代评审应该是最有现场感的过程。我建议评审会直接做两件事放模型预测失败的样本以及让现场老师傅当面判断这些样本的真实标签。算法团队往往觉得自己在测试集上表现很好老师傅拿起一张图说“这种缺陷不可能单独出现它是上一道工序的残留”一句话就能改变整个需求优先级。评审会不需要追求所有任务全部完成只需要让三类信息对齐数据是否还有缺口、模型在当前数据上是否还有硬伤、现场是否需要调整部署方式。4.4 回顾会重点复盘“等待时间”敏捷回顾会如果只看“故事点完成率”容易变成互相甩锅。我更关注的是每类任务的端到端耗时尤其是卡在等待上的时间。等待数据采集、等待标注完成、等待现场排试验窗口、等待IT开权限、等待老师傅有空确认样本这些等待时间才是项目真正的瓶颈。把一个任务从“开始动工”到“被验证”的时间画出来绝大多数时间都是等出来的。回顾会只要解决一个最大的等待问题效率就会明显提升。5. 避坑实录最容易变成“假敏捷”的四个场景这套框架我并不是第一次就搭对中间踩过不少坑。下面几个场景是我在不同项目里反复见过的“假敏捷”如果你也有类似情况可以对照排查。5.1 假敏捷一计划排满数据质量无人负责某项目第一次做迭代计划时算法团队信心满满把训练、调参、优化安排得满满当当。但是没有人负责盯数据质量结果训练集里混入了大量重复图片标签错误率也不低。模型指标看着可以实际是记住了重复样本。后来我们设立数据负责人角色把数据质量核对作为迭代开始的强制检查项。每次训练前必须跑一遍数据体检重复度、标签分布、类别平衡性、图像清晰度。数据体检不过算法不启动。5.2 假敏捷二测试集指标漂亮现场一跑就崩这是最典型的问题。测试集是从历史数据里随机切出来的往往已经做过清洗、去重、亮度修正。现场环境完全不一样产品批次一变、环境光一变模型立刻失灵。现在我把“现场影子模式运行”作为每个迭代的前置条件而不是上线后的可选操作。一个模型如果在影子模式里误报率远超离线评估值那么算法团队的工作不是继续调参而是先弄清楚测试集和真实数据流之间的分布差异。5.3 假敏捷三每次迭代都在调阈值模型结构原地踏步有些团队为了“每周都有提升”总在改报警阈值、改置信度过滤规则让指标看起来在变好。这其实是假迭代。阈值只能微调不能解决模型本身对某些模式不敏感的问题。我会要求实验记录里增加一个字段本次迭代修改了什么如果连续两次迭代都只是改了阈值那就应该把这次冲刺判为无效回到数据采集和模型结构改进上。5.4 假敏捷四只看演示不看漏报误报的代价矩阵不同漏报和误报的成本完全不一样。以质检场景为例漏报一个缺陷可能造成客户投诉和批量返工误报一次可能只是操作员多看一眼。如果验收只看准确率很多团队会选择压低误报、牺牲召回让演示看起来“没那么吵”实际风险全部累积到漏报上。每次验收我都要求团队明确填写代价矩阵漏报单次损失、误报单次损失、当前模型在哪种失衡状态下更值得上线。这个矩阵直接决定模型能否发布而不是看谁指标更好看。6. 工具选型与度量建议别让敏捷变成开会敏捷工具不是关键但轻量的工程记录工具能帮团队把敏捷动作落到每天的操作里。尽量别在项目一开始就上一套复杂的项目管理全家桶那样只会增加填写负担。6.1 轻量组合看板、实验记录、数据目录我常用的组合是一块电子看板管理需求池和迭代卡一套实验记录文件管理每次训练和评估结果一个数据目录管理所有数据版本。这三样东西可以分别用最简单的方式实现甚至电子表格加共享文件夹就能跑起来。看板列越少越好。我之前用过十五列的自定义看板最后没人维护。现在固定为数据就绪、训练实验、离线评估、现场验证、已发布五列每张卡必须要能对应到具体的数据版本和实验记录。6.2 核心度量模型迭代周期而不是故事点传统敏捷的故事点是用来估算开发工作量的但工业AI项目的复杂度更多来自数据不确定性。我建议团队记录这几个数字从业务需求提出到候选模型完成离线评估的周期、从数据采集到数据版本可用的周期、模型在影子模式下的误报率趋势、每次迭代新增有效样本量。其中“新增有效样本量”是最容易忽略的指标。工业AI模型越做越差很多时候不是因为算法不行而是因为新迭代没有补充足够多新的有效样本模型在反复学习同一批数据。6.3 什么时候才需要上重平台如果只有一个试点项目真的不需要建设什么大平台。但当你有多个项目、多条产线、多个边缘设备要统一管理时集中式的模型管理、数据版本管理、设备下发管理才有必要。我判断是否需要上重平台就两个标准团队是否已经因为“模型文件找不到”“数据集版本混乱”“现场设备模型更新靠人肉U盘”而明显痛苦是否有至少三个以上项目共用一个基础能力。如果答案都是否那就先用轻量方案跑起来别让平台建设变成第一个“大项目”。6.4 一个小技巧把失败样本贴墙最后分享一个我非常喜欢的小技巧在每个迭代结束后把模型预测错误的典型样本打印出来贴在项目办公室的实体白板上旁边标注错误类型。下一迭代的目标就是把这些墙上的失败样本逐个消灭。这个做法比任何电子看板都管用。因为每个人路过时都会看到算法工程师会主动想新特征数据工程师会去补样本现场老师傅会指着图说“这个根本不是缺陷”。团队的目标感就靠这面墙撑了起来。我现在不管在哪个项目里都会保留这块物理白板只写五件事当前数据版本、当前最优模型、现场误报案例、现场漏报案例、下一个要验证的假设。这几个问题一摆整个团队的敏捷迭代就不再是仪式而是真正围绕模型效果在转。