AI 导入案例
「应用是能用的，只是通知已经好几年没有送达过。」——委托就是这样开始的。这是一款面向会员制 B2C 服务的 Android 应用。它在应用商店上架、也能正常启动，唯独通知推送不知从何时起一条都发不出去了。这次我们要处理的，是一个既没有开发者、也没有文档的「碰不得的移动应用」——在完全保留会员资产与签名密钥的前提下，用 AI 重新做了一遍。以下是记录。
最可怕的遗留系统，不是会崩溃的应用。
而是从不崩溃、却只有关键功能悄悄停摆的应用。
而是从不崩溃、却只有关键功能悄悄停摆的应用。
在「它还能用」之下，通知早在几年前就停了。
这个应用的真实结构，是在原生外壳中显示既有 Web 服务的WebView 封装＋推送通知。画面沿用既有 Web 资产，所以是活的。问题出在通知：发送机制依赖于上一代的推送基础设施，而当这套基础设施停止服务时，通道本身就消失了。数据库里只加了一个用于保存新方式令牌的字段，却从来没有写入过任何值——线路就这样断在半途，一直无人过问。
约 14,000注册设备（全体）
约 3,200Android 设备
2016 年既有签名密钥的签发年份
1 次所需的重新发布
所谓「碰不得」，八成其实是「怕重做」。
真正撞上的墙，与其说是代码难，不如说是「怕接不住」。尤其是 Android，一步走错就会变成既有用户无法更新的另一个应用。
通知的推送基础设施，连同世代一起消失了通信路径上一代的推送服务已经终止，发送方的通道不复存在。先把它搬到「现代的通道」上，一切从这里开始。
既没有开发者，也没有设计文档应用留下的只有旧源码。我们用 AI 代理读懂结构，把握住「外壳＋WebView＋通知」这一骨架之后再重新设计。不是从零开始，而是理解现物之后再重做，这就是推进方式。
签名密钥接不上，全体用户就无法更新应用在 Android 上，只有用同一把签名密钥签名的包才会作为「更新」送达。我们找出约十年前、2016 年签发的密钥并继承下来，确认证书指纹完全一致，从而确保它是以更新而非全新安装的方式发布。
注册 API 强制要求加密通信通信路径旧服务器的设置会拒绝明文连接，设备注册通不过的原因大多在此。我们没有靠关闭校验来绕开，而是把应用侧统一为以加密通信为前提来解决。
构建环境跟不上现行的商店要求应用旧的运行环境商店不予受理。我们把构建体系（构建工具、语言、运行环境）提升到最新，直到能够输出已签名的分发格式为止，重新整备完毕。
把「保留的」和「重做的」清清楚楚分开。
要做的并不是「全部换新」。能用的资产就原样用下去。拆开来看，是这样的。
| 项目 | 此前 | 重做之后 |
|---|---|---|
| 通知通道 | 上一代的推送基础设施 （已终止服务・无法发送） | 迁移到现行推送基础设施（FCM） |
| 应用外壳 | 世代较旧的原生实现 | 以最新的原生实现重新生成 |
| 画面（咨询内容） | 显示既有 Web 服务 | 原样延续（保留会员资产） |
| 签名密钥 | 2016 年签发 | 继承同一把密钥（作为更新发布） |
| 会员・设备数据 | 约 14,000 台设备已注册 | 原样接管 |
重构本身由 AI 代理一口气推进。重做后的应用在虚拟设备上完整跑通了获取通知令牌 → 注册到服务器 → 实际收到通知这一整套流程，确认往返成立。产物就是可以直接分发的已签名格式。
把「重做」和「重新发布」设计到最小。通知的恢复，其实只靠服务器侧的迁移就能点火，我们就是这样准备的。应用只需重新发布一次，之后不用碰设备就能把通知恢复到运营状态——「不反复请用户更新」这一点，会员越多的服务越受益。
被说成「不能用了」的应用，多数并非全损。只要抓住断掉的那一小段线路和必须继承的密钥，就能在保留现物的前提下回到现代的基础设施上。iOS 篇（实录⑦）会写占会员多数的另一个平台，以及两个系统共通的「不换旧服务器也把通知现代化」的做法。
※ 本文基于真实项目，在无法识别企业与服务的范围内做了一般化描述。数值为截至 2026 年 8 月实测所得的概数。所需周期与工作咨询内容因应用结构而异。