🛡️ AI 辅助数据建模通用 SOP (v1.0)

核心理念:

DBA 思维优先: 永远先设计 SQL (Source of Truth)，再生成代码 (ORM)。
可视逻辑验证: 在写代码前，必须通过 ER 图确认业务逻辑闭环。
对抗性评审: 利用 AI 的多重人格（架构师/攻击者）自我找茬。

📋 准备工作：定义变量

在使用以下 Prompt 前，请先在脑海或记事本中替换以下占位符：

{技术栈}: 例如 PostgreSQL 15, MySQL 8.0, TiDB
{ORM框架}: 例如 GORM (Go), TypeORM (Node), Hibernate (Java)
{业务模块}: 例如用户中心, 订单交易, 库存管理
{具体需求}: 粘贴你的 PRD 片段或业务规则描述

阶段一：上下文注入与规范确立 (Context & Standards)

目的: 确立“宪法”。防止 AI 自由发挥导致命名风格混乱或忽略关键字段。

🤖 通用 Prompt (复制使用)

你现在是我的 **Senior DBA (首席数据库管理员)** 和 **后端架构师**。
我们将基于 `{技术栈}` 和 `{ORM框架}` 进行 `{业务模块}` 的数据库设计。

在开始具体设计前，请牢记并遵守以下 **[设计宪法]**:

1.  **命名规范:**
    - 表名: 复数形式，snake_case (如 `user_orders`).
    - 字段: snake_case (如 `is_verified`).
    - 索引: `idx_表名_字段` (普通), `uniq_表名_字段` (唯一).
    - 外键: `fk_本表_关联表`.

2.  **基础字段 (Base Model):**
    - 所有业务表必须包含: `id` (主键), `created_at`, `updated_at`.
    - 需要软删除的表必须包含: `deleted_at`.
    - 乐观锁(如有需要): `version`.

3.  **类型约束:**
    - 金额: 严禁使用 Float/Double，必须使用 `DECIMAL` 或 `BigInt` (存分).
    - 枚举: 尽量在应用层处理，数据库存 `SmallInt` 或 `String`，避免使用 DB 级 ENUM.
    - 时间: 统一使用带时区的 `TIMESTAMPTZ` (PostgreSQL) 或 `DATETIME`.

4.  **安全与性能:**
    - 必填字段显式标记 `NOT NULL`。
    - 外键必须加索引。
    - 物理外键约束建议使用 `ON DELETE RESTRICT` 防止误删，除非明确需要级联。

收到请回复：“DBA 模式已就绪，请提供具体业务需求。”

阶段二：概念验证 (Conceptual Modeling - ER Diagram)

目的: 宏观排雷。通过可视化图表快速识别逻辑错误（如：1 对多搞成了多对多，或者环状依赖）。

🤖 通用 Prompt (复制使用)

请根据以下 `{具体需求}`，绘制 **Mermaid 格式** 的 ER 关系图 (Entity Relationship Diagram)。

**需求输入:**
"""
(在此处粘贴你的业务逻辑，例如：一个用户可以有多个角色，文章必须属于一个分类…)
"""

**绘图要求:**
1.  展示实体(Entity)及其核心属性。
2.  精准标注关系基数 (Cardinality):
    - `||--o{` (1 对多)
    - `}|--|{` (多 对 多，需画出中间表)
    - `||--||` (1 对 1)
3.  在图表下方简要说明关键关系的业务含义。

阶段三：物理建模 (Physical Schema - SQL DDL)

目的: 产出真理。这是最关键的一步，SQL DDL 定义了数据的最终形态。

🤖 通用 Prompt (复制使用)

ER 图确认无误。请生成 **生产级 (Production-Ready) 的 SQL DDL 建表脚本**。

**执行要求:**
1.  **完整性:** 包含 `CREATE TABLE`, `CREATE INDEX`, 以及必要的 `COMMENT ON` 语句。
2.  **字段细节:**
    - 针对 JSON 数据使用数据库原生类型 (如 PG 的 `JSONB`)。
    - 针对长文本使用 `TEXT`。
    - 默认值 `DEFAULT` 处理到位 (如 `DEFAULT 0`, `DEFAULT FALSE`, `DEFAULT NOW()`).
3.  **约束定义:**
    - 明确定义 `PRIMARY KEY`。
    - 显式定义 `CONSTRAINT` 名称 (便于排错)。
4.  **索引策略:**
    - 除了主键，请根据业务查询场景（如“按状态查询”、“按时间范围排序”）主动添加辅助索引。
    - 解释每个索引添加的理由。

请直接输出 SQL 代码块。

阶段四：代码映射 (Code Generation - ORM Struct)

目的: 翻译。将 SQL 完美映射为代码，利用 AI 自动处理繁琐的 Tag。

🤖 通用 Prompt (复制使用)

基于上述生成的 SQL 脚本，请编写对应的 `GORM (Go)` 模型代码 (Entity/Model)。

**代码要求:**
1.  **Tag 映射:** 完整包含 DB 列名映射、主键定义、默认值定义。
    - (若为 GORM): 使用 `gorm:"column:xyz;type:…"`.
2.  **JSON 序列化:**
    - 所有字段添加 `json:"camelCaseName"`.
    - **敏感字段** (如密码、盐值) 必须设为 `json:"-"` 以防接口泄露。
3.  **类型安全:**
    - 数据库允许 NULL 的字段，在代码中请使用 指针类型 (如 `*string`) 或 专用 Null 类型 (如 `sql.NullString`)。
4.  **文件结构:** 不需要 `gorm.Model` 继承，请显式写出字段，以保证对 JSON Tag 的控制权。

请输出 Go/Java/TS 代码块。

阶段五：红队测试与评审 (Critique & Optimization)

目的: 找茬。让 AI 模拟极端的架构师，攻击当前设计，发现隐患。

🤖 通用 Prompt (复制使用)

现在，请切换角色为 **Google 首席架构师 (Principal Architect)**。
请对上述 SQL 设计进行 **“红队测试” (Red Teaming)** 评审。

**评审维度:**
1.  **扩展性瓶颈:** 如果单表数据量达到 5000 万行，目前的索引设计是否会失效？哪个查询会最慢？
2.  **数据一致性:** 是否存在业务逻辑上需要事务保证，但当前 Schema 难以支持的场景？
3.  **反范式建议:** 是否有过度规范化导致查询需要 Join 太多表？是否建议增加冗余字段？
4.  **边缘情况:** `NULL` 值的处理是否会在聚合查询时导致 Bug？

请列出 top 3 风险点，并给出具体的 **优化建议** (如：修改索引、增加冗余字段、修改类型)。

💡 使用小贴士

不要一次性发完: 强烈建议分步执行。AI 的上下文窗口虽然大，但分步确认能极大提高准确率。
迭代修改: 在“阶段三”生成 SQL 后，如果你发现不满意，手动修改 SQL，然后把修改后的 SQL 发给 AI 进入“阶段四”。永远以 SQL 为准。
保留对话: 把这个对话保留为一个独立的 Session，后续增加字段时，回到这个 Session 继续操作，保持上下文连贯。

6.5 KiB Raw Blame History Unescape Escape

🛡️ AI 辅助数据建模通用 SOP (v1.0)

📋 准备工作：定义变量

阶段一：上下文注入与规范确立 (Context & Standards)

🤖 通用 Prompt (复制使用)

阶段二：概念验证 (Conceptual Modeling - ER Diagram)

🤖 通用 Prompt (复制使用)

阶段三：物理建模 (Physical Schema - SQL DDL)

🤖 通用 Prompt (复制使用)

阶段四：代码映射 (Code Generation - ORM Struct)

🤖 通用 Prompt (复制使用)

阶段五：红队测试与评审 (Critique & Optimization)

🤖 通用 Prompt (复制使用)

💡 使用小贴士

6.5 KiB

Raw Blame History