做ai-engineering-from-scratch这个项目之前，我被问得最多的一句话是：AI工程师到底应该从哪开始学？市面上的课程、文章、开源项目多得翻不完，但大部分人不是被数学劝退，就是被“调包侠”的自我怀疑困住。我整理这套从零起步的AI工程学习路径，是为了把“AI工程”还原成一套可拆解、可上手、可验证的实践体系，而不是又一个收藏夹。
这个项目解决的痛点很明确：知道了一堆概念却搭不出一个端到端可用的系统。你可能会下载模型、调用API、跑通notebook，但一旦要自己设计数据流、评估效果、部署服务、监控指标，就不知道该按什么顺序做。这套内容的目标读者，是那些有一定Python基础、想系统切入AI工程，但缺乏一条清晰路径的开发者。
我的做法很简单粗暴：所有的知识点都围绕“动手做一个真实可用的AI系统”来组织，理论给出为什么，代码给出怎么做，坑点给出我踩过的现场记录。这篇文章就把这套项目的设计思路、核心内容、实操过程完整拆给你看。
1. AI工程到底是什么，我为什么把项目设计成“从零开始”
1.1 被误解最多的一个岗位名称
先说个普遍现象：很多人把“AI工程师”等同于“会训练模型的人”，结果一入坑就扎进深度学习理论里，三个月后连一个简单的服务接口都写不出来。AI工程和算法研究最大的区别在于，前者追求的是系统在真实环境里的稳定表现，后者追求的是模型在指标上的突破。
一个现实中的AI工程问题通常长这样：用户上传一张模糊的发票照片，你要在3秒内返回结构化的字段，并且准确率不能低于98%。这里面牵涉到图像预处理、模型推理、字段校验、异常兜底、日志监控，模型训练只是其中一个环节。我把项目定位为“from scratch”，不是说要从张量推导开始写神经网络，而是把这条完整链路里需要用到的知识，按工程落地的顺序重新排一遍。
1.2 从工程生命周期反推学习内容
设计这套内容时，我先把一个AI系统的生命周期画了出来：需求定义、数据准备、模型选型与训练、评估验证、部署上线、监控迭代。然后反推每个环节需要什么样的知识储备。
- 需求定义环节：需要懂业务指标到技术指标的转换，比如把“减少客服重复回答”拆成意图识别的准确率、延迟、覆盖率。
- 数据准备环节：需要掌握数据采集、清洗、标注、版本管理，这里最常见的坑是训练集和测试集分布不一致。
- 模型训练环节：不是每个任务都要从零训练大模型，更多时候是在预训练模型上做微调，或者直接调用现成能力做编排。
- 评估验证环节：不能只看准确率，要会做bad case分析、切片评估、线上回放。
- 部署监控环节：要理解模型服务化、资源估算、弹性伸缩、漂移检测。
按照这个顺序，我给项目制定了六个模块：工程基础、机器学习核心、深度学习实战、LLM应用开发、MLOps落地、端到端项目。很多人一开始就想啃LLM，我反而建议先把工程基础打牢，因为后续所有环节都建立在这层地基上。
2. 内容结构设计与方案选型的底层逻辑
2.1 为什么用“学习路线 + 可运行代码 + 踩坑记录”的三件套结构
这个项目我采用了仓库即博客的形式，每个模块下面都有三样东西：一篇讲原理和选型思路的文档、一组可以直接运行的代码示例、一份记录真实踩坑的FAQ。之所以这样设计，是因为我发现传统的“看教程学AI”存在一个致命问题：代码是别人写好的，数据是别人清洗好的，环境是别人配好的，你只是点了一下Run。
真正的能力提升发生在你亲自处理环境冲突、数据缺失、显存溢出、版本不兼容的时候。所以我的每个模块都故意留了一些不完美：有的代码需要你自己补全参数，有的数据集需要一个预处理函数，有的服务需要你写一个健康检查接口。做完这些，一个模块才算真正过关。
2.2 手写实现、源码阅读、工程复现三条线并行
我在这套项目里反复强调一个学习方法：同一个知识点，用三种方式吃透。
第一条线是手写实现。比如线性回归、逻辑回归、反向传播，我坚持要求自己从零写一遍，虽然代码丑、性能差，但写完以后你对梯度下降的理解完全不一样了。第二条线是源码阅读，用PyTorch或Transformers库的实现来对照自己的代码，看官方怎么处理数值稳定性、内存复用、批处理。第三条线是工程复现，把一个已经开源的模型或应用（比如简单的RAG问答系统）重新实现一遍，不看原代码，只看架构图。
这三条线不是每个知识点都需要走完，但我建议梯度下降、Transformer的前向传播、RAG检索流程这三个关键点务必用三种方式各做一遍。我在实际学习中的体会是，手写实现带来的思维收益是单纯读文档的三倍以上。
3. 六个核心模块的拆解与实操要点
3.1 工程基础：先解决环境、数据和代码组织问题
很多纯算法背景的人会忽略这个部分，但AI工程里最耗时间的事情往往不是炼丹，而是跟环境作斗争。Python版本冲突、CUDA版本不匹配、依赖库之间互相打架，这些坑会消耗掉你大量的耐心。
我的项目里这部分要求完成三件事：第一，用一个统一的工具（我用的是conda加pip-tools）管理项目依赖，做到requirements可复现；第二，把数据处理的pipeline做成可重放的脚本，每一步都留中间结果，这样调参时不用全部重跑；第三，学会用dotenv管理密钥和配置，不把任何敏感信息写死在代码里。
一个我强烈建议新手养成的习惯是：任何实验代码，跑通第一版后再花20%的时间做结构化重构。哪怕只是拆成几个函数、加上类型注解、补充日志，后面调试省下来的时间会远远超过这20%。项目里配有模板，你直接拿自己的小实验套一遍就会有体感。
3.2 机器学习核心：用可解释的模型建立直觉
这个模块我刻意选了逻辑回归、决策树、随机森林这类相对传统的模型作为开胃菜，不是因为他们过时，而是因为它们具备宝贵的可解释性。当你刚接触机器学习时，最需要的是建立“特征如何影响预测”这种直觉。比如用逻辑回归做垃圾邮件分类，你能直接看到哪些词对判断贡献最大。
这一模块的实操任务是：自己写一个交叉验证的流程，不要直接用sklearn的一行封装。你需要手动切分折数、训练多个模型、汇总指标，这样才能真正理解为什么需要交叉验证，以及不同切分方式会带来什么偏差。随后再用随机森林和梯度提升树做同一个任务，对比它们在表格数据上的表现差异。做完这个对比，你基本就明白了为什么在结构化数据上树模型至今仍然使用广泛。
3.3 深度学习实战：从手写反向传播到理解预训练模型
这一模块是整套项目里理论密度最大的部分。我不建议一上来就去啃Attention Is All You Need的原始论文，而是先用一个极小的例子理解核心机制。我在项目里安排了一个练习：用PyTorch实现一个两层的Transformer编码器，用来做一个简单的序列分类任务。不需要追求效果，重点是理解Q、K、V是怎么计算的，mask起什么作用，残差连接和LayerNorm放在哪里。
当你动手写出Shape变换的那一刻，很多之前读不懂的代码都豁然开朗了。之后再去使用Hugging Face的Transformers库，你会发现它不过是你手写版本的工程优化版。这个模块的落地方向是让读者跑通一个完整的微调流程：加载bert-base、处理数据集、做tokenization、训练、保存checkpoint、加载做预测。我自己当初卡在最久的地方是batch padding和attention mask的管理，项目里为此专门写了一篇长文档解释。
3.4 LLM应用开发：提示词、检索增强与外接工具
LLM相关的工程实践可以很快上手，但也很容易浮于表面。这部分内容我把它分成两半：一半是提示词工程的基本功，包括角色设定、few-shot示例、输出格式约束、思维链提示；另一半是更工程化的能力，包括函数调用（Function Calling）与外部工具的接入、RAG的检索与重排、以及处理模型的随机性和幻觉。
在RAG部分，我设计了一个具体的任务：基于一份企业内部的员工手册，实现一个问答机器人。你需要做文档切分、生成向量索引、写检索函数、把检索结果拼进提示词，最后还要处理查不到答案时该怎么回复。走通这个流程后，你对“LLM应用开发”就不再是只会调API，而是知道每一步的瓶颈在哪里。
3.5 MLOps落地：模型版本化、实验跟踪与服务部署
很多人问：是不是所有AI项目都得上Kubernetes？我的答案是否定的。MLOps的核心不是炫酷的云原生架构，而是保证每一个实验可以被复现、每一个模型可以被追溯、每一次发布可以回滚。所以这个模块我用轻量级的工具就能解决大部分问题：用MLflow做实验跟踪和模型注册，用FastAPI把模型包成服务，用Docker做环境隔离，用Git做代码版本管理。
实操任务是把上一模块训练好的分类模型注册到模型仓库，用FastAPI暴露一个/predict接口，再加E2E的测试请求。然后部署到一台服务器上，用locust做简单的压测，看看QPS和延迟是否满足业务要求。走到这一步，你才算把“模型”变成了“服务”。这个环节我踩过的最大的坑是模型文件与代码版本不同步，后来统一用MLflow的模型URI解决，项目里有详细的参数说明。
3.6 端到端项目：把零散的模块串成完整系统
最后一个模块是考试，也是能力的最终体现。我选了一个经典的业务场景：工单内容自动分类和紧急度判断。你需要综合运用前面学的所有知识：先清洗和标注一份模拟的工单数据，做EDA分析，微调一个文本分类模型，同时用规则做兜底；然后设计一个评估策略，分别衡量分类准确率和紧急度排序的合理性；最后将模型封装成服务，用一个简单的模拟前端来演示调用。
这个项目最重要的设计目标，是逼迫你做出取舍。当准确率和覆盖率冲突时怎么选？当某个类别样本极少时怎么办？当线上预测分布和训练分布不一致时如何处理？这些都是真实世界中必须面对的问题，也是和普通课程作业拉开差距的地方。建议给自己限定两周时间，独立完成，然后把自己的方案和项目里给出的参考方案做对比。
4. 实操记录：从零到一跑通一个AI服务
4.1 先定一个最小可行的验收标准
动手做一个具体项目之前，先逼自己写清楚“做成什么样算成功”。我给自己定的标准是：输入一段用户问题，系统能在2秒内给出分类结果和紧急度评分，且和人工标注的一致率达到85%以上作为第一阶段的验收门坎。有了这个标准，后面的所有决策都变得清晰了：要不要换模型、要不要加规则、要不要做数据增强，判断依据都是有指标的。
我建议你也把标准写进项目的README里。这个动作有两个好处：一是防止自己陷入无限调参；二是你后期写复盘文章时，能清楚地告诉别人你做到了什么程度。项目里我提供了一个模板，包括延迟、准确率、资源占用、鲁棒性几个维度。
4.2 完整跑通一个微调与部署全流程
这里给一个典型流程的简化版，你可以对照这个步骤来复现：
- 准备数据：从公开数据集中抽取与工单分类相关的字段，做标签映射。注意检查类别分布，我拿到的时候发现“退款”类比其他类多了将近二十倍，于是做了分层采样。
- 编写训练脚本：加载预训练模型的分词器和主干，设置最大长度128，批次大小16，学习率2e-5，做三轮微调。关键点是保存每个epoch的checkpoint，方便回滚。
- 编写评估脚本：除了整体准确率，我额外要求自己计算每个类别的精确率和召回率，然后把混淆矩阵打印出来。这一步帮我发现了“网络故障”和“账号问题”两个类别容易被搞混。
- 封装服务：用FastAPI写一个predict接口，接收JSON请求，内部完成文本预处理、模型推理、阈值判断，最后返回分类结果和置信度。
- 压测与优化：用locust模拟20个并发用户，发现P99延迟超过了3秒，后来把模型从CPU切到GPU推理，同时加上一个简单的响应缓存，延迟降到600毫秒左右。
- 容器化部署：写一个Dockerfile，基于官方PyTorch镜像，把模型文件和代码打包进镜像，启动时预加载模型。第一次部署时镜像大小超过4G，后来用Git LFS存模型、写.dockerignore过滤掉缓存才降下来。
整个过程大约需要两天时间，其中一半的时间都在处理各种环境问题，这非常正常。我第一次做的时候最崩溃的环节是CUDA版本和PyTorch版本不匹配，花了一个晚上才解决，这个坑我在后面的问题排查部分详细展开。
4.3 记录实验并保持版本可控
学习过程中，我非常建议你养成记录实验的习惯。不需要复杂工具，就按日期建目录，每次实验记录四件事：目标、代码状态、关键参数、结果指标。我用MLflow来做结构化追踪，但初期用CSV加截图也完全足够。
我自己的记录方式后来演进成了一个模板：一个data_processing.py、一个train.py、一个evaluate.py、一个infer.py，外加一个experiment.md。这个模式被吸收进了项目模板，你在每个模块目录下都能看到类似的组织方式。这样一个实验完成后，你的代码就是别人也能跑通的完整作品，而不是一个没法复现的notebook。
5. 常见问题与避坑指南
5.1 环境依赖和版本兼容性
这类问题占了新手的八成困扰。我的经验是：第一，不要盲目追求最新版本，PyTorch、Transformers、CUDA这三者的版本匹配关系优先参考官方文档的兼容性表格；第二，无论什么项目，第一步都是创建一个独立的虚拟环境；第三，遇到莫名其妙的内存错误或算子报错，先检查是不是CPU和GPU的推理路径混用了。
我还整理过一个快速排查顺序：先看CUDA是否可用（torch.cuda.is_available()），再看模型和设备是否都在同一设备上，再看输入数据的dtype和shape是否符合预期，最后再看是否是显存不足。按照这个顺序排查，大部分问题都能在十分钟内定位到根因。项目里有一整节专门记录这些组合问题，并附上每条解决方案。
5.2 数据泄漏是评估的隐形杀手
第二个最高频的问题是评估结果虚高。很多人做文本分类时直接对整个dataframe做train_test_split，如果同一用户的多条工单同时出现在训练集和测试集里，模型其实已经“见过”答案了。我的建议是：在切分数据前，先弄清楚数据的最小不可分割单元，按这个单元做分组切分，而不是按行切分。
在RAG评估中，还有一个更隐蔽的问题：用生成答案的数据集去评测检索召回率，这会造成严重的数据泄漏。我在项目里专门演示了如何构造一个“检索专用的评测集”，确保查询和文档之间的重叠被严格控制。这个部分建议每个做知识库问答的人都认真读一下。
5.3 模型表现不错，但线上效果崩了
第三个问题是我自己踩过最深的一个坑：离线测试指标非常漂亮，上线后用户反馈却一团糟。后来发现原因有两层。第一层是训练数据的分布和线上真实分布存在差距，表现为类别比例不同、文本风格不同；第二层是没有给模型设置拒答机制，导致模型对完全没见过的问题也硬给一个结果。
解决办法也很直接：在服务里加一个置信度阈值，低于阈值的case走人工兜底或回复模糊求助。再加上一个简单的规则层做前置拦截，比如包含“退款”关键词的工单直接走退款流程。这种做法在网上被讨论得很多，但真正按要求实现的人很少。我把自己的实现方案和参数选择写在了端到端项目里，你可以直接参考。
6. 这个项目的后续拓展方向与我的真实体验
6.1 它还能长出什么新东西
这套内容整理完之后，我发现它其实是一棵树的树干，还有很多可以继续生长的分支。比如把单纯的离线评估升级为在线实验平台，对两个模型做A/B测试；把固定规则的RAG扩展成带用户反馈的自适应检索；把单模型的微调改成多模型集成的决策系统。尤其是LLM领域，工具调用、多模态输入、Agent编排这些方向，都可以作为独立的进阶专题挂在每个模块的底下。
我在项目规划里也给每个模块标注了“进阶延伸”清单，比如机器学习模块之后可以深入特征工程和模型解释性，LLM模块之后可以继续学微调技术如LoRA、QLoRA。如果你想在实际工作中长期做AI工程，这些延伸方向就是你的下一步地图。项目本身也会持续合入新案例，我最近的计划是加入一个基于多模态模型的票据信息抽取示例，因为它覆盖了图像处理和文本理解的交叉场景。
6.2 坚持做完比追求完美重要
最后想分享一点个人真实感受。这套从零开始的AI工程之路，我走了两遍——第一遍是自学踩坑，第二遍是把它整理成项目。我最深的一个体会是，AI工程的核心能力不是知道得多，而是能在不确定条件下做出合理决策。你不可能等读完所有论文再写代码，也不可能等学会所有工具再开始项目，你只能在做的过程中不断补课、不断修正。
如果你也想走这条从零开始的路线，我的建议是：选一个自己真正关心的场景，哪怕只是给自己的工作笔记做一个智能搜索，然后沿着这条主线把工程链路走完。这个过程会比刷十门课程都有用。这条路走得不算快，但每一步都扎实。