SQL 是数据工作的命脉，写错一个 JOIN 就能把生产库拖崩；数据分析靠拍脑袋，结论常常跑偏。把需求丢给大模型直接说「帮我写个 SQL」「分析下这数据」，它要么给你一条跑不通的通用方言、要么凭空编结论。这套 Prompt 包按三级：入门级让 AI 写对单条 SQL，进阶级让它解释并优化已有查询，专家级链式跑完「画像 → 清洗 → 分析 → 可视化」整条流程。每条都贴上 schema、指定方言、分步走——这三条是把 AI 从拍脑袋拉回实事求是的关键。适合数据分析师、后端工程师、产品经理--任何要和表打交道、又不想被 AI 误导的人。
一、入门级：写对单条 SQL
场景：脑子里清楚要查什么，但不想手写 JOIN 和聚合。重点不是让 AI「写出 SQL」，而是让它写出在指定库上能跑通、不返全表的 SQL。
你是资深数据分析师。请用 {{MySQL / PostgreSQL / SQLite / BigQuery}} 方言写一条 SQL：
- 查询目标：{{一句话，例如「近 30 天每个付费用户的订单总额，按金额降序取前 20」}}
- 表结构：{{粘贴 CREATE TABLE，或「表名 + 字段 + 类型」}}
约束：
1. 只输出 SQL 代码块，不写解释
2. 标识符按方言加引号（MySQL 用反引号，PostgreSQL 用双引号）
3. 显式 JOIN ... ON，不要逗号隐式连接
4. 必须加 LIMIT
5. 时间字段按方言写（MySQL 用 DATE_SUB，PG 用 INTERVAL）为什么这几条约束：方言不一致是 SQL 翻车第一大原因，DATE_SUB 在 PostgreSQL 上直接报错；显式 JOIN ... ON 避免漏 ON 条件产生笛卡尔积；强制 LIMIT 防止 AI 写出 SELECT * 把库拖崩。贴 CREATE TABLE 比「口述字段」靠谱得多——AI 能看到类型和主键，写出的聚合和 JOIN 才贴合实际。没有 CREATE TABLE 时，至少给「表名 + 字段名 + 类型 + 主键」，别只说「用户表和订单表」--AI 会自己脑补字段名，写出一堆不存在的列。
二、进阶级：带变量解释并优化查询
场景：拿到一条别人写的、或 AI 生成的 SQL，想确认它到底在干嘛、有没有坑。比「帮我看看这条 SQL」强在让 AI 按结构逐项检查，而不是泛泛说「可以优化」。
你是资深 DBA。针对下面这条 SQL，按顺序输出：
1. 一句话总结：它查什么、产出什么粒度的结果
2. 逐段拆解：FROM / JOIN / WHERE / GROUP BY / HAVING / ORDER BY 各自作用
3. 潜在问题（列 1-3 条），每条标注类型：
- 索引未命中（对字段套函数、隐式类型转换）
- 笛卡尔积或漏 ON
- N+1 查询
- 全表扫描 / SELECT *
4. 优化后的 SQL，逐处标注改了什么、为什么
约束：不要重写无关部分；改动最小；不确定就标「需看执行计划」
SQL：{{粘贴}}
表结构与索引：{{粘贴，可选}}带变量是为了让这条 Prompt 能复用在不同 SQL 上：你只换 SQL 和结构两处。让 AI「标注问题类型」是把它的注意力从「挑格式小毛病」拉到「真正的性能和正确性问题」——加引号、缩进这种它爱挑但无所谓的，被约束挡在外面。常见能捞到的问题：WHERE DATE(created_at) = '2026-07-31' 这类对字段套函数会让索引失效，AI 标成「索引未命中」后改写成范围扫描；WHERE status = 1 但 status 是 varchar，隐式转换同样吃不到索引。
三、专家级：链式数据分析
场景：拿到一份陌生的表或 CSV，不知道从哪下手。一条 Prompt 串起五步，每步等确认再继续，比一次性说「帮我分析」强在每一步都基于上一步的真实产出，AI 没法凭空编数据。
你是资深数据分析师。我有一份数据，请按顺序执行五步，每步输出后等我回「继续」再做下一步：
1. 数据画像：基于字段和样例行，推断每个字段的类型、缺失率、可疑值（如年龄=999、金额为负）
2. 清洗方案：列出脏数据类别（空值 / 重复行 / 异常值 / 单位不统一 / 编码混乱），每类给处理建议和取舍
3. 分析思路：针对我想回答的问题「{{分析目标}}」，给 3 个切入角度，说明每个角度能回答什么
4. 代码实现：对每个角度给出 SQL 或 Pandas 代码，标注依赖的前提（如「需先清洗金额字段」）
5. 可视化建议：对每个分析结果推荐图表类型（柱状 / 折线 / 散点 / 箱线 / 热力），说明为什么这种图最能讲清这个结论
数据字段：{{粘贴}}
样例行（5-10 行）：{{粘贴}}
分析目标：{{一句话，例如「找出流失用户共同特征」}}链式的价值在「每步等确认」：第一步画像暴露的字段问题，会直接改变第二步清洗方案，再影响第三步分析角度——一次性 Prompt 做不到这种反馈闭环。可视化单独成步，是因为 AI 常默认堆柱状图，逼它说「为什么这个图」能把选择拉回数据特性：时序用折线、分布用箱线、相关性用散点。分析目标写得好坏决定整条链的走向：写「分析这数据」AI 只能给泛泛角度，写成「找出付费 30 天内流失用户的共同特征」才有锋利的切入点，第三步的分析角度才会真的围着这个问题转。
四、用 vs 不用，差在哪
不用 Prompt 直接说「写个 SQL」，AI 不知方言、不贴 schema，常给一条跑不通的通用 SQL；说「分析这数据」，它凭空编结论或无脑堆柱状图。用这套，三条硬约束把结果从拍脑袋拉回实事求是：贴 CREATE TABLE 让 AI 看到真实类型和主键、指定方言避免函数不兼容、链式分步让每步基于上一步产出而非臆测。入门级够日常取数，进阶级适合接手别人 SQL，专家级适合面对陌生数据集做完整分析。三级按需取用，不必一上来就上链式--简单的取数用入门级反而更快，专家级那套五步对一条 SELECT 来说是杀鸡用牛刀。
参考来源
- Anthropic Prompt Engineering 概览（结构化、分步、贴上下文的通用原则）：https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
- OpenAI Prompt Engineering 指南（明确指令、拆步骤、提供示例）：https://platform.openai.com/docs/guides/prompt-engineering
- DAIR.AI Prompting Guide（Chain-of-Thought、Few-Shot 等技术总览）：https://www.promptingguide.ai/
- Google Gemini API 提示策略（指定格式、分步引导）：https://ai.google.dev/gemini-api/docs/prompting-strategies