方案说明与演示范围
这是面向公开展示的独立产品推演。北京地铁 1、2、5、6、8 号线的线路与站点来自公开参考信息；资源、人员、设备、事件与响应时效均为虚构演示设计，不对应任何运营单位的真实状态或处置安排。
这不是一张地图，而是应急数据进入现场的共同入口
轨道交通的应急处置，最先面对的往往不是“缺少数据”，而是数据尚未被组织成现场可以使用的上下文。线路、车站、设备、物资、人员、视频、预案和工单各自存在；一旦需要处置，调度人员仍然要先靠电话、群消息和经验把它们重新拼起来。
这个 Demo 的核心判断是：以线路和站点作为共同入口。选中站点后，相关的人员、救援点、物资、预警、事项和现场反馈都围绕同一个位置出现；使用者不必先判断应该进入哪个系统。
解决方案思路
1. 先把静态资源放到可查询、可定位的空间关系中
左侧图层将线网、车站、驻地、救援点、物资、人员家庭位置、线路高程、联络通道和区间视频分别管理。点击一个站点，可以进入救援信息、应急物资和周边应急人员三个入口。
这里强调的不是“地图上多一个点”，而是同一个站点可以成为不同数据表的关联键：人员和工班能被定位，物资能被查到库存与存放点，救援点能展示专业、在岗情况和预计到达时间。公开版里的资源、人员、时效和地址均为虚构演示数据。
2. 预警不是直接派工，而是先进入可追溯的研判
页面顶部的“告警”入口会打开研判弹窗。告警带着发生位置、当前描述、可查看的视频入口和研判建议进入流程。处置人员可将它转化为三种不同业务对象：
- 故障工单：适用于已经明确的设备、设施异常；
- 运营预警：风险尚未形成事件，但需要组织巡查、值守和资源准备；
- 应急响应：现场确认后，需要按响应等级组织跨专业处置。
这一层的目的，是避免“监测告警、人工报告、事件工单”并列堆在一张清单里。每一个判断都留下来源和后续去向，既保留人工决策，也让数据能够继续流动。
3. 所有事件都进入同一套三步处置流
无论从站点卡片、告警研判还是“新增处置”进入，都会走同一套三步流程：先确认事项信息和位置，再按专业与位置匹配工班、在岗人员和增派资源，最后核对并下发任务。
系统不替代调度决策，但会先给出可解释的推荐：基于事件位置和专业，在相关救援点中优先展示到达时间较短、且有人员可用的资源。调度人员可以调整专业、替换资源或增加人员，再确认下发。
4. 用一张事项卡把“任务、人员、物资、现场”重新连起来
每个故障、预警或应急响应都有独立事项卡。卡片中汇集概况、救援资源、任务状态、人员签收与到场、现场动态和会商入口。事项、任务、人员、设备保持稳定关联，切换地图、列表、移动端或会商窗口时，始终指向同一件事。
5. 现场闭环不止停在“已下发”
“移动端协同”模拟现场人员收到任务后的完整过程：锁屏提醒、查看任务、定位、确认到场、上传反馈、申请接入会商。桌面端可以看到任务是否签收、人员是否到场以及现场最新反馈；会商窗口支持邀请人员、通话、接入多路现场视频和查看事件上下文。
这让处置流不再断在“任务已派出”，而能回到调度台，持续支撑下一步判断。
建议的演示顺序
- 点击
军事博物馆，依次打开救援驻地、救援点和应急物资，观察静态资源如何按位置聚合。 - 点击顶部“告警”，查看告警如何经过研判转入故障、预警或应急三种流程。
- 点击“新增处置”或站点卡片中的“发起处置”，体验事项信息、匹配工班、确认下发三步流程。
- 打开“组织会商”和“移动端协同”，查看同一事项如何贯通调度、现场和视频会商。
- 在“基础配置”中查看线路、车站、场段和救援驻地范围如何由同一份基础数据维护。
公开边界
原始本地 Demo 中涉及的真实城市信息、救援范围、时效、签到、住址、内部附件、视频与登录机制均未进入公开版。北京五线的线路、站点及走向仅作公开参考；资源、人员、地址、事件、视频和响应时效均为演示设计，不对应任何运营单位的真实状态与处置安排。高程页面按北京 1 号线站序展示相对高程曲线，仅用于交互说明，不能用于工程判断。公开版保留的是业务结构、交互逻辑和产品判断。