十个万能提示词模板：按月汇总趋势、销量 TOP10、占比饼图、异常值标注直接抄

一、为什么“万能模板”这件事值得认真做

把提示词写成模板，最初看起来像是偷懒——把一段话存起来反复粘贴。但真正做过几十次数据分析对话的人会发现，模板的价值不在“省打字”，而在约束输出空间。语言模型的输出是一个高维概率分布，你不约束它，它就会在“解释、建议、免责声明、格式美化”之间自由游走；你约束得越具体，它落到可用结果上的概率就越高。

学术界对这件事的讨论已经相当系统。Wei 等人 2022 年提出的思维链（Chain-of-Thought）提示^[1]证明，在提示中加入推理步骤示例能显著提升算术与逻辑任务表现；Kojima 等人同年提出的“Let's think step by step”零样本推理^[2]进一步说明，一句结构化的引导语就能改变模型的行为模式。本文评述：这些工作的共同指向是——提示词的本质是对模型推理路径的软性编程，而模板就是把这种编程固化成可复用的函数签名。

工程侧的进展同样值得关注。2023 年以来，DSPy^[3]、LangChain、Guidance、Outlines 等框架陆续把“提示词”抽象成可编译、可优化的模块；OpenAI 在 2023 年发布的提示工程指南^[4]中明确建议“把指令放在开头、用分隔符区分输入、给出输出格式示例”。笔者认为，这些建议与软件工程里的接口设计原则高度同构：输入要明确类型，输出要明确 schema，边界条件要显式声明。

但现实是，大多数一线数据分析人员并没有把这些原则落地。原因不复杂：模板写得太抽象就没法直接用，写得太具体又只能解决一个问题。本文要做的，是在“通用”和“即用”之间找一条中间路线——每个模板都针对一个明确的分析动作，同时保留可替换的参数位。这样既避免了“万能提示词”这种伪概念的陷阱，又让复制粘贴真正产生价值。

需要提前说明的一点：本文所称“万能”，指的是结构可迁移，而非“一句话解决所有问题”。任何声称能用一个提示词搞定所有数据分析的说法，都值得警惕。

二、模板的通用骨架：四要素与字段契约

在拆解十个模板之前，先把它们共享的骨架讲清楚。观察大量可复用的数据分析提示词，会发现它们几乎都由四个要素构成：角色与任务、数据与字段、步骤与规则、输出与校验。这四个要素缺一个，结果的可控性就会明显下降。

2.1 四要素的具体含义

角色与任务：告诉模型“你是谁、要做什么”。角色设定不是为了拟人化，而是为了激活特定领域的表达习惯。让模型扮演“数据分析师”和扮演“文案策划”，对同一份销售数据的处理方式完全不同。

数据与字段：这是最容易被忽略、也最容易出错的部分。你必须明确告诉模型：数据以什么形式给出（CSV/Markdown 表格/JSON）、有哪些字段、字段的类型和含义是什么。字段名如果有歧义（比如 amount 到底是含税还是不含税），必须显式说明。

步骤与规则：把分析动作拆成有序步骤，并声明处理规则。比如“先按月份分组，再对销售额求和，缺失月份补 0 而不是跳过”。规则越明确，模型自由发挥的空间越小，结果越稳定。

输出与校验：指定输出格式（表格/JSON/图表代码），并要求模型给出自检信息。自检是防幻觉的关键手段，后文会专门展开。

2.2 字段契约：把数据字典写进提示词

所谓字段契约，就是把数据字典以紧凑形式嵌入提示词。它的作用是消除字段歧义，让模型不需要“猜”。一个典型的字段契约长这样：

字段契约：
- order_id   订单号，字符串，唯一
- order_date 下单日期，格式 YYYY-MM-DD
- region     销售大区，枚举：华东/华北/华南/西南
- product    商品名称，字符串
- qty        销量，整数，单位：件
- amount     销售额，浮点数，单位：元，不含税
- status     订单状态，枚举：paid/refunded/pending

本文评述：字段契约的价值在于把“数据理解”这一步从模型的隐式推理变成显式输入。在真实的工程场景里，数据字典本来就是团队协作的基础设施，把它复用到提示词里几乎零成本，却能显著降低字段误读导致的错误。笔者认为，没有字段契约的提示词，本质上是在让模型盲猜。

2.3 一个可复用的通用骨架

把四要素组合起来，就得到下面这个通用骨架。后文的十个模板都是在这个骨架上做参数替换：

【角色】你是一名严谨的数据分析师，只基于给定数据作答。
【数据】以下是 {数据描述}，字段契约如下：{字段契约}
【数据内容】
{粘贴数据}
【任务】{具体分析动作}
【步骤】
1. ...
2. ...
3. ...
【规则】
- 缺失值处理方式：...
- 数值精度：保留 {n} 位小数
- 不确定时：明确说“数据不足”，不要编造
【输出】
- 先输出结果表格（Markdown）
- 再输出不超过 {n} 字的关键结论
- 最后输出自检：行数核对、合计核对

这个骨架看起来朴素，但它把最容易出问题的几个点都覆盖了：数据边界、处理规则、输出格式、自检要求。接下来的十个模板，都是它的具体化。

三、模板一：按月汇总趋势

按月汇总是数据分析里最高频的动作，也是最容易出错的。常见错误包括：把不同年份的同月合并、缺失月份直接跳过导致趋势图断裂、日期格式识别错误导致分组失败。一个合格的按月汇总模板，必须把这些坑提前堵上。

3.1 模板正文

【角色】你是数据分析师，负责月度趋势汇总。
【数据】订单明细表，字段：order_date(YYYY-MM-DD)、amount(元)、status。
【任务】按“年-月”汇总销售额，输出趋势表。
【步骤】
1. 过滤 status = refunded 的记录（退款不计入销售额）。
2. 从 order_date 提取年月，格式 YYYY-MM。
3. 按年月分组，对 amount 求和，计数订单数。
4. 补齐时间序列中缺失的月份，amount 填 0，并标记 is_missing=true。
5. 计算环比增长率：(本月-上月)/上月，上月为 0 时标注 N/A。
【规则】
- 金额保留 2 位小数，增长率保留 1 位小数（百分比）。
- 时间范围以数据中最早和最晚日期为准。
- 若某月订单数为 0，仍需出现在结果中。
【输出】
1. Markdown 表格：年月 | 销售额 | 订单数 | 环比 | 是否缺失
2. 不超过 100 字的趋势结论（上升/下降/波动，指出拐点月份）
3. 自检：原始行数、过滤后行数、汇总后月份数

3.2 关键设计点解析

第一个关键点是退款过滤。很多人在提问时忘了这一步，导致销售额被高估。把过滤规则写进步骤，等于把业务口径固化下来。

第二个关键点是缺失月份补齐。这是趋势分析里最隐蔽的坑：如果 3 月没有订单，模型很可能直接跳过，画出来的趋势图看起来是连续的，实际上时间轴是断的。要求补齐并标记，能避免误读。

第三个关键点是环比的分母保护。上月为 0 时计算增长率会得到无穷大，必须显式声明处理方式。本文评述：这类边界条件的声明，正是模板区别于随手提问的核心价值。

3.3 数据预处理细节

如果数据量较大（超过模型上下文窗口），需要先做预处理。推荐流程：用 Python 的 pandas 读取原始数据，做字段清洗和类型转换，再截取最近 12 至 24 个月的数据粘贴给模型。示例代码：

import pandas as pd
df = pd.read_csv("orders.csv", parse_dates=["order_date"])
df = df[df["status"] != "refunded"]
df["ym"] = df["order_date"].dt.strftime("%Y-%m")
monthly = df.groupby("ym").agg(
    amount=("amount", "sum"),
    orders=("order_id", "count")
).reset_index()
print(monthly.to_markdown(index=False))

把这段代码的输出直接粘进模板的“数据内容”位置，模型就不需要再做日期解析，出错概率大幅下降。能预处理的部分尽量预处理，这是让模型专注在“分析”而非“数据搬运”上的基本原则。

四、模板二：销量 TOP10 排行

TOP10 排行看似简单，但“并列怎么处理”“是否合并同名商品”“按销量还是按销售额”这些细节不写清楚，结果就会五花八门。

4.1 模板正文

【角色】你是数据分析师，负责商品销量排行。
【数据】商品销售表，字段：product、qty、amount、region。
【任务】输出销量 TOP10 商品，并给出累计占比。
【步骤】
1. 按 product 分组，对 qty 求和。
2. 按 qty 降序排序；qty 相同时按 amount 降序作为次级排序。
3. 取前 10 名。
4. 计算每个商品销量占全部商品总销量的百分比。
5. 计算前 10 名销量合计占总销量的百分比（集中度）。
【规则】
- 商品名做去空格、统一大小写处理后再分组。
- 并列第 10 名时全部保留，并在备注列标注“并列”。
- 百分比保留 1 位小数。
【输出】
1. 表格：排名 | 商品 | 销量 | 销售额 | 占比 | 累计占比
2. 一句话结论：TOP10 集中度是否超过 60%
3. 自检：分组后商品总数、TOP10 销量合计与总销量是否吻合

4.2 并列与去重的处理逻辑

并列排名是排行类分析的高频争议点。如果第 10 名和第 11 名销量相同，直接取前 10 会丢掉一个本应并列的商品。模板里要求“并列全部保留”，是为了让结果更符合业务直觉。

去重同样重要。“iPhone 15”和“iphone 15 ”在字符串层面是两个商品，但在业务上是同一个。要求模型做标准化处理，能避免排名被拆散。本文评述：排行分析的准确性，八成取决于分组键的清洗质量，而不是排序算法本身。

4.3 集中度指标的延伸

累计占比其实就是帕累托分析（Pareto Analysis）的雏形。如果 TOP10 集中度超过 60%，说明商品结构高度集中，运营策略应聚焦头部；如果低于 30%，说明长尾效应明显，需要关注腰部商品。这个判断标准来自经典的二八法则，但在不同行业阈值差异很大，建议结合历史数据自行校准。

五、模板三：占比饼图与结构分析

饼图是数据分析里争议最大的图表。数据可视化领域的经典研究（Cleveland 与 McGill 1984 年的图形感知实验^[5]）表明，人眼对角度差异的辨别能力弱于对长度差异的辨别能力，因此饼图在精确比较上不如条形图。但在“展示构成、强调占比”的场景下，饼图依然有不可替代的直观性。

5.1 模板正文

【角色】你是数据分析师，负责结构占比分析。
【数据】销售表，字段：region、amount。
【任务】分析各区域销售额占比，输出饼图代码与占比表。
【步骤】
1. 按 region 分组，对 amount 求和。
2. 计算各区域占比，按占比降序排列。
3. 将占比小于 5% 的类别合并为“其他”，避免饼图碎片化。
4. 生成 matplotlib 饼图代码，中文标签，百分比保留 1 位小数。
5. 计算赫芬达尔指数（HHI）衡量集中度。
【规则】
- 占比之和必须为 100%，四舍五入误差归入最大类别。
- 饼图起始角度 90 度，逆时针排列。
- 颜色使用同一色系的深浅变化，避免高饱和撞色。
【输出】
1. 占比表：区域 | 销售额 | 占比
2. 可直接运行的 Python 绘图代码
3. 一句话结论：结构是否均衡（HHI 判断）
4. 自检：占比合计是否为 100%

5.2 为什么要求生成代码而不是直接画图

当前主流语言模型在纯文本环境下无法直接输出图片，但可以输出绘图代码。要求模型生成 matplotlib 或 ECharts 代码，既保证了可复现性，又方便后续调整样式。本文评述：让模型输出“生成图表的代码”而非“图表的描述”，是数据分析提示词的一个重要范式——代码是可验证的，描述是不可验证的。

5.3 小类别合并的阈值选择

模板里用了 5% 作为合并阈值，这是一个经验值。实际操作中，如果类别数少于 6 个，可以不合并；如果超过 10 个，建议提高到 8% 或 10%。判断依据是：饼图上每个扇区的角度不应小于 15 度，否则标签会重叠、难以辨认。

六、模板四：异常值标注

异常值检测是数据分析里技术含量较高的环节。统计学上有多种方法：基于标准差的三西格玛法则、基于四分位距的 IQR 方法、基于密度的 LOF、基于时间序列的 STL 分解等。让模型做异常检测，关键是把方法讲清楚，否则它会用“看起来不太对”这种主观标准来判断。

6.1 模板正文

【角色】你是数据分析师，负责异常值检测与标注。
【数据】日销售表，字段：date(YYYY-MM-DD)、amount。
【任务】用 IQR 方法标注异常值，并给出可能原因假设。
【步骤】
1. 计算 amount 的 Q1、Q3、IQR = Q3 - Q1。
2. 下界 = Q1 - 1.5 × IQR，上界 = Q3 + 1.5 × IQR。
3. 标记超出上下界的记录为异常，区分“偏高”和“偏低”。
4. 对异常点计算偏离倍数：(值 - 上界) / IQR 或 (下界 - 值) / IQR。
5. 检查异常点是否连续出现（连续 3 天以上视为趋势性异常，而非单点异常）。
【规则】
- 只标注，不删除异常值。
- 偏离倍数保留 2 位小数。
- 原因假设必须标注为“假设”，不得表述为结论。
【输出】
1. 异常点表格：日期 | 数值 | 类型 | 偏离倍数 | 是否连续
2. 正常区间说明：Q1、Q3、下界、上界
3. 原因假设（每条不超过 30 字，最多 3 条）
4. 自检：异常点数量、占比

6.2 IQR 与三西格玛的取舍

IQR 方法对极端值不敏感，适合偏态分布；三西格玛假设数据近似正态，对极端值敏感。销售数据通常右偏（少数大额订单拉高均值），因此 IQR 更稳健。本文评述：选择异常检测方法前，先看数据分布，这一步不能省。如果数据明显右偏却用三西格玛，会把大量正常的高值误判为异常。

6.3 异常与“业务事件”的区分

统计意义上的异常，未必是业务意义上的问题。大促当天的销售额暴涨是统计异常，但完全符合预期。因此模板要求模型区分“单点异常”和“趋势性异常”，并要求原因假设标注为假设。这一步是为了防止模型把统计异常直接等同于业务风险，产生误导性结论。

七、模板五至十：其余六个高频场景

受篇幅限制，这里把剩余六个模板的核心结构集中呈现。它们共享第二节的通用骨架，差异主要在步骤和规则部分。

7.1 模板五：同比环比

【任务】计算各月销售额的同比（YoY）与环比（MoM）。
【步骤】
1. 按年月汇总销售额。
2. 环比 = (本月 - 上月) / 上月。
3. 同比 = (本月 - 去年同月) / 去年同月。
4. 标记分母为 0 或缺失的情况为 N/A。
【规则】增长率保留 1 位小数；同比缺失时不得用环比替代。
【输出】表格：年月 | 销售额 | 环比 | 同比 | 备注

同比环比最容易出的问题是“分母缺失时强行计算”。模板显式要求标注 N/A，避免模型用 0 填充分母产生无穷大或错误值。

7.2 模板六：分组聚合

【任务】按 region + category 双维度分组，计算销售额、订单数、客单价。
【步骤】
1. 按 region 和 category 组合分组。
2. 销售额 = sum(amount)，订单数 = count(order_id)。
3. 客单价 = 销售额 / 订单数。
4. 输出透视表：行=region，列=category，值=销售额。
【规则】订单数为 0 的组合客单价填 N/A；空组合补 0。
【输出】明细表 + 透视表 + 一句话结论

双维度分组的关键是“空组合”的处理。如果某个 region 下没有某个 category 的订单，透视表里应该补 0 还是留空？模板要求补 0，是为了让透视表结构完整，便于后续计算。

7.3 模板七：留存与复购

【任务】计算用户月度留存率与复购率。
【步骤】
1. 按 user_id 找首次下单月份，作为 cohort。
2. 对每个 cohort，统计后续每个月的活跃用户数。
3. 留存率 = 第 N 月活跃用户 / cohort 初始用户。
4. 复购率 = 下单次数 ≥ 2 的用户 / 总用户。
【规则】cohort 规模小于 30 的不计算留存率，标注“样本不足”。
【输出】留存矩阵（行=cohort，列=第 N 月）+ 复购率

留存分析对样本量敏感。小 cohort 的留存率波动极大，容易产生误导。模板要求样本不足时标注而非计算，这是一个重要的统计严谨性约束。

7.4 模板八：漏斗转化

【任务】计算“曝光→点击→加购→下单→支付”漏斗各环节转化率。
【步骤】
1. 统计各环节去重用户数。
2. 环节转化率 = 本环节用户 / 上一环节用户。
3. 整体转化率 = 支付用户 / 曝光用户。
4. 找出转化率最低的环节（流失最大）。
【规则】用户数按 user_id 去重；转化率保留 2 位小数。
【输出】漏斗表：环节 | 用户数 | 环节转化率 | 整体转化率 | 流失率

漏斗分析的核心是“去重”和“顺序”。用户可能多次曝光，但只算一次；用户必须按顺序经过各环节，跳步的不计入。这些规则不写清楚，模型的统计口径就会漂移。

7.5 模板九：文本分类打标

【任务】对用户评论做情感分类与主题打标。
【数据】评论表，字段：review_id、content。
【步骤】
1. 情感分类：正面/中性/负面。
2. 主题打标：从 [物流, 质量, 价格, 客服, 外观] 中多选。
3. 输出置信度：高/中/低。
【规则】无法判断时标“其他”，不得强行归类；每条评论最多 3 个主题。
【输出】表格：review_id | 情感 | 主题 | 置信度 | 判断依据（≤20 字）

文本分类的难点在于标签体系的边界。模板要求输出“判断依据”，是为了让结果可追溯、可复核。本文评述：让模型给出判断依据，是降低分类幻觉的有效手段——如果依据站不住脚，分类结果大概率也不可靠。

7.6 模板十：多表关联

【任务】把订单表与用户表按 user_id 关联，分析不同用户等级的消费特征。
【数据】
表A 订单表：order_id、user_id、amount
表B 用户表：user_id、level(普通/银卡/金卡)、city
【步骤】
1. 以订单表为主表，左连接用户表。
2. 按 level 分组，计算总消费、订单数、客单价。
3. 检查关联匹配率：未匹配上的 user_id 数量。
【规则】匹配率低于 95% 时，必须提示数据质量问题。
【输出】分组统计表 + 匹配率 + 数据质量提示

多表关联最容易出问题的是“匹配率”。如果用户表里缺了一部分 user_id，关联后这部分订单会被丢弃，导致统计偏低。模板要求计算并提示匹配率，是一个简单但有效的质量守门机制。

八、校验层：如何判断模型算得对不对

模板能提高输出的稳定性，但不能保证正确性。语言模型在数值计算上依然会出错，尤其是涉及多步运算时。因此，一个完整的提示词工作流必须包含校验层。

8.1 三类校验手段

校验类型	具体做法	适用场景
行数校验	要求模型报告原始行数、过滤后行数、汇总后行数	所有聚合类分析
合计校验	分组求和应等于总计，占比之和应为 100%	占比、分组汇总
交叉校验	用独立脚本复算关键指标，与模型结果比对	关键决策数据

本文评述：行数校验和合计校验属于“模型自检”，成本低但能拦住大部分低级错误；交叉校验属于“外部验证”，成本高但可靠性最强。笔者认为，凡是进入正式报告的数据，都应该经过交叉校验，不能只依赖模型自检。

8.2 防幻觉的三条硬规则

第一，数据不足时明确说“数据不足”。模型倾向于给出一个看起来合理的答案，而不是承认信息不够。在提示词里显式允许“不知道”，能显著降低编造。

第二，区分“数据事实”与“分析推断”。要求模型在输出中标注哪些是数据直接得出的，哪些是推断。这个习惯能帮助读者正确理解结论的可靠性。

第三，禁止补全未给出的数据。有些模型会“顺手”补上缺失的月份或类别，看起来更完整，实际上引入了虚假信息。模板里要求缺失值显式标记，就是为了堵住这个口子。

九、工程化封装：从模板到可回归测试的资产

把十个模板存在备忘录里，只能算“个人技巧”。要让它们在团队里产生复利，需要做工程化封装。这一节给出一个可落地的路径。

9.1 模板的版本管理

把每个模板存成独立的文本文件，用 Git 管理。文件命名建议采用“场景-版本”格式，例如 monthly_trend_v2.md。每次修改都要写清楚变更原因，比如“增加退款过滤规则”。这样做的好处是，当模型结果出现异常时，可以回溯是模板改了还是数据变了。

9.2 参数化与批量执行

模板里的可变部分（数据、字段、阈值）用占位符标记，然后用脚本批量替换。一个简单的 Python 实现：

from string import Template
tpl = Template(open("monthly_trend_v2.md").read())
prompt = tpl.substitute(
    data=df.to_markdown(index=False),
    precision=2,
    max_words=100
)

批量执行时，建议把每次调用的输入、输出、耗时、token 消耗都记录下来。这些日志是后续优化的基础。

9.3 回归测试集

准备一批“标准答案已知”的小数据集，每次修改模板后跑一遍，对比输出是否仍然正确。测试集应覆盖边界情况：空数据、单行数据、缺失月份、并列排名、分母为零。本文评述：提示词工程要真正工程化，回归测试是绕不开的一步。没有测试，模板的迭代就是盲改。

9.4 与代码工具的协同

当前一个明显的趋势是，语言模型与代码执行环境的结合越来越紧密。OpenAI 的 Code Interpreter（现为 Advanced Data Analysis）^[6]、Anthropic 的 tool use 能力^[7]，都允许模型直接运行 Python 代码完成计算。在这种模式下，提示词的重点从“让模型算”转向“让模型写对代码”。本文评述：这是提示词工程的一次范式转移——从“约束计算过程”变成“约束代码生成”，模板的结构也需要相应调整，把“步骤”改写为“代码要求”。

十、前沿预判与结语

站在 2025 年回看，提示词工程正在经历从“手工作坊”到“标准化生产”的转变。几个值得关注的方向：

一是自动提示优化。DSPy 等框架已经能用少量标注样本自动搜索更优的提示词，人工写模板的角色会逐渐从“编写”转向“定义评估标准”。

二是结构化输出约束。JSON Schema、正则约束解码等技术，让模型输出格式的可靠性大幅提升，模板里关于“输出格式”的描述可以逐步交给系统层保证。

三是分析智能体。多步分析任务正在被拆解为“规划—执行—校验”的智能体流程，单个模板会变成智能体可调用的工具，而不是人工粘贴的文本。

但无论技术怎么演进，本文反复强调的那条主线不会变：把模糊的需求转化为明确的契约。字段契约、步骤契约、输出契约、校验契约——这四层契约构成了提示词工程的骨架。十个模板只是这套骨架的具体实例，真正可迁移的是背后的思维方式。

最后给一个务实的建议：不要试图一次写出完美模板。先写一个能跑的版本，用真实数据跑十遍，把每次出错的地方补进规则里。迭代三五轮之后，你会得到一个真正属于自己业务场景的模板库——这比抄任何现成模板都更有价值。