1. 从零搭建AI工程能力，为什么大多数人卡在第一步
“ai-engineering-from-scratch”这个标题，第一次看到的时候我就觉得它戳中了一个很真实的痛点。现在网上关于AI的内容铺天盖地，但绝大多数要么是调个API写个demo就敢叫“实战”，要么是直接甩出一堆数学公式把人劝退。真正从零开始、把AI工程当作一门手艺来教的内容，少得可怜。
我自己带过不少新人，也见过很多想转AI工程方向的开发者。他们最常问的问题不是“Transformer的注意力机制怎么推导”，而是“我到底该先学什么、用什么工具、怎么把一个模型真正跑起来并且让别人也能用”。这就是AI工程和AI研究的核心区别——研究关心的是“能不能做到”，工程关心的是“能不能稳定、可维护、可扩展地做到”。
所以这篇内容我想聊的，是基于“ai-engineering-from-scratch”这个主题，一个从零起步的AI工程学习路径到底应该长什么样。它适合那些有基础编程能力、但对AI工程还没有系统认知的开发者，也适合已经会调模型但想补齐工程化能力的人。我会把重点放在工具链的选择逻辑、环境搭建的坑、最小可用系统的设计思路，以及从demo到生产之间那些没人告诉你的细节上。
先给一个核心判断：AI工程的门槛从来不在算法本身，而在于把数据、模型、服务、监控这四件事串成一条可靠的流水线。你不需要成为数学博士，但你必须理解每个环节的输入输出、失败模式和成本结构。接下来的内容会围绕这条主线展开，每一步都告诉你为什么这么做，以及不这么做会出什么问题。
2. 工具链选型：别一上来就追新，先搞清楚你的约束条件
2.1 语言与框架的选择逻辑
很多人一提到AI工程就默认Python，这没错，但理由不是“Python是最好的语言”，而是“Python的生态最完整”。从数据处理到模型训练再到服务部署，Python在每个环节都有成熟的库。但这里有个容易被忽略的点：如果你的服务需要高并发推理，Python的GIL会成为瓶颈，这时候你需要把推理部分用C++或者Rust重写，或者用专门的推理服务器来托管。
框架层面，PyTorch和TensorFlow的选择已经被讨论烂了。我的建议很简单：如果你是新手，选PyTorch。原因不是它“更好”，而是它的调试体验更接近普通Python程序，出错信息更可读，社区里从零开始的教程也更多。TensorFlow在部署端确实有优势，尤其是TF Serving和TFLite，但那是你走到部署阶段才需要考虑的事。一开始就纠结框架的长期优劣，就像还没学会走路就担心跑鞋的碳板刚度。
提示：不要同时学两个框架。选一个，用它完成至少三个完整项目，再去看另一个。同时学只会让你在两个相似的API之间反复混淆。
2.2 环境管理：conda还是venv
这个问题看似小，但实际影响很大。我的经验是：如果你需要管理CUDA版本和系统级依赖，用conda；如果你只是纯Python包管理，用venv加pip就够了。conda的优势在于它能帮你处理那些pip搞不定的二进制依赖，比如特定版本的cuDNN。但conda的坑也很明显：环境大了之后解析依赖会非常慢，而且不同channel之间的包冲突能让你怀疑人生。
一个折中方案是用miniconda而不是完整版anaconda，然后只装你真正需要的包。另外，不管用哪种方式，一定要把环境导出成文件。我见过太多人因为环境没记录，换台机器就再也跑不起来原来的代码了。
# conda导出环境 conda env export > environment.yml # venv导出依赖 pip freeze > requirements.txt2.3 硬件与云服务的现实考量
如果你有自己的GPU，那当然好。但大多数从零开始的人没有。这时候云GPU是唯一的选择。选云服务的时候，不要只看每小时单价，要算上数据传输成本和存储成本。有些平台GPU便宜，但数据传进去和传出来都收费，最后总账反而更贵。
另一个容易被忽略的是：开发环境和训练环境最好分开。开发用便宜的CPU实例写代码和调试，训练再切到GPU实例。这样能省下大量等待调试的时间成本。我自己的做法是本地用CPU跑小规模数据验证逻辑，确认没问题再上云跑全量。
3. 从零构建第一个AI工程项目的完整路径
3.1 项目选择：为什么我建议从结构化数据开始
新手最容易犯的错误是第一个项目就选图像生成或者大语言模型。这些任务看起来酷，但涉及的数据处理、显存管理、分布式训练复杂度极高，很容易在第一个坑就卡死。我的建议是从结构化数据的分类或回归任务开始，比如预测房价、判断客户流失、或者简单的推荐系统。
原因有三：第一，结构化数据的清洗和特征工程逻辑清晰，你能把精力放在工程流程上而不是数据格式上；第二，这类任务的模型规模小，单卡甚至CPU就能跑，迭代速度快；第三，评估指标明确，准确率、AUC、RMSE这些你一看就懂，不需要额外学习复杂的评估体系。
3.2 数据管道的搭建：最脏最累但最重要
一个AI工程项目里，数据管道的代码量通常占60%以上，但大多数人只愿意花20%的时间在这上面。这是本末倒置。数据管道没搭好，后面模型再好也是空中楼阁。
我的做法是把数据管道拆成三个独立阶段：采集、清洗、特征化。每个阶段都输出中间结果到磁盘，而不是全部在内存里串起来。这样做的好处是，当特征化逻辑出错时，你不需要重新采集和清洗，直接从中间结果开始调试就行。
# 数据管道分阶段示例 import pandas as pd from pathlib import Path RAW_DIR = Path("data/raw") CLEAN_DIR = Path("data/clean") FEATURE_DIR = Path("data/features") def ingest(): # 采集阶段：只负责把原始数据落到磁盘 df = pd.read_csv("source.csv") df.to_parquet(RAW_DIR / "raw.parquet") def clean(): # 清洗阶段：处理缺失值、异常值、类型转换 df = pd.read_parquet(RAW_DIR / "raw.parquet") df = df.dropna(subset=["target"]) df["age"] = df["age"].clip(0, 120) df.to_parquet(CLEAN_DIR / "clean.parquet") def featurize(): # 特征化阶段：编码、归一化、衍生特征 df = pd.read_parquet(CLEAN_DIR / "clean.parquet") df["age_bucket"] = pd.cut(df["age"], bins=[0, 18, 35, 60, 120]) df = pd.get_dummies(df, columns=["age_bucket"]) df.to_parquet(FEATURE_DIR / "features.parquet")每个阶段都要有对应的数据校验。比如清洗后检查目标列是否还有缺失，特征化后检查特征维度是否和预期一致。这些检查看起来简单，但能帮你省下大量“模型效果差但不知道哪里错”的排查时间。
3.3 模型训练的最小闭环
训练环节的核心不是模型结构，而是可复现性。你需要确保同样的数据、同样的代码、同样的随机种子，能跑出同样的结果。这听起来是废话，但实际项目中，因为随机种子没固定、数据加载顺序不稳定、GPU非确定性算子等原因，结果复现不了是常态。
我的做法是在训练脚本开头固定所有随机源，并且把配置写进一个独立的配置文件而不是散落在代码里。配置里至少包含：数据路径、模型超参数、训练轮数、批次大小、学习率、随机种子、输出路径。
import random import numpy as np import torch def set_seed(seed): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed) torch.backends.cudnn.deterministic = True torch.backends.cudnn.benchmark = False另外，训练过程中一定要记录日志。不是print，是写到文件里的结构化日志。至少记录每个epoch的损失、验证指标、学习率、耗时。这样当训练崩溃或者效果异常时，你有据可查。
3.4 评估与验证：别被高准确率骗了
新手看到验证集准确率90%就以为大功告成，这是最危险的。你需要看的是：混淆矩阵、每个类别的精确率和召回率、以及模型在不同数据切片上的表现。一个整体准确率90%的模型，可能在某个重要子群体上只有50%的准确率。
还有一个容易被忽略的点：验证集和测试集的划分方式。如果你的数据有时间属性，随机划分会导致数据泄露。比如用未来数据预测过去，准确率会虚高。正确做法是按时间切分，用过去的数据训练，用之后的数据验证。
注意：永远不要用测试集来调超参数。测试集只能用一次，就是最终评估的时候。调参用验证集，验证集可以反复用。
4. 从能跑到能用：AI工程化的关键跨越
4.1 模型服务化的三种方式与选择依据
模型训练完只是开始，让它能被调用才是工程化的第一步。服务化方式大致有三种：嵌入应用进程、独立推理服务、以及批处理。选择哪种取决于你的调用模式。
如果调用频率低、延迟要求不严格，直接嵌入应用进程最简单，比如在Flask应用里加载模型然后提供接口。如果调用频率高、需要独立扩缩容，那就需要独立推理服务，比如用FastAPI包装模型，然后用容器编排来管理。如果是离线批量预测，那批处理最合适，用Spark或者Ray来分布式跑。
我自己的经验是，大多数从零开始的项目，用FastAPI加Uvicorn就足够了。不要一上来就上Kubernetes，那是规模上来之后才需要考虑的事。
from fastapi import FastAPI from pydantic import BaseModel import joblib app = FastAPI() model = joblib.load("model.pkl") class Input(BaseModel): features: list[float] @app.post("/predict") def predict(input: Input): prediction = model.predict([input.features]) return {"prediction": prediction.tolist()}4.2 监控：模型上线后你该盯什么
模型上线不是终点，而是另一个起点。你需要监控的东西至少包括：请求量、延迟分布、错误率、以及模型输出的分布变化。最后这个最容易被忽略，但最重要。如果线上数据的分布和训练数据不一致，模型效果会悄悄下降，而你的错误率可能完全正常。
一个实用的做法是记录每次请求的输入特征和模型输出，然后定期计算这些特征的统计量，和训练时的统计量做对比。如果某个特征的均值偏移超过阈值，就触发告警。这不需要复杂的系统，一个定时脚本加一个简单的阈值判断就能做到。
4.3 版本管理与回滚策略
模型版本管理不是把文件重命名成model_v1、model_v2就行。你需要记录每个版本对应的训练数据、代码提交、超参数、评估指标。这样当新版本出问题时，你能快速定位是数据变了、代码变了、还是参数变了。
回滚策略也要提前设计。最简单的做法是保留上一个稳定版本的模型文件和服务配置，一旦新版本出问题，切换回去就行。但要注意，如果新版本依赖了新的特征处理逻辑，回滚时特征处理也要一起回滚，否则会出现特征不匹配的错误。
5. 那些没人告诉你但一定会踩的坑
5.1 数据泄露的隐蔽形式
数据泄露不只是“用测试集训练”这么明显。更隐蔽的形式包括：在特征工程阶段用了全量数据的统计量来做归一化，导致验证集的信息泄露到训练集；或者在时间序列任务中，用了未来才会知道的信息来构造特征。这些泄露不会报错，只会让你的验证指标虚高，上线后打回原形。
排查方法很简单：每次构造完特征后，问自己“这个特征在预测时刻真的能拿到吗”。如果答案是否定的，那就删掉。
5.2 依赖版本的地狱
AI项目的依赖冲突比普通项目严重得多。PyTorch、CUDA、cuDNN、Python版本之间有严格的对应关系，错一个就报错。更麻烦的是，有些包会偷偷升级依赖，导致你昨天还能跑的代码今天就不行了。
我的做法是锁定所有依赖的精确版本，包括间接依赖。用pip freeze或者conda env export导出完整环境，然后在Dockerfile里严格按照这个文件安装。不要用pip install package这种不指定版本的方式，那是在给自己埋雷。
5.3 显存不够时的排查顺序
显存不够是训练时最常见的错误。排查顺序应该是：先看批次大小是不是太大，这是最常见的原因；再看模型是不是没释放中间变量，比如在训练循环里累积了损失但没有detach；然后看是不是数据加载器占用了太多显存，比如num_workers设置过大；最后才考虑模型本身是不是太大，需要梯度累积或者模型并行。
# 梯度累积示例：小显存跑大batch accumulation_steps = 4 optimizer.zero_grad() for i, (inputs, labels) in enumerate(dataloader): outputs = model(inputs) loss = criterion(outputs, labels) / accumulation_steps loss.backward() if (i + 1) % accumulation_steps == 0: optimizer.step() optimizer.zero_grad()5.4 推理速度优化的常见误区
很多人一提到推理加速就想到量化或者剪枝，但实际项目中，大部分延迟来自数据预处理和后处理，而不是模型前向传播。我做过一个项目，模型推理只占20%的时间，剩下80%都在做特征拼接和格式转换。所以优化之前一定要先做性能剖析，找到真正的瓶颈。
另一个误区是盲目上GPU推理。如果模型很小、请求量不大，CPU推理可能更划算，因为GPU的启动和传输开销反而更大。只有当模型大到CPU跑不动，或者请求量大到需要批处理时，GPU才有明显优势。
6. 持续迭代：从单个项目到工程能力体系
6.1 建立自己的代码模板库
做第一个项目时，你写的代码可能是一次性的。但做第二、第三个项目时，你会发现很多代码是重复的：数据加载、训练循环、评估指标、日志记录、模型保存。这时候就应该把这些通用部分抽出来，形成自己的模板库。
我的做法是维护一个私有的项目模板仓库，每次新项目直接从模板初始化。模板里包含：标准的目录结构、配置文件模板、日志配置、训练脚本骨架、评估脚本骨架、以及Dockerfile。这样新项目启动时，我只需要改配置和写业务逻辑，不用重新搭架子。
6.2 实验追踪：别再用Excel记结果了
当你跑了十几个实验之后，用Excel或者记事本记录结果会变得不可维护。你需要一个实验追踪工具，至少能记录每次实验的配置、指标、和对应的代码版本。MLflow和Weights & Biases是两个常见选择，前者可以自托管，后者体验更好但需要联网。
我自己的做法是用MLflow，因为数据留在本地更放心。每次训练脚本运行时自动记录参数和指标，然后在UI里对比不同实验的结果。这样当你想复现某个好结果时，直接找到对应的run，一键恢复配置。
6.3 从个人项目到团队协作的过渡
个人项目怎么跑都行，但一旦涉及多人协作，就需要约定。至少包括：代码规范、分支策略、数据版本管理、模型版本管理、以及接口契约。其中数据版本管理最容易被忽略，但最重要。如果两个人用不同版本的数据训练，结果根本没法对比。
一个轻量级的做法是用DVC来管理数据和模型文件，把大文件存在对象存储里，Git里只存指针。这样既能版本化，又不会把仓库撑爆。接口契约则用OpenAPI或者Protobuf来定义，前后端严格按照契约开发，避免联调时才发现字段对不上。
6.4 保持学习：AI工程领域的信息获取渠道
AI工程是一个快速变化的领域，新工具和新方法层出不穷。但不要盲目追新，我的原则是：只学那些能解决我当前问题的东西。如果当前项目用不到，再火也不碰。等信息来源方面，我主要看三个地方：官方文档、GitHub上的活跃项目、以及一些高质量的技术博客。官方文档永远是最准确的，GitHub项目能让你看到真实世界的用法，技术博客则提供经验和踩坑记录。
提示：不要花太多时间在“学习”上，花更多时间在“做”上。做一个完整的项目，比看十篇教程学到的都多。
最后分享一个我自己的体会：AI工程能力的成长不是线性的，而是阶梯式的。你会在一段时间内感觉什么都没学到，然后突然某个时刻，之前零散的知识点全部串起来了。这个时刻通常出现在你独立完成一个从数据到上线的完整项目之后。所以，不要停留在看和学，找一个真实的问题，从头到尾做一遍，哪怕做得很粗糙。做完之后，你会发现自己对AI工程的理解完全不一样了。
