上周三的机械系统集成实训课，我刚把投影上的系统架构图打开，底下坐第一排的男生直接抬手指着屏幕喊：“老师这跟我们去汽配厂参观时看到的AGV调度，到底差在哪啊？”
我当时顿了两秒。
之前的三版教案里，根本没准备这个问题的答案。说不尴尬是假的。
先拆碎：别上来就讲算法
最早的教案设计，是第一节课就把遗传算法、任务分配优先级、路径规划的数学模型全摆出来，PPT翻了二十页，台下的眼神从好奇慢慢变成放空。我后来翻学生的课堂笔记，大半人把“最短路径”四个字抄了三遍，根本没搞懂，这个最短路径是算给谁的。
这学期改了思路，第一节课直接把所有代码示例全收起来。
先让每组学生拿个带滚轮的料车，在实训车间的通道里走三圈，数清楚哪条通道堆了备用工具箱，哪段拐角的宽度只够单台车过，哪两个工位之间的物料转运需求一天能有二十次。上次有个组上来就把仿真模型里的通道宽度设成了两米，实际跑实体AGV的时候，直接卡在拐角的料架边上，卡了三次。全组人蹲在地上笑，我站在旁边也笑，转头就把这个场景记进了教学日志——学生总把系统当纯软件，忘了这是机械结构、传感识别、调度逻辑三者耦合的整体，任何一个参数脱离了实际场景，都是没用的数字。
卡壳的地方，才是要教的核心
上两周的方案设计环节，我见过太多看起来“完美”的调度方案。
路径是最短的。
响应速度是最快的。
结果模拟跑起来全是问题。有个组把所有转运任务的优先级设成了统一值，仿真界面上，装配工位的待料灯亮了二十分钟没反应，旁边质检工位的空AGV来来回回跑了八趟，全是无效空驶。我当时盯着屏幕真的有点想敲黑板——不是他们的代码写错了，是他们从来没站在真实车间的角度想过，什么叫“真的需要转运”。说白了，调度不是算最快，是算最顺。
之前我总觉得，要把最前沿的技术讲给学生听，什么多智能体协同、什么大模型动态调度，后来发现根本不是。刚接触这个方向的学生，连最基本的调度常识都没建立：单向通行的通道就别安排对向会车，永远要留一台满电的AGV在装配工位旁边的待命区，别把所有车都派去跑最远的仓储任务。这些东西课本上根本不会写，都是之前去合作工厂跟现场工程师蹲在通道边攒的干货。
说实话，这些内容讲出来一点都不“高端”，但学生听完再去调参数的时候，仿真里的无效空驶率直接降了一半。
别追求“完美系统”，要留够试错的空间
去年带学生参赛，有个组把系统精度磨到了毫米级，却答不出“通道掉扳手了怎么办”的问题。我当时在旁边听着，真的觉得可惜。他们花了三个月磨精度，根本没给系统留故障冗余的设计。
这学期我把实训课的评分标准全改了。不再看谁的系统跑得多快、定位多准，专门拿三分之一的分数考故障应对：通道临时被堵怎么办、AGV跑到一半低电量怎么办、工位突然加了紧急转运任务怎么办。上次有个组，没花精力去磨那个毫米级的精度，反而给调度逻辑加了条简单规则：只要通道传感器识别到障碍物停留超过十秒，就自动把最近的待派任务转给待命区的AGV，哪怕新的路径比原来长两米，也比卡在原地堵了整条通道强。
我现在越来越觉得，那些之前我觉得太细碎、上不了台面的车间常识，其实才是学生理解整套系统逻辑的起点，比背十页算法公式有用得多。
上周收的实训报告里，有个学生写：“原来调度系统不是写几行代码就能跑的，要先摸清楚车间的每一条路。”
我看到这句话的时候，比看到满页公式推导的满分报告还开心。
这学期的课还剩八周，我准备下周把工厂里真实的堵点案例搬进来——就是去年汽配厂那条因为AGV对向会车堵了二十分钟的通道，让他们自己拆问题，自己调参数。
