配置驱动思维：
换数据集不用改代码的数据分析框架

做数据分析的人大多经历过这种循环：拿到一份新数据集，打开上次的脚本，从头改到尾——改列名、改路径、改指标口径、改图表配置。改完发现逻辑和上次一模一样，变的只有数据的"名字"。

我给自己提了一个问题：能不能让"换数据集"这件事，变成只改一个文件？

01答案：把"变的部分"和"不变的部分"拆开

我把它做成了一个可复用的分析框架，核心只有一句话：数据源、字段映射、指标定义、用户分层规则，全部抽离成一个 JSON 配置文件；分析引擎只读配置、不认识任何具体数据集。

analysis_config.json   ← 唯一需要修改的文件
        ↓
run_analysis.py        ← 通用引擎：读配置执行
        ↓
┌──────────┬──────────┬──────────┐
│ 宽表构建 │ 指标计算 │ 行为模拟 │
└──────────┴──────────┴──────────┘
        ↓
  JSON 数据 → Next.js 看板自动渲染
        ↓
   PDF / Word 报告一键导出
    

换数据集时只走三步：把新数据整理成约定格式放进目录 → 改 JSON 里的字段映射和业务规则 → 跑一条命令。指标计算（GMV、DAU、转化漏斗、留存 Cohort、RFM 分层）和可视化看板全部自动跟上。

判断"配置驱动"是否值得的最简单标准：这套逻辑你会不会用第二次。只用一次的东西，写死反而更快。

02验证：Olist 巴西电商，9.8 万笔订单

空谈架构没有意义，我拿 Kaggle 上的 Olist 巴西电商公开数据集做了端到端验证：

总览、增长诊断、用户分层三个看板页面自动渲染，分析报告支持 Word 与 PDF 一键导出。整个过程我改的只有那个 JSON 文件。

03延伸：这个思维不止用于数据

写完这个框架我意识到，配置驱动是一种通用的拆解方式——把一件重复的事拆成"不变的引擎"和"可变的参数"，然后让引擎去消化参数。

• 后来写 OpenJob 时，我把求职流程做成了同样的结构：采集关键词、城市、评分规则、简历底稿选择，全是配置；采集、评分、生成简历是引擎。换一个求职方向 = 换一份配置。
• 带内容团队时也一样：选题方向、发布节奏、审校清单是配置，产出流程是引擎。新成员上手 = 拿到一份配置文件。

当然它有边界：配置化本身有成本——抽象需要时间，配置文件会变复杂，过度配置化会把简单的事情搞绕。我的判断标准始终是那句话：这套逻辑会被用第二次吗？会，就抽；不会，就让它简单地去。

04和"人机分工"的关系

上一篇写 OpenJob 时我说"机器负责生成，人负责判断"。配置驱动是这句话的工程实现：你把判断写进配置（什么算好岗位、什么算高价值用户），机器按配置执行重复劳动。配置改错了，结果就错——所以配置本身需要被复核，就像 AI 的输出需要被复核一样。

框架已在 GitHub 开源，三步接入文档写在 README 里。如果你也有"每次都在改同一类脚本"的疲惫，欢迎拿去试。

框架地址：github.com/Batianxieshen1/ecommerce-growth-analysis，看板线上版在主页"造物"区可直达。开源协议 MIT。