1. 为什么说AI工程才是项目落地的分水岭
这两年AI领域的火热程度不用我多说，身边越来越多朋友开始接触机器学习、深度学习，GitHub上各种awesome系列仓库收藏了一堆，在线课程买了好几套，但真到了自己要动手做一个完整的AI项目时，却普遍卡在同一个地方——单点技术看懂了，串不起来。
我说的“ai-engineering-from-scratch”，简单讲就是一条从零开始构建AI工程能力的完整路线。它不教你背某个框架的API，也不带你调某个预训练模型的参数，而是把“AI落地”这件事拆成一条清晰的主线：从环境搭建、数据处理、模型训练，到服务封装、部署上线、持续迭代，每个环节都亲手过一遍。做完一遍之后，你再看任何AI项目的技术方案，心里会有一张完整的地图。
这个路线适合谁？两类人最合适。一类是刚入门、学了不少理论但没做过完整项目的学生或转行者，另一类是工作中已经用到AI、但只是调包调用、没深入过工程链路的开发者。坦白讲，这两类人最大的痛点不是“不会写模型代码”，而是不知道一个能跑的AI系统需要哪些零件、零件之间怎么咬合。from-scratch路线解决的就是这个痛点。
我见过太多人学完一堆课程，最后简历上写着“熟悉TensorFlow/PyTorch”，但一问到“你的模型怎么上线的？”“训练数据怎么管理的？”“线上推理延迟多少？”就答不上来。而做过一遍完整链路的人，哪怕项目规模很小，也能把每个环节的来龙去脉说清楚。这就是工程能力和调包能力的本质区别。
所以这篇文章，我不打算写成一份资源清单，而是想把“从零构建AI工程”的完整思路、技术选型、实操过程、踩坑记录都拆开来讲清楚，希望能给准备走这条路的朋友一份真正可参考的路线图。
2. 学习路线的整体设计与阶段拆解
2.1 为什么我坚持“从零手写”而不是“直接上框架”
先聊一个很多人会问的问题：现在PyTorch、TensorFlow这么成熟，直接学框架不就行了？为什么还要搞一个from-scratch路线？
我的看法是：框架解决的是“怎么写更省力”的问题，但解决不了“写什么、为什么这么写”的问题。直接上手框架的人，很容易陷入一种状态——会调用各种API，但不理解底层的数据流、梯度更新、损失函数设计，就像会开车但不懂发动机原理，平时通勤没问题，一旦车子出了奇怪故障就完全抓瞎。
AI工程里有一个很现实的场景：模型训练出来的效果不符合预期。这个时候如果你只会调框架API，能做的事非常有限，最多改改学习率、换换模型结构。但如果你从零手写过线性回归、手写过简单的神经网络、手写过数据Pipeline，你会自然地从数据分布、特征分布、梯度流动这些底层角度去排查问题。这个排查能力，是框架给不了你的。
在ai-engineering-from-scratch这条路线里，我刻意把“手写”和“用框架”做了分层。前几个阶段强制手写，后面的工程化阶段放开用框架。这样既建立了底层认知，又不至于因为过度纠结底层而拖慢工程落地进度。
2.2 路线的四个阶段：从基础补课到上线运维
整条路线我拆成四个阶段，每个阶段有明确的目标和产出物：
阶段一：基础补课与工具链准备
这个阶段的目标是补齐AI工程所需的地基，产出物是一套能跑通的环境和一系列小练习。具体包括：Python编程基础、Linux命令行操作、Git版本管理、Docker容器基础。很多人觉得这些和AI没关系，但实际上AI工程的大部分时间都耗在这些“非AI”的事情上。我的建议是不要跳过，但也不用花太多时间，够用就行。
阶段二：从零手写核心算法与数据Pipeline
这个阶段是整条路线的灵魂。目标不是发明新算法，而是亲手实现一遍经典模型，同时把数据工程的基本功打牢。需要手写的内容包括：线性回归、逻辑回归、简单神经网络（前向传播、反向传播）、数据清洗与特征工程、数据集的划分与评估。每写一个模型，都要配套一个完整的数据处理流程，而不是直接load一个现成数据集。
阶段三：工程化训练与模型服务化
这个阶段开始引入成熟框架，目标是把模型从“能跑”变成“能上线使用”。内容包括：用PyTorch实现一个稍复杂的模型（比如CNN或Transformer结构）、训练流程的工程化改造（配置化、日志化、Checkpoint管理）、模型的保存与加载、用FastAPI将模型封装成在线推理接口。
阶段四：容器化部署与持续迭代
最后一个阶段解决的是“模型怎么长期稳定运行”的问题。内容包括：用Docker打包训练好的模型服务、编写部署编排配置、建立基础的模型性能监控、制定数据回流和模型定期重训的机制。走完这个阶段，你就拥有了一套最小可用的AI工程闭环。
3. 核心技术栈与工具选型解析
3.1 语言和深度学习框架：Python + PyTorch为什么是首选
技术栈的选择直接决定学习成本和后续开发效率。这个我实测下来最有发言权，因为早期我试过TensorFlow，也接触过JAX，兜兜转转还是觉得Python + PyTorch的组合对从零开始的工程实践最友好。
Python的自然语言不用多说，AI生态的绝大部分库都以Python为第一优先支持对象。PyTorch相比其他框架的优势主要有三点：一是调试体验好，模型定义和训练过程都是命令式编程风格，可以在中间任意位置打印张量、检查数据形状，这对于刚建立工程认知的阶段极其重要；二是生态完善，从数据处理到模型部署都有成熟的配套库，不会让你卡在某个环节；三是社区活跃度高，遇到问题能快速找到对应的解决方案。
有些朋友会纠结“现在不是有很多国产框架吗？要不要支持一下？”我的观点是：工程学习阶段选生态最成熟、资料最多的框架，能走得更高效。框架只是一个工具，核心能力在工程思维本身。等技术成熟了，切任何框架都不是难事。
3.2 数据处理链路：pandas + NumPy + Arrow的组合拳
AI工程里有一句老话：数据处理的时间占整个项目的80%。这个比例看似夸张，实际做过项目的人都懂。所以工具链里数据处理组件值得单独拿出来说一说。
基础的数据操作我建议用pandas，它最直观、上手最快，适合做探索性数据分析和轻量级ETL。数值计算用NumPy，因为所有深度学习框架的底层张量操作都基于类似NumPy的机制，理解NumPy的广播机制和向量化操作，对后面理解模型输入输出非常有帮助。如果数据量上来之后发现pandas性能不够，可以考虑引入Arrow和Polars这类列式存储与延迟计算方案。
我自己在做一个文本分类项目时，第一批数据只有几万条，pandas完全够用。后来自动化脚本跑了两周，数据量到了上千万条，一跑就卡，换成Polars + Arrow的组合之后，同样的聚合操作速度快了接近十倍。但我也要提醒一句：这属于“从够用到不够用”的自然演进问题，新人前期别过度设计，等瓶颈出现了再换方案，理解会更深刻。
3.3 模型服务化：FastAPI是目前最省心的选择
模型训练完之后，“怎么把模型能力暴露给外部系统”就是工程化的核心。很多从notebook直接转型的人，第一反应是用Flask写个接口。但我在实际项目里反复对比过，FastAPI是现代AI模型服务化的更优选择。
FastAPI相比Flask有几个非常关键的优势：首先是基于Pydantic的请求参数校验，这省掉了大量手写参数判断的样板代码；其次是自动生成交互式API文档，调试接口时直接在浏览器里点点点就能发请求，效率极高；第三是原生支持异步，面对并发请求时表现更好；第四是性能表现稳定，基于Starlette底层，在同类型框架里属于第一梯队。
我自己在部署一个BERT相似度模型时，用FastAPI封装文本相似度计算接口，实测单机可以稳定支撑每秒几十个请求，延迟控制在几十毫秒级别。这对大多数中小业务场景已经足够了。
3.4 部署与调度：Docker + 容器编排的落地组合
模型接口写好了还不够，怎么让它在各种服务器上稳定运行、怎么让它随着访问量增加而扩容，这才是部署环节的核心问题。我的经验是：Docker是AI工程里必须跨过的一道门槛。
Docker带来的最直接的好处是环境一致性。我踩过最痛的一次坑：本地跑得好好的模型，放到服务器上莫名其妙报CUDA版本不匹配，查了一整天，最后发现是PyTorch版本和服务器上的显卡驱动有兼容问题。如果把应用连同依赖环境一起打成镜像，这种问题基本不会出现。
容器编排方案上，如果你是一个人或者小团队开发，用Docker Compose就能管理大部分服务，没必要直接上Kubernetes那种庞然大物。我见过很多团队一上来就规划Kubernetes集群，结果运维成本比开发成本还高。正确思路应该是：单机阶段用Docker Compose，服务多了之后再逐步迁移到正式的容器编排平台。
4. 实操过程：从零把AI工程完整跑起来
4.1 第一阶段实操：从虚拟环境到第一个版本控制提交
理论知识讲再多，不如亲手跑一遍。我按自己的实操经验，把过程中最值得注意的节点复盘一遍。
环境搭建方面，我强烈建议从一开始就用虚拟环境，不要图省事直接装在全局环境里。用conda或者Python自带的venv都行，关键是要把不同项目的依赖隔离开。我个人的习惯是用conda创建环境，锁定Python版本，再用pip安装项目依赖，并且记录一份requirements.txt。别小看这个习惯，它能帮你避掉无数“我把某个包版本升级之后，另外的项目跑不了”的血泪事件。
Git方面，不管你是做独立项目还是团队协作，都要从第一天开始用。我见过太多初学者习惯改一版代码就另存为一个“最终版v2.py”，到最后文件堆了三四十个，自己都分不清哪个是哪个。正确的做法是始终在一个工程目录下开发，通过Git提交历史来记录变更，需要回退时用Git操作即可。
实战下来，我建议第一个demo项目做到这个程度就合格：建立完整的目录结构（源码目录、数据目录、模型目录、配置目录），提交第一个commit，跑通一段简单的“读取数据—打印统计—输出报告”的脚本。
4.2 第二阶段实操：手写线性回归与完整数据Pipeline
第二阶段最核心的一步，是手写一个线性回归的训练过程，并且自己构造一套完整的数据流水线，而不是用sklearn自带的数据集。
手写线性回归的过程大体分这么几步：生成模拟数据（加入噪声模拟真实场景）、实现数据标准化、手写均方误差损失函数、手写梯度下降更新逻辑、记录训练过程中的损失变化并可视化。每一步都不要跳过，尤其是梯度更新的那一步，强烈建议把每个参数的梯度和更新后的值print出来，亲眼看一遍“参数是怎么一步步调整的”。
不用任何深度学习框架，只用NumPy实现一个完整训练过程，这件事的收获比想象中大。你会直观理解学习率的意义——设大了损失直接震荡发散，设小了半天收敛不了，这种感受只有亲手调过才有。
数据Pipeline的处理上，我推荐一个自己反复用的模板：原始数据预览 → 缺失值与异常值处理 → 特征工程 → 数据标准化 → 训练/验证/测试集划分。每一步都输出一个中间文件，方便核验。这套模板后面做任何项目都能直接用，不要嫌麻烦，前期的规范化能省掉后期几倍的时间。
4.3 第三阶段实操：用PyTorch实现文本分类并封装成接口
完成手写基础算法后，就可以上框架做更复杂的任务了。我选的是文本分类任务，因为这个场景非常贴近实际业务，而且能串起从数据处理到模型服务的完整链路。
模型训练部分有几个工程化细节值得展开说。第一个是训练配置的集中管理，把batch size、学习率、训练轮数、模型参数等写在一个配置类或配置字典里，而不是散落在训练代码各处。第二个是训练日志的结构化记录，用logging模块统一输出到控制台和日志文件，日志里至少包含epoch、loss、accuracy这些关键指标。第三个是Checkpoint管理，每训练几个epoch就保存一次模型权重，保留最近N个版本，防止训练中断后从头再来。
这些细节做的时候感觉麻烦，但一旦遇到“训练到第50轮崩了”“超参要调一轮重新训练”的场景，你就知道它们有多重要了。我在一次真实项目里，因为没做Checkpoint，一个训练了6小时左右的模型在凌晨断电后直接归零，那一天的教训值一万年。
模型训练完成后，就是服务化封装。用FastAPI写一个文本分类接口，接口接收一个字符串，返回类别标签和置信度。核心步骤包括：加载训练好的模型权重、定义输入参数的数据结构、实现推理函数、启动本地服务并用自动化接口测试工具验证。这一部分跑通，你就已经拥有了一个“最小可用”的AI服务。
4.4 第四阶段实操：用Docker打包模型服务的完整过程
服务写好了，最后一步就是打包成Docker镜像。这一阶段的实操会让之前的所有工作产生质变，从“只能在自己电脑上跑”变成“能在任何支持Docker的服务器上跑”。
Dockerfile的编写有几个关键点。第一是选好基础镜像，不要直接拿ubuntu最新版当底，我建议用python:3.10-slim这类精简镜像，体积小安全性高，需要什么再往里面装。第二是提高构建缓存利用率，先COPY依赖文件并安装依赖，再COPY代码文件，这样每次改代码重新构建镜像时，依赖安装那层能够命中缓存，构建速度会大幅度提升。第三是启动命令的正确写法，要用能让进程稳定运行并且能接收外部信号的命令来启动服务。
构建完镜像之后，启动容器验证服务接口是否正常。然后进一步用docker-compose管理整个服务栈，包括模型服务、可选的数据库、资源监控组件等，实现一键启动和停止。到这一步，整个ai-engineering-from-scratch的最小闭环就跑通了。
我个人做这件事的经验策略是第一次必须从最朴素的路径走：一个服务、一个模型、一个容器，不要一上来就分布式、就多级缓存。朴素路径跑通后，后面每一步优化都会更有方向感。
5. 常见问题与排查技巧实录
5.1 模型训练不收敛，先别急着调参
训练过程中的“不收敛”或者说“效果太差”是出现频率最高的问题，新手容易一上来就调学习率、改网络层数，忙活半天却收效甚微。我自己的排查顺序是这样的：
第一步看数据：检查标签是否有错误、类别是否严重不平衡、输入数据是否经过正确标准化。我见过一个项目，模型表现始终很差，查到最后发现是某几个样本的标注文本被意外截断了，数据清洗时一处正则表达式写错导致。第二步看损失曲线：如果loss一直在高位震荡，优先怀疑学习率过大或数据噪声过大；如果loss下降极慢，优先怀疑梯度消失或特征尺度问题。第三步才考虑网络结构本身的问题。
能用数据解决的事情，永远不要先用模型复杂度去解决。这是我实践中最深的体会。
5.2 接口推理速度慢，瓶颈往往不在模型
模型上线后，很多人遇到推理延迟过高的问题，第一反应就是“换更小的模型”。但实际上，推理链路上最拖后腿的往往不是模型计算，而是数据预处理和JSON序列化。
举个我经历过的例子：一个文本分类接口，模型本身推理只要5毫秒，但整个接口响应时间高达200毫秒以上，查了半天发现是每个请求都重新做了一次分词和特征转换，还有一次不必要的同步磁盘读取。把这些步骤改成启动时加载、请求时复用，延迟直接降到30毫秒以内。排查技巧是：在接口的关键节点加上耗时记录，先量出来再优化，不要凭感觉动手。
5.3 环境兼容的坑，用Docker彻底终结
环境兼容问题属于“不遇到则已，一遇到就头大”的典型。本地开发用的是Mac，服务器是Linux，显卡驱动版本不一样、CUDA版本对不上、某个系统依赖库缺失，任何一个问题都能折腾掉半天时间。
我的建议是：不要等到部署阶段才用Docker，从开发阶段就把它纳入工作流。开发时用Docker跑环境，部署时直接把这个镜像带到服务器上，能省掉一大批莫名其妙的问题。如果团队开发，还可以把镜像发布到私有镜像仓库，确保所有人的开发环境高度一致。实测下来，这个做法对团队协作效率的提升只能用“巨大”来形容。
6. 写在最后：这条路线做完之后，你会得到什么
如果完整走完了上面这条ai-engineering-from-scratch路线，你得到的绝对不只是“会写几个模型”的能力，而是一整套AI工程化的思维框架。
你会清楚一个模型从数据采集到持续运维经历了哪些环节、每个环节的关键成功因素是什么、不同环节之间的接口如何设计。工具层面的东西会过时，但这个框架不会。遇到新的AI基础设施、新的模型架构、新的部署方案，你都能快速归位到这个框架里去理解。
我自己的体会是，这条路最难的不是某一个技术点，而是坚持“不跳过”的定力。尤其是手写算法和规范工程化的部分，它们不像调预训练模型那么有“即时满足感”，容易让人怀疑“这是在浪费时间”。但走到后面你会发现，正是这些慢功夫，真正拉开了工程能力的差距。
最后分享一个实操中的小技巧：做一个项目记录文档，每完成一个阶段就记录自己踩过的坑、当时的排查思路、最终的解决方案。时间长了，这份文档会变成你最值钱的经验库，比任何教程都有针对性。也欢迎你在自己的实践路上，不断丰富属于你自己的AI工程地图。