对 SQL 最安全的用法是：只读环境、脱敏数据、先讲清楚再改写。 不要把生产写权限交给模型，也不要在未理解的情况下直接应用重写。

流程

  1. 用只读账号导出执行计划或慢查询文本，去掉敏感字面量。
  2. 让模型先用白话解释查询在做什么、连接键是什么。
  3. 让模型列出风险：全表扫描、错误去重、隐式转换等（基于你提供的计划文本，不编造库规模）。
  4. 再要一到两个重写候选，并要求说明等价性假设。
  5. 在预发用真实数据分布验证，再谈上线。

提示词

先不要给最终 SQL。请：1) 解释意图 2) 列出你不确定的 schema 点 3) 基于【执行计划文本】指出可能问题 4) 再给重写候选与等价性假设。
禁止编造表行数；缺少信息就提问。
【SQL】【计划】【索引信息】

实践提醒

重写候选通过后，补一条回归用例或说明文档，写清假设的数据分布。若线上计划与预发差异大，先查统计信息是否过期，再谈改写。把解释阶段的白话结论留给值班同事，降低知识单点。

执行时请保持单一事实源：输入没有的数字、负责人与截止日期，输出就不要出现。把不确定写清楚，比生成听起来完整却无法核对的句子更有用。若连续两次结果漂移很大，先检查是否混入未脱敏或互相矛盾的材料，再考虑换模型。

也可以把本页提示词改成团队共享片段：只开放「材料区」给同事粘贴，固定规则区由维护人更新。这样能减少每人私改导致的格式分裂，也方便在复盘会上对照同一版本讨论。

也可以把本页提示词改成团队共享片段：只开放「材料区」给同事粘贴，固定规则区由维护人更新。这样能减少每人私改导致的格式分裂，也方便在复盘会上对照同一版本讨论。

相关：报错日志排查、AI 编程安全、调试指南。

把本次用过的提示词与输入输出一并存档，方便对照下次同类任务的差异。凡标注虚构或示意的人名、金额、订单与指标，一律不得进入正式提交或对外承诺。若材料涉及客户或员工个人信息，先按公司数据分级选择允许的工具，再开始粘贴。做完一次闭环，用三句话记录：最有效的约束、仍需人工的步骤、下版提示词要改哪里。

把本次用过的提示词与输入输出一并存档，方便对照下次同类任务的差异。凡标注虚构或示意的人名、金额、订单与指标，一律不得进入正式提交或对外承诺。若材料涉及客户或员工个人信息，先按公司数据分级选择允许的工具，再开始粘贴。做完一次闭环，用三句话记录：最有效的约束、仍需人工的步骤、下版提示词要改哪里。