你不用会写代码，但你得看得懂图纸
你做过硬件。你不会亲手车一个零件，但你看得懂机械图纸——知道这是轴承、那是密封圈、这里为什么留一道公差。图纸不让你去当钳工，它让你在别人干活时，知道他干得对不对。
软件也有这样一张图纸。这一章不教你写代码——写代码交给 AI。这一章只给你那张图：让你知道 AI 交出来的东西里，哪块是哪块、各自管什么、少了哪块会出事。
没有这张图，你会遇到一个具体的麻烦：AI 跟你说「我把数据存好了」「接口调通了」「前端渲染没问题」，你完全没法判断这话是真是假、这样安排合不合理。你只能点头。而点头点错了，是要在现场付代价的。
程序和进程：菜谱，和正在炒的这盘菜
程序是写在硬盘上的一堆代码，静静躺着，什么也不干。就像一张菜谱——写着「热锅、下油、放葱花」，但纸上没有一粒葱花是熟的。
进程是这份菜谱被真正拿去炒了：锅在响、油在冒烟、这一盘菜正在被做出来。同一份菜谱可以同时炒三盘（三个进程），互不相干。你把程序跑起来，就产生了一个进程。
为什么要分清这俩？因为现场出问题时，你会听到两种完全不同的说法：
- 「代码没问题啊」——菜谱写得对。
- 「服务挂了 / 进程死了」——正在炒的那盘菜，锅翻了。
菜谱对，不代表菜正在炒。你的设备半夜没数据了，多半不是代码写错，而是那个进程悄悄停了——就像厨子走开了，菜谱还在墙上挂着，但没人炒。知道这个区别，你就会问出对的问题：「进程还活着吗？谁负责在它死掉时把它重新拉起来？」 这个问题，第十二章会专门讲。
内存和硬盘：手边的操作台，和后面的仓库
这是最容易吃亏、也最容易讲明白的一对。
内存是厨子手边的操作台：切一半的菜、刚打好的蛋、马上要用的调料，都摊在上面。拿取极快，但台面就那么大，而且——一断电，台面上的东西全没了。
硬盘是后面的仓库：米面粮油、封好的货，码在货架上。存取慢一些，但断电了、关机了，货还在那儿。
一句话记住：内存快但断电就空，硬盘慢但断电还在。 数据要想活过一次断电，就必须从操作台挪进仓库——这个动作叫「存下来」「落盘」「写进数据库」。没落盘的数据，跟没炒完的菜一样，跳闸那一刻就消失了。
这对工业设备是要命的。车间跳电是常事。如果你的检测结果只放在内存里、还没落盘，那这段时间的数据一断电就归零。所以你验收时该问的是：「数据多久落一次盘？万一这一秒断电，最多丢多少？」 AI 如果告诉你「都在内存里算，很快」，你要立刻警觉——快是快，但它没告诉你断电会丢。
前端和后端：管你看到的，和管背后算的
你打开一个设备的操作界面：有按钮、有实时曲线、有个红色的「急停」。这些你眼睛看得见、手点得着的东西，是前端——它只管「显示」和「接收你的操作」，也做点轻活（比如画曲线、检查你有没有把输入框填空），但真正的重活不在这儿。就像餐厅的服务员：给你菜单、记下你要什么、把菜端上来，也会提醒你「这道菜没写份数」，但他不炒菜。
真正炒菜的在后厨，你看不见——那是后端。它接住前端传来的请求，去调算法、读传感器、算缺陷、把结果存进仓库，再把答案递回前端显示。前端好看不好看是一回事，后端算得对不对是另一回事。
为什么非得分家？
因为这俩变的频率、跑的地方、要的本事，完全不一样。
- 变化频率不同：界面上按钮挪个位置、颜色改一改，天天可能改；背后的算法逻辑，改一次要重新验证一轮。混在一起，你动个按钮都提心吊胆。
- 跑的地方不同：前端可以跑在车间墙上那块触摸屏、或工程师的笔记本浏览器里；后端往往跑在现场那台工控机（车间里那台专门干活、皮实耐造的电脑）上，紧挨着设备和传感器。离得近，算得快、丢数据的风险小。
为什么你要在意这个分家？因为当界面卡住时，你得判断是「服务员没反应」还是「后厨罢工了」。前端白屏，可能后端好好的，只是没把菜端上来；也可能后厨真的停了。分不清这两者，你会把厨房的锅甩给服务员，白折腾。
数据库：有结构地码货的仓库
前面说硬盘是仓库，但仓库也分两种。一种是随手把货往地上一堆——文件，比如一张张图片、一个个日志文本，扔进去能找，但想问「上个月周三夜班、3 号工位、所有判为不合格的件」，你就得一件件翻，翻到天亮。
数据库是码得整整齐齐、贴好标签、上了货架的仓库。每条记录都有固定的格子：时间、工位、班次、结果、图片在哪。正因为码得有结构，你才能一句话就把「上月周三夜班 3 号工位的不合格件」全捞出来——快、准、不漏。
你不用管数据库长什么样、用哪种。你只要记住它存在的理由：让「事后能按条件快速查、能统计、能追溯」这件事成为可能。 工业设备最值钱的往往不是当下这一下检测，而是攒下来的数据能回头算良率、找规律、追责任。这些全靠数据库撑着。
所以当 AI 说「数据我存成一堆图片文件了」，你要多问一句：「那我以后想按工位、按时间段统计，查得动吗？」 堆在地上的货，和上了架的货，事后差的是天和地。
API：两块软件之间的点菜窗口
最后一个词，也是后面章节出现最多的。
API是两块软件之间说话的窗口，事先约好了「怎么问、怎么答」。就像后厨那个传菜窗口：服务员不能冲进后厨乱翻，他只能站在窗口，按固定格式喊——「一份 3 号桌、宫保鸡丁、不要辣」。后厨照单做好，从窗口递出「这是您的菜」。
关键在约定俩字。窗口两边不用认识彼此、不用知道对方内部怎么运作，只要都遵守同一套喊法就行。于是：
- 你的前端界面，通过 API 向后端「点单」：把这张图判一下。
- 你的后端，通过相机厂商给的 API 去「点」一张照片。
- 你甚至能通过 API 把检测结果递给工厂原有的 MES 系统，不用管它是哪年谁写的老古董。
API 的价值就是这个：让互不相识的两块软件也能协作，只要约定好点菜窗口的规矩。 你后面会反复听到「调用某某 API」——翻译过来就是「隔着窗口，按约好的格式，问它要个东西」。
为什么产品经理必须懂这个？因为你要对接的东西——相机、PLC、工厂的老系统——几乎都是通过 API 打交道。当 AI 说「这个相机没有开放 API」，你就该知道：这不是小麻烦，这是那个传菜窗口根本没开，你的软件没法正经跟它说话，得另想办法。这类坑，第七章会带你趟。
把这张图收进兜里
就这么六样，凑成你的图纸：
- 程序 vs 进程：菜谱，和正在炒的这盘菜。代码对，不等于服务活着。
- 内存 vs 硬盘：操作台断电就空，仓库断电还在。数据要落盘才算数。
- 前端 vs 后端：服务员管你看到点到的，后厨管背后算的存的。
- 数据库：上了架、贴了标签的仓库，事后才查得动、追得到。
- API：两块软件之间的点菜窗口，约好规矩就能协作。
你不用会炒菜。但从这一章起，当 AI 端出一盘东西，你至少能看出它用的是哪口锅、有没有把菜真存进仓库、传菜窗口开没开。看得懂图纸的人，才有资格说「这活儿干得对不对」。后面的章节，我们就拿着这张图，一间屋一间屋地走进去。