开头就从我自己的经历切入吧。几年前我刚开始碰AI的时候，以为“ai-engineering”就是跑跑开源模型、调调参、把别人训练好的权重拿来做个demo。结果真正上手做第一个正经项目，发现自己连“工程”两个字都没摸到边——模型在笔记本上跑得好好的，一到服务器上就崩；代码能出loss，但交给别人复现不了；训练完了不知道怎么部署，好不容易部署了，一压测就内存爆炸。那时候我最大的感觉是：网上教程太多，但缺一条真正从零开始、能把AI工程全链路走通的路。所以看到“ai-engineering-from-scratch”这个标题，我第一反应是很对胃口——它不假设你有任何积累，也不把你扔进某个框架的细节里，而是把“从零开始构建AI工程能力”这件事掰开揉碎讲清楚。这篇文章我就围绕这个主题，结合我自己踩过的坑、用过的工具、总结出来的方法，聊聊一个新手要怎样一步步具备真正能落地的AI工程能力。无论你是刚转行入门的开发者，还是已经在传统软件领域干了几年想加一个AI方向，这篇内容都能给你一条相对清晰的路径。

1. AI工程先别急着学框架：先把“工程”两个字搞清楚

1.1 三种AI工程师画像，你大概率不知道自己要成为哪一种

很多人的第一反应是“今年学PyTorch，明年学TensorFlow，后年我就成AI工程师了”。这就像学建筑先买砖头一样，方向从一开始就偏了。事实是，“AI工程师”这个岗位在行业里至少能拆成三种差异很大的画像：

1. 算法/研究型工程师：主要做模型设计、论文复现、新结构探索，日常产出是实验报告和权重文件，对数据结构和数学功底要求极高。
2. 应用/落地型工程师：把现成模型接到业务里，处理数据流、写推理服务、做性能调优、管模型版本，核心考的是系统工程能力和对模型特性的理解。
3. 平台/基础设施型工程师：做训练平台、推理集群、数据管道、模型生命周期管理，本质是偏后端的AI设施建设。

“ai-engineering-from-scratch”这个标题里最关键的其实是“engineering”——它强调的不是你会不会用某个框架，而是你能不能把一个模型从数据处理开始，经过训练、评估、优化、部署、监控，最终稳定地跑在业务环境里。这个完整链路里，有一段是算法岗不太管的，也有一段是纯后端岗不太懂的，而这恰恰是AI工程师最核心的竞争壁垒。

我自己见过太多“论文读了不少但项目做不出来”的人，也见过“后端很熟但模型效果调不动”的人。他们并不是不努力，而是把精力全砸在了单点上，缺了整条链路的感觉。所以不管你最终想做哪一种，第一步都应该是先把整条链路走一遍，走通一遍之后，你才知道自己该往哪个方向深化。

1.2 AI工程和传统软件工程的三个本质差异

如果你是从传统软件开发转过来的，这三点不先想明白，后面会处处别扭。

• 数据是代码的一部分，而且往往是权重最大的一部分。传统软件里，逻辑写对了就对了；AI系统里，同样的模型，换了训练数据，表现天差地别。数据质量、分布、偏差、重复度，都直接影响最终效果，你写的代码只是系统里较小的一块。
• 性能不是靠逻辑推理能预估的。传统后端你可以通过代码复杂度估算QPS，AI工程里模型的推理速度取决于算子实现、GPU利用率、显存带宽，很多时候一个操作从CPU换到GPU，或者改变输入数据的排布方式，性能就差好几倍。这需要实测，不能靠拍脑袋。
• 系统的行为是概率性的。传统软件在相同输入下永远输出相同结果，AI模型不是。它可能偶尔犯非常愚蠢的错误，而且错误分布还会随着数据漂移而变化。这意味着你必须建立监控和回退机制，而不是上线就完事。

我把这三点放在最前面说，是因为后面所有工具、所有步骤、所有技术选择，本质上都是在围绕这三个差异做应对。理解了这个，你再去看什么PyTorch、TensorRT、Docker、K8s，就不会觉得它们是一堆碎片，而是整条链路上的一个个环节。

2. 从零开始的第一张地图：工具链、硬件与数据认知

2.1 别用“教程导向”学习，用“项目反向驱动”

市面上关于AI的学习路线浩如烟海，但绝大部分都犯同一个毛病：把学习内容按学科体系线性排列（先微积分，再线性代数，再概率论，再机器学习，再深度学习）。这套体系对科班生可以，但对一个想快速具备工程能力的人来说，学完前面五门课，热情基本消耗殆尽了。

我自己更推荐“项目反向驱动”：先定一个足够简单的端到端项目，然后沿着项目需要的东西一路补。比如你定一个“训练一个文本分类模型并通过API提供服务”的目标，那你就会发现你需要：

• Python基础（不用很深，够处理数据和调用库就行）
• PyTorch的基本张量操作和数据管道（不用懂源码，先会用）
• 数据处理的基本方法（分词、清洗、标签处理）
• 一个很简单的模型结构（能跑通原理就行）
• 训练循环里那些最基础的概念（epoch、batch、learning rate、过拟合）
• 模型保存与加载、用FastAPI写个推理接口、用curl或requests测一下

就这么一圈走下来，你可能只花了两周，但你已经完成了传统线性学习路线里需要三个月才能碰到的“实战”。更重要的是，你全程知道自己为什么学这些东西，有了“why”，学“what”就不痛苦。后面的第二、第三个项目再逐步加深，比如第二个项目加数据增强，第三个项目换Transformer结构，第四个项目部署到Docker加性能优化。这个递进过程，其实就是“ai-engineering-from-scratch”真正的展开方式。

2.2 硬件选型：不是越贵越好，而是匹配你的“学”和“做”

另一个容易被忽视的问题是硬件。很多新手一上来就纠结“我要不要买一块4090”“是不是得上A100”，其实绝大多数入门项目在消费级硬件上完全能跑。我自己从GTX 1660 SUPER开始，后来换了二手3090，中间也用过多卡服务器和云GPU，总结下来就是三句话：

• 入门学习阶段（跑跑分类、简单CNN、小规模Transformer微调）：16GB显存左右完全够，再低一点也能凑合。
• 数据量不大、模型不追求SOTA：老一代高端卡性价比最高，二手的RTX 3090或A5000非常香。
• 真要训练大模型或多轮实验：直接上云GPU，按小时计费就好，千万不要一时冲动买多卡机器，散热、电源、噪音都是坑。

在显存不够用的时候，有几个能救急的方向：使用混合精度训练、用梯度累积模拟大batch、缩小输入分辨率或序列长度、尽量加载预训练权重而不是从头训。所有这些“省显存”的技巧，本身也是一种工程能力的积累。我后面会细讲。

2.3 数据认知：模型是灶，数据是米

做AI工程越久就越认同一个观点：大部分真实项目的效果瓶颈不在模型，而在数据。模型选择的空间其实很小——任务类型定了之后，主流结构就那么几个，拼来拼去差别没那么大。但数据的差别是千倍的。

你首先要过的关就是“数据体检”。拿到一份数据，第一件事不是建模，而是做基本的统计分析：总样本量多少、类别分布是否均衡、有没有重复或近似重复的样本、文本里有没有乱码和空值、标注质量靠不靠谱、训练集和测试集是不是同一分布。这些检查在传统软件里没有对应经验——以前你处理的是有固定schema的数据库表，现在你手里的数据是脏的、乱的、不完备的。

我习惯用一个checklist来检查数据：

• 数据量是否足够支撑你选定的模型复杂度？
• 标签是否可靠？可以抽几十条人工看一眼，不要只看统计指标。
• 训练集和验证集的划分是否真的是随机？如果是按时间切分的业务数据，要特别注意概念漂移。
• 是否有大量“容易样本”把指标撑得很好看，掩盖了难样本上的失败？

这些问题在项目早期发现并处理，代价非常低；一旦做了大量实验才发现数据有问题，你前面所有结论都要推倒重来。

3. 第一个端到端AI工程闭环：从文本分类到API服务

3.1 一个值得完整走一遍的微型项目设计

很多教程讲项目都会选一个“图像分类”的例子，因为MNIST、CIFAR这类数据集太成熟、处理起来太顺滑。但我个人更推荐用“情感分析”或“有害内容识别”这类文本任务来练手，原因有两个：一是文本数据不像图像那样有天然的预处理流程，你需要自己处理分词、定长截断和padding，这个“自己动手”的过程更能锻炼数据工程能力；二是文本模型部署上线后，写一个API服务的逻辑和实际业务需求更贴近，容易迁移到你自己的场景里。

我建议你的第一个端到端项目长这样：

• 目标：对一段英文或中文评论文本做正向/负向分类。
• 模型：不要一上来就上BERT，先用一个比较简单的结构（比如词嵌入加双向LSTM/GRU），或者直接用HuggingFace里的小模型做微调。
• 训练：用PyTorch跑通训练循环，保留checkpoint。
• 部署：把训练好的模型用FastAPI包成一个POST接口，接收一段文本、返回预测类别和置信度。
• 验证：写一个客户端脚本或直接用requests发几条样本，确认线上预测和线下测试一致。

别看它小，这个小项目可以把AI工程闭环里80%的核心动作都过一遍。我下面把每一步里的关键点和坑拆开讲。

3.2 训练环节的底层心法：loss不是一切，你关注的指标才是

新手最容易犯的一个毛病是只看训练loss降不降，忽略了业务指标。比如你做文本分类，如果类别不平衡严重（比如90%是负样本），模型完全可以“无脑预测负类”把loss压得非常低，但召回几乎为零。所以从一开始，你就要确定你要优化的核心指标——是精确率、召回率、F1，还是AUC？这个决策要基于业务场景：垃圾邮件过滤更关注精确率（避免误伤正常邮件），疾病筛查更关注召回率（宁可多召回也别漏）。

在训练过程中，要同时盯住训练集和验证集的表现。如果训练loss持续下降但验证指标不涨或变差，大概率是过拟合了，常规手段是加正则化、增加数据量、做数据增强、降低模型复杂度。如果验证集指标和训练集一起卡住不动，那要考虑学习率设置、模型容量或者数据本身的分布问题。训练这个环节没有银弹，快速试错和小步迭代才是常态，你要做的是建立一套能快速验证假设的实验流程。

实验记录是这一步里最容易被忽视但又极其重要的环节。我见过很多新手跑了一周实验，最后连哪个权重文件对应哪组超参都分不清。后来我养成了习惯：每个实验都建一个目录，放配置JSON、训练日志、指标曲线图、best checkpoint，文件夹命名就是实验完成的时间加关键参数摘要。这个习惯一度我整个项目的混乱程度直线下降。

3.3 部署：真正的分水岭，很多人的AI能力死在这一步

训练完模型，你可能会觉得任务已经完成了一大半——这恰恰是最危险的错觉。从工程角度讲，模型训练只是前半程；把模型“变成产品”是后半程，而且这半程的坑远多于前半程。

首先要解决的是模型文件的工程化。用PyTorch训练完的模型，默认的.bin或.pth文件并不能直接给别人用——里面不仅有网络权重，还附着各种训练状态的额外信息。我的习惯是训练完单独导出一份推理用的状态字典，并在旁边保存一份config.json记录模型的输入格式（比如文本是否要tokenize、max_length是多少、label和id的映射关系），这样任何一个陌生人都能只靠这两个文件完成推理，而不是依赖训练代码。

然后是性能问题。第一个项目你可以直接把PyTorch模型加载进FastAPI里，推理时做一次model(inputs)就行。但稍微上点规模，你就需要考虑推理优化：

• 用model.eval()和torch.no_grad()包裹推理，去掉梯度计算，速度至少快一倍。
• 打开torch.inference_mode()，比no_grad进一步减少了开销。
• 如果有多条请求要并发，要加锁或维护一个请求队列，避免GPU上的线程安全问题。
• 考虑开启混合精度推理（FP16），显存占用直接减半，很多卡上速度还能提升。

这些优化里有些是“一行代码的事”，有些需要理解计算图的机制，它们背后的原理都是减少无关计算、降低显存开销、提升吞吐。做第一遍时可以一个个加上去并计时，慢慢感受每个优化的量级。

最后是服务封装。用FastAPI包一个接口本身很简单，但接口设计有几个容易被忽略的点：输入校验要做（文本长度限制、空值处理）、单次请求和批量请求模式都要支持（上线后你会发现批量请求的吞吐远高于循环调单条）、要有最基本的鉴权和限流机制（不然很容易被几行脚本打爆）、要记录推理日志和耗时，方便后面做监控和问题追踪。

3.4 一套可以直接“抄作业”的推理服务模板

我用下面的代码结构作为项目的起点，已经帮团队和身边朋友解决了大量部署问题。核心思路是：模型加载一次、常驻内存，每个请求只是做一次前向传播。

import time import torch from fastapi import FastAPI, HTTPException from pydantic import BaseModel # 你自己的模型加载和预处理逻辑 from my_model_utils import load_model, preprocess app = FastAPI() model = load_model() # 启动时只加载一次 class PredictRequest(BaseModel): text: str max_length: int = 128 class PredictResponse(BaseModel): label: str confidence: float cost_ms: float @app.post("/predict", response_model=PredictResponse) def predict(req: PredictRequest): start = time.time() if not req.text.strip(): raise HTTPException(status_code=400, detail="text cannot be empty") input_ids = preprocess(req.text, max_length=req.max_length) with torch.inference_mode(): logits = model(input_ids) probs = torch.softmax(logits, dim=-1)[0] pred_idx = int(torch.argmax(probs).item()) cost_ms = (time.time() - start) * 1000 return PredictResponse( label=str(pred_idx), confidence=round(float(probs[pred_idx]), 4), cost_ms=round(cost_ms, 2) )

注意几个细节：preprocess里必须和训练时的tokenizer完全一致，否则线上效果会肉眼可见地下降；不要在每个请求里重复加载tokenizer或模型文件；接口入参最好用Pydantic的BaseModel强制约束，避免脏数据直接进模型。这套模板是“能用的版本”，不是“最优的版本”，但把它跑通本身就是一次很有价值的工程训练。

4. 踩坑实录：这些高频错误我替你验证过了

4.1 第一个坑：把评价指标当摆设

我刚接触AI时做过一个信用违约预测的练习项目，用AUC作为官方指标，但我训练时每次只看准确率。准确率到了96%以为大功告成，结果一算AUC只有0.6——因为正负样本严重不平衡，模型只需要全预测成负类，准确率就能接近97%。AUC恰恰能反映排序能力，结果模型根本没学到东西。

从此之后我养成了一个习惯：训练脚本里同时输出精确率、召回率、F1、AUC，并且在验证集上做类别别评估，而不是只看一个“总体准确率”。很多实际业务场景里，少数类才是核心价值所在，而准确率这种指标在类别不平衡时完全会骗人。

4.2 第二个坑：模型版本散落一地，最后自己都找不到

早期我训练了十几个模型文件，各自命名是model_final_v2_2.pth、model_v3_final_actually.pth这种。两周后要复现某个实验结果，我对着文件名根本分不清谁是谁。后来我引入了一套非常简单的命名规范：文件夹按YYYYMMDD_HHMM_experiment_description命名，里面固定放config.json、train.log、metrics.json、best_model.pt。这个规范不用学MLflow，不用学wandb，用最笨的文件系统就能管理好个人实验。

如果你的项目已经大到多人协作，再升级到MLflow这类工具也不迟，但一开始没必要。按我的经验，80%的个人项目阶段，“文件分类加仔细写配置”就够了。

4.3 第三个坑：迷信SOTA模型，小马拉大车

很多新手喜欢从最前沿的大模型开始项目，理由是“效果好”。问题在于大模型对数据量、算力和推理资源的要求都很高。你项目只有几千条数据，上个大模型大概率过拟合到让人崩溃，指标还不如一个结构简单的小模型来得稳定。

我是这样把握模型选型的：先用一到两个baseline（结构要简单、训练要快）把数据管线和评估流程打通，再逐步替换模型结构，每换一个就记录指标变化和资源消耗。这不仅是效率问题，也是科学的实验方法论——你永远拿的是“新结构和旧结构在同一套评估流程下的对比”，而不是“新结构在一个随手写的Pipeline下的表现”。有了这个习惯，就算哪天你要换一个更大的模型，你的流程也能平滑迁移，因为数据、评估、部署这些环节早就稳定了。

4.4 第四个坑：不做推理性能评估就上线

模型指标好看，不等于上线后服务能顶住压力。我身边一位朋友做过一个OCR服务，在单张测试图片上处理时间只有40毫秒，他以为上线没问题。结果压测时发现，服务在10个并发请求下平均响应时间就飙到了2秒多，后来又发现是每张图片都要重新做图像解码和预处理，而这些代码没有做任何缓存和批次优化。

推理性能评估应该在部署之前做。我的做法是至少做三类压测：

• 单请求单张耗时：了解基线性能。
• 多并发请求吞吐：了解系统在负载下的表现。
• 连续长时间运行：观察内存和显存是否持续增长（判断有没有泄漏）。

摸清这些数据以后，再决定要做哪些优化。否则你觉得模型还有提升空间，拼命在算法上找分，真正的瓶颈可能在I/O或预处理上，这就南辕北辙了。

5. 从“能跑通”到“能造”：AI工程师的成长阶梯

5.1 学习资源的正确打开方式

这个部分我直接说结论，不铺开列一份书单。初学阶段你就盯住一条线：Python基础、NumPy/Pandas数据处理、PyTorch官方教程里的60分钟入门到分类实战、一份完整的FastAPI或Flask教程、Docker入门。这些资源在网络上到处是，不需要花钱，关键是顺序和方法。

注意一个原则：每个资源不要从头看到尾，而是看到“能动手”就停下来做个小练习。PyTorch官方教程看完“Tensor”和“Autograd”部分就可以去写训练循环了，不用把20个教程全看完。知识可以被“需要”牵引，但不要被“体系”拖住。我见过太多人收藏了几百个教程，真正的动手时间却少得可怜。

5.2 优化能力：从调用者到理解者

当项目慢慢上了规模，你会发现光会用框架不够。推理优化是几乎所有AI工程师都绕不开的进阶方向，至少要摸一遍以下内容：

• ONNX导出与ONNX Runtime：把PyTorch模型转成中间表示，推理时不再依赖PyTorch库，部署更轻量、速度通常更快。
• TensorRT加速：如果你的服务跑在NVIDIA GPU上，TensorRT能在FP16基础上再榨出一两倍的性能。它的原理是对网络结构做层融合、算子选择和显存优化，代价是转换过程比较繁琐且部分算子不支持，需要踩的坑不少。
• 量化：把模型权重从FP32降到FP16甚至INT8，精度微微受损但显存减半、推理加速。量化方法分后训练量化和量化感知训练，前者方便但精度损失可能明显。

这些工具看起来零散，本质上都是同一个思路：模型推理不等于纯PyTorch前向传播，框架只是你的起点而不是终点。你越早意识到一件事——用最少资源完成同样质量的推理也是工程能力的直接体现——就越能理解为什么这个岗位叫AI工程师，而不是AI算法员。

5.3 跟上时代：大模型时代的AI工程新变数

接口式的AI能力（比如调LLM API）出现以后，很多人的第一反应是“传统AI工程是不是要没了”。恰恰相反，LLM涌现以后，AI工程的需求不是变少了，而是变多了、变复杂了。模型本身的训练门槛变高了，但对模型的调用、编排、评测、数据构造、RAG（检索增强生成）、提示词优化、幻觉治理、合规审计，全都变成了新的工程任务。

我的体会是：以前一个AI工程师的核心交付是一个“模型加一套服务”，现在更多时候是“一个系统”——数据管道负责持续供给高质量语境、模型处理负责理解生成、检索模块负责引用外部知识、反馈闭环负责持续纠偏。这套系统里的工程问题远多于模型训练问题。好消息是，你从“ai-engineering-from-scratch”里练出来的那套端到端能力——数据认知、实验管理、部署优化、监控评估——在新的范式下依然全部成立，而且更吃香。

5.4 最后的建议：给自己建一条“成长反馈回路”

按我的经验，学习AI工程最容易半途而废的时刻，是你发现自己看教程的时候什么都懂，但一到自己写项目就卡住。这个体验非常正常，根本不是能力问题，而是你缺一个“既在你能力边界附近、又足够具体”的实践课题。

我的建议是给自己建一条反馈回路：认领一个你真正关心的小问题（比如“帮我自动分类我的邮件”“预测一下我所在城市明天会不会下雨”），然后走完从数据到部署的全流程。每做完一次，记录成功经验和新发现的盲区，再在下一个项目里刻意补上盲区。这样成长的速度，比任何课程都有效。

从零开始做AI工程，最不缺的就是资料和教程，最缺的其实是“自己完整走一遍链路”的勇气与行动力。只要你愿意把第一个小项目从数据一路做到API上线，后面的路都会越来越顺。

我的建议是别一上来就买一堆课和书。找一份结构清楚的数据集，写一个简单模型，训练完用一个最小的接口把它暴露出去，然后看着它真实地跑起来。这一小步，就是整个AI工程之旅里最重要的一步。