企业官网建设流程全解析

“你们这是帮我们，还是监视我们？”

关于作者

我接触视觉整整10 年。

机器视觉、烟草、煤矿等行业都有深度开发经验。从硬件选型、算法开发、模型训练，到上位机开发及部署，都在一线磨过。

之前是多家公司人工智能团队的技术负责人。现在自己创业了，还在继续做视觉落地这件事。

作者说

工业视觉踩坑实录（六），就是SOP那篇，收到了不少朋友的点赞和收藏，首先谢谢大家的支持。

那一篇文章把SOP行为检测的技术方案从头到尾捋了一遍，YAML配置、状态机架构、多人追踪这些该讲的都讲了。发出去之后私信有个哥们给的要求挺直接「再讲细点」。

今天就来交这份作业。

不过先把话放在这儿，内容可能跟你想的不太一样。

动作开始和结束，到底怎么定

上一篇讲状态机的时候说每个步骤有明确的动作类型和超时阈值，检测到动作就跳下一步，超时就报警。那是在架构层面讲设计逻辑，实际操作中「检测到动作」这五个字本身就是个巨大的坑。

问题在于，工人的动作不是非黑即白的离散事件。

举个例子，「检查外观」这个步骤。有些师傅拿起来快速扫一眼就放下，整个过程不到两秒。有些师傅翻来覆去看好几遍，要花七八秒。还有些师傅会在检查的时候跟旁边的人聊天，手上的动作时断时续，你说他到底是在检查还是在摸鱼。

你没法给出一个精确的「动作开始」和「动作结束」的判定边界。

我一开始设的超时是十秒。结果有的师傅八秒搞定了，流程卡在那里等着判定完成。有的师傅要十五秒，系统报了超时，但人家其实认认真真在检查。改短了漏检，改长了等于没有约束。

后来我想了个办法，不设固定阈值，而是让系统自己学。跑个十几轮之后统计每个工人在每个步骤上的历史耗时分布，取一个自适应的窗口。刚开始没数据的时候用默认值兜底，跑了两三天之后每个工人就有了个性化的基准线。

这个改动确实有效果，误报率降了大概一半。但它解决的是一个表征问题，没有触及根本。

根本问题是什么。是「用姿态模型去判定一个模糊的连续动作」这个思路本身就有天花板。你不管怎么调阈值、怎么加自适应，只要底层的判定逻辑还是「当前帧的姿态属于哪个类别」，就永远处理不了动作的渐变和过渡。

这个认知我后来才想清楚，当时只是觉得哪里不对劲，但说不出来。

线性状态机装不下真实的操作流程

上一篇里讲了状态机的架构设计，那篇文章聚焦在技术实现上。这里我想聊聊状态机在实际业务中遇到的那些非技术问题。

真实流水线上的操作不是教科书里的流程图。它充满了分支、跳转、并行和例外。

最典型的就是并行操作。工人在拧螺丝的同时可能已经伸手去拿下一个零件了。这是非常合理的人体工学，手没事干的时候自然会去准备下一步的物料。但我的状态机要求当前步骤完成后才能检测下一步，并行操作直接触发误判。

还有可选步骤。产线主管跟我说「目视检查」这步，如果来料批次已经被IQC检过了就可以跳过。好，那我加个条件判断。结果过了两天又告诉我，还有好几种其他情况可以跳过不同步骤，条件组合起来有十几种。我的YAML配置文件从最初的三十行膨胀到了将近两百行，全是各种if-else的分支逻辑。

更要命的是条件触发。有些步骤只在特定条件下才需要执行，比如产品贴了红色标签要做额外检查，贴蓝色标签的跳过。这些条件在SOP文档里写得清清楚楚，但在实际操作中工人有时候会搞混，有时候标签本身贴错了。

我的状态机按标签颜色来决定是否触发检测步骤，工人把红标签贴成了蓝标签，系统就不检测了。出了一次质量问题之后产线主管跑来找我，说你这系统怎么回事，该检的没检。

我说你的标签贴错了。他说那你能不能也检测一下标签贴得对不对。

我算了一下，光是「检测标签颜色」+「根据标签决定后续流程」这个逻辑就要加好几个新的状态节点。原来的线性状态机已经快撑不住了。

后来我做了一个比较大的重构，把整个检测逻辑从「状态机驱动」加成了「事件驱动」。系统不再维护一个当前步骤指针，而是持续监听所有可能的动作事件，然后拿事件序列跟SOP模板做匹配。匹配用的是动态时间规整的变体，允许步骤之间有时间弹性，也允许局部乱序。

改动不小，但确实好用了很多。

不过说实话，这些优化都是在原有框架上的缝缝补补。状态机这种东西，它的表达能力有上限，面对真实世界里各种不规则的、模糊的、靠人经验来运转的操作流程，怎么改都会有够不到的地方。

这也是SOP开发过程中最难最磨人的地方，不要迷信某一种方法就能够解决掉所有的问题。

比技术更难的事

前面说的都是系统层面的问题，这些问题虽然麻烦但至少有解决方向。真正让我头疼的是一些跟技术没什么关系的事。

有一次巡线的时候，我看到一个老师傅拧螺丝从来不用定扭扳手，用一把普通扳手凭手感拧。按SOP这绝对算违规操作。但这位师傅在厂里干了六七年了，他负责的那条线良品率常年排前三。

我把这事跟产线主管提了，问他要不要标记一下。主管笑了笑说，张师傅一直都是这么干的，你给他标记了他反而不习惯。

说真的我到现在也不知道这种case该怎么处理。你从SOP合规的角度来看，他就是违规。但从产出质量的角度来看，他就是没问题。你到底是管人还是管结果。

后来我在系统里加了个「经验豁免」的标记功能，管理员可以给特定工人的特定步骤打上豁免标签。但这其实是个偷懒的做法，因为我把裁判权交还给了人，系统本身并没有变得更聪明。

还有一件事让我印象特别深。系统部署大概两周之后，有个年轻工人直接过来找我，跟我说了这么一句话。

「你们搞这个东西，到底是要帮我们还是要管我们。」

我愣了一下。

他接着说，他觉得这个系统就像是在监视他们干活，搞得大家都不自在。有时候动作稍微慢一点或者做法不太一样系统就报警，班组长的脸色就不好看。

那天的对话我记了很久。因为它点到了一个核心问题，你做产品的出发点是什么。如果你的系统让被使用者感到不舒服，那它技术再好也没用。

扯远了，回到正题。

这些问题跟代码无关，跟你用什么模型也无关。它们是「把一个技术系统嵌入到一群人的工作流程中」之后必然会产生的东西。你不可能只写代码不管人，也不可能只管人不用代码。两者之间的平衡点，才是做ToB产品最难的地方。

现在我在做的事

说完了踩坑，聊聊最近的方向。

过去大半年我一直在做一个事，就是重新想清楚SOP行为检测这件事到底该往哪走。起因是去年我看到了几家海外公司的产品，有一家做工厂视频分析的拿了接近一亿美元的融资，还有几家在做类似方向但切入角度不同。我把他们做的事情拆开来看，发现有一个共同的特征。

他们都不只是在做「实时检测」，而是把整个链条串起来了。

他们不是一上来就装摄像头做实时推理，而是先在工厂录制两到三周的视频，拿这些视频去建模，搞清楚这条产线上工人的实际操作是什么样的、哪些步骤是大家都在做的、哪些步骤只有部分人在做、每步平均耗时多少、变异系数多大。有了这个基线模型之后，再上实时检测，检测的标准不是SOP文档写的理想流程，而是实际测出来的正常操作范围。

这个方法论上的转变我觉得挺关键的。之前我的做法是直接拿SOP文档做标准，然后想办法让检测系统去匹配这个标准。新思路是先了解实际是什么样的，再在实际情况的基础上做异常检测。

理念完全不一样。

技术上我也在做一些升级。之前的检测链路是先做目标检测再提取关键点，然后拿关键点去匹配预定义的动作类别。这套东西能回答的问题是「现在这个人在做什么动作」。但我现在加了一层时序动作分割，放在姿态估计后面。它能回答的问题是「从过去十秒到现在的整个动作序列，跟SOP的吻合度有多高」。

从单帧判定变成时序判定，准确率提升了不少，更重要的是它能处理我之前说过的那些模糊动作的问题。一个持续时间很长的检查动作，单帧看可能很乱，但放到十秒的时间窗口里看，它的时序特征是很清晰的。

交付流程上也在优化。之前做标注全靠人工，一个新产线光是动作标注就要花两三天。现在引入了自动分割辅助标注的方案，先用通用模型把视频粗分割成动作片段，人工只需要校对和微调，标注效率大概提升了三到四倍。

产品定位也在变。之前我叫它「SOP行为检测系统」，定位是监控。现在我觉得这个词太硬了，你想啊，谁愿意被监控。新的定位我倾向于叫「数字教练」，意思就是系统发现你的操作跟标准有偏差的时候，不是事后告警追责，而是实时给你一个轻量提示，比如工位旁边的小屏幕闪一下，或者耳机里响一声。就像驾校教练坐在旁边一样，发现你操作不对及时纠正，而不是等你撞了再扣分。

定位从「监控者」变成「教练」，一字之差，但在工厂里接受的度完全不一样。

还有个事我想了很久。现在系统就是个哨兵，看到不对就喊。但喊完之后呢，还得人来处理。我觉得未来应该是系统能自己想清楚下一步。发现检查被跳过了，它应该知道在这个节点的后面插入一个补偿步骤。发现来料有问题，它应该能建议换线或者加检。不只是报警，是自动把修正方案规划出来，甚至直接执行。

这些都是我在做的事情，有些已经落地了，有些还在探索中。踩坑实录这个系列会继续写下去，等这些新方向跑出更多结果了再来跟大家汇报。

头帕王子，十年工业视觉老兵，现在创业中。在产线上踩过的坑比写过的代码还多。

📎 相关专栏

• 工业视觉踩坑实录
• 工业视觉踩坑实录（六）：SOP行为检测：用AI替你盯着工厂流水线