外部行业实践 ·
支付宝落地双回路校验体系实现60万行巨石应用AI重构可验证交付
支付宝针对旗下生活缴费核心在线系统的跨语言重构需求，解决传统重构模式无法确认新老系统业务行为一致性的痛点，采用两套独立互验的工程流程，将重构核心目标从代码迁移调整为业务行为迁移，搭配行为建模、AI场景生成、路径核验、流量回放等技术，搭建起完整的AI重构验证交付体系，有效规避AI生成用例假覆盖、路径偏移等问题，支撑核心系统重构安全分阶段上线。
仅供行业学习与场景参考，不代表优秘交付、客户关系或效果承诺。
面临的问题
传统遗留巨石系统开展跨语言重构时，普遍依靠代码审核、补充测试用例、上线后观测的交付模式，仅能排查出局部代码实现问题，无法证明新系统在预设业务边界内完全保留了老系统的核心业务行为，存在三类核心痛点：一是无法全面梳理老系统分散在代码分支、合作机构配置、外部接口交互里全部需要迁移的关键业务行为；二是即便代码审核通过、测试用例全量跑通、代码覆盖率达标，也无法证明对应业务分支真的被执行到，容易出现AI生成测试用例看起来覆盖实际未跑到的假覆盖、实际执行路径与预期不符的路径偏移问题；三是新老系统的运行结果差异没有分层判断标准，逐字段比对很容易被空值、时间戳这类非业务差异的噪音干扰，放宽比对规则又可能漏掉真实业务偏差，无法给上线发布提供可靠决策依据。同时重构过程还要平衡业务行为全覆盖与测试执行成本的矛盾、AI生成用例效率与路径真实性的冲突、离线验证可复现与线上真实场景还原的平衡等实操难题。
AI 落地做法
将重构的核心目标从「迁移原有代码」调整为「迁移核心业务行为」，搭建两套相互独立又可互相校验的流程机制，把测试场景生成和执行核验两个环节拆分开，明确AI仅参与场景的理解和生成环节，不参与验证环节，避免既当出题人又当阅卷人的自证问题。重构的交付成果不再只有新的系统代码，还新增了业务行为模型、可执行测试场景、实际路径执行证据、差异判定结论、上线发布与回退依据五类材料，形成从老系统业务行为提取、新系统场景回放核验、差异驱动代码修复、真实流量验证到分阶段切换流量的完整交付链路，通过分层的行为等价规则判断新老系统的差异，结合实际路径的执行证据识别假覆盖问题，保障重构全流程都可验证、上线决策可量化，大幅降低核心业务系统重构的上线风险。
实施路径
- 搭建双回路校验机制：第一套回路从老系统中识别各类业务终点，用PERS建模方式表达业务行为，通过Case-Forge路径压缩控制场景总规模，再由AI补全对应的业务数据、机构配置和模拟接口语义，生成可执行的验证场景；第二套回路给新系统输入完全一致的参数和依赖返回规则，运行对应场景，核验实际的执行链路，对比新老系统的业务输出和外部交互影响。
- 优化业务行为集合提取方法：通过PERS模型把前置触发条件、触发事件、业务输出结果、外部副作用整理成和开发语言无关的行为描述，Case-Forge按照不同业务终点整理候选执行路径，复用共享的分支判断条件，对仅影响局部结果的独立因素做增量展开，剔除存在约束冲突或者根本不可能到达的路径组合，在控制测试执行成本的前提下，给每一类关键业务终点都保留有代表性的可执行路径。
- 建立假覆盖识别和差异核验规则：把有效覆盖的判定标准从只检查用例断言通过，升级为同时确认目标业务终点触达、关键分支条件满足、必要接口调用发生、外部副作用符合预期，只有实际运行路径和目标路径完全匹配才计入有效覆盖；用Bubble工具分别在新老系统运行相同场景，按照触达业务终点一致、核心返回内容语义一致、关键业务副作用一致、重要输入输出交互可合理解释的分层规则判定行为一致性，对非业务差异、主动调整的变更
- 落地分阶段上线核验机制：离线场景核验全部通过后，先使用录制的线上真实流量回放验证真实请求的覆盖情况，再通过白名单用户放量、小比例流量切流、分阶段逐步提流的方式扩大上线范围，每个放量阶段都设置明确的观测指标和快速回退预案。
来源：InfoQ 中文（本站改写摘要，成效数据均取自原文）
项目背景
AI原生软件工程发展过程中，AI生成代码的能力已经逐步成熟，但AI生成代码的可验证、可发布工程体系仍不完善，大规模历史遗留系统用AI做重构缺少可落地的工程化交付方法，传统重构交付机制无法适配AI生成代码的验证需求，容易出现覆盖失真、差异无法判定等问题，可能给核心业务系统带来严重的上线风险，行业亟需可复用的大规模AI重构验证交付方案。 本案例依据「InfoQ 中文」公开发布的信息整理，原文：https://www.infoq.cn/article/06y8rRvgxgyBxOpr7L5r?utm_source=rss&utm_medium=article
业务问题
传统遗留巨石系统开展跨语言重构时，普遍依靠代码审核、补充测试用例、上线后观测的交付模式，仅能排查出局部代码实现问题，无法证明新系统在预设业务边界内完全保留了老系统的核心业务行为，存在三类核心痛点：一是无法全面梳理老系统分散在代码分支、合作机构配置、外部接口交互里全部需要迁移的关键业务行为；二是即便代码审核通过、测试用例全量跑通、代码覆盖率达标，也无法证明对应业务分支真的被执行到，容易出现AI生成测试用例看起来覆盖实际未跑到的假覆盖、实际执行路径与预期不符的路径偏移问题；三是新老系统的运行结果差异没有分层判断标准，逐字段比对很容易被空值、时间戳这类非业务差异的噪音干扰，放宽比对规则又可能漏掉真实业务偏差，无法给上线发布提供可靠决策依据。同时重构过程还要平衡业务行为全覆盖与测试执行成本的矛盾、AI生成用例效率与路径真实性的冲突、离线验证可复现与线上真实场景还原的平衡等实操难题。
实践方案
将重构的核心目标从「迁移原有代码」调整为「迁移核心业务行为」，搭建两套相互独立又可互相校验的流程机制，把测试场景生成和执行核验两个环节拆分开，明确AI仅参与场景的理解和生成环节，不参与验证环节，避免既当出题人又当阅卷人的自证问题。重构的交付成果不再只有新的系统代码，还新增了业务行为模型、可执行测试场景、实际路径执行证据、差异判定结论、上线发布与回退依据五类材料，形成从老系统业务行为提取、新系统场景回放核验、差异驱动代码修复、真实流量验证到分阶段切换流量的完整交付链路，通过分层的行为等价规则判断新老系统的差异，结合实际路径的执行证据识别假覆盖问题，保障重构全流程都可验证、上线决策可量化，大幅降低核心业务系统重构的上线风险。
原始来源：https://www.infoq.cn/article/06y8rRvgxgyBxOpr7L5r?utm_source=rss&utm_medium=article