应急指挥信息融合

1客户嘴上要的

「做一张应急指挥『一张图』大屏，所有数据都接进来，再加 AI 自动生成灾情报告。」

这是症状或现成方案，不一定是真问题。下面看两种做法。

2照字面做，会怎么烂

3好 FDE 的实际走法

共 14 周，分 5 个阶段。带三角标记的是这一步最容易踩的坑。

1. 1–2

   第 1–2 周找真问题（看值班室怎么报信息）

   • 跟应急管理局指挥中心的值班长、2 个值班员坐，复盘去年两次汛期的值班记录、快报和续报。发现真痛点：信息来源多（乡镇电话、部门报送、社会媒体、气象和水文数据），同一指标多个口径、多个时间点，值班员大量时间花在核对和汇总上，快报常常因为等核实而晚报。
   • 最危险的是另一件事：未核实的信息在转报中丢了「未核实」标记。乡镇电话里说「可能有人被困」，到了快报里变成「有人被困」，指挥长据此调派力量。
   • 真问题是「每条信息的来源、时间和核实状态在流转中丢失」，不是「数据不够多」。成功标准改成：「演练中首次快报的成稿时间从 50 分钟压到 20 分钟；报告里每个数字都标明来源、时间和是否核实。」
   • 踩坑别只在平时演示。应急系统要在演练中验证，平时好看没有意义。
2. 3–5

   第 3–5 周定范围 + 定口径

   • 砍范围：只做防汛一个灾种，只做 6 个核心指标（受灾人口、紧急转移安置人口、伤亡、交通中断、电力通信中断、水位雨量）。防汛由防汛抗旱指挥部统筹，其办公室多设在应急管理局，少数地方在水利局，先确认本地的牵头单位。
   • 每个指标以哪个单位为准，由防办主任签发一张口径表，作为值班规程附件。
   • 重点设计「核实状态」：每条信息分「已核实 / 待核实 / 已否定」三种状态，状态随信息一起流转，改状态必须记录核实人和核实方式（回电、现场图片、部门书面报送）。
   • 数据：气象、水文数据走数据共享平台接入，乡镇报送用现有的值班值守系统。不新建报送渠道，否则乡镇不会用。
   • 踩坑别新建一个让基层多填一遍的报送系统。基层报送压力最大，多一个渠道就多一个漏报源。
3. 6–9

   第 6–9 周原型 + evals

   • 做「信息汇总台」：每条信息自动归到指标、标来源和时间，同一指标出现冲突时标红并列出各方数字。快报草稿只使用已核实的数字，未核实的单独列为「待核实」。
   • evals：用去年两次汛期的原始值班记录回放，由值班长标注「当时应写进快报的内容」。要求关键信息遗漏为零，冲突识别率不低于 90%。
   • 部署：指挥信息系统在政务外网，模型私有化部署，并做断网情况下的降级方案（只做汇总，不做生成）。
   • 踩坑AI 生成的文字不能把「待核实」写成「已确认」。这条规则写进 evals，每次改模型都要跑。
4. 10–12

   第 10–12 周演练 + 并肩改

   • 参加一次桌面推演和一次实战演练。值班员反馈：「冲突标红很有用，但要能一键给报送单位打电话核实」——加上通讯录联动。
   • 演练后由指挥中心出一份评估，作为是否在汛期启用的依据。
5. 13–14

   第 13–14 周交接交接

   • 交给指挥中心的值班长做业务负责人，信息科做运维。值班长每年汛前组织一次回放测试，口径表随值班规程更新。
   • 周期长的原因：要等演练窗口和汛前检查。没有汛前回放测试，系统一年只用几次，真用时数据接口可能早就断了。

4这个案例教给你的可复用判断