这句话出自 MIT Technology Review 旗下 Business Lab 播客 2026年9月1日的一期节目，由该刊 Insights 部门特约编辑 Megan Tatum 主持，另一位嘉宾是 Infosys 高级副总裁、负责澳大利亚、新西兰及东南亚地区金融保险、医疗与公共部门业务的 Sanjeev Tripathi。两人讨论的核心，是一次把 AI 真正用在遗留系统改造上的项目。

逼上门的技术债

Bupa 在亚太地区服务约700万客户，旗下的 My Bupa 移动应用建立在微软的 Xamarin 跨平台框架之上。而微软对 Xamarin 的支持已于2024年终止。

对一款承担投保查询、理赔办理等关键流程的应用来说，框架停止维护带来的不只是技术风险，还有实实在在的体验损耗。Sherazi 的表述很具体：「一次登录失败不是技术事件，而是一个想查看自己保障范围却没能查到的人。」

这也是她拒绝把延长支持当作解决方案的原因：「延长支持买到的是时间，不是未来。」最终的决定是重写——迁移到原生的 Swift 与 Kotlin。

AI 究竟做了什么

Tripathi 的判断是：「AI 的出现正在从根本上改变现代化改造的经济账。」在这个项目里，AI 的作用集中在三个环节，而且都不是替代人，而是压缩人力最不划算的那部分投入。

第一是代码理解与逆向工程。Infosys 团队用 AI 辅助的方式，从存量 Xamarin 代码中提取业务流程、规则与逻辑，直接生成可用于原生开发的用户故事和验收标准。以往这一步高度依赖业务分析师逐行读代码、访谈业务方。

第二是文档化。AI 驱动的发现与文档生成，节省了约400小时的人工业务分析工作量，并把接近1500个回归测试场景映射到了原生开发的需求集上。这一步的隐性价值在于知识转移：原本散落在少数老员工头脑里的系统知识，被沉淀成团队共享的资产。

第三是测试。团队用 AI 做缺陷分类与预测性缺陷分析，跑了近1400个案例，把测试资源集中投向高风险路径；同时用 AI 驱动的无障碍测试做大规模系统化验证。结果是上线时零安全类与高危级别缺陷。

综合起来，AI 辅助让交付周期相比没有 AI 的时代缩短了约60%。内部最初的估算是18个月，实际交付用了7个月。

数字之外的变化

新版应用上线后的指标变化相当直接：应用评分从3.7升到4.7；用户感知到的崩溃率在安卓端下降近24个百分点，iOS 端下降8个百分点；安卓端每次访问的登录成功率回升至77%，接近翻倍；代码库体积减少30%，应用占用空间减少18%。

功能层面实现了100%的双平台同步发版，不再出现一端有、另一端等的情况。活跃客户中约90%已迁移到新版本，独立下载量接近180万次。此外，账单处理速度提升了4倍，代码提交到测试人员手中的时间压缩到约1小时；整体功能交付速度大约快了4倍。

Sherazi 认为，真正的变化发生在决策的问法上：「过去是，我们的平台能不能支持这件事？现在是，这件事对客户来说是不是正确的。」而对最终用户，她的期待反而克制：「他们会注意到的是，当他们需要我们的时候——往往是在一个焦虑的时刻——它就是能用。」

两条不该被忽略的边界

这次对话中最值得企业技术决策者留意的，是两位嘉宾对 AI 边界的一致态度。

Tripathi 明确划线：「AI 不能替代良好的工程实践，它让组织能够更快地执行这些实践。良好架构、扎实工程与清晰业务目标的重要性会继续存在。」在他的展望中，现代化平台会成为更智能的 AI 驱动生态的底座，「AI 不只是附加功能，而是从设计到运营都内建其中」，客户体验将变得更个性化、更具预测性。

Sherazi 补充的则是组织层面的心得，尤其是改造过程中充满不确定性的阶段：「领导层在那些时刻的工作，是吸收模糊性而不是传导焦虑，因为如果人们觉得可以安心地尽早报告坏消息，几乎没有什么问题是修不好的。」

她对整个项目的定义或许是最凝练的一句总结：「我们做现代化改造，是为了赢得做下一件事的资格，并且能以周为单位而不是以年为单位完成它。」