1. 为什么 KV 存储撑不住大规模流路由状态Datadog Stream Router 本质上是一个管理指标管道路由规则的 API 服务。它要回答的问题很朴素一条指标数据流进来应该被送到哪个下游管道。规则本身不复杂但规则的数量和它们之间的关联关系会随着业务膨胀。早期这套路由状态放在 KV 模型FoundationDB里走的是最终一致性路线写入快、扩展简单看起来是个合理选择。问题出在“关系”上。路由规则不是孤立的一堆键值对规则和管道、租户、标签之间存在大量外键式的引用关系。KV 存储不提供 join也不提供事务性的级联约束于是应用层只能自己把几万个条目拉到 Pod 进程内在内存里手搓关联逻辑。这种做法的代价在高负载时集中爆发一次涉及大量规则变更的操作需要数千次串行往返请求单次耗时最长能到 45 分钟。延迟从数百毫秒一路涨到秒级甚至更久存储占用也居高不下。更麻烦的是数据一致性。最终一致性意味着你在某个时刻读到的路由状态可能是旧的而路由错误会直接导致指标丢失或错投。团队不是没想过优化 KV 的访问模式但“手搓外键”这件事本身就是性能瓶颈的根源再怎么调优也只是缓解。所以结论很明确把关系型语义从应用层下沉到数据库层用 PostgreSQL 的外键、事务和查询优化器来接管这些逻辑。但全量重写风险太高Stream Router 承载的是生产流量不能停机。于是团队选择了一条渐进式路径保留原有 API 契约新增一个 PostgreSQL 后端实现用功能开关控制流量切换同时用 AI 辅助测试驱动的方式加速那些机械性的代码迁移工作。这篇文章面向的是正在或即将做类似存储层迁移的后端团队。我会把迁移配置骨架、连接池参数、schema 映射、回滚开关以及 AI 辅助重构的验证动作都拆开讲清楚。核心观点只有一句AI 能帮你搬代码但能不能信任它取决于你的测试套件有多完备。2. TaoToken 在 AI 辅助重构里的前置准备这次迁移里 AI 承担的角色很具体把旧 KV 模型下的接口实现逐个翻译成基于 PostgreSQL 的等价实现。它不是让你从零设计架构而是在你给定原始函数、新数据结构、预期行为之后生成初稿代码然后由失败测试用例来判定通过与否。这个流程要跑得顺前提是你能稳定、低成本地调用一个足够强的代码模型。我试过用 TaoToken 来做这层模型接入。它的定位是统一的模型 API 网关你拿到一个 API Key就能通过兼容 OpenAI 风格的接口调用包括 Claude 系列在内的多个模型。对于这种需要反复迭代、每次都要传入代码上下文和表结构的重构任务统一入口省去了在多个平台之间切换的麻烦。你需要准备三样东西Base URL、API Key、Model ID。Base URL 用https://taotoken.net/apiAPI Key 在控制台的 API Keys 页面创建Model ID 根据你选的模型填比如做代码重构我一般用 Claude 系列的模型 ID。这三件套在后面的配置片段里会反复出现先记牢。为什么不用本地跑模型因为这次重构的 token 消耗不小。AI 每次迭代都要吃进完整的测试输出日志、代码上下文和表结构累积起来量很大。本地硬件跑不动这个规模的上下文而按量付费的 API 在成本上比人工重写便宜又比自建推理集群省心。还有一个现实考量迁移过程中你需要频繁对比 AI 生成版本和人工优化版本的差异。统一 API 入口意味着你的脚本、CI 流程、对比工具都只需要对接一套认证和调用方式不用为每个模型单独写适配层。这在蓝绿部署阶段做持续对比校验时尤其重要。如果你只是做小项目的一次性重构可能直接手写更快。但像 Stream Router 这种模块化程度高、测试覆盖率有基础、又有蓝绿部署基础设施的系统AI 辅助的收益才真正显现出来。前置准备做到位后面的每一步才不会卡在环境问题上。3. 可复制的迁移配置骨架与 schema 映射这一节是整篇的核心我直接把可复制的配置片段给出来。你需要根据自己项目的实际路径和命名调整但结构可以照搬。先看 PostgreSQL 连接池配置。Stream Router 的迁移场景下连接池参数直接决定高负载时会不会把数据库打满。我用的是 pgx 连接池配置文件放在configs/postgres.yamlpostgres: host: ${PG_HOST} port: 5432 database: stream_router user: ${PG_USER} password: ${PG_PASSWORD} pool: max_conns: 40 min_conns: 8 max_conn_lifetime: 30m max_conn_idle_time: 5m health_check_period: 30s statement_cache: mode: prepare capacity: 512 migration: enabled: true rollback_switch: ROUTER_STORAGE_BACKEND rollback_value: kvrollback_switch这个环境变量是关键。它控制当前生效的存储后端是postgres还是kv。蓝绿部署时两个实例并排跑客户端流量通过这个开关切换。一旦 PostgreSQL 侧出现异常改回kv就能快速回退不需要重新部署。再看 schema 映射。旧 KV 模型里路由规则、管道、租户之间的关联是应用层手搓的现在要用外键表达。核心表结构如下CREATE TABLE pipelines ( id BIGSERIAL PRIMARY KEY, name TEXT NOT NULL UNIQUE, tenant_id BIGINT NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE routing_rules ( id BIGSERIAL PRIMARY KEY, pipeline_id BIGINT NOT NULL REFERENCES pipelines(id) ON DELETE CASCADE, match_expr JSONB NOT NULL, priority INT NOT NULL DEFAULT 0, enabled BOOLEAN NOT NULL DEFAULT true, updated_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE INDEX idx_rules_pipeline_priority ON routing_rules (pipeline_id, priority DESC) WHERE enabled true;ON DELETE CASCADE替代了旧代码里手动清理关联条目的逻辑。idx_rules_pipeline_priority这个部分索引针对的是“按管道查启用规则并按优先级排序”这个高频查询WHERE enabled true让索引只覆盖有效规则减少扫描量。AI 辅助重构时我会把旧函数的实现和新表结构一起喂给模型提示词里明确写出预期行为比如“给定 pipeline_id返回按 priority 降序排列的启用规则列表”。模型生成初稿后用一条失败测试用例去验证。不通过就调整提示词把失败信息精简后回传而不是把完整日志塞进去——完整日志会大幅推高 token 消耗。这里有个坑要提前说AI 生成的 SQL 经常能返回正确结果但会产生大量不必要的网络往返。比如它可能对每条规则单独查一次管道信息而不是用一次 join 搞定。批处理、UNNEST、CTE 这些优化技巧模型不会主动联想需要你人工写一版优化实现再让它在后续方法里复现这个模式。一旦它见过一次迁移到类似场景的成功率会明显提升。4. 验证请求与成功结果对照配置写完不等于迁移完成必须用真实请求验证数据一致性。我用的方式是在蓝绿部署阶段同时向 KV 后端和 PostgreSQL 后端发送相同的路由查询请求对比响应。先看单次验证请求。假设你要查某个管道下的启用规则curl -X POST https://stream-router.internal/api/v1/routes/query \ -H Content-Type: application/json \ -H X-Storage-Backend: postgres \ -d { pipeline_id: 1024, include_disabled: false }预期返回结构{ pipeline_id: 1024, rules: [ {id: 88, match_expr: {metric: http.*}, priority: 100}, {id: 91, match_expr: {metric: db.*}, priority: 50} ], backend: postgres, latency_ms: 3 }关键验证点是rules数组的顺序和内容必须与 KV 后端返回的完全一致。顺序由 priority 决定内容由 enabled 过滤。如果 PostgreSQL 侧返回的规则少了或多了说明 schema 映射或查询逻辑有问题。批量对比校验我用一个独立服务定时跑核心逻辑是从 KV 后端拉取全量路由状态从 PostgreSQL 后端拉取全量路由状态逐条对比。对比脚本的骨架def compare_backends(kv_client, pg_client, sample_size500): kv_routes kv_client.dump_all_routes() pg_routes pg_client.dump_all_routes() mismatches [] for route_id in random.sample(kv_routes.keys(), sample_size): if kv_routes[route_id] ! pg_routes.get(route_id): mismatches.append({ route_id: route_id, kv: kv_routes[route_id], pg: pg_routes.get(route_id) }) return mismatches实测下来迁移初期每天能抓到几十条不一致主要集中在边界情况比如match_expr里嵌套 JSON 的字段顺序、时间戳精度、以及enabled字段在并发更新时的可见性差异。每抓到一条就补一条对应的失败测试用例然后让 AI 针对这条用例调整实现。这个过程重复几轮之后不一致数量会快速收敛到零。性能对照也很直观。旧 KV 后端在高负载操作下单次路由查询延迟在数百毫秒到秒级PostgreSQL 后端在连接池预热后稳定在几毫秒。操作时间从 45 分钟降到 1 秒这个量级主要收益来自把应用层的串行往返换成了数据库内的 join 和索引扫描。存储占用最高缩减到原来的 1/40因为关系型模型消除了大量冗余的键值副本。5. 迁移过程中的常见报错与排查这一节列几个我在迁移里真实撞到的报错以及对应的排查路径。401 Unauthorized调用模型 API 时最常见。先检查 API Key 是否过期或复制时带了空格。TaoToken 的 Key 在控制台 API Keys 页面管理如果确认 Key 有效再看请求头里的Authorization格式是不是Bearer key。另一个容易忽略的点是 Base URL 写错比如漏了/api或者多加了斜杠都会导致认证失败。local proxy failed这个报错通常出现在你本地配置了转发规则但目标地址不可达时。检查你的 HTTP 客户端配置确认没有残留的本地转发设置。如果你在 CI 环境里跑对比脚本检查环境变量里有没有继承到不该有的配置。reading choices 相关报错调用模型接口返回结构解析失败时会出现。典型原因是模型返回的 JSON 被截断或者你解析的字段路径不对。先打印原始响应体确认结构再检查你的解析代码。如果是流式响应注意choices数组可能分多个 chunk 返回需要拼接后再解析。OAuth 相关报错如果你用 Claude Code 或类似工具接入可能会遇到 OAuth token 过期。这类工具通常有自己的认证流程检查你的 token 刷新逻辑。如果是在 CI 里跑确认 token 没有硬编码在脚本里而是通过环境变量注入。连接池耗尽PostgreSQL 侧报too many clients或请求排队超时。检查max_conns是否设得过高导致数据库侧连接数打满或者设得过低导致应用侧排队。Stream Router 的场景下40 个连接配合 8 个最小连接是个可用的起点但要根据实际 QPS 调整。另外确认max_conn_lifetime没有设得太长否则空闲连接会一直占着。schema 映射不一致对比校验服务报出某条路由的match_expr不一致。先检查 JSONB 字段的序列化方式PostgreSQL 的 JSONB 会重排键顺序并去重如果旧 KV 侧保留了原始顺序对比时要做规范化处理。时间戳精度差异也要统一建议全部用TIMESTAMPTZ并统一到毫秒。排查的核心原则是每个报错都要能对应到一条失败测试用例。没有测试用例覆盖的报错修完之后你不知道会不会再犯。这也是为什么迁移前期要花大量时间写测试——测试套件的完整度直接决定你能在多大程度上信任 AI 生成的代码。6. 把 AI 用在刀刃上接入方式与工具选择回到工具层面。这次迁移里 AI 的定位是“量”的搬运工不是“质”的决策者。它适合做接口适配、模型迁移这类模式化的编码但涉及性能优化的查询改写必须人工介入。你要做的是把测试写好让 AI 在明确的通过/不通过标准下迭代。如果你要复现这套流程接入方式很简单在 TaoToken 控制台创建 API Key把 Base URL 设为https://taotoken.net/apiModel ID 选你需要的代码模型。然后在你的重构脚本或 IDE 插件里配置这三件套。对于长期做编码和 Agent 任务的团队Coding Plan 提供了更稳定的调用额度适合这种需要反复迭代的重构场景。如果你想先验证模型对某段代码的理解能力可以直接在模型对话里贴入原始函数和新表结构看它生成的初稿质量。工具选择上Claude 系列模型配合 Cursor 这类编辑器在当前阶段确实好用但别神话它们。它们更像高级自动补全不是独立程序员。AI 生成代码通过测试但性能不佳时取舍标准很明确功能正确性交给测试判定性能优化交给人来 review。批处理、CTE、UNNEST 这些技巧模型见过一次能迁移但不会自己发现。最后留个讨论点如果你要迁移一个核心系统你会先手写完整测试让 AI 填充代码还是让 AI 先生成代码再手动补测试我的答案是前者因为测试套件的完整度决定了你能在多大程度上信任 AI 的输出。没有失败测试用例AI 生成的代码根本无法被信任。 Datadog Stream Router 迁移实战：从 KV 到 PostgreSQL，用 AI 辅助测试驱动重构
1. 为什么 KV 存储撑不住大规模流路由状态Datadog Stream Router 本质上是一个管理指标管道路由规则的 API 服务。它要回答的问题很朴素一条指标数据流进来应该被送到哪个下游管道。规则本身不复杂但规则的数量和它们之间的关联关系会随着业务膨胀。早期这套路由状态放在 KV 模型FoundationDB里走的是最终一致性路线写入快、扩展简单看起来是个合理选择。问题出在“关系”上。路由规则不是孤立的一堆键值对规则和管道、租户、标签之间存在大量外键式的引用关系。KV 存储不提供 join也不提供事务性的级联约束于是应用层只能自己把几万个条目拉到 Pod 进程内在内存里手搓关联逻辑。这种做法的代价在高负载时集中爆发一次涉及大量规则变更的操作需要数千次串行往返请求单次耗时最长能到 45 分钟。延迟从数百毫秒一路涨到秒级甚至更久存储占用也居高不下。更麻烦的是数据一致性。最终一致性意味着你在某个时刻读到的路由状态可能是旧的而路由错误会直接导致指标丢失或错投。团队不是没想过优化 KV 的访问模式但“手搓外键”这件事本身就是性能瓶颈的根源再怎么调优也只是缓解。所以结论很明确把关系型语义从应用层下沉到数据库层用 PostgreSQL 的外键、事务和查询优化器来接管这些逻辑。但全量重写风险太高Stream Router 承载的是生产流量不能停机。于是团队选择了一条渐进式路径保留原有 API 契约新增一个 PostgreSQL 后端实现用功能开关控制流量切换同时用 AI 辅助测试驱动的方式加速那些机械性的代码迁移工作。这篇文章面向的是正在或即将做类似存储层迁移的后端团队。我会把迁移配置骨架、连接池参数、schema 映射、回滚开关以及 AI 辅助重构的验证动作都拆开讲清楚。核心观点只有一句AI 能帮你搬代码但能不能信任它取决于你的测试套件有多完备。2. TaoToken 在 AI 辅助重构里的前置准备这次迁移里 AI 承担的角色很具体把旧 KV 模型下的接口实现逐个翻译成基于 PostgreSQL 的等价实现。它不是让你从零设计架构而是在你给定原始函数、新数据结构、预期行为之后生成初稿代码然后由失败测试用例来判定通过与否。这个流程要跑得顺前提是你能稳定、低成本地调用一个足够强的代码模型。我试过用 TaoToken 来做这层模型接入。它的定位是统一的模型 API 网关你拿到一个 API Key就能通过兼容 OpenAI 风格的接口调用包括 Claude 系列在内的多个模型。对于这种需要反复迭代、每次都要传入代码上下文和表结构的重构任务统一入口省去了在多个平台之间切换的麻烦。你需要准备三样东西Base URL、API Key、Model ID。Base URL 用https://taotoken.net/apiAPI Key 在控制台的 API Keys 页面创建Model ID 根据你选的模型填比如做代码重构我一般用 Claude 系列的模型 ID。这三件套在后面的配置片段里会反复出现先记牢。为什么不用本地跑模型因为这次重构的 token 消耗不小。AI 每次迭代都要吃进完整的测试输出日志、代码上下文和表结构累积起来量很大。本地硬件跑不动这个规模的上下文而按量付费的 API 在成本上比人工重写便宜又比自建推理集群省心。还有一个现实考量迁移过程中你需要频繁对比 AI 生成版本和人工优化版本的差异。统一 API 入口意味着你的脚本、CI 流程、对比工具都只需要对接一套认证和调用方式不用为每个模型单独写适配层。这在蓝绿部署阶段做持续对比校验时尤其重要。如果你只是做小项目的一次性重构可能直接手写更快。但像 Stream Router 这种模块化程度高、测试覆盖率有基础、又有蓝绿部署基础设施的系统AI 辅助的收益才真正显现出来。前置准备做到位后面的每一步才不会卡在环境问题上。3. 可复制的迁移配置骨架与 schema 映射这一节是整篇的核心我直接把可复制的配置片段给出来。你需要根据自己项目的实际路径和命名调整但结构可以照搬。先看 PostgreSQL 连接池配置。Stream Router 的迁移场景下连接池参数直接决定高负载时会不会把数据库打满。我用的是 pgx 连接池配置文件放在configs/postgres.yamlpostgres: host: ${PG_HOST} port: 5432 database: stream_router user: ${PG_USER} password: ${PG_PASSWORD} pool: max_conns: 40 min_conns: 8 max_conn_lifetime: 30m max_conn_idle_time: 5m health_check_period: 30s statement_cache: mode: prepare capacity: 512 migration: enabled: true rollback_switch: ROUTER_STORAGE_BACKEND rollback_value: kvrollback_switch这个环境变量是关键。它控制当前生效的存储后端是postgres还是kv。蓝绿部署时两个实例并排跑客户端流量通过这个开关切换。一旦 PostgreSQL 侧出现异常改回kv就能快速回退不需要重新部署。再看 schema 映射。旧 KV 模型里路由规则、管道、租户之间的关联是应用层手搓的现在要用外键表达。核心表结构如下CREATE TABLE pipelines ( id BIGSERIAL PRIMARY KEY, name TEXT NOT NULL UNIQUE, tenant_id BIGINT NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE routing_rules ( id BIGSERIAL PRIMARY KEY, pipeline_id BIGINT NOT NULL REFERENCES pipelines(id) ON DELETE CASCADE, match_expr JSONB NOT NULL, priority INT NOT NULL DEFAULT 0, enabled BOOLEAN NOT NULL DEFAULT true, updated_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE INDEX idx_rules_pipeline_priority ON routing_rules (pipeline_id, priority DESC) WHERE enabled true;ON DELETE CASCADE替代了旧代码里手动清理关联条目的逻辑。idx_rules_pipeline_priority这个部分索引针对的是“按管道查启用规则并按优先级排序”这个高频查询WHERE enabled true让索引只覆盖有效规则减少扫描量。AI 辅助重构时我会把旧函数的实现和新表结构一起喂给模型提示词里明确写出预期行为比如“给定 pipeline_id返回按 priority 降序排列的启用规则列表”。模型生成初稿后用一条失败测试用例去验证。不通过就调整提示词把失败信息精简后回传而不是把完整日志塞进去——完整日志会大幅推高 token 消耗。这里有个坑要提前说AI 生成的 SQL 经常能返回正确结果但会产生大量不必要的网络往返。比如它可能对每条规则单独查一次管道信息而不是用一次 join 搞定。批处理、UNNEST、CTE 这些优化技巧模型不会主动联想需要你人工写一版优化实现再让它在后续方法里复现这个模式。一旦它见过一次迁移到类似场景的成功率会明显提升。4. 验证请求与成功结果对照配置写完不等于迁移完成必须用真实请求验证数据一致性。我用的方式是在蓝绿部署阶段同时向 KV 后端和 PostgreSQL 后端发送相同的路由查询请求对比响应。先看单次验证请求。假设你要查某个管道下的启用规则curl -X POST https://stream-router.internal/api/v1/routes/query \ -H Content-Type: application/json \ -H X-Storage-Backend: postgres \ -d { pipeline_id: 1024, include_disabled: false }预期返回结构{ pipeline_id: 1024, rules: [ {id: 88, match_expr: {metric: http.*}, priority: 100}, {id: 91, match_expr: {metric: db.*}, priority: 50} ], backend: postgres, latency_ms: 3 }关键验证点是rules数组的顺序和内容必须与 KV 后端返回的完全一致。顺序由 priority 决定内容由 enabled 过滤。如果 PostgreSQL 侧返回的规则少了或多了说明 schema 映射或查询逻辑有问题。批量对比校验我用一个独立服务定时跑核心逻辑是从 KV 后端拉取全量路由状态从 PostgreSQL 后端拉取全量路由状态逐条对比。对比脚本的骨架def compare_backends(kv_client, pg_client, sample_size500): kv_routes kv_client.dump_all_routes() pg_routes pg_client.dump_all_routes() mismatches [] for route_id in random.sample(kv_routes.keys(), sample_size): if kv_routes[route_id] ! pg_routes.get(route_id): mismatches.append({ route_id: route_id, kv: kv_routes[route_id], pg: pg_routes.get(route_id) }) return mismatches实测下来迁移初期每天能抓到几十条不一致主要集中在边界情况比如match_expr里嵌套 JSON 的字段顺序、时间戳精度、以及enabled字段在并发更新时的可见性差异。每抓到一条就补一条对应的失败测试用例然后让 AI 针对这条用例调整实现。这个过程重复几轮之后不一致数量会快速收敛到零。性能对照也很直观。旧 KV 后端在高负载操作下单次路由查询延迟在数百毫秒到秒级PostgreSQL 后端在连接池预热后稳定在几毫秒。操作时间从 45 分钟降到 1 秒这个量级主要收益来自把应用层的串行往返换成了数据库内的 join 和索引扫描。存储占用最高缩减到原来的 1/40因为关系型模型消除了大量冗余的键值副本。5. 迁移过程中的常见报错与排查这一节列几个我在迁移里真实撞到的报错以及对应的排查路径。401 Unauthorized调用模型 API 时最常见。先检查 API Key 是否过期或复制时带了空格。TaoToken 的 Key 在控制台 API Keys 页面管理如果确认 Key 有效再看请求头里的Authorization格式是不是Bearer key。另一个容易忽略的点是 Base URL 写错比如漏了/api或者多加了斜杠都会导致认证失败。local proxy failed这个报错通常出现在你本地配置了转发规则但目标地址不可达时。检查你的 HTTP 客户端配置确认没有残留的本地转发设置。如果你在 CI 环境里跑对比脚本检查环境变量里有没有继承到不该有的配置。reading choices 相关报错调用模型接口返回结构解析失败时会出现。典型原因是模型返回的 JSON 被截断或者你解析的字段路径不对。先打印原始响应体确认结构再检查你的解析代码。如果是流式响应注意choices数组可能分多个 chunk 返回需要拼接后再解析。OAuth 相关报错如果你用 Claude Code 或类似工具接入可能会遇到 OAuth token 过期。这类工具通常有自己的认证流程检查你的 token 刷新逻辑。如果是在 CI 里跑确认 token 没有硬编码在脚本里而是通过环境变量注入。连接池耗尽PostgreSQL 侧报too many clients或请求排队超时。检查max_conns是否设得过高导致数据库侧连接数打满或者设得过低导致应用侧排队。Stream Router 的场景下40 个连接配合 8 个最小连接是个可用的起点但要根据实际 QPS 调整。另外确认max_conn_lifetime没有设得太长否则空闲连接会一直占着。schema 映射不一致对比校验服务报出某条路由的match_expr不一致。先检查 JSONB 字段的序列化方式PostgreSQL 的 JSONB 会重排键顺序并去重如果旧 KV 侧保留了原始顺序对比时要做规范化处理。时间戳精度差异也要统一建议全部用TIMESTAMPTZ并统一到毫秒。排查的核心原则是每个报错都要能对应到一条失败测试用例。没有测试用例覆盖的报错修完之后你不知道会不会再犯。这也是为什么迁移前期要花大量时间写测试——测试套件的完整度直接决定你能在多大程度上信任 AI 生成的代码。6. 把 AI 用在刀刃上接入方式与工具选择回到工具层面。这次迁移里 AI 的定位是“量”的搬运工不是“质”的决策者。它适合做接口适配、模型迁移这类模式化的编码但涉及性能优化的查询改写必须人工介入。你要做的是把测试写好让 AI 在明确的通过/不通过标准下迭代。如果你要复现这套流程接入方式很简单在 TaoToken 控制台创建 API Key把 Base URL 设为https://taotoken.net/apiModel ID 选你需要的代码模型。然后在你的重构脚本或 IDE 插件里配置这三件套。对于长期做编码和 Agent 任务的团队Coding Plan 提供了更稳定的调用额度适合这种需要反复迭代的重构场景。如果你想先验证模型对某段代码的理解能力可以直接在模型对话里贴入原始函数和新表结构看它生成的初稿质量。工具选择上Claude 系列模型配合 Cursor 这类编辑器在当前阶段确实好用但别神话它们。它们更像高级自动补全不是独立程序员。AI 生成代码通过测试但性能不佳时取舍标准很明确功能正确性交给测试判定性能优化交给人来 review。批处理、CTE、UNNEST 这些技巧模型见过一次能迁移但不会自己发现。最后留个讨论点如果你要迁移一个核心系统你会先手写完整测试让 AI 填充代码还是让 AI 先生成代码再手动补测试我的答案是前者因为测试套件的完整度决定了你能在多大程度上信任 AI 的输出。没有失败测试用例AI 生成的代码根本无法被信任。