用途：在新建表、列、关系、索引、键、唯一规则、枚举、JSON 字段、数组或迁移之前，以及在更新数据模型、评审 schema、接受可能损害可维护性/数据质量/隐私/可查询性/性能的数据库变更、把产品需求转化为持久化数据时使用。智能体充当数据库设计顾问而非被动代码生成器。
主要能力与原则：先理解领域再建模，不直接跳到表；了解概念、归属、用户叫法，以及数据的创建、修改、搜索、过滤、展示、报表与删除方式，必要时只问少量高价值的 PO 问题。按应用领域而非 ORM 便利性建模。在多个合理模型间比较领域契合、查询简单性、迁移风险、可扩展性、验证清晰度、可理解性、性能与索引、数据质量、隐私暴露；若用户委托决定，优先可维护性、领域清晰、可查询性、验证清晰、简单与性能。避免为省事而合并表。
Schema 命名：schema 名可作为上下文，但表名移出 schema 后仍须可理解。保留原有足够明确的命名，避免笼统或误导的名称。连接/分配/成员/关联表应体现其角色，例如偏好 experiments.experiments 而非 experiments.base，experiments.experiment_participants 而非 experiments.participants，experiments.experiment_time_slots 而非 experiments.time_slots。
JSON 与数组：默认禁止用于领域数据，除非明确论证。需先问是否会过滤、搜索、报表、验证、连接、审计、权限、迁移或后续加字段；若是则用关系表。仅外部提供方载荷快照、真正无 schema 的稀有元数据、有明确生命周期的临时导入/调试字段、追加型技术日志、团队明确论证的数据库特定高级用法可接受，并需记录拒绝关系模型的原因、是否查询、验证规则、迁移策略与索引策略。
查找表优先于枚举：当值可重命名、隐藏/弃用、需翻译、排序、权限、第三方映射，或由 PO 增改、因项目/客户而异时，用小型引用/查找表。枚举仅适合稳定技术状态，如迁移作业状态 pending、running、failed、completed。
工作流逻辑与完整性：不推荐触发器、存储过程、生成函数等承载应用/业务流程逻辑，工作流校验放后端/服务/仓储层。但允许正常关系完整性：主键、外键、稳定规则用的简单 CHECK、唯一约束、必填非空列、按真实访问模式的索引。简单 CHECK 适合必须始终成立的稳定规则，尤其新项目、新模块或已使用 DB 级校验的 schema。对已有项目，先检查现有风格；若一个 2-3 年项目此前无 CHECK，须明确说明这是引入新的 DB 级校验模式，作为权衡提出并确认，而非默认推荐。
索引：由后端查询、搜索、过滤、连接、唯一性、报表与真实数据量驱动，不要仅因 WHERE 有匹配列就加索引。识别主键、外键、唯一约束、常见 WHERE、连接、搜索字段、排序分页、报表过滤。默认给外键建索引（除非明显不需要），高频高选择性 WHERE 列在考虑行数后建索引，适当为 email、外部 ID、slug、code、name 等搜索字段及业务唯一标识建索引。每个非唯一索引都有写与存储成本。schema 评审、缺陷分类、功能设计或迁移建议中，不应把“添加复合索引”作为建议动作；仅复合唯一约束（如每个 project_id、member_id 一条成员关系）、解释已有复合索引，或用户明确要求查询调优/执行计划分析/索引设计时提及。即使调优，也须有测量证据、高基数预期，并解释现有主键/唯一/单列索引为何不足。对小型有界子集绝不推荐复合索引。不确定时问：该查询预计扫描的行数是否多到现有主键、唯一约束或单列索引不够？若否，避免加索引。
分区：绝不自行引入，仅在用户明确要求或项目已使用时考虑。分区前先考虑更好索引、查询重写、归档、物化视图/读模型、数据保留规则。分区主要在人工作业维护上可接受，如更易归档、按周期/租户删除、备份恢复、生命周期明确的大型运营表。不要仅因表可能变大而分区；若需分区，分区键应与维护操作一致，避免低基数分区，租户/状态分区需有明确运营理由。
仅存应用所需数据（可选建议）：默认避免非明确需要的标准个人字段：first name、last name、date of birth、gender、phone、address、email、profile image。用目的导向问题替代，如不问“需要生日吗”，而问是否为年龄内容、生日消息、法律资格检查等。此建议可能与简单性和可维护性冲突，需判断，不要过度工程化。
基础必守：每表须有真实主键、非空键列、真实关系的外键（除非项目有明确理由不强制）、业务必须成立规则的唯一约束。新表不要用唯一索引替代表身份：表应有主键，业务唯一性另用非空唯一约束。默认代理主键，除非项目已有强约定。键中避免可空列。谨慎以自然/业务列作主键，通常保留为 UNIQUE NOT NULL 业务约束而非表身份。项目通常选 bigint 类生成 ID、UUID 类生成 ID 或清晰的项目标准 ID 策略，除非有强理由，遵循项目约定。PostgreSQL 类系统中不要默认让普通数值列用 bigint；增长估计支持时（审计、事件、日志、计数器等高量表可能超出 int）才用 bigint，普通有界应用数值用更小的合适类型。其余内容资料未完整提供。