过去一年，AI 工程几乎成了技术圈最热门的能力标签之一。
但一个很现实的问题是：
大多数初学者，并不知道自己到底该学什么。
有人从机器学习理论开始，结果学了很久，依旧不会做产品；
有人沉迷教程视频，看了几十小时，真正动手却无从下手；
还有人一上来就研究 Prompt、Agent、RAG，结果连 API、后端、部署这些基本能力都没打牢。
最后的结果通常都差不多：
概念懂了不少，项目做不出来，离“能真正上手做事”还差得很远。
问题不在于你不够努力，而在于学习顺序错了。
如果你的目标是成为一名 AI Engineer，你其实不需要先成为研究员，也不需要先把所有机器学习理论都啃完。
更重要的是先学会一件事：
如何把现成的大模型能力，变成现实世界里可用的系统和产品。
这，才是今天绝大多数 AI 工程师真正的工作内容。
AI 工程师，真正做的到底是什么？
很多人一提到 AI 工程师，脑海里想到的是：
- 训练大模型
- 调参
- 跑论文
- 搭建底层训练系统
但现实是，今天企业里的大量 AI 工程岗位，做的其实是更偏工程落地的事情，比如：
- 接入 OpenAI、Anthropic、Google 等模型 API
- 设计 Prompt 与上下文管理策略
- 做聊天、搜索、自动化、知识库类应用
- 把数据库、工具、业务系统接进 AI 工作流
- 让模型输出稳定的结构化结果
- 优化成本、延迟、可靠性
- 把 AI 能力真正部署进产品
换句话说，AI 工程师其实站在几个交叉点上：
- 软件工程
- 后端工程
- 产品工程
- 自动化工程
- 应用型 AI
所以这篇文章不讲“怎么从零训练大模型”，而是给你一条面向工程落地的 6 个月路线图。
先说结论：AI 工程的核心，不是“懂 AI”，而是“能把 AI 做出来”
如果你想走 AI 工程这条路，真正要学会的，不是“人工智能的一切”，而是下面这几件关键的事：
- 用 Python 和 API 做端到端应用
- 会写 Prompt，但不迷信 Prompt
- 能把模型输出变成结构化结果
- 会做 Tool Calling
- 理解 RAG，而不是只会抄教程
- 知道什么时候该用 Workflow，什么时候该用 Agent
- 会评估、会部署、会监控、会控成本
- 能把 demo 变成产品
如果你 6 个月里真的把这些东西走完，并且每个月都做出实际项目，那你距离“可被雇佣”会比大多数初学者近很多。
整体路线图
这 6 个月，我建议按下面的节奏来：
- 第 1 个月：打软件工程基础
- 第 2 个月：掌握 LLM 应用开发
- 第 3 个月：真正学会 RAG
- 第 4 个月：理解 Agent、Workflow 与评估
- 第 5 个月：学会部署、可靠性与成本控制
- 第 6 个月：选一个方向深挖，并把自己变成“可被购买”的人
第 1 个月：打地基，不要一上来就冲 Agent
很多人学 AI 工程，最大的误区就是：
一开始就想做很“炫”的东西。
今天做个智能体，明天接个工具调用，后天又想做企业知识库。
结果是：看起来一直在追前沿，实际上连 Python、HTTP、Git、API 都没打牢。
所以第一个月只有一个目标：
把自己变成一个能写代码、能调接口、能跑服务的 Python 开发者。
你要掌握什么？
1. Python
至少做到：
- 能写函数
- 能处理 JSON
- 能做文件读写
- 能写简单类
- 能做错误处理
- 能管理依赖和虚拟环境
你不需要一开始就成为高级 Python 工程师，但你必须先摆脱“连基础语法都要边写边搜”的状态。
2. Git 与 GitHub
从第一天开始，把你做的每一个项目都放进 GitHub。
这不是形式主义，而是在做两件事：
- 养成工程习惯
- 积累公开作品集
3. 终端与命令行
你后面会一直和命令行打交道：
- 跑脚本
- 装依赖
- 配环境变量
- 启服务
- 管文件
如果你对终端不熟，后面会不断被小问题卡住。
4. HTTP / API / JSON / async
你第 2 个月就要开始调 LLM API。
所以在那之前，你必须先搞清楚：
- GET 和 POST 是什么
- JSON 是怎么传的
- API key 怎么工作
- 状态码是什么意思
async/await为什么存在
5. SQL 与 Pandas
AI 工程不是数据科学，但你会非常频繁地：
- 查表
- 过滤数据
- 读 CSV
- 做简单清洗
基础 SQL 和 Pandas，会在后面频繁帮你省时间。
6. FastAPI
这是后面几乎一切“把 AI 能力做成服务”的起点。
你至少要会：
- 写 GET/POST 接口
- 定义请求体
- 本地运行服务
- 用
/docs调试
这个月要做什么项目？
不要只学不做。
第一个月，至少完成一个能运行的项目，比如：
- 一个天气查询 CLI
- 一个个人记账工具
- 一个简单的 FastAPI 服务
- 一个调用公共 API 并返回 JSON 的小工具
要求很简单：
它必须是你亲手做出来，并且可以运行的。
第 1 个月结束时，你应该具备这些能力
- 能独立写 Python 小程序
- 能调用 Web API
- 能用 Git 做版本管理
- 能在终端里比较熟练地工作
- 能写并跑起来一个简单的 FastAPI 服务
第 2 个月：真正进入 LLM 应用开发
如果说第 1 个月是在打软件工程底盘，
那第 2 个月，就是你第一次真正开始“做 AI”。
但这里的“做 AI”，不是训练模型，而是：
学会用现成模型 API，构建稳定、可控、可接入业务的应用。
这一阶段的核心能力有 8 个。
1. Prompt 设计：先追求稳定，再追求花哨
Prompt 不是“怎么把话说得更高级”，而是：
怎么给模型一套更稳定的约束，让它更大概率按你想要的方式输出。
你要重点理解：
- system 和 user message 的分工
- 为什么具体比模糊更重要
- few-shot 的作用
- Chain of Thought 什么时候有效，什么时候反而添乱
最好的练习方式，不是看别人总结了多少提示词技巧，
而是围绕一个任务自己写多个版本，然后对比输出差异。
2. 结构化输出：这比“聊得像人”更重要
真实业务里，很多时候你不想要一段自然语言回答。
你想要的是：
- 一个 JSON
- 一个字段齐全的对象
- 一个可以直接被后端接住的结果
所以你要尽快学会：
- 用 Pydantic 定义结构
- 用 schema 约束模型输出
- 处理字段缺失、类型错误、拒答等情况
这是从“会玩模型”到“会做产品”的关键分水岭。
3. Tool Calling：从“会说”走向“会做”
Tool Calling 是 LLM 应用里最关键的一层能力之一。
它的意义在于：
- 模型不只是生成文本
- 它还可以决定什么时候去调用外部能力
比如：
- 查天气
- 做计算
- 查数据库
- 调你自己的内部接口
这一步一旦打通，你会发现很多“像智能体的能力”，其实本质上都建立在这里。
4. Streaming：用户体验提升最大的基础能力之一
很多初学者会忽略 Streaming，
但它几乎是所有用户可感知体验里最划算的一项优化。
因为从用户角度看：
- 一次性等 10 秒很难受
- 看到内容一点点吐出来，会觉得系统“正在工作”
只要是用户可见的 AI 产品，Streaming 基本都值得做。
5. 会话状态：别把“模型有记忆”当成默认能力
LLM 本身是无状态的。
所谓“它记住了我前面说过的话”，其实只是因为你把历史消息一起传回去了。
所以你必须自己理解并设计：
- 如何维护 messages 列表
- 什么时候截断历史
- 什么时候做摘要
- 怎么控制上下文成本
这件事会在第 3、4、5 个月持续反复出现。
6. Token、延迟与成本：越早理解越省钱
很多 AI 应用不是做不出来，而是：
- 做出来太慢
- 做出来太贵
- 一上量就烧钱
所以从第 2 个月开始，你就要建立成本意识：
- 什么是 token
- 输入输出如何计费
- 小模型什么时候够用
- 大模型什么时候真有必要
今天做 AI 工程，没有成本思维，很难真的做好上线系统。
7. 失败处理：生产系统不能只看 happy path
你必须默认模型 API 会失败。
你会遇到：
- 429 限流
- 请求超时
- JSON 不合法
- 工具调用失败
- 模型输出不符合预期
你能不能优雅地兜底，决定了你的东西是 demo，还是产品。
8. Prompt Injection：别等上线后才第一次听说
Prompt Injection 不是安全专家才需要关心的事。
只要你做的是 LLM 应用，这就是必修课。
至少要建立几个基本原则：
- 不要把不可信输入直接和系统指令揉在一起
- 不要给工具过大的权限
- 不要让模型未经校验的输出直接自动执行关键动作
这个月建议完成的项目
至少做一个像样的 LLM 应用，例如：
- 一个稳定输出 JSON 的文本抽取器
- 一个能调用多个工具的 AI 助手
- 一个支持流式输出的聊天接口
- 一个终端里的多轮对话机器人
做到这一步，你已经不是“只会聊 Prompt 的人”了。
第 3 个月：别只会说 RAG，要真的会做 RAG
RAG 是今天最常见、也是最容易被“学歪”的 AI 工程技能之一。
很多人以为自己会 RAG，
其实只是把教程跑通过一遍：
- 读文档
- 切 chunk
- 存向量
- 查 top-k
- 拼进 Prompt
这只能算“跑通示例”，还远远不算“理解 RAG”。
真正的 RAG 工程能力，重点在于下面几个层面。
1. Embedding：理解“为什么能搜到”
你要真正理解 embedding 的直觉：
- 文本被映射到向量空间
- 语义相近的内容距离更近
- 相似度检索的基础就是这个空间结构
如果这一层没搞清楚，后面的很多调优都会停留在“玄学试参”。
2. Chunking：很多 RAG 问题，根源都出在这里
RAG 做不好，很多时候不是模型不行，而是 chunk 切得很差。
你需要理解：
- chunk 太大，检索精度差
- chunk 太小，上下文不够
- overlap 为什么必要
- Markdown / 结构化文档为什么适合递归切块
- 语义切块什么时候有价值
很多教程最爱跳过这一层，但这恰恰是检索质量的核心。
3. 向量数据库：先会用，再研究底层
不要一开始就陷进各种索引算法对比。
对初学者来说，更重要的是先把这些事情做会：
- 存进去
- 查出来
- 带 metadata
- 能过滤
- 能支撑基本问答
你可以先从 Chroma 开始，够轻、够快、够适合本地原型。
4. Metadata Filtering：从 demo 到生产的关键一步
真实业务里，用户不只会问：
“这个问题的答案是什么？”
他们还会问：
- 只看某个时间段的报告
- 只看某个部门的文档
- 只看某个来源
- 只看某个用户范围内的数据
如果你的 RAG 没有 metadata filtering，它大概率只能当 demo。
5. Reranking：把“差不多”变成“更相关”
两阶段检索是非常实用的生产模式：
- 第一阶段快速检索候选
- 第二阶段对候选进行重排
这个动作的收益通常很高，特别是在文档量变大以后。
6. 学会 debug retrieval，而不是只怪模型
RAG 出错时，先别急着说“模型幻觉了”。
你应该先问几个问题：
- 正确 chunk 有没有被召回
- chunk 切分是否导致信息断裂
- top-k 是否太小
- metadata 是否丢失
- query 是否需要重写
一旦你开始按这个思路排查，你才算真正跨进了 RAG 工程。
这个月必须完成的项目
做一个真正能展示给别人的：
Chat with your docs
要求至少包括：
- 文档导入
- chunking
- embeddings
- 向量存储
- metadata
- reranking
- 带引用回答
- FastAPI 接口
这个项目非常适合放进作品集，因为它天然贴近真实企业场景。
第 4 个月：理解 Agent，但不要被 Agent 绑架
这一阶段最重要的，不是“赶紧做个 Agent”，而是：
搞清楚 Agent 到底是什么，以及什么时候根本不该用它。
很多人一提 Agent，就默认它是“高级形态”。
其实不是。
Agent 只是某一类问题下的一种工程方案。
它不是默认最优解，更不是“越多越高级”。
1. 先理解 Agent Loop 本质
Agent 本质上就是一个循环：
- 看当前状态
- 决定下一步
- 调工具执行
- 观察结果
- 再决定下一步
你把这个逻辑想清楚之后，会发现很多框架只是把这个 while loop 封装了。
2. Workflow 和 Agent，不是一回事
一个特别重要的判断标准是：
- 如果步骤固定，就用 workflow
- 如果步骤不固定，且确实需要动态决策，再考虑 agent
这是工程判断力，不是概念判断力。
很多场景其实根本不需要 agent。
一个固定 3 步的 pipeline，通常更快、更便宜、更好 debug。
3. 工具设计、状态管理、失败恢复，比“会不会调框架”更重要
Agent 难的地方，不在于把框架跑起来，
而在于：
- 工具定义是否清晰
- 状态如何传递
- 工具调用失败后怎么恢复
- 如何避免无限循环
- 什么时候该中断、重试、回退
这些东西才决定 agent 能不能用于真实任务。
4. 没有 eval 的 Agent，基本等于不可维护
Agent 天生复杂：
模型、工具、检索、状态、分支逻辑，任何一个地方都可能出错。
所以你必须建立评估能力：
- golden set
- regression tests
- LLM-as-judge
- process metrics
- outcome metrics
不做 eval，后面每一次 Prompt 改动、模型切换、工具调整，几乎都在赌。
这个月建议完成的项目
二选一即可：
方案 A：从零写一个 Agent Loop
- 不用框架
- 给它 3 个工具
- 让它自己迭代执行
- 加最大轮数限制和失败处理
方案 B：做一个固定 Workflow
例如：
- 提取文章事实
- 并行生成摘要、微博、LinkedIn 文案
- 让模型打分并选出最佳版本
这两类项目都很有价值。
关键不是“名字像不像智能体”，而是你是否真正理解了结构。
第 5 个月：把 demo 变成产品
这是最容易被低估的一个月，
也是企业最在乎的一个月。
因为大量人都能做出 demo，
但真正稀缺的是：
能把它上线、跑稳、控成本、出问题能查的人。
这一阶段你要系统学会 7 件事
1. FastAPI 的生产化配置
不是本地 uvicorn --reload 跑通就结束了，而是：
- worker 配置
- health check
- middleware
- 异步资源管理
2. Docker
你必须学会把服务打成容器，因为这是今天最基础的交付方式之一。
3. 后台任务 / 队列
文档处理、批量抽取、长流程执行，不该堵在主请求链路里。
4. 鉴权与 API 安全
没有鉴权的 AI API，就是在邀请别人替你花钱。
5. 日志与可观测性
特别是 LLM 调用链路的 tracing。
请求 200 不代表产品没问题，模型可能照样胡说八道。
6. Prompt 版本管理
Prompt 一旦进生产，它就是配置资产，必须可追踪、可回滚。
7. 缓存与成本控制
在真实流量下，缓存往往是最直接的降本增效手段。
这个月建议完成的项目
把你第 3 个月或第 4 个月最好的项目，真正做一次“产品化改造”：
- Docker 化
- 增加鉴权
- 增加日志
- 增加错误处理
- 增加缓存
- 增加成本监控
- 增加 Prompt 版本管理
做到这里，你和“会做 demo 的人”之间，就已经开始拉开差距了。
第 6 个月：选一个方向，把自己变成“可被购买”的人
学到第 6 个月，最怕的不是“学得不够多”，
而是“什么都懂一点，什么都拿不出手”。
所以你一定要开始做定位。
我更建议把 AI 工程大致拆成 3 个方向。
方向一：AI Product Engineer
适合想去产品型团队、创业公司、做 AI 功能落地的人。
关键词
- LLM 应用
- RAG
- Agent
- FastAPI
- Deployment
- 产品体验
你要做什么
做出 2–3 个别人真的能试用的项目，例如：
- Chat with your docs
- AI 内部工具
- 自动化助手
- 内容生成产品
要求是：
- 真正能运行
- 有 GitHub 仓库
- 最好有在线体验地址
- 有清晰 README
- 有项目截图或 Demo 视频
方向二：Applied ML / LLM Engineer
适合想走更深技术路线的人。
关键词
- Fine-tuning
- LoRA / QLoRA
- 开源模型
- 推理优化
- 评估体系
这一方向最重要的判断
先问自己一个问题：
你到底需要改模型，还是只需要改你和模型说话的方式？
一个很实用的决策顺序是：
- 先做 Prompt Engineering
- 不够，再加 RAG
- 还不够，再考虑 Fine-tuning
不要一上来就把“调模型”当成默认答案。
方向三：AI Automation Engineer
适合想快速为企业创造业务价值的人。
关键词
- 工作流自动化
- CRM / Email / Docs / Support
- 多工具集成
- Human-in-the-loop
- 可审计流程
你要做什么
重点去做那些企业愿意直接付钱的自动化场景，例如：
- 线索打分
- 邮件分类与回复
- 文档处理
- 客服自动化
- CRM 工作流集成
这是最接近“立刻能变现”的方向之一。
学到最后，最重要的不是“学了多少”，而是“做了什么”
说实话，6 个月不会把你变成资深 AI 工程师。
但如果你真的把上面这些东西做过一遍、做出项目、做过部署、做过评估，那么你已经比大多数只停留在“学概念”的人强很多了。
真正决定你能不能拿到机会的，不是“你学了多少”，而是：
- 你做了几个项目
- 这些项目能不能跑
- 能不能上线
- 有没有 GitHub
- 你有没有把自己的学习过程公开出来
所以最后给你一句最重要的话：
不要等“准备好了”才开始做项目。
你永远不会感觉自己完全准备好了。
真正拉开差距的，是从“我在学”切到“我在做”。
给初学者的 4 条建议
1. 每个月至少做一个能跑的项目
不要只读，不要只看教程，必须做出可以运行的成果。
2. 所有项目都放到 GitHub
这既是作品集，也是你成长的证据。
3. 每学完一块就写一篇总结
发掘金、发公众号、发 X、发 LinkedIn 都可以。
输出，是最好的倒逼学习方式。
4. 尽早接触真实场景
哪怕只是给自己做个知识库，给朋友公司做个小自动化，也比只做教程强得多。
最后的结论
AI 工程这条路，不是“谁知道的概念更多”，而是“谁能把东西真正做出来”。
6 个月足够让你完成一次从零到入门实战的跃迁。
前提是你别只收藏路线图，而是真的开始：
- 写代码
- 做项目
- 修 bug
- 部署上线
- 公开输出
- 持续迭代
因为市场最终奖励的，从来不是“学得最全的人”，
而是能交付结果的人。
