搞AI工程这事，我在各种群里见过太多人问“怎么入门”“从哪开始写代码”“要不要先刷完LeetCode”。说实话，网上资料一大堆，但真正能把“从零开始”这条路走通的人不多。我自己的经验是，AI工程不是单点技能，是一套把算法、数据、系统、业务串起来的能力。这篇东西，我就拿“ai-engineering-from-scratch”这个主题，把我从零开始摸索出来的路线、踩过的坑、以及现在还在用的实操方法，一次讲清楚。适合刚转行入坑的、在传统后端想往AI靠的，还有那些已经在调模型但总觉得差点工程味的朋友。
1. 从零开始AI工程，到底在“工程”什么
很多人以为AI工程就是把模型训练跑通。真不是。训练出一个模型只是最前面的环节，甚至有时候是最轻松的环节。AI工程的核心，是把一个能跑通的模型，变成一套稳定、可维护、能迭代的系统。这里面涉及数据处理、训练平台、模型服务、监控反馈、资源调度，每一个环节都能让人熬夜。
我见过不少同学，拿着开源代码在笔记本上跑通了demo，觉得自己就会AI了。结果到了公司，要处理几千万条脏数据，要用GPU集群训练，要把模型压到几十毫秒内返回结果，整套流程瞬间就崩了。这些，才是AI工程真正要解决的问题。
从零开始，意味着你不仅要学会怎么调模型，还得明白特征怎么存、服务怎么起、线上怎么监控。这条路挺长，但有章可循。我总结下来就三板斧：先搭认知框架，再练核心工程技能，最后做端到端的完整项目。顺序不能乱，尤其别一上来就抱着Transformer源码啃，会劝退。
1.1 为什么说“从零开始”是最佳姿势
市面上有太多速成课，教的都是怎么用封装好的库，调几个参数，然后“训练”出一个模型。这不能说完全没用，但会让你产生一种虚幻的掌握感。哪天你遇到一个开源库里没解决的bug，或者需要为业务定制一个网络结构，就完全卡住了。
从零开始，不是说让你手写反向传播，而是你得把AI系统里每一层的职责搞清楚。比如数据管道为什么这么设计，训练和推理为什么分开，模型服务为什么要做请求批处理。你会去读源码，会去查论文，会去画架构图。这个过程慢，但扎实。我团队里带过的新人，凡是走这条路的，半年后基本都能独立扛起一个模块；靠速成的，大概率还在堆代码试错。
而且从零开始还有一个隐性好处：你能建立自己的判断力。技术选型时不会人云亦云，知道TensorFlow和PyTorch的差别，知道什么时候该用Ray什么时候该用Celery，知道模型API该用gRPC还是HTTP。这些判断力，才是AI工程师真正值钱的地方。
1.2 这套“工程”适合谁去啃
说实话，这套东西不适合所有人。如果你是科研向，专注发论文，那工程化内容看看就好，重点还是模型创新。但如果你是应用向、业务向，想把AI落地到真实产品里，那这套体系几乎是必选项。
我的读者里，有三类人相当适合走AI工程这条路。第一类是有后端开发经验，了解系统设计，想转到AI方向，这类人优势明显，工程底子现成的，补算法和模型知识就行。第二类是算法工程师，模型调得不错，但每次上线都手忙脚乱，这类人需要补的是服务化、容器化、监控体系。第三类是零基础的转行者，需要足够的耐心，从Python开始，一路打到分布式训练，周期可能一年多，但方向明确，天花板也高。
这条路虽然长，但每一步都可以模块化去学。不用焦虑一次全部搞完，按阶段推进，每跨过一个坎，你都会明显感觉到自己水平的提升。
2. 先把地基打牢：AI工程的底层能力清单
从零开始进入AI工程，最忌讳的就是“两眼一摸黑直接上框架”。你得先确认自己手里有哪些牌，缺哪些牌。我管这个叫“底层能力审计”。这套审计分三块：数学基础、编程能力、系统认知。很多人觉得数学不重要，被ChatGPT这类大模型的“暴力美学”给带偏了。说实话，调API确实不需要微积分，但做AI工程，尤其是要做性能优化、模型量化、分布式训练，数学不过关就是天花板。
2.1 数学基础：哪些是真要用的，哪些是吓唬人的
线性代数大概率是AI工程里用得最多的。张量的形状变换、矩阵乘法、特征分解，每个都跟日常开发强相关。你写一个自定义的推理算子，或者做模型剪枝，都是在跟矩阵打交道。概率论和统计也躲不开。A/B测试看显著性要用，数据分析看分布要用，模型置信度校准也要用。至于微积分，说实话，大部分场景只需要你理解梯度是什么，以及反向传播大概怎么走，手工推导倒是不用太多。
我建议的做法是：不用去刷整本《统计学习方法》，效率太低。把线代的“矩阵运算”“特征值”，概率的“分布”“假设检验”，微积分的“偏导”“链式法则”吃透就够了。不是为了考试，是为了遇到问题时，知道去查哪本书、哪个章节。
2.2 编程能力：从“能跑”到“能工程”
Python是绕不开的第一语言。但“会写Python脚本”和“能用Python做工程”是两码事。你得理解生成器、装饰器、上下文管理器，得会写类型注解，得知道GIL对你并发代码的影响。这些都是AI工程日常要用的。除此之外，C++在AI工程里越来越重要，尤其是推理优化场景。ONNX Runtime、TensorRT这些推理引擎的核心都是C++，你想做算子融合或者自定义算子，不会C++会非常难受。
工程上还有一个容易被忽略的点：代码组织能力。一个AI项目里，数据预处理、模型定义、训练逻辑、评估脚本，如果没有清晰的模块划分，过两个星期你自己都看不懂自己写的代码。我见过太多Jupyter Notebook里堆了一两千行代码的情况，跑起来没问题，但要部署或者给别人复现，基本等于灾难。
我自己的习惯是，所有重要实验代码都按规范目录组织起来，data、features、models、trainers、serving各归其位。这样做的好处是，实验和上线的gap会小很多，很多代码改改路径就能直接进生产环境。从零开始学AI工程的人，越早建立这种工程意识，后面越省力。
2.3 系统认知：AI工程人不容忽视的“横向能力”
系统认知这一块，很多算法背景的朋友比较薄弱，但这又是AI工程区别于AI研究的核心所在。你训练的模型最终要跑在CPU/GPU集群上，要跟消息队列打交道，要处理高并发请求。不懂操作系统、网络、数据库的基本原理，出了问题会非常被动。
举几个我实际遇到的场景：训练数据从对象存储读取，发现IO瓶颈，你必须知道怎么用多线程预取来解决；模型推理服务遇到流量突增，你必须明白水平扩展和限流降级；特征存储用Redis还是用向量数据库，你得知道不同方案的吞吐量和延迟曲线。这些没有系统认知打底，就只能靠试错，效率极低。
所以我的建议是：不要只盯着模型论文看，花点时间读读《数据密集型应用系统设计》的前几章，了解存储引擎、分布式系统的基础概念。这部分内容不直接产生模型指标，但决定了你的系统能扛多大流量。
3. 核心技能拆解：数据处理、模型训练与服务化
地基打完之后，就要进入AI工程的核心技能区。我把它拆成三个环节：数据处理、模型训练、模型服务。这三个环节对应了很多实操细节，任何一个环节掉链子，整个系统都跑不顺。很多人只关注中间的“训练”，忽略了前后的“数据”和“服务”，最后模型跑得再好也白搭。从零开始，你得把这三块都吃透，才算真正入了AI工程的门。
3.1 数据处理：机器学习里那句名言怎么说的
“垃圾进，垃圾出”，这句话在AI工程里依然有效。我在数据处理上吃过太多亏。第一个项目，接手的表里有个字段，1000万行数据里只有70多万行有值，而且格式还不统一，有的是时间戳，有的是“2024-03-15”这种字符串。当时没仔细做数据探查，直接喂给模型训练，结果模型指标忽高忽低，排查了整整三天，最后发现是特征列取错了版本。
所以我现在做数据工程的第一步，永远是写一个数据探查脚本。查每列的空值率、唯一值数量、数值分布、类型。探查完，再写清洗逻辑。清洗逻辑本身要用纯函数，输入输出要可预期，方便单元测试。不要在一个巨大的脚本里混着做清洗、特征、切分这些事情，那可维护性真的太差了。
特征存储这块也值得注意。早期项目我直接把特征拼在训练数据里，上线时再写一套线上特征计算逻辑。结果训练和线上特征不一致，模型线上效果崩掉。后来改成统一特征平台，离线在线同一套代码生成特征，问题才解决。从零开始搞AI工程，一定要把这个一致性刻在脑子里。
3.2 模型训练：从单机到分布式的关键跨越
模型训练是一个典型的“看起来简单，做起来全是细节”的环节。单机训练，你用PyTorch写个训练循环，跑通不难。难的是多卡并行、分布式训练、混合精度、断点续训。这些技能在真实项目中会遇到很多。我至今记得第一次用分布式训练时的场景，数据加载成了瓶颈，GPU使用率只有30%，眼睁睁看着显卡风扇转得飞快但算得极慢。后来用DALI做数据加载，加prefetch，才把使用率拉到90%以上。
训练脚本的稳健性同等重要。训练到第80个epoch集群掉了一个节点，如果没做checkpoint，前面所有计算全部浪费。从零开始养成的习惯是：每N步存一次checkpoint，同时存优化器状态；选用支持容错的训练框架兜底。写训练代码时，还建议把随机种子固定好，这样实验可复现度会高不少。
对于从零开始的人，我的建议是先吃透单机训练，再用多卡训练框架，最后再逐步过渡到大模型训练优化工具。中间的每一步都要亲手做一遍，不要嫌麻烦。分布式的坑实在太多，不实际踩一遍，看多少文档都记不住。
3.3 模型服务化：模型跑起来不是终点，能被调用才是
模型训练完，只是模型文件。要让业务用起来，得把它变成一个能响应请求的服务。这里面的学问不比训练少。模型服务的第一要务是延迟和吞吐。你训练时用float32，推理时可能就得做INT8量化；你测试时batch_size是1，上线时得做动态batching来提升GPU利用率；单个模型实例扛不住流量，你得做多实例负载均衡。
做过一个推荐模型的服务化，P99延迟要求150毫秒以内。一开始直接用PyTorch原生serving，性能完全不行。后来换了推理优化手段，做了TensorRT加速和请求排队，P99降到80毫秒，才算达标。这个过程中的关键点就是得理解底层的数据布局、算子融合、显存复用，只调API是达不到这种效果的。
服务化还要考虑模型热更新。业务上线一个新模型，不能停机部署。我现在的做法是用模型管理平台加服务编排工具。新模型推送到模型仓库，服务自动拉取加载，流量逐渐切过去。整个过程对用户无感知，出问题也可以快速回滚。从零开始做AI工程，不用一步到位搭这种平台，但要有这个意识，前期就预留好模型版本管理的接口设计。
4. 一个完整的从零项目：意图识别系统的落地全记录
前面说的都是零散技能，这个章节，我拿一个真实的“从零”项目来讲清楚，AI工程是怎么串起来的。我选的是“客服意图识别系统”，一句话说清楚要做什么：给在线客服系统接一个机器人，用户发消息进来，机器人先自动判断这是咨询、投诉、售后还是闲聊，然后分流给对应的人工坐席或自助流程。
这个项目的好处是足够典型：有真实的数据，有模型效果问题，有上线服务延迟要求，还有后续的持续迭代需求。非常适合用来复盘AI工程从零到一的完整链路。无论你是想练手还是参考着在团队里推动类似项目落地，都能从这里找到可执行的思路。
4.1 需求拆解与数据收集阶段
项目启动时，第一步不是找模型，而是把需求和边界想清楚，把“意图识别”的具体粒度定义清楚。跟业务方开了三轮会，才明确了初始需求：分四类意图，准确率要大于90%，平均响应时间要小于300毫秒，并且支持后续扩展新类别。
接下来就是数据收集。公司内部有历史客服会话记录，导出来发现有个特现实的问题：标注质量参差不齐。早期人工打的标签和现在的业务定义对不上，有些对话还含有多重意图。我花了两周时间做数据清洗和重标注，最后整理出一份1.2万条的高质量标注样本（最终验证集约1500条左右）。整个过程比较枯燥，但又是项目成败的关键门槛。
这里有一个容易踩的坑：数据不平衡。投诉类样本特别少，只有几百条，咨询类大几千条。如果不处理，模型大概率会把所有样本都预测成咨询类，准确率虚高但实际没法用。我的做法是先评估数据分布，再决定用什么策略。我试过对少数类做简单复制、同义改写、SMOTE过采样，最终效果最好的是用一个小型的base模型做同义改写，既保证了多样性，又没破坏语义。
4.2 模型与训练：从baseline到目标场景适配
数据就绪后，进入了模型选型与训练阶段。我的习惯是快读搭一个baseline，再迭代优化。baseline直接用了开源的预训练中文BERT模型，在标注数据上做微调。第一次跑完，准确率到了85%左右，有点低于目标，但证明了整套数据管线是通的。
然后是针对性优化。我做了一系列实验：加数据增强后效果有提升但不多；用领域预训练模型做初始化提升明显；调整类别权重、做阈值校准，又在测试集上带来了几个点的进步。最终模型准确率到了93%。所以我的核心经验是：不要一上来就换大模型，先把数据处理到极致，再用领域适配的模型做初始化，性价比是最高的。
训练中间还出了个插曲：显存不够。batch_size稍微调大一点，显卡就报OOM。当时我的解决思路是梯度累积加混合精度，效果不错。这个经验也比较通用，很多文本模型在常规显卡上训练，都需要做类似调整，不能直接照搬他人公布出来的大batch配置。
4.3 上线部署与后续迭代：让系统真正跑起来
模型效果达标，只是万里长征第一步。把模型部署上线，又是另一场战斗。我选了Python做后端推理服务，用容器化部署，模型本身转换成了ONNX格式。这么做主要是考虑推理效率和部署可移植性，实测比直接加载PyTorch模型快了一倍左右。
服务上线前，我做了压测：单机300毫秒内可以处理200个并发请求，P95延迟140毫秒，满足了最初定义的300毫秒要求。但我还是留了系统改进空间。流量高峰期如果翻倍，延迟可能不达标，所以做了弹性伸缩和限流预案，从容应对突发情况。
上线后最重要的就是监控。我记录了每天的调用量、延迟、准确率、用户反馈。上线两周后，发现“售后”类意图的准确率有所下滑，查了下原因是用户话术出现了新形式，比如退货流程更新后产生了新的表达方式。于是重新收集了一批相关数据，补充到训练集里，迭代发布了V2模型。这个“监控—发现问题—补数据—迭代模型”的闭环，才是AI工程长期运转的核心。
5. 从零到一踩过的坑，以及值得坚持的几个习惯
最后这部分，我认认真真盘点一下在这条路上踩过的坑和养成的习惯。有些坑到现在想起来还觉得疼，但正因如此，我更希望你能避开。这部分的干货，跟代码和模型一样值钱。
5.1 值得避开的几个经典坑位
第一个坑：在数据集上反复测试，导致过拟合到验证集。刚开始做AI工程时，经常在同一个测试集上反复调参，结果测试集指标越高，上线效果越差。后来我学乖了，把数据严格切分为训练、验证、测试三份，测试集只在最终评估时用一次。再后来，条件允许的情况下我会再做K折交叉验证，比单一切分要稳很多。
第二个坑：环境依赖混乱。Python环境装包，有时候真的很折腾。不同项目用的包版本互相冲突，torch版本、cuda版本、numpy版本，任何一个不对都能折腾半天。我现在的习惯是每个项目从新建时就固定Python版本，用venv隔离，再把所有依赖存到requirements.txt里。看起来是个小习惯，但能帮你省掉大量时间。
第三个坑：重构和实验同步进行。有一次我一边重构数据处理代码，一边跑新的模型实验。结果实验结果有提升，但我根本不知道是模型改好了，还是数据处理逻辑变了。这种混乱会直接摧毁实验的可信度。现在的铁律是：实验代码和重构分开，要么先重构完收敛了再做实验，要么实验冻结掉了再动代码。
5.2 我觉得值得一直坚持的几个习惯
第一，写实验记录。每个实验，我都会记录下来：改了什么、数据集是什么、参数是什么、指标结果多少。写一个月可能觉得麻烦，写半年再看，那就是一笔巨大的知识资产。很多问题的排查，到最后都是靠翻阅这些记录找到的线索。
第二，做代码评审。早期自己埋头写，写完就跑，也没人帮我看。后来进了团队，坚持请同事做代码评审，每一次都能抓出一些潜在的问题。比如边界情况没处理、资源没释放、并发安全有隐患。做AI工程的人容易陷在自己的逻辑里，外部的视角真的能救命。
第三，定期做项目复盘。每次项目上线后，花一小时做一次复盘：哪些做得好，哪些做得不好，哪些流程下次要改。不是走形式，而是把复盘结果写下来，落实到下一轮的行动计划里。AI工程迭代很快，但如果你能不断从过去的项目里提炼方法，你的成长速度会是别人的好几倍。
5.3 利用开源社区与内容沉淀，让成长飞轮转起来
AI工程这条路上，完全靠自己闭门造车是很累的，而且效率不高。我一直保持着关注开源社区动态的习惯，看到好的开源项目，会去读它的源码、跑它的demo，然后思考它解决了什么问题、跟我手头的场景能不能结合。GitHub上那些star很多的项目，背后往往是有大量真实需求支撑的，值得认真读。另外，写技术博客也是个很好的沉淀方式。我写东西不是为了给别人看，主要是为了逼自己把问题想透。好多技术点，我自以为了解，但真要写出来才发现逻辑链条里缺了关键环节。写完再回头补研究，那部分理解就会特别扎实。
还有一点，是保持跨领域交流。AI工程它不只是算法问题，它要求工程能力，也要求业务理解。我经常跟后端同事聊服务架构，跟产品经理聊用户场景，跟数据工程师聊数据质量。每一次交流都能让我重新审视自己系统里的盲区。这种横向的信息输入，长期来看比多看几篇论文还有用。一个人闷头写代码，进步终究还是太有限了。