明确评审维度与问题类型

先在Trae中新建一个提示词项目，标题设为“数据库变更评审检查清单生成器”。**这里有个关键点：必须选择“结构化输出”模式，否则生成的结果会像脱缰的野马，格式跑偏，没法稳定输出带编号的清单。** 在系统提示框里，你需要输入这样一段话，定义它的“人设”和核心任务： “你是一个资深DBA，熟悉MySQL/PostgreSQL的生产环境规范。请根据用户提供的SQL变更类型（例如：建表、改表、删表、索引调整、数据迁移），输出对应维度的评审问题检查清单。每项检查清单需要包含：编号、问题描述、风险等级（高/中/低）、以及是否可自动化检测（是/否）。”

设定SQL变更类型的触发逻辑

这里有两个办法让“生成器”搞懂你要检查什么类型的SQL，你可以根据习惯选择： **方法一：让用户在输入时手动声明** 比如，在输入框第一行写明：“变更类型：添加唯一索引”，然后紧跟SQL语句：“ALTER TABLE users ADD UNIQUE (email);”。这样最清晰，适合有协作规范的团队。 **方法二：让Trae自己“猜”关键词** 配置一些触发规则，比如： * 看到“ADD INDEX”或“CREATE INDEX”，就自动归类到“索引调整”。 * 看到“DROP COLUMN”或“MODIFY COLUMN”，就归到“改表”。 * 看到“DROP TABLE”——直接拦截并标红“高危操作，禁止执行”，这个没得商量。 **必须警惕的是：** 当SQL里同时出现ALTER和DROP关键字时，必须让Trae优先触发“改表”这个分支，千万不能拆成两个独立流程去处理。否则，一旦遇到“字段删除+类型变更”叠加的场景，很容易忽略掉隐式锁带来的阻塞风险，这在生产环境里可是个大坑。

控制输出格式与字段顺序

这一步是让输出结果看起来专业、统一的关键，操作起来很简单，直接把下面的格式规则粘贴进Trae的“输出约束”文本框即可生效。 * **第一步：** 强制要求每条检查项以数字编号开头，编号后紧跟英文句点加空格，比如“1. ”、“2. ”。 * **第二步：** 问题描述必须用疑问句，而且主语统一为“该SQL”，这样描述起来清晰、聚焦。 * **第三步：** 风险等级统一放在括号内，紧接问题描述末尾，不换行。例如“（高）” * **第四步：** 最后一列“是否可自动化检测”，必须用中文“是”或“否”，不要用“✓/✗”或“Y/N”这种花里胡哨的符号，不然校验起来麻烦。 来看一个正确的输出示例，这样写就对了： 1. 该SQL是否在高频查询字段上创建了非覆盖索引？（高）否 2. 该SQL是否对超过500万行的表执行了无WHERE条件的UPDATE？（高）是