01「进阶SQL提示词」到底在问什么
「进阶SQL提示词」这类需求，难的不是有没有方法，而是能不能在这一次就做出可用的结果。方法给得再多，落到具体任务上还是要重新调。放到编程开发里看，真正决定结果的是信息量，不是措辞的漂亮程度。
别急着一次写全。先让结果跑起来，再针对最不满意的那个点补一句，比一开始就写两百字有效。
为了让你少走弯路，下面把「怎么写」和「怎么判断写得对不对」放在一起讲。只讲前者，你永远不知道自己那版差在哪。
到了「进阶SQL提示词」这个层次，能提升的已经不是句子本身，而是你对任务的拆解。同一段话，拆成三步问，结果会比一次问清楚更稳。
进阶的标志是开始做减法：删掉角色设定、删掉客套话、删掉用不上的约束，只留真正影响结果的那几行。
02三种写法，差别在哪
三种写法放在一起对比，最容易看出问题：多数人卡在第一行，以为多写几句客套话就叫说清楚了。
| 常见写法 | 为什么效果差 | 改成这样 |
|---|---|---|
| 「写个函数实现进阶SQL提示词」 | 得到一段能跑但没处理边界的代码 | 「写一个函数，输入是××，需处理空值、超长、并发三种情况」 |
| 「这段代码报错了怎么办」 | 没有上下文，回答只能是猜测 | 「报错信息：……，相关代码：……，运行环境：……，请定位原因」 |
| 「优化一下性能」 | 不知道瓶颈在哪，优化往往是猜测 | 「这段代码在 10 万条数据下变慢，请先分析瓶颈再给方案」 |
03一条能直接用的示例
先跑这一版。它把最容易漏的三项（背景、约束、格式）都写进去了，多数情况下比一句话需求好一个档次。
你是工程经验丰富的开发者。
【任务】围绕「进阶SQL提示词」，给我可以直接运行的代码。
【要求】写清运行环境和依赖版本；给出输入输出示例；说明时间复杂度和可能的失败输入。
【约束】不要伪代码；不要省略错误处理；不确定的库版本标出来。
【格式】先给完整代码，再给三行以内的说明，最后列出已知限制。04要加强版就加这两步
这一段适合任务比较重要、不能出错的场合。核心差别是加了「先复述再执行」和「标注不确定项」，能挡掉大部分硬伤。
你是做代码评审的资深工程师，需要为「进阶SQL提示词」产出一段能直接用的实现。
【任务】写代码，并把边界说清。
【要求】
1. 先说明输入假设和输出约定（类型、空值、异常）；
2. 给出完整可运行的实现，不要省略号；
3. 列出至少四个边界情况，并说明代码里怎么处理；
4. 说明这段代码在什么规模下会出问题（时间复杂度或内存）。
【约束】不引入未说明的第三方依赖；不使用「这里省略」；变量名要能自解释。
【格式】先说明，再代码，最后边界表。05字段怎么填
字段不用一次填满。先填任务和格式，看结果差在哪，再回头补对应那一行，效率比一次写全高。
| 字段 | 怎么写 | 常见反例 |
|---|---|---|
| 环境 | 语言版本、依赖、运行方式 | 「在你的环境里跑一下」 |
| 边界 | 空值、超长输入、并发怎么处理 | 只写正常路径 |
| 限制 | 在什么数据量下会变慢或出错 | 声称适用于所有场景 |
| 输入约定 | 类型、空值、长度上限，写清 | 假设输入永远合法 |
| 错误处理 | 说明失败时返回什么、抛什么 | 只写正常路径 |
| 可运行性 | 要求完整代码，不留省略号 | 接受伪代码 |
06换场景，侧重就不一样
场景变了，重点就变了：有的要短，有的要全，有的必须先声明边界。选错侧重，写得再细也不合适。
| 场景 | 这种场合下要侧重什么 |
|---|---|
| 写新功能 | 先定接口再写实现，避免返工 |
| 改老代码 | 先让模型读现有代码，再提改动方案 |
| 排查报错 | 给完整错误栈和相关代码，别只给一句报错 |
| 写测试 | 先让它列用例，再实现，覆盖率高很多 |
07六个常见错误
- 不说明版本，代码在别人机器上直接报错。
- 只给正常路径，一遇空值就崩。
- 拿它生成的代码直接上生产，没有测试也没有 review。
- 让它「优化性能」但不说数据规模，改完反而更慢。
- 直接复制没跑过的代码，边界一碰就崩。
- 让模型解释报错，却不给完整错误信息和上下文。
08怎么判断这次输出能不能用
判断标准要能自检，不能靠感觉。下面四条都是你自己就能确认的，不需要别人帮忙看。
09三个让它更稳的做法
10三种不满，三种改法
不满意通常只有三种来源：信息不够、格式没定、边界没说。对着症状改，比重新想一遍快。
| 你现在的感觉 | 该动哪一行 | 改完会怎样 |
|---|---|---|
| 语气不像我们自己的 | 背景行贴一段你自己写过的样本，注明「照这个语气」 | 措辞向你靠，不向平均值靠 |
| 老是先解释概念，我要结论 | 任务行开头加「不要解释原理，直接给结论」 | 省掉三分之一的铺垫 |
| 每次结果都不一样，没法复现 | 自检行让它先列三条核对项，再输出正文 | 波动变小，出错也知道错在哪一步 |
11换个模型，要调什么
不必为每个模型重写一套。多数情况只需要动一行，剩下的是同一套结构。
| 模型 | 常见差异 | 调整一处 |
|---|---|---|
| 智谱清言 | 结构化好，爱用「首先、其次」 | 格式行禁掉序号词，改成短句并列 |
| Midjourney | 参数决定画幅和风格力度 | 主体写最前面，参数单独放最后一行 |
| Claude | 长文和改写更稳，但句子容易绕 | 加一条「每句不超过 30 字，能删就删」 |
| 文心一言 | 中文语感顺，遇到敏感话题会自我收窄 | 把要求拆小，一次只问一件事 |
12从空白到能交：五步走完
流程的价值在于可复现：同样的五步，换一个任务照样能走。
- 先选任务动词：提炼、改写、对比、拆解、生成，只选一个。
- 补主语和对象：给谁、关于什么、基于哪些材料。
- 划定边界：字数、结构、语气，以及不能出现的内容。
- 要求可核验：数字给来源，判断给依据。
- 复跑一次，两次方向一致再定稿；差得远说明要求有歧义。
13常被追问的四件事
下面四个问题出现频率最高，答案都不长，但能省掉不少弯路。
多半是一次改太多。一次只动一行，改完立刻跑，才知道是哪句起的作用。
各家对「简洁」「专业」的默认理解不同。把要求写成能检验的条件，比如字数、段落数、禁用词，差异会小很多。
加一句：没有依据的数字写「待核实」，不许估算。然后把待核实项逐条自己查。
要。存的时候连适用场景和已知失效情况一起写，否则三个月后你不敢用。
14这套写法什么时候不管用
任何方法都有失效场景。这几条不属于「再调调就好」，而是要换一种做法。
| 情况 | 为什么不管用 |
|---|---|
| 结果要是能直接交付的成品 | 排版、配色、图表这些，模型只能给描述，落到文件还得你自己动手。 |
| 要求可复现的打分或判断 | 同一份输入两次结果不同是常态。需要稳定判断，就把标准写成清单逐项打分，别让它自由发挥。 |
| 内容要过平台审核 | 各家规则不同而且一直在变，提示词保证不了过审。发布前按平台最新的社区规范自己过一遍。 |
FAQ常见问题
「进阶SQL提示词」生成的代码能直接用吗？
小工具可以，生产代码不行。至少要做三件事：跑通边界用例、看依赖是否安全、确认没有硬编码的密钥。
怎么让它少出错？
给具体的输入输出示例，比写十句「注意健壮性」有效。再补一句「不确定的库版本标注出来」。
需要会编程才能用吗？
要能读懂报错。完全不看代码就上线，出问题时你无法判断是逻辑错还是环境错。
AI 写的代码能直接用吗？
小片段可以用，进生产前必须过测试。重点检查空值、越界、并发和异常吞掉这四类问题，它们最容易漏。
为什么不给完整代码，它总写省略号？
因为提示词里没要求完整。加一句「不要省略，给出可直接运行的完整代码」，命中率会明显提高。
怎么让它理解我的项目？
把相关的目录结构、接口定义、已有实现贴给它。它对上下文的理解完全依赖你给的信息，不给就只能按通用写法来。
→同类关键词
同一类需求换个说法，答案的侧重也不同。下面这些词的写法可以直接套用。