锁定具体业务动作与数据流起点

具体怎么操作？第一步，直接在提示词开头写明：“你是一名有6年电商中台经验的DBA，正在为‘用户下单后30分钟内未支付自动关单’这个功能设计订单库表结构。” 这一步的目的是给模型一个具体的身份和场景，而不是让它自由发挥。

第二步，紧接着补充一句约束：“不讨论通用范式理论，只围绕‘关单触发条件判断’‘状态变更日志留存’‘下游库存回滚通知’这三个动作展开字段设计。” 这样就把讨论范围限定在特定实际问题中，模型就不会再去复制范式理论。

必须注意的是，提示词里不能出现“应遵循”“建议采用”“通常需要”这类指导性措辞，否则模型会自动填充教科书式原则，徒增噪音。

用真实SQL片段锚定字段粒度

方法很简单：把你要讨论的SQL语句直接贴进提示词。例如，对于自动关单场景，你的查询可能是这样的：

SELECT order_id, status, updated_at FROM orders WHERE status = 'unpaid' AND updated_at < NOW() - INTERVAL 30 MINUTE;

然后加一句：“请基于此查询语句，指出当前orders表缺失的2个关键字段，并说明每个字段的类型、是否允许NULL、默认值及索引策略。” 这样AI就不会凭空编一些“id、name、time”这种玩具级字段。

另一个做法是提供已有表结构截图的文字转录。哪怕只有三行：

orders表现有字段：order_id(BIGINT PK)、user_id(INT)、total_amount(DECIMAL)；无updated_at、expire_at、version字段。

直接复制建表语句进来就行。模型看到真实字段名和类型，就不会再编造那些无关痛痒的字段。

强制输出可验证的冲突点

这是最关键的一步：让模型直接暴露潜在的设计漏洞。具体来说，要求模型列出1个“看似合理但会导致关单漏判”的字段设计错误。例如，把expire_at设为DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP。这个设计乍一看很合理——自动记录时间戳，但它会在更新status时自动更新expire_at，导致原本未支付的订单被误判为已超时。

紧接着，要求模型写出对应的反例SQL，证明该设计在并发场景下失效。比如：

INSERT INTO orders(order_id,user_id,total_amount) VALUES(1001,888,99.9);
UPDATE orders SET status='paid' WHERE order_id=1001;
-- 此时expire_at被自动更新，导致30分钟后无法识别原未支付订单。

最后，要求给出修复方案。修复方案必须包含ALTER TABLE语句和对应索引命令，不能只说概念。例如将expire_at改为固定值，并确保它不会被自动更新。

这三步必须连贯，中间不能插入解释性文字。模型一旦开始讲原理，就又滑向泛泛而谈。