我用了大半年的时间，把“AI工程”这件事从头到尾重新走了一遍——不是看教程、跑通一个demo就完事，而是从第一行数据处理代码写起，到模型训练、调优、部署、监控，完整地做出了一套能跑在生产环境里的系统。回头看，这个过程最大的价值，不在于最终产出了什么项目，而在于“从零开始”这四个字逼着我把每一个环节背后的原理、取舍和坑都亲手摸了一遍。
这篇文章想把这条路线完整地拆给你看。不管你是刚入门、想系统建立AI工程能力的学生，还是已经在用现成框架搭模型、但总觉得哪里不踏实的开发者，我相信这条从我真实经历中走出来的路径都能给你一些参考。这里没有多余的虚话，只有当时怎么想的、怎么选的、踩了什么坑，以及为什么我会建议你也这样走一遍。
1. 为什么选择“从零开始”：从调包侠到工程思维的转变
先说说动机。
我做AI相关开发有一段时间了，早期的工作模式基本是：遇到一个问题，去GitHub上搜一个能用的开源项目，把README读完，跑通demo，然后稍微改改用在自己的场景里。这种模式很快，但问题也积累得很快——模型效果稍微差一点，我不知道该调数据还是调网络结构；数据一变，整个pipeline就崩；最难受的是，模型上线后出了问题，我面对一大堆抽象调用链，根本不知道从哪一层开始查。
说白了，就是“能用”和“会用、懂用”之间有一条鸿沟。大多数教程教你的是“怎么用”，没有人教你“为什么这样能工作”“哪里容易出问题”“怎么系统地调试和迭代”。我决定从零开始，把这个工程链条完整走一遍，目标不是重复造一个开源库的轮子，而是亲手搭一套最简单但完整可用的AI系统，把每一个环节都弄明白。
1.1 看着跑通和真正能用之间的距离
很多刚接触AI工程的读者会觉得，能跑通一个项目就是掌握了。我当初也这么想。但真正开始从零搭建之后才发现，跑通只是万里长征第一步。
举一个很简单的例子：训练好一个模型，在验证集上F1到了90%，你以为完事了。但把它接到真实数据流上，前十分钟就收到报警——因为线上数据分布和训练集差异太大，模型开始大量误判。又比如，你把模型包装成HTTP接口，本地测试响应时间50毫秒，但部署到生产环境一压测，延迟直接翻十倍，因为你没考虑并发、没做批处理、没优化特征预处理的速度。
这些都是“跑通”阶段根本看不见的问题。从零走一遍的最大意义，就是让你有机会在每一个环节上遇到这些问题、理解这些问题、解决这些问题。当你亲身经历过一次从数据到模型再到服务的完整链路，并解决了其中每一个“你以为没问题但实际有问题”的细节之后，你对AI工程的认知才是立体的。
1.2 从零开始的正确含义：不是重复发明轮子，而是拆装轮子
这里要澄清一个误解。“From Scratch”不是让你拒绝一切现成工具，去手写线性回归、手写反向传播——那是造轮子，不是做工程。
我个人的理解是：从零开始，指的是掌握“把系统做出来”的完整能力，而不是只会调用别人做好的黑盒。你可以用PyTorch、用Transformers、用各种成熟的框架，但你要清楚每个环节为什么要这么设计。框架只是工具，工程能力是判断力——知道什么时候该用什么、出了问题怎么排查、多个方案之间怎么取舍。
打个比方：你会开车不代表懂修车，但如果你目标是做一名赛车技师，至少要能把引擎拆开再装回去一遍，知道每个零件为什么存在、不装会怎样。AI工程也是一样。把一条最简链路亲手搭一遍，就是“把引擎拆开再装回去”的过程。
2. 地基自查：数学、编程与数据基本功怎么过
既然说从零开始，首先面对的就是基础关。我不建议一上来就啃完一整本《深度学习》或者刷完几门数学课再动手，那样大概率会半途而废。更务实的做法是“按需学习”——在项目推进过程中遇到什么补什么。但有一些基本功，是在动手之前最好先确认自己过关了的。
2.1 数学、编程与数据基本功怎么过关
AI工程涉及的数学主要是线性代数、概率统计和微积分。但说实话，除非你要读论文、自己发明新算法，否则工作中真正高频用到的数学并没有那么高深。
第一，向量和矩阵运算要熟悉。特征就是向量，数据集就是矩阵，模型就是矩阵乘法和非线性变换的组合。你至少要能看懂张量的形状怎么变化、点积和矩阵乘法在代码里怎么对应的。第二，概率统计的直觉很重要。损失函数本质上是概率建模，过拟合是方差问题，A/B测试要用假设检验，这些如果不懂，做决策的时候会很被动。第三，微积分里最重要的是链式法则和梯度下降的思想，这决定了你调学习率、理解梯度消失时的方向感。
我的建议是：准备一本靠谱的教材，但不强迫自己从头读到尾，而是做项目时遇到数学概念就去查对应章节，这样记得最牢。
2.2 Python工程化习惯：从写脚本到写系统
很多初学者写Python就是写脚本：一个文件跑到底，函数之间靠全局变量传递数据。但AI工程是一个系统，不是脚本，你需要尽早培养工程化的习惯。
最重要的几个习惯：函数要做到输入输出清晰、不依赖隐式全局状态；数据处理的每一步尽量用类或函数封装，方便复用和测试；学会用虚拟环境管理依赖，不要把项目依赖装到全局环境里；Git的操作要熟练，因为实验管理靠它；另外etertools、pathlib等标准库的高效用法也能省下大量时间。
这些看着琐碎，但都是工程心态的体现。如果代码还是脚本水平，后面的模型迭代、多人协作出问题的概率会成倍上升。
2.3 数据敏感性：应该用多少数据量做合适的试验
“数据敏感性”是我最想强调的一个基础能力，但这块其实不是靠读书读出来的，而是一次次被数据坑过之后的长进。大概意思就是：拿到一批数据，你大致扫一眼就能判断出质量怎么样、分布特点是什么、哪些字段后面很可能出问题。
训练集和测试集要分得合理，不能乱切——尤其是时序数据，不能随机切分，否则会造成信息泄漏。数据的量级也很关键。我个人的经验：小规模试验阶段，几千条干净样本就足够暴露pipeline里的大部分bug；几十万条以上的数据适合做一次正式训练；更大量级的数据，你就得开始考虑采样策略或者分布式处理了。很多新手一上来就往全量数据上冲，跑一次训练几个小时，结果一个低级错误导致全部白跑——这就是明显缺乏数据敏感性的表现。
3. 核心链路拆解：从原始数据到可用模型的完整流转
基础过了关，就进入这条链路的正题。我把从原始数据到可用模型的完整环节拆成了四步：数据清洗与特征工程、模型设计、训练与调优、评估与迭代。每一步都有它的关键问题和常见误区，我逐步讲。
3.1 数据清洗与特征工程：什么脏数据会“吃掉”模型性能
拿到原始数据，第一件事不是喂给模型，而是先“体检”。
最常见的问题类别有这么几类：缺失值、异常值、重复数据、类型不一致和分布偏差。处理缺失值，要区分是随机缺失还是有偏缺失，固定值填充、均值填充还是模型预测填充，得按业务来。异常值则要小心，有时候异常值代表真实业务场景中的关键信号，直接删掉可能适得其反。
特征工程是一个需要经验的设计过程。例如，把分类变量做成one-hot，数值变量做归一化，时间特征拆成年月日星期。另外，特征之间的交叉组合有时能带来效果提升，但也可能引入过拟合。一个核心判断标准：特征在训练集和测试集上的分布要尽量一致，如果某个特征只在训练集上能取到值，这就是泄漏。
3.2 模型设计：从Baseline到更优解的判断路径
一个好的工程习惯是：小的、简单的模型先跑通，再逐步增加复杂度。
不要一上来就上大模型。我一开始总是直接上预训练模型、上大网络，结果常常是：明明问题是数据质量太差，却在折腾更大的模型。先做一个逻辑回归或者随机森林作为Baseline，好处非常多：第一，算得快，能快速验证特征和数据的正确性；第二，能在小规模上跑通整个训练和评估流程；第三，它的表现可以作为天花板参考——如果复杂模型在测试集上连Baseline都打不过，说明你的数据或特征工程有问题，而不是模型能力不够。
3.3 训练与调优：学习率、批量大小和过拟合的博弈
模型训练的过程，本质上是在做一种“拟合”的平衡。拟合不足是欠拟合，拟合过头是过拟合，你要找到的合适合适区间。
学习率是最重要的超参数。如果学习率设得过大，loss会在震荡甚至发散；如果设得过小，收敛速度让人心焦。实践里用学习率预热、余弦退火这些策略能改善收敛。批量大小则影响训练稳定性和显存占用，常规的选择在32~128之间。数据量越大，批量通常可以设得更大，学习率也可同步调大。
过拟合有几个常见的信号：训练loss继续下降但验证loss开始回升、训练指标远好于测试指标、模型对训练样本“死记硬背”。对应的手段也很成熟：增加数据量（包括数据增强）、正则化（如Dropout、权重衰减）、早停机制，还有模型集成。我自己的经验是：先从简单模型出发，逐步增加复杂度，每一步都要用验证集的指标说话，训练过程要有清晰的实验记录。
3.4 评估与迭代：用什么指标衡量模型的真实价值
准确率是最直观的指标，但在很多场景里不够用。例如在类别不均衡的数据里，准确率再高也可能是垃圾模型。分类问题需要多看精确率、召回率、F1等指标；回归问题看MAE或RMSE；如果是排序类业务，可能还要看AUC等排序指标。
更接近真实场景的评估方式，是做离线评估和在线评估的组合。离线评估用历史数据验证模型的普适能力；在线评估则是小流量灰度发布，观察真实业务指标的变化。模型迭代不要只靠拍脑袋，而要用评估结果驱动：先在验证集上定位是偏差还是方差问题，再决定是调数据、调特征还是调模型结构，每一次改动都对应一次完整的实验记录。
4. 服务化部署：把模型变成别人能用的产品
模型的训练和目标环境本上只在训练环境里有意义，要把价值落地，就得把它部署成服务。这一章节的经验，大多数只有真正从零做过一次的人才会懂。
4.1 模型封装与接口设计：模型不是终点，接口才是
模型训练完，首先需要被封装。最常见的方式是序列化成文件，比如PyTorch的.pt、Transformers库的safetensors等，然后在服务进程里加载。
接口设计的问题在于，业务方不关心你的模型内部结构，他们只关心一件事：传入合法的输入，返回有意义的结果。因此你需要做一个预处理和后处理的层。例如文本分类模型，接口层接收字符串，内部做分词、编码、预测、概率转换，最后吐出结构化JSON。这些处理最好全部封装在一个类里，对外只暴露一个predict方法，这样后续换模型、加逻辑都比较方便。
4.2 性能优化：延迟、吞吐和规模化
部署上线后，你会立刻面对三个工程指标：延迟（从请求到响应的耗时）、吞吐（单位时间能处理的请求数）、稳定性（高并发下不挂、不超时）。
延迟瓶颈通常出在预处理、模型推理、后处理这三处。预处理可以考虑并发处理；推理则可以考虑是否用GPU、开启TensorRT等专用优化，或者批处理。还有一个比较容易的事情是：如果同一批数据同时请求，可以把它们合在一起做一次批推理，能显著提升吞吐。
工程上，一般会用Web框架封装模型服务，起多个Worker进程，前面再架一层负载均衡。缓存高频重复的请求结果也能减少不必要的计算量。
4.3 监控与持续集成：生产环境的问题往往在模型之外
模型上线只是开始。数据分布偏移、用户行为变化，都会让模型效果随时间慢慢衰减。你需要一套监控体系关注推理服务的CPU、内存、GPU利用率、响应时间、错误率等基础指标，以及模型层面的平均置信度、输出分布等语义指标。
我踩过的一个坑是：某个分类模型上线后效果持续劣化，但服务健康指标一直正常，后来一查才发现是上游数据的某个字段格式变了。这就是典型的“模型之外”的问题。监控不仅要做，而且要形成反馈闭环——一旦指标异常，能定位到是数据变了、特征变了还是模型老了。
5. 工具箱取舍：哪些该自己造，哪些该用现成的
从零实践的过程中，工具选择也是重要一环。我的原则回到前面那句话：不用重复造轮子，但要知道轮子为什么存在、什么时候该用哪个。
数据处理阶段，Pandas在中小数据量下效率高，但超大数据量时要考虑Polars工具库或Spark。训练框架层面，PyTorch是当前主流推荐，生态好、调试相对方便；TensorFlow也有自己的场景，但新手建议优先学习PyTorch。模型层面，Transformers库里统一下了很多预训练模型，直接利用能省大量时间；但真正做垂直场景的调优时，还是要明白内部的tokenizer、attention等关键原理。
部署工具方面，FastAPI + Uvicorn跑模型服务很轻便；如果对性能要求高，还可以考虑ONNX Runtime、TensorRT等推理优化引擎。这些工具没有谁绝对好，关键看场景和问题的定位。从零做一遍的核心目的，就是你亲手把“该选什么工具”的决策做过一遍，下次遇到新问题就知道从哪个方向选型。
6. 一个完整实例：从零构建文本分类系统
理论和工具聊了很多，落一个完整的实践。就拿文本多分类这个任务做例子，带你串一遍从数据到部署的完整过程。这个任务足够简单，适合从零走通链路，又不失代表性。
6.1 数据准备与分析
假设我们要做电商评论的情感分类：好评、差评、中性三类。原始数据是一批带标签的评论文本，但这些文本质量参差不齐——有重复、有错别字、有超短样本，还有标签分布严重不均衡的情况。
第一步，加载数据后先做基本统计：看类别分布、文本长度分布、缺失值情况。发现“差评”只有“好评”的十分之一，于是考虑后续用数据加权或者直接做下采样处理。初步清洗，包括去重、去除明显无意义的文本（比如只有一个标点符号），保留不同标签的代表性样本。
这里信息泄漏的风险是：切分数据集不能随机乱切，因为某一条用户可能会有多条评论，而这些评论可能分布在不同类别里。如果不做用户级别的分组切分，模型学会的很可能不是判断文本情感，而是记住用户。这个坑绝对值得提一下。
6.2 特征构建与模型选择
初版做法最简单有效的特征工程就是：直接把文本用TF-IDF向量化，喂给一个逻辑回归模型。
清华的新手不要一上来就上BERT。逻辑回归走一遍完整流程，能让你把数据处理、训练、评估、部署的各个接口都理顺，而且有一个稳定的表现做Baseline。测试下来，逻辑回归在这个任务上准确率大概在82%左右，这成绩够格搭出完整服务了。
接着再引入中文预训练模型的对比。既然要提升效果，直接用一个相对小型的BERT类模型——例如6层的中文预训练模型。分词、加padding、构建DataLoader，训练过程相对长，但结果确实比Baseline有显著提升，准确率到了91%左右。
6.3 训练调优与上线部署
训练调优阶段，我记录了多组对照实验：不同学习率（3e-5和5e-5对比）、不同batch size（16和32）、不同max length。最后验证下来，学习率3e-5、batch size 32、max length 128的组合在这份数据下表现最稳定。
部署上分了两版：第一版是直接把逻辑回归模型用joblib序列化，做成一个FastAPI接口，验证整个在线预测流程。第二版把BERT模型导出成ONNX格式，用ONNX Runtime推理，延迟比原始PyTorch的推理降了一半以上。监控用了一个很轻量的方案：把每次请求的输入文本哈希、预测类别和置信度记录到日志，定期用这个日志画一个置信度分布曲线，观察是否出现漂移。
最后说一下这个项目带给我的最直观感受：当一条新评论进来，几百毫秒内返回一个可靠的分类结果，而且我对从数据到模型再到服务的每一个环节都有了掌控力的时候，才真正感觉到自己是在做工程，而不是在“跑程序”。
7. 从零到一的路上：我踩过的四个典型坑
这一章节单独把踩过的坑列出来，每一个都耗费过我不少周末。
7.1 数据泄漏
第一次做数据切分时，我偷懒直接随机切分。模型效果很好，评估数据很漂亮，但部署后效果就打了对折。后来才发现，同一作者的评论同时出现在了训练集和测试集，模型其实是在记忆作者特征。
7.2 评估指标选错
二分类任务我一开始只看准确率。后来把坏样本翻出来看，发现“差评”这个类别的召回率低到离谱，大量差评被归到了中评。对于这种不均衡的场景，要盯住类的精确率和召回率。后来改用宏平均F1作为优化指标，才算真正开始提升模型的实用价值。
7.3 训练服务“本机可以，上线不行”
模型在本地跑得好好的，量化后部署到服务器上，效果立刻下降。原因是量化策略太激进，对敏感层造成了精度损失。这个教训告诉我：模型优化必须在目标环境做测试，不能用开发环境的结果推断生产环境表现。
7.4 监控缺失
严格来说这不算技术坑，而是流程问题。模型部署早期没有做输出分布监控，上线三周后才从业务侧发现某个类别比例极度失衡。等到我查清原因，发现是数据源端格式变更早就发生了。如果有监控，这种问题半天内就能定位。
关于从零开始这件事的最终心得
如果你问我走完这一圈之后最深的感受是什么，我的回答是：AI工程的能力，没有任何捷径可以替代亲手把一个完整系统做一遍。那些执行层面的细节，那些接口之间的微妙关系，那些吃了亏才能记住的判断力，都是真正做工程时才会长出来的技能。
从零开始，真正的意义不是标榜所谓“白手起家”，而是用一个最小的完整项目，把所有黑盒拆成白盒，把每个环节的判断标准长在自己身上。有了这条底子，后面再用什么工具都是顺水推舟的事，因为你已经知道那些工具在你亲手搭起来的框架中处于什么位置。
最后分享一个我一直很受用的建议：走这条长路的时候，给自己找一个足够小但完整的项目，比如一个垂直场景的分类或预测任务，然后用最快速度把全链路跑通，再回到每个环节里细究“为什么”。这个时候，你会真正感觉到，自己已经不是一个不会翻车的调包侠，而是一个能对系统负责的AI工程师了。
