第1965篇：复杂业务系统的AI化策略——增量改造与平滑迁移的路径设计
第1965篇：复杂业务系统的AI化策略——增量改造与平滑迁移的路径设计
我参与过一次相当惨烈的"AI化改造"项目。
那是一个运行了七年的订单管理系统，核心逻辑大概有三十万行Java代码，文档基本没有，原始开发者早就离职了。管理层要求在这个系统上"引入AI能力"，给了六个月时间。
团队一开始的方案是大刀阔斧重写：用AI辅助生成新版本，然后做数据迁移。三个月后，新系统的基础功能实现了大概70%，但积累了大量在原系统里存在但没有被显式记录的业务规则——"特殊客户折扣逻辑"、"节假日价格调整"、"部分SKU的例外处理"……这些规则分散在几年的迭代历史里，没有任何人能说清楚全貌。
最终这个项目没有按时交付，被迫降级为"部分模块替换"，折腾了将近一年，真正有价值的AI功能反而很少。
这个教训让我认真思考：复杂业务系统的AI化，路径设计比技术选型更重要。
为什么"大爆炸式重写"在AI化项目里特别危险
"重写"在软件工程里本来就是高风险的。乔尔·斯波尔斯基的那篇名文《别再这样做了》（Things You Should Never Do）说得很清楚：你认为乱成一团的老代码里，其实隐藏着大量用血泪换来的隐性知识。
AI化项目让这个风险更高，因为：
AI本身就有不确定性。 你在新系统里引入了一个置信度92%的AI模块，加上重写本身的隐患，风险叠加在一起，出问题的概率不是加法，更接近乘法。
AI化的效果需要真实业务数据来验证。 在旧系统完全下线之前，AI模块没有经过生产流量的检验。你以为AI的决策是合理的，但可能在某些边缘场景下完全出乎意料，而这些边缘场景恰恰是业务最关注的。
团队的注意力被"重写"本身占满了，AI的价值反而没有时间打磨。 六个月时间，三个月花在重建基础功能，真正用在AI能力上的时间少得可怜。
正确的路径是什么？增量改造。
增量改造的核心原则：Strangler Fig模式
Strangler Fig（绞杀植物）模式是Martin Fowler提出的系统迁移策略。绞杀植物会从树的顶部长起，逐渐覆盖并替代原有的树，整个过程是渐进的，原来的树在被替代之前始终保持运转。
应用在AI化改造上：
- 不动原系统，在旁边建AI新功能层
- 用流量路由逐步把请求引导到新层
- 当某个模块的新层完全稳定后，才去掉对应的旧模块
整个系统从来没有一个"大切换"的时刻，始终都在运行。
关键是路由层和Feature Flags的设计，这是整个架构的核心控制点。
路径设计的四个阶段
对于一个复杂业务系统，我建议按以下四个阶段推进AI化改造：
阶段一：观察期（1-2个月）
目标：建立系统画像，找到AI化的正确切入点。
在这个阶段，你不写任何AI代码，只做一件事：深度理解现有系统的实际行为。
具体操作：
- 在关键业务节点加日志，记录输入输出
- 分析高频和低频路径，找出"热点业务逻辑"
- 识别哪些决策是规则明确的，哪些是模糊的、依赖经验的
- 收集业务人员对现有系统不满意的地方（这是AI可以改善的空间）
用一个Java示例来说明日志埋点的方式：
// 在关键决策节点埋点，收集AI化候选数据
@Aspect
@Component
public class BusinessDecisionLogger {
private final KafkaTemplate<String, String> kafkaTemplate;
@Around("@annotation(LogForAI)")
public Object logDecision(ProceedingJoinPoint pjp) throws Throwable {
String methodName = pjp.getSignature().getName();
Object[] args = pjp.getArgs();
long startTime = System.currentTimeMillis();
Object result = pjp.proceed();
long duration = System.currentTimeMillis() - startTime;
// 收集决策输入输出，为未来AI训练或规则提取做准备
DecisionLog log = DecisionLog.builder()
.method(methodName)
.inputHash(hashInputs(args)) // 不存原始数据，只存哈希
.inputFeatures(extractFeatures(args)) // 抽取特征，不含敏感信息
.outputCategory(categorizeOutput(result))
.durationMs(duration)
.timestamp(System.currentTimeMillis())
.build();
kafkaTemplate.send("business-decisions",
objectMapper.writeValueAsString(log));
return result;
}
}
// 标注注解，选择性地在目标方法上加
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface LogForAI {
String decisionType() default "";
}
// 使用示例：在需要观察的业务方法上标注
@Service
public class PricingService {
@LogForAI(decisionType = "pricing")
public BigDecimal calculatePrice(Order order, Customer customer) {
// 现有定价逻辑...
}
}观察期结束后，你应该能回答：
- 哪些决策逻辑是规则明确、可以用AI增强效率的？
- 哪些是模糊的、AI有提升空间的？
- 哪些是高风险的、不适合AI介入的？
阶段二：旁路期（2-3个月）
目标：在不影响主流程的情况下，验证AI模块的实际效果。
在这个阶段，AI模块以"影子模式"运行：所有请求仍然由原系统处理，但同时发送给AI模块，AI的输出只被记录，不对业务产生影响。
@Service
public class OrderRecommendationService {
private final LegacyRecommendationEngine legacyEngine;
private final AiRecommendationEngine aiEngine;
private final ShadowModeLogger shadowLogger;
public List<Product> recommend(User user, OrderContext context) {
// 主流程：永远执行旧引擎
List<Product> legacyResult = legacyEngine.recommend(user, context);
// 影子模式：异步执行AI引擎，只记录，不影响响应
if (shadowMode.isEnabled()) {
CompletableFuture.runAsync(() -> {
try {
List<Product> aiResult = aiEngine.recommend(user, context);
// 记录两个结果的差异，用于评估AI质量
shadowLogger.log(ShadowComparison.builder()
.userId(user.getId())
.legacyResultIds(extractIds(legacyResult))
.aiResultIds(extractIds(aiResult))
.contextHash(hashContext(context))
.timestamp(System.currentTimeMillis())
.build());
} catch (Exception e) {
// 影子模式的异常不应该影响主流程
log.warn("AI shadow mode error (non-critical): {}", e.getMessage());
}
});
}
return legacyResult;
}
}影子期的核心工作是对比分析：
- AI和旧系统的结果一致率是多少？
- 不一致的地方，AI是更好还是更差？
- 哪些场景AI明显更好（这是第一批切换的候选）？
- 哪些场景AI不稳定（这是最后切换或永远不切换的部分）？
这个阶段的数据是后续决策的基础，也是向管理层展示AI价值的证据。
阶段三：灰度期（2-4个月）
目标：用小比例真实流量验证AI模块，逐步扩大。
在有了影子期数据的支撑后，开始真正的切换。但不是全量切换，而是灰度：先1%，再5%，再20%，每一步都有明确的成功标准。
@Component
public class TrafficRouter {
private final FeatureFlagService featureFlags;
private final MetricsCollector metrics;
public RoutingDecision route(String userId, String featureName) {
// 从Feature Flag服务获取当前灰度比例
int aiTrafficPercent = featureFlags.getIntValue(
"ai_recommendation_traffic_percent", 0);
// 基于用户ID做稳定的分桶（同一用户总是在同一个桶里）
int userBucket = Math.abs(userId.hashCode()) % 100;
boolean useAi = userBucket < aiTrafficPercent;
// 记录路由决策，用于后续分析
metrics.record(RoutingMetric.builder()
.feature(featureName)
.userId(userId)
.userBucket(userBucket)
.routedToAi(useAi)
.aiTrafficPercent(aiTrafficPercent)
.build());
return useAi ? RoutingDecision.AI : RoutingDecision.LEGACY;
}
}
// 服务层使用
@Service
public class RecommendationFacade {
@Autowired private TrafficRouter router;
@Autowired private LegacyRecommendationEngine legacy;
@Autowired private AiRecommendationEngine ai;
public List<Product> recommend(String userId, OrderContext ctx) {
RoutingDecision decision = router.route(userId, "product_recommendation");
return switch (decision) {
case AI -> {
try {
yield ai.recommend(userId, ctx);
} catch (AiServiceException e) {
// AI异常时自动降级到旧引擎
metrics.incrementCounter("ai_fallback_count");
yield legacy.recommend(userId, ctx);
}
}
case LEGACY -> legacy.recommend(userId, ctx);
};
}
}灰度期的每次扩大都需要满足晋升标准：
- 核心业务指标（转化率、满意度、错误率）在AI路由下不低于legacy路由
- 系统稳定性指标（响应时间P99、错误率）在可接受范围内
- 没有出现影子期未发现的边缘问题
阶段四：清理期（1-2个月）
当某个模块的AI版本已经全量运行稳定一段时间，才做最后一步：移除旧代码。
这一步很多团队会无限推迟，因为"旧代码留着也没事，万一需要回滚呢"。但旧代码留着有成本：维护两套逻辑、代码复杂度上升、新人理解成本增加。
清理的前提是：AI版本已经稳定运行至少两个迭代周期，没有被触发过回滚。
一个容易被忽略的问题：AI化改造的测试策略
增量改造最大的难点不是代码写作，而是测试。
旧系统的行为是参照标准，你需要能够准确衡量AI系统的行为与旧系统的差异——哪些差异是"改进"，哪些是"退化"，哪些是"中性差异"。
这需要预先定义：
- 核心指标：业务上最重要的度量（通常是转化率、满意度分、错误率）
- 防守指标：不能退步的指标（通常是安全性、合规性）
- 探索性指标：你希望AI帮助改善但还不确定的方向
有了这三类指标的定义，才能对每一批灰度数据做出有依据的判断：这次放大灰度比例，还是暂停观察，还是回滚？
增量改造的本质是用时间换稳定性，它看起来比大爆炸慢，但它的风险成本低得多，而且每一步都有清晰的成功信号。在复杂业务系统里，慢即是快。