不少读者看完 Gamma SQL 提示词教程后，回头自己动手时依然感到迷茫——面对真实的业务报错场景，完全不知道该如何组织提示词。问题并不在于理解力不足，而是缺少一个可以直接填入具体内容的明确框架。当你只对模型说一句“请优化 SQL”时，它会默认启用通用话术库，而不会主动帮你补充字段规则、时间锚点或权限边界这类关键信息。
先拆解“写提示词”这个动作幻觉
Gamma 并不处理“写”这一行为，它只响应“填空”。你必须提供一个带占位符的固定模板，而不是让它从零生成。打开 Gamma 聊天框，在输入框最顶部第一行，务必要粘贴这句话：【每条提示词必须按四段式填充：①目标用户身份（如 Java 后端开发）；②字段原始名 + 业务含义；③异常触发条件（含时间 / 数值 / 状态三要素）；④不可触碰边界（如禁止改表结构）】。如果不把这句放在最顶行，Gamma 会把后续所有内容当作普通对话，自动降级成泛泛而谈。操作很简单，直接复制粘贴到输入框第一行即可。
用真实报错反向推导提示词结构
方法一：从错误日志中提取三要素
找到最近一次 SQL 报错的完整日志，从中提取：错误码（例如“ORA-01722”）、触发值（例如“传入字符串 'abc' 给 NUMBER 字段”）、发生时间（例如“2026-06-12 14:33:07”）。这三者缺一不可——一旦遗漏时间锚点，Gamma 可能会将原因归咎于‘历史数据质量差’这类无法验证的结论。
方法二：将错误三要素填入模板第二段
在四段式模板的第三段位置，写成：“当前 SQL 在 2026-06-12 14:33:07 执行时，因将字符串 'abc' 赋值给 order_amount NUMBER 字段触发 ORA-01722 错误”。注意务必保留单引号包裹的原始值、精确到秒的时间戳、完整错误码——Gamma 正是依靠这些硬特征来激活真实报错路径推理，而不是依赖“类型不匹配”这种概括性描述。
强制绑定可执行载体，封死空泛建议出口
第一步：明确写出你接下来要操作的具体文件
在四段式模板第四段中，写清楚你实际能修改的位置。例如：“我只能修改 order-service 模块下的 OrderQueryMapper.xml 第 47 行 SQL，不能动数据库结构，也不能加新索引”。
第二步：标注不可触碰的物理边界
接着写：“禁止执行 ALTER TABLE、禁止在凌晨 2 点执行 OPTIMIZE TABLE、禁止新增字段供前端展示”。不设定这些限制，Gamma 可能会推荐需要 DBA 权限才能执行的方案，而你根本无法落地。
第三步：将载体信息嵌入问题描述开头
在 Gamma 输入框第一行粘贴完四段式模板后，紧接着另起一行写：“请基于以上约束，为以下 SQL 生成可直接粘贴使用的修复提示词：SELECT * FROM orders WHERE order_amount = #{value}”。这一步能让 Gamma 锁定在真实可编辑的 SQL 文本上，而不是飘去讲抽象的优化原则。