这几年被问得最多的一个问题翻来覆去就那么几句AI 工程到底怎么入门要不要先把数学啃完先学 TensorFlow 还是 PyTorch我在回答了几十次、也看过不少人的学习记录之后决定直接写一份 ai-engineering-from-scratch 式的路线梳理——不是又一个链接合集而是把我自己从看教程到能独立上线模型这段过程里真正管用的部分重新剪辑一遍。它面向的是这样的人有点编程基础想进入 AI 方向但不清楚该在哪里花时间也不确定练到什么程度才算会了。这份内容能帮你解决三件事第一把从零开始从一个模糊的口号拆成可执行的阶段第二用最小的工具集从头跑通一个数据到 API 服务的完整闭环第三把那些 demo 阶段发现不了、上线才爆炸的工程问题提前说出来让你少踩几轮。我不太喜欢把这类话题包装成七天精通因为这个领域真实的成长周期是按季度算的但每个季度能走到哪一步完全可以预见。下面就是我反复验证过的走法。1. 先把从零开始拆清楚AI 工程到底在解决什么问题很多人一上来就扎进模型结构、损失函数结果越学越糊涂原因不是不够努力而是没搞明白自己要扮演的角色。AI 工程不是调包也不是发明算法它是一套把数据、模型、代码、系统串起来并持续交付的能力。1.1 别把 AI 工程和算法研究混为一谈同样是跟AI沾边圈子里的分工其实是三类三类的学习路径天差地别算法研究员研究新模型、新机制产出论文和 idea对数学推导要求最高。算法工程师负责把已有模型应用到具体业务比如做推荐、做风控核心是建模和特征工程对数据分析能力要求高。AI 工程师也叫 MLOps 工程师更关注整个系统——数据怎么组织、模型怎么训练和评估、怎么部署成服务、上线后怎么监控。模型本身只是系统里的一个组件。表格看更直观角色核心产出最花时间的部分对工程能力的要求算法研究员论文、新方法数学推导、实验验证中算法工程师业务模型、特征方案数据处理、调参、评估中高AI 工程师稳定运行的模型系统数据管线、部署、监控、迭代高ai-engineering-from-scratch 这套路径瞄准的是第三类顺带覆盖第二类的基本功。你会发现它不要求你发明新模型但要求你能把一个现成的模型——哪怕是最简单的线性模型——稳定、可复现、可维护地跑在真实场景里。能做到这一点的人在今天远比能背出十种注意力机制公式的人稀缺。1.2 一个真实项目的生命周期就是你的学习地图如果只记住一张图我希望是下面这个闭环。它也是后面所有章节的骨架定义问题业务上要解决什么成功标准是什么。数据获取与清洗收集原始数据处理缺失、重复、标签错误。预处理与特征把文本、图像、表格数据变成模型能吃的形式。模型训练与验证选模型、定指标、防过拟合。评估与可复现用科学的方式确认模型真的有效而不是碰运气。部署上线把模型封装成 API 或批处理任务接进业务流程。监控与迭代观察线上数据分布变化定期重训。从零开始的真正含义不是从写神经网络开始而是从问题定义一直推到监控迭代把这七个环节走通一遍。走通一遍之后你再回头看那些模型结构的细节会有完全不同的理解——因为你知道每个设计最终要服务于这个闭环里的哪个位置。2. 路线图上的三个节点基础期、模型期、系统期分别要拿下什么我把整条路径切成三段每段有明确的验收标准。这样做的好处是你不会在某个深坑里无限徘徊因为你知道自己正在哪个节点、下一步该往哪走。2.1 基础期把数学砍到能用为止这个时期的目标是能熟练操作数据而不是成为数学家。编程基础假设你已经有 Python 经验如果完全没有先用两周熟悉变量、函数、类和常用的内置库。数学方面我不建议抱着《统计学习方法》或者《深度学习》从头啃一年再动手。真实工程里你 90% 的时间用到的数学只有三块线性代数理解矩阵乘法是批量计算的写法理解 shape 变换。因为 PyTorch 里所有张量操作本质上就是矩阵运算。概率统计理解分布、期望、方差理解似然和贝叶斯思想的直觉。做评估时要懂准确率、召回率、置信区间这些都在概率框架里。微积分核心是链式法则和梯度。反向传播就是反复用链式法则梯度下降就是沿着负梯度方向更新参数。你不需要手推复杂的积分表达式但要知道 loss 对参数求导这件事在干什么。数据处理工具是这阶段的另一个重点pandas 做表格操作numpy 做数值计算SQL 用来取数。很多新手低估了数据清洗的占比实际上一个正经 AI 项目里数据准备常常占掉 60% 以上的时间。验收标准给你一个包含脏数据的 CSV 文件你能写出脚本完成去重、补缺失值、格式转换、抽样统计并输出一份干净的训练集。能做到这一点基础期就算过了。2.2 模型期先跑通再补原理到了这个阶段你可以开始碰机器学习模型了。我的建议是从 scikit-learn 入手而不是直接上深度学习。为什么因为 scikit-learn 的接口极其统一fit 训练predict 预测score 评估。它能让你在一天内跑通完整的训练评估循环建立模型是个对象的心智模型。你不需要理解梯度下降的内部细节就能先看到结果这会有很强的正反馈。用 scikit-learn 跑熟之后进入深度学习。选 PyTorch 作为主框架逐步掌握数据加载用 Dataset 和 DataLoader 管理训练数据。模型搭建用 nn.Module 定义自己的网络结构。训练循环自己写 for 循环跑 epoch手动调用 optimizer.zero_grad()、loss.backward()、optimizer.step()。评估与保存在验证集上计算指标用 torch.save 保存参数。这个阶段不要贪多。CNN、RNN、Transformer 各跑通一个经典任务图像分类、文本分类就够了。关键是理解训练循环的每个步骤在做什么而不是刷模型动物园。验收标准自己从零写一个包含数据加载、模型定义、训练、评估、保存的完整 PyTorch 脚本并且能用它在一个公开数据集上达到合理指标。这一步是整条路径的分水岭跨过去之后后面基本是工程问题不再是学习问题。2.3 系统期从 demo 到产品的分水岭模型训练出来了只是万里长征第一步。系统期要解决的是你的模型怎么让别人用起来并且一直好用。这个阶段的技能清单包括代码工程化写清晰的模块、类型标注、单元测试、日志。版本管理不只是代码要上 git数据、模型参数、实验配置也要能追溯。部署用 FastAPI 封装预测接口用 Docker 打包环境放到服务器上运行。监控记录线上请求分布、预测结果分布及早发现数据漂移。自动化定时重训、自动评估、告警通知。到这里你才真正称得上 AI 工程师。前两个阶段你是一个会训练模型的人系统期结束你是一个能交付模型系统的人。这两者之间的差距就是我见过的大多数人学了几个月却找不到相关工作的真正原因。3. 工具栈选型少即是多我的原则是跑到部署为止工具选择是新手焦虑的重灾区。今天看到这个框架火了明天看到那个工具出圈收藏夹里躺着十几个教程真正用顺手的没几个。我的建议非常朴素每类工具只挑一个能陪你从小项目跑到上线的其他等有需要再换。3.1 环境与依赖管理Python 环境问题能把人逼疯。我见过有人因为系统 Python 和项目依赖冲突直接在服务器上重装系统。推荐的做法是从第一天就用环境隔离工具。需求我的选择备选方案说明环境隔离miniconda condavenv、uv新手用 conda 最省心一个命令装好 Python 和 CUDA 相关依赖依赖锁定pip freeze 输出 requirements.txtconda env export可复现实验环境的基本保障关于 conda 和 pyenv、uv 的具体选择我的观点是项目一旦开始立刻就把环境锁死。等你在半年后需要重现一个实验结果时会发现当时没记录版本是灾难性的。3.2 训练与实验追踪训练框架选 PyTorch这一点我比较坚持。TensorFlow 的 Keras 接口对新手友好但一旦要深入定制训练循环文档的割裂感会让人很痛苦。PyTorch 的调试体验好太多而且当前开源模型生态几乎都往 PyTorch 靠你以后想加载别人的预训练模型时会省很多时间。实验追踪工具小项目阶段用 MLflow 就够它是开源的自托管方案能记录参数、指标、模型文件还自带一个简单的模型注册表。WB 也很好用但闭源服务对数据敏感的项目有限制。TensorBoard 只适合看训练曲线管不了完整的实验生命周期。3.3 服务化与部署API 层我推荐 FastAPI它自带接口文档参数校验、异步支持都是原生能力对新手极其友好。模型文件管理不要自己造轮子把模型文件当成普通产物命名带上版本号和训练日期存放在固定的目录或对象存储里。推理优化工具比如 ONNX Runtime、TensorRT我建议先不碰。它们的收益是在模型真正上线、遇到性能瓶颈之后去考虑的。一开始就把这些塞进学习路线容易陷入工具学习的泥潭。4. 端到端最小复现从 CSV 数据到能调用的预测服务讲再多原则不如亲手走一遍最小闭环。下面这个项目是我带人入门时最常用的版本一个文本情感分类服务数据是一份 CSV最终产物是一个能调用 HTTP 接口的 Docker 容器。整个过程一个小时左右能走完但该踩的工程坑基本都踩一遍。4.1 第一步准备并检查数据先在项目目录下建一个干净的仓库结构sentiment_service/ ├── data/ │ └── sentiment.csv ├── model/ ├── train.py ├── app.py ├── requirements.txt └── Dockerfile数据文件 data/sentiment.csv 是这个格式text,label 这家餐厅的菜非常好吃下次还会再来。,1 等了一个小时还没上菜体验很差。,0 服务态度很好上菜速度快。,1 菜品不新鲜不会再来了。,0第一件事不是跑模型而是先写一个探数脚本检查行数、缺失值、标签分布。这个习惯能省下后面大量的调试时间。简单验证方式import pandas as pd df pd.read_csv(data/sentiment.csv) print(df.shape) print(df[label].value_counts()) print(df.isnull().sum())如果标签分布差异过大比如正面 990 条、负面 10 条你就得先想清楚是采集阶段的问题还是业务本身就这样。盲目训练一个分布极不平衡的数据集准确率虚高是必然的。4.2 第二步训练一个可保存的模型这个阶段先用 scikit-learn 的 Pipeline 做文本分类因为它把预处理 模型封装成了一个整体训练、预测、保存都非常干净# train.py import pandas as pd from sklearn.feature_extraction.text import CountVectorizer from sklearn.linear_model import LogisticRegression from sklearn.pipeline import Pipeline from sklearn.model_selection import train_test_split from sklearn.metrics import classification_report import joblib df pd.read_csv(data/sentiment.csv).dropna() X_train, X_test, y_train, y_test train_test_split( df[text], df[label], test_size0.2, random_state42, stratifydf[label] ) model Pipeline([ # 中文文本建议配合 jieba 分词自定义 tokenizer这里先用字级 ngram 演示 (vec, CountVectorizer(ngram_range(1, 2), max_features5000)), (clf, LogisticRegression(max_iter1000, random_state42)) ]) model.fit(X_train, y_train) print(classification_report(y_test, model.predict(X_test))) joblib.dump(model, model/sentiment_model.joblib)注意那个random_state42。这行代码的核心作用不是固定一个数字而是让整个数据切分过程可复现。没有它每次跑出来的训练集和测试集都不一样你根本无法判断模型效果变化是来自改动还是来自随机性。这是新手最容易忽略、也最影响判断力的细节。中文文本直接用 CountVectorizer 的默认分词效果不太理想实际项目中一般引入分词器。但为了演示主链路这里不展开你只要知道这个点存在即可。4.3 第三步用 FastAPI 把模型暴露成 API模型训练好之后立刻把它封装成一个服务。服务化的核心思路是模型加载一次之后每个请求都复用同一个内存中的模型对象避免重复读文件带来的延迟。# app.py from fastapi import FastAPI from pydantic import BaseModel import joblib app FastAPI() model joblib.load(model/sentiment_model.joblib) class Item(BaseModel): text: str app.get(/health) def health(): return {status: ok} app.post(/predict) def predict(item: Item): proba model.predict_proba([item.text])[0] pred int(model.predict([item.text])[0]) return { prediction: pred, probability: float(max(proba)), label: positive if pred 1 else negative }这里有两个细节值得说。第一接口里返回predict_proba的概率值而不只是类别因为业务方往往需要置信度来做后续决策比如概率低于 0.6 时转人工。第二本地验证时用uvicorn app:app --reload跑起来然后访问http://127.0.0.1:8000/docs可以直接在浏览器里测试接口FastAPI 会自动生成交互式文档不用自己写 curl 也能验证。4.4 第四步容器化与上线路线本机能调通接口之后下一步是 Docker 打包。容器化的意义是消除环境差异——你在本地能跑换台机器也能跑。一个最小的 DockerfileFROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY app.py . COPY model/ ./model/ EXPOSE 8000 CMD [uvicorn, app:app, --host, 0.0.0.0, --port, 8000]接下来docker build -t sentiment-service . docker run -d -p 8000:8000 sentiment-service curl -X POST http://127.0.0.1:8000/predict \ -H Content-Type: application/json \ -d {text: 这家店味道还不错}到这一步一个最小可用的预测服务就跑通了。它产出的不是 Jupyter Notebook 里的一个跑完就忘的单元格而是可以被业务调用的真实系统。整个链路不复杂但它是后面所有复杂工程的基础形态数据进、模型算、结果出。后面无论加什么——自动重训、AB 测试、监控告警——都是在这个骨架上长出来的肉。5. 决定项目成败的工程细节可复现性、评估陷阱与线上稳定性很多模型在 notebook 里表现得像个天才一到线上就翻车。我自己就见过准确率 95% 的模型上线一周后被业务方投诉预测结果完全不可用。问题不在模型而在工程细节。这章节专门讲三个最容易翻车的地方。5.1 可复现性你的实验结果要能重跑一百遍可复现性不是代码能跑就行而是任何人在任何时候重跑都能得到一致的结果。我见过太多项目过了一个月连作者自己都说不清当时那版好模型是怎么训出来的。要做的事有三件第一固定随机种子。在训练脚本开头统一设置import random import numpy as np import torch def set_seed(seed: int 42): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed)第二锁定环境版本。训练完了立刻执行pip freeze requirements.txt或者如果用的是 conda导出完整环境文件。这能避免半年后复现时被某个依赖大版本升级导致行为变化这种问题恶心到。第三做好实验记录。不用复杂的平台哪怕是一个简单的 CSV 或者 Markdown 表记录每次实验的配置、数据版本、模型参数、关键指标。MLflow 能自动做这件事但我更推荐先手动记几轮——你只有吃过忘记记录的亏才知道自动化的价值。5.2 评估不只是准确率三个例子说明为什么准确率是最直观的指标也是最容易骗人的指标。第一个例子类别不平衡。1000 条样本里 990 条好评、10 条差评模型把所有输入都预测成好评准确率 99%但它什么都做不了。这种场景要看 F1、召回率、混淆矩阵还要关注少数类的表现。第二个例子数据泄漏。在时间序列数据上随机切分训练集和测试集会让模型偷看未来信息测试指标虚高。正确做法是按时间顺序切分只用过去预测未来。数据泄漏是评估环节里最隐蔽、也最致命的坑它会让你的模型在实验室数据上完美、在真实世界里失灵。第三个例子样本量过小。只有 50 条样本时一次随机切分的结果可能完全不代表真实水平。这时可以考虑交叉验证或者干脆把结论的描述改为在小样本上初步看起来有效需要更多数据验证——诚实评估比一个漂亮数字有价值得多。评估的核心不是找到一个最好看的指标而是找到能代表真实业务表现的指标。所以在上线前请回到第 1.2 节那个闭环的第一步确认你的评估方式真的对应着业务目标。5.3 线上稳定性推理速度和兜底策略模型服务上线后的表现跟训练时的预期总会有差距。几个最常见的线上问题推理延迟超时。复杂模型单条预测比较慢线上并发一高就超时。应对思路包括用批量预测代替单条循环、用 ONNX Runtime 做推理加速、适当缩小输入长度或图像尺寸。输入分布和训练分布不一致。用户提交的文本写法、长度、用词习惯和训练集差距很大模型表现自然下滑。你能做的最实用的一件事是提前定义一个低置信度阈值当预测概率落在阈值附近时返回不确定而不是硬给一个答案。没有日志和监控。线上服务必须记录请求分布和响应分布。不需要很复杂把输入文本的长度分布、预测类别的比例变化定时画出来。一旦发现分布偏移就要准备触发重训。这些细节听起来不酷但一个稳定的线上服务靠的就是它们。我始终觉得AI 工程里面最性感的部分不是模型结构而是让模型系统在真实流量下依然可靠的那套机制。6. 回头去看新手最容易掉的五个坑6.1 坑一先花一年啃数学一次模型都没跑过这是最常见、也最可惜的坑。数学是用来理解模型的工具不是用来入门的前置条件。反着学的效果通常更好先跑通一个最简单的模型遇到不理解的部分再回头补数学。带着问题学效率比无目的啃书高好几倍。6.2 坑二环境地狱没处理好热情被消磨光我见过太多人倒在装包这一步。Python 版本冲突、CUDA 装不上、模型数据下不动每个都能卡一个星期。解决方案就是第一时间引入 conda 环境隔离把在干净环境里复现项目当成一个明确的技术目标来练。环境问题处理不了后面寸步难行。6.3 坑三收藏了 100 个教程动手写了不到 3 个脚本收藏等于学会是这个时代的幻觉。看教程的爽感来自觉得懂了但这种懂是脆弱的遇到一个真实报错就散了。从第一周开始哪怕用最笨的方法也要每周至少完成一个小项目清洗一份数据、训练一个模型、写好一个接口。动手量的优先级永远高于阅读量。6.4 坑四追新框架基础没打牢今天 GraphCast 火明天 LoRA 出新版新手最容易产生 FOMO。但实际上工程领域的基础能力——数据清洗、模型评估、服务部署、调试排错——十年内不会过时。任何新框架都是建立在这些地基之上的。把手里的 PyTorch 和 FastAPI 用熟比你眼馋五个新工具更有价值。6.5 坑五只做分析不做产品我用 LSTM 在 notebook 里跑了个 89% 的准确率和我训练了一个模型并部署成 API 供业务实时调用是完全不同的两件事。前者是练习后者是交付。从第一个项目起就强迫自己走完整个闭环哪怕丑一点、慢一点。你会在走完一圈的过程中发现真正难的地方根本不在模型训练而在那些没人写进论文里的工程细节。我个人走到现在最大的体会是AI 工程不是一个知识点而是一套习惯。习惯固定种子、习惯记录实验、习惯写接口文档、习惯上线前评估分布这些习惯叠加起来才构成所谓的工程能力。刚开始会觉得繁琐但等你独立扛过一个线上事故之后就会明白这些繁琐的每一次都在帮你避免更大的麻烦。如果你正在起步挑一个最小的项目今天就从 CSV 数据开始按我上面那个闭环把它推到能调用的 API 为止。完成它你就已经站在大多数停留于教程阶段的人前面了。