给 Data Engineer、Analytics Engineer、BI / 数据平台同学：把 数据管道、RAG、semantic layer、eval、trace、治理 翻译成 AI 职业竞争力。
这本不是劝所有 Data Engineer 都改名叫 AI Engineer。更准确地说，AI 时代的 DE 会分化：一部分继续做数据平台，但要变成 AI-native；一部分转去 RAG、LLMOps、AI Platform；还有一部分会走数据治理和 AI 产品数据负责人。
你读的时候只抓三件事：哪些 DE 工作会被 AI 工具吃掉，哪些能力会更值钱，你该往哪条路线补项目和简历。
WEF 的 Future of Jobs 2025 把 AI、big data、software、security 相关职业放在增长主线里；LinkedIn 2026 Jobs on the Rise 也把 AI engineer 放到增长最快岗位之一。对 DE 来说，真正的问题不是“会不会被 AI 替代”，而是你还停在写 pipeline，还是已经能支撑 AI 系统。
表、文档、日志、工单、指标
DE 熟chunk、embedding、metadata、semantic layer
新增RAG、Agent、Eval、Trace、权限
目标
不要一边学 RAG，一边学 Agent，一边学 MLOps，一边刷 LeetCode。AI 时代的 DE 不是只有一条路，先选一条和原经历贴得住的线。
最贴近 DE。你负责文档入库、chunk、embedding、metadata、权限、刷新和检索质量。
可做项目：项目：公司知识库 RAG，支持 citation、ACL、错例回灌。
更偏平台。把模型调用、评估、trace、成本、灰度和权限做成团队能复用的底座。
可做项目：项目：prompt + eval CI，按模型、版本、用户拆成本。
会 dbt / semantic layer 的人很适合。把指标口径和自然语言问数连起来。
可做项目：项目：NL-to-SQL 指标助手，只允许查已定义 metric。
如果代码能力够，可以从 DE 切到应用层：RAG、tool calling、agent workflow、API。
可做项目：项目：带工具调用的数据排障助手，能查 Airflow/DBT 日志。
大公司会很需要。AI 项目最怕脏数据、越权、PII、口径混乱。
可做项目：项目：AI 数据准入 checklist + 自动化质量报告。
不一定纯写代码。负责把业务数据、指标、AI 场景、风险评估串起来。
可做项目：项目：为客服/销售/运营 AI Copilot 设计数据边界。
AI 应用看起来新，底层很多还是工程老问题：数据从哪来、口径怎么算、权限怎么控、线上怎么查。你要做的是把老能力翻译成 AI 语言。
别让 AI 直接猜业务指标。先把指标定义成 semantic model。
AI 数据不是一次性导入，文档更新、权限变化都要重新索引。
AI 答错不一定是模型差，很多时候是 chunk、metadata、freshness 出问题。
Airflow/dbt 的思维可以直接迁移到 AI 工作流。
RAG 最怕“检索到了不该看的数据”。DE 的治理经验很值钱。
能把一次回答拆成 retrieval、rerank、LLM、tool 四段，面试就有底气。
LangChain 把 RAG 拆成 indexing 和 retrieval/generation。DE 最容易补位的是 indexing：数据清洗、切片、metadata、embedding、索引刷新、权限过滤。
RAG 数据管道：
source docs / tables
-> clean + normalize
-> chunk by structure
-> add metadata: source, owner, time, ACL, version
-> create embeddings
-> vector / hybrid index
-> retrieval + rerank
-> answer with citation
-> eval + trace + feedback
AI 会把脏数据说得很自信，所以数据质量比以前更要命。一个 RAG 系统答错，可能不是模型差，而是文档过期、chunk 不完整、权限过滤漏了、指标口径乱了。
你如果已经做过数据治理或数仓项目，别把它写成“老 DE 经历”。扫 Angela 的码，可以先看怎么改成 AI 方向项目表达。
从 demo 到生产，差别不在 UI 漂不漂亮，而在能不能证明“变好了”。OpenAI 和 LangSmith 都把 eval 单独拿出来讲，就是因为 AI 系统不能只靠人工点几下。
| 要量什么 | DE 能怎么做 | AI 项目里怎么说 |
|---|---|---|
| Retrieval recall | 准备 golden queries 和 expected docs | 检索有没有把正确上下文找回来 |
| Citation accuracy | 抽样标注 source 是否支持答案 | 回答有没有证据，不是凭空编 |
| P95 latency | 分段计时和 dashboard | 慢在检索、rerank、LLM 还是 tool |
| Cost per answer | 按模型、prompt、用户、功能拆账 | 降本后还要重跑 eval |
DE 转 AI 的作品集，要让面试官看到你不只是会调 API，而是能把数据系统接进 AI。下面 4 个项目，选一个做到扎实，比做 5 个玩具 demo 强。
用 200-500 篇真实文档做 RAG。要求：metadata、source citation、用户权限、更新策略、10 个失败案例。
不用让模型自由写 SQL。先建 semantic model，让它只能解释和查询已定义 metric。
让 Agent 读取 DAG 状态、dbt test、warehouse query history，但危险动作只建议不执行。
把每次 AI 回答拆成 retrieval、prompt、model、tool、cost、latency。做 50-100 个 golden queries。
别只写“做过数据管道”。AI 招聘方想知道：你的数据管道能不能支撑 RAG？能不能做 eval？能不能治理权限？能不能查线上问题？
转型最怕“收藏了一堆课”。你只需要一个主项目，把 RAG、权限、eval、trace、简历表达都塞进去。
核对日期：2026-06-30。市场趋势用公开报告和公开媒体报道；技术做法尽量用官方文档，不把营销文章当技术依据。
把一个数据项目升级成 AI 项目：加 RAG、权限、eval、trace、失败案例。这样你不是被工具替代，而是变成能把 AI 落到企业数据上的人。