这几年我经常被人问到同一个问题：想转做AI工程，但不知道从哪下手，网上的东西太散，看着看着就放弃了。我自己的经验也是这样过来的，所以看到“ai-engineering-from-scratch”这个项目名时，第一反应就是：终于有人愿意把这条路老老实实铺出来了。它不是一个读一遍就懂的理论教程，而是一条从零开始、每一步都有可执行材料的AI工程学习路径，覆盖编程基础、机器学习原理、数据处理、模型训练、部署上线这些环节。这篇文章我想结合自己踩过的坑和实际带项目的经验，把这条路径拆开讲清楚，适合正在入门AI工程、或者已经学了一段时间但总感觉“差点工程味”的人参考。

1. 为什么选“从零开始”这条路线

1.1 AI工程与AI算法不是一回事

很多初学者容易把“AI工程师”理解成“会训练模型的人”，但真到工作中会发现，训练模型只是其中一小块。AI工程更讲究的是：怎么把数据变成可用的训练集、怎么保证训练过程可复现、怎么把模型打包成服务、怎么监控线上效果、出了问题怎么快速定位。这些能力在学校课程里很少系统讲过，而“ai-engineering-from-scratch”这个标题之所以吸引我，就是因为它强调的是“工程”，不是“算法”。我在带新人的时候经常说一句话：算法是子弹，工程是枪膛，数据是火药。光有子弹打不响，光有枪膛也发射不出去。

从零开始的意义，不是让你重造轮子，而是让你把每个环节都亲手走一遍。比如数据清洗，很多人觉得直接用pandas跑两行代码就完事了，但真实脏数据里藏着各种编码问题、缺失策略选择、时间戳不一致，这些只有自己处理过才知道坑在哪。同理，模型部署也不只是用FastAPI包一层接口那么简单，中间还涉及版本管理、并发控制、特征对齐、日志监控。这些细节，只有从零开始搭建一个完整项目时才会暴露出来。

1.2 从零开始路线解决了什么痛点

市面上大多数教程要么太偏理论，从头推导数学公式，学完还是不会动手；要么太偏调包，直接告诉你“调用这个API就行”，换个数据就翻车。从零开始的路线补的正是中间那段：理解原理能让你知道为什么这么写，动手实践能让你知道写出来有可能出什么问题。路线里通常会拆成几个里程碑，每个里程碑都有一个可运行的项目产出，比如第一个项目是一个简单的线性回归房价预测，第二个是图像分类，第三个是端到端的对话系统或推荐系统。这样学下来，你简历上至少有2到3个拿得出手的完整项目。

适合参考这条路线的人，我总结下来有三类：第一类是计算机背景但没做过AI项目的学生，第二类是从其他方向转行、已经会写代码但不懂机器学习的人，第三类是已经在做数据分析或后端开发、想往AI方向靠的从业者。如果是纯零编程基础，建议先把Python语法和基础数据结构过一遍，再进入这条路线，效果会好很多。

2. 学习路线的整体设计与阶段拆解

2.1 阶段一：编程基础与Python工具链

AI工程的核心语言目前依然是Python，这没有什么好争论的。第一阶段主要解决三件事：语言熟练度、数据处理能力、代码工程习惯。语言熟练度不是指你会写for循环，而是能熟练操作字典推导式、列表切片、生成器、装饰器这些常用特性。数据处理能力特指NumPy和Pandas，NumPy要理解数组的广播机制、向量化运算，Pandas要熟悉DataFrame的筛选、分组、合并、透视表。代码工程习惯包括使用Git做版本管理、用虚拟环境隔离依赖、写清晰的函数而不是一坨脚本。

我见过太多人跳过这个阶段直接上深度学习框架，结果后面补得极其痛苦。一个很典型的场景：你要做数据增强，需要对一批图像做随机裁剪、旋转、归一化，如果NumPy的索引切片和广播机制不熟，你会发现代码写得又慢又绕。再比如训练数据的分组统计，如果你不熟悉groupby和apply的原理，很容易写出一层层循环，性能差得离谱。这一阶段建议用两周到一个月的时间，每天刷一到两个小练习，重点把Pandas的链式操作练熟。

2.2 阶段二：机器学习与深度学习核心原理

第二阶段进入算法原理，但要把握一个尺度：不追求手推所有公式，但核心概念必须理解透彻。需要掌握的内容包括回归和分类的基本框架、损失函数与梯度下降、过拟合与正则化、交叉验证、混淆矩阵与评价指标。这些是通用基础，不管之后做CV还是NLP都用得上。深度学习部分至少要把反向传播的直觉搞明白——损失函数的变化是怎么通过链式法则一层层传回去的，学习率为什么设置不当会导致震荡或收敛过慢。

我推荐的做法是每个算法都动手用纯NumPy写一遍简单的版本，再切换到Sklearn或PyTorch。比如手写一个只有一层的逻辑回归，你才能真正理解训练循环里epoch、batch、learning rate这些词对应的是什么。Sklearn上线快，适合快速验证思路；PyTorch灵活，适合做复杂模型和自定义训练逻辑。在这一阶段，至少要把逻辑回归、决策树/随机森林、简单CNN、简单RNN或Transformer的mini版亲手训练起来。不用追求SOTA，但一定要能解释清楚“模型在做什么、为什么效果好或不好”。

2.3 阶段三：工程化能力：数据、训练、部署

到第三阶段，学的重点明显开始往“工程”倾斜。首先是数据工程，要会写数据采集脚本、处理数据漂移、做数据版本管理，简单的做法可以是给数据集打上带时间戳的版本标签，或者用DVC工具管理大文件。然后是训练流程工程化，包括训练脚本的参数化、配置文件的组织、日志记录、模型检查点保存、早停策略。最后是部署与上线，要懂如何把模型导出为ONNX或TorchScript，如何在FastAPI里加载模型并提供REST接口，如何做简单的容器化部署，如何监控推理服务的延迟和吞吐。

这一阶段最值得花时间的点在于“打通全链路”：从原始数据到最终API响应，中间经过清洗、特征工程、训练、评估、打包、部署，每一步都不能断。你可以在本地用一个小数据集跑通这条链路，哪怕业务场景很简单，也比只会在notebook里堆代码强得多。因为notebook里的代码通常没有考虑输入校验、异常处理、批量推理的稳定性，这些都是工程化要解决的问题。

2.4 阶段四：完整项目实战

前面三个阶段是点，第四阶段是线。找一个真实场景，比如电商评论情感分析或二手房价预测，从数据采集开始做，一直做到部署成一个可以访问的API服务。项目要满足几个标准：数据源是真实可获取的，数据量至少几万条，存在明显的脏数据问题，评估指标要跟业务目标挂钩，部署要有一定并发需求而不是一个空壳。

做完一个完整项目之后，你自然就会理解为什么很多大佬强调基线模型先行。我记得第一次做完整项目时，直接上手用了很复杂的模型，结果数据预处理出了问题，模型效果差得离谱，后来花了两天排查才发现是特征归一化前后不一致。如果先跑一个简单的线性模型，就能快速暴露数据层面的问题。所以完整项目实战的核心目标不是“把准确率刷到98%”，而是让你对AI项目的生命周期产生肌肉记忆，知道什么时候该做什么事。

3. 实操过程与关键环节实现

3.1 环境搭建与依赖管理

从零开始的第一步是先搭一个干净的环境，这里我强烈建议用Miniconda加虚拟环境，不要直接在全局Python里装包。原因很简单，AI项目的依赖多且版本敏感，直接装全局很容易出现某个库升级后另一些库不兼容的情况。关于conda的安装步骤这里不再赘述，注意一点：Miniconda比Anaconda轻量很多，我们只需要conda这个包管理器。

环境建好之后，用requirements.txt或environment.yml固定依赖版本。我的推荐做法是分两个文件：一个requirements-base.txt存放基础库，另一个requirements-dev.txt存放开发调试用的库。比如前者放numpy、pandas、scikit-learn、torch，后者放jupyterlab、pytest、ruff、pre-commit。训练代码用常规.py脚本，notebook只用来做探索性分析和可视化，这样能保证主线代码是可执行的、可测试的。

3.2 数据准备与特征工程示例

我用一个电商评论情感分析的小例子来串一遍数据准备。假设原始数据是从某个公开平台爬下来的评论文本、评分、时间戳。第一步先做数据探查，用pandas的info和describe看缺失情况，用value_counts看标签分布。第二步做清洗，包括去除HTML标签、统一大小写、处理重复评论，评分在这里可以作为弱标签辅助训练。第三步做特征工程，对于情感分析这类文本任务，常用特征是TF-IDF向量或预训练词向量；如果是结构化数据，则要做缺失值填充、类别编码、数值列归一化。

特征工程里一个非常容易忽略的点是训练集和测试集的特征一致性。我在做项目时就踩过这个坑：训练时用了特征A的归一化参数，但在推理时忘了对测试数据套用同一套参数，导致模型输出完全不对。正确做法是把所有特征处理逻辑封装成一个类或函数，在训练时fit，在推理时只做transform。比如用Sklearn的Pipeline可以很优雅地解决这个问题：

from sklearn.pipeline import Pipeline from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.linear_model import LogisticRegression from sklearn.model_selection import train_test_split pipe = Pipeline([ ("tfidf", TfidfVectorizer(max_features=5000, ngram_range=(1, 2))), ("clf", LogisticRegression(max_iter=1000)) ]) X_train, X_test, y_train, y_test = train_test_split( df["comment_text"], df["label"], test_size=0.2, random_state=42 ) pipe.fit(X_train, y_train) score = pipe.score(X_test, y_test)

你会发现当用Pipeline把向量化和模型串在一起时，训练和推理阶段只需要调用fit和predict，特征转换流程被固定在同一个对象里，不会出现不一致的问题。后续如果想换SVM或什么模型，只需要替换管道的最后一步。

3.3 模型训练与实验记录

训练环节最容易出现的毛病是“乱试一气，没有记录”。我建议从零开始就养成记录实验的习惯，哪怕只是用一个Excel表或Markdown文档，也需要把每次实验的数据集版本、特征方案、模型、超参数、评估指标、运行时长记录下来。进阶可以用MLflow或W&B，但一开始没必要上太重的工具，核心是建立“实验可回溯”的意识。

一个典型PyTorch训练脚本关键部分长这样：

import torch import torch.nn as nn from torch.utils.data import DataLoader, Dataset class TextDataset(Dataset): def __init__(self, texts, labels, tokenizer, max_len=128): self.texts = texts self.labels = labels self.tokenizer = tokenizer self.max_len = max_len def __len__(self): return len(self.texts) def __getitem__(self, idx): enc = self.tokenizer( self.texts[idx], truncation=True, padding="max_length", max_length=self.max_len, return_tensors="pt" ) return { "input_ids": enc["input_ids"].squeeze(0), "attention_mask": enc["attention_mask"].squeeze(0), "label": torch.tensor(self.labels[idx], dtype=torch.long) }

写训练循环时，model.train()和model.eval()的切换要警惕。很多人会在评估阶段忘记model.eval()，导致dropout层还在生效，结果验证集指标忽高忽低。另外，每一个epoch结束后要保存checkpoint，后缀带上epoch和val_score，比如best_model_epoch_3_val_0.876.pt，这样即使训练中途崩了，也不用从头再来。

关于优化器，Adam是默认选择，但学习率设置非常敏感。我的经验是batch size 32到64时，学习率从2e-5到5e-5开始试，BETT（BERT类）预训练模型调参时尤其要注意小学习率。如果你用的是自定义网络，可以先用一个简单的网格搜索试几个数量级[1e-4, 1e-3, 1e-2]，找到合适的区间再细调。

3.4 部署上线与监控反馈

把模型部署成API服务，我最早用的是Flask，后来换成FastAPI，原因就是FastAPI自带请求参数校验和自动文档，性能也更好。一个最简的推理服务脚本大概长这样：

from fastapi import FastAPI from pydantic import BaseModel import torch import joblib app = FastAPI() model = joblib.load("./models/sentiment_model.joblib") class PredictRequest(BaseModel): text: str @app.post("/predict") def predict(req: PredictRequest): pred = model.predict([req.text])[0] prob = model.predict_proba([req.text])[0].tolist() return {"label": int(pred), "probability": prob}

这里有个细节：不要把模型的加载写在接口函数里面。每次请求都重新加载模型的话，GPU显存很有可能会被撑爆，更重要的是推理速度会慢几个数量级。正确做法是在模块加载阶段就把模型load进内存，这样后续的请求都复用同一个实例。另外，生产环境一定要做batch推理，也就是把多个请求凑成一个batch一起过模型，而不是一条一条跑，尤其是在GPU上，batch的吞吐量提升非常明显。

部署之后监控也是工程的一环。最基础要记录三个指标：请求量、推理延迟、模型返回的置信度分布。当线上数据分布跟训练集不一致时，置信度往往会有明显变化，这是一个信号。如果不想上Prometheus那套复杂的监控体系，至少要在日志里把每次预测的输入输出和耗时打出来，出问题时能回溯。

4. 常见问题与排查技巧实录

4.1 训练loss不下降怎么办

这是初学者最常遇到的问题。排查顺序我建议是这样的：先看数据，是不是标签有错、样本顺序有没有被shuffle、类别是否极不平衡。再看模型，是不是最后一层激活函数和损失函数不匹配，比如二分类用了softmax却配了BCELoss。接着看优化器，学习率是不是太高导致震荡，或者太低导致几乎不动。最后看训练循环，backward之前有没有清零梯度、梯度有没有被clip。

我印象很深的一次是训练一个文本分类模型，loss一开始就在2.3附近不动，查了半天发现是tokenizer把文本全部转成了同一个字符。原因是数据里有一部分行读取时编码出问题，变成了统一的替换字符，模型当然学不出名堂。所以遇到loss不降，先随机抽几条训练样本打印出来，肉眼看看数据是不是正常的，这一步能省掉很多瞎猜的时间。

4.2 GPU显存不足

显存不足分几种情况。第一种是模型本身太大，这时可以调小batch size，或者用混合精度训练。PyTorch里开启混合精度很简单：

from torch.cuda.amp import autocast, GradScaler scaler = GradScaler() with autocast(): outputs = model(input_ids) loss = criterion(outputs, labels) scaler.scale(loss).backward() scaler.step(optimizer) scaler.update()

第二种是数据加载时积累了太多中间变量，比如在循环里不断拼接tensor，却没有把旧的移到CPU或者释放，这时可以用del和torch.cuda.empty_cache()辅助清理。第三种是显存碎片化，通常出现在反复创建不同形状张量的场景，可以把计算图里不必要的中间结果detach掉，或者调整数据加载的collate方式，让同一个batch内的张量shape尽量一致。

4.3 过拟合与欠拟合的判断和处理

判断过拟合看训练集和验证集的差距就能知道：训练集指标接近满分而验证集明显差，基本就是过拟合。从零开始做项目时，很多人一上来就用很大的预训练模型，数据量才几千条，没过两个epoch就开始过拟合。防过拟合最有效的手段依次是：增加数据量、做数据增强、降低模型复杂度、加大正则化、增加dropout、加早停。从零开始的新手反而要警惕另外一种情况：数据量足够但模型太简单，训练集和验证集都上不去，这就是欠拟合，这时候该做的不是加正则，而是换更多参数的模型。

我还想分享一个很容易被忽略的点：随机种子。如果你固定了所有超参数但每次运行结果都不同，说明没有设置随机种子。训练前把random.seed、numpy.random.seed、torch.manual_seed都设置好，GPU场景还要设置torch.cuda.manual_seed_all，这样结果才能复现，排查问题时也不会被随机性误导。

4.4 部署阶段模型体积过大和延迟高

模型体积大的问题，主流解法是蒸馏、量化、剪枝，但对于从零起步的人来说，先别急着上这些高级手段，先确认一下模型是否真的需要那么复杂。我用过一个文本模型，在只比简单TF-IDF+LR好一个百分点的情况下，推理延迟却高了30倍，最后在业务场景里果断换回了轻量方案。如果确实需要深度模型，可以先做半精度导出或者量化到int8，PyTorch官方已经有比较成熟的量化工具，能把模型体积压缩到四分之一左右。

延迟高的另一个常见坑是输入数据预处理拖了后腿。比如每次请求都对原始文本重新做全量预处理，频繁调用正则和分词，这部分消耗甚至比模型推理还大。优化思路是做一个轻量级缓存：对完全相同的输入文本直接返回上一次的结果，或者把预处理结果缓存起来。如果延时要求很高，还可以考虑用ONNX Runtime替代PyTorch的Eager模式，推理速度通常有1.5到3倍的提升。

5. 学习资源与工具选型建议

5.1 值得从头跟练的项目参考

“ai-engineering-from-scratch”本身就很适合作为一条主线，但如果还想补充更多实践，我建议按难度选几个经典案例跟练。简单级别是泰坦尼克号生存预测或房价回归，这些数据干净、任务简单，适合练Pipeline和交叉验证。中等级别是图像分类类，比如CIFAR-10，需要自己写数据加载器、做归一化、设置学习率衰减，能很好地理解卷积网络的训练节奏。进阶级别是端到端的推荐系统或问答系统，这时候要考虑数据稀疏性、冷启动、离线评估和在线AB测试，工程味更浓。

我个人不太建议一开始就跑去刷Kaggle比赛，比赛里的数据处理和特征工程通常非常复杂，不适合建立基本框架。等你自己能从头做出两三个项目后，再去参加比赛才会更有收获。

5.2 该用什么工具以及为什么

工具选型的原则是“优先使用主流且简单的方案”，不要被新框架带跑。语言层面用Python；环境管理用Miniconda；版本管理用Git；数据处理用Pandas和NumPy；模型实验用Scikit-learn加PyTorch；部署用FastAPI加Docker；有日志和实验追踪需求再上MLflow。这些工具组合已经经过大量项目验证，足够覆盖从零到上线全流程。我自己在早期纠结过是否要用TensorFlow还是PyTorch，最后选PyTorch的原因主要是调试方便、动态图更适合研究和灵活实验，而且现在工业界的生态也越来越向PyTorch靠拢。

有一点必须提醒：工具是拿来用的，不是拿来崇拜的。不要为了用某个新技术而用某个新技术，比如你的项目很简单，直接写几个Python文件就够了，非要上Kubernetes反而把问题搞复杂。工程能力是“用合适的工具解决对应的问题”，这个判断力需要在实际项目里慢慢磨。

5.3 时间投入与学习节奏规划

如果每天能投入两到三个小时，我建议用三个月来走完前面说的四个阶段。第一个月主攻编程基础和机器学习基础，第二个月深度学习核心和第一个完整小项目，第三个月做复杂项目并部署上线。每周末可以抽出半天做整理和复盘，把本周遇到的bug和解决思路记录下来，这本身就是一份很好的面试素材。不要贪多，一个接一个做，每做完一个项目就迭代一次自己的脚手架代码，后面会越来越快。

根据我的观察，很多人在第三阶段容易卡住，不是学不会，而是“感觉自己什么都会一点，但又很难独立做完整项目”。这其实是正常的，工程能力不像算法题那样有标准答案，它需要被真实的冲突和异常逼着成长。你只要把一个项目从头到尾做完，哪怕粗糙一点，那种“全链路心理”就建立起来了，后面再遇到问题不会再慌张。

写在最后

我刚开始做AI项目的时候，也到处找过“速成路线图”，结果越看越焦虑。后来发现，真正让人踏实的就是回到“从零开始”这件事本身——自己亲手写每一行代码、踩每一个坑、解决每一个诡异的问题。回头看看，“ai-engineering-from-scratch”这个名字其实点破了核心：不要试图在空中盖楼，你的地基是代码能力，是数据处理，是工程习惯，是不断重复的调试循环。

最后再分享一个小技巧：准备一个专门的目录存放你的“踩坑笔记”，每当解决一个有意思的问题，用一两句话记下来，标注当时的错误日志和解决思路。半年后你会感谢自己，因为那些最折磨你的坑，往往正是面试时最能讲好的亮点。