在数据库设计评审会上，最令人头疼的莫过于听到“建议加索引”“注意主键”这类笼统结论。要想快速输出可直接落地的字段定义、索引策略与约束逻辑，必须借助结构化提示词驱动通义千问，生成能直接粘贴到建表语句中、能让DBA一目了然、能让开发人员立即写入DDL脚本的具体操作步骤。具体该怎么做？先锁定核心实体与业务状态流转路径，再提供字段描述或关系图示，最后强制输出包含ENGINE、CHARSET、显式外键、CHECK约束、规范命名的纯SQL建表语句。

在数据库设计评审会上，快速产出可落地的字段定义、索引策略和约束逻辑是核心目标。不能只让通义千问输出“建议加索引”“注意主键”这类模糊结论，必须让它生成能直接粘贴进建表语句、能被DBA一眼看懂、能被开发立刻写进DDL脚本的具体步骤。

第一步：锁定核心实体与业务动线

打开需求文档，逐句标记所有名词：订单、优惠券、履约单——这些就是待建模的实体。再标出所有包含“创建”“更新”“失效”“核销”等动词的句子，这些就是关键业务状态流转节点。若省略此步骤，后续所有字段都可能沦为空中楼阁。

将已确认的实体名和状态动词整理成两栏表格：实体列→[user, order, coupon]；状态列→[create, expire, use, refund]。完成此步骤后，你便拥有了建模的锚点，模型不会再凭空编造“积分快照”“风控评分快照”这类无人提及的内容。

第二步：用字段列表式提示词喂给通义千问

方法一：直接喂结构化字段描述

例如，需要设计三张表：user_info表，字段包括user_id（主键，BIGINT）、mobile（唯一索引，NOT NULL）、status（tinyint，0=正常，1=冻结，2=注销）、create_time（datetime，默认CURRENT_TIMESTAMP）；order_master表，字段包括order_id（主键）、user_id（外键→user_info.user_id）、amount（decimal10,2）、pay_status（tinyint，0=待支付，1=已支付，2=已退款）；coupon表，字段包括coupon_id（主键）、code（varchar32，唯一）、valid_start_date（date）、valid_end_date（date）。然后指示通义千问：请为每张表生成完整CREATE TABLE语句，需包含ENGINE=InnoDB、CHARSET=utf8mb4、COMMENT中文说明，且所有外键必须显式声明ON DELETE RESTRICT。

方法二：用关系图示法补全路径约束

再比如，表关系为user_info(user_id)←order_master(user_id)←order_item(order_id)→product(prod_id)。关键约束：order_item.quantity必须≥1且≤999；product.price必须>0；order_master.create_time ≥ '2026-07-01'才允许插入。然后指示通义千问：请生成order_item和product两张表的建表语句，字段必须包含上述校验字段，CHECK约束要写进DDL，不要用触发器替代。

第三步：强制输出可执行DDL片段

第一步，在提示词末尾添加硬性指令：“只输出纯SQL代码块，不加任何解释、不加‘以下是’‘建议如下’等引导语，不换行不缩进，每条CREATE TABLE语句以分号结尾。”

第二步，绑定具体执行环境：所有时间类型用datetime而非timestamp；所有字符串字段用utf8mb4_bin排序规则；主键必须显式命名为pk_表名；唯一索引命名为uk_字段名。

第三步，注入校验动作：生成后，请自行检查：① 每个外键是否都写了REFERENCES；② 每个CHECK约束是否都用AND连接多个条件；③ 所有NOT NULL字段是否都配了DEFAULT值或注释说明为空原因。若任一条件不满足，整段重写。

这一步操作起来很简单，直接复制输出结果就能进MySQL执行，不用再手动删注释、补分号、改排序规则。