这两年总有人问我同一个问题：“我不是科班出身，现在想学 AI，从零开始到底该怎么走？”一开始我还耐心回一句句讲，后来问的人实在太多，我便把整个思路整理成了一个叫ai-engineering-from-scratch的学习工程。很多人一听这个名字就以为又是一份“三个月速成、半年月薪三万”的鸡汤清单，其实不是。它是一个目标非常明确、按周推进、以落地项目为验收标准的学习路线，面向的是那些真正想成为 AI 工程师、而不是只停留在“会用 ChatGPT 聊天”的读者。

写这篇博文，是把这个项目的核心思路、路线设计、工程环节和踩坑经验一次性讲透。如果你正处于“想转 AI 但不知道从哪下手”的状态，或者已经在学但总觉得学完不会用，那这篇文章就是给你写的。我会尽量把每一步的“为什么”也讲明白，而不是丢一堆资源链接让你自己悟。

1. “从零开始”的真相：AI 工程和 AI 研究、AI 调参不是一回事

开始排路线之前，必须先做一个很多人忽略的区分：你想要的到底是哪种 AI 工程师。这个区分直接决定了你的学习内容，选错了方向，努力全部白费。

1.1 你想要的到底是哪种 AI 工程师

业内常说的“搞 AI”，其实下面至少分成四类人。

• AI 研究员：主要工作是根据论文复现模型、改进模型结构、发 paper。门槛通常是硕博起步，数学和理论要求极高。
• 纯算法/调参工程师：主要职责是训练和微调模型，关注 loss 曲线、数据集质量、超参搜索。工作集中在模型本身，经常和数据团队、标注团队打交道。
• AI 工程师（AI Engineer）：核心职责是把模型变成产品里的一个可用功能。要处理 API 封装、服务部署、请求并发、模型评估、数据回流、成本优化。模型是白的还是黑盒不重要，能用、能稳定、能落地就行。
• AI 产品经理：负责定义“AI 能解决什么用户问题”，不需要写很多代码，但对技术边界要有准确判断。

对于多数转行者、自学者来说，最现实的目标是第三种：AI 工程师。原因很直白：这类岗位的缺口最大，对论文能力要求相对宽松，更看重工程能力，而且边界相对清晰。ai-engineering-from-scratch整个路线的设计预设，也是面向这一目标。

1.2 AI 工程师的技能画像，和你预想的不太一样

我见过不少人以为 AI 工程师的日常是研究神经网络结构，实际恰恰相反。AI 工程师更像个“翻译官”——要把模型的输出翻译成稳定的产品服务。平时打交道最多的往往是这些东西：

Python / FastAPI / 容器化部署 向量数据库 / 检索中间件 API 网关与并发策略 缓存 / 限流 / 降级 日志收集与评估体系 CI/CD 与模型版本管理

这个列表里没有一个涉及数学推导，但每一个都是产品化必需的基础设施能力。很多算法出身的人反而不擅长这部分，这就给了转行者一个非常明确的空间——你不一定非得啃下整本花书才能上车，但你必须把服务化、评测、监控这套工程底子打扎实。

1.3 为什么目标区分对“从零开始”至关重要

“从零开始”最容易犯的错误，就是把无限的知识倒序排列一遍，然后从最难的开始学。《线性代数》《概率论》当然重要，但如果你今天学的每一个公式都感受不到它和“一个能跑起来的 AI 产品”有什么关系，你大概率坚持不过六周。

我们恰恰应该从头想清楚终点：我的目标是让一个 AI 功能上线、稳定、可维护。这个终点倒推回来，就会得到一条完全不同的路线——先搭工程骨架，再补模型知识，最后需要什么数学补什么数学。路线看着反常识，但执行起来保真率高得多。

2. 一条可执行的从零到一路线图：按周推进的三阶段规划

很多人收藏过的学习路线我都见过，基本是“学 Python，学机器学习，学深度学习，学 transformer，然后你会了”。这种路线有个致命问题：太粗了，每一步没有明确的验收标准。学多久？做到什么程度算过？不知道。

ai-engineering-from-scratch把路线收敛成三个可验收的阶段，每个阶段大约八周，全程大概半年。这个节奏既不会快到让人崩溃，也不会慢到让人失去紧迫感。

2.1 第一阶段（第 1-8 周）：编程基础与 Python 数据栈

这是整个路线里最容易“轻视”的阶段，也是后期掉队最集中的阶段。目标只有一个：能用 Python 写清晰的、可维护的工程代码。

• 第 1-3 周：Python 语法基础，重点是数据结构、函数、类与模块化、错误处理。验收项目：写一个命令行工具，能从 CSV 里读取数据并做简单的统计分析输出。
• 第 4-5 周：常用数据栈，Pandas 做表格处理，NumPy 做数值运算，matplotlib 画图。验收标准：给定一份公开数据集，完成清洗、分组统计、可视化三件事。
• 第 6-8 周：工程化基础，Git 管理代码、virtualenv/conda 管理环境、用 requests 调用 HTTP API、了解 Flask 或 FastAPI 写一个最简单的后端接口。

说实话，前几周难免会觉得“这和 AI 有什么关系”，但请务必撑过去。后面所有内容都是建立在这个模型之上的：假设你要端出一个 AI 产品，那它首先是一个 Python 程序，其次才是一个带智能的程序。程序写不干净，智能根本没地方安放。

第一阶段的中期验收项目，建议做一个小工具：把身高体重数据输入进去，输出 BMI 和健康建议。听着幼稚，但它能完整覆盖“读取→处理→计算→结构化输出”这个最小闭环，也是对 Python 工程能力的基本练兵。

2.2 第二阶段（第 9-16 周）：机器学习与深度学习核心

第二阶段开始进入正题，但它同样不是让你从数学教科书第一页学起。核心策略是：先用工具跑通，再回头理解原理。

• 第 9-10 周：机器学习基本概念。用 scikit-learn 跑完线性回归、逻辑回归、决策树。理解训练集测试集划分、过拟合与正则化这些基本概念。
• 第 11-12 周：用 PyTorch 搭建第一个神经网络。建议从手写数字识别（MNIST）入手，理解张量、自动求导、优化器、loss 这几个核心概念。
• 第 13-14 周：卷积神经网络（CNN）与图像分类，跑通一个 CIFAR-10 分类器。
• 第 15-16 周：循环网络与序列模型，用 LSTM 或 GRU 做一个简单的情感分析任务。

很多人问这个阶段为什么不上 Transformers。两个原因：第一，Transformer 类模型训练成本高、依赖大，不适合新手当第一个练手模型；第二，CNN 和 RNN 里学到的训练流程、数据流、过拟合排查方法，到了大模型场景依然适用，只是规模和工具换了。

记得这个阶段最重要的一句话：不要沉迷调参刷分。MNIST 准确率从 99% 刷到 99.1%，对实际工作没有任何意义。真正有意义的产出是——跑完整个流程以后，你能说清楚训练脚本里的每一个模块在做什么，能独立打印 loss 曲线并判断模型有没有收敛，能设计一个简单的验证集来发现过拟合。这种“读懂代码+会排错”的能力才是后续学习的引擎。

2.3 第三阶段（第 17-24 周）：LLM 工程化与应用开发

第三阶段就是大部分自学者最关心的部分：大语言模型的工程化。这个阶段不再培训模型，而是把大模型当作一个能力组件，去构建完整的应用。

• 第 17-18 周：熟悉 Hugging Face Transformers 库，学会用pipeline加载预训练模型，理解 tokenizer、模型输入输出格式。
• 第 19-20 周：Prompt 工程实践，学会写出稳定、结构化的提示词，掌握 few-shot 和思维链的基本用法。
• 第 21-22 周：接入 OpenAI 或开源模型 API，用 FastAPI 包成一个带并发控制、错误重试的对话服务。
• 第 23-24 周：搭建一个最简 RAG（检索增强生成）应用，用向量数据库存文档，检索后交给大模型回答。这个项目做完，你已经走完了 AI 工程方向最完整的一条主链路。

三阶段走完，你会有一个直观的感知转变：AI 工程的大部分时间不是花在“改模型”上，而是花在“让模型的输出变成稳定可靠的服务”上。这种感知越早建立，后面走的弯路越少。

3. 大模型时代，AI 工程新增的技能拼图

传统机器学习时代，“AI 工程师”的核心是模型训练。到了大模型时代，重心明显迁移了：更多人不再训练模型，而是基于大模型做应用构建。这导致技能树发生了一次结构性变化，很多旧路线图都没来得及更新。ai-engineering-from-scratch特意把这一块拆开来讲，因为它很重要，也最容易学偏。

3.1 Prompt 工程是先导技能，但不等于全部

现在网络上有一种声音，把 Prompt 工程吹成 AI 工程师的全部，这是另一个极端。Prompt 工程更像写作中的“表达技巧”——它决定你调用模型的下限，但解决不了系统性的稳定性问题。

真正有效的 Prompt 工程，本质上是在做“需求分析”：

• 明确角色：你是谁，用什么视角回答。
• 明确输入输出格式：尤其需要让模型按照固定 JSON 结构返回，方便下游解析。
• 给出约束条件：哪些不能答、哪些需要引导用户补充信息。
• 提供示例：一个 few-shot 样例，通常胜过一百句抽象描述。

但要注意，Prompt 写得再好，模型仍然可能“偶尔发挥失常”。所以工程上绝对不能只在 Prompt 层面控输出，还要在代码层面加输出校验、重试机制和兜底逻辑。把 Prompt 当作代码来管理——要版本化、要记录效果、要灰度实验——这才是 AI 工程的做法。

3.2 RAG 应用的完整链路，远不止“接个向量库”

RAG 是目前落地最多的大模型应用模式。但很多人以为 RAG 就是“上传文档到向量库，查一下塞给大模型”，实际跑一遍就会发现坑特别多。

一个相对完整的 RAG 链路，至少包含这些环节：

文档加载 → 切分策略 → 向量化 → 向量库存储 用户查询 → 查询改写/意图识别 → 检索召回 → 重排序 → 上下文拼装 → 模型生成

其中最容易翻车的三个点：

• 文档切分：固定长度硬切分经常把语义切断，需要结合段落标题、句子边界做启发式切分。切多短会导致上下文碎片化，切太长会导致检索精度下降。
• 召回质量：单纯用余弦相似度召回很容易召回一堆“字面像但语义无关”的内容。实际工程里要试多种向量化模型，还要组合关键词检索（BM25）做混合召回。
• 重排序：topk 结果放进去之前用一个 rerank 模型重新打分，精度提升往往比你在向量模型上纠结半天更明显。

我在项目里专门留了两周给 RAG，不是因为它复杂，而是因为它是最容易带给你“从零到可上线”完整感的项目。跑通 RAG，你对 AI 工程的链路理解就真正闭环了。

3.3 模型部署与推理优化：成本与速度的平衡

有产品就必然推推理部署问题。开源大模型不是下载下来就能用的，你至少要让模型在 GPU 上稳定跑起来，并且保证响应延迟在可接受范围。

工程上常用的手段：

• 用 vLLM 这类推理框架部署，它通过 PagedAttention 和连续批处理（continuous batching）大幅提升吞吐。
• 做量化：把权重从 FP16 降到 INT8 或 INT4，显存占用直接减少一半以上，速度也会提升。代价是有损精度，需要自己做评估权衡。
• 开流式输出：首字延迟（TTFT）降下来，用户体感明显更好，很适合对话类产品。
• 做并发控制：用队列和信号量限流，避免突增请求把 GPU 显存打爆。

我在项目里经常提醒：不要一开始就追求“最好最快的模型”，先看自己的场景和预算。能调用现成大模型 API 解决的问题，别急着本地部署开源模型——GPU 的资源成本和运维成本，绝对比 API 调用费要更高，这个话题展开讲又是一篇长文。

3.4 评估与可观测性：AI 工程里的“测试”

传统软件工程里，代码写没写对可以用单测断言。大模型应用却有点“薛定谔”——同一段输入，模型可能对也可能错，你没法用传统断言兜底。这就需要一套专门针对 AI 的评测机制。

至少要做到三件事：

• 确定性场景用断言。例如客服问答，预置一批标准问题，规定必须包含哪些关键答案点，用规则匹配来验证。
• 开放场景用 LLM 评分。请一个“裁判模型”对回答打分，评估相关性、忠实度、简洁度。这听着套娃，但在业界已经是标准做法。
• 记录线上日志。把每一次请求的 prompt、上下文、模型输出、用户反馈全部记录下来。这是最宝贵的资产，后续不管做评测还是微调，都要从这些日志里淘数据。

很多做 AI 工程的人不爱做评估，导致上线后模型“偶尔胡言乱语”也没人发现，等用户投诉了才被动处理。如果你能把评估体系当成“AI 应用的 CI”，让每次 Prompt 改动、每个模型版本更新都自动跑一轮评测，那你就已经比市面上大多数团队专业了。

4. 工程落地的关键动作：选型、评估、监控与迭代

学完技术点以后，真正让你和别人拉开差距的，往往是落地动作。ai-engineering-from-scratch最后一段的学习主线，就是带着你走一遍完整的工程落地流程。这段经验其实是从各种真实项目里提炼出来的，非常值钱。

4.1 技术选型原则：别追新，求稳

做 AI 应用，技术选型真的比大多数人想象中保守。新一代模型一出来网上就全是 demo，但生产环境换模型牵扯到的是评测数据、Prompt 兼容、成本审计、风险预案一整套流程，不是拍脑袋就能切。

我的选型建议排序是这样的：

1. 优先选成熟稳定的 API 服务，项目初期能快速验证产品价值。
2. 需要私有化部署时，再选活跃、社区大、文档全的开源模型，维护成本可控。
3. 架构上把模型调用层抽象出来，做一个统一的 adapter 层，这样换模型不需要改业务代码。

这条原则放到向量库、推理框架等等中间件上同样成立：生产环境里“稳定优先”，永远比“极客炫技”更正确。

4.2 离线评估与线上监控：上线之前先定基线

一件非常反直觉的事是：很多团队上线 AI 功能，都是别人说“好用”就上了，完全没有基线概念。等模型出问题，连“比之前是变好了还是变坏了”都无法判断。

正确做法是三步：

• 先建离线评测集。至少准备 100-200 条覆盖典型场景的问题，作为模型效果的“及格线测试”。
• 再跑对比实验。新模型或新 Prompt 上线前，老逻辑先跑一轮测试记录分数，新逻辑跑完对比，分数不降才能放。
• 最后做线上灰度与监控。逐步切流量，观察延迟、错误率、用户投诉率。同时在日志里记录“用户有没有编辑 AI 的回答、有没有重试、有没有否定反馈”，这些是效果变差的早期信号。

4.3 数据闭环：每一次用户反馈都是训练材料

AI 应用和传统应用最大的区别，就是它会越用越有“数据资产”。你说出来的“帮助不大”、你点击的答案、你追问的问题，全都是改善系统的信号。

从第一天就要搭建收集体系：

• 记录答案被“点赞”还是“点踩”。
• 记录用户编辑后的文本，这就是隐式的真实标准答案。
• 定期把高频错误问题整理出来，构成困难样本集，去评测模型、优化 Prompt，甚至考虑做定向微调。

我的经验是，一个 AI 产品上线三个月以后，大部分收益不再来自换更大的模型，而是来自对用户数据的细抠：窄化问题范围、补充背景知识、调整答案结构、修正错误边界。这些功夫，不建立数据闭环的人根本做不了。

5. 实操练习：从“看得懂”到“扛得住”的三个项目

很多人学到第四周就开始焦虑：看教程全懂，一动手全废。这个现象非常正常——看是输入，写是输出，中间的转化需要刻意练习。为了带你完成这一步，我特别设计了三个项目，难度层层递进。每个都要求放在 GitHub 上，当作一个小作品来维护。

5.1 项目一：本地知识库问答助手（RAG 入门）

这个项目是把“文档问答”做完整。可以拿一些小规模的行业资料、公司制度、或个人笔记作为数据源。

• 读取文档，按结构切分成块。
• 用 embedding 模型向量化，存入向量库（比如 Chroma 或 FAISS）。
• 用户提问后，先检索 topk 相关片段，再拼进 prompt。
• 用大模型生成回答，并附上引用来源。

这个项目做完，你会发现它没有你想象中那么“神奇”，但你会懂得把一份文档变得“可被检索、可被引用”，本身就是最大的工程工作量。

5.2 项目二：模型对话服务（API 封装与并发评测）

这个项目不做前端，只做一个规范化的模型调用服务。

• 用 FastAPI 封装统一对话接口，兼容多路模型后端，比如 OpenAI 风格接口和本地 vLLM 接口。
• 实现请求级超时、重试、熔断、限流。
• 构建一份简单评测脚本：用 50 条问题跑一轮，自动统计正确率与延迟。

做完以后你会对生产环境下的“稳定性焦虑”有真实体感：模型偶尔超时、偶尔返回乱码、偶尔拒绝回答，你要想办法让系统整体依然可用。这种场景，不写代码的人是永远感受不到的。

5.3 项目三：端到端 AIOps 助手（Agent 加工具调用）

最后一个项目，是把 Agent 的概念落在实处。做一个具备工具调用（Function Calling）能力的助手，让它能自主完成多步骤任务。

比如做一个“代码仓库周报助手”：

• 工具一：扫描 Git 提交记录，统计本周代码变更。
• 工具二：调用大模型生成周报摘要。
• 工具三：把周报写入飞书/钉钉群机器人。

大模型负责拆解任务、决定调用什么工具、解读工具结果、生成最终汇报。你负责定义工具、控权限、容错和审计。这个过程做完，你会发现 Agent 的关键难点不是“聪明”，而是“可控”。怎么限制它不要执行危险操作、怎么让它在工具调用链断掉时优雅降级——比调 Prompt 有意思得多。

这三个项目全部做完，你已经不是在“学 AI 工程”，而是真的在“做 AI 工程”。简历上的项目经验，描述也完全有了实料。

6. 我自己走过的弯路与建议

最后这部分，来自真实走过的弯路，而不是教科书。如果你正在从零开始，这几点能帮你省下大量时间。

6.1 弯路一：试图在数学上“准备完美”

早期我学机器学习，非要先把线代、概率、最优化全部刷完，结果一个月过去了还在矩阵里打转，连一个模型都没跑起来。后来停止补数学，直接从代码入手跑模型，遇到看不懂的公式再去查，效率提升了不止一倍。数学是“用进废退”的，你不做实际任务，根本不知道哪些数学是真正需要的——做 AI 工程的人员，绝大多数场景用不到偏微分方程。

6.2 弯路二：过度关注模型，忽略工程

很长一段时间，我刷完一堆模型论文，觉得这才是“硬核”。直到第一次把一个 demo 给朋友用，才发现它在并发 5 个请求的状态下直接卡死，一个显存变量的小错让我排查了三天。从那时候起我彻底转变：模型能力固然重要，但工程稳定性才是产品真正的生命线。没有工程兜底，再强大的模型也只是实验室里的漂亮花瓶。

6.3 弯路三：把“会调库”当作“会工程”

用三行代码调用大模型 API，和做一个健壮的对话服务，完全是两个世界。前者是 10 分钟的事，后者可能是一整周的活——要考虑认证、限流、缓存、审计、日志、成本、回退策略。我一直提醒自己：越是看起来“一行代码搞定”的能力，越要严肃对待它背后的工程边界。只有你真的把服务放在生产环境被流量锤几轮，才会理解“稳定”两个字的分量。

最后分享一个小技巧：学 AI 工程，不要拿“学完这个知识点”当里程碑，要拿“做完一个小作品”当里程碑。作品会不断把它推到问题面前，逼你把知识一环一环串起来。ai-engineering-from-scratch这个项目本身也是这样诞生的——它不是一份收藏后吃灰的清单，而是一条真实走通的路径。如果你照着它一步步走完，半年后再回头，你就很清楚 AI 工程到底是怎么回事了。