1. 赛题解读AIoT公共空间与设备调度平台到底在考什么这几年电子信息大类的竞赛里物联网方向几乎成了固定赛道但绝大多数团队第一反应还是“做个传感器环境监测”“搞个NB-IoT路灯控制”。不是说这些不行而是评委早就看腻了答辩时追问几句“你比别人强在哪”“这个方案落地要解决什么工程问题”很多人就答不上来。所以我看到《基于AIoT的公共空间与设备调度平台》这个赛题时第一感觉是出题人想筛掉那种只会上位机开发板点灯的车队。这个赛题有几个关键词值得先拆一拆AIoT不是单纯“物联网加个AI壳”而是在设备联网的基础上用数据驱动决策公共空间指的是会议室、图书馆自习区、实验室工位、园区展厅这种人流和设备交互频繁的场所设备调度则是核心动作比如智能灯控、空调温控、投影仪/教学屏的预约联动、充电桩分配、门禁权限管理。换句话说题目要求你做一个“能感知空间状态、能自动调配设备资源”的系统而不是一个只会定时开关灯的控制面板。逐字稿如果只是念PPT上的架构图十分钟就能讲完但评委想听到的是你发现公共空间存在什么问题你的平台用哪种方式解决这套方案在真实场景里能不能扛住并发和环境干扰。这三个问题贯穿整个答辩过程稿子的主线也应该围绕它们展开。还要提醒一点这类比赛不仅是技术赛更是表达赛。设备调度平台的技术含量再高如果逐字稿里全是术语堆砌评委听不进去分数照样上不去。我见过不少团队项目本身不错但讲的时候逻辑混乱一会儿说算法一会儿说硬件最后评委只能按“印象分”给成绩。所以逐字稿的好坏直接决定了技术落地转化率。从热词搜索情况看不少人把Esp32、物联网环境监测、阿里云物联网等话题和比赛混在一起搜其实方向有偏差。比赛要的是“完整解决方案能力”不是单点传感数据的采集。你可以用现成的模组快速搭建原型但讲解重点必须放在平台层和应用层放在调度策略和异常处理上。2. 系统整体架构从物理感知到决策执行的完整链路2.1 分四层设计而不是一个板子搞定所有事我看了很多学生的参赛方案最容易犯的毛病是把所有传感器接到一块开发板上然后把数据一个串口或者Wi-Fi全推给云平台。这种架构在现场演示时确实简单粗暴但真实场景里基本不可行原因是扩展性太差一旦某个传感器故障整个链路都要重启。更合理的方式是四层架构感知层、边缘接入层、平台调度层、应用交互层。感知层包括红外人体传感器、毫米波雷达、光照传感器、温湿度传感器、门磁/窗磁等负责采集空间占用情况与环境参数边缘接入层用小尺寸开发板比如ESP32-S3或STM32Wi-Fi模块做局部汇聚承担数据过滤和简单的边缘判断比如“空间是否有人”“设备是否在线”平台调度层负责统一设备管理、预约请求处理、算法决策和指令下发应用交互层给管理员和普通用户提供小程序或Web界面用来查看空间状态、提交使用预约、手动接管设备。这种分层最大的好处是职责单一。每一层出了问题都能快速定位不会出现“设备没响应不知道是传感器坏了还是网络断了还是平台卡了”的情况。答辩时被问到“系统稳定性怎么保证”这也是最好的回答锚点。2.2 设备接入为什么优先选MQTT而不是HTTP设备调度平台的核心能力之一是大量的在线设备需要实时上报心跳和数据同时平台要能快速下发控制指令。如果所有通信都走HTTP轮询设备多了以后压力很大而且HTTP是请求-响应模型服务器没法主动推指令给设备除非设备不停来问“有没有新指令”这种轮询在功耗和网络资源上都非常浪费。这个场景天然适合MQTT协议。它基于发布/订阅模型设备端只维护一条长连接通过主题区分消息类型。比如室内灯的开关指令可以发布到building/f1/room102/light/set状态上报走building/f1/room102/light/state设备和平台各自订阅自己关心的主题互不干扰。还有一个关键点是MQTT支持遗嘱消息设备异常掉线时Broker可以主动推送离线通知平台端就能及时把该设备标记为离线并在调度时跳过它。这一点在答辩时非常加分说明你真的考虑过设备掉线问题。移动端和平台后端之间的API接口可以继续用RESTful HTTP因为Web端和手机端的访问频率远低于设备消息频率请求-响应模式足够满足需求。也就是说异构通信是这里的核心设计理念设备走轻量长连接业务端走标准API两者通过调度中台做数据转换。2.3 调度中台的核心策略规则引擎加上动态修正很多参赛队的“智能调度”其实就是预先写死几个if-else条件例如“温度高于28度就开空调”。这种做法不是不对而是不够。公共空间的设备调度往往是多目标、多约束的比如会议室被预约了但一直没人进来设备要不要提前准备好空调按预约时间开了但会议提前结束又该怎么判定我建议在中台里设计一个轻量级的规则引擎把所有约束条件做成可配置规则再叠加一个动态修正模块。规则引擎负责处理明确的业务逻辑比如“预约时间段前15分钟自动开启投影仪”“空间内无人且湿度低于设定阈值时关闭加湿器”动态修正模块则接收边缘侧上报的实时数据判断是否有违反初始假设的情况例如“预约时间到了但有15分钟没检测到人则推迟设备启动”。这个架构在逐字稿里讲起来也非常有层次。你可以先说基础规则保证确定性再说动态修正提升智能化最后落到“调度平台不是取代人而是替人省掉重复性决策”。2.4 数据流设计一次完整的调度闭环长什么样让我用会议室场景把数据流理一遍这部分容易被旁人忽略。用户在小程序里预约了A房间下午2点到3点平台收到预约后生成一个“空间使用计划”下发到边缘网关下午1点45分边缘网关里判定预约即将开始便触发“预启动预检”流程向传感器节点发送状态查询确认房间是否空置、传感器是否在线、投影仪是否处于可接管状态1点50分平台自动开启门禁权限、启动投影仪待机同时把空调设为预约温度2点05分边缘侧人体传感器检测到有人进入上报真实占用事件平台将设备状态从“计划运行”切换为“实际运行”3点05分传感器连续10分钟未检测到人平台再次自动关闭投影、空调切换为节能模式并向用户发送“房间可能已无人使用设备已自动调整”的信息。这套闭环看起来不复杂但把感知、预测、执行、反馈四个环节全部串起来了。评委问到“你的平台调度逻辑能展开讲讲吗”时你能用一段完整的数据流回答比背几个算法名词强得多。3. 核心模块实操拆解与落地要点3.1 公共空间感知分清“检测到人”和“人正在使用”空间感知是整个平台的数据底座但这里的坑比想象中多。普通的红外热释电传感器对静态人体不敏感人坐在工位上不动几分钟后传感器就判断为“无人”容易造成设备误关。而毫米波雷达虽然能检测到微动比如呼吸引起的胸腔起伏、手部小幅移动但成本高、功耗也大不可能每个工位都装一个。我实测下来比较稳定的方案是“双传感器融合”门口区域安装红外热释电加门磁用来判断进出门事件工作区域使用带微动检测功能的毫米波雷达或者成本更低的方案是红外阵列传感器比如8x8热成像阵列通过像素级温差变化判断区域内是否有人存在。热成像阵列还有一个额外优势它能提供多区块的占用分布比如“会议室前排坐了3个人后排空着”这种粒度对空调和灯光的区域级调度很有价值。关于数据上报频率不能每100毫秒一次也不能5分钟一次。对空间占用状态这种变化不剧烈的数据1秒一次上报足够设备状态运行功率、温度等可以2到5秒一次环境数据照度、温湿度10秒一次完全够。太频繁的上报会快速消耗设备电量和网络资源太稀疏又会让调度反应迟钝。逐字稿里提到“我们对不同数据类型设计了差异化上报周期”短短一句话就能体现工程思维。3.2 设备接入层边缘网关是断网时的“最后防线”公共空间的设备调度依赖网络但网络不可能永远稳定。如果平台侧在网络中断时集控完全失效评委一句“断网了怎么办”就能让你不知所措。我的做法是在边缘网关里内置一套简化版的本地调度表它从平台同步未来3小时的预约计划和控制策略当检测到网络断连后网关自动切换到本地模式按照缓存的时间表执行控制并把异常状态记录在本地日志里。网络恢复后再把日志补传到平台平台根据补传数据修正状态。这样设计既保证了系统在极端情况下的可用性也让答辩多了一个亮点“我们考虑了弱网环境调度策略支持边缘降级运行。”不过要注意本地模式只能处理预设任务无法响应临时的人工指令所以网关界面必须提供本地手动控制按钮否则断网时管理员就成了“离线操作员”。3.3 算法部分优先级调度和冲突消解多设备调度最尴尬的情况是“抢资源”。比如同一时间有人预约了A会议室和B展厅但展厅的投影仪临时故障调度系统是否应该把A会议室的投影仪拆过去显然不行因为两个空间的需求是独立的。正确做法是建立设备与空间的绑定关系再引入优先级队列会议预约属于高优先级定时环境调节次之节能优化属于低优先级系统在资源冲突时按优先级顺序释放低优先级任务并通知相关用户。另外一个容易被忽视的点是设备状态机设计。每台设备至少有“离线、待机、运行、故障”四种状态调度指令只能在可允许的状态迁移下执行。比如投影仪正在运行中就不应该接受“关机重启”指令除非先执行“关闭”再执行“启动”。在代码里用枚举加状态转换表维护能避免很多并发指令带来的控制混乱。3.4 UI层管理员、普通用户、系统日志三个视角平台界面不能只有一个手机App至少要有三种视角。管理员视角负责设备列表、空间状态总览、手动接管、告警处理普通用户视角负责查看空闲空间、提交预约、接收设备联动消息日志视角要能回溯每一次调度动作的原因比如“2025-06-12 14:03:05 会议室A投影仪启动触发原因预约计划启动操作人系统”。日志系统特别重要因为比赛答辩时评委很可能会问“中间某个执行动作产生的依据是什么”没有日志你就只能凭记忆解释。日志做到什么程度呢每一次指令下发、每一次传感器状态跳变、每一次规则命中都要记录关键词和值。这些记录不一定要全部展示但评委问起来你能打开后台现场调取效果远比口头解释强得多。4. 比赛逐字稿参考从开场白到收尾的完整表述4.1 开场与背景引入部分的逐字稿示例这部分的目标是在30秒内让评委知道你要解决什么问题以及为什么这个问题值得解决。切忌一上来就讲技术细节评委还没进入语境。参考逐字稿如下“各位评委老师好我们是XX团队的成员。今天带来的项目是《基于AIoT的公共空间与设备调度平台》。先说一下我们的出发点我们在校园调研中发现很多公共空间的使用效率其实不高——会议室被预约了却空置两小时自习区明明没多少人空调和照明却全程开放另一方面设备管理的响应速度很慢管理员要接到报修电话才知道投影仪坏了。这些问题看似是小问题但累积起来能源浪费和资源冲突在大型园区里非常可观。所以我们做了一套平台用AIoT的方式去感知空间、调度设备让公共资源的使用从‘人工被动管理’变成‘数据主动运营’。”这里面“调研中发现”非常重要哪怕你的调研只是采访了宿管阿姨和图书馆管理员也要说得真实可信。评委非常看重需求是否真实存在而不是为了技术而技术。4.2 系统架构展示部分的逐字稿示例架构图页是逐字稿里最容易讲砸的一页很多人对着图念文字评委根本来不及看。你应该把架构图当成一个“路线图”只讲主干和关键链路。参考逐字稿如下“我们的平台整体分为四层。最底层是感知设备层包括空间占用传感器、环境传感器和受控设备它们通过无线方式接入边缘网关。边缘网关这层可能是评委比较陌生的部分我们特意加入了低功耗断网降级机制当云平台不可达时网关可以依靠本地策略继续执行已经预约的调度任务。再往上就是整个平台的核心调度中台它负责设备注册、状态管理、规则引擎和调度决策所有调度指令都由中台统一发出。最上面是应用层我们提供了小程序端和Web管理端面向用户和管理员两个角色。整个链路的核心逻辑可以概括为感知空间、预测需求、调度设备、反馈状态。”这里“感知空间、预测需求、调度设备、反馈状态”这16个字值得记下来这相当于全篇的归纳核心评委问到任何模块都可以往这条主线上挂。4.3 核心功能演示部分的逐字稿示例演示环节最怕“演示成功但讲得太平淡”。合理的做法是在操作演示之前先抛出一个待验证的问题再让操作去回答问题。参考逐字稿如下“接下来我针对‘自动调度’这个功能做一个现场演示。我现在在小程序端预约B202会议室时间是下午2点到3点。大家注意看电子大屏在我们点击确认预约的同时系统已经开始执行预启动流程。现在时间是1点48分屏幕显示B202房间的投影仪已经切换为待机预热状态空调设置为用户偏好的24度门禁权限也自动放开了。现在我们再模拟一种情况2点10分传感器连续10分钟没有检测到人员进入大家看屏幕系统并没有直接关闭设备而是自动将风机盘管切换为节能模式同时给预约人发送了一条确认消息询问是否取消预约。如果用户5分钟内不回复系统才会把设备转入关闭流程。这个设计是为了避免‘一刀切’式关闭设备导致用户体验下降。”演示时有一个小技巧说完“大家看屏幕”之后停顿两秒给评委一个注意力切换的时间。很多选手边操作边说话结果评委既没看清操作也没听清讲解。4.4 答辩环节高频问题应答参考这部分虽然不直接在逐字稿正文朗读但也应该提前写成逐字稿让同组队员能反复背熟。我把高频问题整理成表格式的应答模板高频答辩问题推荐应答思路逐字稿示例你这个平台和普通智能家居有什么区别强调多设备、跨空间、协同调度“智能家居是一户人家内部几个设备联动我们要处理的是一个区域里多波用户、多台设备、多个时间片的资源调度规模不同冲突消解逻辑也不同。”如果两个预约时间重叠怎么办说明优先级和冲突消解机制“我们会在预约提交时做时间片冲突检测同一空间同一时间段只允许一个有效预约如果遇到临时加塞我们会通知用户并提供附近可用空间的替代建议。”系统的识别准确率怎么保证从多传感器融合和运维数据修正讲“我们对不同传感器设置了不同的判定逻辑比如热释电主要用于进门事件热成像阵列用于区域占用度判断两种数据交叉比对后再生成空间状态。”别人能轻易复制你这套系统吗强调数据积累和场景调优的壁垒“硬件和代码可以模仿但我们积累了大量空间使用模式数据调度规则是经过多轮调优出来的比如不同场景下无人判定时间窗口设置都不一样这是核心竞争力。”答辩时还要注意遇到不会的问题不要硬编可以先复述问题确认理解再说“我们目前方案在这一点上的处理是……”这样即使回答得不够深入也不会显得完全没想过。5. 常见问题与现场排查实录5.1 设备频繁掉线状态显示忽上忽下比赛现场环境非常复杂场馆里几百个Wi-Fi热点挤在一起2.4G频段拥挤是必然的。实测中ESP32设备经常出现连接不稳定、心跳丢失的问题。我踩过这个坑后来在代码里给设备端加了“心跳超时重连指数退避”逻辑连续3次心跳无响应就主动断开重连重连时间间隔从1秒开始成倍增加最大到30秒。千万不要用固定间隔重连否则所有设备同时断网时重连风暴能把AP直接打垮。另一个排查思路是区分“网络断开”和“设备死机”。网络断开时设备会弹出重连日志设备死机时没有任何输出。所以演示前一定要检查串口日志如果设备已经跑飞光改网络参数没用。5.2 调度指令“抖动”设备反复开关造成振荡这种问题最典型的原因就是规则引擎的条件阈值设置太细。比如温度设定为26度传感器在25.8度和26.1度之间来回跳空调压缩机的制冷指令就会频繁启停。解决办法是给规则设置“滞回区间”温度上升到26.5度才开始制冷下降到25.5度才停止制冷中间2度区间保持当前状态不变。这个思路和恒温器的滞回控制是一回事看起来简单但能有效延长受控设备寿命。还有一种抖动来自多个规则同时命中。比如“按时自动开空调”和“无人自动关空调”在临界点同时触发导致空调开关指令接连下发。我们在调度中台里为每个空间加了“指令冷却时间”同一设备在30秒内只能执行完一条指令并更新状态后才能接受下一条指令从根本上防止指令风暴。5.3 演示现场“翻车”的紧急应对预案比赛答辩当天设备临时掉线、传感器被围观人群遮挡、触屏无法响应这些情况都可能出现。一定要准备一个“最低可行演示预案”换句话说如果系统全瘫了你要能打开截图录屏继续讲。我的习惯是提前录制两版视频一版是完整功能演示一版是3分钟的精华剪辑现场演示失败时直接说“为了节省时间我先播放一段我们提前录制的完整演示视频”然后切换到录屏继续讲解绝不冷场。另外现场演示时要有一个人专门盯着设备在线状态另一个人主讲不要所有事情都堆给主讲人。团队分工在答辩时也是评委观察的一个维度配合默契的队伍即使技术普通印象分也会更高。6. 备赛心得时间、分工和资源协调6.1 倒排期计划比技术方案更重要比赛准备周期通常只有几周很多团队把大量时间花在调通硬件上等硬件通了发现没时间写稿子、做PPT、录演示视频最后草草上场。我的建议是开赛第一周就把逐字稿初稿写出来哪怕技术还没完全实现稿子逻辑先跑通。之后硬件每稳定一个功能就往稿子里补一段对应的演示脚本这样到最后一周你已经有一份功能与稿子同步更新的成熟脚本了。比较合理的分工是2人负责硬件与边缘网关2人负责平台后端与算法1人负责前端应用与UI设计所有人轮流参与讲稿校对。注意最后一位上台主讲的成员至少要在正式比赛前完整朗读三遍逐字稿每遍都录音然后回听找问题。听录音你会发现很多自己平时讲话时注意不到的“嗯、啊、然后”这些语气词被放大器放到评委耳朵里非常影响专业感。6.2 比赛评分的隐性维度除了技术完成度、创新性和表达能力之外评委还会关注能源消耗、成本可控制性和社会价值。逐字稿里如果能算一笔经济账会特别加分“以某园区100间会议室为例通过平台调度后空调平均运行时长下降了约30%照明能耗下降约20%预计一年可节省电费XX万元”。抱出一个可信的数字哪怕是估算值评委也会认为你想过商业化落地。成本也是重要考察点。不要把所有设备都用最高配逐字稿里可以说“单间会议室改造成本控制在800元以内核心传感器选用低成本模组通过算法弥补硬件性能差距”这会让方案看起来更有可行性。很多选手把成本说得很贵仿佛项目经费无上限结果评委一眼就看穿不实用。6.3 项目后续还能怎么延伸最后简单说点个人体会。这个项目如果后面还想继续扩展可以往这几个方向走一是加入更多类型的公共空间比如充电桩停车位调度、实验仪器共享预约把平台从“空间设备调度”扩展为“空间资源运营”二是结合历史使用数据用时间序列预测某个时段的空间占用热度提前调整设备策略三是把边缘网关升级成支持多协议的通用智能盒子兼容Modbus、Zigbee和蓝牙Mesh设备这样商业化空间会更大。每次比赛复盘我都会发现一个通用规律真正拉开差距的不是谁的硬件板子更贵而是谁把系统工程想得更完整。光是“调度平台”这三个字就足够拆出感知、通信、决策、执行、反馈五个课题每一个环节都值得打磨。希望这份逐字稿参考能帮你在场上多一份从容少一次卡壳。
