前面五章你一路顺风：把想法写成规格，补了点计算机常识，然后用 AI 搭出了一个能点、能跑、能演示的原型。你大概已经有种错觉——剩下的无非是把这个 demo 做大一点。
这一章我要把这个错觉拆掉。不是泼冷水，是让你在掉进坑之前先看见坑在哪。因为工业设备和你熟悉的那种「网站 / App」，不是同一类东西的大小之分，而是两个物种。它们在三件根本的事情上，规则完全不一样。
一句话预告：demo 跑通，不等于产线跑住。demo 是「在我电脑上、在我盯着的时候，它对了一次」；产线跑住是「在没人管的车间里、连续三个月、每 0.5 秒一次、一次都不许出大错」。这两件事之间隔着一条鸿沟，这一章讲清楚这条鸿沟由什么构成。
一、网站活在网线里，设备活在物理世界里
你做过的所有软件，本质上都在一个干净、听话的世界里跑：数据从数据库来，从接口来，是别人已经整理好、喂到你嘴边的数字。你几乎从不需要问「这个数字是真的吗」。
工业设备不是。它的数据来自真实世界的传感器——一个测温度的探头、一个测振动的加速度计、一个拍零件的工业相机。而真实世界，是脏的。
- 相机镜头上会落一层粉尘，本来 99% 准的检测，脏了三天变成 80%——图像没变，世界变了。
- 车间夏天 45℃，传感器读数会漂移；冬天冷启动，前十分钟的数据全都偏。
- 旁边一台大功率电机一启动，电磁干扰让你的信号线上凭空冒出一堆毛刺，像有人往你的数据里撒了盐。
- 设备会老化。今天标定好的参数，跑半年，机械磨损了、皮带松了，同样的动作出来的数据慢慢就不是原来那个样子了。
还有一个绕不过去的角色，你迟早要跟它打交道——PLC。
PLC（可编程逻辑控制器），你就把它想成车间里那台专门指挥机器干活的工业电脑。你手机上装的是微信、抖音；PLC 上装的是「气缸伸出→夹紧→机械臂转 90 度→松开」这种一步一步的动作指令。工厂里几乎每一台会动的设备背后，都有一个 PLC 在发号施令。它皮实、简单、几十年不宕机，但它只懂自己那套工业语言，你想让它告诉你「现在第几号工位、传感器读数多少」，或者反过来让它听你的算法指挥，得专门去跟它「对话」。这件事有多难，第七章整章都在讲。
所以第一个根本不同是：网站的数据是别人喂给你的、干净的；设备的数据是你自己从物理世界里刨出来的、脏的、会变的。你的 demo 之所以好用，很可能只是因为你喂给它的那几张测试图，恰好是最干净、光照最好的那几张。
二、网站崩了刷新就好，产线崩了要死人
这是第二个、也是最需要你从骨子里改掉的习惯。
做软件的人对「出错」有一种天然的松弛：崩了？刷新一下。数据错了？改完重新提交。服务器挂了？重启，用户顶多骂两句。软件世界里，错误几乎都是可以撤销、可以重来的。
物理世界不能撤销。
- 你的算法误判了一次，机械臂多走了 5 毫米——一个价值上千的工件报废了，而且是已经报废了，没有 Ctrl+Z。
- 你的程序卡了两秒没响应——整条线停在那里，上下游几十道工序全部堵住，一分钟停产的损失可能是几万块。
- 最严重的：一个本该在人靠近时立刻停机的判断没执行，旁边站着一个工人。
请把这句话刻下来：在工业现场，安全永远是第一位的，比功能、比准确率、比工期都高。这不是口号，是设计原则。它意味着你做每一个判断时，都要先问一句「万一它错了，最坏会发生什么」，而不是「它多久能对」。
这带来一个反直觉的结论：一个会「安全地失败」的系统，比一个「大部分时候很准但偶尔疯一次」的系统，靠谱得多。宁可它拿不准的时候老老实实停下来报警、让人来看，也不能让它自信地做一个可能造成事故的动作。你在网站上追求的是「尽量别出错」；在产线上追求的是「出错的时候，错得安全」。这两种心态，做出来的东西完全不同。
后面第十二章讲「让它跑住」，一大半篇幅其实都在讲这件事：怎么让系统在硬件抽风、数据缺失、网络断了的时候，退到一个安全的状态，而不是随便乱来。
三、网站要「快」，设备要「准时」
第三个不同最微妙，很多人一辈子没绕明白：实时性。
你可能觉得实时就是「快」。不是。
实时不是「平均很快」，而是「保证在规定时间内，一定给出响应」。快，是偶尔慢一下没关系，平均值好看就行；准时，是一次都不许超时——超一次就出事。这俩是两码事。
打个比方。你刷网页，平时 0.1 秒打开，偶尔卡成 3 秒——你皱个眉，也就过去了。对网站来说，「99% 的请求很快」是一份漂亮的成绩单。
但工业设备的世界是这样的：一个零件在传送带上以固定速度经过相机，它只在这个位置停留 50 毫秒。你的系统必须在这 50 毫秒内拍照、判断、并且告诉后面的气缸「这个是次品，吹掉它」。
- 你 99% 的时候只用 20 毫秒，很好。
- 但有那么 1%，因为你的程序正好在清理内存、或者被别的任务抢了资源，这一次用了 120 毫秒。
- 零件早就过去了。次品混进了良品堆里；或者更糟，气缸晚动作 100 毫秒，一巴掌拍在了下一个好零件上，甚至撞上了机械臂。
看明白了吗？在实时系统里，「平均很快」是没有意义的，「最坏情况有多慢」才是唯一重要的数字。晚 100 毫秒，在网站上是一次卡顿，在产线上就是一个废件、一次撞机。
而这恰恰是普通电脑、普通操作系统不擅长的事（跟你用什么编程语言关系不大——真正偷停你的是操作系统）。你的笔记本能流畅剪视频，是因为它擅长「平均快」——它会在你看不见的地方偷偷停下来收拾垃圾、更新后台、临时去忙别的进程。这些「偷偷停一下」，在剪视频时你根本察觉不到，在产线上却是致命的。让机器做到「每一次都准时」，需要专门的硬件和专门的做法，这就是第十一章「部署到边缘」要解决的核心问题之一。
把三条鸿沟连起来看
现在回头看你那个跑通的 demo。它之所以顺利，是因为它同时享受了三份「豁免」：
- 数据是干净的——你喂的是精挑细选的测试样本，没有粉尘、没有电磁干扰、没有老化。
- 出错是免费的——它判断错了，你笑一笑改一改，没有工件报废、没有人受伤。
- 时间是宽松的——它慢个一两秒，你等得起，没有零件在传送带上等不及。
产线，把这三份豁免全部收回。这就是「demo 跑通」和「产线跑住」之间那道鸿沟的全部内容：脏的物理世界、不可撤销的后果、不许超时的节拍。你后面遇到的几乎每一个「为什么这么麻烦」，都能追溯到这三条里的某一条。
我不是要吓你。恰恰相反——知道难在哪，本身就是最大的省事。大多数人不是被难度打败的，是被「意外」打败的：以为翻过一座小土坡，结果脚下是悬崖。你现在提前看清了这道鸿沟由哪三块石头砌成，接下来的章节，就是一块一块教你怎么过：第七章教你怎么把脏的、真实的数据从传感器和 PLC 里正确地读进来（物理约束）；第十一、十二章教你怎么让它在没人管的车间里，安全地、准时地、连续几个月不出岔子（后果与实时）。
从这一章开始，你不再是在搭一个能点的东西。你在造一台要对真实世界负责的机器。心态换过来，路就对了。