第十三章 · 怎么知道它是真的对：验证、试运行与迭代

没测过的「做好了」，等于没做

你让 AI 改了一段代码，它回你一句：「已完成，功能正常。」你信吗？

问题在于：你不会写代码。它说「正常」，你没有任何独立的手段去戳穿它。它要是错了，或者只是「在它想到的那几种情况下对」，你也看不出来。你只能信。而在工业现场，信一个你验证不了的东西，是要出事的——不是你被扣绩效那种出事，是整批产品流到客户手里、或者机械臂在真人旁边做了个不该做的动作那种出事。

先说个不好听的实话：验证这件事一点都不酷。它耗时间，没有 demo 那一刻的高光，还经常被跳过——因为跳过它，在演示当天没人看得出来。但它恰恰是「demo 侠」和「真能交付的人」之间那条线。demo 侠交付的是「那天那台机器上，那几个样品，跑通了」；能交付的人交付的是「这条线接下来三个月，见到什么它都扛得住」。

第一件事：让机器替你反复核对

测试，说白了就是把「喂它这个，它应该吐出那个」这句话，写成一段机器能自己跑的核对程序。你规定：这张有划痕的图，判定必须是「不合格」；这张干净的图，判定必须是「合格」。写好之后，机器每次都能自动把这一串都核对一遍，对不对当场给你亮红绿灯。

好消息是：这段核对程序，你不用自己写，AI 写得又快又好。你负责的是另一件 AI 干不了的事——指定该测哪些情况。这才是你的活。AI 会本能地测那些「正常的、漂亮的」情况，因为那些最好想。真正会咬人的，是你在第 3 章定规格、第 12 章想「万一坏了怎么办」时列过的那些边界和坏情况：

• 划痕正好压在零件边缘、一半在一半不在，算不算缺陷？
• 图片是全黑的（镜头被挡了）、或者曝光过度一片白，它会不会硬判一个结果出来？
• 传送带上同时来了两个零件，它数得清吗？
• 一个从没见过的、图纸上根本没有的新缺陷类型来了，它老实说「我不确定」，还是瞎猜一个？

你把这些情况用大白话列给 AI，让它把每一条都变成一个自动核对项。列得越刁钻，这张网越密。

改一处，别弄坏十处

还有个更省心的好处，叫回归测试——「回归」意思是「你别给我倒退回去」。软件有个反直觉的坑：你改 A 处，可能悄悄把八竿子打不着的 B 处弄坏了，而且当场一点声都不出。等你三周后发现 B 坏了，早忘了是那次改 A 干的。

但真正的考场，不在你电脑上

这是本章最想让你记住的一句话。你电脑上、你办公室那台样机上的所有测试，都只是模拟卷。工业产品真正的考场在现场——那条产线的光照会变、来料会脏、工人操作会花样百出、车间温度湿度粉尘全和你实验室不一样。在你桌上跑得漂漂亮亮，到现场露馅，是常态，不是意外。

所以最关键的问题变成了：怎么把新系统搬到现场,又不让它一上来就闯祸？

影子模式：先在旁边看，不许动手

答案叫影子模式（shadow mode）。名字很形象——让你的新系统像个影子一样,跟在现有流程旁边一起跑，只看、只判断、只记录，但不许动手。它说「这个不合格」，产线该怎么走还怎么走（还是老办法或老师傅说了算），它的判断只被默默记在一边。

然后你干一件事：把它记下来的判断，和现场真实结果（人工复检、老设备、老师傅）一条条比对。它说不合格的，真的不合格吗？它放过去的，真的没问题吗？

这招妙在哪——它把上线的风险降到几乎为零。因为在你攒够信心之前，它一次都没真正碰过产线。它判错一百次，也只是让你在报表上看到一百个错，一件产品都没被它误伤。你是在没有代价的情况下，看清了它到底几斤几两。等它跟着跑了足够久、比对下来一直靠谱，你再让它从「影子」转成「真身」，接管那个动作。

灰度：先上一条线，别铺满全厂

就算比对通过了，也别一激动就全厂铺开。用灰度——不是黑白一刀切上线，而是先放一小块「灰」的：先上一条线、一个班次，跑几天。

用数据判断，不用感觉判断

「我觉得还行」是验证里最危险的四个字。「还行」是多行？漏检率百分之一算行还是不算？你要是答不上来，就说明你根本没法判断它到底行不行——你只是在凭当天心情打分。

正确的顺序是倒过来的：上线之前，先把「怎么算成功」用数字定死。这就是第 3 章那个验收标准该还的债。比如：

• 真缺陷，必须抓住 99%（漏检率不超过 1%）——因为漏检的直接流到客户手里，最贵；
• 误报（把好的判成坏的）控制在 5% 以内——误报太多，工人烦到直接把系统关了，那就等于白做；
• 每个零件判定必须在 0.5 秒内出结果——慢了就跟不上产线节拍。

数字定死之后，影子模式攒的那批真实数据就有用了：拿真数据去比对这几个数字，达标就是达标，不达标就是不达标，没有「感觉」插嘴的余地。让 AI 帮你把这些数据做成一个看板——每天的漏检、误报、耗时画成曲线，摆在眼前。你不用会做图，但你得知道自己要盯哪几个数。

闭环：现场的反馈，得能流回来

上线不是终点，是另一件事的起点。现场每天都在给你反馈——这批漏检了、那个总误报、工人抱怨某个角度它老看走眼。这些反馈如果只是变成一句抱怨、飘散在车间里，那它们就白疼了。

迭代闭环就是让这些反馈能流回来、变成改进的一条环路：

1. 现场发现问题（漏检、误报、工人吐槽某种情况）；
2. 把这些真实案例收集起来，变成新数据、或补进规格里的新条款；
3. 拿这些新料去改进系统；
4. 改完，再走一遍测试和影子模式验证——确认真改好了，也没弄坏别的。

然后回到第一步。这个环得一直转下去，不能转一圈就停。闭环不闭，一切归零——因为还有第 9 章提过的那个阴魂：数据漂移。现场是活的、会变的，来料换了供应商、车间换了灯、季节变了湿度，模型对着一个变了的世界，准头会慢慢退化。你今天验收合格的系统，半年后可能悄悄烂掉，而且没人告诉你。持续把现场的新情况喂回去，是让它别烂掉的唯一办法。

AI 能帮你什么，帮不了你什么

这一章从头到尾，AI 都在给你打下手，但有几件事它死活替不了你——认清这条线，你才不会把命交错人。

AI 能帮你的：把你指定的情况写成自动测试；搭现场数据看板；从成堆的现场日志里翻出规律（「一到下午三点误报就飙高」这种，人眼看一周看不出来，它一扫就出来）。这些又快又好，放心用。

AI 帮不了你的：它不知道你这个场景「多好才算够好」——漏检 1% 到底能不能接受，取决于你的产品、你的客户、这批货流出去要赔多少，这是业务判断，只有你懂。它更不能替你去现场蹲点——车间里那股「哪儿不太对劲」的味道，工人一个皱眉、一次悄悄绕过系统的操作，那些藏着真问题的活信号，得靠你一双腿走到线边上、一双眼睛盯着看，才捞得回来。