☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要让trae生成的数据库迁移说明像真实用户所写，需设定“刚接手老项目的后端工程师”角色，明确读者为测试/dba/前端，绑定618大促和12%超时率等真实业务背景，用“请+动作+结果”句式、动词化描述变更、补充执行细节（如凌晨2点、47秒、1.2亿行），并列出三方协作项、回滚条件及flyway兼容性提醒。
要让trae生成的数据库迁移说明文档读起来像真实用户写的，而不是ai套话堆砌，关键在于注入具体上下文、真实约束和人话表达——比如明确谁在看这份说明、为什么改这张表、上线后哪几个接口会受影响。
用角色+场景双锚点锁定输出风格
第一步：在提示词开头强制设定双重身份——“你是一位刚接手老项目、正在修复订单超时问题的后端工程师”，不是“数据库专家”或“系统架构师”。这个角色天然带出技术债感、时间压力和实操视角。
第二步：绑定阅读对象，“这份说明将贴在团队飞书群，供测试同学验证、DBA审核、前端同事同步字段变更”。AI立刻知道不能写“建议添加索引”，而要写“测试同学请重点检查订单列表页加载速度，DBA请确认idx_order_status_created_at已建好”。【不写“建议”“应”“需”，全部改用“请”+动作+结果】
第三步：插入一句真实业务钩子，例如“本次变更是为支撑618大促期间订单状态实时刷新，当前超时率已达12%”。数字和时间节点一加，整段文字就从模板变成战报。
把SQL脚本转成人类可读的“发生了什么”
方法一：用“动词+影响范围+触发条件”重写变更描述
不要写：“ALTER TABLE order ADD COLUMN timeout_at DATETIME DEFAULT NULL”；改成：“给order表加timeout_at字段，所有未完成支付的订单会在创建30分钟后自动填入超时时间——这是为了给风控系统提供统一超时判断依据。”
方法二：对每个字段变更追加一句“谁会用它、怎么用”
比如新增status_version字段，必须补上：“前端提交订单时会带上这个版本号，后端校验失败直接返回409，避免并发修改覆盖。”这句比任何DDL注释都管用。
方法三：用括号补充真实执行细节（AI常忽略这点）
“此脚本需在凌晨2点执行（避开订单高峰），预计耗时47秒（基于生产库1.2亿行数据压测结果），执行期间order表写入会阻塞约0.3秒。”【没有“预计”“大概”“可能”，所有时间/数据量/影响范围必须给确定值】
嵌入真实协作摩擦点
第一步：列出本次迁移必须同步的三方
① 测试同学：需验证订单详情页“超时倒计时”组件是否正常渲染；
② 运维同事：需在执行前关闭Prometheus对order表的慢查询采集（避免误报）；
③ 前端Leader：确认下周迭代排期是否允许他们提前接入timeout_at字段（否则需兼容旧逻辑）。
第二步：标注回滚条件与操作路径
“若出现订单创建失败率突增＞5%，立即执行rollback.sql（已附在附件），并@我手动清理残留的timeout_at非空记录——别等晨会，现在就做。”
第三步：写一句只有真实开发者才懂的提醒
“注意：Flyway校验时会因MySQL 5.7的TIMESTAMP默认值限制报错，已在v20260528__fix_timeout_at.sql中用SET SQL_MODE=''临时绕过，DBA审核时请重点关注此兼容性处理。”
