GitHub 上“ai-engineering-from-scratch”这类项目隔一阵子就冒出一批点进去往往是超长 roadmap线性代数、反向传播、分布式训练、大模型微调、RAG 全链路收藏率极高真正走完的人却寥寥无几。我做过一段时间 AI 工程相关的带教和项目落地也在社区里回答过大量“从零该怎么学”的问题最终发现大家卡住的根源都一样把 AI 工程理解成了纯知识堆积总想“学完所有原理再动手”。其实 AI 工程并不是“多会几个模型”而是一种端到端的交付能力——从业务问题建模、数据处理、模型训练与评估到上线、监控、持续迭代每一步都要靠动手来内化。这篇文章不打算再画一张看不到头的知识地图而是把真正可执行的从零路线拆开讲清楚每个阶段学什么、做什么项目、用什么工具、会遇到什么坑。无论你是后端转 AI、前端想拓展技能栈还是应届生准备入行都可以把这条路当作起点。1. 先想清楚“从零开始”到底要走到哪1.1 别把 AI 工程当成“学一堆模型”很多从零路线烂尾是因为把重心全放在模型和算法上。但真实工作场景里模型训练只是其中一环。行业里常被引用的经验数字是一个 AI 系统从立项到上线数据准备和特征工程往往占掉 50% 到 60% 的精力模型训练和调参占 20% 到 30%剩下全是部署、监控和持续迭代。如果只盯着模型学学完你会发现自己离一个能稳定跑在生产环境里的系统还很远。AI 工程更接近“模型生产化”把一段在 notebook 里能跑通的 Python 代码变成一套稳定、可监控、可回滚、能应对数据变化的软件系统。它同时要求软件工程基本功代码质量、依赖管理、测试、日志和机器学习基本功数据处理、评估、调优两者缺一不可。这一点决定了你的学习路线不能只围绕算法转要围绕“完整项目”转。1.2 from scratch 的两种解读选错的人大多放弃了“from scratch”在 AI 学习社区里有两种截然不同的理解。一种是从底层原理出发手写反向传播、手写 Attention把每个矩阵推导都过一遍。对这个方向我保持尊重但明确建议普通人绕行。它的价值主要在理论研究或框架开发对绝大多数应用型工程师来说性价比极低。你有几个月时间手推公式用 PyTorch 或 HuggingFace 一个晚上就能跑通同样的效果。另一种更贴合工程实践的 from scratch是从“连环境都不会配的小白”成长为“能独立负责 AI 系统交付的工程师”。本文讲的就是这条路。它同样要求理解底层原理但标准是“知道每个环节在做什么、出了问题知道去哪排查”而不是“能徒手实现一遍”。很多人低估了这种“理解深度”认为只有能手写代码才算懂。实际恰恰相反AI 工程的价值在于组合和落地而不在于重复造轮子。1.3 这条路线适合谁不适合谁我梳理的这套路线适合三类背景的人。第一有后端或全栈经验、想往 AI 方向转的开发者你们最大的优势是工程底子好差的只是机器学习知识第二计算机相关专业的学生希望在毕业前建立一套完整的 AI 工程视角而不是只会调包第三已经在用大模型 API 做业务的开发者想往更深水区走一步。不适合的人也有两类。没有任何编程基础、准备从 Python 语法开始学的纯小白建议先花两到三周把 Python 基础补上不必精通但要会写、会调、会查错。还有一类是只对“调大模型接口”感兴趣、不想碰数据和部署的读者你们更适合直接去学业务层的 Prompt 编排和应用逻辑不必走完整条工程路线。判断标准很简单如果提到“数据漂移”“特征一致性”“模型监控”你完全不感兴趣那这条路对你来说太长。2. 地基怎么打工程基础与机器学习核心2.1 Python 工程能力比模型更重要我得说句可能不太好听的话如果 Python 代码本身写得很糟糕AI 工程这条路会走得非常痛苦。实际项目里模型模块往往只占代码库很小一部分大部分时间都在和数据处理、特征脚本、接口服务、配置管理打交道。这些都需要扎实的 Python 工程习惯。具体来说几个关键点必须做到会用虚拟环境做依赖隔离。建议直接学 uv 或 pdm 这类新一代工具比传统 conda 更轻、更快也更适合团队协作写代码习惯加类型标注哪怕只是def foo(x: int) - int的程度。配合 mypy能提前发现大量低级错误会用 pytest 写基础单元测试尤其是对数据处理函数。数据管道是最容易出隐蔽 bug 的地方测试能救命了解 logging 模块而不是到处 print 调试至少能看懂并修改 Dockerfile因为所有部署环境的最终形态都长在容器里。还有一个容易被忽略的点养成固定依赖版本的习惯。requirements.txt里只写包名不写版本号三个月后你会踩大坑。某天重新跑旧项目发现某个传递依赖版本变了结果全线崩溃时间全花在环境排查上。这个教训我在项目里见过太多次。2.2 数学学到什么程度就够用数学是劝退主力军其实应用型工程师需要的数学远没有想象中多。我的建议是线性代数理解矩阵乘法的含义、转置、形状匹配知道张量维度为什么必须对齐就能应对绝大多数场景不需要会手算行列式概率与统计掌握均值、方差、正态分布、条件概率、最大似然的直觉。关键要理解“模型输出的是一个概率分布”这件事微积分重点是导数和链式法则的直觉因为反向传播的核心就是链式法则不需要会各种积分技巧。有一种学习策略叫“用到再补”遇到不理解的概念比如 KL 散度、注意力分数里的缩放因子再去专门查带着问题学效率远高于从头啃教材。3Blue1Brown 的线性代数、神经网络可视化系列是我见过最适合建立数学直觉的资料配合一个小项目同时看效果更好。2.3 机器学习核心要过三道坎在碰深度学习之前先把经典机器学习基础打牢。很多人直接跳到大模型结果连交叉验证和过拟合都说不清楚遇到问题完全无从排查。经典机器学习阶段必须亲手过三道坎。第一道坎用 scikit-learn 完整跑通一个项目。选一个有标签的结构化数据集比如 UCI 的 Adult 收入数据集或客户流失数据做一次完整的分类任务数据清洗、缺失值处理、特征编码、划分训练集和测试集、训练、调参、评估。这个流程走一遍你就对后续所有 AI 项目的基本框架有了手感。第二道坎搞清楚评估指标。准确率、精确率、召回率、F1、AUC、对数损失每个指标回答的是不同问题。比如信用卡欺诈检测正样本极少准确率几乎没意义应该关注召回率信息流推荐更关注排序质量。评估指标的选择永远由业务场景决定这是面试常考、项目常错的地方。第三道坎理解泛化与调参。什么是偏差方差权衡交叉验证为什么能减少评估波动正则化惩罚为什么能缓解过拟合网格搜索和随机搜索的区别在哪。你未必需要掌握贝叶斯优化但必须彻底理解“训练集上表现好不算本事没见过的数据上表现好才算”这个底层逻辑。3. 深度学习和 LLM 工程化从调通模型到上线服务3.1 PyTorch 实战组织训练代码的正确姿势经典机器学习跑通后就进入深度学习阶段。推荐直接用 PyTorch 搭配 HuggingFace 生态这是目前应用最广、资料最全的组合。第一个目标是训练一个自己的图像分类或文本分类模型跑通从 Dataset 到训练循环的完整链路。今天不打算逐个 API 讲解而是提醒几个工程上容易忽略的细节。随机种子要固定。深度学习有大量随机性权重初始化、数据打乱顺序。不固定种子每次训练结果都不一样后面排查问题会非常痛苦。断点续训要尽早支持。模型训练动辄几小时网络断了、机器重启了都要能恢复。训练循环里定时保存 checkpoint至少包含模型权重、优化器状态、当前 epoch 和最优指标。实验记录从第一天就养成习惯。每改一个超参数、每换一个预处理版本都把结果记录到 MLflow 或 Weights Biases 里。不要等项目复杂了再回头补那时候你已经分不清哪个结果对应哪次改动。训练循环尽量用成熟的框架封装比如 PyTorch Lightning 或 HuggingFace Trainer。如果非要用原生代码理解原理最小骨架长这样import torch from torch import nn from torch.utils.data import DataLoader def train_one_epoch(model, loader, optimizer, criterion, device): model.train() total_loss, total 0.0, 0 for x, y in loader: x, y x.to(device), y.to(device) optimizer.zero_grad() logits model(x) loss criterion(logits, y) loss.backward() optimizer.step() total_loss loss.item() * x.size(0) total x.size(0) return total_loss / total model nn.Sequential( nn.Flatten(), nn.Linear(784, 128), nn.ReLU(), nn.Linear(128, 10) ) optimizer torch.optim.Adam(model.parameters(), lr1e-3) criterion nn.CrossEntropyLoss() loader DataLoader(train_dataset, batch_size32, shuffleTrue) for epoch in range(10): train_loss train_one_epoch(model, loader, optimizer, criterion, device) print(fepoch{epoch}, loss{train_loss:.4f})这段代码虽然简单但代表了训练工程的最小骨架。后续加学习率调度、早停、验证评估都是在这个骨架上扩展。3.2 部署不是“调个接口”那么简单模型训练完真正的工程挑战才开始。部署涉及几个核心决策这里给出我常用的方案组合。模型格式方面PyTorch 模型直接加载没问题但生产环境里尤其是推理性能要求高的场景我会先把模型导出成 ONNX 格式。ONNX 的好处是跨框架、跨语言可以脱离 PyTorch 运行时推理再借助 ONNX Runtime 获得明显速度提升。如果要追求极致性能可以继续编译 TensorRT但多数项目用到 ONNX 这一步就够了。服务化框架用 FastAPI当前最主流。一个基础思路是模型在启动时加载一次到内存或显存放在全局变量里接口函数从全局取模型推理避免每次请求都重新加载。最小示例from fastapi import FastAPI from pydantic import BaseModel import torch app FastAPI() class Item(BaseModel): text: str model torch.load(model.pt, map_locationcpu) model.eval() app.post(/predict) def predict(item: Item): tokens tokenize(item.text) with torch.no_grad(): probs model(tokens) return {prob: probs.item()}容器化是必须掌握的环节。Dockerfile 有几个坑要避开基础镜像不要直接用python:3.10而是根据 CUDA 版本选nvidia/cuda:12.x.x-cudnn8-runtime-ubuntu22.04这类匹配镜像COPY 代码之前先装依赖充分利用 Docker 缓存生产镜像别带编译器工具链体积能少一半。服务上线要接监控基础指标至少包括接口延迟、返回码、QPS、GPU 显存占用率。3.3 LLM 应用工程是现阶段最大的增量如果说前面是传统深度学习工程那近年 AI 工程最大的增量在大语言模型应用。这里不要求从零训练大模型那也不是多数公司会做的事。真正重要的是围绕现成基座模型构建应用系统的能力。RAG检索增强生成是落地最多、最容易理解的方向。它的核心逻辑很直白大模型不懂你的私有数据那就先从你的文档库里检索相关内容拼进 Prompt 里再让模型回答。完整链路是文档加载、文本切分、向量化、存到向量数据库、用户提问时做向量相似检索、对结果做重排、注入 Prompt、模型生成答案。几个关键参数直接决定系统质量环节关键决策常见推荐值或方案文本切分chunk_size 与 overlap按语义块切中文资料 300-500 字overlap 约 10%-20%向量化embedding 模型中文场景用 bge 或 text2vec 系列英文可用 sentence-transformer向量库存储与检索小型项目用 FAISS正式项目用 Milvus 或 Qdrant检索召回top_k 设置初始 4-8配合重排再调重排Reranker 模型召回量翻倍后用 Rerank 取 TopK关于 Agent我的态度是别神化。拆开看Agent 就是一个能调用外部工具的循环大模型根据用户需求决定调用哪些工具、按顺序执行、观察结果、再决定下一步。工程难点在状态管理、工具调用格式校验、失败重试和防循环。先用 LangChain 这类框架跑通再把关键环节逐步替换成直接用 HTTP 调底层模型可控性会大幅提升。微调和 RAG 经常被放在一起比较我的取舍建议是知识型问题优先 RAG风格与能力型问题才考虑微调。RAG 能随时更新知识且不需要训练微调能改变模型行为和输出风格但成本高、迭代慢。绝大多数企业内部问答场景先做 RAG 就够了。4. 实操路线一套可以直接照做的 90 天计划4.1 阶段安排与每周目标把前面讲的内容装进时间盒路线就清晰了。下面这份计划基于每天投入 2 到 3 小时、周末全天的情况制定适合上班族和在校生。时间少就拉长到四个月关键是节奏别断别连续停超过三天。阶段时间学习内容产出物第一阶段第 1-4 周Python 工程规范、pandas 数据处理、scikit-learn 经典机器学习完整的结构化数据分类项目第二阶段第 5-8 周深度学习原理、PyTorch、HuggingFace一个图像或文本分类模型的训练与调优第三阶段第 9-12 周模型部署、FastAPI、Docker、LLM 应用开发完整问答机器人或 API 服务第一阶段的关键动作是每天写代码不要只看视频。刷完一个知识点就去 Kaggle 或 UCI 拿一个数据集练习。第一个项目建议做“客户流失预测”有标签、数据量适中、业务理解简单能让你完整走过数据分析、特征工程、模型训练、评估的全流程。第二阶段一定要完成一次训练可视化记录。用 MLflow 把每次实验的 loss 曲线和指标记录下来训练结束复盘一次哪次学习率太高导致发散哪次数据预处理改动让准确率明显提升。这些复盘记录比项目本身更有价值它会帮你建立对模型训练的直觉。第三阶段要逼自己把一个模型真正通过 API 暴露出来、用容器跑通再做一个 RAG 问答系统。这一阶段的目标不是“能跑”是稳定要能回答别人问的“挂了怎么办”这就进入工程师思维了。4.2 三个值得反复打磨的练手项目很多人的问题不是没项目做而是同一个项目草草跑完就换下一个。我建议把三个项目分别打磨到“可以对着面试官讲半小时”的地步。第一个是结构化数据项目比如客户流失预测或房价预测。要能讲清楚如何处理缺失值和异常值、为什么选择某个评估指标、用了哪些特征工程技巧、模型上线后怎么监控。第二个是深度学习项目选文本分类比如情感分析比图像分类更容易向 LLM 方向扩展。走一遍预训练模型加载、微调、评估、部署全流程。这个项目会让你熟悉 HuggingFace 生态后面做 RAG 会非常顺畅。第三个是 LLM 应用项目推荐做一个“个人知识库问答机器人”把几十篇 Markdown 文档或公司内部资料做成 RAG 系统。麻雀虽小五脏俱全涉及文本切分、向量检索、重排、Prompt 设计、系统评估这是当前最贴合招聘市场需求的练手项目。4.3 工具链检查清单给你一张我常用的工具清单按环节划分可以直接照着装环节推荐工具备注环境与依赖uv、pdm比传统 conda 更轻的 Python 管理器代码质量ruff、mypy自动格式化加类型检查数据处理pandas、polars数据量大到内存不够时换 polars实验记录MLflow开源、可自托管、团队可用模型训练PyTorch、Lightning 或 HF Trainer主流组合模型部署FastAPI、ONNX Runtime小项目最快捷方案推理服务vLLMLLM 高吞吐场景容器化Docker、Docker Compose必学监控Prometheus、Grafana延迟和资源监控向量库FAISS、Qdrant从 FAISS 起步就够这张表不是让你每个都精通而是知道每个环节该用什么。当你看到一个陌生 AI 项目时能快速识别它大概用了哪些工具对陌生系统的掌控感会明显提升。5. 踩坑实录训练不收敛、上线变差、RAG 答非所问怎么办5.1 训练 loss 不降的排查顺序我见过太多“loss 没降就怀疑模型写错了”的场面其实按顺序排查多数问题几分钟就能定位。第一步取一小部分数据比如一个 batch过拟合。如果 loss 能降到很低说明模型和代码基本没问题如果不能先去查数据标签是否对上了、预处理是否有 bug。第二步检查学习率。当前主流是 1e-3 到 1e-4 量级Adam 配合学习率调度器能避免后期震荡。第三步检查 loss 函数和数据格式是否匹配比如多分类任务误用了 BCE、logits 没有配合对应损失函数这类问题通常看报错就能定位。第四步检查梯度是否出现 NaN 或梯度爆炸必要时加梯度裁剪。一个强烈建议拿到新任务先跑最小配置验证 pipeline再逐步加东西。很多人一上来就全量数据加数据增强出了问题根本不知道是哪一步引入的。5.2 模型上线后离线指标好、线上效果差这个现象大概是 AI 工程最经典的困境常见原因有三个。第一训练数据和线上数据分布不一致比如用历史数据训练的模型用户行为已经随时间变化。第二训练时的特征工程和线上服务时不一致比如训练时某个特征做了全局归一化线上只按单条样本归一化。第三评估方式有偏差比如离线用随机划分线上是时间序列数据。解决方案首先是特征一致性检查。最笨也最有效的方法是把线上实时处理的特征值和离线特征表的同一 ID 样本做比对看分布是否接近。其次是上线前做 shadow 模式新老模型并行跑、只记录不切换。最后是上线后监控定时任务里比对线上特征分布与训练集特征分布的差异设置漂移告警。5.3 RAG 检索质量差的三个修复点RAG 系统最常见的失败形态是“答非所问”多数情况不是大模型的问题而是检索环节的问题。检修分三个层次。第一检查 chunk 切分。切太碎每个片段缺乏上下文切太大检索噪音多还浪费上下文窗口。中文资料 300-500 字的 chunk、10%-20% 的重叠是比较稳的起点。第二检查 embedding 模型是否匹配你的语言和领域。通用模型对专业术语不友好换成领域微调过的模型比如 bge-large-zh效果可能立竿见影。第三加入重排环节。先召回 20 到 50 条候选再用 Cross-Encoder 重排取 TopK效果比只用向量相似度好非常多。另一个常被忽略的点是混合检索把基于关键词的 BM25 检索和向量检索结合能覆盖专有名词和长尾表达。5.4 环境与依赖的经典坑最后补几个环境问题全是过来人的血泪经验。第一个是 CUDA、驱动和 PyTorch 的版本匹配。装 PyTorch 前先去官网查对应 CUDA 版本不要用默认通道随便装。推荐直接指定版本号pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121第二个经验项目环境全部容器化。宿主机上只留 Docker 和显卡驱动就能摆脱“换一台机器跑不起来”的尴尬。第三个经验依赖冲突时先看报错里的版本要求别直接升级到最新。我见过很多本来能跑的项目因为“顺手升级了一个包”一夜之间全崩。还有一个小技巧在任何项目的 README 里写清楚复现步骤包括 Python 版本、CUDA 版本、关键依赖版本、启动命令。三个月后你会感谢当时的自己。如果让我给一条最朴素的建议不要等学完再动手。把“今天学到一个知识点立刻用最小 Demo 验证它”当铁律。我见过太多人陷在“再学一个月就动手”的循环里一旦真正扎进项目学习效率会高出一个量级。路线是标准化的节奏是自己的。你在跑这条路线时踩过的每一个坑都会成为将来别人问你“AI 工程从零怎么学”时最值钱的回答素材。