AI 工程师不是一个岗位：先选方向，再补技能
从应用开发、AI 平台、模型工程到前线交付，拆开 AI 工程师的四条路线，也说清零经验者该怎么做出求职证据。
“AI 工程师”这个职位名称，已经装下了几种完全不同的工作。
有人负责把模型接进产品，有人负责搭模型网关和推理平台，有人做训练与微调，还有人直接去客户现场，把一个演示版本变成能跑在业务流程里的系统。
这些岗位都可能写着 AI Engineer，但准备方式并不相同。一个人可以熟悉 RAG，却不懂 GPU 推理；也可以会 PyTorch，却不擅长把客户的模糊需求变成可交付的软件。
所以，零经验转向 AI 工程，第一步不是把所有课程都收藏一遍，而是先决定：你要进入哪一类工作。
先看岗位到底在招什么
公开的 AI 工程岗位数据给出了一个很实用的参照。 GitHub 上的 AI Engineering Field Guide 汇总了 4,894 份来自多个城市的 AI 工程岗位描述，并把岗位、技能、面试和学习路径拆开整理。
仓库当前的 README 把 AI 工程拆成几类内容：AI 应用、平台与基础设施、传统机器学习、前线交付、面试准备和作品集。仓库没有提供统一的开源许可证文件，因此不适合直接把它称作“某某许可证项目”；它更像一份持续更新的研究资料库。
从这些岗位描述里，可以先得到一个判断：公司要的通常不是“只会调用模型的人”，而是能把模型、数据、代码、部署和业务流程接起来的人。
这也是为什么 Python 、 SQL 、 API 、 Docker 、云平台、日志、评估和成本控制，会和 RAG 、 Agent 、 Prompt 一起出现在招聘要求里。
四条路线，准备重点不一样
1. AI 应用工程师：把模型做成能用的产品
这是最适合有软件开发基础的人切入的路线。
日常工作可能包括：
- 把模型 API 接进已有产品；
- 做企业知识库问答和 RAG；
- 设计工具调用、结构化输出和多轮状态；
- 处理流式响应、超时、重试和降级；
- 让结果能被用户理解、修改和继续使用。
RAG 的难点不在于“把文档向量化”这一步，而在于检索结果是否真的回答了问题。文档切分错了，检索就可能拿到目录而不是条款；元数据缺失，系统就分不清合同、部门和时间；没有评估集，改完之后也不知道质量到底变好了还是变差了。
这一方向的学习顺序可以很朴素：
- Python 、 HTTP 、 JSON 、数据库和异步基础；
- 一个模型 API 的调用、流式输出和结构化结果；
- 文档解析、切分、向量检索、过滤和重排；
- 评估集、错误分析、日志和成本统计；
- 用 FastAPI 或其他后端框架做成一个可运行服务。
不要先把时间花在“换哪个 Agent 框架”上。先做一个能回答真实问题、能展示引用、能记录失败案例的小系统。
2. AI 平台工程师：让团队用得起、管得住
这条路线经常被忽略，但很多公司真正缺的是这一层。
当三支团队各自接了四家模型服务，没人知道费用属于哪个部门；当主模型在下午出现波动，系统需要切换备用模型；当调用量上来后，重试、限流、缓存和日志彼此冲突，应用团队就需要一个统一的平台。
AI 平台工程师会处理：
- 模型网关和路由；
- API Key 、团队和用户的成本归属；
- 配额、限流、缓存和故障转移；
- 模型别名、版本管理和输出格式；
- 监控、追踪、延迟和吞吐；
- Docker 、云平台、 CI/CD 和服务部署。
这条路线更接近后端、平台和 DevOps 。它不等于“必须自己训练大模型”，也不等于“只要学 CUDA 就行”。如果你喜欢系统、成本和稳定性，平台方向可能比追逐最新模型更适合。
3. 模型工程师：训练、微调和推理优化
这是很多学习路线最喜欢写的方向，但岗位数量通常没有宣传中那么大。
模型工程师会做：
- 数据清洗和标注；
- 训练、微调和实验管理；
- PyTorch 、 TensorFlow 或其他训练框架；
- 推理性能和显存优化；
- 评估模型在特定任务上的效果；
- 训练流程和模型上线。
微调也不是默认答案。一个客服分类任务，如果通用模型已经能满足效果，直接调用可能更省时间；只有当任务足够窄、调用量足够大，或者延迟和成本有明确上限时，微调才更值得投入。更麻烦的是，业务分类一旦改变，训练集也要跟着更新，真正的工作常常落在数据标注和质量维护上。
这条路线适合愿意补数学、机器学习、深度学习和工程基础的人。它的准备周期通常比“做一个模型应用”更长，也更依赖具体公司和岗位阶段。
4. 前线交付工程师：把系统放进真实业务
Forward-Deployed Engineer，通常可以理解为前线交付工程师。这个岗位同时要求写代码、理解客户流程和承担部署结果。
工作可能是这样的：客户每天人工处理大量单据，你先花时间理解他们真正的工作方式，再把信息抽取、人工复核和后续系统连接起来。模型即使有 94% 的字段准确率，也可能达不到业务要求，因为剩下的错误会集中落在高风险字段上。
成熟的做法通常不是让模型直接替人做决定，而是：
- 自动提取低风险信息；
- 把低置信度结果送进人工队列；
- 保留原始证据和修改记录；
- 用每单节省多少时间衡量效果；
- 把现场发现的问题反馈给产品和工程团队。
这条路线对沟通能力要求很高，也要求工程师能适应客户的技术栈和数据环境。它适合喜欢解决具体问题、愿意和业务人员一起工作的人，但不太适合只想在封闭开发环境里写代码的人。
评估能力不是第五条路线，而是四条路线的共同门槛
无论做应用、平台、模型还是交付，都需要回答一个问题：系统到底有没有变好。
最小的评估流程可以这样开始：
- 在写代码前，先准备 30 个真实问题；
- 写下什么答案才算合格；
- 运行系统，人工阅读失败记录；
- 把失败按原因分类；
- 只改一个变量，再重新评分；
- 保留前后结果和成本、延迟变化。
很多作品集只展示“页面能打开”“模型回答很流畅”，却没有展示错误样本。对招聘方来说，一个能说明系统为什么失败、改动带来什么变化的人，比只会堆功能的人更容易获得信任。
零经验者怎么做出求职证据
“先学六个月，再去找工作”听起来完整，但容易把学习变成无期限准备。更有效的方式是尽早做出可检查的证据。
第一件事：做一次错误分析
选一个自己能运行的 RAG 或 Agent 系统，收集几十条真实记录，逐条标记错误原因，例如：
- 没检索到相关内容；
- 检索到了，但上下文不完整；
- 模型理解错了问题；
- 工具调用失败；
- 输出格式不符合要求；
- 系统没有把不确定性告诉用户。
然后把分类、样例和修改前后的结果写进项目 README 。这个交付物比“我会 LangChain 、向量数据库和 Prompt Engineering”更有说服力。
第二件事：做一个能跑的完整项目
项目不需要大，但要有完整链路：
- 输入从哪里来；
- 数据怎么处理；
- 模型怎么调用；
- 结果如何验证；
- 失败如何记录；
- 成本和延迟怎么观察；
- 用户如何知道答案来自哪里。
一个小而完整的合同问答、客服分类、内部文档搜索或业务表单抽取项目，都比十个只停留在 Notebook 里的小实验更适合作品集。
第三件事：让方向和背景对上
- 已经有后端、前端或全栈经验：优先考虑 AI 应用工程；
- 喜欢部署、网络、云平台和成本：考虑 AI 平台工程；
- 有数学、机器学习或科研基础：再考虑模型工程；
- 擅长沟通、理解流程并能快速交付：考虑前线交付工程。
如果背景还没有明确优势，也可以从应用工程开始，因为它能最快让你建立代码、模型、数据和产品之间的连接。
一条更实际的学习顺序
可以把前六个月拆成几个阶段，但不要把月份当成保证：
阶段一：补工程基础
Python 、 Git 、终端、 HTTP 、 JSON 、 SQL 、虚拟环境、异常处理，以及一个后端框架。
阶段二：做出模型应用
学会提示词、系统指令、结构化输出、工具调用、流式响应、会话状态、成本和延迟控制。
阶段三：补 RAG 和评估
理解切分、嵌入、向量数据库、元数据过滤、重排、引用、错误分析和评估集。
阶段四：学习 Agent 和工作流
理解 Agent 循环、工具选择、状态管理、重试，以及哪些任务根本不该交给 Agent 。
阶段五：部署和可靠性
Docker 、后台任务、队列、认证、日志、可观测性、版本管理、缓存、限流和费用监控。
每个阶段都应该产出一个可展示的结果，而不是只增加收藏夹里的链接。
资料入口
完整的岗位数据、学习路径、面试问题和作品集建议，可以查看 GitHub 上的 AI Engineering Field Guide：
https://github.com/alexeygrigorev/ai-engineering-field-guide
这份资料适合用来校准方向，不适合当作就业承诺。它分析的是岗位描述，岗位描述不等于真实招聘结果，也不能代表所有国家、公司和岗位类型。
AI 工程的入门门槛正在从“会不会调用一个模型”转向“能不能让系统稳定完成一件事”。先选一个方向，做出一个能运行、能评估、能解释失败原因的项目，再继续扩大技能范围，通常比把所有方向都学一遍更有效。