如何把遗留软件纳入 AI SDLC

每一场关于 AI 辅助开发的对话,最终都会撞上同一堵墙:“新应用当然没问题,可我们的业务跑在一个十二年历史的 Rails 单体和一套没人完全弄得懂的 Java 计费系统上。”这堵墙是真的——大多数 AI 开发工具假设一切从零开始——但团队从中得出的结论,即遗留系统必须等一次重写之后 AI 才帮得上忙,恰恰弄反了。遗留系统才是 AI 辅助工程回报最高的地方,因为维护负担、知识风险和积压清单真正住在那里。

把遗留系统纳入 AI SDLC,不是让模型把它重新生成一遍。而是让既有代码享有一个新 AI 应用同等的交付闭环:一个系统能可复现运行、智能体可以安全作业的环境;一张哪段代码属于哪个业务职能的地图;保护危险区域的政策;围绕不可改变行为的自动化测试基线;以及一条从变更到部署的受控路径。这个闭环一旦存在,AI 智能体就能在治理之下承担人最发怵的工作——依赖升级、bug 积压、小功能、文档——同时系统继续服务生产。

战略上的重新框定是:现代化不再是一个目的地(那场永远还差十八个月的大重写),而成为系统从今往后被维护方式的一种属性。进入闭环的系统随着每一次受治理的变更逐步变好。留在闭环之外的系统按时刻表衰败。

一个有用的心智模型:把遗留系统当作正在办理入院的病人,而不是待拆的大楼。入院意味着先观察——复现它、映射它、给它的行为建基线——再随着证据积累逐步加大治疗剂量。办入院不要求相信这个系统很好;只要求承认它在承重,而这恰恰是它配得上机器而非英雄主义的原因。下面的阶段就是那套入院流程,按顺序排列,风险前置在可逆的步骤上。

这种痛是结构性的,不是偶然的。弄懂系统的工程师已经离开或转岗,所以每次变更都从考古开始。测试覆盖薄弱或流于仪式,所以每次部署都是一次小小的壮举,所以部署越来越少,所以变更越攒越多,所以部署越来越险——经典的死亡循环。与此同时,业务需求的积压在增长,而有能力碰这个系统的人,把产能都花在维持它活着上,而不是改进它。这正是一个产能问题,而产能问题正是 AI 辅助工程要解决的——前提是存在让智能体安全作业的防护机制。

传统的逃生舱——大爆炸式重写——有一份每个 CIO 都熟悉的失败记录:多年的时间线、老系统在新系统脚下继续演化、最后那 20% 没有文档却在承重的行为吃掉大部分预算。重写失败,是因为它要求组织一次性理解整个系统,而那正是已经流失的知识。渐进式方法成功,是因为它每次只要求理解一个变更——而一次一个变更,恰恰是 AI 智能体加治理最擅长的粒度。

还有人才现实。没人想坐遗留系统的维护席,为它招聘一年比一年难。把系统包进 AI SDLC,能把那个席位从全职考古变成方向把握与审核——一个资深人士真的愿意接的角色。

积压清单本身就告诉你困住了多少价值。大多数老化系统背着多年的延期请求——小功能、集成需求、报表改动——每一项单独看都不值得冒部署的风险。这就是死亡循环残酷的算术:部署越危险,动手的门槛越高,队伍排得越长。打破循环——便宜、安全、受治理的变更——队伍就从一张负债清单变成一条价值管线,这也是为什么积压消化率是这类项目最有说服力的早期指标。

这套上道方案在 Ciao 上是一条一等路径,不是改装。自定义沙箱镜像把 AI 辅助工程包裹在 Rails、Java、Go、Python、Node 与多进程后端之上——框架的第二阶段直接成为平台能力。随后 Guardrails 负责映射与保护:它把代码映射进业务领域、检测高风险变更、应用简明英文政策、记录人工审核,并在每次合并背后留下审计轨迹,这正是遗留系统要求的治理先行姿态。QA 搭建并运行基线——确定性浏览器回放、自愈式测试、发布前的冒烟测试关卡、发布后的生产环境检查——Doctor 探测线上应用、DNS 与 CDN,在有东西行为不端时诊断根本原因。

对于项目组合而非单个系统,Conductor 用一个屏幕覆盖成百上千个项目,配有实时健康状况与受保护区域可见性,这正是一个滚动式现代化项目要由小团队管理时真正需要的。部署可以留在合规要求的任何地方:你自己的 AWS、Azure 或 GCP 账户、私有 VPC,或在另行约定条款下的本地环境。严肃的开发项目起价为每年 10,000 美元。与销售团队的对话要具体:带上一个老化系统和它的积压清单,为它界定第一阶段的样子。

在组织内部诚实地设定预期:头几周产出的是基础设施,不是功能——一个可复现的环境、一张业务领域地图、一条测试基线——对被许诺了 AI 速度的干系人来说,这可能显得进展缓慢。复利在之后开始:后续每一次变更都跑在同一条轨道上,第一百次受治理变更的成本只是第一次的零头。把这个形状提前讲清楚的项目留得住赞助人;对一个十二年历史的代码库许诺即时速度的项目,会把第三个月花在道歉上。