具体来说，听障者依旧通过文字呼救，这些文字通过小程序等用户端，发送到腾讯应急开放平台上。平台会将它们转化成语音，帮助听障者拨打 120。120 接听或者回拨，也会通过语音识别转化成文字，反馈给呼救者。

「实现用户端多模态多方式报警急救，原本就是腾讯应急开放平台规划中的一环。」魏正平说。

今年 10 月，在北京腾讯总部大厦，董明昊第一次见到滕超。董明昊记得，他们聊得很投机，「只花了二十来分钟，就在无障碍呼救合作上达成一致。」

利用语音识别技术辅助呼救，依众也想过，「可是技术能力不够，很难实现」。但无障碍急救功能的上线和推广，需要对接到 120，这是依众的强项。成立这个基金会的公司叫远盟康健，他们为全国数十个城市的 120 急救中心开发了呼叫调度平台。

双方的合作，从一份 27 页的技术文档开始，里头详细梳理了此次合作中，腾讯应急开放平台会提供的技术支持。

「没想到腾讯会做这个事情。」袁本初说。作为远盟康健 120 急救系统的一位技术负责人，他参与到这次项目的用户端研发。

此前，他以为这只是一次急救小程序的共同开发。可看见那份标准化接口文档后，他意识到，自己将要开发的产品只是其中一个前端，作为听障群体急救信息的入口，嫁接到腾讯应急开放平台上。

为了提高呼救效率，呼救端产品加入了地理位置自动抓取、病症状况描述模版等功能｜腾讯应急开放平台

魏正平说，腾讯应急开放平台除了「公益」，还强调「开放」，是希望让多方以「开放连接」的模式接入进来，以此实现应急信息有效互通，资源高效匹配。

这样，无论接入方是苹果系统还是安卓的，是 App 还是小程序，都可根据应用端的需求和特点做适配开发。这极大提升了接入方的开发效率。

正如袁本初所说，他们只需要对腾讯应急平台的接口文档进行验证，看是否满足急救报警流程，再完善用户侧的急救交互，便能完成无障碍呼救用户端产品的开发。

双方此次合作开发的产品，微信小程序是听障者发送急救文字的入口。在文字和语音转化环节，调用了腾讯云的语音识别技术。

紧急呼救沟通可能涉及特定地名、病症名称。此外，语音识别还得做到精准断句。这样才能提升呼救信息的读取效率。

这些都对语音识别技术提出了很高的要求。而腾讯云的语音识别技术，经历了微信十亿级用户考验，具有超强的稳定性，完全能复用到这个平台上。

为进一步提升语音识别率，避免不同地域接线员的普通话问题，魏正平他们还加入了方言数据库。

听障者将呼救信息发送到腾讯应急平台后，平台便开始为其拨打 120。在魏正平看来，这是打通这条急救「生命线」最难啃的环节。

当下，120 急救存在一套明确的规范。其中一条是，120 只接听由运营商号码打进来的语音电话。

电话接通后，还必须满足两个条件：报警人可以准确说出关键信息；电话号码可被回拨。不满足任何一条，都会被调度员判定为废单。

「这就把我们难住了。」魏正平说。为了实现为听障者代打 120，平台首先要向通讯运营商申请一定数量的电话号码。

如果用固定电话拨打，必须使用 120 急救中心所在地的固定电话。也就是，固话区号必须为所在地的，否则 120 系统就会自动过滤掉，接线员接不到这通电话。

随着上线城市越来越多，应急平台需要给每个城市申请充足的固话资源。有的城市相对好申请，有的城市可能申请不到。每个地方的状况并不一样。

手机号倒是可以拨通全国的 120。但手机号的申请需要个人身份证实名认证，对于一个应急开放平台来说，要申请足够的手机号也很难。

「腾讯云的云服务里有网络电话功能。这次号码申请也是这边同事在帮忙。」魏正平说，「我们也在想方案提高号码的使用率。目前的策略是固话打底，全国再配合一组手机号码做流动。」

号码资源之外，另一个难题是保证电话能实现回拨。

在急救流程中，平台拨入 120 的号码是唯一标识。意思是，救护车司机只会通过回拨这个号码来联络呼救人。

所以，「平台的号码一定要跟这通呼救订单维持住，要保证通信链路的通畅。」魏正平说。要保持稳定性，这在技术上的挑战就很大。

更麻烦的环节还在用户侧。在急救的慌乱情况下，听障者容易产生误操作，比如退出小程序。这时候，呼救人就跟平台的联系断了，救护人员极有可能联络不到。

为了避免这种情况，他们在急救小程序内添加了明显提示，告知用户不要乱点或者退出。即便误操作了，也会发出一条短信，内含急救小程序链接。呼救者直接点击即可回到报警页面。

应急平台的开发跟互联网产品不同。互联网产品可以迭代，上线一个 demo 版，再逐步完善。但应急工具事关生命，交付时必须是最可靠的状态。

「我们在设计流程、研发系统的时候，考虑最多的问题就是，上线之后它怎么样能做到 100% 稳定。」魏正平说。

今年 11 月下旬，这个无障碍呼救系统的开发就基本完成了。让它真正嫁接到 120 急救体系，在实际救助的场景中发挥作用，成了需要翻越的下一座大山。

在原本的设计中，听障者通过腾讯应急平台呼叫 120，接线员接收电话后，会先听到一段语音合成的提示，大致内容为「这是一通听障者打来的呼救电话，是否同意接听」。

有接线员反馈，「我们每天接几百个电话，对这种机器声的电话，可能条件反射地认为是骚扰电话。」于是，语音提示变成了消息弹窗，直接在系统上通过文字告知接线员。

在原本的语音提示里，还有一个确认接听环节，必须要接线员说出「同意」二字，才能接通电话。

一个工作大厅，十几个接线员同时在处理紧急来电，环境嘈杂会影响语音识别率，可能接线员扯着嗓子喊了好几声「同意」才能最终认。于是，这个环节就改成了按键确认。

为了进一步保证回拨电话的稳定性，120 急救中心还建议添加紧急联系人。在联系不到救助者本人时，也可以通过紧急联系人，进行二次确认。

上线之前，腾讯应急开放平台、依众基金会联合数地 120 急救中心进行了密集的调试。

有次深夜，他们进行模拟测试，救助消息已经从应急平台发送到急救中心，可接线员那边却没接到电话。当地急救中心的主任很重视，半夜把技术人员叫醒，拉了一个群，分析呼救失败的原因。

距离正式上线不到 24 小时，为了保证首批落地城市使用的稳定性，他们决定再集中测试一次。多数城市都顺利接通了，但有几个城市却一直无法拨通。

确认系统运行状况，摸排流程，最后紧急通过腾讯云的同事联系上当地通讯运营商，才最终查出了原因。为此，他们一直弄到了深夜。

魏正平说：「在这几个城市拨打 120 后，当地运营商发现是网络电话，就把呼救过滤掉了，所以 120 那边接听不到。」

经过沟通，这个问题得到解决。事后，有同事评价「这是惊心动魄的一夜」。

今年 12 月 3 号，这天是国际残疾人日，包括北京、南京、武汉、南昌在内 24 个城市的 120 急救中心，终于成功接入了这个无障碍急救功能。

为什么要做社会应急？要解决什么？从做这件事的第一天，滕超就在思考这个问题。

有人会说，应急这个事情有什么好做的，使用频次这么低。也有人说，你们不就是做了某个场景下的解决方案么。

「最终，应急是为了提升社会的安全感，无论你是在家里还是在公共场合，都能够在需要帮助的时候便捷的发出请求，并得到响应。」腾超说。

腾超进一步解释：「因此，我们的底层解决方案需要有一定的普适性，能适应于各种场景。我们构建在上层的产品又需要把每个场景做透，从而实现更好的体验闭环。整个社会急救的网络应该是有层次的。先是你的家人朋友，然后是社区机构，以及无数的陌生志愿者」。

今年夏天，河南洪水，当时很多人受灾，也有很多人想要伸出援手。可真实情况却是，一度比较混乱，有的受灾人有网络，通过微博发了求救信号。很多人看到，一股脑冲过去。「这时候，虽然把人救了，但也浪费了极大的社会资源。」

还有很多人没有信息传递的途径，或者不知道通过什么路径求助。魏正平感慨，这就导致了一种急救资源的错配状态。

现有的急救体系，是否能有效满足全部急救需求，以及能否加入社会化的方法来优化这个体系。滕超表示，这是他们思考社会应急这件事的起点。

什么是社会化的方法？举个例子，从救助者拨打 120 到救护车抵达现场，这中间一般需要十五分钟。如果交通拥堵，可能得三十分钟。大部分人在这段时间里只能焦急等待，是急救的空窗期。但这个时间是可以充分被利用的。

比如，是否能调动救助地附近的志愿者，有医疗技能的可能先于医护人员抵达现场查看病情，熟悉当地路况的可以为救护者指引，减少找路花费的时间。

这是一个科技问题。科技能否做些什么，让这个体系运转的更好。「我们要发挥好连接人的能力，」滕超说，「同时，这也是一个社会问题。」

今年 4 月 19 日，腾讯发布了其公司历史上第四次战略升级，提出「可持续社会价值创新」战略，并宣布将为此首期投入 500 亿元。

对此，腾讯首席执行官马化腾在接受《南方周末》采访时提到，腾讯在教育、环保、医疗等诸多领域进行了公益方探索，「这不是一个部门花钱跑项目就能解决的，而要着眼长远，深入几个领域去做前期的积累。开始不追求回报，但要帮助它们形成可持续的发展模式。」

腾讯应急开放平台也是在这个思路下的尝试。实现无障碍呼救，这条为 2000 万听障者开辟的急救「生命线」，只是一个开始。