【必须】先完整输出结构化框架，再进入具体设计讨论；未输出框架前，禁止出现任何表名、字段名、数据类型、索引建议或SQL片段。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要Claude在参与数据库设计讨论前，先输出一份清晰、可验证的结构化框架，而不是直接跳进字段命名或索引选择等细节——没有结构的讨论容易陷入碎片化争执，导致关键维度被遗漏、约束被忽略、权衡无据可依。
强制Claude先输出结构的提示词写法
在提示词最开头第一行就写：【必须】先完整输出结构化框架，再进入具体设计讨论；未输出框架前，禁止出现任何表名、字段名、数据类型、索引建议或SQL片段。
这道硬性指令能拦住Claude惯性直奔实现细节的倾向。它默认会把“用户表该加什么字段”当作首要问题，但真正的设计瓶颈往往卡在“要不要分库”“主键用UUID还是自增”“读写分离策略是否纳入本次设计范围”这些结构性判断上。
结构化框架必须包含的三类要素
明确要求框架只含以下三类内容，缺一不可：
方法一：核心实体与边界
– 明确列出本次设计覆盖的【全部业务实体】（如：订单、商品、库存、用户、支付单），不含派生视图或临时计算表
– 标注每个实体的【数据主权归属系统】（如：订单归属订单中心，库存归属仓储服务）
– 划定【本次设计不覆盖的边界】（如：不涉及物流轨迹表、不处理跨境税费计算逻辑）
方法二：关键约束与决策锚点
– 写明【强一致性要求项】（如：订单创建与库存扣减必须原子完成）
– 列出【不可妥协的性能基线】（如：订单查询P95≤120ms，日均写入峰值≥8万条）
– 注明【基础设施限制】（如：仅允许使用PostgreSQL 15.6，禁止引入Redis作为主存储）
方法三：演进路径与扩展接口
– 给出【未来6个月必扩字段清单】（如：订单表需预留tax_calculation_id、currency_code字段）
– 定义【跨系统数据同步机制】（如：用户变更通过CDC投递至Kafka，下游消费方自行构建宽表）
– 标明【版本兼容策略】（如：v2订单表兼容v1读取逻辑，新增字段设DEFAULT NULL且非NOT NULL）
实操示例：电商订单库设计提示词
第一步：复制粘贴以下完整提示词到Claude对话框
【必须】先完整输出结构化框架，再进入具体设计讨论；未输出框架前，禁止出现任何表名、字段名、数据类型、索引建议或SQL片段。我们正在为新电商业务设计核心订单数据库。当前系统为单体Java应用，计划3个月内拆分为订单中心+仓储服务+支付网关。已确认使用PostgreSQL 15.6，集群部署在阿里云RDS，DBA团队不允许执行pg_dump全量备份超过15分钟。请按以下三类要素输出结构化框架：
① 核心实体与边界
② 关键约束与决策锚点
③ 演进路径与扩展接口
第二步：等待Claude返回纯框架内容（应仅含条目式列表，无解释、无代码、无推荐）
第三步：确认框架中已包含“库存扣减必须原子完成”“订单查询P95≤120ms”“预留tax_calculation_id字段”三项后，再输入：“现在基于上述框架，开始设计orders表的字段与主键策略。”
