“ai-engineering-from-scratch”这个项目名，我之前在好几个技术社区都看到过。说实话，一会儿是学习路线图，一会儿是开源仓库，一会儿又是一堆教程的合集，挺多人把它当成收藏夹里吃灰的资源。但如果你真的想认真走一遍AI工程这条路，这个标题其实点出了最关键的一招：别急着上框架、别急着套模板，先搞清楚底层是怎么回事，再一步步把系统搭起来。

我做了几年AI方向的落地项目，也带过不少新人，今天就用一篇长文把“从零开始学AI工程”这件事拆开讲清楚：这条路到底涉及哪些技能、按什么顺序学、学到什么程度算过关、实操时最容易在哪儿翻车。不管你是刚毕业的学生、想转行的后端工程师，还是已经在用API调模型但想深入一层的开发者，这篇文章应该都能给你一个可执行的参考框架。

1. 先别急着写代码：AI工程这条路到底该怎么走

1.1 为什么“从零开始”是最好的起点

很多人学AI的第一步不是补基础，而是直接去跑别人的开源项目。我之前也这么干过，克隆一个仓库，pip install一把梭，跑通demo的那一刻确实爽，但换个数据集、换种业务场景就立刻抓瞎。问题出在哪？出在你只看到了“别人的结论”，没看到“别人的决策过程”。

“from scratch”的核心价值，就是强迫你走一遍完整的决策链路：为什么要用这个模型而不是那个模型？为什么要这样处理数据？损失函数为什么选交叉熵而不是均方误差？这些东西在教程里往往被一句带过，但恰恰是面试和实际项目里最常考、最常卡住的点。

我的建议是：前三个月不要碰任何深度学习的封装库，先用NumPy把线性回归、逻辑回归、简单的两层神经网络手写一遍。这个过程很痛苦，但效果是立竿见影的——你会真正理解梯度下降在干什么、反向传播到底怎么把误差传回去的、学习率为什么不能随便调。这些底子打牢了，后面用PyTorch、用Transformers库都只是换工具的事，而不是重新学一遍。

1.2 AI工程的核心能力地图

AI工程不是一个单一技能，而是一组能力的组合。我习惯把它分成四层：

• 理论基础层：线性代数、概率统计、微积分、最优化方法。不需要你达到数学系水平，但至少要能看懂公式、能推导简单的梯度表达式。
• 算法模型层：经典机器学习算法（回归、分类、聚类、树模型）、神经网络基础、Transformer架构、大语言模型的核心机制。这一层是“算法工程师”和“AI工程师”的重合地带。
• 工程实现层：Python编程、数据处理、模型训练与调优、模型部署、API服务、性能优化。这一层是AI工程师区别于算法研究员的关键。
• 生产落地层：数据管道、评测体系、监控告警、实验管理、成本控制。这一层决定了你的模型能不能在真实业务里活下来。

如果你只想调API做应用，那第三层和第四层的前半段就够了。但如果你想成为真正意义上的AI工程师，前两层不能跳过。市面上很多速成班让你三个月就从零冲到ChatGPT套壳开发，结果就是大家都会套壳，但一遇到模型效果不好就没人知道怎么调。

你可以拿下面这个清单自测一下，看自己在哪一层还有缺口：

2. 地基三件套：数学、Python与机器学习基础

2.1 数学不是要你成为数学家，但要够用

我见过最极端的两个案例：一个是从头啃完三册《数学分析》结果代码一行没写，一个是完全零基础直接上手Transformer结果连损失函数都看不懂。这两种都不可取。AI工程所需的数学是“够用”就行，关键是知道自己缺哪块、去哪补。

线性代数里最核心的是矩阵乘法、转置、逆矩阵、特征值与特征向量。你不需要会证明，但要能直观理解：矩阵乘法为什么对应特征变换，特征向量在PCA里有什么用。这些在Transformer的QKV计算里会反复出现——Q @ K^T这一步本质上就是在做相似度计算，而缩放因子sqrt(d_k)是为了防止点积过大导致softmax梯度消失，背后的数学直觉就是高维向量的模长会随着维度增大而增大。

概率统计方面，重点掌握：概率分布（正态、伯努利、多项分布）、条件概率、贝叶斯定理、极大似然估计、期望与方差。交叉熵损失函数为什么要配softmax使用？因为softmax把logits变成概率分布，交叉熵衡量的是预测分布和真实分布的差异，这两个搭配起来梯度计算最稳定。这个理解是面试高频考点，也是你排查训练问题时的重要工具。

微积分这边，核心是偏导数、链式法则和梯度。反向传播的整个算法就是链式法则的工程化应用——你只需要记住一件事：每一层梯度的计算都依赖后一层的梯度，所以叫“反向”传播。最优化的核心是梯度下降及其变体，要理解学习率、动量、Adam优化器为什么这么设计。

2.2 Python生态与工具链

Python是AI工程的事实标准语言，但“会Python”和“会写AI工程的Python”是两码事。除了基本的语法、数据结构、面向对象编程之外，你需要熟练掌握以下工具链：

• NumPy：所有数值计算的基础。要熟练使用向量化操作，尽量避免写Python循环——同样的计算，向量化之后通常快几十倍。
• Pandas：数据处理的主力工具。要掌握数据清洗、分组聚合、缺失值处理、特征工程的常见操作。
• Matplotlib + Seaborn：可视化分析。模型训练时你需要看loss曲线、看数据分布，这些工具是基本功。
• PyTorch：深度学习框架。重点是理解nn.Module、DataLoader、optimizer、loss_fn这四件套的配合方式。

很多人会纠结要不要先学TensorFlow。我的建议是：直接学PyTorch。不是TensorFlow不好，而是当前学术界和工业界的生态已经明显向PyTorch倾斜，绝大多数预训练模型、研究代码、工具库都以PyTorch为基础。你学会PyTorch之后，再去看TensorFlow或者JAX，很多概念是互通的。

这里有一个实用的学习技巧：不要对着文档刷API，而是找一个真实的小项目，比如Kaggle上的Titanic生存预测，从数据加载、特征工程、模型训练到提交结果完整走一遍。过程中遇到什么API不会，就查什么API，这样记得最牢。

2.3 机器学习核心概念：一次讲透

机器学习的基础概念不需要多，但每个都要“真懂”。我按重要程度排个序：

第一个是过拟合与欠拟合。这是整个机器学习里最核心的现象。模型在训练集上表现好但在测试集上表现差，这是过拟合；在训练集上就表现很差，这是欠拟合。对应的方法分别是：增加数据量、增加正则化、减小模型复杂度；以及增加模型复杂度、减少正则化、训练更久。这个判断思路贯穿你整个AI工程生涯，因为调模型80%的时间都是在和过拟合博弈。

第二个是评估指标的选择。分类问题里，准确率在类别不平衡时会骗人——比如99%的样本都是负样本，那模型全预测负样本就有99%的准确率，但一点用没有。这时候要看Precision（查准率）、Recall（召回率）和F1分数。回归问题要看MSE、MAE，其中MSE对异常值更敏感，MAE更稳健。这个选择直接影响你对模型效果的判断，一定不能只盯着一个指标看。

第三个是数据划分与交叉验证。简单随机划分在大多数场景下可行，但时间序列数据必须按时间顺序划分，否则就是“用未来预测过去”，测试指标虚高。交叉验证能更稳定地评估模型，但代价是训练时间翻倍。在深度学习场景下，通常的做法是固定一个验证集，而不是做K折交叉验证，因为大模型训练成本太高了。

学习这一部分时，我强烈建议搭配动手实验：自己构造一个线性可分的数据集、一个非线性数据集、一个高噪声数据集，然后用逻辑回归、决策树、随机森林分别去跑，观察它们的决策边界和性能差异。这个过程能帮你建立非常重要的“模型直觉”——看到什么样的数据分布，大概就知道什么模型会表现好。

3. 从训练到应用：亲手构建一个完整的AI系统

3.1 第一个里程碑：用手写数字识别建立全局认知

MNIST手写数字识别被称为“深度学习界的Hello World”，但它值得做的原因不是简单，而是能让你在最短时间内把一套深度学习流程完整跑通。我当时做这个项目时，给自己定了一个要求：用三层不同的实现方式各做一遍。

第一遍用NumPy手写一个全连接网络。这一遍最痛苦，因为你要自己实现前向传播、反向传播、梯度下降。写完你会明白：loss.backward()这行代码背后到底发生了什么——它其实是在计算图中从输出端往输入端逐层求梯度，每一层的梯度都依赖上一层（从输出方向看）的梯度。

第二遍用PyTorch实现同样的网络，但不用nn.Module，而是手动定义权重和梯度更新。这一遍的目的是建立PyTorch和手写实现之间的映射：F.linear其实就是一个矩阵乘法加偏置，F.relu就是一个逐元素的非线性变换。一旦你建立了这个映射，PyTorch对你来说就不再是黑盒。

第三遍才用完整的PyTorch工程化写法：nn.Module定义模型、DataLoader管理数据、optimizer管理参数更新、torchvision做数据增强。这一遍是给你以后做项目打样的，后面的所有项目都可以复用这套模板。

做完这三遍之后，你还应该做一个实验：把学习率分别设成0.1、0.01、0.001，观察loss曲线的差异；把网络层数从2层加到5层，观察过拟合现象；往训练集里注入20%的随机标签，观察模型如何从“学规律”退化为“死记硬背”。这些实验的成本很低，但对理解“模型为什么这样表现”帮助极大。

3.2 大模型时代：应用开发的范式转移

2023年之后，AI工程的重心明显从“训练模型”转向了“应用大模型”。这不是说传统深度学习不重要了，而是工程范式发生了变化。现在的主流做法是：以一个强大的基座模型（比如LLaMA、Qwen、GPT系列）为基础，通过提示词设计、检索增强生成（RAG）、微调、Agent等手段，解决具体的业务问题。

这几条路线有清晰的适用边界，选错方向会很痛苦：

• 提示词工程：模型本身的通用能力够用，只是需要把问题描述清楚。成本最低，见效最快。适合客服问答、文本分类、信息抽取等场景。核心技巧是少数样本（few-shot）示例、思维链（CoT）提示、结构化输出约束。
• RAG（检索增强生成）：模型需要回答私有领域知识或最新信息。把资料库切片、向量化，用户提问时先检索相关内容，再把检索结果塞进提示词让模型生成回答。它的本质是“外挂知识库”，不用重新训练模型，更新知识只需要重新索引一遍文档。
• 微调：需要模型稳定地模仿某种风格、输出格式，或者需要掌握私有领域的特定行为模式。训练成本高，但能改变模型的行为模式。适合代码生成、特定领域写作、结构化信息提取等。
• Agent：需要模型自主完成多步骤任务，比如调用API、操作工具、做计划。让模型循环思考“当前状态→下一步动作→观察结果→继续”，本质是把大模型变成一个“决策大脑”。

这四个方向不是互斥的，真实项目里经常组合使用。我见过一个很典型的组合：企业内部合同审核系统，用RAG解决法律条款检索，用微调让模型输出标准的审核意见格式，再用Agent自动调用合同比对API做差异分析。

3.3 实战拆解：一个RAG问答系统的搭建过程

RAG是当前大模型应用里最值得深入掌握的技术，因为它在企业内部的落地场景非常广。我以一个“公司内部知识库问答系统”为例，拆解完整的搭建过程。

第一步：文档加载与分块。这一环看似简单，但直接决定系统效果的上限。你可能会想：“我直接把整篇文档塞给模型不就行了？”问题在于模型上下文窗口有限，而且长文档里的大部分内容是噪音，会影响检索和回答质量。我的做法是按语义分块：段落级优先，可以用LangChain或LlamaIndex的RecursiveCharacterTextSplitter，先按段落分，再按句子边界调整，让每个块保持语义完整。块大小有一个经验区间：中文场景200到500字比较稳，太短会切断语义，太长会引入无关信息。

第二步：向量化。用嵌入模型把每个文本块转成向量。嵌入模型的选型很关键，有几点经验供参考：领域匹配度比模型大小更重要，法律文档优先用法律领域微调的嵌入模型；中文场景优先考虑对中文分词友好的BGE系列等本土模型，这些模型在中文语义理解上通常优于通用英文嵌入模型；向量维度不是越高越好，不要盲目追求大模型——要结合向量数据库的检索性能综合取舍。

第三步：构建检索链路。用户提问后，把问题向量化，在向量数据库（milvus、FAISS、pgvector都可以）里做相似度检索，取Top-K个最相关的文档块。这里有两个细节需要特别注意：一是“检索”不只是向量相似度，像BM25这种传统的关键词检索在某些场景下效果反而更稳，很多生产系统会把向量检索和BM25做混合检索（hybrid search），然后做结果融合排序；二是Top-K不是越大越好，通常取3到5个块就够了——太多了会把不相关的噪音塞给模型，反而降低回答质量。

第四步：提示词组装与生成。把检索到的文档块拼进提示词，明确告诉模型：“请基于以下参考资料回答用户问题，如果资料中没有相关信息，请直接说明不知道，不要编造。”这个“拒绝编造”的指令非常重要，因为大模型的幻觉问题是RAG系统面临的最大风险。输出格式也建议结构化，比如要求返回“回答”和“参考依据来源”两个字段，这样用户可以溯源，也便于后续评测。

第五步：评测迭代。这是RAG系统能不能长期维护的关键。你需要准备一份评测集——50到100条真实业务问题，每条标注正确答案和对应的文档来源。每次改动检索策略、分块方式、提示词或嵌入模型，都要在评测集上跑一遍，对比回答准确率和检索命中率。我见过太多团队把RAG系统上线后就再也不管了，结果是业务数据更新了、问题分布变了，系统效果悄悄下滑却没人察觉。

4. 工程化是真正的分水岭：让模型跑在生产环境

4.1 部署：从Notebook到API服务的最后一公里

训练好模型只是完成了前一半工作，怎么让模型在真实环境中稳定服务，才是AI工程师和算法工程师拉开差距的地方。我自己第一次部署模型时就吃过不小的亏：在Notebook里推理一切正常，封装成API一压测就发现单请求耗时飙到1.2秒，根本没法用。

部署时的核心考量有这么几个：

首先是推理加速。模型加载到GPU后，推理速度的主要瓶颈是显存带宽和计算效率。常用的手段包括：混合精度推理（FP16/INT8量化）、批处理（把多个请求合并成一个batch）、模型蒸馏（用大模型教小模型）。对于大语言模型，vLLM这类高性能推理框架是生产环境的标配，它通过PagedAttention和Continuous Batching技术把吞吐量提升了数倍，实测下来非常稳。

然后是服务框架选型。FastAPI是目前最适合AI服务部署的Python框架，原生支持异步、自动生成API文档、性能也不错。关键是要处理好两个问题：一是模型加载要放在全局（Gunicorn多进程模式下，每个worker加载一次，避免重复加载），二是服务要支持超时控制和优雅重试——大模型推理不稳定，偶发超时很正常，客户端需要正确的重试策略。

最后是容器化与资源管理。Docker是基本功，你要能写出规范的Dockerfile——基础镜像要选带CUDA的版本，依赖要用requirements.txt或poetry锁定版本，模型文件通过启动脚本在容器启动时从对象存储拉取而不是打进镜像里（否则镜像动辄几十GB，发布一次要传半天）。GPU资源的调度在生产环境通常交给Kubernetes管理，但对于个人项目或小团队，用Docker Compose加单机GPU通常就够了。

4.2 评测与监控：没有评测就没有优化

我踩过最大的一个坑，就是上线了一个精心训练的模型，业务方反馈效果“很差”，但离线测试指标明明很好看。后来排查发现：离线测试集和线上真实数据分布严重不一致——测试集是人工精心标注的标准案例，而线上输入五花八门，很多噪声和特殊情况离线完全没覆盖到。

这个教训让我建立了两个习惯，值得所有做AI工程的人参考。

第一个习惯是评测集要和业务一起设计。建模型之前，先拉着业务方定义清楚“好”和“坏”的标准：什么场景必须答对、什么场景可以容忍模糊、什么场景绝对不能出错。然后围绕这些标准构造评测集，覆盖边界情况和异常输入。评测集里的每一条都要带着“为什么选这条”的意图，而不是随手从历史数据里抽样。

第二个习惯是线上监控必须从第一天就做。模型上线不仅仅是发布一个API，而是要构建一整套监控体系：输入特征分布漂移检测（训练时的数据分布和线上新进来的数据是否逐渐偏离）、预测置信度分布、业务指标的实时变化（比如问答系统的用户满意度、推荐系统的点击率）、以及系统稳定性指标（延迟、错误率、GPU利用率）。建议在服务部署的第一天就接入基础的日志和监控，哪怕先记录到日志文件里，也比事后补救强得多。

4.3 MLOps基础：让AI系统“可维护”而不是“一次性”

很多个人项目和初创团队做AI模型，模式是“训练一次、跑通就完了”。但模型不是写死的一次性代码，它在生产环境里是需要持续维护的活体系统。MLOps要解决的，就是让这个系统可重复、可追踪、可恢复。

先说实验管理。训练模型的过程本质上是“探索”，你今天改了学习率，明天改了模型结构，如果不做记录，几周之后就完全搞不清哪个配置产出了哪个结果。目前主流工具是MLflow和Weights & Biases，它们可以自动记录超参数、训练指标、模型文件、代码版本。哪怕只是个人项目，也建议养成一个习惯：每次训练都在MLflow里留一条记录，标注数据版本、代码commit号、超参数和结果指标。

再说数据版本管理。模型效果和训练数据强相关，数据一变，模型行为就可能完全变了。DVC（Data Version Control）这类工具能把数据集纳入版本管理，和Git联动。这样每次训练用的数据都能精确复现——排查线上问题或复现某个历史实验结果时，能轻松找到当时用的是哪一版数据。

最后是模型版本与回滚机制。生产环境里，模型升级必须支持“平滑发布”和“快速回滚”。平滑发布是让新旧模型模型同时在线，按比例切流量（比如先5%新模型，观察指标稳定后再逐步扩大）；快速回滚是当新模型出现问题时，能一键切回旧版本。这个机制不是可选项，而是生产环境的必需品——大模型时代，任何预先评测都有可能漏掉线上风险，发布机制本身就是最后一道防御。

5. 踩坑实录与进阶方向

5.1 新手最容易翻车的五个坑

这些年带新人和做项目踩过的坑实在太多，挑五个最高频的分享出来，都是血泪教训。

坑一：数据质量没验证就训。新手最常见的行为是拿到数据集不做EDA（探索性数据分析），直接就开始训练。结果训练loss降不下去，查了半天才发现数据里有大量重复、缺失、标签错乱。更隐蔽的是标签泄漏——有些特征实际上包含了未来信息（比如用“是否退款”去预测“是否满意”），训练时模型表现得特别好，一到真实场景就原形毕露。我现在的习惯是：动手训练之前，至少花半天时间做数据探索——看每个特征的分布、检查异常值、做特征和标签的相关性分析、确认没有泄漏。

坑二：过度依赖AI调试AI。大模型时代的一个新坑是“AI辅助开发依赖症”——出了问题直接把报错信息扔给ChatGPT，照着回答改，改完还错就再扔回去。不是说不能用AI工具，而是你先要有自己的判断：你应该先读报错信息、看调用栈、复现问题，形成自己的假设，再用AI工具验证。如果完全依赖AI，你会失去最重要的“调试直觉”——而这种直觉正是AI工程师的核心竞争力。

坑三：不读源代码。很多新手用熟了某个库就不再打开它的源码。但我强烈建议，至少每个主流库的核心模块要读一遍源码。比如PyTorch的DataLoader是怎么实现多进程加载的？Transformers库的generate方法是怎么实现beam search的？这些读一遍，你对框架的理解会从“用户”升级为“参与者”。“from scratch”精神在这个时代的最佳体现，不是什么都自己造轮子，而是拆开轮子看一遍再装回去。

坑四：只看准确率不看业务指标。技术上“模型效果不错”和业务上“这个系统能用”之间往往隔着很大的鸿沟。准确率提升2个百分点，如果线上用户根本感知不到，这个提升就没有业务价值。做AI工程项目，你要学会和老业务方对齐指标：你提出“准确率90%”，他们关心“能省多少人力工时”；你说“召回率提升了10%”，他们要问“这能带来多少转化率提升”。学会把技术指标翻译成业务收益，这是中级工程师到高级工程师的必修课。

坑五：忽视成本控制。大模型API按token计费，GPU训练按小时计费，成本说失控就失控。我见过一个团队做客服机器人大模型改造，直接调用外部商业API，上线第一个月账单就超预算三倍。后来改造为本地部署开源模型+提取高频问题缓存答案，成本降了80%，效果还更稳定。做AI工程，模型层面的优化是必要的，但成本思维同样重要——好的AI工程师不只是把模型做出来，还要在效果和成本之间算清账。

5.2 学习路径优化：怎样安排更高效

根据我自己的经验，从零基础到能独立负责一个AI工程项目的周期，大约是6到9个月（前提是保证每天2到3小时的投入）。这比很多速成班承诺的时间长，但踏实得多。时间分配可以参考这样的比例：

有个容易被忽略但非常关键的建议：早点开始写博客或做输出。不用等到全学完了再写，学到一个新知识就用自己的话整理成笔记。输出是最好的学习方式——当你试图向别人解释一个概念时，你会发现自己哪里“以为懂了但其实没懂”。我自己很多知识盲区就是通过写博客暴露出来的。

5.3 下一步：从AI工程师到AI系统架构师

如果你已经能独立完成一个AI应用从训练到上线的全流程，那接下来就可以往AI系统架构师的方向走了。这个阶段的核心不再是“把某个模型训好”，而是“设计一个稳定、可扩展、成本可控的AI系统”。

需要刻意锻炼的能力包括：大规模数据管道的设计（亿级数据的清洗、存储和调度）、多个AI服务之间的编排与协同（比如Agent架构下的多模型调用链）、AI系统与业务系统深度集成（权限控制、审计日志、与现有CRM/ERP打通）、以及系统可靠性设计（故障转移、降级策略、压测和容量规划）。

我的建议是不要急着跳槽或追求头衔，而是找一个真实业务场景，把一个系统的全链路问题都摸一遍。比如你做一个智能客服，不只是做一个问答API，而是把工单系统对接、用户身份识别、知识库更新机制、人工接管流程、会话日志分析全部拉通。这个过程会逼你面对大量“训练模型之外”的问题——而这些才是AI工程真正的深水区。

最后分享一个我个人的体会：AI工程领域变化太快，今天学的框架可能半年后就过时了，今天的主流模型可能下个月就不是最优选择了。但底层的东西——线性代数、概率统计、算法逻辑、工程方法论——是不变的。这也是“from scratch”最值得坚持的原因：它让你拥有的是稳固的底层框架，而不是一套精致但脆弱的工具技巧。构建自己的底层框架，需要耐心和时间，而这恰恰是快速迭代的行业里，最稀缺也最有价值的资产。