上个月有个读者私信我说自己学了三个月的机器学习理论Sklearn 里的模型能默写出来但真让他把一个小模型部署成服务给同事用直接就卡住了——环境装不明白、数据管道不完整、代码一跑就报错。他问我“AI 工程从零开始到底该怎么学”这个问题其实问到了点子上。太多人把“AI 工程”等同于“会调模型”但真正做过 ai-engineering 的人都知道从零到一最难的不是算法原理而是把算法变成稳定、可维护、可交付的软件系统。这篇东西就是写给那些想认真走 from scratch 路线的人我会把这个领域拆成几块告诉你怎么安排学习顺序、第一个项目该怎么做、模型上线之后又会碰到什么问题。1. 先搞懂一件事AI 工程拼的不是算法是工程心智1.1 算法实验和工程交付根本是两种游戏在实验室里跑一个 notebook和在一个生产环境里跑一条推理服务看起来都是“跑模型”但背后的思维完全不同。做实验的时候你关心的是“这个模型在测试集上有没有涨点”做工程的时候你关心的是“这个模型在没人盯着的情况下能不能稳定跑一个月”。我给你一个特别典型的例子。很多人在 Jupyter 里训练出来的模型准确率是 95%一放到线上就跌到 60% 甚至更低。这不是玄学而是训练环境和推理环境之间出现了断层。实验环境里你用的是清洗好的离线数据线上来的却是带着缺失值、异常值、甚至字段名都变了的真实请求。模型本身没问题问题是周围的工程系统没有兜住这些变化。所以把“AI 工程”拆开来看算法只是中间一小块。外围还有数据管道、特征存储、模型部署、监控告警、版本回滚这一整套东西。初次接触的人容易低估外围总觉得“先把模型跑通再说”。但恰恰是这些外围工程能力决定了你能不能从“会做实验”过渡到“能交付系统”。1.2 工程心智的三个关键词可复现、可观测、可回滚我在带新人的时候会反复强调六个字可复现、可观测、可回滚。这三件事几乎可以概括 AI 工程和纯算法实验的所有区别。可复现的意思是任何一次实验换一台机器、换一个人只要拿着同样的代码、同样的数据、同样的依赖版本就能得到同样的结果。这一点做到其实不容易因为 Python 的包依赖实在太容易出问题。我见过太多“在我电脑上是好的”这种翻车现场。解法也很朴素从第一天就用虚拟环境最好再加 Docker 把整个运行环境固化下来。可观测的意思是模型上线之后你不是把它扔在那里就不管了。请求量、响应时间、预测分布、错误率这些指标都要有地方看。没有观测模型哪天悄悄退化了你都不知道等业务方来投诉才后知后觉。可回滚的意思是只要新模型上线后表现不好你得能在几分钟内切回旧版本。很多人以为模型上线就是终点其实上线只是起点。后面的每一次更新都意味着一次潜在的回滚操作。后面我会专门讲这块怎么做。2. 从零到一的路线图五块基石按什么顺序打才不慌2.1 别一上来就啃 Transformer先把硬功夫铺平很多人问我要学习路线我给的顺序和市面上大部分课程都不太一样。市面上的课喜欢从机器学习算法讲起线性回归、决策树、神经网络一路讲下去。我的建议是反过来先解决“干活”的问题再解决“懂原理”的问题。我推荐的顺序是这样学习模块核心内容最小够用标准学习方式Python 工程基础函数、类、装饰器、文件读写、异常处理能写一个结构清晰的模块而不只是脚本配合项目边做边补Linux 与命令行文件操作、进程管理、环境变量能在服务器上独立部署服务跟着教程敲命令Git 与版本管理分支、commit、merge、冲突解决能管理自己的代码仓库不乱掉边写代码边用数据处理pandas、SQL、数据可视化能独立完成清洗、聚合、统计用真实数据练手机器学习工程sklearn、模型训练、评估、序列化能离线完成训练并导出模型文件小项目反复练习你会发现这个排序里没有“深度学习”也没有“Transformer”。我的观点是如果你连 pandas 都玩不转连服务器都登不上去那你学再深的模型也没地方施展。AI 工程的第一步不是模型是“能把模型装进去的那个壳子”。2.2 每一块知识学到“够用”就往下走有一个词叫“学完再干”陷阱。很多人总觉得基础没打好不敢动手结果基础永远打不完。我建议每一块都定一个“最小够用”的线过了线就去做项目项目里缺什么再回头补。比如 Python你不需要把装饰器、元类、协程全部吃透但函数、类、列表推导式、字典操作这些必须非常熟。再比如 Linux不需要会写复杂的 shell 脚本但 cd、ls、vim、grep、ps、kill 这些高频命令要形成肌肉记忆。正则表达式可以现查但文件路径和日志定位这种基本功不行。这里我想特别强调一个反直觉的点很多人以为 Python 很简单学两天就会。但 Python 写脚本和 Python 写工程是两码事。工程代码要考虑模块划分、异常处理、日志记录、配置管理。我建议你在第一个项目里就有意识地用包结构来组织代码而不是把所有内容塞进一个 main.py。2.3 Git 和 Linux 为什么要前置它们是工程的“空气”我在这个阶段最想按下停止键的是那些整天刷算法题却不碰 Git 的人。对一个现代 AI 工程师来说Git 不是可选项是空气。你的代码要版本化你的模型要版本化你的实验记录最好也版本化。没有版本管理你做的每一次调参都可能把之前的好结果覆盖掉等你想回头就已经来不及了。Linux 同样重要。训练模型这件事本地能跑通小样本不代表能做正经训练正经训练早晚要上服务器。而现实的服务器环境大多是 Linux 命令行界面没有图形界面给你点。你会不会用 vim 改配置会不会用 nvidia-smi 看显存这些直接决定了你搬砖的效率。我自己带项目的经验是前两周会刻意让新人去完成一些“非模型”任务——比如写一个脚本定时备份数据集、把训练日志接到监控平台、给代码仓库写规范的 README。这些任务看似和目标无关但很快就成了整个项目的地基。3. 第一个端到端项目从原始数据到能调用的 API3.1 项目选题的原则别做“猫狗识别”做一个业务问题学 AI 工程的人特别容易一上来就选一个“网红”项目比如猫狗分类、手写数字识别。这类项目最大的问题是数据已经清洗好、任务已经定义好、网上教程一大把你做完了只是为了证明“我调通过一个模型”对工程能力的提升非常有限。我强烈建议你选一个有“业务味”的项目。比如给客服工单打标签、预测某个用户会不会流失、给新闻文章做分类。这类项目的数据没那么干净输入输出也没有那么标准你需要自己去处理数据、定义标签、设计评估方式——这才是真实 AI 工程的样子。我当时给初学者推荐最多的一个项目是“工单自动分类”你有几千条客服工单文本每一条需要分成“退款”“维修”“投诉”“咨询”等类别。这个项目麻雀虽小五脏俱全有文本数据要清洗有类别不均衡要处理有模型要训练最后还要做一个接口把模型暴露出去。3.2 数据处理这块会吃掉你 80% 的时间选好项目之后第一件事不是建模而是把数据彻底摸明白。我一般会先跑一个 describe 看看字段分布再检查缺失值比例最后把标签的分布打印出来。这三个步骤看起来基础但能避免后面一大堆麻烦。以工单分类为例数据里常见的脏点有三个空文本用户忘了写字、重复工单同一问题被多次提交、类别严重不均衡“咨询”类占了 80%。“咨询”占大头会导致模型学成一个偷懒的分类器全预测成“咨询”也能拿到不错的准确率。处理的办法也不复杂。空文本直接剔除重复内容去重类别不均衡的可以用分层抽样保证训练集和验证集里的分布一致或者对少数类做简单的过采样。这些操作都不需要多高深的技术但你在做是否保留、是否合并的决定时已经开始体现工程判断力了。import pandas as pd from sklearn.model_selection import train_test_split df pd.read_csv(tickets.csv) # 去掉空文本 df df[df[content].notna() (df[content].str.strip() ! )] # 去重 df df.drop_duplicates(subset[content, label]) # 分层划分 train_df, test_df train_test_split( df, test_size0.2, stratifydf[label], random_state42, )你注意我加了random_state42。这个参数很小但极其重要。没有固定随机种子每次划分结果不一样实验就不可复现了。这就是前面说的工程心智在数据环节的体现。3.3 训练和评估先跑 Baseline再谈涨点数据准备好之后很多人会迫不及待地上 BERT、上深度学习。我的建议是先忍住用最简单的模型打一个 Baseline。对文本分类来说先用 TF-IDF 加逻辑回归跑一遍把评估指标记下来。这个 Baseline 不一定是最好的结果但它给你一个参照物。后面不管上什么模型都要跟这个数字比否则你不知道新模型的提升是真实的还是只是运气好。我是习惯把评估指标从单一准确率扩展到几个维度。类别不均衡的数据集里准确率会骗人。更要看的是每个类别的精确率、召回率和 F1 值尤其是少数类。一个只预测“咨询”的模型准确率可能高达 80%但它在“退款”这个业务场景上的召回率是 0等于完全不可用。到这一步你的项目已经完成了数据清洗、Baseline 建模、指标体系搭建这三件事。第一次做的时候这些过程足够让你把 pandas、sklearn 用熟了。3.4 把模型包装成 API让代码第一次变成别人能用的工具模型训练完model.joblib文件也导出来了接下来就是整个项目里最能体现“工程”二字的动作把它包成一个 API。这一步做完了你就不再是“训练了一个模型”的人而是“交付了一个服务”的人。我习惯用 FastAPI 来做这件事。选择它最大的原因是轻量且自带文档不用写一行前端代码就有交互页面。下面的代码是一个最小可用的推理接口import joblib from fastapi import FastAPI from pydantic import BaseModel, Field import pandas as pd app FastAPI() model joblib.load(model.joblib) classes [咨询, 退款, 维修, 投诉] class Ticket(BaseModel): content: str Field(..., min_length1, description工单文本内容) app.post(/predict) def predict(ticket: Ticket): # 注意真实项目中这里一定会有与训练时完全相同的特征变换 vec vectorizer.transform([ticket.content]) prob model.predict_proba(vec)[0] idx prob.argmax() return {label: classes[idx], confidence: float(prob[idx])}为什么用predict_proba而不是predict因为给出置信度对调用方很有价值——置信度低的请求可以做人工兜底或者干脆返回“无法判断”。你看这一个小小的设计背后就藏着对业务的理解。启动服务我用的是 uvicorn命令就一行uvicorn app:app --host 0.0.0.0 --port 8000跑起来之后在浏览器里打开http://localhost:8000/docs就能看到接口文档还可以直接在页面上发请求测试。再用 curl 从命令行发一条curl -X POST http://localhost:8000/predict \ -H Content-Type: application/json \ -d {content: 我买的手机一个月就坏了想退货}到这里你从零开始做的第一个 AI 工程闭环就成立了原始数据 → 清洗 → 建模 → 序列化 → API 服务。这个闭环的价值不在于模型多高级而在于你亲手走通了整条链路知道了每个环节长什么样。4. 模型上线才见真章数据漂移、版本回滚和监控三板斧4.1 “模型上线就变笨”的排查链路其实是三件事很多第一个项目跑通 API 的人会在部署后遭遇一次灵魂拷问为什么线下验证好好的线上预测出来一堆离谱结果我复盘了无数个项目之后发现几乎都是下面三件事里的一件在作怪。第一件是数据分布漂移。线上新进来的数据跟你训练时用的历史数据在分布上已经发生了变化。比如你训练时“退款”类工单平均 50 个字线上用户开始用语气更激烈的短句投诉这个长度和用词的变化就会影响模型表现。第二件是特征不一致。最常见的是训练时你对文本做了清洗比如去停用词、转换大小写但部署时忘了把同样的清洗逻辑包进推理端。还有更隐蔽的训练时用的某个字段线上接口根本没有传进来。这一类问题属于离线和在线的特征工程没有做到“一份代码两处共用”。第三件是调用方使用习惯和你预期不一样。比如你设计的接口一次只传一条工单调用方图省事一次传一百条超时就直接失败了。这种不是模型的问题是接口契约没设计好。排查的思路也很固定先看输日志。推理服务从第一版就要打日志把每一条请求的原文、预测结果、置信度全部记录下来。一旦线上表现不对第一步是去日志里抽样看真实请求长什么样是不是模型没见过的东西。第二步去查线上特征和离线特征的分布对比跑一个简单的统计描述看到底哪个字段分布偏了。第三步再回头看代码确认推理链路里的数据预处理和训练链路是否完全一致。4.2 模型的版本管理每次发布前先想好怎么回退模型不是训练完就扔到服务器上不管的。你迭代了一个月之后模型 v1、v2、v3 可能都存在。这时候如果完全没有版本管理你将面临一个非常尴尬的局面新模型崩了想回滚到上一个版本结果发现那个模型文件被新文件覆盖了。我在项目里的习惯非常朴素每个模型文件命名带上训练日期和版本号例如model_20250610_v3.joblib。同时在项目目录里维护一个简单的MODEL_VERSION文件记录当前生产环境用的是哪个版本。这样做不需要任何复杂平台只靠文件命名规范就能实现最基本的回滚能力。再到后面项目复杂了就可以上 MLflow 这类模型注册工具本质上解决的问题是一样的。发布策略上我强烈建议先做灰度发布不要一下把所有流量切到新模型。最简单的做法是流量比例分配先拿 10% 的请求走新模型对比新老模型的输出质量观察半天到一天确认没问题再逐渐提高到 30%、50%、100%。这个过程不需要什么中间件负载均衡层或者网关配一下就够。这里我想说一句可能被忽略但很重要的经验回滚这件事最好在新版本发布之前就演练一遍。真出故障的时候线上每一分钟都在损失你根本没有时间一边看文档一边想怎么回滚。提前把回滚步骤写进部署手册和代码一样版本化这是很多小团队的交付物里最容易缺失的一环。4.3 监控别只看 CPU更要看“模型表现”本身模型部署之后的监控绝大多数人会局限于看服务器指标CPU 使用率、内存占用、请求量、错误率。这些当然重要但还不够。你还得监控模型自己的“表现指标”。一个很有用的指标是预测分布的稳定性。拿分类模型来说线上预测的类别比例应该和训练集里的类别比例大致接近。如果某一天“投诉”类突然从 10% 窜到 60%那通常是两类原因一类是业务上真的有突发变化比如产品出现了大规模故障另一类是特征分布漂移导致模型输出异常。不管是哪一类你都应该第一时间知道。另一个指标是平均置信度。如果整个系统平均置信度从 0.85 掉到 0.6说明模型面对的输入很可能已经偏离了它熟悉的区域。这时候不需要等业务方骂人你自己就能察觉问题。到这一步你搭建的就不再是一个孤零零的模型服务而是一个具备基本可观测性和可回退能力的系统。你的身份也悄悄从一个“模型训练员”变成了“系统负责人”。5. 一个人单打独斗怎么把“从零开始”这条路走到底5.1 反人类的“先全部学完再动手”——别被它耽误半年我能理解为什么这么多人学 AI 工程会卡在“学习期”出不来因为互联网上可学的东西太多了收藏夹里躺着几百个教程每天看一篇感觉自己特别勤奋。但残酷的事实是只要你不动手写代码那些知识就永远不会变成你的能力。我的做法是“项目倒逼学习”定下一个最终项目比如上面的工单分类系统然后倒推自己需要哪几块能力。缺 pandas就去补 pandas 的常用操作缺 FastAPI就去看官方文档的快速入门。每学一样东西立刻用到项目里。这样你学的不是一些悬浮的知识点而是直接嵌入到项目里的零部件。有的读者可能会担心我连项目长什么样都不知道怎么定项目这个也不用怕。你参考别人的项目定一个范围只有自己能力的 70% 左右的小项目就行。记住第一个项目的目的不是做出一个惊艳的产品而是完整走完一条链路。哪怕你最后做的是“超市销售预测”的 API只要链路是完整的它的训练价值远超做一个半吊子的“人脸识别系统”。5.2 资料选则官方文档优先课程为辅别囤课现在网上的 AI 学习资料多到让人选择困难。我的过滤标准很简单能用官方文档解决的问题优先看官方文档。FastAPI 有非常优秀的官方教程pandas 的官方文档也足够清晰。官方文档的缺点是语言不够“友好”但优点是准确、完整、更新及时。课程也有它的价值特别是帮你建立对一个陌生领域的整体感觉。选课程我有一个判断标准要看是不是那种“边讲边写代码”的课而不是“PPT 念概念”的课。边写代码的课你能跟着敲跟着跑过程中的报错也是一种学习。囤课是我见过的最普遍的问题。收藏了几十个 G 的课程最终真正看完的不超过两门。我现在看到好东西的第一反应不是收藏而是问自己这周能不能抽出时间把它转化成一次实操如果不能那就先让它存在那里等有项目需要的时候再精准查阅。5.3 把踩坑过程变成自己的资产GitHub 是最好的笔记本最后我想讲一个很多人没意识到的学习方法把踩坑的全过程记录下来。不是旧式的“学习笔记”那种记录而是把你的项目仓库本身当成活文档。我自己的习惯是每解决一个值得记录的坑就把它写进项目的TROUBLESHOOTING.md内容包括问题描述、错误日志、排查过程、最终解法。别小看这个动作两个月后你回头看会发现这堆文档比任何教程都值钱因为它们完全是针对你自己的实践经验写的。同时保持 GitHub 的活跃度不只是为了给别人看。频繁的 commit 会让你的代码始终处于“可以被追溯”的状态这对于一个从零开始的工程师而言尤其重要。我见证过很多人从不敢点 commit 到习惯性 commit 的转变这个转变本身就是你从“学习者”到“工程人”的进阶标志。写到最后我想给所有准备迈出第一步的人打一针强心剂别怕一开始写得烂别怕环境装不上别怕代码报错。你遇到的每一个报错剥开来看都是环境、数据、语法、逻辑这四类问题中的一种而这些问题全部可以通过搜索加试错解决。真正要克服的是“一直停留在准备阶段”的心理惯性。给自己设定一个两周内跑通第一个 API 接口的小目标吧完成它时你的感受会证明这条路是对的。
