先说几个核心判断。要让Copilot生成的建表文档一眼被DBA扫出字段逻辑、主键意图和索引必要性，关键不是堆砌“需具备高可用性”这类空话，而是把物理约束、业务动因和验证动作全部钉死在提示词里。否则，它默认会把“建表需求”等同于教科书式的DDL说明，跟实际业务场景脱节。
来看具体操作。
锁定唯一业务实体与核心操作动线
提示词开头，直接写明本次建表服务的唯一业务实体全称。比如“客户退货单（RET-2026-Q3）”，而不是模糊的“退货相关表”或“售后数据表”。Copilot看到缩写+年份+季度编号，会自动关联到真实系统命名规范，不会生成“t_return_info”这种没有上下文的泛化表名。
紧接着，绑定这个实体的核心操作动线。比如“用户提交→客服初审→仓库实退→财务冲账→归档”，必须按真实流转顺序列出5个动词节点。跳过这一步，Copilot大概率会把字段设计成静态快照结构，漏掉“初审人ID”“冲账时间戳”这类过程态字段。
操作很简单，直接把“用户提交→客服初审→仓库实退→财务冲账→归档”复制进提示词就行。
强制字段描述含可验证动作
这里有一个核心原则：每个字段的描述必须带一句“谁在什么场景下用它做什么”。来看例子：
✅ 正确写法：“ret_status（退货状态）→ 客服在工单系统点击‘转仓库’按钮时，由前端自动写入值‘pending_warehouse’”。
❌ 错误写法：“ret_status：标识退货当前所处阶段”。这种写法，Copilot根本无法判断是否要加NOT NULL约束或CHECK约束。
对于必填字段，还需要追加触发条件。比如“ret_amount（退货金额）→ 仅当ret_type=‘full_refund’时强制填写，否则置为NULL；若为空且ret_type≠‘partial_refund’，系统拦截保存并弹窗提示‘请先选择退款类型’”。关键点在于：不写‘金额字段需校验’，而写‘ret_amount为空且ret_type≠partial_refund时拦截保存’。这样Copilot才能生成精准的约束逻辑。
索引需求必须绑定查询频次与超时阈值
第一步：列出三个最高频的真实查询场景。
① 客服查某客户近30天所有退货单 → WHERE cust_id = ? AND create_time >= DATE_SUB(NOW(), INTERVAL 30 DAY)
② 财务按日汇总各仓退货金额 → WHERE warehouse_id = ? AND DATE(create_time) = ?
③ 仓库按SKU统计当日待处理退货数 → WHERE sku_code = ? AND ret_status = ‘pending_warehouse’ AND DATE(create_time) = CURDATE()
第二步：为每个场景标注SLA要求。
① 必须≤150ms返回结果 → 建复合索引(cust_id, create_time)
② 必须≤800ms完成聚合 → 建索引(warehouse_id, create_time, ret_status)
③ 必须≤50ms响应 → 建索引(sku_code, ret_status, create_time)
第三步：禁用模糊表述。删除所有“建议添加索引”“可考虑优化查询性能”等句式。只保留“建索引(X,Y,Z)”格式，Copilot会自动补全CREATE INDEX语句，而且不会多建冗余索引。
DDL输出必须含环境验证指令
这一步很容易被忽略，但恰恰是验证DDL可用性的关键。有两种方法：
方法一：指定测试环境执行路径。例如“在DEV环境执行：mysql -u dev_db -p -e ‘DESCRIBE ret_2026_q3;’ → 验证ret_amount字段类型为DECIMAL(12,2)且允许NULL”。
方法二：绑定失败案例反向验证。粘贴一句上周线上事故记录：“6月28日14:22，因ret_status未设DEFAULT值，新单插入时触发NULL插入失败，导致37笔退货卡在‘draft’状态”。Copilot会在DDL中自动补上DEFAULT ‘draft’ NOT NULL，并在备注里写明“防6.28同类故障”。
必须提供具体日期和错误现象，否则Copilot会忽略验证环节，只输出标准CREATE TABLE语句。
