DALI 编址、模块标签、场景版本和控制箱交接不要混着验
把 DALI 回路规划、模块端口映射、分组场景回归、网关版本冻结和控制箱交接拆成五条线，避免一句“智能照明已调通”掩盖不同风险。
现场判断
施工知识
先确认工序边界、施工条件和交接面，再按本文步骤落到现场。
优先把本文对应的工序检查点、照片编号和交接条件写进当天记录。
- 施工部位与工序条件
- 班组交接与样板状态
- 照片编号与复查结论
检查清单
优先使用文章内配套清单；没有清单时可复制正文检查项。
读完直接接到现场动作
按本文内容匹配规范口径、资料模板、计算工具和材料条目，减少来回搜索。
可用模板
把检查结论落到表格、台账或记录。
对应计算器
涉及数量、坡度、损耗或工期时先统一口径。
智能照明最容易出现的假象，是“现场已经能控了，所以系统大概已经交得出去”。实际上，很多项目把下面五件完全不同的事混成一句“照明联调完成”：
- 这条 DALI 总线到底该挂谁、地址该怎么留
- 这个模块地址、这个端口、这一路灯到底是不是同一个对象
- 地址写进去以后，分组、场景和断电重启后到底稳不稳
- 这次网关下发的是哪一版，出了问题能不能退回稳定版本
- 运维接手时，到底知不知道现在谁在控、怎么控、测完怎么恢复
这五件事都和智能照明有关，也常常发生在同一轮调试和移交窗口里，所以最容易被一句“系统已调通”糊过去。真到出问题时，才会发现地址策略做了，模块映射没做；映射锁清了，场景矩阵没回归；场景调出来了，版本冻结没做；版本回退有了，控制箱交接却没人讲得清。
这篇不处理哪两件事
- 如果主要问题是
照明效果、电压降、回路负荷和箱内回路对应，先看 照度、照明负荷、压降和回路对应不要混着判。 - 如果主要问题是
可寻址照明网关下发结果本身是否一致，而不是版本冻结与回退边界，优先看 可寻址照明网关场景下载审核。
这篇只处理中间这五条 控制链与交接链边界。
第一层：DALI 回路规划与地址策略
这层回答的是：这条总线该挂谁、地址段怎么切、后面还留不留得出扩容空间。
它优先看 DALI 回路规划与地址策略复核。这条线是 编址前的结构设计，重点在回路切分、分区命名、地址预留和维护边界，不是把地址写进设备的执行动作。
如果这一步没做清，后面就很容易出现：
- 施工顺手把不同功能区硬塞进同一条总线
- 图纸分区、平台分区和现场口头叫法各不相同
- 当前设备数量刚好能跑，但后期一补点位就没余量
第二层：模块地址标签与端口回路映射
这层回答的是：你在软件里点到的那个地址，柜里到底是哪块模块、哪一路端口、哪片区域。
它优先看 照明控制模块地址标签与回路映射复核。这条线是 模块级对象确认，重点在物理槽位、软件地址、端口编号和受控对象名称能不能一一回指，不是分组逻辑，也不是网关版本。
这一步最常见的风险不是不会控，而是：
- 平台操作 A 区，现场动作却落在 B 区
- 换过模块、重编过地址后，旧标签还留在柜里
- 柜内只标模块名，不标端口号和受控回路
第三层：DALI 分组、场景矩阵与断电回归
这层回答的是：地址写进去以后，这套控制逻辑在真实场景和重启以后到底稳不稳。
它优先看 DALI 分组、场景矩阵与断电回归复核。这条线是 编址后的系统回归，重点在组逻辑、场景矩阵、高频场景调用和断电重启后的状态稳定性，不是编址前的规划，也不是版本冻结本身。
这一步最容易被误判的地方是：
- 地址逐点点亮都正常，就默认分组也一定没问题
- 只测全开全关，不测半亮、夜景、保洁或跨区联动场景
- 调试当天稳定，第二天断电重启后却出现串组或场景漂移
第四层：智能照明网关场景版本冻结与回退
这层回答的是：这次准备下发的是哪一版，旧版有没有冻结，异常时能不能按记录回退。
它优先看 智能照明网关场景版本冻结与回退复核。这条线是 版本级风险控制，重点在网关版本、场景包基线、旧版回退包和试点窗口，不是单次场景执行结果，更不是模块端口映射。
如果这一步混过去，最容易出现的情况是：
- 平台显示下载成功，但谁也说不清现场到底生效了哪一版
- 旧版只留了一张截图，没有可导入的回退包
- 首个网关已经异常，还继续往下一批整片推送
第五层：照明控制箱交接
这层回答的是：运维接手后知不知道这只控制箱现在控谁、当前是什么模式、测试完怎么恢复。
它优先看 照明控制箱交接不要只交钥匙和回路表。这条线是 控制权和控制状态交接，重点在本地面板、平台命名、手自动状态、时控或场景优先级，以及恢复路径，不是模块编址，不是版本冻结，也不是回路带电关系本身。
这一步最容易留下的坑是：
- 钥匙交了、回路表交了，但没人知道当前自动逻辑是否已经恢复
- 本地面板和平台命名不一致，接手人无法快速定位对象
- 调试期间长期靠手动强制维持效果，交接时却没清掉临时状态
为什么这五条线不能互相代替
- 地址策略清楚，不代表模块端口和现场对象已经对上。
- 模块映射锁清，不代表分组和场景矩阵在真实工况下就一定稳定。
- 场景调用正常，不代表当前网关版本就已经冻结、可回退。
- 版本回退包齐全，不代表控制箱交接后现场值守人员就知道怎么接管。
- 控制箱讲清了现在怎么控，也不代表前面的地址策略和模块映射没有历史错位。
一句话说，这五条线虽然都属于智能照明调试，但对应的是 规划、对象、逻辑、版本、接管 五种不同层级。
更稳的执行顺序
- 先做 DALI 回路规划与地址策略复核，把总线边界和命名口径锁清。
- 再做 照明控制模块地址标签与回路映射复核，确认地址、端口和受控对象一致。
- 然后做 DALI 分组、场景矩阵与断电回归复核，证明系统逻辑在真实工况和重启后稳定。
- 准备批量下载或移交前，再做 智能照明网关场景版本冻结与回退复核，把版本基线和回退窗口锁定。
- 最后用 照明控制箱交接不要只交钥匙和回路表 收口，让接手方明确控制范围、当前模式和恢复路径。
这个顺序的重点是：先把对象和结构锁清，再证明逻辑稳定，最后再做版本与接管收口。
资料链怎么分别挂
- 地址规划、分区和批量写入，主记录挂到 DALI 地址编程器批量调试记录。
- 场景下载、试点结果和版本回退，挂到 智能照明网关场景下发记录。
- 控制范围、模式状态和恢复结果，挂到 照明控制箱交接核验记录。
- 如果当前连命名、分区和图纸对象都还没统一，先用 图纸核对清单 把差异收口，再继续往后做。
一句话边界
DALI 规划解决“总线该怎么切”，模块映射解决“这个地址到底控谁”，场景回归解决“逻辑稳不稳”，版本冻结解决“这次下发的是哪一版、出错能不能退”，控制箱交接解决“后面的人知不知道怎么接”。都属于智能照明，但不能混成一句“已经调好了”。