AI工程师求职指南：数据从业者30天转型LLM应用开发岗

本文来源于数据从业者全栈知识库，更多体系化内容请访问知识库。

这是 2024-2025 年增长最快的技术岗位，也是目前市面上求职指南最少的岗位之一。本文帮你把这件事想清楚。

相关文档：AI数据工程师岗位解析 | AI时代数据人的职业地图 | AI数据岗位全景导览

目录

• #一、AI Engineer 是什么岗位
• #二、国内外岗位全景
• #三、核心技能地图
• #四、简历写法
• #五、面试核心题库
• #六、项目作品集建议
• #七、30天转型路线图

一、AI Engineer 是什么岗位

先把概念说清楚，因为市场上这三个岗位经常被混淆。

1.1 与其他岗位的本质区别

一句话区分：数据工程师管数据从哪来、去哪里；ML Engineer 管模型怎么训练；AI Engineer 管 LLM 能做什么、做得好不好。

1.2 AI Engineer 的核心工作内容

这个岗位的日常工作，大概是这样的：

设计和实现 RAG 系统 把企业的私有文档（合同、知识库、产品手册）接入 LLM，让模型能基于公司特有的知识回答问题。核心挑战不是”让 AI 开口说话”，而是让它说的话准确可信。

构建 AI Agent 工作流 把 LLM 变成一个能调用工具、执行多步骤任务的自动化系统。比如”分析这个季度的销售数据，找出异常，生成报告，发给相关负责人”——这是 AI Agent 要干的事，不是一次简单的 API 调用。

Prompt 工程和优化 Prompt 不是随便写几句话。结构化的 Prompt 设计、Few-shot 示例的筛选、思维链（CoT）的构造——这些决定了 LLM 输出质量的上限。

LLM 应用的评估和迭代 如何判断 RAG 系统做得好不好？不能靠感觉。需要建立评估框架（Ragas、ARES），量化召回率、精确率、答案相关性，形成”测量 → 分析 → 优化”的闭环。

与产品团队协作定义 AI 功能 AI Engineer 是 LLM 能力和产品需求之间的桥梁。需要判断”这个需求适不适合用 LLM 解决”，然后用工程的方式把它实现出来。

1.3 为什么这个岗位正在爆发

几个数字：

• 2023 年底 ChatGPT 引爆之后，全球 AI Engineer 相关职位在 2024 年增长了约 3-4 倍
• LinkedIn 2024 年最热门职位榜单，AI Engineer 首次进入前 10
• 国内，2024 年下半年开始，大厂、AI 独角兽的”AI 应用工程师”岗位从几十个扩张到数百个
• 供给侧：会训练模型的 ML Engineer 培养周期长（需要 PhD 或大量科研积累）；AI Engineer 的门槛相对低，但市场已经开始有需求

更重要的结构性原因：大模型的能力开始够用了。2023 年之前，很多企业在观望；2024 年开始，大量企业真实落地 AI 应用，需要有人把 API 变成产品功能。这个人就是 AI Engineer。

二、国内外岗位全景

2.1 国内市场

一线大厂

阿里、字节、腾讯、百度、华为都有大量”AI 应用工程师”岗位，岗位名称可能是：

• AI 应用开发工程师
• 大模型应用工程师
• LLM 产品工程师
• 智能对话系统工程师

大厂的特点：稳定、资源充足、平台价值高，但内部流程复杂，技术决策链条长，想快速落地一个完整的 AI 应用有一定难度。

AI 独角兽

月之暗面（Moonshot/Kimi）、智谱 AI（Zhipu）、百川智能（Baichuan）、MiniMax、深度求索（DeepSeek）——这些公司的 AI 应用工程师岗位技术含量高，成长快，但稳定性相对低，需要承受高强度。

这类公司目前是 AI Engineer 最值钱的背景之一，因为他们真正在生产环境处理最复杂的 LLM 应用问题。

传统企业 AI 化

银行、保险、制造业正在大规模推进”AI 赋能”项目。这里有大量”智能客服”、“知识库问答”、“合规审查辅助”等项目需求。

优点：项目稳定，业务场景清晰；缺点：技术栈相对滞后，进化速度慢。适合不想承受初创公司压力、但想积累 AI 应用落地经验的人。

2025 年薪资参考（北京/上海，仅供参考）

2.2 国外市场

顶级 AI 公司

Anthropic、OpenAI、Cohere 的 AI Engineer 岗位竞争极为激烈，但薪资也极高（美国湾区，Total Compensation 常见 30-60 万美元）。他们要的是真正有深度项目经验的人，不是”会调 API”的人。

FAANG 的 AI 产品团队

谷歌（Gemini 应用团队）、Meta（Llama 应用团队）、亚马逊（AWS AI 服务团队）都在大规模扩张 AI 应用工程师。这类岗位会着重考察系统设计能力和大规模工程实践。

AI 原生初创公司

硅谷的 AI 原生创业公司（Cursor、Perplexity、Harvey、Glean 等）通常 4-20 人的工程团队，做的事情非常聚焦，对 AI Engineer 的综合能力要求极高，但增长空间和期权价值可观。

三、核心技能地图

mindmap
  root((AI Engineer 技能))
    必须掌握
      Python
        数据处理 pandas
        异步编程 asyncio
        API 调用与封装
      LLM API
        OpenAI SDK 参数精通
        Anthropic Claude SDK
        理解 temperature/top_p
        理解 token 计费
      RAG 基础
        文本分块策略
        Embedding 模型选型
        向量数据库 CRUD
        检索策略设计
      Prompt Engineering
        系统提示词设计
        Few-shot 示例筛选
        思维链 CoT
        结构化输出 JSON Mode
      AI 框架选一个
        LangChain 生态
        LlamaIndex 文档处理
        LangGraph 工作流
    加分项
      LLMOps
        LangFuse 监控
        成本追踪与优化
        A_B 测试框架
      AI Agent
        LangGraph 状态机
        CrewAI 多智能体
        工具调用设计
      本地模型
        Ollama 部署
        vLLM 推理服务
      向量数据库深度
        HNSW 索引原理
        混合搜索 BM25+向量
        Milvus / Qdrant 运维
      MCP 开发
        MCP Server 开发
        数据工具集成
      Fine-tuning
        LoRA 概念与实践
        QLoRA 内存优化
    不需要
      深度学习理论
        反向传播推导
        优化器数学
      CUDA 编程
      分布式训练
        DeepSpeed
        Megatron-LM
      模型架构设计

3.1 必须掌握的（非谈判项）

Python：不解释。如果 Python 还不熟，先停下来把它搞定，其他什么都不用看。

LLM API 调用：不是”会调”，是”精通参数含义”。temperature 控制什么、max_tokens 怎么估、top_p 和 temperature 同时调会怎样——这些是面试必考项。

RAG 基础：

• 文本怎么切块（chunk）？切多大？重叠多少？
• Embedding 模型怎么选？text-embedding-3-small 和 text-embedding-ada-002 有什么区别？
• 向量数据库怎么选（Chroma/Qdrant/Milvus）？
• 检索出来的结果怎么排序（Reranker 的作用）？

Prompt Engineering：

• Few-shot：给模型几个例子，让它学会输出格式
• CoT（Chain-of-Thought）：让模型”先想再答”，减少错误
• 结构化输出：让 LLM 输出 JSON，方便程序解析
• 系统提示词的角色设计：怎么让模型”扮演”一个专业角色

AI 框架（选一个精通）：

• LangChain：生态最大，资料最多，适合快速开始
• LlamaIndex：文档处理和 RAG 场景的专业工具，API 设计更清晰
• LangGraph：Agent 工作流的首选，基于图的状态管理，稳定性好

选哪个都行，但面试时要能说清楚”为什么选它，它的核心设计思想是什么”。详见 AI Agent框架选型指南。

3.2 加分项（差异化竞争）

LLMOps：生产环境中的 LLM 应用需要监控、成本追踪、版本管理。LangFuse 是目前最流行的开源 LLMOps 工具，会用它等于告诉面试官”我考虑过生产环境的问题”。详见 LLMOps体系全景。

AI Agent 开发：LangGraph 的状态机设计、CrewAI 的多智能体协作——这两个是 2025 年 Agent 开发的主流选择。Agent 的核心挑战是”防止 AI 做错事”，能把这个讲清楚是加分项。详见 AI Agent框架选型指南。

MCP 协议开发：Model Context Protocol 是 2024 年底 Anthropic 发布的工具调用标准，正在成为 AI 应用集成数据工具的新范式。开发过 MCP Server 并开源，目前竞争对手极少。详见 MCP学习路线图。

向量数据库深度：不只是会调 API，要理解 HNSW 索引原理、混合搜索（BM25 + 向量搜索）的 alpha 参数调优、大规模场景下的分片策略。这是区分”会用”和”懂”的关键。

3.3 不需要的（省精力）

• 深度学习理论：你不需要推导反向传播，不需要理解优化器的数学，不需要知道 Transformer 每一层的计算细节
• CUDA 编程：GPU 内核优化是 ML System 工程师的工作
• 分布式训练：DeepSpeed、Megatron-LM——那是训练大模型的团队需要的，不是你

把时间从这些地方省下来，用在 RAG 调优和 Agent 设计上，投资回报率高 10 倍。

四、简历写法

4.1 项目描述模板

AI Engineer 的简历项目描述要遵循一个原则：有数字，有技术选型，有挑战。下面是 STAR 格式的 AI 版本：

## 企业内部知识问答系统（RAG 架构）

背景：公司内部有 5 万份合规文档，业务人员每天花 2-3 小时手动检索，
      传统关键词搜索召回率低（约 40%），答非所问情况频发。

方案：基于 LangGraph + Qdrant + Claude API 构建混合检索问答系统。
      核心设计：
      - 文档分层切块（按段落 + 固定窗口，overlap=20%）
      - 混合搜索（BM25 权重 0.3 + 向量搜索权重 0.7）
      - Reranker 二次排序（bge-reranker-v2-m3）
      - LangFuse 追踪每次查询的延迟和成本

数据：检索召回率从 40% 提升到 87%，答案相关性评分（RAGAS）0.82，
      平均响应时间 2.1 秒，每次查询成本控制在 $0.003 以内。

规模：覆盖 5 万份文档（约 2.3 亿 tokens），服务 300 名业务用户，
      日均查询量 1500 次。

## 数据分析 AI Agent（LangGraph 实现）

背景：数据团队每周需手动生成 12 份例行报告，每份耗时 1-2 小时，
      高度重复，且难以快速响应临时分析需求。

方案：基于 LangGraph 构建 Multi-step 数据分析 Agent。
      核心设计：
      - 工具集：SQL 查询、Python 数据处理、图表生成、报告模板渲染
      - 安全护栏：只读 SQL 权限，危险操作（DROP/DELETE）拦截
      - Human-in-the-loop：关键步骤需人工确认后继续执行
      - 错误重试：最多 3 次自动修复，失败后回退并通知人工

数据：例行报告生成时间从 90 分钟缩短至 8 分钟（降低 91%），
      临时分析需求响应时间从 2 天缩短至 30 分钟。

规模：支持 15 类报告模板，处理过最大单次查询 500 万行数据。

4.2 两种背景的人怎么写简历

从数据工程师转型

你的优势是：真正理解数据的质量、血缘、流转——这正是 AI Engineer 经常忽视的薄弱环节。很多 RAG 系统失败，不是因为 Prompt 不好，而是数据本身有问题。

重点强调：

• “设计了数据入库 Pipeline，确保文档质量（去重、格式标准化、元数据提取）”
• “基于数仓架构经验，设计了向量数据库的分区和索引策略”
• 把 ETL 经验转化为”文档处理 Pipeline 设计能力”的表达

不要写：

• “负责离线数仓 ODS/DWD/ADS 层建设”（这是数据工程师的话，不是 AI Engineer 的话）
• 把所有数仓工作堆在前面，把 AI 项目缩在最后一条

从后端工程师转型

你的优势是：系统设计能力、API 集成经验、对高并发和稳定性的理解。

重点强调：

• “设计了 LLM 服务的熔断、限流、降级机制”
• “实现了 RAG 系统的缓存层，将热门查询响应时间从 2.1 秒降至 0.3 秒”
• 把 API 设计能力转化为”LLM 应用工程的系统设计能力”

4.3 不要写的内容

• “熟悉 ChatGPT 的使用”（这不叫技能，这叫会用工具）
• “对大语言模型有浓厚兴趣”（兴趣不等于能力）
• 没有量化数据的项目描述，例如：“效果显著提升，用户反馈良好”
• 技能列表里堆砌工具名称但没有使用深度的描述

五、面试核心题库

5.1 RAG 系统设计类（最高频）

Q1：如何设计一个百万级文档的企业知识问答系统？

这是最经典的 AI Engineer 面试题，回答框架：

第一层：明确需求和约束

• 文档类型（PDF/Word/网页）和总量（百万级）
• 查询类型（精确检索 vs. 语义理解）
• 响应时间要求（实时 vs. 可接受 3-5 秒）
• 成本预算

第二层：核心架构设计

• 文档预处理 Pipeline：解析 → 清洗 → 分块 → Embedding → 入库
• 分块策略：按段落切割 + 固定窗口兜底，overlap 15-20%
• 向量数据库选型：百万级文档用 Qdrant 或 Milvus，不要用 Chroma（单机内存有上限）
• 检索策略：混合搜索（BM25 + 向量），Reranker 二次排序

第三层：质量保证

• 离线评估：构建 QA 测试集，每次迭代跑 RAGAS 评估
• 在线监控：LangFuse 追踪每次查询的召回文档和用户反馈
• 持续优化：定期分析”召回了但没用到的文档”和”用户觉得答案不对”的案例

第四层：扩展性

• 增量更新：新文档实时 Embedding 入库，不需要全量重建
• 权限控制：基于用户角色过滤可检索的文档范围

Q2：RAG 系统的检索效果不好，你会从哪些方向排查？

这道题考察你是否真正做过 RAG 并遇到过问题。分层排查：

第一层：数据质量问题

• 原始文档解析是否准确？（PDF 表格提取、扫描件 OCR 是高频问题）
• 分块是否合理？（块太大导致噪声，块太小导致上下文不足）
• Embedding 模型是否适合当前语言和领域？（通用 Embedding 在专业术语密集的场景效果差）

第二层：检索策略问题

• 只用了向量搜索，没有 BM25？（关键词精确匹配场景纯向量搜索会失效）
• 没有 Reranker？（Top-K 召回的文档排序不一定合理，Reranker 重排序通常有明显提升）
• 查询改写了吗？（用户的原始问题可能比较口语化，改写成更清晰的检索语句效果更好）

第三层：上下文利用问题

• 召回的文档是否真的被 LLM 有效利用？（检索对了，但 LLM 忽略了上下文的情况存在）
• 上下文窗口是否够长？（文档塞太多 LLM 会”忘记”前面的内容）

第四层：问题定义问题

• 这个问题本身适合 RAG 吗？（有些问题需要跨文档推理，RAG 处理不好）

Q3：混合搜索（Hybrid Search）中 alpha 参数怎么调？

混合搜索公式：score = alpha * vector_score + (1-alpha) * bm25_score

• alpha 接近 1：更依赖向量搜索，适合语义相似度高、关键词不明确的场景
• alpha 接近 0：更依赖 BM25，适合精确关键词匹配、专有名词（产品型号、人名）等场景
• 起点建议：alpha=0.7（向量权重略高），然后基于 QA 测试集的 MRR@10 指标调优
• 分场景处理：可以根据 Query 类型动态调整 alpha（检测到专有名词时降低 alpha）

5.2 AI Agent 设计类

Q4：设计一个能分析数据库并生成报告的 AI Agent，如何防止它执行危险操作？

这道题考察 Agent 的安全设计，核心思路是多层防护：

第一层：权限约束

• Agent 使用的数据库账号只有 SELECT 权限，从数据库层面拦截写操作
• 禁止 Agent 直接执行 DDL（DROP、ALTER、TRUNCATE）

第二层：工具设计约束

• SQL 工具函数内置关键词检查：检测到 DROP/DELETE/UPDATE 直接报错拒绝执行
• 限制单次查询的行数上限（防止全表扫描把数据库打挂）

第三层：Human-in-the-loop

• LangGraph 实现：在”执行 SQL 前”节点加入人工确认步骤
• 对于影响面宽的操作（查询超过 100 万行），强制暂停等待确认

第四层：审计日志

• 所有 SQL 语句和执行结果记录到日志，出问题可追溯

Q5：LangGraph 和 CrewAI 你会怎么选，各适合什么场景？

参考 AI Agent框架选型指南 中的详细对比，核心判断：

选 LangGraph 的场景：

• 需要精确控制 Agent 的执行流程（状态机图结构）
• 需要 Human-in-the-loop（LangGraph 原生支持暂停/恢复）
• 生产环境，对稳定性和可观测性要求高
• 单 Agent 复杂工作流

选 CrewAI 的场景：

• 多个 Agent 需要协作分工（角色化设计，每个 Agent 有明确职责）
• 原型验证阶段，快速搭建 Multi-Agent 系统
• 任务之间有依赖关系但流程相对固定

关键区别：LangGraph 是”工程师友好”的，需要自己定义图结构；CrewAI 是”快速上手”的，用声明式方式定义 Agent 角色。

5.3 LLM 应用工程类

Q6：如何控制 LLM 应用的成本，有哪些层次的优化手段？

从成本高到低，分层优化：

Q7：如何评估一个 RAG 系统的效果好不好？

评估分两个维度：

离线评估（RAGAS 框架）：

• Context Precision：召回的上下文中，有多少比例是真正相关的？（精确率）
• Context Recall：真正相关的内容，有多少被召回了？（召回率）
• Answer Relevancy：生成的答案和用户问题有多相关？
• Faithfulness：答案是否忠实于召回的上下文，有没有”幻觉”？

在线评估（生产环境）：

• 用户显式反馈（点赞/点踩）
• 追踪”答案被采用率”（用户是否基于 AI 的回答做了操作）
• 监控”答案被重新查询率”（用户立即重问同一问题，说明上一个答案没解决需求）

5.4 行为面试类

Q8：你做过最难的 AI 应用工程挑战是什么？

回答框架（3-5 分钟版本）：

1. 背景（30 秒）：项目是什么、规模有多大
2. 挑战（1 分钟）：具体遇到了什么技术难题，为什么难
3. 分析过程（1 分钟）：你怎么拆解问题、尝试了哪些方向
4. 解决方案（1 分钟）：最终采用了什么方案，为什么这样选
5. 结果（30 秒）：量化的改进数据

不要说：

• “我们遇到了 LLM 幻觉问题，最终加了一些 Prompt 解决了”（太模糊）
• “整个项目都很难”（没有聚焦在一个具体挑战上）

Q9：如何在 AI 效果（更好的模型）和成本之间做权衡？

这道题考察工程判断力，参考答案框架：

第一步：量化效果差距

• 用 A/B 测试或离线评估，量化更好的模型带来的效果提升（例：RAGAS 从 0.78 提升到 0.86）
• 把效果提升转化为业务价值（用户满意度 +8%，预计减少人工干预 X 次/天）

第二步：量化成本增加

• 估算 Token 消耗，计算每月新增成本
• 考虑延迟增加带来的用户体验影响

第三步：决策

• 如果效果提升带来的业务价值 >> 成本增加：用更好的模型
• 如果成本压力大：探索”路由策略”（简单问题用小模型，复杂问题用大模型）
• 持续监控：定期重新评估，随着模型价格下降，决策可能会变

六、项目作品集建议

AI Engineer 必须有作品，没有作品直接出局。这不是”加分项”，是必要条件。

6.1 三类推荐项目

项目一：企业知识问答系统（最标配）

这个项目是市场需求最大的场景，几乎每家公司都需要，做了就有话说。

技术栈：LangChain 或 LlamaIndex + Qdrant + Claude/GPT-4o API + LangFuse

必须有的功能：

• 混合搜索（BM25 + 向量，不能只有向量）
• Reranker 二次排序
• 对话历史管理（多轮对话）
• LangFuse 监控（展示你考虑过生产环境问题）
• RAGAS 评估结果展示

量化指标必须有，示例：

• 检索召回率：从 XX% 提升到 XX%
• 平均响应时间：XX 秒
• 每次查询成本：$X.XXX

项目二：AI Agent 工作流（差异化）

LangGraph 实现的数据分析 Agent，展示你对 Agent 设计的理解——特别是”防止 AI 做坏事”的设计。

必须展示的设计亮点：

• Human-in-the-loop：某个关键步骤需要人工确认
• 错误处理：Agent 执行失败时的重试和回退逻辑
• 工具设计：SQL 工具有安全约束

项目三：MCP Server 开发并开源（加分项）

为一个数据工具（比如 ClickHouse、Hive、Doris）开发 MCP Server，发布到 GitHub，写好 README。

这个项目目前竞争对手极少，技术门槛适中，但在 AI Engineer 求职中有极高的区分度。参考 MCP学习路线图 快速上手。

6.2 作品集展示要点

GitHub README 要有什么：

• 架构图（Mermaid 或 draw.io，让看的人 5 秒内理解系统结构）
• 效果数据（截图 + 数字，不能只写文字）
• 快速启动命令（docker compose up 一键跑起来，降低评审门槛）
• 技术选型说明（“为什么用 Qdrant 而不是 Chroma？“这个问题在 README 里答掉）

部署在线可访问：

• Hugging Face Spaces（免费，部署 Gradio/Streamlit 应用）
• Railway（免费额度，部署 FastAPI 后端）
• Vercel（前端部署）

面试官能直接点链接访问你的作品，和只能看代码，效果天差地别。

七、30天转型路线图

适用于有数据工程或后端工程背景、想快速进入 AI Engineer 赛道的人。

7.1 Week 1 精选资源

• OpenAI Cookbook（github.com/openai/openai-cookbook）：官方示例，代码直接能跑
• LlamaIndex 官方文档（docs.llamaindex.ai）：RAG 场景最系统的文档
• Simon Willison 的博客（simonwillison.net）：AI 应用工程实践的最佳个人博客

7.2 Week 2 精选资源

• LangGraph Academy（academy.langchain.com）：LangGraph 官方免费课程，有代码练习
• LangGraph GitHub：代码示例比文档更有参考价值
• AI Engineer YouTube 频道（youtube.com/@aiEngineer）：工程实践向内容

7.3 Week 3 精选资源

• RAGAS 文档（docs.ragas.io）：RAG 评估框架，直接接入用
• Qdrant 文档（qdrant.tech/documentation）：混合搜索配置非常清晰
• LangFuse 文档（langfuse.com/docs）：LLMOps 监控，30 分钟上手

7.4 Week 4 投简历技巧

• 目标公司筛选：先从 AI 独角兽和 AI 原生初创公司投，大厂流程慢，可以并行投
• 简历版本：准备两个版本，一个突出”RAG/知识问答”，一个突出”Agent 工作流”，根据 JD 切换
• 内推优先：脉脉上找目标公司的员工，内推通过率是普通投递的 3-5 倍

总结

AI Engineer 这个岗位的本质是：用工程师的方法，把 LLM 的能力转化成实际可用的产品功能。

它不需要你有深度学习背景，不需要你会训练模型，但它需要你：

• 真正跑过完整的 RAG 系统，踩过坑，知道哪里容易出问题
• 能用量化数据说清楚”你做的东西有多好”
• 理解生产环境的约束（成本、延迟、稳定性），不只是在笔记本上跑 Demo

30 天够了。条件是你真的动手做，而不是看完教程觉得自己懂了。

#AI工程师 #求职 #RAG #LLM应用 #LangGraph #职业规划 #AI-Engineer

本文节选自数据从业者全栈知识库。知识库包含 2300+ 篇体系化技术文档，覆盖数据分析、数据工程、数据治理、AI 等全栈领域。了解更多 ->