1. 项目概述：为什么 SaaS 数据模型生成不能只靠“写得快”大多数人第一次让 Claude Code 生成数据库 schema 时，会得到一张看起来很漂亮的users表：主键、邮箱、密码哈希、创建时间——字段齐全，类型合理，甚至带了注释。但当它被扔进一个真实的 SaaS 项目里，不到三天就会出问题：租户隔离字段漏了，软删除标记没加deleted_at而是用了布尔值，历史版本表没建索引导致查询超时，迁移脚本里ADD COLUMN没加NOT NULL DEFAULT就直接上线……这些不是“写得慢”的问题，而是“写得不全”的代价。我上个月在交付一个多租户 CRM 系统时就踩过这个坑。团队用 Claude Code 快速生成了前 8 张核心表的初始 schema 和 Flyway 迁移脚本，开发节奏确实快了——API 层当天就跑通了。但第三天 QA 提交了一个阻塞性 Bug：同一租户下两个用户同时修改客户备注，最终只保留了后提交的那条，前一条被静默覆盖。查下来发现，contacts表缺了updated_at的ON UPDATE CURRENT_TIMESTAMP，更致命的是，contact_history表的version字段没设为BIGINT AUTO_INCREMENT，而是靠应用层递增，而应用层没做分布式锁。这不是 AI 写错了，是它根本没被告诉“这个字段必须支持并发安全的乐观锁”。SaaS 场景下的数据模型，从来不是单张