核心是将业务理解精准翻译为模型可执行指令，关键在明确角色、限定边界、提供上下文、分步引导和强制结构化输出+人工校验。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
用 Prompt 生成 SQL 和数据库设计，核心不是让大模型“猜”，而是把人对业务、结构、约束的理解，精准翻译成它能执行的指令。关键在明确角色、限定边界、提供上下文、验证输出。
明确角色与任务边界
不要只写“帮我写个SQL”，要告诉模型它此刻是“有10年经验的PostgreSQL DBA，专注电商订单系统”。角色设定直接影响输出质量：
- 指定数据库类型（MySQL/PostgreSQL/SQLite），因为语法和函数有差异，比如分页用 LIMIT OFFSET 还是 FETCH FIRST
- 说明任务类型：是“从自然语言需求生成SELECT”、“反向推导建表语句”，还是“根据已有表结构优化索引建议”
- 禁用模糊表述，例如把“查最近的订单”改成“查询2024年6月1日至今、状态为‘已支付’的前20条订单，按创建时间倒序”
提供最小但完整的上下文
模型没有记忆，也不懂你的表。每次 Prompt 都要带必要元信息：
- 已有表名 + 关键字段（含类型和含义），例如：users(id: INT PK, name: VARCHAR(50), email: VARCHAR(100) UNIQUE)
- 业务规则约束，例如：“一个用户可下多个订单，但每个订单只能归属一个用户”“折扣码最多被使用3次”
- 避免贴全DDL——只给当前任务相关的部分，冗余信息反而干扰推理
分步引导，不依赖单次生成
复杂逻辑很难一步到位。拆解为可验证的小任务：
- 先让模型输出ER关系草图（用文字描述：用户→1对多→订单；订单→1对多→订单项）
- 再基于该关系，生成各表CREATE TABLE语句，要求显式写出外键和ON DELETE行为
- 最后补充常用查询示例（如“查某用户所有未发货订单及商品总数”），并要求附带注释说明JOIN逻辑
强制结构化输出 + 人工校验点
用格式指令降低后期处理成本：
- 要求SQL输出包裹在
```sql块中，注释用--而非/* */，方便复制粘贴 - 对建表语句，明确要求字段顺序：主键 → 业务字段 → 外键 → 时间戳字段 → 索引说明（另起一行，以-- INDEX: 开头）
- 必须标注潜在风险，例如：“注意：price字段未设NOT NULL，业务层需保证必填”或“WHERE created_at > '2024-01-01'可能无法走索引，建议在created_at上建索引”
不复杂但容易忽略：生成结果不是终点，而是校验起点。每条SQL在真实库中跑explain，每个外键确认级联行为是否符合预期，每个NULL约束对照业务规则复核——Prompt 是杠杆，人仍是支点。
