地震、洪水、台风发生后 72 小时是救援黄金期，但 responders 面对的第一个问题往往不是"没人救"，而是"不知道去哪救"：灾区路网与建筑底图缺失或过时，求助信息散落在微博、微信、短视频评论区，物资捐赠与需求错配（灾区缺水，收到的却是旧衣服）。学界把这称为危机信息学（crisis informatics）问题。
开源社区的两条主线分别回应这两个问题：
HOT 的激活机制已经流程化：灾害发生后评估数据缺口，在 Tasking Manager 上把灾区切成网格任务，志愿者领取任务按卫星影像描绘建筑与道路，经验绘图员做二级审核，成品通过 HDX 与直接 API 供 UNOSAT、红十字、无国界医生等机构使用。2025 年的公开记录包括 3 月缅甸地震、9 月阿富汗地震、10 月墨西哥洪水等多次激活。
| 事件 | 时间 | 众包响应 | 关键数字 |
|---|---|---|---|
| 海地地震 | 2010 | OSM 紧急绘图（HOT 起点） | 数周内完成灾区主要底图（定性） |
| 河南暴雨"救命文档" | 2021.7 | 腾讯文档自发接力 | 24h 250 万访问，更新至 660 版，3000+ 人获救助 |
| 土耳其-叙利亚地震 | 2023.2 | HOT 激活 + 本地 OSM 社区 | 大规模建筑绘图支持搜救与评估（定性） |
| 缅甸中部地震 | 2025.3 | HOT × 缅甸 OSM 社区（myOSM） | 2 天 12 万+ 建筑、2204 km 道路、500+ 志愿者 |
| 阿富汗地震 / 墨西哥洪水 | 2025.9 / 2025.10 | HOT 激活 | 进行中/近期记录（OSM Wiki 组织编辑日志） |
值得注意的是响应速度的结构变化：2010 年海地响应用了数周组织绘图，2025 年缅甸响应的产能高峰出现在 48 小时内——Tasking Manager 的任务切分、影像预取与验证流程把"动员成本"压缩了一个量级。这是软件与流程设计直接救命的最清晰证据。
2025 年 3 月缅甸中部强震后，HOT 与本地社区 myOSM 合作启动激活：500 多名志愿者在两天内绘制超过 12 万栋建筑和 2204 公里道路，直接支撑了人道机构的损伤评估与物资投放定位。模式要点：本地社区做地面真值校验 + 全球志愿者做产能 + 任务管理平台做质量门禁。对开发者的启示：这类系统最缺的不是绘图界面，而是影像预处理、任务推荐与验证排队等"让志愿者产能翻倍"的基础组件。
2021 年 7 月 19 日晚，河南籍研究生李睿（网名 Manto）创建腾讯文档《待救援人员信息》，将散落在微博、微信的求助信息汇总成表，志愿者接力核实、分类、更新。24 小时访问量突破 250 万次，7 月 22 日晚超过 650 万次，更新至第 660 版，据报道 3000 多人经此获得救助。它没有任何"技术含量"，却完成了危机信息系统最难的部分：去中心化的信任与分工。留给我们的问题同样清晰——下一次暴雨来临前，谁来把这份文档模板化、预置核验流程、对接救援队伍？国内尚无稳定的组织化答案。
工具版图速览：Tasking Manager（HOT 的任务分发平台，开源）；HDX / HXL（人道数据交换与人道数据交换标准）；Sahana Eden（物资、避难所、人员管理一体化的开源灾害管理系统）；Ushahidi（众包事件地图鼻祖，开源）；Missing Maps（HOT 与美国/英国红十字会、无国界医生 2014 年联合发起的"灾前预绘"计划，把高风险区域在灾前就画好）。共同特征：全部开放许可、可自部署、以"志愿者与机构协作流程"为中心而非以功能为中心。
个人开发者可做的：成为 HOT 技术志愿者（Tasking Manager、fAIr AI 辅助绘图等均为开源项目，issue 即入口）；做国内版的"协作文档应急模板包"——预置求助登记、物资供需、志愿者排班、寻人四个表单与联动规则，平时开源维护，灾时一键部署；为县域救援队做轻量微信小程序（离线优先、扫码上报）。
小团队可做的：卫星影像 + AI 建筑提取辅助制图（HOT 的 fAIr 方向证明需求真实，中国团队在遥感基础模型上有人才优势）；县域应急"一张图"系统，把 OSM 底图、物资产能、安置点、队伍位置装进一个低代码界面，卖给或捐给应急管理局与本地社会组织；无人机正射影像快速成图与变化检测管线。
差异化切入点：中文语境的危机信息核验（河南文档当年 80% 人力耗在核实信息真伪上，LLM + 多源交叉核验可显著降本）；"灾前预绘"的中国版——把西部地震高风险县（如川滇交界）的建筑底图在平时补齐，这是 Missing Maps 模式在中文圈几乎空白的复制机会。