2024 年下半年，我们开始做 ChatBI，让不会写 SQL 的业务同事直接用自然语言查数据。上线之后，简单查询从半小时压缩到几分钟，复杂分析也开始从按天计算变成按分钟计算。后来又往前走了一步，把取数、圈人、画像、行为序列、AB 评估做成 Agent 可以调用的 Skills。

为了让 Agent 得到可靠的结果，我们不得不把分析师和数仓工程师脑子里的知识写出来：指标该用哪张表，字段什么时候改过口径，什么波动值得追，什么结论只是相关性，什么情况下应该拒绝回答。过去，这些知识散落在一个个数据从业者的脑子里。现在，它们正在变成 Agent 可以读取的 Context、Skill 和 Eval。

我把让 Agent 能够可靠使用企业数据的这层能力叫作 Data Harness。越往下做，一个感受越清楚：它正在把数据从业者的隐性知识变成机器可以使用的基础设施。而这些隐性知识，恰恰是很多数据岗位过去的护城河。

说白了，我们在亲手拆自己行业的护城河。

所以想认真探讨一个问题：数据领域几个主要岗位的 AI 暴露度到底怎么样，出路在哪里。

这里说的 AI 暴露度，指一个岗位的核心任务有多少已经具备由 Agent 独立完成的条件。任务暴露并不意味着岗位立即消失，最终需要多少人，还取决于可靠性、责任归属，以及成本下降后会不会产生更多需求。但完成同样工作的时间大幅下降，原来的团队规模很难不受影响。这个过程会用一年、三年还是更久，我说不准。

总的判断

数据岗位表面上差异很大，过去的护城河却很相似：既知道怎么把活做出来，也知道那些没写在文档里的规则。哪张表能信，哪个指标是谁定的，什么结果看起来对其实错了，出了问题该找谁。

Agent 同时在削弱这两层优势。Data Agent 接手查询、分析和表达，Coding Agent 接手 SQL、ETL 和平台代码，Data Harness 再把原本依附在人身上的知识变成组织资产。

几个岗位的边界最后会怎么变，我现在判断不了。能确定的是，各岗位内部的执行工作都在被压缩。

但我对数据职能的总判断仍然是收缩。不同岗位只是速度不同，没有哪个传统岗位会因为 Agent 普及而整体扩张。新增的 Context、Eval 和治理工作很重要，但需要的人不会太多。

分岗位看

分析师（BI）

暴露度最高，没有悬念。

分析师很多年里很大一部分工作的本质是「翻译」：把业务问题翻译成 SQL，把查询结果翻译成图表和报告。这一层有明确的输入输出，错误也相对容易验证，是 Agent 最容易接手的部分。

这个岗位会越来越「哑铃化」。一端是贴着决策者工作的分析师，价值是知道接下来该问什么，能解释数字背后的业务变化；另一端是对口径和结论承担责任的人，审计、财报、对外披露的数字，最后总要有人签字。中间那层以取数、制表和常规专题分析为主要价值的分析师，空间会被持续压缩。

这里最危险的未必是初级分析师。初级便宜，还能承担基础工作。更容易被成本审视的，是价格已经上去，工作内容却仍然可以被拆解和验证的中间层。把 SQL 写得更好，报告做得更精美，回报会越来越低。

还有一个长期问题。过去，一个初级分析师通过几年取数逐渐熟悉业务。取数岗位减少之后，企业不会自动得到更成熟的分析师，只会失去原来的训练场。还处在职业早期的分析师，应该尽早让 Agent 接手机械执行，把时间花在追问「这个数为什么长这样」上。

数据科学家（DS）

这个岗位要拆成两个物种。

第一种是执行建模的 DS。早在 LLM 之前，机器学习平台就已经把很多建模工作变成了填参数、跑流程。现在 Agent 可以继续接手特征分析、生成和修改代码、比较实验结果、整理报告。在文本分类、信息抽取这类任务上，一些过去需要训练专有模型的问题，已经可以直接调用基础模型解决。「把模型跑出来」这件事正在贬值。

但流失预测、定价和排序这些结构化预测任务，不能普遍靠调用一次基础模型 API 解决。变化更快的是建模过程里的人工执行，不是专有模型整体消失。

第二种是能定义问题的 DS。业务方提出一个目标，他们要把它变成可以检验的问题：要预测什么，应该做实验还是看历史数据，用什么指标和方法，什么结果才算有效。Agent 可以写代码、跑模型，也可以给出一份统计上很漂亮的结论，但它不会让一个定义错的问题变对，混杂因素也不会因此消失。

所以，以执行建模为主要价值的 DS，位置会减少。统计训练仍然值钱，但价值会更多体现在问题定义、实验设计、因果识别和模型验证上。只会把模型跑出来，已经不够了。

数据开发工程师（数仓）

这是国内数据团队里人数最多的岗位，收缩的绝对规模也可能最大。

一头是接需求、写 SQL、搭调度的执行型数仓。他们脑子里也装着全公司的口径、血缘和坑：哪张表不能信，哪个字段改过定义。这曾经是真实的护城河。但 Data Context 建设做的事，恰恰是把这些知识显性化到语义层里。护城河被填平，而且往往是他们自己动手填的。

另一头是做业务建模的数仓。好的数仓工程师，价值从来不在写 SQL，而在把混乱的业务过程抽象成一套能复用、能对齐口径的数据模型。这件事和语义层、Data Context 建设本来就是同一类工作，只是换了技术载体。

这个岗位留下来的，会是最懂业务建模和口径治理的那批人。对数仓工程师来说，继续把 SQL 写得更熟，回报会越来越低。更值得投入的是业务建模、口径治理和语义层的持续维护。

数据平台工程师

这是短期最安全，也最容易产生错觉的岗位。

性能、稳定性、权限、安全和成本仍然需要工程师负责，Coding Agent 暂时接不走生产责任。但写服务、配资源、排查故障这些任务同样在被压缩。云厂商的托管服务早已减少了企业维护底层集群的需要，Agent 只是继续沿着这个方向往前走。

Data Harness 也不是建完就结束。Context 会过期，Eval 要持续回归，权限边界和纠偏机制要跟着场景演进。但持续演进不等于持续需要一支大团队。基础能力稳定之后，工作会更多转向 Context 维护、持续评测、权限治理，以及生产环境里的稳定性和成本。

平台工程师的优势是能力带得走，分布式系统和生产工程经验可以迁移到 Agent infra、推理平台和通用后端。它对个人是好去处，但撑不起一群数据从业者的出路。

数据产品经理

这个岗位面对的，是产品形态本身的动摇。

我早年做过几年 BI 工具，对这一点体感很直接。拖拽式报表、自助分析、可视化配置，这套产品逻辑的前提是「用户不会写查询语言，所以需要一个图形界面」。对话成为界面之后，大量临时查询不再需要先配置一张报表。

固定看板不会消失。监控、汇报和形成组织共识，仍然需要稳定的界面。但 self-service BI 作为统一入口的地位正在消失，做这类工具的数据 PM，手里的产品边界会越来越窄。

数据 PM 接下来要设计的是：问题什么时候需要澄清，什么结果可以直接展示，什么操作必须确认，错误怎么反馈，权限怎么申请。过去数据 PM 主要设计人怎么使用数据产品，现在还要设计人怎么和 Agent 一起工作。

这要求数据 PM 补上技术判断。至少要能跑一遍 Eval，看得懂一次错误来自模型、Context、工具还是数据本身。只会接需求和画页面的人，暴露度同样很高。

一个共同规律

五个岗位都承担了某种翻译：分析师翻译业务问题，DS 翻译统计方法，数仓翻译业务过程，平台翻译系统复杂度，数据 PM 翻译各方诉求。Data Harness 做的事，就是把其中可以描述、重复和验证的部分沉淀下来，让 Agent 可以直接使用。

过去需要多人反复执行的工作，未来可能只需要少数人维护规则和处理异常。所以这轮变化对整个数据职能是总量收缩，不是岗位之间简单轮动。Agent 带来的新增工作是真实的，但 Context、Eval 和治理需要的人有限。

最终的数据团队长什么样，我不知道。但团队会更小，执行岗位会更少，能承担专业责任的人会更重要。

出路

如果一个人的主要工作仍是取数、写 SQL、搭报表、跑模型或维护组件，风险已经很高。这些任务越来越容易描述、拆解和验证，完成它们的成本也在下降。继续提高执行熟练度，很难再换来过去一样的回报。

留在原岗位，工作内容也得变。分析师要从交付数字走到解释数字，对进入决策的结论负责；DS 要负责定义问题、设计实验和验证结果；数仓工程师要做业务建模和口径治理；平台工程师要更多处理架构、安全和成本；数据 PM 要设计 Agent 的使用方式和行为边界。

另一个方向是 Data Harness。Context 需要整理和更新，Eval 需要持续运行，权限和纠偏机制要有人设计，高频的分析流程也要做成 Skill。这些建设方法会逐渐标准化，但具体问题不会消失：哪些口径已经过期，哪些错误会影响业务决策，系统出问题时怎么控制影响。

也会有人离开传统的数据团队。平台工程师可以去做 Agent infra、推理平台和通用后端；DS 的统计和实验训练，可以用在实验平台、模型评测和风险决策里；熟悉业务的分析师和数据 PM，可以进入更靠近经营和产品决策的位置。