从零开始搞 AI 工程这条路我是踩着一堆坑走过来的。当初看各种教程总觉得算法是最大的门槛真正动手才发现环境装不上、数据跑不通、模型部署完没人调用每一项都比想象中麻烦。“ai-engineering-from-scratch”这个标题说的就是完全靠自己的双手不去套用现成的脚手架从理论、环境、数据、模型到部署一层一层把 AI 工程能力搭起来。这篇博文就是我对这条路的完整复盘包含路线设计、实操细节、踩坑记录和可以直接抄作业的方案。如果你正处于“看了很多书但写不出一个能用的服务”的阶段这篇内容应该能帮你省下大量试错时间。1. 为什么我坚持把每个环节都亲手搭一遍1.1 “从零开始”不是重复造轮子而是弄懂轮子为什么能转很多人听到 from scratch第一反应是“这不就是自己造轮子吗”。其实完全不是。我的理解是不借助现成的全栈式 AI 平台或低代码方案而是从底层组件开始一步步组合出属于自己的完整链路。比如训练一个图片分类模型不光要知道model.fit()怎么调还要能自己把数据集准备好、写清楚数据加载逻辑、设计好训练循环、把模型导出、再包一层 HTTP 接口、最后用容器方式部署到服务器上。这条路走一遍你才知道那些封装好的工具到底替你解决掉了哪些脏活累活。这也是为什么我在标题里特意加上 from scratch 的原因。现在网上现成的资源和开源项目太多了随便拉一个下来都能跑但跑通一个 demo 和真正掌握这门技术完全是两回事。自己动手把环境和代码一行行搭起来遇到报错自己看日志解决踩过一遍坑之后你对整个系统的理解深度和单纯用工具的人不在一个层级上。1.2 我的整体路线图四个阶段渐进推进我给自己规划的路线是这样的前后大约花了 8 个月每天保证 3 到 4 个小时的学习和实践时间阶段核心目标时间投入主要产出物理论入门建立对 AI/ML 的基本直觉看懂公式在做什么6~8 周学习笔记、小规模实验脚本工程基础补齐 Python、Linux、Docker、Git 等技能4~6 周标准化的项目目录、环境配置脚本项目实战完成一个完整的数据→训练→部署闭环8~10 周可访问的 API 服务、GitHub 仓库生产化打磨监控、日志、性能优化、CI/CD持续进行稳定的线上服务、复盘文档这条路线没有把算法数学放在最前面是有意的。顺序很关键先跑通一个最小的工程闭环建立正反馈再回头补理论你会发现那些数学公式突然有了落地的场景。一开始就埋头啃数学大概率会在矩阵求导那里劝退。1.3 为什么铺天盖地的教程反而让人越学越焦虑市面上大量教程存在两个问题。第一是拼盘式学习今天看一个 PyTorch 入门明天学一个 Transformers 实战后天刷一道 LeetCode知识点全是零散的组不成系统。第二是过度聚焦模型结构讲一堆注意力机制、各种网络变体但读者连数据加载都没弄明白更别说把模型跑起来、用于生产环境。我后来想明白一个道理AI 工程的能力值应该用“能不能独立交付一个可用系统”来衡量而不是用“记住了多少模型结构”来衡量。所以我干脆把那些教程全部暂停给自己定了铁律——学任何新知识点必须同时写代码验证并且最终都要指向我能把一个服务部署上线这件事。事实证明这条主线思维真的帮了大忙我后来给同事做技术分享时大家反馈最多的就是“原来每一步的衔接是这么处理的终于对上了。”2. 理论部分用最少时间建立最重要的判断力2.1 数学学到什么程度就够了数学是很多人最怕的部分但工程实践需要的数学远没有想象中那么深。我的经验是线性代数必须掌握矩阵乘法和向量空间的基本概念因为这些是深度学习所有运算的底层表达概率统计要懂期望、方差、常见分布和最大似然估计模型训练的本质就是在做概率分布拟合微积分重点理解导数和链式法则这是反向传播的数学基础。举个例子理解批量矩阵运算为什么比循环快你要知道 GPU 并行计算本质上是把大规模矩阵乘法拆成成千上万个小的并行单元。这种层面不需要你会证明什么定理只需要有数学直觉就够了。如果遇到完全不熟悉的公式我经常把它画出来或者写一段小代码验证一下比对着教科书硬啃效率高很多。2.2 机器学习基础先搞懂这些核心机制机器学习部分我把精力集中在下面这些主题上线性回归与逻辑回归理解最简单模型的训练流程包括损失函数、梯度下降、参数更新。决策树与随机森林这是处理表格数据的常青树能理解特征重要性的含义。评估指标准确率、精确率、召回率、F1、AUC 到底在衡量什么什么时候该用哪个。过拟合与正则化什么是欠拟合和过拟合L1/L2 正则化、Dropout 的直观理解。我强烈建议初学者认认真真手写一次线性回归的梯度下降。数据集就用最简单的波士顿房价或者现在常用的替代数据集代码可能只有 50 行但当你看着损失值一点点下降参数一步步收敛到合理范围你就真正理解了 SGD随机梯度下降的运作方式。这个直觉对后续理解深度学习的优化器至关重要。2.3 深度学习必备知识清单深度学习的理论不用贪多我整理了一份“最小可行理论清单”前向传播与反向传播把 2.1 提到的链式法则落到实际网络结构上。常见激活函数ReLU、Sigmoid、Tanh什么时候用哪个原因是什么。优化器演进从 SGD 到 Momentum、Adam各自解决什么问题。学习率与 Batch Size这两个超参几乎决定了训练的稳定性和收敛速度。卷积/循环/注意力三大结构图像、序列、语言三种数据形态的典型建模思路。这个清单大概用 2 到 3 周就能看完配合 PyTorch 动手敲一遍。在这个阶段我强烈建议不要直接套用高层 API比如nn.Sequential很方便但你至少要自己用底层接口拼过一次网络层否则后续遇到自定义损失函数或者特殊结构会完全无从下手。我是在写完一个手写数字识别模型后才真正通透理解了维度匹配是怎么运层到层传递的。3. 工程基础真正卡住你的不是算法是环境3.1 Python 与 Linux这些“非核心技能”决定效率如果用一个词形容我的第一段学习经历那就是“调试地狱”。代码本身逻辑没错但环境装不上、版本冲突、路径不对、权限不足各种奇怪问题能把一个下午耗光。所以后来我把 Python 工程化和 Linux 操作提到很高的优先级。具体来说至少要做到这些熟练创建和管理虚拟环境明白conda和pip混用会带来的问题会用venv或conda创建隔离环境知道requirements.txt和environment.yml的差异和适用场景会基本的 Linux 命令、文件权限、进程查看和日志查看特别是grep、find、ps、kill这些高频操作能写简单的 Shell 脚本完成环境初始化或定时任务。我还养成了一个习惯所有项目都使用固定的目录结构比如project-root/ ├── config/ # 配置文件 ├── data/ # 原始数据与处理脚本 ├── models/ # 模型定义与训练脚本 ├── services/ # API 服务代码 ├── tests/ # 测试 ├── requirements.txt ├── Dockerfile └── README.md这个结构现在成了我的肌肉记忆极大降低了在不同项目之间切换的成本。3.2 为什么 Docker、Git 和数据库必须提前学这三个东西看起来和 AI 没关系但它们是 AI 系统真正“落地”的关键。Git 解决的是版本管理和协作问题你训练模型时不断调整代码有时候改了几个版本的超参数回头发现还是第一次的效果最好有 Git 可以随时回溯不至于靠手动拷贝备份。Docker 解决的是环境一致性我踩过一个教训——本地跑的很好上服务器各种库版本对不上后来统一用 Docker 镜像把 Python 版本、CUDA 版本、依赖库全部固化到镜像里再没有出现过“在我机器上是好的”这种问题。数据库这块最简单的是 SQLite 起步适合小项目做数据存储数据量大了可以考虑 PostgreSQLAI 场景经常需要记录实验参数、指标、样本数据用一张表清晰地管理这些信息比散落一堆 CSV 文件高效得多。我实际的项目里就用 SQLite 存储每次训练的实验记录对着表格分析哪组超参最优比翻训练日志直观太多。3.3 本地 AI 开发环境搭建清单可直接抄这是我反复测试后觉得比较稳定的组合针对不同系统具体细节有差异但整体思路通用操作系统Windows 的话装 WSL2直接在里面做开发比原生 Windows 舒服很多。Python 版本管理用 Miniconda不仅在 Python 版本切换上方便还能把 CUDA 相关依赖装进独立环境。GPU 环境先确认显卡型号和驱动版本再安装匹配的 CUDA Toolkit 和 cuDNN最后用torch.cuda.is_available()验证可用性这一环最容易来回折腾。代码编辑器VS Code Remote SSH 插件本地写代码远程服务器跑模型和本地开发几乎没有差别。Docker DesktopWindows 和 Mac 上跑容器最方便的工具注意配置好 WSL2 后端。有个小建议把环境搭建的每一步都记成 Markdown包括操作系统版本、驱动版本、安装命令、遇到的错误和解决方案。这份文档的复用率远超你的想象我后来重装系统或者换新电脑基本照着笔记半小时就能恢复完整环境。4. 第一个完整项目实战图片分类服务从零到上线4.1 数据准备决定了模型的天花板数据这块我选择了一个非常经典的场景猫狗图片分类。网上的公开数据集很容易获取规模可控训练起来也不需要顶级显卡。但数据不是下载下来就能用的你需要自己做一次完整的处理流程。第一步是数据清洗把损坏的图片、重复的图片、标注错误的样本挑出来。一个非常实用的技巧是写一个脚本统计所有图片的尺寸、通道数、文件大小异常值大概率代表文件损坏。第二步是统一格式把所有图片缩放到同样尺寸我用的224x224这是很多预训练模型的默认输入大小。第三步是划分数据集我按 8:1:1 的比例切分成训练集、验证集、测试集并且保证类别分布均匀。这里有个很容易被忽略的细节验证集和测试集必须在训练流程中保持完全独立不能参与任何数据增强否则评估结果会虚高。我处理数据时的目录结构长这样data/ ├── raw/ # 原始下载文件 ├── processed/ # 清洗和缩放后的图片 │ ├── train/ │ │ ├── cat/ │ │ └── dog/ │ ├── val/ │ └── test/ ├── split_data.py # 划分脚本 └── stats.py # 统计脚本这份结构眼熟吗就是第 3 节那个通用目录模板的具体实例。现在你应该明白我为什么强调工程基础先行了——数据准备环节用的全是工程技能而不是算法技能。4.2 模型训练从预训练模型开始不做重复劳动对于一个刚入门的人我不建议完全自己设计网络结构而是用迁移学习。这里有个很重要的认知预训练模型是在大规模通用数据集上训练好的已经具备识别基础特征的能力你只需要在它之上微调让它学会区分猫和狗。这个思路既节省大量训练时间效果也通常更好。我当时的做法是用 PyTorch 加载 ResNet18替换掉最后一层全连接层让输出的维度变成二分类的数量。然后冻结骨干网络的参数只训练新加的分类头学习率设置在0.001使用 Adam 优化器和交叉熵损失函数batch_size设为 32。这个阶段训练很快大概 10 个 epoch 就能达到不错的验证精度。之后再做一步微调解冻部分骨干网络层把学习率调低一个量级比如0.0001继续训练 5 个 epoch。这一招能再提升一到两个百分点的准确率。我在实验记录里对比过两次训练的过程解冻后验证集损失的下降明显更平稳最终测试集准确率从 91% 提升到了 93.5%。还有一件事非常关键模型训练时要把随机种子固定保证实验可复现。random、numpy、torch都要设置这样别人或者未来的你重跑代码才能拿到几乎一致的结果。我在每个训练脚本最前面都会写上这几行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)4.3 模型封装把训练好的模型变成真正能用的 API模型训练好如果只是存在磁盘上其实没有任何实际价值。真正的工程闭环是把它封装成一个可供外部系统调用的服务。这一步我推荐 FastAPI它的优点是性能好、自动生成接口文档、依赖注入和参数校验写起来很舒服。封装服务需要解决几个核心问题模型加载和推理逻辑的设计、请求数据的解析与校验、响应格式的统一。我的实现比较简单初始化时加载模型权重设置成评估模式请求进来时对图片做预处理尺寸缩放、归一化推理得到类别和置信度最后按统一格式返回from fastapi import FastAPI, UploadFile, File import torch from PIL import Image import torchvision.transforms as transforms app FastAPI() model torch.load(model_resnet18_finetuned.pth, map_locationcpu) model.eval() transform transforms.Compose([ transforms.Resize((224, 224)), transforms.ToTensor(), transforms.Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]) ]) app.post(/predict) async def predict(file: UploadFile File(...)): image Image.open(file.file).convert(RGB) tensor transform(image).unsqueeze(0) with torch.no_grad(): outputs model(tensor) _, predicted torch.max(outputs, 1) return {class_id: predicted.item(), class_name: classes[predicted.item()]}一个很容易踩的坑是模型推理模式和训练模式的混淆。没有调用model.eval()某些层比如 Dropout、BatchNorm的行为就不对结果会不稳定。这是我在调试中真实撞过的问题当时测试时好时坏排查到深夜才发现是这个原因。4.4 容器化部署与基础监控服务写好了下一步是部署。深度学习服务最推荐的方式就是容器化。我写了一个最小可用的 DockerfileFROM python:3.9-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [uvicorn, main:app, --host, 0.0.0.0, --port, 80]构建镜像并启动容器几行命令就能搞定docker build -t catdog-classifier:latest . docker run -d -p 8080:80 --name classifier catdog-classifier:latest容器化之后服务上线变得非常干净。部署到云服务器或者任何一台机器上只要装了 Dockerdocker run就能跑起来环境问题基本为零。之后再加上最简单的健康检查接口GET /health返回服务状态和模型加载状态就可以挂到监控系统里了。日志这块我习惯统一收集每次请求的响应时间和状态码存到单独的地方万一服务异常排查起来很快。5. 实战高发问题排查那些文档里不会写的内容5.1 环境依赖问题版本不匹配是第一大杀手我碰到过最经典的问题就是 CUDA 版本和 PyTorch 版本不匹配。现象是安装 PyTorch 时一切正常但导入时直接报CUDA driver version is insufficient。解决思路是先确认显卡驱动的最高 CUDA 版本再往下选择合适的 PyTorch 版本。具体操作用nvidia-smi查看驱动支持的 CUDA 版本然后去 PyTorch 官网选择对应该版本的安装命令因为 PyTorch 各版本对应的编译环境不同装错版本即使能导入也跑不了 GPU。另一个高频问题是conda和pip混用带来的依赖错乱。conda管理的包和pip安装的包位于不同位置两者混装时可能互相覆盖产生诡异报错。我的原则是优先用conda装 PyTorch 和 CUDA 相关组件剩下的纯 Python 包再用pip。并且每次安装新依赖都会检查一遍conda list确认和pip list有没有冲突迹象。5.2 数据处理问题那些让人欲哭无泪的细节数据环节的坑往往比模型训练还要多。我总结三个最容易踩的数据泄漏。数据增强只用在学习率之外的地方不不不关键是验证集和测试集不能参与任何会影响数据分布的操作。比如你先对整个数据集做了标准化再划分训练验证验证集的信息已经混进了均值方差里这叫数据泄漏会让评估结果虚高。正确做法是只计算训练集的均值方差再应用到所有集合。中文路径。Windows 下如果有中文路径很多深度学习库的读取逻辑会直接失败。我初期经常遇到莫名其妙的FileNotFoundError后来把所有数据路径全部改成英文问题彻底消失。类别不均衡。如果猫狗图片数量差距过大模型会学歪倾向于把结果都预测成多数类。用小数据集练习时可以先抽样保持均衡后续再学过采样、欠采样等更高级的手段。5.3 模型训练与推理的坑速查表直接收藏我把实操中最容易撞上的问题整理成一张速查表全是我自己踩过的现象可能原因排查顺序损失不下降学习率过大或过小先用 0.001 跑 5 个 epoch 观察趋势再调训练抖动剧烈batch size 太小增大 batch size或降低学习率验证集掉点严重过拟合加正则化、Dropout或者早停GPU 显存不足输入尺寸或 batch size 过大降低 batch size、缩小图片、用梯度累积推理速度慢未开启 eval 模式或未用 GPU补上 model.eval() torch.no_grad()CPU 内存爆炸数据加载线程数过大降低 num_workers别超过物理核数太多还有个容易被忽略的经验训练时定期打印验证集指标并且保存表现最好的权重文件而不要只看最后一个 epoch。很多初学者习惯训练完直接拿最后的权重评估但最佳模型往往出现在验证集损失的拐点之前。我每次训练都会加一个回调逻辑监控验证集损失一旦连续几个 epoch 没有改善就保存当前权重并停止训练。6. 未来扩展方向与我的个人体会这个项目跑通之后可以扩展的方向非常多。我把推荐的路线列出来供参考把图片分类换成目标检测了解Faster R-CNN、YOLO等模型的服务化封装方式尝试 NLP 方向用预训练语言模型搭一个文本分类或问答服务把模型接入消息队列实现异步推理解决高并发场景下的响应问题引入 CI/CD 流程代码推送到仓库自动触发测试和部署让整个系统更接近工业级标准。根据我自己的经验这条从零开始的路线最大的收获不是学会了一个框架或模型而是建立起了一套系统级的调试和排查思维。现在遇到任何技术问题我不再会慌乱而是先拆解问题归属的层次——是环境问题、数据问题、模型问题还是工程问题再针对性定位。这套方法迁移到任何技术领域都通用。如果让我给刚开始的人一句建议那一定是不要追求完美更不要深陷理论海洋出不来快速跑通第一个最小闭环哪怕效果很差先让它动起来再一步一步优化。工程能力的成长速度和你亲手解决的问题数量成正比和你看过的教程数量关系不大。动手吧没有比实际运行起来的代码更有说服力的老师了。