① 【字段命名】→ 所有列名须用snake_case，禁止驼峰、中文、下划线开头或结尾；反例：userName、用户姓名、_id、name_。 ② 【主键设计】→ 每张表必须有单一自增BIGINT主键，命名为id，禁止联合主键或UUID主键；反例：PRIMARY KEY (order_id, sku_id)、id UUID DEFAULT gen_random_uuid()。 ③ 【外键约束】→ 必须显式声明ON DELETE RESTRICT，未声明则视为违规；反例：FOREIGN KEY (user_id) REFERENCES users(id)。 ④ 【字符集】→ 所有TEXT/VARCHAR列所在表的CHARACTER_SET_NAME必须为'utf8mb4'（查INFORMATION_SCHEMA.TABLES）；反例：表默认字符集为latin1。 ⑤ 【索引覆盖】→ WHERE/JOIN/ORDER BY中出现的单表字段组合，必须存在对应B+树索引；反例：WHERE status=1 AND created_at > '2024-01-01' 无联合索引(status,created_at)。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让通义千问输出一份可用于数据库设计评审的检查清单，而不是泛泛而谈“注意性能”或“要建索引”，而是能逐项核对、带明确判断标准的具体条目。
明确评审目标和范围
先在提示词开头锁定场景：告诉模型这是用于关系型数据库（如MySQL/PostgreSQL）的逻辑与物理设计评审，对象是新建业务模块的DDL脚本或ER图，不包含运维配置或SQL调优。
写明输出格式必须为带编号的纯文本清单，每项含【检查项】【判断标准】【反例说明】三要素，不加解释性段落。
这一步不能省略——【若漏写“仅限DDL和ER图”这一约束，模型可能混入慢查询优化、备份策略等超范围内容】。
注入结构化约束条件
方法一：用分隔符强制字段对齐
在提示词中写：“请严格按以下模板生成每一项：
① 【字段命名】→ 所有列名须用snake_case，禁止驼峰、中文、下划线开头或结尾。
② 【主键设计】→ 每张表必须有单一自增BIGINT主键，命名为id，禁止联合主键或UUID主键。”
方法二：用否定式排除模糊表述
加入：“禁止出现‘合理设置’‘酌情考虑’‘视情况而定’等无法落地的措辞；所有标准必须可由DBA一眼判定对错。”
方法三：绑定真实约束规则
例如：“外键必须显式声明ON DELETE RESTRICT，未声明则视为违规；TEXT类型字段必须有长度注释说明预期最大字节数。”
要求模型自我验证输出
第一步：让模型先列出它认为最关键的5类风险维度（如范式合规、索引覆盖、权限隔离、时区处理、字符集一致性）。
第二步：针对每个维度，生成不少于3条可执行检查项，且每条必须含一个具体技术锚点（如“INFORMATION_SCHEMA.COLUMNS中CHARACTER_SET_NAME≠'utf8mb4'”）。
第三步：对生成的全部条目做交叉校验——删除任何一条中缺少【判断标准】或【反例说明】的项，直至剩余条目100%满足三要素结构。
这一步操作起来很简单，直接把校验逻辑写进提示词末尾即可：“最后输出前，请逐行检查：若某条未出现‘→’符号分隔三个部分，则整条删除。”
