要聊“ai-engineering-from-scratch”，我得先说实话：这年头敢把“from scratch”写进标题的人，要么是真想把地基打穿，要么是刚被某个AI教程坑过、决定不再当“调包侠”。我见过太多人顶着“AI工程师”的头衔，实则连模型输入输出的边界都说不清楚，更别提自己从头训练一个能用的模型。这个项目标题吸引我的地方，恰恰是它不打算走捷径——它默认你愿意从数学、数据、代码、模型、部署这条长路一步步走下来，而不是靠“复制一段prompt、换个API key”就算完事。

这个项目适合谁？两类人。一类是刚入行、被各种“五天搞定AI”的广告烦到不行、想老老实实把基本功补上的新人；另一类是已经在做业务开发、但总觉得自己对AI的了解停留在“调接口”层面、想往底层多走一步的工程师。它会告诉你：AI工程不是一门“玄学”，而是一套可以被拆解、被练习、被验证的工程能力。

下面我就以一份实操路线图的视角，把这个“从零开始”到底该怎么落地、会踩哪些坑、哪些环节最容易被低估，逐步拆开讲清楚。

1. 整体设计与路线拆解：为什么“从零”不是重复造轮子

1.1 这套路线的底层逻辑

“ai-engineering-from-scratch”并不是让你从晶体管开始造计算机，也不是逼你手写反向传播然后哭晕在厕所。它的核心逻辑是：你要理解AI系统每一层的关键机制，并在关键节点亲手实现一遍，从而获得对系统的掌控力。这就像学做菜——你不需要从种小麦开始，但你必须亲手和过一次面、炒过一盘焦了的菜，才能真正理解“火候”两个字意味着什么。全抄菜谱的人做不出自己的菜，全凭感觉的人上不了宴席。

所以，这个项目的路线设计通常遵循一条清晰的依赖链：数学基础 → Python工程能力 → 机器学习核心 → 深度学习 → 大模型应用与部署。每一层都建立在前一层之上，跳过任何一层，后面都会以“似懂非懂”的方式还回来。我在带人时最常看到的现象就是：跳过数学直接上Transformer，结果连“维度变换”都看不懂，调参全靠猜；跳过工程化直接跑模型，结果代码写得像仓库里堆满了过期罐头。

1.2 阶段划分与能力地图

我建议把整个学习过程拆成四个阶段，每个阶段设定明确的“交付物”，而不是“学了多少小时”：

• 阶段一：数学与Python基础。目标是能独立实现线性回归和KNN算法，并写出一份整洁的代码。
• 阶段二：经典机器学习。目标是完成一个从数据清洗到模型评估的完整项目，比如房价预测或垃圾邮件分类。
• 阶段三：深度学习与PyTorch。目标是理解自动求导、张量操作，并亲手训练一个CNN或简单的Transformer模型。
• 阶段四：大模型工程化。目标是搭建一个基于RAG的问答系统，或者完成模型微调与部署。

这四个阶段看起来普通，但你注意到没有：每个阶段都有一个“亲手做出来”的标志性产物。这正是“from scratch”这个项目最反套路的地方——它用输出倒逼输入，而不是用“收藏夹吃灰”代替“真正学会”。很多人学AI最大的误区就是“输入过载、输出不足”，刷了一百个视频，没跑通一个完整的项目。

2. 第一阶段实操：数学基础与Python工程能力怎么补

2.1 别再被数学吓跑——按需学习才是正道

很多人一听到“AI要学数学”就直接放弃，或者反过来买了一堆《数学分析》《高等代数》啃了三个月，然后发现跟AI离题万里。这两条路我都见过，都不对。

从AI工程的实际需求出发，你需要掌握的数学并不是“整个数学系”，而是四个板块的精选内容：

• 线性代数：重点是矩阵乘法、向量空间、特征值分解、SVD。这是理解神经网络层与层之间数据流动的“语法”。
• 概率论与统计：重点是概率分布、期望方差、贝叶斯思想、最大似然估计。这是理解模型不确定性、损失函数设计、评估指标的“语义”。
• 微积分（主要是多元微积分）：重点是偏导数、链式法则、梯度。这是理解反向传播的“物理引擎”。
• 最优化基础：重点是梯度下降、学习率、损失曲面。这是理解模型为什么能收敛、为什么震荡、为什么陷入局部最优的“动力学”。

我的建议是：不要按教材顺序从头啃，而是按项目需要倒推回去查漏补缺。比如你写线性回归时发现梯度下降公式推不动，就回头补偏导数和链式法则；你做矩阵分解时卡住了，就回头补特征值和SVD。这样学下来的数学是“带着问题找答案”，记忆深度完全不一样。

2.2 Python工程能力——决定你能否走到最后

数学决定你懂不懂AI，Python工程能力决定你能不能把懂的做出来。这个观点我在多个场合强调过：代码能力是AI工程师的“手”，很多人脑子会了、手不会，最后只能看着别人的开源代码发呆。

你需要重点练这几项能力：

• 用NumPy实现张量操作，包括广播机制、索引切片、矩阵运算，而不是只会调PyTorch的API。
• 写出结构清晰的Python代码：函数拆分、类型标注、模块化设计。AI项目一旦变大，代码混乱带来的心智负担会远超模型本身的复杂度。
• 熟悉至少一种虚拟环境和依赖管理工具。很多新手在同一环境里装了三遍不同版本的PyTorch，最后环境崩了，还以为是模型代码的问题。这种低级事故会浪费你一周时间。

我在实际带项目时，会让新人先用纯Python+NumPy实现一个两层神经网络，不许用PyTorch。这个练习逼着他们手动推导前向传播、反向传播、梯度更新的每一步。虽然写出来的代码可能比PyTorch版本慢一百倍，但做完这个练习之后，再回去看loss.backward()这行代码，你会清楚地知道它背后发生了什么，而不是把它当成魔法。

3. 第二阶段核心：经典机器学习——模型背后的“手感”

3.1 从回归到树模型：掌握模型选择的判断力

到了这个阶段，你会接触到线性回归、逻辑回归、决策树、随机森林、SVM、K-Means等经典算法。很多人觉得这些“过时了”，但我告诉你：经典机器学习是培养“模型手感”的最佳训练场，这种手感在大模型时代仍然是稀缺品。

什么叫手感？就是你看到一个数据集，能大概判断出：这数据适合线性模型还是树模型；特征之间是交互关系还是独立关系；数据量级够不够支撑复杂模型；类别不平衡需要怎么处理；过拟合风险出现在哪里。这些判断力来自对经典算法的深入理解，而不是来自“看了一篇综述文章”。

实操上，我建议你按这样一个流程走完至少一个完整项目：

1. 数据探索（EDA）：画分布图、相关性矩阵，理解每一列的含义和分布。
2. 特征工程：处理缺失值、类别编码、数值标准化、构造新特征。
3. 模型选型：从线性模型开始，再到树模型，对比效果。
4. 评估与调参：划分训练/验证/测试集，使用交叉验证，学习曲线诊断偏差与方差。

这个流程表面平淡无奇，但它教你一个核心习惯：不要把模型当黑盒，要用系统的证据链来做决策——这种习惯到了复杂的大模型项目里会救你的命。

3.2 最重要的不是调参，而是诊断

第二阶段最容易走偏的地方是：一头扎进“调参比赛”，用网格搜索搜了几百组参数，准确率从0.91提到0.92，就觉得自己进步了。但真正的工程能力体现在——当模型效果不好时，你能不能快速定位问题出在哪里。

我给你一个超实用的排查顺序：

• 先查数据：标签是否泄漏、训练集和测试集是否混入了未来信息、类别分布是否正常。
• 再查基线：一个简单的启发式规则（比如预测众数）能做到多少？如果模型比基线提升有限，说明特征或者模型能力有瓶颈。
• 然后查拟合状态：训练集损失高是欠拟合，验证集损失高而训练集很低是过拟合，两类问题的解法完全不同。
• 最后才查超参数：前面几步没问题，才值得花时间调参。

我见过一个真实的案例：有人花了两周时间调一个分类模型，准确率始终上不去，最后发现是因为他把“用户ID”当成特征喂进去了，导致训练集效果“虚高”，验证集直接崩溃。这种问题，靠调参永远解决不了，必须靠诊断。

4. 第三阶段关键跨越：从机器学习到深度学习与Transformer

4.1 PyTorch——从“会用”到“懂它”

深度学习阶段的核心工具，我首推PyTorch。为什么？因为它把“动态计算图”这种灵活的设计作为第一原则，对研究者和工程师都极其友好。TensorFlow虽然也很强，但历史上它的静态计算图设计让很多新手在调试时痛苦不堪，PyTorch的“跟写普通Python代码一样写模型”的特点，大大降低了心智负担。

但“用PyTorch写模型”和“理解PyTorch”是两码事。我建议你亲手做三件事：

• 用纯Tensor操作实现一个线性层（包括初始化、前向、反向）。
• 手动写一个training loop，包括数据加载、损失计算、optimizer.zero_grad()、loss.backward()、optimizer.step()。很多新手在这里漏掉zero_grad()，导致梯度累积，loss曲线乱成心电图。
• 理解Dataset和DataLoader的机制，以及batch_size、shuffle、num_workers这些参数对训练速度和稳定性的影响。

做完这三件事，你就算真正“上手”了PyTorch。我还可以告诉你一个小经验：先学会阅读PyTorch报错，再学写模型。框架的报错信息虽然有时候长到吓人，但仔细读往往能精确定位问题。训练中超过一半的“模型不收敛”问题，其实都是维度不对、数据类型不对、设备不统一造成的。

4.2 从CNN到Transformer：理解“注意力机制”不只是看看图

现在AI工程绕不开Transformer。很多人靠一张“Attention is All You Need”的架构图以为自己懂了，但真正实现一遍之后才会发现：之前以为理解的地方全是模糊的。

我的建议是分步骤实现一个简化版Transformer，你可以参考以下顺序：

• 先实现多头注意力机制本身：理解Q、K、V是怎么从输入变换来的、为什么除以sqrt(d_k)、为什么需要mask。
• 再实现位置编码：理解为什么Transformer没有天然的序列顺序感，以及正弦位置编码的几何意义。
• 然后组装Encoder层：包括残差连接、LayerNorm、Feed-Forward Network。
• 最后在玩具数据集（比如“复制序列”或“简单加法”）上训练它，观察loss下降的过程。

这整个过程可能需要你花一两周，但做完之后你会获得一种“通透感”：当你在大模型时代听到“上下文长度”“注意力掩码”“KV Cache”这些词时，你脑子里会有具体的张量流动画面，而不是一堆术语的空转。

4.3 本地跑LLM的硬件门槛与实操选择

走到大模型这一步，很多人会被硬件门槛卡住，我需要把真实情况说清楚。以我手头一台32GB内存的MacBook Pro为例，跑参数量为7B到8B的量化模型（Q4或Q5量化），用CPU推理大概每秒能生成5到10个token，完全可以用作实验和学习。如果想要更快的速度，一块24GB显存的消费级GPU（比如RTX 3090/4090）可以非常流畅地运行7B到13B的量化模型，甚至勉强尝试33B模型的极限量化版本。

• 7B-8B量化模型：MacBook Pro（32GB）可用CPU跑，速度可控可用。
• 7B-13B量化模型：24GB显存GPU可流畅运行，是本地实验的“甜点区间”。
• 70B级别模型：需要多卡或至少48GB以上显存，消费级基本不现实，建议走云服务。

基于这个现实，我建议初学者的本地实验路线是：先用7B级别的量化模型（比如Qwen2.5-7B-Instruct或Llama-3.1-8B）跑通推理、RAG、Function Calling这些应用场景；等需要微调时再根据显卡显存选择合适的基座模型。这样既能学到东西，又不至于被硬件劝退。

5. 大模型应用工程化：从“会跑模型”到“会做产品”

5.1 RAG、Agent与微调——怎么选

到了大模型应用阶段，你会面对三条技术路线：RAG、Agent、微调。很多初学者在这里犯迷糊，我的建议是：先搞懂它们各自解决什么问题，再决定从哪条路线入手。

• RAG（检索增强生成）解决的是“模型不知道你的私有知识”的问题，它通过外挂检索系统给模型提供参考材料，实现知识更新快、可控性强、幻觉率低。适合文档问答、客服助手、企业知识库等场景。
• Agent（智能体）解决的是“让模型会使用工具、完成多步任务”的问题，它通过将大模型与工具调用、规划、记忆相结合，处理复杂的任务流程。适合自动办公、代码助手、数据分析等场景。
• 微调解决的是“让模型的行为模式适配特定风格或任务”的问题，它直接改变模型的权重。适合领域术语极强、输出格式要求严格的任务。

我的建议是：初学者先从RAG入手。因为RAG的工程链路清晰、每一步都可以独立验证、出问题也容易排查。而Agent和微调都建立在“模型本身能力已经够用”的前提下，如果模型基础能力不足，强行做Agent会陷入无休止的prompt调试和工具联调地狱。

5.2 动手搭一个RAG系统

我带你过一遍最基础的RAG搭建流程，这个流程是我在多个项目中反复使用过的基准方案：

1. 文档加载与清洗：用PDF解析器或文本抽取工具把原始文档转成干净的文本，重点处理页眉页脚、表格、乱码。
2. 文本切分：按语义边界切分文本块，块大小通常在300-800字之间。这里有个经验值：块太小会丢失上下文，块太大则检索噪声增多。你需要根据你的文档类型实验。
3. 向量化：用Embedding模型（比如BGE或OpenAI的text-embedding系列）将文本块转成向量。注意Embedding模型一定要与你的文档语言、领域匹配。
4. 向量存储与检索：存入向量数据库（比如Milvus、Qdrant、Chroma），查询时用余弦相似度取Top-K相关块。
5. 提示词组装：把用户问题和检索到的文档块组装成Prompt，传给大模型生成回答，并强制要求“如果参考文档中没有答案，就坦诚说不知道”。

这个流程跑通之后，你才算真正体验了一次“大模型应用工程化”的完整闭环。之后你再优化重排序、混合检索、多路召回，才是有根之木。

5.3 模型部署的最后一公里

模型写得好只是起点，真正考验工程能力的是部署和上线。我在实践中体会到，部署环节最容易被忽视的往往是这几件事：

• 模型量化：把FP16模型压到INT8或INT4，推理速度可能提升2-4倍，显存占用大幅下降。用比如llama.cpp或vLLM来加载GGUF或AWQ格式的量化模型，是本地和小规模部署的主流选择。
• 并发与吞吐：生产环境需要同时服务多个用户，你的推理服务能不能扛住？vLLM的Continuous Batching技术能大幅提升吞吐，这是它成为部署首选的原因之一。
• 可观测性：我强烈建议从一开始就记录每次请求的响应时间、输入输出长度、Token用量，方便后续优化和排障。很多人跳过了这一步，等到线上出问题就两眼一抹黑。

部署还有一种被很多人忽略的“轻量方案”：如果并发要求不高（比如内部工具或学习项目），直接用FastAPI包一层模型推理接口就够了，不需要上重型推理框架。我在原型验证阶段通常先用FastAPI，等功能稳定后再迁移到vLLM做性能优化。

6. 常见问题与避坑指南

6.1 学习路线上的高频“翻车点”

我根据带项目的经验，整理了下面这份避坑清单，每一条都是真实踩过或者看别人踩过的：

• “拿来主义”式学习：GitHub上clone了一堆项目，跑通了就觉得自己会了。但你自己从头写过DataLoader吗？没有的话，换个数据集你可能就不知道从哪下手。
• 数学恐惧症和数学贪食症两个极端：要么完全不学数学，要么一头扎进数学分析无法自拔。正确姿势是“项目驱动、按需补充”。
• 死磕调参不重数据：数据显示一切问题的根源。先看数据，再谈模型。数据质量上去了，随便一个模型效果都会提升。
• 忽视代码工程规范：训练脚本、评估脚本、配置文件全揉在一个文件里。等到你要复现三个月前的实验时，那种痛苦会让你明白“规范”两个字的含义。
• 用“看过”代替“做过”：看了一百篇Transformer讲解，不如亲手实现一个。知识的掌握程度，以你能写出来的代码为准。

6.2 本地推理的硬件坑与省钱方案

硬件选择是另一个重灾区。我的建议是“先软件、后硬件”，在你确认自己真的需要本地大模型之前，不要急着买显卡。先用云GPU按小时租用（比如AutoDL或各大云厂商的GPU实例），把流程跑通、确认需求，再决定是否投入硬件。这个策略帮我省下了不少钱，也避免了冲动消费后吃灰的问题。

如果你确实需要本地部署，再考虑以下配置思路：

• 32GB内存的Mac或PC：可以跑7B量化模型，适合学习和轻量任务。
• 24GB显存的NVIDIA GPU：本地部署的“性价比甜点”，7B-13B量化模型流畅运行，可以做一些严肃的实验。
• 多卡或48GB以上显存：进入“高阶玩家”区间，适合跑更大模型或并发服务。

还有一个容易被忽略的问题：散热和噪音。高负载跑模型时GPU风扇的噪音非常大，如果你在办公室或家里部署，一定要提前想好放置位置和散热方案。

6.3 一个实操排查案例：本地模型越聊越“笨”

我遇到过一个很典型的排查案例。有个朋友部署了本地模型，刚开始对话很正常，但聊了一段时间后，模型开始回答得越来越简短，甚至有点“前言不搭后语”。他怀疑是模型出了问题，重装了一遍依然如此。

我问他：是不是没清理对话历史？他才想起自己的代码把整个对话历史都塞进了上下文窗口，越塞越长，模型能用的“有效注意力”越来越少，回答质量自然往下跌。解决方式也很简单：限制对话轮数、适时裁剪历史消息、或者做摘要压缩。

这个案例特别典型，因为它揭示了大模型应用工程中一个核心认知：上下文窗口不是无限免费的资源，它既是能力边界，也是成本边界。很多“模型变笨了”的问题，根因根本不在模型，而在应用的上下文管理策略。

7. 长期精进：如何让“from scratch”的底子持续生长

走到这一步，你已经具备了一个从零开始构建AI系统的基本能力框架。但我要泼一盆冷水：“from scratch”不是一次性的通关任务，而是一种持续的学习姿态。

技术栈会不断翻新。今天你熟悉的这些工具和框架，很快就会过时。但你在“from scratch”过程中练出来的核心能力——拆解问题的能力、亲手验证的能力、读文档和源码的能力、快速定位问题根因的能力——这些东西不会过时。

根据我个人的经验，我建议你在完成基础路线后，定期做三件事：持续跟进开源社区的新模型和工具（注意关注官方文档和release note，而不是二手中文解读）；给自己设定一个有挑战性的项目目标（比如“我能不能自己搭一个带RAG的私人知识助手”）；坚持输出和记录。写博客、写笔记、做分享，都是很好的方式，因为“能讲清楚”和“能写清楚”是最严格的验证标准。

最后再说一个心态上的建议：遇到不懂的，不要慌，去读源码、看官方教程、拆别人的代码。这个领域没有什么“看一眼就会”的神迹，所有看似云淡风轻的输出，背后都是一遍遍从零开始的笨功夫。