蔚来数据分析岗笔试复盘：SQL窗口函数与业务案例实战解析

2024年秋招，我投了蔚来汽车的数据分析岗，笔试做完最大的感受是：蔚来这套题不是想刷掉你，而是想看清你到底有没有做过真正的数据分析工作。网上关于蔚来笔试的零散经验帖不少，但大多是“考了什么题型”“难度如何”这种两三句话，真正把解题思路掰开揉碎讲清楚的很少。这篇文章我把自己的复盘过程完整记录下来，从题型设计逻辑、核心考点、3道代表性真题的完整解法，到踩坑教训和备考建议，一次讲透。如果你是准备车企数据分析岗位的求职者，或者单纯想看看商业数据分析笔试到底在测什么，这篇文章可以直接当参考。

1. 蔚来数据分析岗笔试的整体设计与破题思路

1.1 笔试的定位：不只是筛人，更是一次真实工作场景的预演

蔚来作为造车新势力里数据基建做得比较早的公司，数据分析岗笔试和传统互联网大厂有个明显区别：纯背概念、刷题库能过的概率很低。整套卷子给我的感觉是，出题人明显是把日常工作中会遇到的场景直接搬到了试卷上——用户增长团队关心的留存率、换电运营团队关心的电池健康度、销售团队关心的转化漏斗，这些都成了考点。

这也暴露了蔚来笔试的第一条底层逻辑：他们要的不是“懂数据分析理论的人”，而是“拿到业务数据能快速产出结论的人”。所以整张卷子几乎每一道题都在逼着你把技术能力和业务场景绑在一起思考。如果只是会写SQL、会调pandas，但不知道留存率为什么要分群算、电池损耗数据为什么要做异常检测，答题的时候就会明显觉得“使不上劲”。

从我身边参加笔试的同学反馈来看，蔚来这套题还有一个特点：时间紧凑度中等偏上，考的是熟练度而不是极限手速。题型以单选、多选、SQL编程题、Python编程题、业务案例简答题为主，整体下来大约90到120分钟。它不是那种让人完全写不完的变态难度，但如果前面在概念题上纠结太久，后面的编程题和案例分析就会很被动。

1.2 题型结构与时间分配：先抓大分，再啃硬骨头

拿到卷子我第一件事不是埋头做题，而是花了两分钟快速扫了一遍全局。我的判断是：SQL和Python两道上手题占了将近一半分值，业务案例题是拉开差距的关键，前面的单选题反而是最需要控制时间的部分。

当时自己拟了一个时间分配方案，参考价值比较大，整理成表格方便你们对照：

这个分配看起来有点反直觉，因为我刻意把单选题的时间压得很短。原因很简单：选择题这种客观题每题分值有限，就算全对也拉不开差距，而编程题和业务题才是展示分析能力的主战场。实际做下来这个策略很稳，我最后甚至留了几分钟回头检查SQL代码的逻辑漏洞。

2. 核心考点逐项拆解：统计学、SQL、Python、业务思维一个都不能少

2.1 统计学部分：假设检验和AB测试是真正的重头戏

蔚来笔试对统计学的考察不是让你背公式，而是给你一个业务场景，让你判断用什么方法、怎么解释结果。单选题里出现了中心极限定理、置信区间含义这类基础题，但更值得关注的是AB测试相关的多选和简答。

关于AB测试，有一个很典型的考法：某项产品改动上线后，观测组和对照组的转化率分别提升了0.3%和0.1%，p值为0.04，问这个结果能不能说明改动有效。很多人的第一反应是“p值小于0.05，说明显著有效”，但正确答案往往要求你考虑多重检验问题、样本量是否足够、以及实际业务提升幅度是否具备商业意义。

统计学这块我的复习思路是从“为什么”入手，而不是“怎么算”。比如置信区间，不是背“95%置信区间”的定义，而是要理解它和业务决策的关联——如果区间跨越了0，那就意味着影响方向都不能确定，这时候谈“显著提升”就是自欺欺人。这是商业数据分析里最容易翻车的点，也是出题人最爱挖的坑。

2.2 SQL部分：窗口函数和复杂join是分水岭

SQL是数据分析岗笔试的基本盘，蔚来考得比很多互联网大厂更贴近业务。常见的注册表、活跃表、订单表、换电记录表都会出现，考察点集中在三类：

第一类是聚合查询和时间维度计算，比如按月份统计不同车型的订单量、计算用户注册后7天内的活跃率，这类题要求你对group by和case when非常熟练。第二类是窗口函数，比如用row_number()给用户按活跃天数排名、用lag()计算相邻两次换电的时间间隔，这类题是拉分项，平时不经常用窗口函数的人会在这里卡壳。第三类是多表关联的细节处理，比如考察left join和inner join在数据膨胀场景下的差异。

我印象很深的一道SQL题是让你统计“每个换电站当月首次换电的用户数”。如果不懂窗口函数，常规思路是先按用户和站点分组算最小时间，再套一层子查询去重，写出来极其啰嗦。而用row_number() over (partition by user_id, station_id order by swap_time)一条窗口函数就能解决。这就是蔚来在SQL题里的节奏：用最直接的业务需求，考察你有没有用最合适工具解决它的习惯。

2.3 Python部分：pandas和numpy的基础功比花活更重要

Python题的难度整体友好，但很考验代码习惯。考点基本围绕pandas的数据清洗、分组聚合、透视表和简单可视化展开，偶尔会涉及numpy的数组操作。

卷子里有一道题是给出车辆上报的GPS轨迹数据，要求清洗缺失值后计算每辆车的平均行驶速度。如果熟悉pandas的话，这道题的核心是处理时间格式、按车辆分组、计算时间差和里程差，最后汇总成速度。如果对pandas不熟，就会陷入用for循环逐行遍历的泥潭，代码慢不说，还容易出错。

在这里我想强调一个经常被忽略的点：笔试平台运行代码的环境跟本地可能有差异，有些平台不允许联网，pandas版本也可能不一样。所以平时练习的时候，要养成不依赖第三方扩展库、不用过于冷门API的习惯。能直接用pd.to_datetime和groupby解决的问题，就不要用pd.read_sql或者需要额外安装的库。

2.4 机器学习基础与业务场景结合

机器学习在蔚来笔试里占比不大，但属于“必考一道”的类型。常见的出题方式有两种：一种是给出一个业务问题，让你选择合适的算法；另一种是给你一段模型的评估结果，让你判断问题出在哪。

比如有一道多选题问：预测用户未来3个月是否会再次购车，样本量10万，正负样本比1：9，以下哪些处理方式是合理的？选项有随机欠采样、SMOTE过采样、调整分类阈值、直接使用准确率作为评估指标。前三个都是合理手段，第四个明显是陷阱——类别不平衡的场景下准确率没有参考意义，应该看AUC或F1值。

这类题考察的其实就是商业数据分析的基本功：知道什么场景用什么模型、怎么评估模型效果、怎么把模型结果翻译成业务语言。不会让你手推梯度下降，更不会让你手写神经网络反向传播，这一点准备起来相对轻松。

3. 实操复盘：3道高价值真题的完整解题过程

3.1 SQL实战：用窗口函数计算用户7日/30日留存率

这道题是蔚来笔试里比较有代表性的SQL题，表结构如下：

-- 用户注册表 CREATE TABLE register ( uid STRING, reg_date STRING ); -- 用户活跃日志表 CREATE TABLE active_log ( uid STRING, act_date STRING );

题目要求：统计2024年8月新增注册用户在注册后7日和30日的留存率，结果保留两位小数，输出格式为 reg_date、d7_retention_rate、d30_retention_rate。

我当时的解法分三步走。第一步，筛选出8月注册的用户并去重；第二步，把注册表和活跃表按用户关联，计算每次活跃距离注册日期的天数差；第三步，用条件聚合算出7日活跃用户数和30日活跃用户数，再除以总注册人数。

WITH reg AS ( SELECT uid, reg_date FROM register WHERE reg_date BETWEEN '2024-08-01' AND '2024-08-31' ), active AS ( SELECT DISTINCT uid, act_date FROM active_log WHERE act_date BETWEEN '2024-08-01' AND '2024-09-30' ), user_ret AS ( SELECT r.reg_date, COUNT(DISTINCT r.uid) AS total_users, COUNT(DISTINCT CASE WHEN DATEDIFF(a.act_date, r.reg_date) >= 7 THEN r.uid END) AS d7_users, COUNT(DISTINCT CASE WHEN DATEDIFF(a.act_date, r.reg_date) >= 30 THEN r.uid END) AS d30_users FROM reg r LEFT JOIN active a ON r.uid = a.uid GROUP BY r.reg_date ) SELECT reg_date, ROUND(d7_users * 100.0 / total_users, 2) AS d7_retention_rate, ROUND(d30_users * 100.0 / total_users, 2) AS d30_retention_rate FROM user_ret ORDER BY reg_date;

这道题有两个关键的坑。第一个坑是活跃表里同一个用户一天可能有多条访问记录，如果不先去重，join之后会出现数据膨胀，导致count(distinct)结果虽然没错，但中间表变得巨大，影响性能。第二个坑是取30日留存时，活跃时间区间必须覆盖到注册后30天，如果只统计到2024-09-15，那么8月20日之后注册的用户30日留存会被低估。

提示：实际笔试中如果时间窗口参数给得模糊，建议在注释里写明你的假设。我那次就在代码注释里写了“假设30日留存定义为注册当日算第0天，第30天仍有访问记录”，这种细节能体现你对口径的敏感度，是加分项。

3.2 Python实战：换电电池健康度数据分析与异常检测

这道Python题比较有意思，给出的是一份换电记录表，字段包含station_id、battery_id、swap_time、vehicle_id、battery_health。题目有两问：第一问是统计每个换电站的平均换电时长和换电次数；第二问是找出健康度下降最快的Top10电池，并判断是否存在异常。

第一问比较简单，pandas几行就能解决。需要先清洗时间字段，再用groupby聚合，有一个细节是按站点聚合前要先按时间排序，因为计算单次换电时长需要同一站点相邻两条记录的时间差。

import pandas as pd import numpy as np df = pd.read_csv('battery_swap.csv') df['swap_time'] = pd.to_datetime(df['swap_time']) df.drop_duplicates(inplace=True) # 按站点和时间排序 df = df.sort_values(['station_id', 'swap_time']).reset_index(drop=True) # 计算同一站点相邻两次换电的时间差 df['duration_gap'] = df.groupby('station_id')['swap_time'].diff().dt.total_seconds() / 60 # 过滤掉跨站点的边界记录 valid = df.dropna(subset=['duration_gap']) # 统计每个站点的平均换电时长和换电次数 station_stats = valid.groupby('station_id').agg( avg_swap_minutes=('duration_gap', 'mean'), swap_count=('swap_time', 'count') ).reset_index()

第二问考的是对“健康度下降”的定义，这个没有标准答案，考察的是你定义业务指标的能力。我的做法是计算每块电池的初始健康度和最新健康度的差值，再除以使用时长。

battery_trend = df.sort_values(['battery_id', 'swap_time']) battery_trend['health_diff'] = battery_trend.groupby('battery_id')['battery_health'].transform(lambda x: x.iloc[-1] - x.iloc[0]) battery_trend['usage_days'] = (battery_trend.groupby('battery_id')['swap_time'].transform('max') - battery_trend.groupby('battery_id')['swap_time'].transform('min')).dt.days battery_summary = battery_trend.groupby('battery_id').agg( total_health_change=('health_diff', 'last'), usage_days=('usage_days', 'last'), swap_times=('swap_time', 'count') ).reset_index() battery_summary['health_decline_per_day'] = -battery_summary['total_health_change'] / battery_summary['usage_days'].replace(0, np.nan) top10 = battery_summary.nlargest(10, 'health_decline_per_day')

异常判断我用了一个比较简单的方法：计算所有电池日健康度下降值的均值和标准差，超过均值加3倍标准差的标为异常。代码本身不难，但有个地方容易被忽略——有些电池可能只换过一次电，usage_days为0，这里要做除数保护，否则会直接报错。这种细节就是笔试和本地刷题的区别，在线评测平台不会给你debug提示，运行了才发现报错就浪费了时间。

3.3 业务案例题：订单转化率下降如何归因

业务题没有标准答案，考的是分析框架和逻辑链条。题目大概是：某车型9月的订单转化率环比下降15%，你是数据分析师，会如何分析原因，请写出分析思路。

这类题最忌讳上来就写“我要看一下哪个渠道出了问题”，这种回答太宽了。我的回答逻辑是先拆指标、再分维度、后提假设、最后用一个分析计划收尾。

指标拆解上，我把订单转化率拆成“各环节转化率”的乘积：曝光→试驾→下订→锁单→交付。因为环比下降15%是个结果指标，一定要先定位到具体哪个环节降了。分维度上，至少要从渠道（App自然流量、线下门店、合作渠道）、城市级别（一线/新一线/二三线）、用户画像（新用户/老用户/增换购用户）三个维度做分层对比。有了维度拆解，再结合政策、竞品、季节因素提出假设，比如“是否9月竞品集中上新导致App端到店率下降”“是否门店销售政策调整导致试驾转化率下降”。

最后我给了一个分析计划：先拉出各环节漏斗数据，按城市和渠道维度做同环比对比，定位下降最集中的环节；再针对该环节下钻到用户行为日志，配合用户调研做归因；最后给出短期预警方案和长期监控指标。这样回答的好处是既体现了商业数据分析的思维框架，又给出了可以落地的执行步骤，出题人能看到你不是只懂技术，还懂怎么把数据和业务决策串起来。

4. 笔试中的常见陷阱与实战避坑指南

4.1 概念题里最容易丢分的3类考点

蔚来笔试的单选题里有很多“看起来很简单，实际上全是坑”的题。我复盘后总结了3类高频丢分点。

第一类是统计学概念的口径问题。比如“95%置信区间”的正确理解是“重复抽样100次，大约95次构造的区间会包含总体参数”，而不是“总体参数有95%的概率落在该区间”。后者是初学者最常见的错误表述，在选择题里几乎必考。第二类是AB测试的显著性判断，容易被p值小于0.05蒙蔽，忽略样本量不足、多重比较、新奇效应这些实际问题。第三类是机器学习评估指标的选择，在正负样本不平衡的场景下准确率没有意义，要选AUC、F1、召回率等指标。

这三类题丢了分很可惜，因为它们不需要复杂计算，纯粹是概念理解问题。我当时备考的时候把每个考点都做了一张“易错点对照表”，这里挑最核心的分享出来：

4.2 编程题的细节处理：不报错不代表能拿满分

笔试平台和本地环境不一样，它对代码的容忍度很低。我那次Python题没报错，但我出来复盘的时候发现自己漏了一种边界情况——就是前面说的usage_days为0的情况。这种错误在本地跑自己的测试数据可能永远不触发，但在笔试的隐藏测试用例里很容易暴露。

所以我的建议是：编程题写完一定要花两分钟检查三个地方。第一，是否有除零风险，涉及到除法的地方都要看看分母是否可能为0；第二，是否考虑过空表和全空值的情况，groupby之后如果某个组没有数据会返回空结果，你的代码能不能处理；第三，时间字段是否有格式不一致的问题，比如有的记录是日期、有的是时间戳，不统一就会导致类型转换报错。

这些细节看着不起眼，但在笔试评分里占比很大。因为客观题和简答题的区分度有限，编程题的隐藏测试用例才是拉分的关键。你写得再漂亮，只要有一个case跑不过，分数照样扣。

4.3 时间管理上的一个反常规建议

有些人习惯按顺序做题，但我建议拿到卷子先跳过最后一道案例分析题，把前面的编程题做完后再回头写。原因很简单：案例分析题没有标准答案，写多写少都在一念之间，很容易陷入“写满才安心”的误区，结果挤占了后面编程题的时间。

我当时的策略是先快速做完选择题，然后直接奔SQL和Python编程题，用完整的时间块把代码写完，最后再留20分钟专心写案例分析。那20分钟里我全程用的是“框架+关键词+短句”的写法，每一点只写两三行，不铺开写长篇大论，保证答题密度优先于篇幅长度。

注意：如果你在编程题卡壳超过10分钟，立刻切换到下一题。数据分析笔试的编程题往往是一环扣一环的，第一问写不出来第二问很难独立完成，与其耗着不如先保证其他题的完整度。

5. 备考重点与笔试后的复盘衔接

5.1 三周冲刺周期的复习内容安排

我复盘完整张卷子之后，大致估算了一下备考时间。如果是从零开始，建议至少留三周，按下面的节奏走：

第一周主攻统计学和SQL。统计学重点看假设检验、置信区间、AB测试的原理与案例，SQL重点练习窗口函数和复杂join。这个阶段不用做题海，而是每个知识点找两三道代表性题目做透，尤其是要搞明白每道题背后的业务场景。第二周主攻Python和机器学习基础。Python把pandas的groupby、merge、apply、pivot_table这些高频操作练熟，机器学习重点复习逻辑回归、决策树、聚类的基本原理和评估方法。第三周做整套模拟题，严格控制时间，训练做题节奏。

有一个经验很关键：练习时不要只刷LeetCode风格的SQL题，要特意找有业务背景的题来做。像“统计各门店销售额环比增长率”“分析用户复购周期分布”这类题目，才能模拟笔试的真实场景。蔚来笔试的题不是考算法，而是考你在业务约束下能不能干净利落地出结果。

5.2 笔试结束后的复盘动作：为面试铺路

笔试结束不代表这件事就完了。我每次面完试或考完笔试，都会立刻趁热打铁做一份复盘文档，记录三件事：卷子里出现的题型、自己卡壳的环节、以及面试时可能被追问的点。

比如我发现自己对“留存率口径定义”的思考不够快，那接下来面试前就会重点准备“新用户次日/7日/30日留存分别怎么定义、指标口径差异对业务决策有什么影响”这类问题。再比如业务案例题里写了“结合用户调研做归因”，面试官大概率会追问“用户调研具体怎么做、样本量和可信度如何把控”，这些都需要提前准备好，不能只停留在框架层面。

笔试题目和面试问题往往是强关联的。笔试里考的点，大概率是面试官认为数据分析师日常工作中最重要的能力。你把笔试复盘做透，就相当于提前预判了面试提问方向。

6. 关于蔚来数据分析笔试，我还想多说几句

从投简历到笔试再到面试，蔚来数据分析岗的考察逻辑始终围绕着一个核心：你能不能把数据分析用到真实业务里。整车厂的数据分析和大厂有一点不太一样，这里要面对的数据更杂、业务链条更长，从销售端到用户运营端再到车辆运营端，数据口径多种多样，业务协作链路也很长，这对数据分析师的业务理解能力和沟通能力要求非常高。

笔试只是第一步，后面还有面试环节等着你。以我自己和身边同学的经验来看，能过笔试的人已经具备不错的数据处理基础，但面试时还会考察项目经历、沟通表达、逻辑思维和对汽车行业的理解。如果时间充裕，笔试结束后可以多研究一下蔚来的产品线、用户社区模式，以及“换电模式”如何影响数据采集和分析的组织方式，这些内容在面试阶段会成为你区别于其他候选人的差异点。

最后分享一个自己踩过坑之后养成的习惯：每次笔试前，把所有常用函数的参数和边界条件过一遍，不要以为“用过几百次就一定会写对”。我在面试前模拟写一个时间序列窗口聚合的SQL，结果就在lag()的参数顺序上卡了两分钟。平时越熟悉的东西，笔试越容易因为紧张而出错，这跟驾考时最容易挂在侧方停车是一个道理。稳扎稳打，把基本功打磨到不经过大脑也能正确输出，笔试这一关就稳了。