产业观察｜观澜编辑部

企业AI的成果，正在从“生成了多少代码”走向“完成了什么工程工作”。运动品牌On与Google Cloud十月八日公布一项云迁移案例：双方称，On利用AI代理迁移了二十四项核心服务，并把单项服务的迁移时间从三个月缩短到两周。其中十五项迁移由内部工程师自行完成，单项服务计划内切换停机时间低于五分钟。这些数据来自合作双方的公告，是特定项目的结果，并非适用于所有企业的通用承诺。

按照Google Cloud发布的案例说明，代理承担代码库分析、配置生成和测试验证等步骤；工程师复核生成代码、执行基础设施变更，并批准生产切换。项目的重点因此不仅是自动化速度，还包括哪些工作可以交给代理，哪些决定仍需要了解业务的人作出。

迁移项目适合拆分，也容易隐藏风险

云迁移中有大量可以重复执行的工作：识别依赖、整理配置、比较环境和检查服务状态。这类任务若有清楚的输入与验收条件，代理就能承担部分执行压力。但复杂系统也存在文档没有记录的连接、历史例外和业务约束。配置看起来一致，不能说明切换后所有用户体验都一致。

我们认为，这个案例可借鉴的地方，是把执行与最终放行分成不同职责。团队可以让代理快速生成候选方案，再通过测试和人工检查判断是否能进入生产。速度提升应在完整周期中衡量，包括失败重试、审核、数据核对和切换后的观察，而不只计算生成配置的时间。

外部报价不等于已经实现的节省

同样，企业评估此类项目时，不能把避免采购外部服务直接等同于净收益。内部工程师投入、模型调用、云资源、培训和后续维护，都会进入真实账单。较好的比较方式，是在相同服务范围与可靠性目标下核算总投入，并说明原有项目计划与实际工作量的差别。

On的公告为AI参与基础设施工作提供了一个具体观察点。它能否形成可复用的方法，还要看其他系统上的迁移结果，以及上线后运行是否稳定。对于工程团队，AI的价值可能体现在减少机械整理，把人的时间留给架构判断、故障处理和业务责任；这需要能被复核的工作流程来支持。