让AI干重复的活真是省力——数据库对比

让AI干重复的活真是省力——数据库对比

以前做数据库结构对比，最容易陷入一种低价值但又不能不做的工作：打开不同数据库，查表结构，导出 Excel，对字段，一个个看类型、长度、是否必填、主键、视图，再把差异整理成报告。

这件事难吗？不难。

但它特别消耗注意力。尤其是一个 Java 系统同时适配 PostgreSQL、Oracle、MySQL、Kingbase、OceanBase、openGauss、达梦这类数据库时，人工对比很快就会变成“机械劳动 + 高出错概率”的组合。

这也是我最近对 AI 使用方式的一点体会：AI 真正省力的地方，不只是帮你写几段代码，而是把那些有规则、可校验、重复发生、需要耐心的活接过去。

数据库结构对比就是一个很典型的例子。

一、问题不是“能不能看出来”，而是“要看太多次”

数据库结构对比常见于这些场景：

• 开发环境与测试环境结构是否一致；
• 基准库与国产数据库适配库是否一致；
• 版本升级后脚本是否漏执行；
• Java Entity 与数据库表字段是否匹配；
• 多数据库适配时字段类型是否被正确映射；
• 表、字段、主键、视图是否有缺失；
• 报告问题时，需要快速定位到底是代码问题、脚本问题，还是数据库结构问题。

如果只是一张表、十几个字段，人工看也可以。

但真实项目里不是这样。一个系统可能有上百张业务表，每张表几十个字段，还要横向对比多个数据库。更麻烦的是，不同数据库的元数据表现并不完全一致。

比如 PostgreSQL 的 text、Oracle 的 clob，从数据库类型看不一样，但映射到 Java 里可能都是 String。PostgreSQL 未限定长度的字符串，在 JDBC 元数据里可能表现成很大的长度值；Oracle 里可能是 varchar2 或 clob。如果简单按数据库类型名称对比，就会制造大量“伪差异”。

所以真正的问题不是“人能不能看懂”，而是：

1. 人不适合长时间做重复对比。
2. 数据库之间存在类型表达差异。
3. Java 代码与数据库结构之间还多了一层映射关系。
4. 对比结果需要完整、稳定、可复查。

这类工作非常适合交给 AI 和脚本组合来做。

二、从“问 AI”进阶到“让 AI 按规则干活”

很多人用 AI，停留在这样的问题上：

帮我写一个 SQL。

帮我看一下这个字段类型。

帮我生成一个 Excel。

这当然有用，但还只是单次问答。

更进阶一点的用法，是把工作规则沉淀下来，让 AI 每次都按同一套规则执行。比如在项目目录里放一个 AGENTS.md，把数据库对比的上下文写清楚：

• 需要对比哪些数据库；
• 哪个库是基准库；
• 哪些库是对比库；
• 只检查哪些表；
• 默认只读元数据，不比较业务数据；
• 哪些差异必须查；
• 哪些差异暂不查；
• 不同数据库类型如何映射到 Java 类型；
• 报告按什么格式输出；
• 每次检查后报告保存在哪里。

这样一来，AI 不再只是“临时回答问题”，而是可以变成一个按本地规则执行的工作助手。

关键变化在于：你不是把任务描述一遍又一遍，而是把规则写成长期上下文。

每次要对比数据库时，只需要让 AI 读取这个规则文件，然后它就知道该连接哪些开发库、查哪些元数据、按什么逻辑过滤伪差异、最后输出什么格式的报告。

这比手工导出 Excel 再筛选要稳定得多。

三、开发环境：多数据库结构对比与同步

在医疗信息化产品里，多数据库适配是很常见的现实问题。

一套 Java 程序可能要同时支持 PostgreSQL、Oracle、MySQL，以及多个国产数据库。业务代码希望尽量保持一致，但底层数据库的 SQL 方言、字段类型、长度、大小写、Schema、视图定义都会有差异。

如果每次都靠人去看，成本很高。

更合理的方式是让 AI 执行这类检查：

1. 读取本地规则文件。
2. 连接开发环境数据库。
3. 只读查询元数据。
4. 以一个基准库为标准。
5. 分别对比其他数据库。
6. 输出每个数据库单独的小节。
7. 差异清单完整列出，不只展示前几百条。

对比范围可以先聚焦在高价值项：

• 是否缺表；
• 是否多表；
• 是否缺字段；
• 是否多字段；
• 字段类型是否不一致；
• 字段是否必填不一致；
• 主键是否一致；
• 视图是否缺失。

这些检查不需要业务数据，也不需要写数据库，只需要读取系统表、information_schema、JDBC 元数据或数据库字典表即可。

也就是说，这件事天然适合在开发环境里做自动化检查。

以前人工流程可能是：

1. 从 PostgreSQL 导出表结构；
2. 从 Oracle 导出表结构；
3. 从 Kingbase 导出表结构；
4. 从达梦导出表结构；
5. 合并到 Excel；
6. 按表名字段名排序；
7. 人工检查差异；
8. 整理报告；
9. 再反复确认是不是数据库类型表现差异。

现在可以变成：

让 AI 读取本地规则，连接开发库，只读检查元数据，生成结构对比报告。

这里省下来的不是一两分钟，而是一整套低价值重复流程。

四、Java Entity 与数据库结构的双向校验

数据库之间对比只是第一层。

更进一步，还要对比 Java Entity 与数据库表结构是否一致。

这件事在实际项目里很重要。因为很多问题并不是数据库之间不一致，而是代码模型和数据库结构不一致：

• Entity 里有字段，数据库表里没有；
• 数据库表里有字段，Entity 里没有；
• Java 字段类型和数据库字段类型不匹配；
• 字段长度约束不一致；
• 主键定义不一致；
• 视图存在于某个数据库，但代码或其他数据库环境里缺失；
• 字段可空性和代码校验规则不一致；
• 逻辑上应该是枚举或状态字段，但数据库类型设计不统一。

这类问题如果上线后才暴露，排查成本会明显增加。

比如一个字段在 Java 里是 Long，但某个数据库里被建成了普通字符串；或者 Java 里是 LocalDateTime，但数据库里某个适配库使用了不合适的日期类型。代码编译时未必能发现，运行时才可能在查询、反序列化、ORM 映射、SQL 执行时出问题。

AI 可以做的事情包括：

• 扫描 Java Entity 类；
• 解析字段名、注解、主键、表名映射；
• 读取各数据库表结构；
• 建立 Java 类型与数据库类型的映射表；
• 判断字段是否缺失；
• 判断字段类型是否匹配；
• 判断长度、精度、可空性是否一致；
• 判断主键是否一致；
• 判断视图是否缺失；
• 输出可操作的差异报告。

这里的重点不是让 AI “猜”，而是把判断规则写清楚。

例如：

• PostgreSQL 的 text 与 Oracle 的 clob 都按 Java String 处理；
• PostgreSQL 的 varchar 与 Oracle 的 varchar2 映射到 Java String；
• PostgreSQL 的 timestamp 与 Oracle 的 timestamp(6) 可按 Java LocalDateTime 等价处理；
• bytea 与 blob 可按 Java byte[] 等价处理；
• numeric、decimal、number 涉及精度和小数位时要进一步判断；
• 数据库类型等价不代表主键、必填、默认值、索引也可以忽略。

这样可以减少大量没有实际意义的类型噪音，把注意力集中在真正可能影响运行的问题上。

五、不导 Excel，不靠眼睛扫，让报告成为交付物

数据库对比最怕的不是发现差异，而是差异不可复查。

如果只是口头说“两个库不太一样”，没有价值。

如果只是 Excel 里手工筛选了一份结果，也容易出现口径不一致、遗漏、排序混乱、下次无法复现的问题。

更好的方式是让 AI 每次生成固定格式的 Markdown 报告：

• 结论：是否存在差异；
• 高风险差异：是否影响启动、查询、写入、版本升级；
• 对比对象：基准库、对比库、对比时间；
• 差异清单：按数据库分别列出；
• 建议：哪些需要补脚本，哪些可以忽略，哪些需要人工确认。

多库对比时，尤其要避免把所有差异混在一张大表里。更清晰的方式是：

• DB2 Oracle 一个小节；
• DB3 OceanBase 一个小节；
• DB4 KingbaseES 一个小节；
• DB5 openGauss 一个小节；
• DB6 Dameng 一个小节。

每个对比库都有自己的差异表。这样研发、测试、实施、项目经理都能直接看懂。

更重要的是，报告可以纳入项目过程：

• 版本发布前生成一次；
• 数据库脚本改动后生成一次；
• 国产数据库适配前后各生成一次；
• 测试环境异常时生成一次；
• 发版包交付前留档一次。

这时 AI 的价值就不只是“帮忙看一下”，而是把重复检查变成了稳定流程。

六、AI 做重复活，人做判断

这类任务里，人和 AI 的分工应该很清楚。

AI 适合做：

• 读取规则；
• 查询元数据；
• 批量对比；
• 归类差异；
• 生成报告；
• 初步判断风险；
• 根据历史规则过滤伪差异。

人更适合做：

• 判断某个差异是否符合业务设计；
• 决定是否补数据库升级脚本；
• 决定 Java Entity 是否要调整；
• 确认不同数据库的兼容策略；
• 评估上线风险；
• 处理涉及生产数据和权限的动作。

这也是 AI 使用进阶的一个关键点：不要把 AI 当成万能决策者，而是把它放到合适的位置上，让它承担重复、繁琐、规则明确的工作。

数据库结构对比刚好符合这个特点。

它不需要 AI 发挥太多创造力，反而需要它严格按规则执行。规则越清楚，效果越稳定。

七、安全边界：只读、本地、脱敏、可复查

数据库对比涉及连接信息和系统结构，必须有边界。

我的基本原则是：

• 只在本地执行；
• 不上传数据库配置；
• 不使用生产库真实患者数据；
• 优先只读查询元数据；
• 不做数据库写操作；
• 不把账号、密码、内网地址写进博客或报告；
• 生成报告时只保留必要的结构差异；
• 涉及生产服务时需要人工审批和操作留痕。

尤其在医疗信息化场景里，这一点更重要。

AI 可以提升效率，但不能绕过权限、安全和审计。开发环境结构对比可以自动化，生产环境变更必须谨慎处理。

八、这件事真正节省的是什么

表面看，AI 节省的是导出 Excel、复制字段、手工对比的时间。

但更深一层，它节省的是人的注意力。

研发人员不应该把大量时间花在机械扫描字段上。项目经理也不应该靠肉眼判断多数据库结构是否一致。测试人员更不应该在不同环境间反复猜测“是不是脚本漏了”。

AI 适合把这些问题提前暴露出来：

• 哪个库少了表；
• 哪张表少了字段；
• 哪些字段类型不匹配；
• 哪些主键没建；
• 哪些视图缺失；
• 哪些差异只是数据库元数据表现不同，实际映射到 Java 后可以忽略；
• 哪些差异确实需要研发处理。

这才是 AI 工具链真正有用的地方。

不是替代人做技术判断，而是把人从重复确认里解放出来，让人把时间花在架构、业务、风险和决策上。

九、我的体会：AI 使用进阶，不是提示词更花哨，而是流程更稳定

很多人讨论 AI 使用技巧，会强调提示词怎么写。

提示词当然重要，但更重要的是流程。

对数据库对比这类任务来说，真正有效的不是写一句“请帮我对比数据库结构”，而是把工作规则沉淀成可复用的上下文：

• 明确基准库和对比库；
• 明确只对比结构，不对比数据；
• 明确检查范围；
• 明确类型等价规则；
• 明确 Java 类型映射；
• 明确哪些差异必须输出；
• 明确哪些差异暂时忽略；
• 明确报告格式；
• 明确安全边界。

当这些规则稳定下来，AI 就可以从“问答助手”升级成“执行助手”。

这也是我理解的 AI 使用进阶：不是让 AI 看起来更聪明，而是让它在你的真实工作流里持续减少重复劳动。

数据库对比只是一个例子。

同样的方法还可以扩展到：

• 版本变更脚本检查；
• Entity 与接口 DTO 对比；
• 数据字典完整性检查；
• 接口字段与前端表单字段对比；
• 多环境配置差异检查；
• 工单问题归类；
• 实施手册问答；
• 常见问题排障。

凡是“规则明确、重复发生、人工容易漏、结果需要报告”的工作，都值得交给 AI 试一试。

结语

让 AI 干重复的活，真是省力。

数据库对比这件事本身并不新，但 AI 让它的执行方式发生了变化：以前靠人打开工具、导出 Excel、肉眼检查；现在可以让 AI 读取本地规则、查询元数据、对比结构、过滤伪差异、生成报告。

人要做的，是定义规则、确认边界、判断风险。

AI 要做的，是不厌其烦地执行。

这才是当前阶段最务实的 AI 落地方式：不追求玄乎的智能，先把每天、每周、每个版本都要重复做的活省下来。