AI 数据分析脚手架一个 Prompt 模板管一类分析场景一、每次分析都重写 Prompt的困境先问一个问题你上一次在 ChatGPT 或 Claude 里做数据分析时花了多少时间写 Prompt我统计了一下我们团队的数据平均每个分析任务写 Prompt 的时间占了 30%~40%。这不是说 Prompt 难写——而是每次都要重复交代同样的上下文你是一个数据分析专家、请用中文输出、数据口径是……、需要给出 actionable 的建议。更麻烦的是质量参差不齐。同样的分析场景今天写的 Prompt 运气好产出了一份漂亮的报告明天换个同事写的 Prompt可能就输出了一堆业务持续向好的废话——问题不在 AI而在 Prompt 的设计没有标准化。为什么Prompt 标准化是 AI 数据分析工程化的第一道门槛很多人以为是模型不够好换了 GPT-4o、Claude Opus、Gemini 2.0——花了更多 API 费用产出质量波动率依然在 ±40%。问题出在一个被忽视的认知上LLM 的输出质量 ≈ 模型能力 × Prompt 质量²Prompt 质量是平方级影响。同一个分析 Q2 用户流失你用一句话丢给模型 vs 用结构化的 System Prompt 角色定义 分析框架 输出格式约束产出的差距不亚于一个实习生和一个资深分析师。更致命的是隐性上下文——你心里知道流失的定义是连续 30 天未登录但你没写在 Prompt 里AI 用自己的理解猜了一个定义然后输出了看似合理但口径全错的结论。脚手架的核心价值把隐性知识分析方法论、分析框架、业务口径从人脑子里提取出来固化到 Prompt 模板里让每次分析都遵循同一套高标准。这就是数据分析脚手架要解决的问题把一类分析场景的 Prompt 设计成可复用的模板需要时填入具体数据、维度、指标参数就能稳定产出高质量的分析结果。flowchart TD A[分析需求来了] -- B{场景匹配} B --|留存分析| C[模板1: 用户留存分析] B --|归因分析| D[模板2: 指标波动归因] B --|AB 实验| E[模板3: AB 实验解读] B --|数据探查| F[模板4: 数据集探查] B --|异常检测| G[模板5: 业务异常诊断] C -- H[填入: 事件名称/时间窗口/分群条件] D -- H E -- H F -- H G -- H H -- I[LLM 生成分析报告] I -- J[人工 Review 微调] J -- K[输出最终报告]二、什么是数据分析脚手架脚手架这个词借用了软件开发里的概念——create-react-app、Vue CLI 这些脚手架帮你搭好项目骨架你只需要往里面填业务代码。数据分析脚手架同理把 Prompt 中的不变部分固化为模板每次只需要填入变的部分具体数据、指标、分析目标。一个好的 Prompt 脚手架应该满足三个标准场景适配每种分析场景留存、归因、AB 实验、异常检测……都有专门的模板不搞万能模板参数化关键变量通过占位符注入数据同学不需要手动拼接 Prompt产出可控模板中包含了输出格式约束确保 AI 产出的分析报告结构一致、质量稳定三、搭建一个可复用的 Prompt 模板体系我团队目前的 Prompt 模板体系按分析场景分类管理 AI 数据分析脚手架 —— Prompt 模板管理系统 设计原则: 1. 一种分析场景 一个模板类 2. 模板中「不变的部分」固化在代码里 3. 「变的部分」通过参数注入 4. 输出格式在每个模板中明确定义 from dataclasses import dataclass, field from typing import List, Dict, Optional, Any from string import Template import json class AnalysisTemplate: 分析模板基类 子类只需要实现: 1. build_system_prompt() → 定义 AI 的角色和行为约束 2. build_context() → 注入业务上下文和数据 3. build_output_format() → 定义产出物的格式 def render(self, **kwargs) - Dict[str, str]: 渲染最终的 Prompt 返回: { system_prompt: 系统提示词角色定义, user_prompt: 用户提示词具体分析任务 数据, metadata: {...} # 模板元信息 } system_prompt self.build_system_prompt() # 组合上下文 分析任务 数据 输出格式 user_prompt self.build_user_prompt(**kwargs) return { system_prompt: system_prompt, user_prompt: user_prompt, metadata: self.get_metadata(), } def build_system_prompt(self) - str: 子类必须实现定义 AI 角色 raise NotImplementedError def build_user_prompt(self, **kwargs) - str: 子类必须实现构建具体的分析 Prompt raise NotImplementedError def get_metadata(self) - Dict: 模板元信息 return { template_name: self.__class__.__name__, version: 1.0, } # # 模板 1: 用户留存分析 # class RetentionAnalysisTemplate(AnalysisTemplate): 用户留存分析 Prompt 模板 def build_system_prompt(self) - str: return 你是一个资深的数据分析师专长于用户增长和留存分析。 你的分析风格 - 数据驱动所有结论必须有数据支撑不做无根据的推测 - 分层拆解优先从不同维度渠道、新老用户、行为特征拆解留存表现 - 落地建议每个发现都要有对应的可执行建议不只说什么不好了还要说怎么改 - 警惕幸存者偏差区分因果和相关不跳结论 输出语言简体中文 def build_user_prompt(self, **kwargs) - str: metric_name kwargs.get(metric_name, 次日留存率) data kwargs.get(data, {}) time_range kwargs.get(time_range, 最近 30 天) segment kwargs.get(segment, 全量用户) prompt f请基于以下数据完成一份用户留存分析报告。 ## 分析背景 - 指标{metric_name} - 时间范围{time_range} - 分析分群{segment} ## 数据{json.dumps(data, ensure_asciiFalse, indent2)}## 分析要求 1. **趋势判断**整体的{metric_name}变化趋势如何是持续上升、下降、还是波动 2. **关键拐点**有没有明显的上升或下降拐点可能的原因是什么 3. **分群对比**如果有分群数据哪个分群的留存表现最好/最差差距有多大 4. **基准对比**当前水平与行业基准、历史基准相比如何 ## 输出格式 请按以下结构输出报告 ## 五、总结 ### 二、关键发现 至少 3 条数据驱动的发现每条包含具体数据 → 初步解读 → 可能原因 ### 三、分群对比分析如有分群数据 ### 四、建议与行动计划 按优先级排列每条建议包含目标 → 具体动作 → 预期效果 ### 五、需要深入排查的问题 当前数据不足以解释但值得关注的现象 ⚠️ 注意 - 不要用持续向好稳中有升等空洞话术 - 每条发现的数值变化必须给出具体百分比或绝对值 - 避免过度归因对不确定的原因请标注推测 return prompt # # 模板 2: 指标波动归因分析 # class MetricAttributionTemplate(AnalysisTemplate): 指标波动归因 Prompt 模板 def build_system_prompt(self) - str: return 你是一个精通归因分析的数据分析师。 你的分析原则 - 维度下钻按照整体变化 → 谁贡献了变化 → 为什么变化的层次递进 - 量率拆分把指标变化拆解为流量变化和转化率变化两个因子 - 明确不确定性区分数据可以证明的和推测性的 - 先量后率优先检查流量结构变化新老用户比例、渠道分布再查转化率变化 输出语言简体中文 def build_user_prompt(self, **kwargs) - str: metric kwargs.get(metric, GMV) period1 kwargs.get(period1, 上周期) period2 kwargs.get(period2, 本周期) value1 kwargs.get(value1, 0) value2 kwargs.get(value2, 0) drilldown_data kwargs.get(drilldown_data, {}) change_pct ((value2 - value1) / value1 * 100) if value1 ! 0 else 0 direction 上升 if change_pct 0 else 下降 prompt f请完成以下指标波动的归因分析。 ## 分析目标 - 指标{metric} - {period1}{value1} - {period2}{value2} - 变化{direction} {abs(change_pct):.1f}% ## 下钻数据按维度拆解{json.dumps(drilldown_data, ensure_asciiFalse, indent2)}## 分析要求 按以下步骤逐层归因 1. **量率拆分** - 流量侧访问/曝光量是否变化量变 - 转化侧转化率/CVR是否变化率变 - 哪个因子贡献了大部分变化 2. **维度归因** - 从下钻数据中找出贡献度最高的 3 个维度切片 - 每个切片解释为什么它导致了指标变化 3. **业务根因推断** - 基于上述归因推断最可能的业务根因 - 区分数据可证明的原因和需要进一步验证的推测 ## 输出格式 ### 一、变化概览 ### 二、量率拆分结果 流量贡献: X%转化率贡献: Y% ### 三、Top 3 归因维度 每个维度: 维度名 → 变化贡献 → 可能原因 → 置信度 ### 四、根因推断与置信度评估 ### 五、建议后续行动 return prompt # # 模板 3: AB 实验分析 # class ABTestAnalysisTemplate(AnalysisTemplate): AB 实验解读 Prompt 模板 def build_system_prompt(self) - str: return 你是一个 AB 实验数据分析专家。 你的分析要点 - 统计显著性检查p 值是否 0.05置信区间是否穿越 0 - 实际显著性判断统计显著 ≠ 实际值得做评估效应量的大小 - 辛普森悖论防范检查整体显著的分维度是否也显著 - 实验质量评估样本量是否足够实验时长是否合理分流是否均匀 输出语言简体中文 def build_user_prompt(self, **kwargs) - str: experiment_name kwargs.get(experiment_name, 未命名实验) control_data kwargs.get(control_data, {}) treatment_data kwargs.get(treatment_data, {}) test_result kwargs.get(test_result, {}) prompt f请分析以下 AB 实验结果。 ## 实验信息 - 实验名称{experiment_name} - 实验日期范围{kwargs.get(date_range, 待补充)} - 分流比例{kwargs.get(split_ratio, 50%:50%)} ## 实验数据 对照组数据{json.dumps(control_data, ensure_asciiFalse, indent2)}实验组数据{json.dumps(treatment_data, ensure_asciiFalse, indent2)}统计检验结果{json.dumps(test_result, ensure_asciiFalse, indent2)}## 分析要求 1. **核心指标对比**实验组 vs 对照组在各个指标上的差异 2. **统计显著性判断**差异是否具有统计显著性p 值、置信区间 3. **实际显著性评估**差异是否具有业务价值效应量、ROI 估算 4. **分群稳健性**关键分群新老用户、不同渠道上的效果是否一致 5. **实验质量检查**样本量、AA 校验、分流均匀性 ## 输出格式 ### 一、实验结果总结 ### 二、核心指标详细对比 ### 三、统计显著性与效应量评估 ### 四、分群效果稳健性分析 ### 五、实验结论与决策建议上线 / 优化 / 放弃 ### 六、注意事项 风险提示 return prompt # # 模板 4: 数据集探查报告 # class DataProfilingTemplate(AnalysisTemplate): 数据集快速探查 Prompt 模板 def build_system_prompt(self) - str: return 你是一个数据质量与探查专家。 你的探查要点 - 完整性缺失率、空值分布 - 唯一性重复值检测 - 一致性格式是否统一、枚举值是否在预期范围内 - 准确性异常值检测统计方法判断 - 时效性数据更新时间是否符预期 输出语言简体中文 def build_user_prompt(self, **kwargs) - str: table_name kwargs.get(table_name, 未知表) schema_info kwargs.get(schema_info, {}) sample_data kwargs.get(sample_data, []) stats_summary kwargs.get(stats_summary, {}) prompt f请基于以下信息生成一份数据探查报告。 ## 表信息 - 表名{table_name} - 字段数{kwargs.get(col_count, ?)} - 行数{kwargs.get(row_count, ?)} ## Schema 信息{json.dumps(schema_info, ensure_asciiFalse, indent2)}## 各字段统计摘要{json.dumps(stats_summary, ensure_asciiFalse, indent2)}## 样本数据前 20 行{json.dumps(sample_data, ensure_asciiFalse, indent2)}## 输出格式 ### 一、数据概览2-3 句话说明这张表是干什么的 ### 二、字段级质量评估每个字段类型是否合理、缺失率、异常情况 ### 三、数据完整性检查 ### 四、潜在数据质量问题按严重程度排序 ### 五、使用建议哪些字段可以放心用哪些需要谨慎 return prompt # # 模板 5: 业务异常检测 # class AnomalyDetectionTemplate(AnalysisTemplate): 业务异常检测与诊断 Prompt 模板 def build_system_prompt(self) - str: return 你是一个业务监控与异常检测专家。 你的诊断方法论 1. 先确认异常是否真实排除数据采集、口径变更等系统因素 2. 再判断异常的影响范围全局 or 局部短期 or 持续 3. 然后结合业务背景推断可能的原因 4. 最后给出分级的应急建议 输出语言简体中文 def build_user_prompt(self, **kwargs) - str: alert_info kwargs.get(alert_info, {}) recent_data kwargs.get(recent_data, {}) historical_baseline kwargs.get(historical_baseline, {}) prompt f请诊断以下业务异常告警。 ## 告警信息{json.dumps(alert_info, ensure_asciiFalse, indent2)}## 近期实际数据{json.dumps(recent_data, ensure_asciiFalse, indent2)}## 历史基准数据{json.dumps(historical_baseline, ensure_asciiFalse, indent2)}## 诊断要求 1. **异常确认**这是一个真实的业务异常还是数据问题或正常的周期性波动 2. **影响范围评估**影响面有多大全量用户 or 特定分群 3. **根因推测**按可能性从高到低列出可能的根因标注置信度 4. **应急建议**按紧急/重要矩阵给出分级建议 ## 输出格式 ### 一、异常判定真异常 / 数据噪音 / 正常波动 ### 二、影响范围 ### 三、根因推测按置信度排序 ### 四、应急建议急/重 → 不急/不重 ### 五、24 小时内需确认的事项清单 return prompt四、模板管理器的完整实现 Prompt 模板管理器 —— 注册、查询、渲染的一站式入口 from typing import Dict, Type class PromptTemplateManager: Prompt 模板管理器 使用方式: manager PromptTemplateManager() manager.register(retention, RetentionAnalysisTemplate) prompt manager.render(retention, metric_name次日留存率, datamy_data, time_range2026年6月) def __init__(self): self._templates: Dict[str, Type[AnalysisTemplate]] {} def register(self, name: str, template_class: Type[AnalysisTemplate]): 注册一个分析模板 self._templates[name] template_class def list_templates(self) - List[str]: 列出所有已注册的模板名称 return list(self._templates.keys()) def render(self, template_name: str, **kwargs) - Dict: 渲染指定模板的 Prompt 参数: template_name: 模板名称如 retention、attribution **kwargs: 模板需要的参数每个模板不同 返回: {system_prompt: ..., user_prompt: ...} if template_name not in self._templates: available , .join(self._templates.keys()) raise ValueError(f未知模板 {template_name}可用模板: {available}) template self._templates[template_name]() return template.render(**kwargs) # 注册所有模板 manager PromptTemplateManager() manager.register(retention, RetentionAnalysisTemplate) manager.register(attribution, MetricAttributionTemplate) manager.register(ab_test, ABTestAnalysisTemplate) manager.register(profiling, DataProfilingTemplate) manager.register(anomaly, AnomalyDetectionTemplate) print(f✅ 已注册模板: {manager.list_templates()}) # 使用示例生成留存分析 Prompt retention_data { day1_retention: [0.45, 0.43, 0.41, 0.39, 0.38, 0.42, 0.44], day7_retention: [0.25, 0.24, 0.23, 0.22, 0.21, 0.24, 0.26], day30_retention: [0.12, 0.11, 0.10, 0.10, 0.09, 0.11, 0.13], dates: [06-01, 06-08, 06-15, 06-22, 06-29, 07-01, 07-08], segments: { 新用户: {day1: 0.35, day7: 0.18}, 老用户: {day1: 0.55, day7: 0.32}, iOS: {day1: 0.48, day7: 0.28}, Android: {day1: 0.42, day7: 0.23}, } } prompt manager.render(retention, metric_name次日留存率, dataretention_data, time_range2026-06-01 至 2026-07-08, segment全量用户 按平台/新老分群) print(\n 生成的 System Prompt ) print(prompt[system_prompt][:200] ...) print(\n 生成的 User Prompt前 300 字) print(prompt[user_prompt][:300] ...) 踩坑提醒System Prompt 里的角色定义太长超过 500 字反而会降低分析质量很多人把 System Prompt 写成业界最佳实践大全 公司所有的业务口径定义洋洋洒洒 2000 字。LLM 对 System Prompt 中间部分的注意力权重衰减严重头尾效应关键约束可能被淹没在背景知识里。System Prompt 控制在 300-500 字只放角色定义 核心分析原则 输出语言——具体分析方法和数据口径放在 User Prompt 里靠近数据部分注意力更集中。模板参数量**kwargs不能包含原始数据全量 JSON否则 token 消耗和延迟爆炸json.dumps(retention_data)如果包含了 100 天的逐天明细数据几千条记录序列化后的 JSON 可能就是 50000 token一次 API 调用 0.15 美元GPT-4。一天分析 20 次一个月就是 90 美元的 API 费用。分析模板只传入聚合后的摘要数据或可视化关键数据点——模板本身就包含分析和聚合逻辑的框架不需要给 AI 喂原始明细让它从头聚合。Prompt 模板的版本号不能只是v1.0必须绑定到模型版本如gpt-4o-2024-05-13同一个分析模板在 GPT-4o 上产出 80 分的报告在 Claude Opus 上可能是 60 分——因为不同模型对分析要求、输出格式的理解方式不同。模板元数据必须记录验证通过的模型版本号 验证日期 验证人当模型大版本升级时模板需要重新验证后才能迁移。数据脚手架解决的不是 AI 能力不够的问题而是 AI 能力释放不稳定的问题。同样的分析任务同一个模型用精心打磨的模板和用随手写的 Prompt产出质量能差一个档次。这个模板体系给数据团队带来的几个确定收益新人上手快不需要学 Prompt 工程选场景模板 → 填参数 → 出报告三步走产出质量稳模板内置了分析方法论框架AI 的输出被约束在正确的分析路径上迭代有锚点模板不好用可以持续优化优化一次整个团队受益知识内化模板本身就是团队分析方法论的载体——什么样的分析应该看什么维度、用什么拆解逻辑都固化在模板里了最后抛一个实操建议先从你最频繁做的那类分析开始掏出一个模板跑 10 次看看效果。效果稳定了就固化下来不稳定就迭代模板。当一个模板能稳定产出 80 分的分析报告时你就有了第一个真正好用的数据分析脚手架。为什么让 Prompt 模板稳定产出 80 分比偶尔产出 95 分更有价值数据分析不是论文竞赛——业务方不需要一篇文采飞扬但结论只有 80% 准确率的报告他们需要的是每次都遵循相同分析范式、口径一致、可对比的报告。一个 95 分的分析报告价值只有 95 分的一次性价值但一个 80 分的分析报告如果每周输出同样的分析框架、同样的指标口径、同样的结论结构它带来的价值是趋势可对比 × 口径一致 × 减少沟通成本 远超 95 分的复合价值。脚手架追求的不是每次写出最好的报告而是每次写出同等质量水平的报告——一致性比峰值质量更稀缺。
)
