Google 金融工程团队在升级遗留数据层时选择了 Cloud Spanner。对于要求高吞吐和金融级准确性的生产服务，迁移期间不能停机，必须在历史数据回填和校验完成前，确保遗留数据存储与 Spanner 同时接收完全一致的写入。
双写迁移的工程瓶颈
团队将迁移拆分为三个阶段：历史数据回填、双写与双读实现，以及拦截 RPC 流量进行字节级一致性校验的自动化 API 验证。架构路径明确，但代码库中包含 30 多个数据访问对象（DAO），每个 DAO 都需要编写独立的 MutationConverter 类以映射领域模型与 Spanner 列、处理双写分支及回滚逻辑，并配备基于 FakeTimeSource 等测试替身的单元测试。
如果手动在每个 DAO 中重复这些高精度改动，预计需要数月时间。
标准化 MutationConverter 与无头自动化
为让自动化工具可靠生成代码，团队先将 DAO 重构模式标准化，把 Spanner 表名和列赋值从核心业务逻辑中剥离，封装进独立的 MutationConverter 接口。这一确定性契约使 AI 编码代理能够据此推理并生成代码。
交互式 IDE 聊天界面难以胜任跨代码库的系统性多文件更新。团队编写了编排脚本 migration_ui.py，以无头模式（-p）运行 Antigravity CLI，使其可直接嵌入 Shell 脚本、持续集成流水线和后台任务，无需人工终端交互。
具体流程包括：
- 提示词版本化：将处理时间戳序列化、可空性转换、Mutation 歧义和 FakeTimeSource 注入等 Spanner 边界情况的规则，编码为可复用的提示词模板，作为工程制品纳入版本控制。
- 批量执行与自动校验：编排脚本接收目标 DAO 名称，提取现有单写源码与 Schema，连同结构规范输入无头模式的 Antigravity，由其生成新的转换器、双写 DAO 及对应单元测试，随后运行
blaze test。若出现 Linter 错误或断言失败，错误日志会直接回传给 Antigravity 进行自修正。 - 无人值守执行：工程师可在下班前排队提交约 10 个 DAO，流水线在夜间完成生成、测试与校验，次日早晨产出可供人工审查的变更列表。
迁移成效
据该团队介绍，结合 Spanner 的分布式数据库能力与 Antigravity CLI 的无头自动化后，原本需要大量手工编码与测试的 DAO 双写迁移在极短时间内完成并通过审查。由于所有生成的 DAO 遵循同一套经过测试的 MutationConverter 模式并接受自动化单元测试，预发布环境保持了严格的数据一致性。工程师也得以将精力从样板代码重构转向数据建模、架构韧性与性能优化。
团队建议，在启动类似迁移前应先定义隔离新数据库 SDK 需求与既有业务逻辑的严格接口；当重构涉及三个以上文件时，应从交互式对话转向脚本化的无头工作流，并将 AI 生成环节直接接入构建与测试系统，使模型在开发者审查代码前自行修复编译和断言错误。