面试复盘时，一位同学去面某厂的数据开发岗。二面进行到一半，面试官突然问：
❝ "你做过的数仓里，哪一层最适合给 RAG 做检索？为什么？"
他一下被问住了。SQL 八股背了，维度建模复习了，Spark 调优也准备得很充分。偏偏这道题，既不像传统数开题，也不是纯粹的大模型题。
面试结束后，他跟我吐槽："感觉这两年，数开岗位静悄悄换了一茬题。题库变了，自己却连通知都没收到。"
这句话很真实。很多数开不是能力突然不够了，而是岗位的考察坐标发生了偏移。接下来，我们就把这件事拆开说清楚：题目为什么变、变到了哪里，以及现在该怎么准备。
1.不是题库更新，而是岗位的终点变了
把两三年前和现在的数开面试题放在一起看，最明显的变化，并不是题库里多了几个 AI 名词，而是数据最终要服务的对象变了。
过去，数开的主要任务是"把数据做好，给人看"。数据经过采集、清洗、建模和汇总，最后进入 BI 报表、经营看板和分析系统，帮助业务人员做判断。
因此，传统能力栈一直很稳定：
- SQL、维度建模，以及星型模型与雪花模型的取舍
- Hive、Spark、Flink 的开发与性能调优
- ODS、DWD、DWS、ADS 等数仓分层
- 调度、ETL、数据质量与异常追溯
- 元数据、血缘、数据字典等治理能力
这些能力没有过期。只是今天，越来越多的数据还要"给 AI 用" 。Agent 要能稳定调用，RAG 要能准确召回，模型还要从真实反馈中持续改进。于是，能力栈上面又叠了一层：
一句话概括
**❝**以前的终点是"BI 给人看"，现在又多了一个终点：让数据成为 AI 可以理解、检索、调用和追溯的上下文。不是旧题被新题替代，而是旧能力之上增加了新的使用场景。
2.别急着"再学一门 AI"
看到题目变化，很多人的第一反应是：赶紧刷 Transformer 架构、背 Prompt Engineering，再把大模型名词过一遍。
基础概念当然要懂，但如果准备只停在背诵层面，收益往往有限。原因也很直接：标准答案随手就能查到；没有真实链路经验，追问两层就容易露怯；更重要的是，你原本最值钱的数据经验反而没有被用起来。
很多看似陌生的新名词，其实都能在旧能力里找到对应关系：
你甚至可以拿过去的项目，逐个追问：
- 如果把结构化事实转成可检索语料，应该怎样组织文本、Chunk 和元数据？
- 原来的数据质量监控，哪些指标可以迁移到检索质量监控？
- 已有的元数据和血缘，怎样帮助回答结果追溯到来源表、版本和加工规则？
这套转换做完，你的定位就不再是"会一点 AI 的数开"，而是"能把 AI 数据链路做稳的数开"。两者听起来只差几个字，实际稀缺度完全不同。
可以立刻做的 3 个动作
**❝**动作一：重写一遍旧项目
给每个做过的数仓项目补一段：如果今天重做，并增加 RAG 或 Agent 的使用场景，数据模型、权限、质量指标和更新机制会怎么变？
❝ 动作二：跑通一个端到端项目
不要只做能演示的 toy demo。项目里要有真实数据、可量化指标、异常处理、增量更新和可追溯链路。
❝ 动作三：做一次业务方案演练
假设业务方要上线一个 Agent，你从数据侧给出完整方案：数据从哪里来、如何清洗、如何检索、怎样控权、怎么监控，以及 bad case 如何回流。
3.真正拉开差距的 3 项能力!
第一层问题考你知不知道，第二层、第三层就会追问你到底做没做过。下面三项能力，正是新题里最容易被向下深挖的地方。
❝ 能力一：打通"数据 → Embedding → 向量库"
重点不是接通一个 Embedding API，而是把整条链路做成可上线、可扩展、可维护的数据系统。你至少要能说清楚：
- Chunk 如何按句子、段落或语义切分，是否需要 overlap
- HNSW、IVF、PQ 等 ANN 索引如何在召回率、内存和延迟之间取舍
- 百万级数据怎样批量写入，如何避免把向量库打爆
- Embedding 模型升级后，怎样重建索引并平滑切换，不影响线上服务
你会发现，批量处理、性能调优、增量更新、双版本切换，本来就是数开的优势区。
**❝**能力二：理解 SQL、图谱、全文与向量的边界
SQL 擅长精确过滤和聚合，却不擅长复杂关系推理；向量检索能找到语义相似内容，但对产品编码、金额、日期等精确条件并不可靠；全文检索适合关键词匹配，却未必理解用户换了一种说法后的真实意图。
生产级 RAG 往往不是"只选一个"，而是把结构化查询、图谱关系、全文和向量召回组合起来，再通过 Rerank 融合结果。能讲清每种方案的边界，比只会报技术名词更重要。
**❝**能力三：把数据反馈闭环真正跑起来
AI 使用数据，产生调用日志；日志里暴露失败请求和低质量答案；团队再从中识别 bad case，回流到检索数据、评测集或训练集。
这不是一句"持续优化"，而是一条需要口径、版本、标注、调度、质量监控和效果评估的数据链路。模型工程师更关注模型本身，数开最有优势的，恰恰是把闭环里的数据流做稳。
4.更适合数开的实战路线
如果想把上面的能力真正练出来，可以按下面四个项目逐步推进。它不是四个彼此孤立的 demo，而是一条从数仓治理走向 Data Agent 的完整链路。
❝篇一：金融数仓 + 数据治理
覆盖 ODS、DWD、ADS 分层，补齐主数据、数据契约，以及 SLA/SLO 等治理机制。先把可信数据底座做稳。
❝篇二：实时离线 Pipeline + 知识图谱
通过 Flink CDC 构建实时链路，处理双流同步、实体管理和图谱关系，让数据不仅能查字段，还能查关系。
❝篇三：搜索引擎 + 语义检索
组合 Elasticsearch、BGE、混合召回与 Rerank，建立可量化的检索评测体系，持续优化 Recall、Precision 和最终答案质量。
❝篇四：Data Agent + 反馈闭环
加入 SQL 沙箱、Function Call、bad case 挖掘和数据集回流，把检索、调用、安全与迭代串成闭环。
最后
数开不会凭空消失，但会继续进化，同样前后端也不会消失，但是会AI+,数据分析等。我们要通过现象看本质，AI+时代的本质。
这场变化，并不是简单地用 AI 替代数据开发，而是要求数据开发进一步成为"AI 的数据工程师"。你不必人人都去训练模型，但需要理解 AI 如何消费数据、在哪些地方容易失真，以及怎样让这条链路稳定、可控、可追溯。