数据分析 Prompt 实战 SOP：把 LLM 变成你的数据分析师

Q: 我只有 Excel，不会 SQL 和 Python，这个 prompt 对我有用吗？

有用。把 `{tool}` 填 `Excel`，模型会输出公式和 Power Query 步骤，注明作用区域。你照着在单元格里填公式即可。如果你用的事 WPS 或新版 Excel，直接把表头加几行样本贴进数据上下文就行，不要求你会写代码。

Q: 模型生成的 SQL 是 MySQL 语法，我用的是 PostgreSQL，怎么办？

在 `{tool}` 变量里直接写明"PostgreSQL 14"，模型会改用对应语法（如 `TO_CHAR` 替代 `DATE_FORMAT`、`LIMIT` 不变但窗口函数写法可能不同）。同理，写明 "ClickHouse" 它会用 ClickHouse 方言。方言差异是 SQL 生成的常见坑，提前声明能省一轮返工。

Q: 怎么让洞察更贴合我的业务，而不是通用废话？

两个杠杆。第一，在 `{business_goal}` 里加业务背景（行业、产品类型、近期动作，如"AI 工具类自媒体，上周开始试小红书渠道"）。第二，在数据上下文的语义层写清业务口径和已知异常。信息越具体，模型越没法给"放之四海皆准"的废话。 ---

自媒体人和小团队天天在和数据打交道：昨天那篇推文阅读量为什么暴跌？三个获客渠道哪个 ROI 最高？上个月直播 GMV 环比到底涨没涨？这些问题本来该数据分析师回答，但绝大多数小团队没有专职分析师，也没人愿意为了一份临时报表去学 SQL 和 pandas。于是流程就变成了：运营把数据导进 Excel，拉个透视表，凑几个数，拍脑袋写一句"环比上升 2.3%"交差。数据有了，结论却是糊的。

这篇不教你搭复杂的数据分析智能体（那是另一篇 ai-data-analysis-sop 的范畴，用 Coze 造数字员工）。这篇只解决一件事：给你一个可复制、带变量、拿来就能用的数据分析 prompt 模板。只要你把数据集描述（CSV 表头加几行样本、或数据库 schema）、业务目标、用的工具三个变量填进去，LLM 就能稳定输出四样东西——分析思路、可执行的 SQL 或 pandas 代码、关键洞察方向、可视化建议。它不是万能的，但在没有分析师的团队里，它能把"看一眼数据"的成本从两小时压到二十分钟。

和本站其他 prompt 模板（如 cheatsheet-prompt-formula 通用公式）不同，这篇专攻数据分析，核心是「数据上下文 + 分析框架 + 输出格式」三重约束，下面逐层拆开。

一、场景与痛点：没分析师，但天天有数据要看

先对号入座，看这些场景熟不熟：

自媒体做内容复盘：公众号后台导出近 30 天文章数据（阅读/分享/完读/涨粉），想找出"哪类选题带粉最多"。你拉了个透视表，发现"职场"标签阅读高但涨粉低，"工具"标签反之，但说不清为什么，也定不了下周该多发哪类。
小电商看投放：抖音千川、小红书聚光、微信广告三个渠道，每周末要把花费、点击、转化、ROI 拉到一张表里对比。手工拼接费时，还经常算错 ROI 的分母（用花费除成交，还是除点击？）。
SaaS 小团队看留存：数据库里躺着用户登录日志，想算"注册第 7 天留存率"，但没人会写那条略复杂的 SQL，产品经理只能用 Excel 手工数，一个月才出一次数。直播团队看场次也是同理，数据散在运营后台、话术表、商品表里，没人能快速给归因。

这些场景的共同点是：问题不复杂，数据就在那里，但缺一个能把数据翻译成结论的人。专职数据分析师贵且难招，而 LLM 在 2026 年的代码生成和统计推理能力，已足够胜任"初级分析师"的角色——前提是你得会用它。

直接把数据往 ChatGPT 里一扔问"帮我分析下"，通常灾难收场：它编造数字、写跑不通的代码、给出放之四海皆准的废话。问题不在模型，在你的 prompt 没给足约束。这就是这篇 SOP 要解决的。

一句话定位：这篇不是教你"用 AI 写 SQL"，而是教你用一个结构化 prompt，让 LLM 像一个会先想后做、结论克制的数据分析师那样工作。

二、原理：为什么 prompt 要这么设计

一个好的数据分析 prompt，本质是在回答四个问题：让模型扮演谁、给它什么背景、让它按什么思路想、让它用什么格式交。对应四个设计要素。

2.1 角色（Role）：定调分析的专业度和克制

给 LLM 一个角色，是在给它的输出"定调"。说"你是一位有 8 年经验的高级数据分析师"，模型就会调用分析师的专业范式：先看数据分布再下结论、区分描述性和诊断性分析、对异常值敏感。不设角色直接问"分析下这个表"，你会得到一段营销文案式的"数据告诉我们……"，没营养。

角色设定里最关键的一句是"结论必须有数据支撑、拒绝编造"。这句话不是废话，它直接抑制 LLM 最大的毛病——幻觉统计（下面踩坑会详讲）。

2.2 数据上下文（Data Context）：消除字段臆造

LLM 写代码跑不通，十有八九是因为它臆造了字段名。你给它"一张用户表"，它可能写出 user_age、register_time 这种看起来合理但根本不存在的列。根治办法只有一个：在 prompt 里把真实的表头（或 schema）原样贴进去。

数据上下文要包含三层信息：

层级	内容	作用
结构层	CSV 表头，或数据库表名/字段名/类型	让代码字段名逐字一致
样本层	3-5 行真实结构的数据（可脱敏）	让模型理解字段取值和数据形态
语义层	字段含义、业务口径、已知的数据质量问题	消除口径歧义，比如"活跃"指启动还是登录

很多人只贴表头，不贴语义层，结果模型把"订单状态=3"当成失败单，实际业务里 3 是"已完成"。样本层尤其重要——模型看到 created_at 列里的时间字符串才知道要做日期解析，看到 amount 列有空值才知道要处理缺失。

2.3 分析框架（Framework）：逼它先想后做

新手 prompt 的通病是直接要"代码"或"结论"。好的分析师不会上来就敲 SQL，他会先拆问题：看哪些指标？做哪些对比？数据有没有坑？这个"先想"的过程就是分析框架。

在这个 prompt 里，框架被显式拆成四段输出：分析思路 → 代码 → 关键洞察 → 可视化建议。这个顺序不是随便排的：

分析思路在前：逼模型先表态"我打算怎么分析"，把逻辑漏洞暴露在写代码之前，避免它为了凑结论而乱写查询。
代码居中：思路定了，代码就是水到渠成。要求代码带注释、只准用真实字段、末尾 print 中间结果，方便你核对。
洞察在后且克制：洞察部分要求写"预期方向"而非编造的数字——"若 X 呈 Y 趋势，则说明 Z"。模型没真正跑代码（除非你用带代码执行的环境），它给的数字一定是编的，只有方向才有参考价值。
可视化收尾：图表是沟通语言，但很多人忘了在 prompt 里要，结果模型只给一堆数。显式要求"图表类型+字段+说明+工具函数"，你拿过来就能画。

2.4 输出格式约束（Format）：让结果可复用

格式约束解决的是"拿过来能不能直接用"。这个 prompt 要求：四段用 ## 标题分隔、代码块带语言标识（sql / python）、数值保留两位小数、字段名保留英文。输出能直接复制进编辑器或 BI 工具，不用二次整理。

另外有一个"工具适配"设计：{tool} 变量填 SQL / pandas / Excel 三选一，prompt 里对应不同的执行假设（SQL 假设 MySQL 8.0 只输出查询；pandas 假设 df 已加载；Excel 输出公式或 Power Query）。这让一个模板覆盖三种最常见的非程序员数据分析场景。

设计哲学小结：这个 prompt 的全部技巧，就是用「角色定调 + 数据上下文消歧 + 框架逼思路 + 格式保可用」四道约束，把 LLM 从一个爱吹牛的聊天机器人，调教成一个先想后做、结论克制、代码能跑的初级分析师。

三、分步实操：填变量、跑 prompt、迭代

下面是核心交付物——可复制的数据分析 prompt 模板。三个变量用 {} 包起来：{dataset_description}、{business_goal}、{tool}。复制到任意 LLM（ChatGPT / Claude / Kimi / DeepSeek / 通义都行）即可用。

3.1 可复制 Prompt 模板

Prompt

# 角色
你是一位有 8 年经验的高级数据分析师，擅长把原始数据转化为可执行的业务决策。你熟悉 {tool}（SQL / pandas / Excel 公式），习惯先理清分析框架再动手写代码，结论必须有数据支撑、拒绝编造。不确定时明确说"需要运行代码确认"，绝不凭空给数字。

# 数据上下文
{dataset_description}
（这里贴：CSV 表头 + 3-5 行样本，或数据库 schema：表名/字段名/类型/注释，以及字段含义和业务口径。样本行用真实结构但可脱敏。已知的数据质量问题也写在这里。）

# 业务目标
{business_goal}
（一句话说清这次分析要回答什么业务问题，例如"找出上周 GMV 下降的主要原因"或"判断哪个获客渠道的 LTV 最高"。可补充行业、近期动作等背景。）

# 工具与执行环境
- 分析工具：{tool}
- 若 {tool}=SQL：假设兼容 MySQL 8.0 语法，只输出 SELECT 查询语句，不要 DDL/DML，不要修改表结构。
- 若 {tool}=pandas：输出可在 Python 3.11 + pandas 2.x 环境运行的代码，假设 df 已按表名加载好（多表则 df_orders / df_users 等）。
- 若 {tool}=Excel：输出公式或 Power Query 步骤，注明用到哪个函数、作用在哪个区域。

# 分析框架（请严格按以下四部分输出，每部分用 ## 标题分隔）

## 一、分析思路
1. 用 3-5 句话拆解业务问题：要回答它需要看哪些指标、做哪些对比（同比/环比/分组/漏斗/同期群）。
2. 列出关键假设和潜在数据质量问题（缺失值/异常值/口径不一致），并说明你会如何处理。
3. 给出 2-4 个层层递进的分析子问题，从描述性统计到诊断性归因。

## 二、代码（{tool}）
- 输出可直接执行的 {tool} 代码，带中文注释。
- 只用"数据上下文"里真实存在的字段，不得臆造列名；不确定的字段先在注释里标"待确认"。
- 代码末尾用 print（pandas）或 SELECT 把关键中间结果打出来，便于核对。
- 若代码较长，拆成"数据准备 / 指标计算 / 结果输出"三段。
- pandas 代码先 `print(df.dtypes)` 和 `print(df.describe())` 做一次结构核对。

## 三、关键洞察（预期方向）
- 基于代码"预期会跑出什么"，给 3-5 条洞察方向，格式："若 X 指标呈 Y 趋势，则说明 Z"。
- 明确标注哪些是数据能直接验证的，哪些需要结合业务经验推断。
- 给出 1-2 个反直觉的、值得深挖的异常点假设。
- 严禁编造任何具体数值；所有数字标注"需运行代码确认"。

## 四、可视化建议
- 推荐 2-3 张图表，每张写明：图表类型 / 用到的字段 / 想说明什么 / 适合的工具函数（matplotlib 的 plt.bar、或 SQL 后导出给 Excel 画、或 pandas df.plot）。
- 标注坐标轴、标题、图例的命名建议。

# 纪律
- 不得编造任何具体数值；不确定时说"需要运行代码确认"。
- 字段名必须与数据上下文逐字一致。
- 输出全部用中文，代码与字段名保留英文原样。

3.2 Step 1：准备数据上下文（最费劲也最值的一步）

这一步决定整篇分析的成败。三种常见数据源怎么填 {dataset_description}：

CSV / Excel 导出：复制表头行，再挑 3-5 行有代表性的样本（不要只挑正常的，故意留一两行有空值或异常的）。在下面用一段话解释字段含义。例如：

text

CSV 表头：article_id,title,publish_date,channel,reads,shares,completes,new_followers
样本（5 行）：
1001,"5个免费AI工具",2026-07-28,wechat,12034,892,0.62,213
1002,"我用Claude写了一周代码",2026-07-29,xiaohongshu,8421,,0.55,156
1003,"",2026-07-30,wechat,0,0,0,0
1004,"LLM选型横评",2026-07-31,zhihu,5610,233,0.48,87
1005,"SOP实操：n8n搭客服",2026-08-01,wechat,9877,611,0.59,198

字段说明：
- channel：发布渠道（wechat公众号/xiaohongshu小红书/zhihu知乎）
- completes：完读率（0-1 小数，公众号后台口径）
- new_followers：该文净增粉丝
已知问题：1003 行 title 为空、reads 为 0，是定时发布失败的脏数据，分析时应剔除。

数据库 schema：贴建表语句或字段列表，带类型和注释。例如：

text

表 orders（订单）：order_id BIGINT, user_id BIGINT, channel VARCHAR(32) COMMENT '获客渠道', amount DECIMAL(10,2) COMMENT '订单金额', status TINYINT COMMENT '1待付 2已付 3已完成 4已退款', created_at DATETIME
表 users（用户）：user_id BIGINT, reg_channel VARCHAR(32), registered_at DATETIME, last_login_at DATETIME
业务口径：ROI = 当月该渠道成交金额 / 当月该渠道花费（花费在另一张 spend 表，本次不涉及，ROI 仅算分子）

只贴表头 + 样本，不贴全量。几万行数据贴进 prompt 既超 token 又没用——模型分析靠的是结构和样本，不是逐行读数。真正的大数据处理交给它生成的代码在你本地跑。

3.3 Step 2：写清业务目标

{business_goal} 越具体，分析越有的放矢。对比两种写法：

糟糕写法："分析下这些数据。"（模型会给你一个泛泛的描述性统计，没用）
好写法："找出近 30 天涨粉效率（new_followers / reads）最高的渠道，并判断是否值得在该渠道加倍投入；同时标出表现明显异常的文章。"

好的业务目标包含三要素：要回答的问题 + 判断标准 + 输出粒度。补充行业背景（"我们是 AI 工具类自媒体"）和近期动作（"上周试了小红书渠道"）能让洞察更贴合实际。

3.4 Step 3：选工具变量

{tool} 三选一，按你的数据量和技能栈定：

场景	选 {tool}	理由
数据在数据库，要复用查询	SQL	一次写好长期跑，性能好
数据是导出的 CSV，要做探索分析	pandas	灵活，图表一体化
完全不会代码，只有 Excel	Excel	公式和透视表门槛最低

填好后，整段 prompt 复制进 LLM。

3.5 Step 4：读输出与迭代

模型会按四段输出。拿到后别急着照搬代码，做三件事：

核对字段：扫一眼代码里的字段名，和你的表头逐字对比。模型偶尔还是会把 created_at 写成 create_time，发现就让它改。
跑代码：把代码贴进你的环境（数据库 / Jupyter / Excel）。带代码执行能力的 ChatGPT Advanced Data Analysis 或 Claude 的 analysis 工具能直接跑，跑完把真实结果喂回模型。
追问深化：第一轮给的是框架性结论，挑一个最有意思的子问题追问。比如"你提到小红书渠道完读率偏低，给我一段按小时分组的 pandas 代码看是不是和发布时段有关"。多轮迭代是 LLM 数据分析的常态，一轮出不了深结论。

迭代心法：第一轮求"对的方向"，第二轮求"细的代码"，第三轮求"能落地的洞察"。别指望一个 prompt 一次性挖出所有结论。

四、踩坑速查：每坑配解法

LLM 做数据分析有几个高频坑，每个都让"图省事"的人翻过车。下面给现象、原因和解法。

坑 1：LLM 编造数据和幻觉统计

现象：你还没跑代码，模型就信誓旦旦地说"小红书渠道 ROI 为 3.2，环比上升 18%"。这些数字是它编的。

原因：LLM 本质是预测下一个 token，倾向于给"看起来完整"的答案。你问"分析结果"，它就生成一段带数字的结论，哪怕根本没算过。

解法：在 prompt 里写死"严禁编造任何具体数值；所有数字标注'需运行代码确认'"（本文模板已加）。拿到输出后，凡没跑过代码就出现的具体数字，一律视为幻觉，让模型改成"预期方向"。可信数字只来自你执行代码后的真实结果。

坑 2：代码跑不通（字段臆造 + API 过时）

现象：复制模型给的 pandas 代码进 Jupyter，报 KeyError: 'user_age'——表里根本没有这列。或者 SQL 里用了 DATE_FORMAT，但你的库是 PostgreSQL 只认 TO_CHAR。

原因：模型基于"看起来合理"臆造字段名；训练数据里各库 API 混杂，版本过时（pandas 1.x 的写法在 2.x 报错）。

解法：三招组合。第一，数据上下文里贴真实表头，并在纪律里写"字段名必须逐字一致"。第二，在工具与执行环境里指定库版本（"pandas 2.x""MySQL 8.0""PostgreSQL 14"），模型会按版本适配。第三，要求代码先 print(df.dtypes) 做结构核对，跑挂了第一时间定位是字段还是 API 问题。报错就把完整 traceback 贴回模型让它修。

坑 3：不懂数据分布，直接算均值被极值带偏

现象：模型算出"客单价 256 元"，但你瞟一眼数据发现有笔 9.9 万元的企业订单把均值拉飞了，中位数其实才 89 元。模型没做异常值检查就给了均值。

原因：LLM 倾向走最短路径——算个 mean() 交差，不会主动检查分布。它不"看"你的数据，只看字段名。

解法：在分析框架里强制要求"先做描述性统计和异常值检查"。本文模板的代码段要求先 print(df.describe())，洞察段要求"标出反直觉的异常点假设"。你还可以在业务目标里直接点一句"注意排除异常大额订单"，模型就会改用中位数或分位数，或者先过滤再算。

坑 4：长数据超 token，硬塞导致截断或失忆

现象：你想把一份 5 万行的销售明细 CSV 整个贴进对话框，要么直接超限报错，要么模型只"记住"了开头几千行，后面的数据等于没给。

原因：LLM 有上下文窗口上限（不同模型从 8K 到上百万 token 不等，越塞越贵越慢，长上下文里注意力还会衰减）。原始数据逐行塞，token 烧光也没意义。

解法：永远只贴表头 + 3-5 行样本，不贴全量数据。让模型产出代码，代码在你本地或带沙箱的环境里跑全量。数据在数据库就贴 schema，模型写 SQL，数据库自己跑。这是用 LLM 做数据分析最核心的一条原则：模型负责想和写，你的机器负责算。用 ChatGPT Advanced Data Analysis 这类带代码执行的工具可上传完整文件让它自写代码读，但别上传几百 MB 的怪物文件，先抽样或聚合。

坑 5（附加）：业务口径不一致，算对了数却答错问题

现象：模型算出"活跃用户 1.2 万"，老板说不对应该是 8000。模型把"打开 App"当活跃，公司口径是"登录并产生行为"。

解法：在 {dataset_description} 的语义层把业务口径写死（"活跃=当日有 >=1 条行为日志的用户"）。口径是数据分析师的命根子，prompt 里不写清，模型只能猜。

五、FAQ

Q1：我只有 Excel，不会 SQL 和 Python，这个 prompt 对我有用吗？ 有用。把 {tool} 填 Excel，模型会输出公式和 Power Query 步骤，注明作用区域。你照着在单元格里填公式即可。如果你用的事 WPS 或新版 Excel，直接把表头加几行样本贴进数据上下文就行，不要求你会写代码。

Q2：模型直接给了带具体数字的结论，但我没让它跑代码，能信吗？ 不能信。凡是模型没经过真实代码执行就给出的具体数字，一律视为幻觉。正确做法是让它只给"方向"，数字必须你跑代码后填进去。用带代码执行的工具（如 ChatGPT 的数据分析功能、Claude 的 analysis 工具）则让它跑完代码再报数。

Q3：数据有几十万行，能直接喂给 LLM 吗？ 不能。原始数据贴进 prompt 会超 token 且没意义。只贴表头 + 3-5 行样本 + 字段语义说明，让模型生成代码，代码在你本地环境跑全量。数据在数据库就贴 schema，模型写 SQL，数据库执行。记住：模型出思路和代码，你的机器跑数据。

Q4：模型生成的 SQL 是 MySQL 语法，我用的是 PostgreSQL，怎么办？ 在 {tool} 变量里直接写明"PostgreSQL 14"，模型会改用对应语法（如 TO_CHAR 替代 DATE_FORMAT、LIMIT 不变但窗口函数写法可能不同）。同理，写明 "ClickHouse" 它会用 ClickHouse 方言。方言差异是 SQL 生成的常见坑，提前声明能省一轮返工。

Q5：怎么让洞察更贴合我的业务，而不是通用废话？ 两个杠杆。第一，在 {business_goal} 里加业务背景（行业、产品类型、近期动作，如"AI 工具类自媒体，上周开始试小红书渠道"）。第二，在数据上下文的语义层写清业务口径和已知异常。信息越具体，模型越没法给"放之四海皆准"的废话。

六、参考来源

OpenAI 数据分析官方指南（ChatGPT 数据分析功能与代码执行说明）：https://platform.openai.com/docs/guides/data-analysis
OpenAI 代码解释器（Code Interpreter / Advanced Data Analysis）发布说明：https://openai.com/index/new-tools-for-data-analysis/
Anthropic 提示工程指南（角色、上下文、输出格式等技巧）：https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
Anthropic 代码执行工具文档（Claude 的 analysis / code execution 能力）：https://docs.anthropic.com/en/docs/build-with-claude/tool-use/code-execution-tool
DAIR.AI Prompting Guide（提示工程系统技巧库）：https://www.promptingguide.ai/
Google Gemini 代码执行官方文档：https://ai.google.dev/gemini-api/docs/code-execution

说明：大模型的数据分析与代码执行能力迭代很快，各模型的具体上下文窗口、可用库版本、沙箱限制以官方文档为准。本文的 prompt 模板与踩坑解法基于 LLM 通用行为设计，不依赖某一模型的特定版本。