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接口
"""

# ====== 工具1：SQL 模板生成器 ======
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(r'AS\s+\w+', sql, re.IGNORECASE))
    },
]

2.3 模型选择的矩阵

三、思维模型升级

技术栈的升级是显性的，思维模型的升级才是 7 月最大的收获。我认为一个"AI 时代的数据分析师"需要内化以下四个思维模型：

模型 1：AI 能力边界模型

这个月的所有踩坑归结起来，就是对 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 月见。