AI 数据分析师的 7 月进化技术栈与思维模型的双重升级7 月对我来说是一个分水岭 — 从会用 AI 工具的数据分析师到能把 AI 嵌入工作流的数据分析师。这篇文章是一次完整的自我复盘。一、7 月之前 vs 7 月之后翻看 6 月底的工作笔记发现自己当时对 AI 的态度基本是拿来主义——有需求了打开 ChatGPT 问一下拿到答案贴进代码跑通了就过了。这算不上问题但确实没什么体系。7 月的四个项目逼着我重新审视了这件事当一个数据分析师的工作流里有 30% 的任务可以由 AI 加速时你怎么系统化地管理这 30%答案是你需要的不只是一堆工具而是一套工作流和思维模型。二、技术栈进化2.1 从聊天框到工作流6 月的我用 AI 的方式打开 ChatGPT → 粘贴需求 → 复制回复 → 贴进代码 → 跑一下 → 完事7 月的我需求评审 → 判断任务类型 → 选择合适的 AI 工具/模型 → 生成初稿 → 代码 Review 测试 → 质量校验 → 提交核心变化是增加了三个环节任务分类、工具选择、质量校验。2.2 新增的工具层 7月份搭建的个人AI数据分析工作流工具集 每个工具解决一类特定场景而不是一个大而全的Chat接口 # 工具1SQL 模板生成器 def generate_sql_template(requirement: str, table_schema: dict) - str: 根据需求描述和表结构调用 LLM 生成 SQL 模板 注意生成的是模板不是最终SQL需要人工检查逻辑 prompt f 你是SQL专家。根据以下信息生成SQL查询模板。 ## 需求 {requirement} ## 可用表结构 {table_schema} ## 要求 - 只在输出中提供 SQL不要解释 - 使用明确的表别名和列别名 - 对聚合字段添加 ROUND(, 2) 保留两位小数 - 日期过滤使用明确的日期范围 # 调用 LLM API如 OpenAI / Qwen 本地部署 return call_llm(prompt) # 工具2数据探索摘要 def auto_explore_data(df_summary: dict) - str: 输入 DataFrame 的 describe() 结果 前 5 行 LLM 生成数据探索的观察摘要 prompt f 你是数据分析师。根据以下数据摘要写一段简短的观察 1. 数据是否有明显的异常值或缺失 2. 各列的分布有什么值得注意的特点 3. 有什么你建议进一步分析的 ## 数据摘要 {df_summary} ## 要求 - 控制在 200 字以内 - 用编号列出每条不超过一行 return call_llm(prompt) # 工具3异常分析文案生成 def generate_anomaly_report(metric_name: str, anomaly_detail: dict) - str: 检测到数据异常后生成分析报告初稿 仅生成事实陈述部分归因和结论由人工补全 prompt f 根据以下异常检测结果生成一段事实陈述。 **不要做归因推断只描述数据发生了什么。** ## 异常详情 指标: {metric_name} 检测时间: {anomaly_detail[detected_at]} 当前值: {anomaly_detail[current_value]} 预期范围: {anomaly_detail[expected_range]} 偏离幅度: {anomaly_detail[deviation_pct]}% ## 格式 - 标题: {metric_name} 出现异常波动 - 正文: 3-4句数据事实描述 - 标注: ⚠️ 以上仅为数据事实原因分析需人工研判 return call_llm(prompt) # 工具4质量检查 def validate_ai_output(output_type: str, content: str, validation_rules: list) - dict: AI 输出质量检查框架 每种内容类型有对应的检查规则 results {} for rule in validation_rules: rule_name rule[name] rule_func rule[check] passed rule_func(content) results[rule_name] ✅ if passed else ❌ all_pass all(v ✅ for v in results.values()) return { passed: all_pass, details: results, content: content if all_pass else ⚠️ 需要人工复核 } # SQL 质量检查规则示例 sql_validation_rules [ { name: 无 SELECT *, check: lambda sql: SELECT * not in sql.upper() }, { name: 有 WHERE 条件, check: lambda sql: WHERE in sql.upper() }, { name: 没有 NOT IN NULL 风险, check: lambda sql: NOT IN not in sql.upper() or IS NOT NULL in sql.upper() }, { name: 聚合有别名, check: lambda sql: bool(re.search(rAS\s\w, sql, re.IGNORECASE)) }, ]2.3 模型选择的矩阵三、思维模型升级技术栈的升级是显性的思维模型的升级才是 7 月最大的收获。我认为一个AI 时代的数据分析师需要内化以下四个思维模型模型 1AI 能力边界模型这个月的所有踩坑归结起来就是对 AI 能力的认知从它什么都能做变成了它只能在特定区间内可靠能力AI 表现人类应该做什么数值计算 又快又准定义计算逻辑和口径模式识别 适合监督学习的模式判断模式是否有业务意义逻辑推理 简单逻辑 OK复杂容易出错验证推理链路的每一步因果推断 本质是相关性匹配设计实验、控制变量创意构思 能提供灵感但不保证可行性根据业务约束做取舍模型 2校验优先模型以前是写代码 → 跑 → 看结果对不对。现在是AI 生成 → 规则校验 → 人工抽查 → 上线监控每一步都是过滤器用最低的成本过滤掉最常见的问题。模型 3可替代清单在 7 月份的实践中我刻意记录了每个任务中 AI 能替代的部分和不能替代的部分AI 能替代的约 30%SQL 模板编写✓ 但要人工检查 JOIN 逻辑数据描述性统计代码✓ 几乎不出错图表生成代码✓ matplotlib/seaborn 模板分析报告文案润色✓ 但不要让它做归因AI 不能替代的约 70%需求理解和业务逻辑梳理 — 这是对齐问题不是生成问题指标口径的定义和统一 — 这是组织共识问题数据质量的判断 — 没有标准答案异常根因分析 — 需要跨系统知识和实验验证和业务方的沟通 — 理解没说出来的需求模型 4持续迭代模型四、8 月计划把校验优先模型拆解成标准化的 checklist整理一份个人用的 AI 辅助 Prompt 模板库至少 20 个场景搭建本地模型部署 API 路由的简易网关把A/B测试方法论推广到 AI 功能评估中五、总结7 月最重要的认知升级可以用一句话概括会用 AI和会系统化地用 AI是两件完全不同的事情。前者是打开聊天框问问题后者是知道什么任务适合 AI、什么任务不适合给 AI 的输入有结构、有约束、有校验给 AI 的输出有多层过滤每次使用后都做复盘优化下一次的 Prompt 或流程这个月我真正想明白的一件事是AI 不会替代数据分析师但会用 AI 的数据分析师会替代不会用的。这行发展到今天技术工具在快速变化但理解业务、定义问题、判断质量这些核心能力不但没有被削弱反而因为 AI 的存在变得更加重要。因为当 AI 能快速生成 10 种分析方案时能选出对的那一个才是最稀缺的能力。8 月见。
)
)
