如何让AI准确按照你的需求生成建表语句？核心不在于字段类型的选择，而在于你提供的信息是否足够具体、视角是否恰当。简单来说，不要指望AI能猜测你的意图，你必须将业务场景、约束条件和交付标准逐条明确说明。接下来从几个实战角度拆解，看看提示词如何编写才能直接有效。

按业务角色视角编写提示词

首先明确：这张表的使用者是谁、解决什么问题、受哪些实际条件限制。例如“为客服系统后台开发人员设计一张工单流转记录表，需要支持按处理人ID快速查询未关闭工单，并且所有时间字段必须使用UTC时区存储”——这样一句话就锚定了业务角色和核心行为。

然后，逐一说明每个字段的业务含义和强制约束，用分号分隔：

“ticket_id（唯一主键，bigint自增）；assignee_id（处理人ID，非空，关联user表id）；status（状态码，枚举值：'open','pending','closed'，默认'open'）；created_at（创建时间，datetime NOT NULL）”

最后，收尾技术交付要求，必须一字不漏：

“输出纯CREATE TABLE语句，不带注释，不带IF NOT EXISTS，字符集使用utf8mb4，排序规则使用utf8mb4_unicode_ci；【如果漏掉字符集声明，Copilot默认生成latin1，写入中文数据时会变成乱码】”

采用这样的写法，Copilot就不会绕圈子跟你讨论“建议字段类型”，而是直接输出DDL。（注意一个细节：如果不声明字符集，默认生成latin1，中文数据写入后会变成问号——这个提示词中的陷阱，需要提前堵上。）

按数据流向视角编写提示词

方法一：从上游源头出发
这张表接收来自API网关的JSON日志，字段映射关系如下：req_id→request_id（varchar(64)）、client_ip→ip_address（varchar(45)）、timestamp→event_time（datetime，需要将ISO8601格式转换）、body→payload（json，允许NULL）。请生成建表语句，payload字段必须使用JSON类型，event_time设置索引。

方法二：向下游消费端对齐
该表将由BI工具通过ODBC直接连接，BI侧要求所有数值字段必须为非空且带有默认值，字符串字段长度预留30%冗余。请按照此要求生成建表语句，其中user_name字段最大长度设置为VARCHAR(128)，score字段设置为DECIMAL(5,2) DEFAULT 0.00。

两种方式，一种关注源头映射，一种聚焦下游消费。选择哪种取决于你的上下文场景——关键是让AI清楚这张表的上下游关系，而不是凭空想象。

按运维安全视角编写提示词

① 首先声明部署环境的硬性限制
“在MySQL 8.0.33集群上建表，禁用全文索引和GIS类型，所有TEXT字段必须指定长度（如TEXT→MEDIUMTEXT），主键必须为BIGINT UNSIGNED AUTO_INCREMENT。”

② 再嵌入权限与审计需求
“表名设置为audit_login_log；需要包含created_by（varchar(32)，记录操作人账号）、created_at（datetime，默认CURRENT_TIMESTAMP）；【created_by不能设置为外键，因为审计表需要独立于用户主表存在】”

③ 最后指定物理存储策略
“启用ROW_FORMAT=DYNAMIC；设置PAGE_COMPRESSED=1；添加注释‘记录用户登录行为，保留180天’。”

运维视角常常被忽视，但这正是生产环境中最令人头疼的问题——索引不完整、字符集错误、存储策略缺乏规划，上线后再修改就来不及了。按照上述三步执行一遍，AI生成的DDL基本可以直接部署到集群中运行。