当AI模型准确率高达90%时，工业场景真正在意的却是那10%的错误如何兜底。本文深度剖析高风险AI项目中产品经理的核心战场——不是追求模型完美，而是构建严密的防错体系。从预警工单的三重质检机制到冷启动数据的巧妙挖掘，揭示如何在不许出错的领域让不确定的AI输出确定的结果。
前阵子有个做工业软件的朋友跟我喝酒，吐槽他们刚上的那套排放异常预警。模型准确率做到九成，老板在周会上还挺得意。结果环保局的人来调研，听完介绍只回了一句：剩下那一成错的时候，谁去顶？
他当场没接上话。
这一句，差不多就是所有高风险 AI 项目的命门。工业环保监测尤其是这样——一个排放数据判错了，后面牵的不是什么用户体验，是停产、是罚单、是真有人要担责任。在这种地方，你跟人说”准确率九成”，对方压根不关心那九成，只关心那错的一成兜不兜得住。
而兜底这件事，模型自己干不了。能干的只有产品经理。
我做产品 4 年，最近 2 年都泡在 AI 方向，越做越觉得：在不许出错的场景里，PM 真正该操心的根本不是模型准不准——那是工程师的战场——而是模型错的那一下，整套流程接不接得住。模型天生是不确定的，可你交到客户手上的东西必须是确定的。这两者中间隔着的那层，才是 PM 的活。
下面几条，是我自己琢磨过、也跟几个做工业的同行掰扯过的。不一定对，挑几个想得比较清楚的说。
我见过太多 AI 项目，一上来就想给每个输出都上保险，结果系统又慢又贵，最后谁也推不动。
毛病出在没分清轻重。
内部知识问答答错了，用户再问一遍就完事，几乎零成本。可排放超标的处置建议里，模型把”先断电”那一步给漏了，工人照着干，那是会出人命的。这两种错，凭什么用一套标准量？
所以第一件事不是建模型，是坐下来跟业务一条一条过：这个输出错了会怎样？最坏到哪一步？最后拍板的是人，还是机器？
(我发现不少 AI 产品经理特别躲这种活，总觉得这是业务该操心的，自己应该去钻 prompt、钻检索。可偏偏就是这步躲掉了，后面所有防护都盖在空中。)
过完一遍，心里大概就有杆秤了。有的输出直接触发设备动作、派工单、决定放行还是拦——这种错一次代价就够大，得重防。有的是给个参考、人还会再确认一遍的——轻轻拦一下就够。有的纯粹是给人看的日报摘要——人自己会把关，你瞎防反而添堵。
劲要使在刀刃上，不是摊在每一寸。
就拿预警接抢修工单这条线说。从一个异常被发现，到一张工单递到工人手上，中间得过好几道关，每道关盯的还不是一回事。
最前面那道，机器几毫秒就跑完，便宜得很。它不管对不对，只管能不能用：字段填全没有，设备编号格式对不对，工单上写的备件编号在仓库系统里查不查得到，优先级是不是只填了那几个允许的值。这道关拦的，是模型在信息不够时自己瞎补进去的东西——最低级，也最高频。
再往后一道，得上模型了，盯的是对不对。归因说的是 3 号机组主轴承坏了，抢修步骤里却写着换 2 号机组的轴承——设备号都对不上。这种矛盾，规则不一定抓得全，得让另一个模型把整张单子从头读一遍。合规文件白纸黑字写着必须先断电，可生成的步骤里压根没断电这一步，这也得靠语义去比对。
最后一道，是人。涉及人身安全的、动火吊装这类特种作业的、核心产线停机的——必须有个活人签字。这道关最贵，所以只能留给最该留的那几张单。
三道关不是重复劳动。代码看不懂逻辑矛盾，模型读不出”这条规程是法律强制的”，人又不可能去一张张盯成千上万条格式错。少哪道，都会从那个口子往外漏东西。
PM 要干的，就是把这几道关怎么排、什么单子走哪条道，画成一张谁都看得懂的图。
还有个细节特别容易漏。
质检那道关吐出来的，别只是一个红叉。我见过一个团队就栽在这儿。他们的质检只返回”通过/不通过”，结果每次不通过，都得有个人去翻到底哪儿错了。检查是上了，人比以前还累。
那不叫防错，那叫给自己又添了个瓶颈。
正经做法是让它吐一份明细：哪个字段有问题、问题是什么、跟哪条规程顶了、模型自己有几分把握。这份东西能再喂回去，让系统自己改一遍、重新过关，人只管那些机器修不动的疑难杂症就行。
说完该干的，得说说不该碰的。这部分我觉得比前面还重要，因为 AI 产品经理最容易在这儿栽跟头——刚看完两篇技术文章，就觉得自己什么都懂了。
最常见的就是微调。一聊到模型不够准，总有人脱口而出：”要不咱微调一个？”
在用检索的场景里，多数时候真不用微调，PM 更不该是拍这个板的人。
微调是把知识烧进模型的权重里。可你做检索，知识是用的时候现查、现塞进去的，根本不用烧。报告生成也好、异常归因也好，要的是把查来的文档读懂、按模板写出来——知识库做扎实、prompt 写清楚，就够了。真到了输出格式刁钻到 prompt 怎么写都跑偏、或者专业术语模型根本不认、检索也喂不进去那一步，才轮得到微调。可到没到那步、怎么调、拿多少数据调，那是工程师的判断，不是 PM 该硬插的手。
我那个做了十几年工业自动化的朋友有句话，我一直记着：产品经理最危险的一刻，就是他觉得自己听懂了的那一刻。
还有个地方 PM 老搞混——预警这一步到底用什么。
一提预警，好多人张口就是”用大模型行不行””千问能不能上”。这是把两码事混一块儿了。
预警处理的是传感器吐出来的一串数字：温度、压力、流量、浓度。判断这堆数字里有没有不对劲，用的是异常检测、分类那一类模型，根本不是语言模型该管的事。冷启动时没标注数据，先上无监督的，让它自己摸清楚正常长什么样，偏了就报警；等攒够了标注，再换成能分清异常类型、还能给个概率的有监督模型。
大模型在哪儿出场？在后面——拿着查来的历史案例和故障手册，去把原因讲出来、把抢修步骤写出来、把工单组织成型。前半段是发现数字不对，后半段才是用人话把事说清楚。两段用的压根是两种东西。
PM 不用会调这些模型，但得分得清这条道上每一步该用哪一类。分不清，需求文档里就会蹦出”用大模型做预警”这种让工程师哭笑不得的话。
不一定。看两件事：风险高不高，系统跑稳没。
风险这条，有一段是技术绕不过去的。特种设备、危化品、动火作业，国内这些领域人工审核是法规写死的，不是你产品设计上能选的。这条线，拿任何技术理由都跨不过去。PM 能做的是认下它、老老实实把它画进流程，而不是琢磨怎么绕。
系统成熟这条，倒是能慢慢挪。新系统刚上，让所有单子都过人——不是不信任模型，是这会儿每一张被人改过的单子，都是质检模型最好的教材。等某一类单子的质检准头稳了，再把这一类放开自动派。人工就这么一点点退到只剩高风险那几类。
所以”要不要人审”不是一锤子买卖，是一条会动的线。PM 的活，是设计这条线怎么挪、按什么指标挪、挪的时候留什么兜底。
兜底这点，在抢修里尤其要命。抢修是抢时间的，质检要是把流程卡死、单子半天出不来，那就是帮倒忙。所以质检没过的时候，不能让单子堵在那儿，得留一条快速转人工的道——宁可叫人来接，也不能让流程停摆。
防错和效率，在这种地方天生是打架的。怎么取舍没有标准答案，得看那台设备坏了到底有多急。
聊质检绕不开置信度，可这词一出来好多人就懵。其实特别白。
你就想象一个老师傅站在设备边上盯着，心里默默打分。一切正常，十分，放心；有点不对味儿，六分，接着盯；八九不离十要出事了，九分，赶紧喊人。置信度，就是让模型学这个老师傅打分，给个零到一之间的数。
不同模型算法不一样，这个不重要。重要的是工程上有条铁律：单看某一个时刻的分高，没用。
噪声、抖一下，都可能让某一瞬间的分蹿上去。真该报警的，是一段时间里这个分稳稳往上爬——这一刻 0.6，下一刻 0.7，再下一刻 0.8，连着几下都压在高位。偶尔跳一下就报，工人很快会被假警报磨得麻木，等真出事那回反倒没人搭理。
漏报会出事故，误报会让人不再信这套系统。两头怎么平衡，得看设备多金贵：核心的宁可错报也不能漏，边角的就得把误报压住、别天天扰民。
阈值定在哪，说到底不是技术题，是业务题。把业务的轻重缓急，翻译成模型里那个阈值——这恰恰是 PM 该干的。
工业 AI 最常卡在这儿：一开始没有标注数据。不少团队就堵这儿了，觉得没数据没法训，迟迟动不了。
可数据往往就在手边，只是没被当成数据看。
维修工单就是。每张工单都写着：啥时候、哪台设备、出了啥故障。这等于天然标好了”异常发生在什么时间、是哪一类”。拿故障时间往前推几个钟头，那段传感器数据就是异常样本；挑设备稳稳运行、啥记录都没有的时段，就是正常样本。冷启动要的数据，这么一拼就出来了。
不过有个坑得提一句：过去没报警，不等于过去没异常，可能就是当时没人发现。所以从老数据里挖出来的”正常样本”别全信，最好拉个老工程师再过一眼。标注这道关，机器替不了人。
行业里有个挺聪明的做法：先用不要标注的无监督模型把摊子支起来，它报一次警，就派人去现场看一次，看完的结论又变成新的标注，攒够了再升级成更准的模型。系统就这么边干活、边给自己攒教材，越跑越准。
PM 在这事上能出的力，是去翻清楚公司手里到底压着哪些”看着不像数据、其实是数据”的东西。工单、停机记录、巡检台账——这些往往比你重新去采一批，值钱多了。
写到这儿回头看，有个结论其实挺反直觉：在不许出错的场景里，PM 花在模型本身上的劲，反而该是最少的。
模型准不准，那是工程师的战场。PM 真正要守的，是模型外面那一圈——哪些输出值得防，防到什么份上，谁来兜底，那条人工的线怎么随系统成熟一点点往外挪，还有哪些事自己压根不该碰。这些想透了，比把准确率多抠两个点，对落地的意义大得多。
这套东西，没有哪一条是能从论文里直接抄来的。它一半在车间，一半在规程，还有一半，在那个出了事要担责的人身上。
所以我也不敢说上面这些就一定对。我就是把自己想过、跟人吵过的几条摆出来。
留个问题给你：你手上那个 AI 项目，要是模型明天就错一次，谁会第一个知道？知道之后，是系统自己把它接住了，还是得等个人加班来救火？这俩要是答不上来——可能就真不是模型不够好的问题了。
本文由 @Talen 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。