AI工程从零到落地：环境、数据、训练、部署与监控完整指南

这两年“AI工程师”这个title是越来越多了但说句实在话很多人挂在简历上的“AI工程能力”其实就是调调现成的API、跑跑开源的notebook。真要自己从零搭一套数据管线、训练一个模型、再把它部署成别人能用的服务中间隔着的东西可不止一个“pip install”。这个“ai-engineering-from-scratch”的项目标题说白了就是一条把AI从“能跑通”推到“能落地”的完整路径。这篇文章我不打算给你列一堆视频课链接而是直接拆解一个AI工程师从零起步必须趟过的那些核心环节环境怎么搭、数据怎么管、模型怎么训、服务怎么发、线上怎么维护。每一块我都结合自己实际踩过的坑来讲适合那种已经会写Python、但对AI工程全流程还没有完整认知的人也适合想系统梳理自己知识盲区的初级算法工程师。1. 内容整体设计与思路拆解1.1 AI工程不等于“调模型”很多人一开始理解AI工程以为就是把模型训练出来就完事了。但这个理解在真实业务里是行不通的。AI工程的全链路其实很长业务问题定义、数据采集与清洗、特征工程、模型训练与调优、模型评估、服务化部署、线上监控与迭代每一环都有独立的工程难题。哪怕你训练了一个准确率99%的模型如果没办法稳定地跑在线上环境、没办法处理数据分布漂移、没办法在流量高峰期保持低延迟那这个模型的价值就等于零。我见过太多团队把精力都花在“刷榜”上结果模型在离线测试集上表现很好上线之后被线上真实数据教做人。原因很简单离线测试集是静态的线上数据是动态的。用户行为在变环境在变数据分布就在变。没有工程化思维的人第一步就会错判重点。所以从零开始的AI工程第一课不是学某个框架怎么用而是建立“全链路闭环”的意识。你敲下的每一行代码都应该是在为“模型能稳定创造价值”这件事服务而不是为了让自己感觉在“做AI”。1.2 为什么“从零开始”必须强调系统化市面上不缺AI入门资料但绝大多数是碎片化的今天学个Transformer结构明天学个模型压缩技巧后天又去研究某个部署框架的API。这种碎片化学习最大的问题在于——知识之间没有形成网络。你学了一堆名词但不知道它们在实际项目中是怎么串联起来的。“ai-engineering-from-scratch”这个项目的核心价值就在于它按工程项目推进的顺序来组织知识。先解决环境问题再解决数据问题然后是模型问题最后是系统问题。每解决一个问题你手里的工具就多一件。这个过程不像看教程那么轻松但走完一遍之后你会发现自己具备了一种能力拿到任何一个AI需求脑子里能自动浮现出一个工程路径图。这种能力才配叫AI工程能力。1.3 这个路径适合谁走我把话说直接一点如果你是那种“调包侠”心态遇到问题第一反应是百度报错信息然后照抄Stack Overflow那这条路径对你会比较辛苦但恰恰是你最需要的。因为从零搭建工程体系的过程逼着你理解每一层发生了什么。相反如果你已经带过项目、部署过服务这篇文章里的很多内容你会觉得熟悉但其中一些细节和避坑经验还是值得一看。适合的人群再具体一点计算机相关专业、会基本的Python语法和Linux操作、对机器学习概念有模糊认知但没完整做过项目或者在职的Java/Python后端想转AI方向。这些人都能通过这条路径建立实战能力。但我不建议完全零编程基础的人直接上手先花两周把Python基础补上再来效率会高得多。2. 环境与工具链的硬核搭建2.1 Python环境管理的“脏乱差”难题任何一个从零开始的AI工程项目第一步永远是环境。但就是这个看似简单的第一步能劝退一半的人。我见过太多人的电脑里Anaconda、Miniconda、virtualenv、pyenv混着用Python 3.7到3.11装了好几个版本最后自己都搞不清当前用的是哪个解释器。这种混乱的根源在于不知道环境隔离是为什么服务的。Python的包管理工具本身比较“奔放”不同项目对包版本的要求经常冲突A项目需要numpy 1.21B项目可能就需要numpy 1.24。如果不做隔离你就是在拿自己的项目做赌注。我的建议非常明确不要直接用系统Python统一用Miniconda做环境管理。Conda不仅管Python版本还能管CUDA、cuDNN这类深度学习依赖这个特性在AI工程里极其省心。2.2 GPU环境的“一次性配好”方案深度学习训练离不开GPU但GPU环境的配置堪称“劝退之王”。CUDA版本、cuDNN版本、PyTorch或TensorFlow版本的匹配关系稍有偏差就报错。基于我的经验新手最稳妥的方案是先确定你要用的深度学习框架版本再倒推CUDA版本最后安装对应的显卡驱动。比如你决定用PyTorch 2.1它对应CUDA 12.1那你就把CUDA Toolkit装到12.1驱动版本不低于530即可。顺序反了后面就有你折腾的。如果你没有本地GPU云服务是更理性的选择。我不建议新手一开始就买GPU服务器因为利用率太低。先用Google Colab的免费GPU跑通流程或者用云厂商的按量付费GPU实例熟悉了再考虑长期租用。顺便提一句很多云平台的GPU实例文档写得比较抽象申请之前先确认有没有你需要的镜像和机型别等开通了才发现驱动不对、镜像不对钱花得冤枉。2.3 项目结构从第一周就规范化环境问题解决之后紧接着就是项目目录结构的问题。很多从零开始的人压根不在乎目录怎么组织全都堆在一个文件夹里训练脚本、数据文件、临时测试代码混在一起。三个月后回来看自己都找不到之前的实验配置。这里我分享一个经过多个项目验证的目录模板特别适合中小型AI项目project/ ├── configs/ # 所有配置文件yaml或json ├── data/ # 原始数据与处理后数据通常git忽略 ├── notebooks/ # 探索性分析的Jupyter笔记本 ├── src/ # 核心代码 │ ├── data/ # 数据加载与预处理 │ ├── models/ # 模型定义 │ ├── train.py # 训练脚本 │ ├── evaluate.py # 评估脚本 │ └── predict.py # 推理脚本 ├── tests/ # 单元测试 ├── scripts/ # 辅助脚本 ├── outputs/ # 实验输出 └── requirements.txt这个结构的好处是每个东西都有固定的去处新人接手项目时不需要问“这个文件放哪”。尤其是configs目录它对AI项目极其重要因为AI项目本质上是实验驱动的参数配置一变就是一次新实验。把所有参数放到配置文件里用命令行参数覆盖这样每次实验都能被完整回溯。我个人见过太多“跑完就忘参数”的悲剧了。3. 机器学习核心概念与最小实战闭环3.1 用“房价预测”理解全部核心概念环境搭好了目录建好了接下来就是实打实的机器学习环节。很多人一上来就啃《统计学习方法》公式推导了一堆结果写代码的时候依然不知道从哪下手。我建议换一种路径先选一个极小的数据集完整跑通一个机器学习流程把概念和代码对应起来。我经常用的例子是波士顿房价预测虽然这个数据集存在争议但作为教学材料是真的好。整个流程其实可以拆成六个动作加载数据、数据清洗与特征工程、划分训练集和测试集、选择模型、训练、评估。就这六步里面的门道极多。比如划分训练集和测试集看起来就是一行sklearn.model_selection.train_test_split的事但随机种子多少、是否分层采样、数据有没有泄漏都会直接影响你对模型能力的判断。我见过有人划分数据时不打乱顺序结果训练集全是前半段、测试集全是后半段模型上线后表现一塌糊涂。这不是段子是真实事故。3.2 从“调包”到“懂原理”手写一个线性回归为了弄懂机器学习模型内部的机制我强烈建议你手写一次线性回归。别觉得这是“重复造轮子”这个过程的收益远超你的预期。在PyTorch或NumPy里实现一个线性回归核心代码其实不到三十行。我用PyTorch的手写版本给你演示一下核心训练循环这才是AI工程师的基本功import torch # 造一点带噪声的线性数据 x torch.linspace(0, 10, 100).reshape(-1, 1) y 3 * x 2 torch.randn(x.size()) * 0.5 # 初始化模型参数 w torch.randn(1, requires_gradTrue) b torch.zeros(1, requires_gradTrue) learning_rate 0.01 for epoch in range(1000): # 前向传播 y_pred x * w b # 计算损失均方误差 loss torch.mean((y_pred - y) ** 2) # 反向传播 loss.backward() with torch.no_grad(): w - learning_rate * w.grad b - learning_rate * b.grad w.grad.zero_() b.grad.zero_() if epoch % 100 0: print(fepoch {epoch}, loss {loss.item():.4f})你亲手敲一遍这段代码看着loss从几十降到零点几参数w向3靠近、b向2靠近你才算真正理解了“训练”的本质——它不是什么神秘魔法就是通过梯度下降不断调整参数使损失变小。这个认知比你背十遍反向传播公式都管用。很多新手在学深度学习框架时直接用高层API做线性回归几行代码就出结果了但这样除了学会API调用什么也没理解。手写一次你就对框架帮你做的事有了具象认知。3.3 特征工程的底层逻辑和实操技巧模型瓶颈很多时候不在算法而在特征。特征工程这件事听起来很“传统”但在深度学习时代依然是AI工程师的核心竞争力。我举一个简单例子假设你在做用户购买预测原始的“注册天数”特征可能和转化率不成线性关系但如果把它做成分箱特征比如30天内、90天内、一年以上模型就可能发现不同用户群体之间存在明显差异。这就是特征工程的“人肉搜索”环节基于业务理解去构造更有表达能力的特征。实操中我的建议是遵循一个顺序先做数据清洗处理缺失值和异常值再做基础特征包括数值归一化和类别编码最后才做组合特征和业务特征。别一上来就搞复杂特征交叉先跑一个baseline模型再逐步加特征用模型效果来验证每个特征的贡献。这种方式一方面避免你在无用特征上浪费时间另一方面也让你对每个特征的实际效果有清晰的认知。记住一个原则加特征容易删特征难一开始就用简单特征打底。4. 深度学习的模型训练与迭代路径4.1 PyTorch vs TensorFlow的选型逻辑当你决定进入深度学习阶段第一个绕不开的选择就是框架。TensorFlow和PyTorch之争吵了很多年但现在答案已经非常明确了PyTorch是学术界事实标准而且随着TorchServe和TorchScript的成熟它在工业界的份额也追了上来。对于从零开始学AI工程的人我建议直接选择PyTorch没有纠结的必要。原因主要有几个维度第一PyTorch的调试体验远好于TensorFlow因为它的执行方式是动态图你可以用Python原生的print和pdb去调试模型中间结果不用像TensorFlow那样处理图上下文第二最新的模型和论文源码几乎都是PyTorch写的你学习、复现、改造的成本最低第三HuggingFace Transformers生态对PyTorch支持最好而NLP领域你基本绕不开HuggingFace。TensorFlow现在最大的存量优势在移动端和部分生产环境但不是你该首要考虑的。4.2 训练脚本的“工程化骨架”很多教程里给的训练代码都是单文件、单轮跑完就结束的demo版本。真实项目里完全不是这样。一个工程化的训练脚本至少要满足几个要求支持随时断点续训、支持实验参数配置化、有详细的日志和指标记录。我每次写新项目的训练脚本都会套用同一个骨架核心结构如下import argparse import yaml import torch def load_config(): parser argparse.ArgumentParser() parser.add_argument(--config, typestr, requiredTrue) return yaml.safe_load(open(parser.parse_args().config)) def train_one_epoch(model, dataloader, optimizer, criterion): model.train() total_loss 0 for batch in dataloader: optimizer.zero_grad() outputs model(batch[input]) loss criterion(outputs, batch[label]) loss.backward() optimizer.step() total_loss loss.item() return total_loss / len(dataloader) def validate(model, dataloader, criterion): model.eval() total_loss 0 with torch.no_grad(): for batch in dataloader: outputs model(batch[input]) loss criterion(outputs, batch[label]) total_loss loss.item() return total_loss / len(dataloader)关键点在于这三个设计配置和代码分离、每一轮epoch都做验证、模型在训练和评估之间正确切换。这些看起来稀疏平常但每一个都是在真实项目里用“线上事故”换来的经验。比如model.train()和model.eval()的切换新手经常忘记导致BatchNorm和Dropout在验证时做了错误的行为指标就虚高了。这种细节文档不会强调但直接影响最终质量。4.3 模型调优的“实验管理”意识模型训练一旦开始你很快就会面临一个新问题迭代次数多了实验记录就乱了。这批跑了A参数那批跑了B参数哪个效果最好当时用的数据版本是哪个学习率调整过几次如果没做管理你会发现自己陷入“实验泥潭”。我的习惯是给每个实验一个独立目录用一个命名规则把关键信息编码进去比如resnet50_lr1e3_bs128_aug_v2。同时建议用一个Excel或Google Sheets做实验登记表记录实验编号、配置摘要、关键指标、数据版本、代码commit号。虽然很多团队已经上了Weights Biases或MLflow这类专业工具但对于从零起步的个体来说从手动登记开始建立的纪律意识比工具本身更重要。等你的实验量级上来了再引入MLflow做自动跟踪也不迟。先形成习惯再升级工具。4.4 过拟合与欠拟合的判断和应对训练过程中你迟早会遇到一个现象训练集上的loss不断下降但验证集上的loss卡住不动甚至开始上升这就是过拟合。很多人第一反应是加正则化、加Dropout但我想说这些操作要慎重因为它们只是“压制”症状没有解决问题的根源。最有效的办法按优先级排序是增加数据量和数据增强、降低模型复杂度、然后才是正则化。欠拟合相对少见一点主要表现为训练集和验证集的loss都很高且降不下去这时候优先考虑的是模型表达能力不足或学习率设置不当。我见过一个典型案例训练loss一直在3.5附近震荡折腾了两天后来发现是学习率设得太大loss在最优值附近来回跳过降不下去。把学习率从0.1调到0.01之后loss很快就下来了。所以遇到指标异常先别慌着改模型结构先用最朴素的手段排查学习率、数据预处理、损失函数、梯度检查一层层上来。5. 从模型到系统的工程化落地5.1 模型部署的三条路线对比模型在离线环境里表现良好这只是一半的路。真正考验AI工程能力的是把模型变成线上服务。行业中主流的部署方式有三条路线各自适用场景完全不同我在部署项目里都试过这里给你做个横向对比。第一条是Docker加FastAPI封装这是最通用、上手最快的方案。把模型加载到内存中用FastAPI暴露一个HTTP接口配合Gunicorn做多进程管理。优点是灵活、生态成熟、调参空间大缺点是需要自己处理负载均衡、弹性伸缩、GPU资源调度这些底层问题。第二条是TorchServe它是PyTorch官方推出的模型服务框架。优势在于原生集成、支持模型版本管理、内置推理API适合PyTorch生态的单模型部署。但它的灵活性和社区规模不如第一条方案遇到问题排查资料相对少。第三条是用云厂商的托管推理服务把模型打包上传平台自动处理伸缩和监控比如阿里云的PAI-EAS或AWS SageMaker。优势是省心缺点是费用高、和平台绑定深换平台成本很大。我的推荐很务实个人项目和小型团队直接用第一条路先跑通再优化模型形态复杂、需要高并发时再引入专门的服务框架预算充足且对数据合规无强要求的企业才考虑托管服务。5.2 FastAPI部署一封完整的示例我不打算讲太多理论直接给你一份能用的部署代码骨架。这是我在多个项目里验证过的模式结构清晰、容易扩展from fastapi import FastAPI, HTTPException from pydantic import BaseModel import torch import joblib app FastAPI() # 全局加载模型避免每次请求重复加载 model torch.jit.load(model.pt) model.eval() preprocessor joblib.load(preprocessor.pkl) class PredictRequest(BaseModel): features: list class PredictResponse(BaseModel): prediction: float app.post(/predict, response_modelPredictResponse) def predict(req: PredictRequest): try: processed preprocessor.transform([req.features]) with torch.no_grad(): tensor torch.tensor(processed, dtypetorch.float32) result model(tensor).item() return PredictResponse(predictionresult) except Exception as e: raise HTTPException(status_code500, detailstr(e)) app.get(/health) def health_check(): return {status: alive}几个细节值得你注意第一模型一定要在服务启动时一次性加载到全局变量千万不能在请求函数里加载否则每个请求都会慢几十倍第二输入和输出的数据结构用Pydantic定义FastAPI自动帮你做参数校验和文档生成第三健康检查接口不是摆设上云之后负载均衡器靠它判断实例存活性没有这个接口你的实例可能被误判为宕机。5.3 性能瓶颈排查与优化方法服务部署好之后性能问题就浮现出来了。最经典的一个问题单次推理只要10毫秒但整个请求链路要200毫秒为什么答案往往是序列化、网络传输、数据预处理拖慢了整体。排查性能问题我的方法论很简单链路打点。从请求进入到响应返回每个环节都记录耗时不要靠猜。具体工具层面先用Python的time模块或者cProfile做粗粒度分析定位到热函数之后再看是CPU密集还是IO密集。如果是CPU密集考虑批量推理把多个请求打包成一个batch利用GPU并行能力把吞吐量提上去如果是IO密集则重点优化数据加载和预处理管线。还有一个常见的低级问题模型在CPU和GPU上的推理性能差异巨大但服务里部署到了CPU上推理延迟比训练时高几十倍。上线之前务必确认推理设备是不是你预期的那一个。5.4 模型评估不止于准确率离线评估阶段准确率很高不代表上线后业务指标就优秀。这里必须引入更多维度的评估视角。首先是性能维度AUC、F1、召回率、精确率这些指标要根据业务场景取舍。比如欺诈检测漏掉一笔欺诈交易比多拦截一笔正常交易代价更大那就应该更关注召回率而非精确率。其次是延迟和吞吐量P99延迟是核心指标尤其是面向C端用户的服务99%的请求必须在几百毫秒内返回。如果P99非常高说明系统偶尔存在严重卡顿但平均值看着还行这种情况就是典型的“被平均掩盖的灾难”。最后是数据分布上线后需要监控线上数据分布是否和训练时一致一旦漂移明显模型表现大概率会下滑这就触发重训流程。6. 常见问题与排查技巧实录6.1 数据加载慢到难以忍受训练时的数据加载是第一个大坑。你可能模型结构写好了训练代码也没问题但跑起来之后GPU利用率一直在20%以下训练一天都出不了几个epoch。这就是IO瓶颈。原因通常是数据在CPU侧加载、预处理和增强太耗时GPU一直在空等。很多没有工程经验的人看不懂GPU利用率的含义以为训练慢是模型问题调了半天结构发现没用。解法有实用的一套组合拳用DataLoader的num_workers参数开启多进程预加载一般设为CPU核数的一半pin_memoryTrue可以加速数据从CPU到GPU的拷贝有条件就上albumentations这种高性能预处理库或者把数据先缓存成内存友好的格式比如LMDB、TFRecord避免每次迭代都做磁盘随机读。我实测下来单是优化数据管线这一项就能让训练速度提升3到5倍。6.2 训练Loss变成NaN的排查思路NaNNot a Number是训练过程中最让人头疼的问题之一。损失突然变成NaN之后模型参数基本上也就废了只能重新开始。排查NaN我的固定顺序是先缩小学习率八成的问题在这一步就能解决。学习率过大会导致梯度爆炸权重更新幅度太大数值计算溢出。如果缩小学习率没用再检查数据里是不是有NaN值或异常值——数据里有NaN不奇怪但很多损失函数对NaN完全没有抵抗力一个NaN传染整片梯度。再往后是检查模型结构有没有不稳定的操作比如除零、对数零。如果用了混合精度训练还要检查梯度缩放相关的设置。最后放大招在反向传播之前打印每一层的梯度手动定位哪一层梯度异常。用这套流程排查绝大多数NaN问题都能在半小时内定位。6.3 模型服务的内存泄漏问题服务上线跑一段时间内存占用缓慢上升最后导致OOM被系统杀掉。这个现象常见原因有三个一是在请求处理中创建了不需要长期持有的对象没有释放二是PyTorch的推理图缓存导致内存攀升特别是动态图模式下反复构造计算图三是全局变量被意外修改导致引用不断增加。针对PyTorch服务我的经验是用torch.no_grad()包住推理过程避免构建计算图同时用torch.jit把模型序列化成脚本模式减少动态图开销。对了还有一个低级又常见的问题日志打印太多logger没有设置上限庞大的日志对象占用内存这种问题用memory_profiler测一下就能发现。6.4 线上效果与离线不一致怎么办这是所有AI项目里最容易引起团队恐慌的问题。离线测试结果明明很好上线之后业务指标就是不行。这种现象的根因九成都在“训练数据和线上数据分布不一致”上。说到底就是数据时效性线下用的是三个月的旧数据线上的用户行为已经变了或者是采样方式不同线下是均衡采样线上是真实分布模型没见过真实分布的样本组合。面对这个问题首先要冷静下来对比线上输入特征和训练集特征的分布用KS检验或PSI指标量化漂移程度。确认漂移存在之后解决方案就是重新采样数据、缩短训练周期、加入在线学习机制。如果重新训练之后仍然无法解决那就要考虑特征体系本身是否过时了。7. 学习路径规划与实战项目建议7.1 用“三阶段”规划六个月的从零路线很多想学AI工程的人都折在同一个地方没有学习路径东一榔头西一棒子。我给一个实操性很强的六个月三阶段规划你在任何培训机构都拿不到这种具体的进度安排。第一阶段第1到2个月是基础能力期目标是“能读、能写、能跑”掌握Python科学计算库NumPy和Pandas、学会SQL基本操作、完成一个完整的机器学习小项目比如Kaggle的Titanic或房价预测。注意这个阶段的关键不是学多少模型而是习惯“数据—模型—评估”的完整循环。第二阶段第3到4个月是深度学习入门期目标是“能训、能调、能优化”学PyTorch基础复现一个图像分类模型或文本分类模型学会用GPU训练掌握学习率调整、正则化、早停这些训练技巧。第三阶段第5到6个月是工程落地期目标是“能部署、能监控、能迭代”把第二阶段训练的模型用FastAPI部署成服务加入Docker容器化做一个完整的监控方案最后用Grafana展示模型指标。走到第三阶段结束时你手里就有一个从训练到上线的完整项目了。7.2 三个适合练手的实战项目理论说再多都不如亲手做一个项目来得实在。我推荐三个不同侧面、难度递进的项目每一个都能逼着你把工程能力练出来。第一个项目是“电影评论情感分析API”用IMDb或中文影评数据集训练一个文本分类模型然后部署成HTTP接口让用户提交评论就能返回情感标签。这个项目覆盖了NLP的完整链路和数据预处理、文本向量化、模型部署难度适中非常适合作为第一个完整作品。第二个项目是“图片分类服务的自动伸缩”用CIFAR-10训练一个图像分类模型部署到云服务器上然后模拟并发请求测试系统的吞吐量和延迟观察它在高并发下崩溃的形态和原因。这个项目逼你去思考性能、扩展性这些工程问题而不是只关注模型结构本身。第三个项目是“自建推荐系统的AB测试框架”用一个公开的电商数据集做召回和排序设计两套算法方案搭一个简化的AB测试分流服务统计两个方案的点击率差异。这个项目偏业务和数据决策做完之后你对推荐系统全链路和“模型上线不只是技术问题”这句话会有深刻体会。7.3 学习中的“时间黑洞”与避坑策略自学的最大敌人不是难度而是时间黑洞。我自己学习过程中浪费过大量时间的几个坑在这里给你排掉。第一个黑洞是“收藏夹吃灰”今天收藏一个教程明天保存一篇文章资料越攒越多但真正动手的时间几乎没有。破法很简单每次收藏资料的时候问自己一句“这周能不能花两小时把它跑一遍”不能就删掉。第二个黑洞是“死磕底层原理”遇到一个概念不懂就花三天去啃数学推导结果整个学习节奏被打破。我的建议是80/20法则80%的概念只要有个直觉理解就够了真正需要死磕的是那些反复阻碍你的问题。第三个黑洞是“重复造轮子成瘾”明明sklearn有现成的实现非要自己手写一遍。手写模型用来理解原理是必要的但如果所有东西都要自己实现那你不是在学工程你是在做学术研究。8. 写在后面的几条实在建议项目做完整条链路之后我对AI工程这件事有了和当初完全不一样的体会。最大的感受是AI工程的核心矛盾从来不是“模型不够聪明”而是“把聪明模型放进真实世界之后它变得不再聪明”。数据会变环境会变业务会变你的系统必须跟着变。还有一点想强调工程化的本质不是堆工具而是建立确定性。什么是确定性就是任何一个人拿到你的项目按照README里的步骤能跑起来任何一次实验都能回溯到对应的代码和数据任何一次线上故障都有日志和监控可以定位。工具只是手段这些才是AI工程师真正要修炼的内功。如果你真的决定走这条路那就从今天开始动手不用等把所有理论都学完再动手先搭一个最简陋的环境跑一个最基础的模型把它部署成服务然后在迭代中一点一点补足知识。这个过程会遇到很多问题、很多挫败但每一次把问题解决掉之后你对AI工程的理解都会上一个台阶。这条路值得走。