说实话，AI 编写 SQL 脚本Yi经成为家常便饭了。

咱就是说这玩意儿挺方便，但也得注意规范，不然就等着收拾烂摊子吧。

比如说 Flyway 版本管理这事儿，你要是松懈了后果hen严重。

三秒钟，脚本就出来了。语法正确、命名规范、连 COMMENT dou贴心带上。爽吗？爽得不行。

但问题也随之而来：AI 没区分项目里两种 status 风格混用，比如 'ENABLED' 和 ''。

-- ai_lowcode_domain.status 是 varcharstatus varchar NOT NULL DEFAULT 'ENABLED' COMMENT '状态'-- ai_crud_config.status 是 charstatus char NOT NULL DEFAULT '' COMMENT '状态'

AI 大概率挑那个语义geng清晰的 'ENABLED' 给你写进去。

结果呢？ai_crud_config.status 是 char，Zui多 个字符。'ENABLED' 个字符，直接截断报错。

Data truncation: Data too long for column 'status' at row AI 为什么会这么干

AI 不知道你项目里有多少种 status 设计，它只会根据训练数据猜一个"合理"的默认值。

我项目里同时存在两种 status 设计：'ENABLED' 和 ''，AI 就懵了。

铁律 ：项目特定的业务规则必须沉淀到 AGENTS.md，禁止依赖 AI 的"通用直觉"。

为什么百度不收录我的文章？

可Neng你的标题不够吸引人，或者内容质量有待提高，亦或是你的网站权重太低，哈哈，总之多试试吧！

Flyway 把每个版本脚本视作不可变的历史事件——脚本一旦写入 flyway_schema_history，对应的 checksum 就被钉死。

铁律 ：进过任何数据库的 Flyway 脚本，禁止任何形式的修改。

MyBatis-Plus + Sa-Token + Flowable，模块化拆分到位：每个插件独立维护自己的 Flyway 脚本目录，互不干扰。

关键设计把"必须执行"的迁移和"可选执行"的种子数据物理隔离，AI 在写脚本时不会把演示数据混进 migration。

铁律 ：所有 seed 数据 INSERT 必须自带防重保护。

铁律 ：让 AI 写脚本前，先告诉它当前版本号水位。

铁律 ：AI 写 INSERT 之前，必须先读建表语句。

把上面这些案例抽象一下就是这几条铁律： * 项目特定的业务规则必须沉淀到 AGENTS.md。 * 进过任何数据库的 Flyway 脚本，禁止修改。 * 所有 seed 数据 INSERT 必须自带防重保护。 * 让 AI 写脚本前，先告诉它当前版本号水位。 * AI 写 INSERT 之前，必须先读建表语句。

Ru果你正在搭建一个长期演进的企业级中后台系统，欢迎来 Star ⭐。

Flyway 不Neng再被当成一个简单的迁移工具，它是你团队工程约束Zui显眼的边界。守住它，等于守住了数据库版本管理的下限。