边开飞机边换引擎：大型系统改造中的可控验证实践

在大型系统改造项目中，代码生成只是交付的起点，真正阻塞进度的往往是验证环节。本次实践以“边开飞机边换引擎”项目为类比，探索在核心业务系统不停服的情况下，如何构建一套可控、隔离的验证环境。两个月的倒排计划内，需要完成大型登录系统的完整替换，同时日常需求开发不能中断。登录系统涉及正常登录、Token刷新、退出登录等主链路，以及Redis、数据库等基础设施依赖。尤其在Redis不可用、数据库异常等边界场景下，系统是否能正确降级，直接决定着迁移的成败。传统验证方式在公共环境和预发环境中都面临诸多限制，这促使团队思考新的验证范式。

公共环境服务于数百人的开发协作，主动停止Redis、断开数据库或修改关键配置都可能影响其他开发者的进度，因此Redis不可用、数据库故障等场景几乎无法验证。另一方面，即使开发者知道要验证什么，也常常被“环境起不来、依赖配不齐、没有权限动公共资源”卡在最后一公里。预发环境的验证路径同样偏长，一次变更通常需要先合入公共分支，再协调审批，等待云端构建镜像和流水线执行，从发起到可验证通常需要30分钟至1小时。对于仍在快速试错、需要频繁验证边界条件的系统改造来说，这个反馈周期过长，严重制约迭代效率。

公共环境与预发环境的双重困境

针对上述困境，团队采用AI+工具链的组合方案来解决验证卡点。核心思路是让AI不替代验证，而是润滑验证链路。AI不适合作为“自由执行命令的操作员”从零生成命令，更好的方式是将高频、关键且易错的操作固化为受约束的工作流。具体而言，通过Makefile固化镜像构建和推送流程，开发者或AI不需要记忆复杂的Docker构建参数，只需调用约定好的目标即可完成镜像构建、Tag生成和仓库推送。同时编写面向AI的Skill，让AI在明确约束下调用Makefile，辅助触发标准动作、读取构建结果，并在失败时分析日志和定位问题。这种“人先收敛、AI在约束内执行”的分工模式，既提高效率，又保证过程可复用、可审查。

AI与工具链的协同验证方案

镜像构建完成后，下一步是部署验证环境。如果直接要求每位开发者使用原生Kubernetes或完整TKE平台，需要理解Namespace、Deployment、Pod、Service、ConfigMap等大量概念，学习和排障成本很高。因此，团队基于已有的Docker、Helm和K8s资产，结合镜像仓库与AI快速搭建了轻量化管理平台。该平台通过前端页面提供镜像选择与版本管理、Workload部署和更新、Helm Chart部署、ConfigMap配置资源管理、多集群接入与资源查看等能力。架构上，平台本身部署在公共机器上，提供统一操作页面；实际的Workload、Pod、Service、ConfigMap以及Redis、DB等依赖资源，仍然部署在各自的开发环境中，并与其他开发者的环境保持隔离。这种架构将“平台入口统一”和“验证资源按人隔离”结合起来，开发者无需直接面对复杂的kubectl命令，即可完成从镜像部署到接口验证的基础测试闭环。

专用工具提升故障定位效率

除了环境验证，团队还构建了针对Token和Session问题的专用工具。在Token相关功能改造中，一旦某个接口返回401或403，排查成本很高：问题可能来自Token签发时缺少Claim，也可能来自接口自身的鉴权逻辑。Token重新签发工具可在受控测试环境中使用测试密钥，导入已有Token并按需修改Claim，再重新签发测试Token。这样，原本需要反复修改代码、构建部署、重新登录的多轮排查，收敛为一次控制变量验证。Session解密工具则解决了Cookie中加密Session无法直接查看的问题，研发人员可以快速查看会话内容，结合接口返回和日志定位问题。这两个工具都不追求通用性，而是聚焦当前项目中最耗时的排查路径，用可观察、可复现的事实替代猜测，直接缩短问题定位周期。

本次实践验证了一个核心观点：AI的价值不应只停留在“写代码”，在高风险系统改造中，真正决定交付速度的是能否快速、低成本地验证代码在真实依赖和异常条件下的行为。团队通过Makefile固化构建入口、轻量化K8s平台承接部署操作、专用工具缩短排查路径，将验证链路中的时间、人力和资源利用率转化为可观察的变化。这一经验可复用于后续服务改造、灰度验证和故障演练场景。