第十二章 · 让它在产线上跑住，而不只是跑通

demo 和产品之间，隔着一场地震

你在办公室里，把摄像头对准几个样品，AI 一个个都判对了。你截了屏，发到群里，老板点了个赞。那一刻你觉得，成了。

可这只是「跑通」。跑通的意思是：在一切都顺利的时候，它能干对一次。

而产线要的是「跑住」：在接下来的三百六十五天里，不管有人踢掉网线、不管半夜车间跳闸、不管上游换了个新料号导致图像变了样，它都得要么继续干对，要么安全地停下来喊人——而不是悄无声息地崩掉，让一整批不合格的产品混着走了。

这两者之间隔着的，不是功能，是现实。现实里，一切都会坏。

工业软件的第一性原理：假设一切都会坏

普通人（包括你让 AI 写代码时的默认状态）写程序，脑子里想的是「事情顺利地发生」：传感器读到数、网络是通的、数据长得跟昨天一样。这条「一切顺利」的路径，有个行话叫 happy path（顺利路径，就是假设万事如意时程序走的那条道）。

工业软件的设计前提，恰恰相反。它叫 防御性编程：不指望一切顺利，而是预先把每个环节坏掉的样子都想一遍，想好它坏了我怎么办。

打个比方。业余司机开车，想的是「路是平的，前面没人」。老司机开车，眼睛一直在扫「那辆车会不会突然并线、这个路口会不会窜出人、刹车要是失灵我往哪打方向」。老司机不是悲观，他是知道：路上什么都可能发生，你得提前替这些「万一」留好后手。工业软件，要的就是老司机。

下面五个东西，就是老司机的五个后手。我一个个用大白话讲，每个都告诉你：不做，会怎样。

后手一 · 异常处理：程序摔倒了，得能爬起来

异常处理说白了就是：当一件本该正常的事突然不正常了，程序不能整个人当场去世，而要「接住」这个意外，记下来，然后决定是接着干还是安全停下。

现实里会发生什么意外？传感器这一秒突然读不到数（返回一个空值）；有人蹲下去理线，网线松了；上游系统升级，传过来的数据格式从「12.5」变成了「12.5mm」多了俩字母。

没有异常处理，会怎样？程序遇到一个它没见过的情况，直接崩溃退出。产线上没人盯着屏幕，机器还在往下走料，AI 已经死了半小时了没人知道——这半小时的产品，等于没人检。

「接住」不等于「假装没事」。接住的意思是：这一帧图像坏了，那我跳过这一件、记一笔、报个警，而不是让整条线陪着它一起死。

后手二 · 断电断网重连：拔了插头，还能接着干

车间不是机房。跳闸、临时停电、Wi-Fi 抽风，是家常便饭。所以你的程序必须假设：我随时会被人拔电源。

好的程序被拔了电、再上电，应该能自己重新连上摄像头、连上数据库、接着上次的地方干下去。而且要满足两个苛刻的要求：不丢数据，不重复算。

不丢数据——断电前那几件的检测结果，得已经安全落到硬盘上，不能只存在内存里跟着一起没了。不重复算——恢复以后，别把已经检过、已经发货的那件又重新检一遍、又报一次废。

不做会怎样？轻则每次一断电就得有个人跑过去手动重启、手动对齐进度；重则数据对不上账，这个班次到底做了多少件、废了多少件，成了一笔糊涂账。工业现场最怕糊涂账。

后手三 · 日志：给你的产品装个黑匣子

日志就是程序一边干活一边写的流水账：几点几分，发生了什么。「14:03:07 第 8821 件，判为合格，置信度 0.97」「14:03:09 摄像头读取超时，已跳过，已报警」。

飞机上有黑匣子，出了事靠它复盘。你的产品也需要黑匣子。因为工业现场的故障有个特点：它往往不在你眼前发生。凌晨四点漏检了一件，等早上有人发现，现场早就恢复正常了，你上哪儿去找当时到底哪儿出了岔子？

答案是：翻日志。没有日志，你就是抓瞎——只能靠猜，靠「重现」一个你根本不知道怎么触发的问题。有日志，你能把出事那一刻前后几秒钟，一帧一帧看清楚。

后手四 · 看门狗：一个不睡觉的值班员

有一种坏，比崩溃更阴险：程序没退出，但卡死了——它还开着，界面还亮着，看上去活着，其实早就不动了，像个植物人。这种时候连崩溃日志都没有，最难发现。

看门狗（watchdog）就是专门治这个的：另起一个极简单的小程序，在旁边盯着主程序。主程序每隔几秒得主动「喊一声」报平安，看门狗一旦发现超过约定时间没听见喊声，就判定它卡死了，直接把它重启。

你可以把它想成一个不睡觉的值班员，手里攥着秒表：每隔十秒你得跟我打个招呼，超过十秒没动静，我就当你出事了，一巴掌把你拍醒（重启）。

不做会怎样？程序悄悄卡死，产线继续走料，可能几个小时都没人发现「AI 其实早不干活了」。看门狗的价值，就是把「几小时没人管的植物人」变成「几十秒后自动满血复活」。

后手五 · 失效安全：拿不准的时候，倒向安全那一侧

这是五个里最重要的一个，它接着第六章讲的「安全第一」。

失效安全（fail-safe）说的是：万一系统出了问题、拿不准了，它要倒向安全的那一侧，而不是稀里糊涂地放行。

什么叫安全的那一侧？在质检里，是「宁可停机报警，也不放行一个可能有缺陷的产品」。在控制机械臂里，是「一旦拿不准位置，立刻停住别动，也不许乱挥」。核心是一句话：不确定的时候，选择「停」和「喊人」，而不是「继续」。

为什么这条最要命？因为它跟别的失效不一样。程序崩了、卡死了，你顶多是「没检」，损失的是没抓到的次品。但一个「失效不安全」的系统，会在自己出问题的时候，还自信地告诉产线「这件是好的，放行吧」——这是把缺陷主动放进了合格品里，甚至可能让机械臂在错误的位置发力。前者是漏，后者是错，错比漏严重得多。

健康的默认姿态是：不确定 = 停 + 报警。绝不能是：不确定 = 放行。这一个字的差别，就是安全和事故的差别。

不会写代码的你，怎么把这些做扎实？

看到这儿你可能慌了：这五样听着都很「工程」，我不会写代码，AI 又默认只写顺利路径，那这些防御谁来做？

关键洞见来了——你不是靠自己写，你是靠在规格里就把这些坏情况列进去，逼 AI 去处理。

回到第三章那句话：AI 不会主动替你操心失效，它只会老老实实实现你说了的东西。你说「判断产品好坏」，它就给你写一条顺利路径。你没提「传感器读不到数怎么办」，它就当这事永远不会发生。所以这些防御做没做，取决于你问没问。

而「把所有可能坏的地方都想一遍」，恰恰是产品经理最值钱的看家本领——想全场景。这活儿本来就该你干，只不过以前你想完是写进需求文档给工程师，现在你想完是写进规格给 AI。能力没变，对象变了。

一份可操作的「坏情况清单」思路

做法很简单：拿着你的每一个环节，逐个追问一句「这里坏了怎么办」，把答案写进给 AI 的规格里。像这样一条条过：

• 输入坏了：传感器读不到数、图像全黑、数据格式变了——程序该跳过并报警，还是停机？（写清楚：跳过这一件，记日志，亮黄灯。）
• 连接断了：断电、断网、摄像头掉线——恢复后要自动重连、接着上次进度干，不丢已存的数据、不重复处理已完成的件。
• 程序卡了：要有看门狗，超过 N 秒无响应就自动重启，并记一条「我被重启过」的日志。
• 结果不可信：置信度低于某个线、或出现从没见过的情况——一律走失效安全：停机 + 报警，绝不放行。
• 出了事查得到：每一件的判断结果、每一次异常、每一次重启，都要落日志，能按时间倒回去看。

把这五问的答案，明明白白写进你给 AI 的规格里。你不需要知道 AI 用什么代码实现——就像你不需要知道老司机踩刹车的肌肉是怎么收缩的——你只需要坚持要求「这些万一，都得有后手」。