AI 直接设计数据库？先让它讲清退款和重复回调

数据库表设计错了，上线后才发现改不动。这类问题在 AI 写代码时更常见。模型补主外键很快，碰到真实查询、租户隔离、在线迁移，问题就露出来。

这条推文提到一个 Claude Code 专用 Agent：Database Architect。项目页给它的定位很硬：任何数据库 schema 工作都该用它，包括小改动和紧急请求。默认 PostgreSQL，会先读现有 migration 目录、ORM schema、命名和 ID 策略，再设计表、索引、约束和迁移。

安装命令：

npx claude-code-templates@latest --agent database/database-architect

项目页显示下载量 12,527，单文件 12.9 KB。它能做的事包括：数据建模，表结构、主外键、索引、约束；技术选型，PostgreSQL、MySQL、MongoDB、向量数据库；多租户设计，RLS、Schema 隔离、独立数据库；性能规划，读写模式、分库分片、扩展方案；数据迁移，生成迁移脚本和回滚方案。

生成 SQL 只是其中一步。比较实用的用法是让它先分析业务访问模式，再设计表结构。评论区有开发者提到，AI 生成表结构时常顾着主外键，忽略 WHERE、JOIN、ORDER BY 和执行计划，索引建多也拖慢写入。还有人建议，别一上来丢一句“帮我设计数据库”，先给一条业务流程：下单后退款、重复支付回调、商品被删除，数据各自怎么办。Agent 如果讲不清这些异常流程，ER 图再完整也没用。

多租户是另一个容易埋雷的地方。有网友问 SaaS 该选租户级 schema 还是 row-level tenant_id。讨论里更倾向初期用 tenant_id 加 RLS，开发和迁移成本低，统一维护方便。但前提是所有查询都受租户隔离约束，不能只靠应用层过滤。租户数量少、隔离要求高时再考虑独立 Schema。真正容易踩坑的是跨租户数据泄露和后期迁移。Agent 的规则里也写了：每张租户表加 tenant_id，用复合外键防跨租户引用，开 RLS 并 FORCE，应用角色不能有 BYPASSRLS。这些细节比“支持多租户”四个字有用。

已有真实数据的库，改字段类型、拆表、加约束都可能影响线上业务。迁移脚本不只看 SQL 对不对，还要看锁表时间、数据兼容性和回滚方案。最好拿生产数据量级的测试库跑一遍。项目页的规则提到，在线变更要设 lock_timeout，用 CREATE INDEX CONCURRENTLY，约束先 NOT VALID 再 VALIDATE，改名走 expand/contract，还要在真实 Postgres 上跑迁移测试。生成 DDL 和迁移脚本仍需要人工审核，尤其生产环境的数据变更。

分表时机也别让 Agent 猜。评论区有人说，分表不能只看数据量，还得结合查询模式、增长速度、索引大小和实际性能瓶颈，拿真实业务数据和执行计划验证。

更稳的流程是：先把核心实体、业务关系和数据约束定下来，再让 Agent 补索引建议、DDL 和迁移脚本。可以先让它画 ER 图，但别急着建表。把核心业务流程、异常场景讲清楚，再拿实际查询和数据增长预期检查索引和约束，确认后生成 DDL。表结构这块，前期省下的时间，后面很容易加倍还回去。

你现在用 AI 开发项目，会让它直接设计数据库，还是自己先把表结构定好？