LO
这个职业有新的已核实记录时通知我 → · 标出哪些任务是你的(VOLO Pro,发布期间免费)→
数据分析师
把一个业务问题变成查询,把查询变成数字,把数字变成有人会据以行动的决策。
选你公司争议最多的那个指标,把定义写到两个人会算出同一个数字的精确度。发出去,数一数有多少反对。
这不是失业概率。它把「岗位任务中有多少暴露于自动化」与「采用实际走到了哪一步」合成为一个值 —— 只用于在同一套口径下横向比较职业,除此之外不作他用。
适用于使用 SQL、电子表格与 BI 工具的业务、产品与营销分析师。数据工程师、建模的数据科学家以及研究场景中的统计人员情况不同。
到底什么在变#
分析单位是任务,不是职位名称。职业不会被整体替代 —— 变的是它的任务构成。
每一格是一项任务。大小是它在这份工作里的分量,颜色是它正在往哪个方向走。点一格,看这个判断还不能说明什么。
「数据干净、问题清楚」是一个很大的前提。大多数公司两者都不成立,工具在含混的表结构上会给出自信的错误答案。
自助工具让管理者可以自己把问题问得不好,而不是去问分析师。「问对问题」仍然有价值,但分析师得在场才能提供 —— 而在场的人变少了。
可信度是个人的,而且积累得慢 —— 它护住的是已经站稳的分析师,别人沾不上。刚入职的分析师没有可信度,而现在能用来挣可信度的常规任务也变少了。
维护指标定义是比「回答问题」更小的活,而且一个组织只需要一份。所谓编制「转向」它,委婉地说就是更小的团队在做不同的事。
这就是你做的吗?认一下,这一页会缩到只剩与你有关的那一份。
职位名只是一组恰好被打包买走的任务,而没有两个人手里的那一组是一样的。什么都不会被发送出去 —— 它只留在这个浏览器里。
近期变化#
这是厂商的操作指南与参考实现,不是任何一家公司在用的报道 —— 原文没有点名任何雇主在运行它。按技术能力层记录,而这一层在本站永不改变评估。三个任务链接各自靠什么:模板自带的说明覆盖了找表、只读 SQL 与解释发现(写查询);它的前置条件与第 3 步要求使用团队提供指标定义、可信过滤条件与此前审阅过的查询,第 9 步只在有人明确要求时才保存一条纠正(拥有工具所依赖的指标定义);而它作为示例印出来的那几条过滤 —— 排除员工与测试账号、排除当天未完整的数据、8 月 18 日移动端结账埋点改过 —— 正是分析师对「数据在哪会骗人」的知识,由人提供,而不是被 agent 发现。日期取自 cookbook 里加入这个示例的那次提交,因为展示页本身没有日期。
演示、评测或论文表明技术上能做。它更新的是「技术能力」,不是「企业会怎么做」。
作者就是这个基准的作者,而且他们还有一个竞争性系统(Rubicon)要推 —— 所以这里的利益相关方,立场正是「那些容易的基准是错的」。但底层说法是可核查的:Beaver 用的是 MIT 那个 1400 多张表的 Oracle 数仓以及另外三个数仓的真实查询日志,榜单也是公开的。文中给出的四个原因是结构性的,而不是关于模型好坏 —— 公开基准的数据本来就在训练语料里、真实 schema 会腐化成六个都叫 salary 的字段、数仓里有本地黑话、真实查询往往要连两三张表而不是一张。
失败、撤回、监管或成本正在抑制采用。可以下调评估,或扩大不确定区间。
英国法定统计监管机构关于官方统计体系的报告。它说,在生产或传播官方统计数据时使用 AI 的机构,应当像对待其他统计方法或模型一样适用《统计实务守则》;更新后的指引将涵盖质量保证、人工监督和对产出的明确问责;官方统计中的 AI 使用仍主要是研究、测试和行政辅助,而不是日常生产。它针对的是政府统计人员而不是企业分析师,指引也还在更新中。
失败、撤回、监管或成本正在抑制采用。可以下调评估,或扩大不确定区间。
领英员工关于其内部文本转 SQL 聊天机器人的论文。它自 2024 年 7 月起在领英的查询平台上提供,每周稳定有 300 多名活跃用户。它依赖一个知识图谱:数据集负责人标注每一列是指标、维度还是属性,常用表有人写的说明;这些组件把被评为正确或接近正确的回答从 9% 提高到 48%。在专家对 124 个生产回答的评审中,53% 被评为正确或只有小问题,最常见的问题是筛选条件错误(24%);作者指出,「最新点击率」这个请求对不同团队意味着不同的东西。这是一家公司的内部工具,由开发者自己测量。
企业已正式投入使用。可以改变基线,但要结合规模与场景相似度加权。
Grab 工程师描述自己的内部数据工具。最常查询的数据表只有 20% 有文档;团队为最关键的表预先填入 AI 生成的文档,并通知数据生产者审阅,在生产者接受或修改之前,这些文档带「AI 生成」标签;这些表的文档覆盖率因此提高了 70 个百分点,达到约 90%,之后才推出大模型数据发现机器人。机器人运行在 Grab 采用的一个供应商平台上;数字是公司自己的。
企业已正式投入使用。可以改变基线,但要结合规模与场景相似度加权。
一家公司的有限发布;Uber 平台每月约 120 万次交互查询,此工具占比很小。原文自陈幻觉出的表/列与提示质量仍是未解问题。
企业已正式投入使用。可以改变基线,但要结合规模与场景相似度加权。
这对你意味着什么#
仅靠 SQL 能力入行比以前弱了,因为那正是工具在做的部分。更强的入口是「领域 + 数据」:把一个业务领域学到足以知道它的数字意味着什么、会怎么出错,查询交给工具。主动接下「写指标定义文档」这种不显眼的活 —— 新的分析师角色正在那里成形,而现在几乎没人愿意做它。
如果你一周大部分时间在满足报表需求,预期这个队伍会随着需求方自助而缩小,并预期你会以「你的工作改变了什么决策」而不是「交付了多少看板」被衡量。你积累的「数据在哪会出错」的知识是资产。把它变成语义层和指标定义,你就成了自助工具能给出正确答案的原因。
你的选择#
四个方向,每个都写明真实约束和一个本周可验证的动作。继续做下去也是正当选择 —— 只要它是被选择的,而不是被默认的。
从回答问题到拥有定义
自助分析把瓶颈从写查询转移到底层指标是否正确。这话是厂商自己说的:OpenAI 为这份工作发布的那个 agent 模板,把指标定义、可信过滤条件、以及此前审阅过的查询,列在「开始之前使用团队必须提供」的那一栏里。拥有那一层比拥有一张看板更耐久、也更资深。
治理工作慢、有政治性、很少被称赞。它需要一个已经为数字不一致吃过苦头的组织。
选你公司争议最多的那个指标,把定义写到两个人会算出同一个数字的精确度。发出去,数一数有多少反对。
转分析工程
在上游构建清洗数据的模型和管道,是大量分析师精力正在转移去的地方,而且报酬高于做报表。
需要真正的软件习惯 —— 版本管理、测试、代码评审 —— 以及对「做好了就没人看见」的工作的耐受。
选一条你每周都在跑的查询,把它变成一个有版本、有测试的转换。如果这个过程让你觉得满足而不是乏味,认真看这条路。
嵌入业务部门的分析师
财务、运营和产品团队越来越想要一个懂领域的自有分析师,而不是一个接工单的中央服务。领域知识就是护城河。
你会部分地成为那个部门的人 —— 要准备学它的词汇、它的日程和它的政治。
问某个部门的负责人:他最希望回答、却回答不了的问题是什么。如果你能看出怎么回答,你就找到了自己嵌入的位置。
常见问题#
值得,但理由和以前不同。你写的会更少,读和检查的会多得多。理解一条查询在做什么,是让你抓住工具在含混表结构上给出的那个自信错误答案的能力 —— 而这个「抓住」现在就是工作本身。像编辑懂语法那样学 SQL:不是为了亲自写每一句,而是为了一眼看出哪句错了。
信号是:谁在跑查询。当管理者开始在自助工具里自己回答问题、而不再把问题发给你时,变化就到了 —— 而你最先失去的不是工作,是那份每天接触数据、因而能看出它什么时候在骗人的手感。
写查询与做看板 —— 本页标为「正在自动化」的那一项。提出对的问题、以及知道数据什么时候在骗人,不在其中 —— 但这两件事都依赖你离业务足够近才有的上下文,而自助化会把你推远。
这是真实的工作,本站也把它标为新出现的任务。但它一个组织只需要一份,而且比「回答问题」更小。把编制说成「转向」它,是在客气地描述一个更小的团队在做不同的事。
还在读书、想往这个方向走?
这些专业能通到这里。它们的页面会拆解:哪些能力真的用得上、毕业生普遍缺什么。
这些判断底下是什么#
这一页上 5 条任务判断里,5 条有已核实事件支撑、0 条是平台推断,每一条都在它出现的地方标注着。它们底下是 2 个技术维度、一条自语言模型进入公众视野以来的回溯轨迹,以及 6 条已核实事件。
同一个职能里的其他岗位#
一家公司先把工作分成职能,再分成岗位。下面这些和这一份工作同在「技术与数据」里 —— 那是一件关于组织结构的事实,不是「它们相似」或者「它们在朝同一个方向变」的判断。
初级程序员 · 中高级软件工程师 · 前端工程师 · 后端工程师 · 数据工程师 · 算法 / 机器学习工程师 · AI 研究员 · 测试工程师 · 数据科学家 · 统计师 · 经济学家 · 业务分析师 · 业务系统与流程负责人 · IT 支持 / 技术支持 · 网络安全分析师 / 安全运营 · 运维 / 平台工程师 / SRE · 网络工程师 · 技术文档工程师 / 技术写作 · 基金申请书撰写人