尧图网页设计 
很多想做 AI 工程的人最先搜到的往往是各种“XX天速成”“调包侠指南”但那些东西要么太浅、要么直接把你往别人的 API 上引。真正的 AI 工程不是会调几个 Python 包、跑通几个 Notebook 就完事儿的它牵扯到数据怎么管、模型怎么训、服务怎么部署、性能怎么压、成本怎么控是一套完整的工程链路。“ai-engineering-from-scratch”这个项目的核心就是不带任何捷径地把这条链路从头捋一遍——不靠现成平台的拖拉拽不靠别人封装好的黑盒靠自己的代码把一个 AI 应用从零搭起来。这篇文章我把整个项目的设计思路、核心模块、实操步骤和踩坑记录都拆开讲清楚适合刚入门想建立系统认知的人也适合那些已经在写模型但总觉得“差点工程味儿”的同学。1. 项目整体设计与思路拆解1.1 这个项目到底在做什么“ai-engineering-from-scratch”字面意思就是“从零开始的 AI 工程”。它不是某一个具体的算法教程而是一套面向 AI 应用落地全流程的工程实践指南。我更愿意把它理解成一个人在没有 AI 平台、没有现成框架、没有大厂基建的前提下如何用最朴素的工具链把一个 AI 想法做成一个可运行、可维护、可扩展的真实系统。拆开看这个项目要覆盖的环节包括需求定义、数据采集与清洗、特征处理、模型选型与训练、模型评估、服务化封装、接口设计、部署上线、性能优化、监控运维。任何一个环节单独拿出来都可以写一本书但 as a whole它训练的是你对“AI 系统”的全局感。我在实际做这个项目时定的一个重要原则就是“不逃避底层”。比如做文本分类不直接用 HuggingFace 的 Trainer 一键训练而是手动写数据加载器、手动写训练循环、手动实现早停和模型保存做部署不直接用云厂商的模型服务平台而是自己写一个 FastAPI 服务用 Docker 打包再用 Nginx 做反向代理。这些“绕远路”的动作恰恰是建立工程直觉最快的方式。1.2 为什么选择“从零实现”而不是“站在巨人肩上”这里有个容易引起争议的点现在 AI 基础设施这么成熟为什么不直接拿来用我的答案很直接——工具可以随便换但工程能力是迁移的。如果你只会用别人封装好的 Trainer换个框架、换个任务、换个部署环境你就抓瞎了。而从零实现一遍你才知道每个环节的输入输出是什么、瓶颈在哪、哪些地方可以优化、哪些地方是在浪费时间。打个比方你要学做菜看美食视频能学到菜品样式但只有自己从切菜、配菜、调味开始练才能形成手感。AI 工程也是一样自己写过一遍训练循环才能理解 batch size 为什么影响收敛、学习率调度器到底在调度什么、模型服务化之后为什么显存会涨。但这里我必须补一句“从零实现”不等于“不用任何工具”。像 NumPy、Pandas、PyTorch 这种基础库该用还是用它们是“厨具”而不是“预制菜”。项目真正避免的是那种“输入数据、点按钮、出结果”的端到端黑盒而不是拒绝一切抽象。1.3 项目的目标边界与适用范围这个项目适合谁来跟我做了这么久最深的体会是它的最佳受众是“有一定编程基础、想认真做 AI 但还没建立系统认知”的人。不需要你懂分布式训练不需要你会写 CUDA但至少要熟悉 Python、看得懂 PyTorch 的基本语法、知道 Git 的基本操作。项目的目标也不是做一个“达到 SOTA 的模型”而是做一个“结构完整、逻辑清晰、可复现的 AI 应用参考实现”。这意味着在某些环节我们甚至会故意采用“更笨但更透明”的方案——比如用 TF-IDF 做特征而不是直接上 BERT因为 TF-IDF 的每一个参数你都能解释清楚而 BERT 的向量空间对你来说基本是个黑盒。边界划清楚了后面每一步该怎么走心里就有数了。2. 核心技术点拆解与选型逻辑2.1 数据工程整个项目的隐形地基我在带人做这个项目时反复强调一句话模型训练只占 20% 的时间剩下 80% 都在跟数据打交道。很多人不信等到自己上手才发现数据清洗能让人怀疑人生。数据工程这一块项目里重点做了三件事。第一件是数据采集。我们选了一个公开的中文数据集作为练手对象具体领域不强求关键是数据要有一定规模、有真实噪声这样既避免法律风险又能保证项目的可复现性。采集环节要处理的核心问题是数据从哪里来、格式是什么样的、怎么统一成规范的结构。这个环节学到的技能是“写健壮的解析脚本”——真实数据几乎永远是脏的你要处理编码问题、字段缺失、格式错乱、重复记录。第二件是数据清洗与标注。清洗的常规操作包括去重、去空、修正格式、处理异常值。做这件事的时候我建议把每次清洗操作都记录下来形成一份“数据清洗日志”这样别人才能知道你从原始数据到干净数据到底做了哪些变换。这玩意儿看着不起眼但在工程协作中非常关键。第三件是数据划分与泄漏防止。训练集、验证集、测试集的划分必须严格遵守“互不重叠”原则而且要保证分布一致。这个环节最容易踩的坑是数据预处理时用了整个数据集的统计量比如全局归一化的均值和方差导致信息泄漏模型评估结果虚高。我在项目里专门写了一个小节讲这个问题因为太多初学者在这个点上栽过。2.2 模型选型从“套模板”到“选得明白”模型选型这个环节最能看出一个 AI 工程师是“真懂”还是“假懂”。在“ai-engineering-from-scratch”里我的建议是先做一套经典的、可解释的基线模型再逐步引入更复杂的模型。比如我们做的这个文本分类任务基线模型我选的是“TF-IDF 逻辑回归”。为什么不是因为它在精度上能打过 BERT而是因为它训练快、参数少、解释性强、不容易过拟合它能让你快速验证“数据是否有信号”“特征工程是否做对了”。很多项目上来就微调大模型结果数据有问题还浑然不觉因为模型太强了把数据的 Bug 也学会了。基线模型稳定之后再换用 PyTorch 手写一个 TextCNN 或者一个简单的 BiLSTM。这个过程的重点不是“模型结构多先进”而是“你能不能亲手实现一遍 forward、backward、参数更新”。我见过太多人简历里写着熟悉深度学习结果问一句“梯度下降时参数是怎么更新的”就卡壳这个项目就是要把这种“虚”补成“实”。选型的另一个逻辑是算力匹配。自己电脑是 CPU 还是 GPU、显存多大、训练时间预算有多少都直接决定了模型选型。我在项目里专门给了一张对照表把不同模型的训练时长、显存占用、效果预期列清楚避免有人一上来就要训练一个 7B 的大模型结果发现光加载参数就把内存吃光了。2.3 服务化封装从离线模型到在线推理模型训出来只是第一步能被别人调用才是“工程”。在这个环节我们的目标很朴素把一个训练好的模型封装成一个带 HTTP 接口的服务让别人通过 POST 请求就能拿到推理结果。技术栈上我选了 FastAPI Uvicorn。FastAPI 的好处是自带请求参数校验、自动生成 OpenAPI 文档、异步支持好写起来比 Flask 更顺手。核心步骤包括加载模型权重、定义请求体结构、写推理函数、处理异常、设置超时和并发控制。这里最容易被忽略的细节是推理与训练的环境差异。训练时模型是.train()模式BatchNorm 和 Dropout 都处于“活跃”状态推理时必须切到.eval()模式并配合torch.no_grad()否则同样的输入输出结果可能会有微小的抖动。我在项目里专门写了一行代码、一行代码地解释这个过程就是为了让大家真正理解“为什么服务端和训练脚本的代码不完全一致”。服务化之后还要做压力测试。我用的工具是 Locust 或者直接写一个简单的并发脚本测试在多少并发下服务开始变慢、会不会 OOM、需不需要加缓存、需不需要上 GPU 推理。这些内容在普通教程里很少讲但实际工作中天天都要面对。2.4 容器化与部署让项目换台机器还能跑一个 AI 项目最尴尬的场景是什么是“在我机器上跑得好好的到你那儿就崩了”。环境不一致导致的依赖冲突、CUDA 版本不匹配、系统库缺失是新手最容易掉进去的坑。Docker 解决的就是这个问题。我带着大家在项目里写了一个 Dockerfile把 Python 版本、依赖库、模型文件、启动命令全部固化到一个镜像里。这里有几个要点第一基础镜像尽量选官方维护的python:3.10-slim体积小、安全性高第二用requirements.txt锁定依赖版本避免“昨天还能跑、今天报错”的幽灵问题第三模型文件要打进镜像里或者挂载外部存储不能在容器启动时临时去下载否则一断网就废了。部署这一层我的建议是“先本地、再服务器”。先在本地把 Docker 镜像跑起来确认接口通了、效果正确再推到云服务器上。如果有条件可以用 docker-compose 把应用和 Nginx 反向代理编排在一起实现端口转发和负载均衡。这些动作看起来简单但是把“算法工程师”和“AI 工程师”区分开的重要分水岭。3. 实操过程与核心环节实现3.1 环境准备与项目骨架搭建动手前先搭环境这是老生常谈但依然有人图省事直接在全局环境里装依赖结果把系统 Python 搞坏了。我的建议是使用venv或 Conda 创建独立的虚拟环境Python 版本统一用 3.10避开某些库在新版本下的兼容性问题。项目骨架我用的是这样一套目录结构ai-engineering-from-scratch/ ├── data/ │ ├── raw/ # 原始数据 │ ├── processed/ # 清洗后的数据 │ └── splits/ # 训练/验证/测试划分 ├── src/ │ ├── data/ │ │ ├── collect.py # 数据采集脚本 │ │ ├── clean.py # 数据清洗脚本 │ │ └── dataset.py # 数据集类定义 │ ├── features/ │ │ └── build_features.py │ ├── models/ │ │ ├── baseline.py # 基线模型 │ │ ├── text_cnn.py # 深度模型 │ │ └── trainer.py # 训练循环 │ ├── api/ │ │ └── server.py # FastAPI 服务 │ └── utils/ │ ├── logger.py │ └── metrics.py ├── tests/ # 单元测试 ├── scripts/ │ ├── train.sh │ └── deploy.sh ├── Dockerfile ├── requirements.txt └── README.md这套结构的好处是“数据、模型、服务、工具”四层分离职责清晰。就算项目规模再大十倍这个骨架也能平滑扩展。3.2 数据处理的完整流程演示我用的是一个公开的文本分类数据集为了方便说明这里用一个简化版的代码来演示数据清洗流程import pandas as pd import re def clean_text(text: str) - str: 清洗文本去HTML标签、去URL、去多余空白 text re.sub(r[^], , text) # 去HTML text re.sub(rhttp\S|www\.\S, , text) # 去URL text re.sub(r\s, , text).strip() # 压缩空白 return text def process_data(input_path: str, output_path: str): df pd.read_csv(input_path, encodingutf-8) print(f原始数据量: {len(df)}) # 去重 df df.drop_duplicates(subset[text]) # 去空 df df.dropna(subset[text, label]) # 清洗文本 df[clean_text] df[text].map(clean_text) # 过滤清洗后为空的记录 df df[df[clean_text].str.len() 0] print(f清洗后数据量: {len(df)}) df.to_csv(output_path, indexFalse, encodingutf-8)这段代码看起来简单但每一步都有讲究。drop_duplicates如果不指定subset会拿整行去比较现实中往往只有个别字段相同就认为是重复所以要指定关键列。dropna要明确是只要某一列为空就删还是全部为空才删这里我们选的是前者因为一条没有正文的样本无论标签多完整都没有意义。数据划分代码如下from sklearn.model_selection import train_test_split df pd.read_csv(data/processed/clean.csv) train_df, temp_df train_test_split(df, test_size0.3, random_state42, stratifydf[label]) valid_df, test_df train_test_split(temp_df, test_size0.5, random_state42, stratifytemp_df[label]) print(f训练集: {len(train_df)}, 验证集: {len(valid_df)}, 测试集: {len(test_df)})这里有个必须解释的细节为什么划分要分两步而不是一次性train_test_split分三份因为两次划分可以确保验证集和测试集都是独立采样且都能保持标签分布一致。stratify参数是分层抽样保证每个集合里的类别比例和全量数据一致这对不平衡数据集尤其重要。数据处理环节还有一个容易被忽略的点就是保存中间结果。我建议把 raw、processed、splits 三个数据版本都保留下来不要原地覆盖。这样如果后边发现有数据泄漏问题还能回溯到具体是哪一步引入的而不是从头再来。3.3 基线模型的完整实现这一节先做 TF-IDF 逻辑回归。代码分两部分特征工程和模型训练。from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.linear_model import LogisticRegression from sklearn.metrics import classification_report # 特征工程 vectorizer TfidfVectorizer(max_features5000, ngram_range(1, 2), stop_wordsenglish) X_train vectorizer.fit_transform(train_df[clean_text]) X_valid vectorizer.transform(valid_df[clean_text]) # 训练模型 model LogisticRegression(C1.0, max_iter1000, random_state42) model.fit(X_train, train_df[label]) # 验证 y_pred model.predict(X_valid) print(classification_report(valid_df[label], y_pred))TF-IDF 的三个参数值得展开一下。max_features5000限制特征数量防止词表过大导致稀疏矩阵爆炸ngram_range(1, 2)同时考虑单词和相邻单词组合能捕捉一些简单短语信息stop_words去掉“的、了、是”这类高频虚词避免它们干扰特征重要性。这里必须强调一个很多新手都会犯的错fit_transform只能用在训练集上验证集和测试集只能用transform。因为fit的过程是在学习词表、计算 IDF 权重如果验证集也参与了 fit那验证集的信息就“泄漏”到了特征工程里评估结果会虚高。基线模型的效果不用太在意它的核心价值是让你验证整个数据链路是否通畅。如果逻辑回归的准确率明显高于随机猜测说明数据里有信号如果准确率和随机差不多问题大概率出在数据处理环节先别着急上复杂模型。3.4 手写 PyTorch 训练循环接下来是重头戏用 PyTorch 实现一个简单的 TextCNN 模型并且不借助任何高级封装手写训练循环。先定义数据集类import torch from torch.utils.data import Dataset class TextDataset(Dataset): def __init__(self, texts, labels, tokenizer, max_len64): 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): text self.texts[idx] label self.labels[idx] # 简化处理按空格切分并映射到词表索引 tokens self.tokenizer(text) input_ids [self.tokenizer.vocab.get(t, 1) for t in tokens] # padding / truncation if len(input_ids) self.max_len: input_ids [0] * (self.max_len - len(input_ids)) else: input_ids input_ids[:self.max_len] return torch.tensor(input_ids, dtypetorch.long), torch.tensor(label, dtypetorch.long)再定义模型结构import torch.nn as nn class TextCNN(nn.Module): def __init__(self, vocab_size, embed_dim128, num_filters100, num_classes2): super().__init__() self.embedding nn.Embedding(vocab_size, embed_dim, padding_idx0) self.convs nn.ModuleList([ nn.Conv1d(embed_dim, num_filters, kernel_sizek) for k in [3, 4, 5] ]) self.fc nn.Linear(num_filters * 3, num_classes) self.dropout nn.Dropout(0.5) def forward(self, x): # x: (batch, seq_len) emb self.embedding(x) # (batch, seq_len, embed_dim) emb emb.transpose(1, 2) # (batch, embed_dim, seq_len) pooled [] for conv in self.convs: c conv(emb) # (batch, num_filters, seq_len) p torch.max_pool1d(c, c.size(2)) # (batch, num_filters, 1) pooled.append(p.squeeze(2)) cat torch.cat(pooled, dim1) # (batch, num_filters * 3) out self.dropout(cat) return self.fc(out)然后是最关键的手写训练循环import torch.optim as optim from torch.utils.data import DataLoader from tqdm import tqdm def train_epoch(model, dataloader, optimizer, criterion, device): model.train() total_loss, total_correct, total 0, 0, 0 for batch in tqdm(dataloader, descTraining): input_ids, labels batch[0].to(device), batch[1].to(device) optimizer.zero_grad() outputs model(input_ids) loss criterion(outputs, labels) loss.backward() optimizer.step() total_loss loss.item() * input_ids.size(0) _, preds torch.max(outputs, dim1) total_correct (preds labels).sum().item() total input_ids.size(0) return total_loss / total, total_correct / total def evaluate(model, dataloader, criterion, device): model.eval() total_loss, total_correct, total 0, 0, 0 with torch.no_grad(): for batch in dataloader: input_ids, labels batch[0].to(device), batch[1].to(device) outputs model(input_ids) loss criterion(outputs, labels) total_loss loss.item() * input_ids.size(0) _, preds torch.max(outputs, dim1) total_correct (preds labels).sum().item() total input_ids.size(0) return total_loss / total, total_correct / total注意model.train()和model.eval()之间的切换以及with torch.no_grad()的用法这三行代码能解释清楚说明你是真的理解推理和训练的区别而不是背了个模板。完整的训练脚本还会包含学习率调度、早停Early Stopping、模型检查点保存等逻辑篇幅关系这里不全部展开但项目里都有完整实现可直接参考。3.5 模型服务化FastAPI 部署实战模型训练完现在要把它变成一个服务。这是整个项目里最“工程”味十足的部分也是很多人最陌生的部分。先写一个推理封装类import torch from src.models.text_cnn import TextCNN class Predictor: def __init__(self, model_path, vocab_path, devicecpu): self.device device self.vocab torch.load(vocab_path) self.model TextCNN(len(self.vocab) 2) self.model.load_state_dict(torch.load(model_path, map_locationdevice)) self.model.to(device) self.model.eval() def predict(self, text: str): # 文本 - 向量 tokens text.split() input_ids [self.vocab.get(t, 1) for t in tokens] input_ids (input_ids[:64] [0] * 64)[:64] input_tensor torch.tensor([input_ids], dtypetorch.long, deviceself.device) with torch.no_grad(): outputs self.model(input_tensor) prob torch.softmax(outputs, dim1) label torch.argmax(prob, dim1).item() return {label: int(label), confidence: float(prob[0][label])}然后再用 FastAPI 包一层 HTTP 接口from fastapi import FastAPI from pydantic import BaseModel app FastAPI(titleText Classification API) predictor Predictor(models/text_cnn.pt, models/vocab.pt) class PredictRequest(BaseModel): text: str app.post(/predict) def predict(req: PredictRequest): result predictor.predict(req.text) return result app.get(/health) def health(): return {status: ok}这里有三个安全细节要提醒。第一predictor对象要放在 module 级别在服务启动时只加载一次模型每个请求直接复用已经加载好的模型否则每个请求都重新加载一遍权重服务和“卡死”没什么区别。第二with torch.no_grad()在推理时一定要加否则 PyTorch 会为每个中间变量构建计算图导致内存不断上涨。很多人在本地跑没问题一部署就 OOM九成是这个原因。第三请求体的参数校验交给 Pydantic 的BaseModel来做不要自己手写try/except去解析 JSON那样既繁琐又容易漏掉边界情况。写好这两个文件在命令行执行uvicorn src.api.server:app --host 0.0.0.0 --port 8000再用curl测试一下curl -X POST http://localhost:8000/predict \ -H Content-Type: application/json \ -d {text: 今天天气真好适合出去走走}能返回 JSON 结果说明服务化这一环已经通了。接下来就是 Docker 和部署。Dockerfile 可以这样写FROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 8000 CMD [uvicorn, src.api.server:app, --host, 0.0.0.0, --port, 8000]构建镜像docker build -t ai-engineering-demo . docker run -d -p 8000:8000 ai-engineering-demo这里有几个值得强调的细节python:3.10-slim镜像体积小、攻击面小比用python:latest稳妥COPY . .之前一定要有.dockerignore文件把data/raw、__pycache__、.git排除掉否则镜像体积瞬间膨胀不要用pip install装不带版本号的依赖统一走requirements.txt。3.6 模型评估与指标解读模型不能只看准确率尤其在类别不平衡的时候准确率会骗人。项目里我要求大家至少要看四个指标准确率Accuracy、精确率Precision、召回率Recall、F1 值并且要分别算 Macro 平均和 Weighted 平均。举个例子假设我们的测试集里 90% 是类别 A10% 是类别 B。一个“无脑全预测为 A”的分类器准确率是 90%看起来很高但对类别 B 的召回率是 0等于这个模型在真实场景里“瞎了”。所以看指标必须结合类别分布来看。我在项目里把评估模块独立成一个脚本输入测试集和模型预测结果输出一个完整的分类报告同时画出混淆矩阵。这些可视化结果不仅能帮你发现问题也是对外展示项目成果的有力材料。4. 常见问题与排查技巧实录4.1 模型训练 Loss 不下降怎么办这是所有 AI 项目必经的“鬼打墙”时刻。我的排查顺序是先看数据把训练样本随机打印几条肉眼检查预处理后的输入是否正常、标签是否对齐。很多“Loss 不下降”的问题其实是数据加载器的索引和标签错位了。再看梯度如果 Loss 是nan通常是学习率过大、数值不稳定或者标签范围不对如果梯度直接为 0可能是网络没有连起来。最后看模型用一个小批量数据试训练把 batch size 调小、学习率调低跑几十步看 Loss 是否在动如果纹丝不动检查模型forward里是否有detach()导致梯度断流。解决这个问题的关键不是某个神奇的调参咒语而是冷静地把链路拆开、逐段验证。4.2 服务端推理速度太慢推理慢是部署阶段的高频问题。常见的原因和应对措施可以整理成一张表可能原因排查方法解决措施每次请求都加载模型看日志里是否有模型加载的耗时记录服务启动时预加载一次没有用 GPU 推理看推理是否默认走了 CPU指定devicecuda未开启批量推理看单条推理是否串行用gather/批处理接口输入文本过长看预处理环节的耗时占比限制max_len剪裁长文本模型结构冗余分析耗时分布判断 CNN/全连接占比裁剪网络结构或做模型量化另外可以加一层简单的缓存对重复的请求比如同一句话发两次直接返回上一次的结果能显著降低压力。4.3 Docker 镜像构建失败或体积过大镜像构建失败最常见的是网络问题导致依赖下载失败尤其是 PyTorch 这种体积巨大的包。解决办法是配置国内镜像源或者把依赖拆成多个阶段安装减少失败时重新下载的成本。镜像体积过大常见原因是没有.dockerignore把数据集和 git 历史打进去了。还有如果基础镜像用的是python:3.10而不是python:3.10-slim体积会差几百 MB。做好这些优化镜像从 2GB 降到 500MB 是完全可能的。4.4 数据泄漏导致的评估虚高这个问题在前文提过但它值得单独拿出来说。我见过太多人拿着虚高的测试集准确率沾沾自喜上线后效果暴跌。防止数据泄漏的几个铁律数据划分必须在任何特征工程、归一化、降维之前完成。任何从训练集计算得到的参数均值、方差、词表、IDF 权重都要序列化保存推理阶段只加载、不重新计算。如果用 TF-IDF 或 BERT 的 Tokenizer词表的构建只能基于训练集。如果可以项目里建议把“预处理管线”整体封装成两个对象fit方法和transform方法训练集上执行fit_transform验证集/测试集上只执行transform。这样从设计上就杜绝了泄漏的可能。5. 项目经验总结与后续扩展5.1 我在实际推进中的个人体会做这个项目最大的感受就是“AI 工程的复杂度不是线性的”。你推数据清洗的时候觉得繁琐写完训练循环觉得有点成就感但真的到了部署阶段才发现前面的工作都只是热身。环境配置、性能调优、异常处理、安全防护每一件都在消耗你能量的同时逼着你建立全局意识。我想给大家的建议是千万不要跳过任何环节尤其不要跳过“服务化”和“部署”这两个看似跟算法无关的部分。我在带人做项目的时候发现很多人宁可在 Kaggle 上卷精度也不愿意把模型部署成一个别人能用的服务结果就是算法能力强、工程能力弱面试时一旦被问到“怎么做上线”就露馅。另外代码规范要从第一天就抓好。变量命名、函数拆分、日志打印、注释风格这些“表面功夫”决定了你的项目能不能被别人接手、能不能在一周后自己还能看懂。我在项目里给出的所有代码都尽量保持风格一致、注释到位就是希望大家养成好习惯。5.2 这个项目还能怎么往上扩展“ai-engineering-from-scratch”的架构做完之后扩展方向非常多这里列几个我认为最有价值的。一个是加入 MLflow 做实验跟踪把每次训练的配置、指标、模型产物都记录下来形成完整的实验矩阵避免“调参调到失去记忆”。另一个是把单机服务改成多 worker 部署用 Gunicorn 管理多进程或者用 Kubernetes 做容器编排。这一步能让你真正理解“高可用”和“水平扩展”的工程含义也跟现实工作的技术栈更贴近。还有一个是模型量化与加速比如把 PyTorch 模型转成 ONNX用 TensorRT 做推理加速或者在模型层面做剪枝和蒸馏。模型压缩是一个永远有需求的方向而且做得越深你对模型内部结构的理解就越透。最后强调一句项目里的每段代码都包含详细注释并且配套了完整的 README 文档。在原仓库的基础上你完全可以把它当作一个自己的练手项目来跑改数据、换模型、扩展模块、优化性能做成你自己的作品集项目。真正值钱的不是项目本身而是你在做项目的过程中建立的那套对 AI 工程的完整感觉。 从零搭建AI工程全链路：数据、模型、部署与踩坑实录
很多想做 AI 工程的人最先搜到的往往是各种“XX天速成”“调包侠指南”但那些东西要么太浅、要么直接把你往别人的 API 上引。真正的 AI 工程不是会调几个 Python 包、跑通几个 Notebook 就完事儿的它牵扯到数据怎么管、模型怎么训、服务怎么部署、性能怎么压、成本怎么控是一套完整的工程链路。“ai-engineering-from-scratch”这个项目的核心就是不带任何捷径地把这条链路从头捋一遍——不靠现成平台的拖拉拽不靠别人封装好的黑盒靠自己的代码把一个 AI 应用从零搭起来。这篇文章我把整个项目的设计思路、核心模块、实操步骤和踩坑记录都拆开讲清楚适合刚入门想建立系统认知的人也适合那些已经在写模型但总觉得“差点工程味儿”的同学。1. 项目整体设计与思路拆解1.1 这个项目到底在做什么“ai-engineering-from-scratch”字面意思就是“从零开始的 AI 工程”。它不是某一个具体的算法教程而是一套面向 AI 应用落地全流程的工程实践指南。我更愿意把它理解成一个人在没有 AI 平台、没有现成框架、没有大厂基建的前提下如何用最朴素的工具链把一个 AI 想法做成一个可运行、可维护、可扩展的真实系统。拆开看这个项目要覆盖的环节包括需求定义、数据采集与清洗、特征处理、模型选型与训练、模型评估、服务化封装、接口设计、部署上线、性能优化、监控运维。任何一个环节单独拿出来都可以写一本书但 as a whole它训练的是你对“AI 系统”的全局感。我在实际做这个项目时定的一个重要原则就是“不逃避底层”。比如做文本分类不直接用 HuggingFace 的 Trainer 一键训练而是手动写数据加载器、手动写训练循环、手动实现早停和模型保存做部署不直接用云厂商的模型服务平台而是自己写一个 FastAPI 服务用 Docker 打包再用 Nginx 做反向代理。这些“绕远路”的动作恰恰是建立工程直觉最快的方式。1.2 为什么选择“从零实现”而不是“站在巨人肩上”这里有个容易引起争议的点现在 AI 基础设施这么成熟为什么不直接拿来用我的答案很直接——工具可以随便换但工程能力是迁移的。如果你只会用别人封装好的 Trainer换个框架、换个任务、换个部署环境你就抓瞎了。而从零实现一遍你才知道每个环节的输入输出是什么、瓶颈在哪、哪些地方可以优化、哪些地方是在浪费时间。打个比方你要学做菜看美食视频能学到菜品样式但只有自己从切菜、配菜、调味开始练才能形成手感。AI 工程也是一样自己写过一遍训练循环才能理解 batch size 为什么影响收敛、学习率调度器到底在调度什么、模型服务化之后为什么显存会涨。但这里我必须补一句“从零实现”不等于“不用任何工具”。像 NumPy、Pandas、PyTorch 这种基础库该用还是用它们是“厨具”而不是“预制菜”。项目真正避免的是那种“输入数据、点按钮、出结果”的端到端黑盒而不是拒绝一切抽象。1.3 项目的目标边界与适用范围这个项目适合谁来跟我做了这么久最深的体会是它的最佳受众是“有一定编程基础、想认真做 AI 但还没建立系统认知”的人。不需要你懂分布式训练不需要你会写 CUDA但至少要熟悉 Python、看得懂 PyTorch 的基本语法、知道 Git 的基本操作。项目的目标也不是做一个“达到 SOTA 的模型”而是做一个“结构完整、逻辑清晰、可复现的 AI 应用参考实现”。这意味着在某些环节我们甚至会故意采用“更笨但更透明”的方案——比如用 TF-IDF 做特征而不是直接上 BERT因为 TF-IDF 的每一个参数你都能解释清楚而 BERT 的向量空间对你来说基本是个黑盒。边界划清楚了后面每一步该怎么走心里就有数了。2. 核心技术点拆解与选型逻辑2.1 数据工程整个项目的隐形地基我在带人做这个项目时反复强调一句话模型训练只占 20% 的时间剩下 80% 都在跟数据打交道。很多人不信等到自己上手才发现数据清洗能让人怀疑人生。数据工程这一块项目里重点做了三件事。第一件是数据采集。我们选了一个公开的中文数据集作为练手对象具体领域不强求关键是数据要有一定规模、有真实噪声这样既避免法律风险又能保证项目的可复现性。采集环节要处理的核心问题是数据从哪里来、格式是什么样的、怎么统一成规范的结构。这个环节学到的技能是“写健壮的解析脚本”——真实数据几乎永远是脏的你要处理编码问题、字段缺失、格式错乱、重复记录。第二件是数据清洗与标注。清洗的常规操作包括去重、去空、修正格式、处理异常值。做这件事的时候我建议把每次清洗操作都记录下来形成一份“数据清洗日志”这样别人才能知道你从原始数据到干净数据到底做了哪些变换。这玩意儿看着不起眼但在工程协作中非常关键。第三件是数据划分与泄漏防止。训练集、验证集、测试集的划分必须严格遵守“互不重叠”原则而且要保证分布一致。这个环节最容易踩的坑是数据预处理时用了整个数据集的统计量比如全局归一化的均值和方差导致信息泄漏模型评估结果虚高。我在项目里专门写了一个小节讲这个问题因为太多初学者在这个点上栽过。2.2 模型选型从“套模板”到“选得明白”模型选型这个环节最能看出一个 AI 工程师是“真懂”还是“假懂”。在“ai-engineering-from-scratch”里我的建议是先做一套经典的、可解释的基线模型再逐步引入更复杂的模型。比如我们做的这个文本分类任务基线模型我选的是“TF-IDF 逻辑回归”。为什么不是因为它在精度上能打过 BERT而是因为它训练快、参数少、解释性强、不容易过拟合它能让你快速验证“数据是否有信号”“特征工程是否做对了”。很多项目上来就微调大模型结果数据有问题还浑然不觉因为模型太强了把数据的 Bug 也学会了。基线模型稳定之后再换用 PyTorch 手写一个 TextCNN 或者一个简单的 BiLSTM。这个过程的重点不是“模型结构多先进”而是“你能不能亲手实现一遍 forward、backward、参数更新”。我见过太多人简历里写着熟悉深度学习结果问一句“梯度下降时参数是怎么更新的”就卡壳这个项目就是要把这种“虚”补成“实”。选型的另一个逻辑是算力匹配。自己电脑是 CPU 还是 GPU、显存多大、训练时间预算有多少都直接决定了模型选型。我在项目里专门给了一张对照表把不同模型的训练时长、显存占用、效果预期列清楚避免有人一上来就要训练一个 7B 的大模型结果发现光加载参数就把内存吃光了。2.3 服务化封装从离线模型到在线推理模型训出来只是第一步能被别人调用才是“工程”。在这个环节我们的目标很朴素把一个训练好的模型封装成一个带 HTTP 接口的服务让别人通过 POST 请求就能拿到推理结果。技术栈上我选了 FastAPI Uvicorn。FastAPI 的好处是自带请求参数校验、自动生成 OpenAPI 文档、异步支持好写起来比 Flask 更顺手。核心步骤包括加载模型权重、定义请求体结构、写推理函数、处理异常、设置超时和并发控制。这里最容易被忽略的细节是推理与训练的环境差异。训练时模型是.train()模式BatchNorm 和 Dropout 都处于“活跃”状态推理时必须切到.eval()模式并配合torch.no_grad()否则同样的输入输出结果可能会有微小的抖动。我在项目里专门写了一行代码、一行代码地解释这个过程就是为了让大家真正理解“为什么服务端和训练脚本的代码不完全一致”。服务化之后还要做压力测试。我用的工具是 Locust 或者直接写一个简单的并发脚本测试在多少并发下服务开始变慢、会不会 OOM、需不需要加缓存、需不需要上 GPU 推理。这些内容在普通教程里很少讲但实际工作中天天都要面对。2.4 容器化与部署让项目换台机器还能跑一个 AI 项目最尴尬的场景是什么是“在我机器上跑得好好的到你那儿就崩了”。环境不一致导致的依赖冲突、CUDA 版本不匹配、系统库缺失是新手最容易掉进去的坑。Docker 解决的就是这个问题。我带着大家在项目里写了一个 Dockerfile把 Python 版本、依赖库、模型文件、启动命令全部固化到一个镜像里。这里有几个要点第一基础镜像尽量选官方维护的python:3.10-slim体积小、安全性高第二用requirements.txt锁定依赖版本避免“昨天还能跑、今天报错”的幽灵问题第三模型文件要打进镜像里或者挂载外部存储不能在容器启动时临时去下载否则一断网就废了。部署这一层我的建议是“先本地、再服务器”。先在本地把 Docker 镜像跑起来确认接口通了、效果正确再推到云服务器上。如果有条件可以用 docker-compose 把应用和 Nginx 反向代理编排在一起实现端口转发和负载均衡。这些动作看起来简单但是把“算法工程师”和“AI 工程师”区分开的重要分水岭。3. 实操过程与核心环节实现3.1 环境准备与项目骨架搭建动手前先搭环境这是老生常谈但依然有人图省事直接在全局环境里装依赖结果把系统 Python 搞坏了。我的建议是使用venv或 Conda 创建独立的虚拟环境Python 版本统一用 3.10避开某些库在新版本下的兼容性问题。项目骨架我用的是这样一套目录结构ai-engineering-from-scratch/ ├── data/ │ ├── raw/ # 原始数据 │ ├── processed/ # 清洗后的数据 │ └── splits/ # 训练/验证/测试划分 ├── src/ │ ├── data/ │ │ ├── collect.py # 数据采集脚本 │ │ ├── clean.py # 数据清洗脚本 │ │ └── dataset.py # 数据集类定义 │ ├── features/ │ │ └── build_features.py │ ├── models/ │ │ ├── baseline.py # 基线模型 │ │ ├── text_cnn.py # 深度模型 │ │ └── trainer.py # 训练循环 │ ├── api/ │ │ └── server.py # FastAPI 服务 │ └── utils/ │ ├── logger.py │ └── metrics.py ├── tests/ # 单元测试 ├── scripts/ │ ├── train.sh │ └── deploy.sh ├── Dockerfile ├── requirements.txt └── README.md这套结构的好处是“数据、模型、服务、工具”四层分离职责清晰。就算项目规模再大十倍这个骨架也能平滑扩展。3.2 数据处理的完整流程演示我用的是一个公开的文本分类数据集为了方便说明这里用一个简化版的代码来演示数据清洗流程import pandas as pd import re def clean_text(text: str) - str: 清洗文本去HTML标签、去URL、去多余空白 text re.sub(r[^], , text) # 去HTML text re.sub(rhttp\S|www\.\S, , text) # 去URL text re.sub(r\s, , text).strip() # 压缩空白 return text def process_data(input_path: str, output_path: str): df pd.read_csv(input_path, encodingutf-8) print(f原始数据量: {len(df)}) # 去重 df df.drop_duplicates(subset[text]) # 去空 df df.dropna(subset[text, label]) # 清洗文本 df[clean_text] df[text].map(clean_text) # 过滤清洗后为空的记录 df df[df[clean_text].str.len() 0] print(f清洗后数据量: {len(df)}) df.to_csv(output_path, indexFalse, encodingutf-8)这段代码看起来简单但每一步都有讲究。drop_duplicates如果不指定subset会拿整行去比较现实中往往只有个别字段相同就认为是重复所以要指定关键列。dropna要明确是只要某一列为空就删还是全部为空才删这里我们选的是前者因为一条没有正文的样本无论标签多完整都没有意义。数据划分代码如下from sklearn.model_selection import train_test_split df pd.read_csv(data/processed/clean.csv) train_df, temp_df train_test_split(df, test_size0.3, random_state42, stratifydf[label]) valid_df, test_df train_test_split(temp_df, test_size0.5, random_state42, stratifytemp_df[label]) print(f训练集: {len(train_df)}, 验证集: {len(valid_df)}, 测试集: {len(test_df)})这里有个必须解释的细节为什么划分要分两步而不是一次性train_test_split分三份因为两次划分可以确保验证集和测试集都是独立采样且都能保持标签分布一致。stratify参数是分层抽样保证每个集合里的类别比例和全量数据一致这对不平衡数据集尤其重要。数据处理环节还有一个容易被忽略的点就是保存中间结果。我建议把 raw、processed、splits 三个数据版本都保留下来不要原地覆盖。这样如果后边发现有数据泄漏问题还能回溯到具体是哪一步引入的而不是从头再来。3.3 基线模型的完整实现这一节先做 TF-IDF 逻辑回归。代码分两部分特征工程和模型训练。from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.linear_model import LogisticRegression from sklearn.metrics import classification_report # 特征工程 vectorizer TfidfVectorizer(max_features5000, ngram_range(1, 2), stop_wordsenglish) X_train vectorizer.fit_transform(train_df[clean_text]) X_valid vectorizer.transform(valid_df[clean_text]) # 训练模型 model LogisticRegression(C1.0, max_iter1000, random_state42) model.fit(X_train, train_df[label]) # 验证 y_pred model.predict(X_valid) print(classification_report(valid_df[label], y_pred))TF-IDF 的三个参数值得展开一下。max_features5000限制特征数量防止词表过大导致稀疏矩阵爆炸ngram_range(1, 2)同时考虑单词和相邻单词组合能捕捉一些简单短语信息stop_words去掉“的、了、是”这类高频虚词避免它们干扰特征重要性。这里必须强调一个很多新手都会犯的错fit_transform只能用在训练集上验证集和测试集只能用transform。因为fit的过程是在学习词表、计算 IDF 权重如果验证集也参与了 fit那验证集的信息就“泄漏”到了特征工程里评估结果会虚高。基线模型的效果不用太在意它的核心价值是让你验证整个数据链路是否通畅。如果逻辑回归的准确率明显高于随机猜测说明数据里有信号如果准确率和随机差不多问题大概率出在数据处理环节先别着急上复杂模型。3.4 手写 PyTorch 训练循环接下来是重头戏用 PyTorch 实现一个简单的 TextCNN 模型并且不借助任何高级封装手写训练循环。先定义数据集类import torch from torch.utils.data import Dataset class TextDataset(Dataset): def __init__(self, texts, labels, tokenizer, max_len64): 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): text self.texts[idx] label self.labels[idx] # 简化处理按空格切分并映射到词表索引 tokens self.tokenizer(text) input_ids [self.tokenizer.vocab.get(t, 1) for t in tokens] # padding / truncation if len(input_ids) self.max_len: input_ids [0] * (self.max_len - len(input_ids)) else: input_ids input_ids[:self.max_len] return torch.tensor(input_ids, dtypetorch.long), torch.tensor(label, dtypetorch.long)再定义模型结构import torch.nn as nn class TextCNN(nn.Module): def __init__(self, vocab_size, embed_dim128, num_filters100, num_classes2): super().__init__() self.embedding nn.Embedding(vocab_size, embed_dim, padding_idx0) self.convs nn.ModuleList([ nn.Conv1d(embed_dim, num_filters, kernel_sizek) for k in [3, 4, 5] ]) self.fc nn.Linear(num_filters * 3, num_classes) self.dropout nn.Dropout(0.5) def forward(self, x): # x: (batch, seq_len) emb self.embedding(x) # (batch, seq_len, embed_dim) emb emb.transpose(1, 2) # (batch, embed_dim, seq_len) pooled [] for conv in self.convs: c conv(emb) # (batch, num_filters, seq_len) p torch.max_pool1d(c, c.size(2)) # (batch, num_filters, 1) pooled.append(p.squeeze(2)) cat torch.cat(pooled, dim1) # (batch, num_filters * 3) out self.dropout(cat) return self.fc(out)然后是最关键的手写训练循环import torch.optim as optim from torch.utils.data import DataLoader from tqdm import tqdm def train_epoch(model, dataloader, optimizer, criterion, device): model.train() total_loss, total_correct, total 0, 0, 0 for batch in tqdm(dataloader, descTraining): input_ids, labels batch[0].to(device), batch[1].to(device) optimizer.zero_grad() outputs model(input_ids) loss criterion(outputs, labels) loss.backward() optimizer.step() total_loss loss.item() * input_ids.size(0) _, preds torch.max(outputs, dim1) total_correct (preds labels).sum().item() total input_ids.size(0) return total_loss / total, total_correct / total def evaluate(model, dataloader, criterion, device): model.eval() total_loss, total_correct, total 0, 0, 0 with torch.no_grad(): for batch in dataloader: input_ids, labels batch[0].to(device), batch[1].to(device) outputs model(input_ids) loss criterion(outputs, labels) total_loss loss.item() * input_ids.size(0) _, preds torch.max(outputs, dim1) total_correct (preds labels).sum().item() total input_ids.size(0) return total_loss / total, total_correct / total注意model.train()和model.eval()之间的切换以及with torch.no_grad()的用法这三行代码能解释清楚说明你是真的理解推理和训练的区别而不是背了个模板。完整的训练脚本还会包含学习率调度、早停Early Stopping、模型检查点保存等逻辑篇幅关系这里不全部展开但项目里都有完整实现可直接参考。3.5 模型服务化FastAPI 部署实战模型训练完现在要把它变成一个服务。这是整个项目里最“工程”味十足的部分也是很多人最陌生的部分。先写一个推理封装类import torch from src.models.text_cnn import TextCNN class Predictor: def __init__(self, model_path, vocab_path, devicecpu): self.device device self.vocab torch.load(vocab_path) self.model TextCNN(len(self.vocab) 2) self.model.load_state_dict(torch.load(model_path, map_locationdevice)) self.model.to(device) self.model.eval() def predict(self, text: str): # 文本 - 向量 tokens text.split() input_ids [self.vocab.get(t, 1) for t in tokens] input_ids (input_ids[:64] [0] * 64)[:64] input_tensor torch.tensor([input_ids], dtypetorch.long, deviceself.device) with torch.no_grad(): outputs self.model(input_tensor) prob torch.softmax(outputs, dim1) label torch.argmax(prob, dim1).item() return {label: int(label), confidence: float(prob[0][label])}然后再用 FastAPI 包一层 HTTP 接口from fastapi import FastAPI from pydantic import BaseModel app FastAPI(titleText Classification API) predictor Predictor(models/text_cnn.pt, models/vocab.pt) class PredictRequest(BaseModel): text: str app.post(/predict) def predict(req: PredictRequest): result predictor.predict(req.text) return result app.get(/health) def health(): return {status: ok}这里有三个安全细节要提醒。第一predictor对象要放在 module 级别在服务启动时只加载一次模型每个请求直接复用已经加载好的模型否则每个请求都重新加载一遍权重服务和“卡死”没什么区别。第二with torch.no_grad()在推理时一定要加否则 PyTorch 会为每个中间变量构建计算图导致内存不断上涨。很多人在本地跑没问题一部署就 OOM九成是这个原因。第三请求体的参数校验交给 Pydantic 的BaseModel来做不要自己手写try/except去解析 JSON那样既繁琐又容易漏掉边界情况。写好这两个文件在命令行执行uvicorn src.api.server:app --host 0.0.0.0 --port 8000再用curl测试一下curl -X POST http://localhost:8000/predict \ -H Content-Type: application/json \ -d {text: 今天天气真好适合出去走走}能返回 JSON 结果说明服务化这一环已经通了。接下来就是 Docker 和部署。Dockerfile 可以这样写FROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 8000 CMD [uvicorn, src.api.server:app, --host, 0.0.0.0, --port, 8000]构建镜像docker build -t ai-engineering-demo . docker run -d -p 8000:8000 ai-engineering-demo这里有几个值得强调的细节python:3.10-slim镜像体积小、攻击面小比用python:latest稳妥COPY . .之前一定要有.dockerignore文件把data/raw、__pycache__、.git排除掉否则镜像体积瞬间膨胀不要用pip install装不带版本号的依赖统一走requirements.txt。3.6 模型评估与指标解读模型不能只看准确率尤其在类别不平衡的时候准确率会骗人。项目里我要求大家至少要看四个指标准确率Accuracy、精确率Precision、召回率Recall、F1 值并且要分别算 Macro 平均和 Weighted 平均。举个例子假设我们的测试集里 90% 是类别 A10% 是类别 B。一个“无脑全预测为 A”的分类器准确率是 90%看起来很高但对类别 B 的召回率是 0等于这个模型在真实场景里“瞎了”。所以看指标必须结合类别分布来看。我在项目里把评估模块独立成一个脚本输入测试集和模型预测结果输出一个完整的分类报告同时画出混淆矩阵。这些可视化结果不仅能帮你发现问题也是对外展示项目成果的有力材料。4. 常见问题与排查技巧实录4.1 模型训练 Loss 不下降怎么办这是所有 AI 项目必经的“鬼打墙”时刻。我的排查顺序是先看数据把训练样本随机打印几条肉眼检查预处理后的输入是否正常、标签是否对齐。很多“Loss 不下降”的问题其实是数据加载器的索引和标签错位了。再看梯度如果 Loss 是nan通常是学习率过大、数值不稳定或者标签范围不对如果梯度直接为 0可能是网络没有连起来。最后看模型用一个小批量数据试训练把 batch size 调小、学习率调低跑几十步看 Loss 是否在动如果纹丝不动检查模型forward里是否有detach()导致梯度断流。解决这个问题的关键不是某个神奇的调参咒语而是冷静地把链路拆开、逐段验证。4.2 服务端推理速度太慢推理慢是部署阶段的高频问题。常见的原因和应对措施可以整理成一张表可能原因排查方法解决措施每次请求都加载模型看日志里是否有模型加载的耗时记录服务启动时预加载一次没有用 GPU 推理看推理是否默认走了 CPU指定devicecuda未开启批量推理看单条推理是否串行用gather/批处理接口输入文本过长看预处理环节的耗时占比限制max_len剪裁长文本模型结构冗余分析耗时分布判断 CNN/全连接占比裁剪网络结构或做模型量化另外可以加一层简单的缓存对重复的请求比如同一句话发两次直接返回上一次的结果能显著降低压力。4.3 Docker 镜像构建失败或体积过大镜像构建失败最常见的是网络问题导致依赖下载失败尤其是 PyTorch 这种体积巨大的包。解决办法是配置国内镜像源或者把依赖拆成多个阶段安装减少失败时重新下载的成本。镜像体积过大常见原因是没有.dockerignore把数据集和 git 历史打进去了。还有如果基础镜像用的是python:3.10而不是python:3.10-slim体积会差几百 MB。做好这些优化镜像从 2GB 降到 500MB 是完全可能的。4.4 数据泄漏导致的评估虚高这个问题在前文提过但它值得单独拿出来说。我见过太多人拿着虚高的测试集准确率沾沾自喜上线后效果暴跌。防止数据泄漏的几个铁律数据划分必须在任何特征工程、归一化、降维之前完成。任何从训练集计算得到的参数均值、方差、词表、IDF 权重都要序列化保存推理阶段只加载、不重新计算。如果用 TF-IDF 或 BERT 的 Tokenizer词表的构建只能基于训练集。如果可以项目里建议把“预处理管线”整体封装成两个对象fit方法和transform方法训练集上执行fit_transform验证集/测试集上只执行transform。这样从设计上就杜绝了泄漏的可能。5. 项目经验总结与后续扩展5.1 我在实际推进中的个人体会做这个项目最大的感受就是“AI 工程的复杂度不是线性的”。你推数据清洗的时候觉得繁琐写完训练循环觉得有点成就感但真的到了部署阶段才发现前面的工作都只是热身。环境配置、性能调优、异常处理、安全防护每一件都在消耗你能量的同时逼着你建立全局意识。我想给大家的建议是千万不要跳过任何环节尤其不要跳过“服务化”和“部署”这两个看似跟算法无关的部分。我在带人做项目的时候发现很多人宁可在 Kaggle 上卷精度也不愿意把模型部署成一个别人能用的服务结果就是算法能力强、工程能力弱面试时一旦被问到“怎么做上线”就露馅。另外代码规范要从第一天就抓好。变量命名、函数拆分、日志打印、注释风格这些“表面功夫”决定了你的项目能不能被别人接手、能不能在一周后自己还能看懂。我在项目里给出的所有代码都尽量保持风格一致、注释到位就是希望大家养成好习惯。5.2 这个项目还能怎么往上扩展“ai-engineering-from-scratch”的架构做完之后扩展方向非常多这里列几个我认为最有价值的。一个是加入 MLflow 做实验跟踪把每次训练的配置、指标、模型产物都记录下来形成完整的实验矩阵避免“调参调到失去记忆”。另一个是把单机服务改成多 worker 部署用 Gunicorn 管理多进程或者用 Kubernetes 做容器编排。这一步能让你真正理解“高可用”和“水平扩展”的工程含义也跟现实工作的技术栈更贴近。还有一个是模型量化与加速比如把 PyTorch 模型转成 ONNX用 TensorRT 做推理加速或者在模型层面做剪枝和蒸馏。模型压缩是一个永远有需求的方向而且做得越深你对模型内部结构的理解就越透。最后强调一句项目里的每段代码都包含详细注释并且配套了完整的 README 文档。在原仓库的基础上你完全可以把它当作一个自己的练手项目来跑改数据、换模型、扩展模块、优化性能做成你自己的作品集项目。真正值钱的不是项目本身而是你在做项目的过程中建立的那套对 AI 工程的完整感觉。