最近更新：2026-04-25

这份文档的定位

老系统向新系统迁移，过去的分工是人定规则、AI 执行、人 review 兜底。这是”人 + AI 协作”模式，AI 是工具。

AI 优先的工作模式做三个转变：

1. 1. AI 是主责方（owner），人是 escalation 处理者，只在 AI 主动求助时介入
2. 2. “AI 不适合做 X” 不是结论，是规则不够细的信号 —— 把 X 的判据机读化到 AI 能做
3. 3. Review 由多 agent 互审闭环，不是人审 AI 的单向流程

目标不是让 AI 帮人干活，而是让整条迁移流水线默认以 AI 为主语运转，人在特定 escalation 条件下介入，介入本身是信号 —— 介入频率过高 = 规则缺判据，要改规则，不是接管。

这份文档的作用是：把”人的判断前移”做到极致，把所有可机读的判据都机读化，把剩余无法机读的事项显式列为 escalation 触发条件。

TL;DR

三个核心机制：

1. 1. 判据机读化 —— 所有建模规则给出 AI 可直接判断的信号（读写比、字段差异比、调用链是否命中、confidence 阈值），不留”看情况”
2. 2. 多 agent 互审 —— 生成 agent + 审查 agent + 对抗 agent 独立跑，分歧就是 escalation 信号；不依赖人做第二层 review
3. 3. Escalation 触发条件显式化 —— AI 在四类场景主动呼叫人：规则冲突、判据边界（confidence < 阈值）、合规红线、破坏性操作；其他一律 AI 自闭环

AI 为主语的流程：

AI 扫源库 + 爬调用链 + 爬下游消费方 → 生成业务文档草稿  ↓人补充例外 + 确认白名单（唯一必选人工节点，< 1 小时）  ↓AI 按规范建新表 → AI 多 agent 互审 → AI 自检全绿  ↓AI 生成双写 shim + 对账脚本 + 灰度开关 + 回滚路径  ↓AI 执行迁移 → AI 监控对账 → 异常触发 escalation  ↓人只在 escalation 时介入

主线 A 也 AI 闭环：双写 shim 代码、对账脚本、灰度策略、回滚路径、脏数据处置、外部依赖兼容检查 —— 全部由 AI 生成 + 执行 + 监控；人只做 escalation 裁决。

建模规则按”信号 / 阈值 / AI 动作”三列给出，不写”看情况判断”；AI 读信号直接决定。

分工反转：AI 是 owner；人是 escalation 处理者 + 规则维护者 + 红线审批者。三者都不是迁移主语。

失败信号即规则缺陷：人介入频率 / escalation 频率 / agent 互审分歧率都是可观测指标，指标劣化 = 规则粒度不够，回头补判据，不是让人接手。

一句话收束：AI 优先不是 AI 万能，而是让 AI 默认闭环、让人的介入从”主流程”退化为”异常处理”，并把每次介入变成规则升级的信号。

正文

一、核心工作假设

传统 “AI 辅助” 的假设是：AI 不稳定、业务判断需要人。结论：人 review 兜底。

AI 优先的假设是：AI 不稳定的地方，是判据不够细的地方。结论：把判据细化到 AI 能做，剩余的列为 escalation。

这个转变有三个推论：

1. 1. “AI 做不了业务判断” 是伪命题。业务判断之所以”需要人”，是因为判断所依赖的信号没被结构化。一旦信号机读化（读写 QPS、字段差异比、调用链依赖、合规标签），判断本身就机械化了。
2. 2. 人介入频率是系统指标，和 CPU 使用率、错误率一样可观测。频率高 = 规则有缺陷，要回头改规则。
3. 3. Review 不是人的职责。Review 的本质是独立视角验证，多 agent 互审比人 review 更可扩展、更可回归测试。人只在 agent 分歧时做仲裁。

二、三个核心机制

机制 1：判据机读化

规则：每条建模规范必须给出 AI 可直接判断的信号和阈值，不写”看情况”、”根据场景”、”评估后决定”这种需要人脑补的判据。

反例（传统写法，不够）：

“读远大于写的聚合可以落预计算表”

正例（AI 优先写法）：

• • 信号：近 30 天读 QPS / 写 QPS 比值
• • 阈值：≥ 10
• • 数据源：生产 slow log + binlog 统计
• • AI 动作：比值 ≥ 10 → 落预计算表；< 10 → 保持实时计算；数据缺失 → escalation

信号数据源必须显式列出，不能假设 AI 能凭空算出。常见数据源：

• • 生产访问日志（读 QPS、写 QPS、字段被查询频率）
• • 调用链追踪（哪些字段被哪些下游消费）
• • 源码静态分析（字段被哪些模块引用）
• • 数据库元数据（字段 null 比例、区分度）
• • 外部系统 schema registry（消息格式、API 契约）

迁移准备的第一件事：把这些信号接入统一查询接口，让 AI 可以一次拉全。这个工作比建新表更重要。

机制 2：多 agent 互审

规则：不依赖人做第二层 review。用三类 agent 独立跑同一输入，对比结果，分歧即 escalation。

• • 生成 agent：按规范产出 DDL / 映射 / 脚本
• • 审查 agent：用不同模型 + 不同 prompt 独立审查输出，产出差异报告
• • 对抗 agent：主动找反例（字段命名歧义、拆表边界、白名单漏项），产出”应该但没做”清单

三方结果一致 → 通过，不需要人介入。三方有分歧 → 分歧点作为 escalation 上报，人做仲裁。

流程：

        ┌───────────────────────────────────────┐        │  输入：老表结构 + 规范文档 + 信号数据  │        └───────────────────┬───────────────────┘                            │         ┌──────────────────┼──────────────────┐         │                  │                  │         ▼                  ▼                  ▼  ┌─────────────┐    ┌─────────────┐    ┌──────────────┐  │ 生成 agent  │    │ 审查 agent  │    │ 对抗 agent   │  │ 模型 A       │    │ 模型 B      │    │ 模型 C       │  │ ─────────── │    │ ─────────── │    │ ───────────  │  │ 按规范产出   │    │ 独立按规范   │    │ 主动找反例   │  │ DDL + 映射   │    │ 审查输出     │    │ 漏项 / 歧义  │  └──────┬──────┘    └──────┬──────┘    └──────┬───────┘         │                  │                  │         └──────────────────┼──────────────────┘                            ▼                ┌───────────────────────┐                │  结果汇总 + 差异计算   │                └───────────┬───────────┘                            │              ┌─────────────┴─────────────┐              ▼                           ▼          三方一致                     任一分歧              │                           │              ▼                           ▼        ┌──────────┐          ┌─────────────────────────┐        │ 通过     │          │ 生成 escalation 工单     │        │ 进下阶段 │          │  · 分歧点                │        └──────────┘          │  · 各 agent 理由         │                              │  · 引用的规则条款        │                              └────────────┬────────────┘                                           ▼                              ┌─────────────────────────┐                              │ 人一次性裁决              │                              │ + 补判据 / 改规则 / 补信号 │                              └────────────┬────────────┘                                           ▼                              ┌─────────────────────────┐                              │ 规则升级 → 历史结果回归跑 │                              └─────────────────────────┘

关键约束：

• • 三 agent 必须独立（不同模型、不同 prompt、不共享上下文），否则互审退化成自说自话
• • 审查 agent 的规则来自规范文档本身，不是从生成 agent 那里继承
• • 所有分歧上报必须可追溯（谁在哪条规则上和谁分歧、理由是什么），成为规则升级的输入

为什么不用人做第二层：

• • 人 review 无法回归测试（规则改了，历史 review 不会自动重跑）
• • 人 review 不可扩展（上千张表评审者会崩）
• • 人 review 口径漂（今天 A 的标准 ≠ 明天 B 的标准）
• • Agent 互审是可测试的软件系统，人 review 不是

机制 3：Escalation 触发条件

规则：AI 在以下四类场景必须主动暂停、呼叫人。其他一律自闭环，不等人确认。

非触发场景（AI 一律自闭环，不等人）：

• • 字段命名翻译
• • 注释补全
• • 索引策略初版生成
• • 对账脚本生成
• • 双写 shim 代码生成
• • 灰度切换脚本
• • 僵尸字段清理（非破坏性，先 soft delete）

Escalation 频率是可观测指标：每个 sprint 统计。频率上升 = 规则失灵，要回头改规则 / 补判据 / 加信号数据源，不是给人排班。

触发与处置流程：

    ┌────────────────────────────────────────┐    │ AI 执行过程中持续检测                    │    └────────────────┬───────────────────────┘                     │      ┌──────────┬───┴────┬──────────┐      ▼          ▼        ▼          ▼   规则冲突   判据边界  合规红线  破坏性操作      │          │        │          │      │    confidence<阈  │    删字段/删表      │    多 agent 分歧  │    物理删数据      │    信号数据缺失   │    修改外键      └──────────┴────┬───┴──────────┘                      │                      ▼          ┌───────────────────────────┐          │ 生成结构化 escalation 工单 │          │ ───────────────────────    │          │ · 类别                     │          │ · 上下文 + 数据快照        │          │ · 当前规则引用             │          │ · AI 建议方案 + confidence │          └─────────────┬─────────────┘                        ▼          ┌───────────────────────────┐          │ 进人的 escalation 队列      │          └─────────────┬─────────────┘                        ▼          ┌───────────────────────────┐          │ 人裁决                     │          └──┬────────────────────┬───┘             │                    │     仅一次性裁决         改规则 / 补信号 / 补判据             │                    │             ▼                    ▼    ┌──────────────┐    ┌──────────────────────┐    │ AI 继续执行   │    │ 规则升级              │    │ (本次任务)    │    │ → 未来同类问题 AI 自决 │    └──────────────┘    │ → 历史结果回归跑       │                        └──────────────────────┘

注意：理想状态是人的每次裁决都沉淀为规则升级，而不是每次重复做同类裁决。裁决频率高但规则不动 = 流程失灵。

三、建模规则（信号 / 阈值 / AI 动作）

每条规则三列给出。AI 读信号直接执行，不做模糊判断。

1. 主键选型

• • 信号：是否跨库部署 / 是否分库分表 / 是否对外暴露 / 是否需要跨环境合并
• • 阈值：以上任一为是
• • AI 动作：是 → 分布式 ID；否 → 自增 BIGINT

2. 拆表（类型差异）

• • 信号：子类独有字段数 / 主表总字段数
• • 阈值：> 30% → 拆；< 20% → 单表 + nullable；20~30% → 看操作语义一致性（调用链里这两类是否走同一组方法）
• • AI 动作：阈值明确直接执行；20~30% 且操作语义不一致 → 拆；一致 → 单表；无法判断操作语义 → escalation

3. 冗余 / 聚合字段

• • 信号：读 QPS / 写 QPS 比值（来自生产日志统计）
• • 阈值：≥ 10 且实时计算 P99 > SLA → 预计算表；其他 → 实时计算
• • AI 动作：阈值明确直接建预计算表（物化视图 / 定时刷新）；不在业务主表加冗余字段

4. 一对一关系

• • 信号：两表是否同生同灭 + 是否每次一起读 + 是否权限边界一致
• • 阈值：全部为是 → 合表；任一为否 → 拆表
• • AI 动作：按信号直接决定

5. 软删除

• • 信号：近 90 天”查已删数据”的查询次数 + 合规要求 + 数据生命周期长度
• • 阈值：查询 > 0 或合规要求保留 → deleted_at；高频短生命周期（< 7 天）且无查询需求 → 物理删 + 归档
• • AI 动作：按信号直接决定

6. 外键

• • 信号：是否跨库 + 写入 QPS
• • 阈值：跨库 或 写入 QPS > 阈值（按数据库能力配置）→ 应用层校验 + 对账；否则 → 数据库外键
• • AI 动作：按信号直接决定

7. 命名

• • 信号：字段名是否通过 AI 语义清晰度打分（给 LLM 打分：0-10，≥ 7 通过）
• • 阈值：< 7 → 回炉重命名；跨系统已有事实标准 → 遵从
• • AI 动作：打分 + 重命名 + 重新打分直到通过

8. 注释

• • 信号：注释是否包含业务语义 + 取值范围（AI 语义检查）
• • 阈值：缺任一 → 回炉补全
• • AI 动作：生成 + 自检 + 回炉

9. 字符集 / 引擎

• • 信号：数据库类型
• • 阈值：MySQL → utf8mb4 + InnoDB；PG → UTF8 + 默认引擎
• • AI 动作：直接执行

10. 时间字段

• • 信号：表是否只插入 + 是否需要软删
• • 阈值：created_at 必须有；有更新操作 → updated_at；软删场景 → deleted_at
• • AI 动作：直接执行

四、白名单：AI 自动识别 + 人确认边界

传统做法：人定义白名单。AI 优先做法：AI 从信号里识别白名单候选，人只看 AI 标记的 confidence 低的项。

白名单类别 + 识别信号

AI 动作：

1. 1. 扫所有信号源，自动识别候选
2. 2. 对每个候选打 confidence
3. 3. confidence ≥ 阈值 → 直接加入白名单迁移
4. 4. confidence < 阈值 → 列 escalation 清单，人一次性确认
5. 5. 业务文档覆盖 + 非白名单 → 迁
6. 6. 业务文档未覆盖 + 非白名单 → 进 AI 自动挂起队列，由 AI 反查调用方：有引用就保留，无引用 soft delete 观察 N 天后物理删

关键：人不再维护白名单本身，人只做 confidence 低的边界确认。白名单规则和信号源是维护的对象。

单字段决策流程（AI 对每个源字段执行）：

                ┌──────────────────────┐                │   源表字段 X          │                └──────────┬───────────┘                           ▼            ┌────────────────────────────────┐            │ AI 拉信号（并行）               │            │ · 业务文档是否覆盖              │            │ · 字段名模式匹配                │            │ · 调用链：谁在引用              │            │ · 下游消费方：谁在消费          │            │ · 数据分类标签（PII 等）        │            │ · 源码静态分析引用次数          │            └────────────────┬───────────────┘                             ▼                ┌──────────────────────┐                │ 白名单八类模式匹配    │                └────┬─────────────┬───┘                     │             │                  命中           未命中                     │             │                     │             ▼                     │   ┌────────────────────┐                     │   │ 业务文档是否覆盖    │                     │   └──┬─────────────┬───┘                     │      │             │                     │    覆盖          未覆盖                     │      │             │                     │      │             ▼                     │      │   ┌──────────────────────┐                     │      │   │ AI 自动挂起队列       │                     │      │   │ 反查调用方 + 消费方   │                     │      │   └──────┬───────────────┘                     │      │          │                     │      │   ┌──────┴───────┐                     │      │ 有引用         无引用                     │      │   │               │                     │      ▼   ▼               ▼                     │   ┌──────────┐   ┌────────────────┐                     │   │ 加入迁移 │    │ soft delete     │                     │   └────┬─────┘   │ 观察 N 天 → 物理删│                     │        │         └────────┬─────────┘                     │        │                  │                     └────────┴──────────────────┘                                   │                                   ▼                    ┌─────────────────────────────┐                    │ confidence 检查              │                    └────┬──────────────────┬─────┘                         │                  │                      ≥ 阈值            < 阈值                         │                  │                         ▼                  ▼                   ┌──────────┐      ┌─────────────┐                   │ AI 自决  │      │ Escalation  │                   └──────────┘      └─────────────┘

这条流程是”判据机读化”的典型实例：每个决策节点都有明确信号来源和阈值，AI 直接执行；只在 confidence 边界或合规红线上触发 escalation。

五、流程：AI 为主语

端到端主流程图（AI 为主干，人为旁路）：

  ╔══════════════════════════════════════════════════════════════════╗  ║  阶段 0（一次性基础设施投入）                                      ║  ║  ──────────────────────────                                       ║  ║  信号数据源统一接入 AI 可查询接口：                                 ║  ║   · 生产日志 QPS 统计      · 外部 schema registry                   ║  ║   · 调用链追踪              · 数据库元数据                          ║  ║   · 源码静态分析            · 监控看板 query 抓取                   ║  ╚══════════════════════════════════════════════════════════════════╝                                │                                ▼  ┌──────────────────────────────────────────────────────────────────┐  │  阶段 1  AI 扫描老系统                                             │  │  ──────────────────────────                                       │  │  · 爬前端 + 异步链路 + 监管链路 + 下游订阅                          │  │  · 识别白名单候选 + 打 confidence                                   │  │  · 产出：业务文档草稿 + 白名单清单 + confidence 报告                 │  └────────────────────────────────┬─────────────────────────────────┘                                   ▼                      ┌──────────────────────┐                      │ 按 confidence 分拣    │                      └───┬──────────────┬───┘                          │              │                    ≥ 阈值          < 阈值 或合规项                          │              │                          │              ▼                          │    ┌────────────────────┐                          │    │ 阶段 2  人介入      │                          │    │ 一次性 < 1 小时      │                          │    │ 只确认边界项        │                          │    └──────────┬─────────┘                          │               │                          └───────┬───────┘                                  ▼  ┌──────────────────────────────────────────────────────────────────┐  │  阶段 3  AI 建新表 + 多 agent 互审                                  │  │  ──────────────────────────                                       │  │  生成 agent → 审查 agent → 对抗 agent（独立并行）                   │  └────────────────────────────────┬─────────────────────────────────┘                                   ▼                      ┌──────────────────────┐                      │  互审结果              │                      └───┬──────────────┬───┘                          │              │                     三方一致          任一分歧                          │              │                          │              ▼                          │      ┌────────────────┐                          │      │ Escalation     │                          │      │ 人裁决 + 改规则 │                          │      └────────┬───────┘                          │               │                          └───────┬───────┘                                  ▼  ┌──────────────────────────────────────────────────────────────────┐  │  阶段 4  AI 生成迁移基础设施                                       │  │  ──────────────────────────                                       │  │  · 双写 shim 代码        · 回滚路径 + 回滚阈值                      │  │  · 对账脚本              · 脏数据处置规则                           │  │  · 灰度开关 + 切换脚本   · 下游兼容性自动化测试                      │  └────────────────────────────────┬─────────────────────────────────┘                                   ▼  ┌──────────────────────────────────────────────────────────────────┐  │  阶段 5  AI 执行迁移（持续监控）                                   │  │  ──────────────────────────                                       │  │  按灰度策略切换 + 对账实时监控 + 异常检测                           │  └────────────────────────────────┬─────────────────────────────────┘                                   ▼                      ┌──────────────────────┐                      │ 异常检测              │                      └───┬──────┬───────┬───┘                          │      │       │                     指标正常  软异常  硬异常                          │      │       │                          │      ▼       ▼                          │  ┌────────┐ ┌──────────────────┐                          │  │ 继续   │ │ 自动回滚          │                          │  │ +告警  │ │ + escalation 通知 │                          │  │ +留痕  │ └────────┬─────────┘                          │  └───┬────┘          │                          │      │               ▼                          │      │      ┌─────────────────┐                          │      │      │ 人分析根因       │                          │      │      │ + 改规则 / 改 shim │                          │      │      └─────────────────┘                          └──────┴───────┐                                         ▼  ┌──────────────────────────────────────────────────────────────────┐  │  阶段 6  AI 闭环验证                                              │  │  ──────────────────────────                                       │  │  对账差异 = 0 持续 N 小时 → 全量切换                                │  │  清理老表 → 破坏性操作 escalation → 人签字后 AI 执行               │  └──────────────────────────────────────────────────────────────────┘

图例说明：

• • ╔═╗ 标示一次性基础设施投入（阶段 0），后续迁移复用
• • 主干（▼）是 AI 自动流转路径；旁路（→ Escalation）是人介入点
• • 人的介入只出现在阶段 2 一次性 confidence 边界确认、互审分歧裁决、自动回滚后的根因分析、破坏性操作签字四处
• • 每次人介入都伴随规则升级动作，使未来同类问题 AI 可自决

人在整个流程里的介入点：

• • 阶段 0：一次性投入建信号数据源
• • 阶段 2：一次性确认 confidence 低的项（< 1 小时）
• • 任一阶段：escalation 触发时

其余全部 AI 自闭环。

六、主线 A（迁移过程）也 AI 闭环

传统观念认为主线 A（双写/灰度/回滚/对账）是”AI 帮不上主动决策的硬骨头”。AI 优先模式下把它也拆解成判据 + 信号 + AI 动作：

人在主线 A 的角色：

• • 给 AI 配置自动回滚阈值（一次性）
• • 对 AI 上报的 escalation 做裁决
• • 合规红线签字（不可委托）

人不再”盯”迁移过程，盯的是告警和 escalation 队列。

七、工具与模型架构

• • Agent 架构 > 单 prompt：生成 / 审查 / 对抗 三 agent 独立运行，彼此不共享上下文
• • 多模型互验 > 单一最强模型：不同模型的盲点不同，互验比堆能力更有效
• • 对话式分步 + 完整追溯：每一步决策有 trace（输入信号、规则引用、confidence、输出），便于规则升级
• • 工具本身通用化：业务知识通过信号数据源 + 业务文档输入，不硬编码进 agent prompt
• • Human-in-the-loop 窄接口：escalation 以结构化工单形式进人的队列，不让人读 raw agent log
• • 失败注入测试：定期往 agent pipeline 注入故意错误，验证互审机制真的能捕捉（防止互审 agent 躺平）

八、分工：AI 是 owner

三个角色都不是迁移的主语。迁移的主语是 AI agent 集群。

反模式：

• • 规则维护者替 AI 决策 → 规则没写清，回头写清楚
• • Escalation 处理者变成”日常 review 者” → escalation 条件太松，收紧
• • 红线审批者被日常事项淹没 → 红线定义太宽，收窄

九、可观测指标（系统健康信号）

AI 优先模式下，迁移系统本身是被观测对象。以下指标持续跟踪：

指标劣化的处置：回头改规则 / 补判据 / 补信号数据源，不是给人加排班。

十、失败信号 = 规则缺陷

十一、风险与边界

AI 优先不是 AI 万能。以下必须显式承认：

• • 合规 / 法律 / 安全红线不能自动化：AI 可以识别，但决策必须人签字
• • 判据机读化有成本：阶段 0 的信号数据源建设是一次性重投入，省不掉
• • 多 agent 互审不等于正确：agent 可能共享盲点，需要失败注入持续验证
• • 最终责任在规则维护者：AI 出错时追溯到规则，规则追溯到人；责任不消失，只是前移

这些不是对 AI 优先的否定，是对它的边界条件声明。

十二、一句话收束

AI 优先不是 AI 万能，而是让 AI 默认闭环、让人的介入从”主流程”退化为”异常处理”，并把每次介入变成规则升级的信号 —— 直到下一次同类问题 AI 能自己解决。