企业官网建设流程全解析

1. 这个项目到底在解决什么问题

第一次看到 "ai-engineering-from-scratch" 这个标题，我脑子里蹦出来的第一个念头是：又一个教人调包的教程仓库？但仔细琢磨了一下 "from scratch" 这四个字，我意识到它想做的事情可能完全不一样。市面上讲 AI 工程的内容，绝大多数是从import torch或者from transformers import ...开始的，你跟着敲一遍，模型跑起来了，loss 也降下去了，但真要问你一句"这个张量在内存里到底长什么样""反向传播的时候梯度是怎么一层层传回去的"，很多人是答不上来的。这个项目标题里的 "from scratch"，我理解它的核心诉求就是把这些被高级框架封装掉的底层细节重新摊开，让你从最原始的地方开始理解 AI 工程到底是怎么一回事。

说白了，这个项目面向的不是那种"我就想快速跑个 demo"的需求，而是面向那些已经不满足于当调包侠、想要真正搞明白 AI 系统底层运转逻辑的工程师。它解决的核心问题是知识断层——你会用 PyTorch，但你不知道 PyTorch 帮你做了什么；你能训练一个模型，但你说不清数据在 GPU 显存里是怎么流动的；你部署了一个推理服务，但你不清楚延迟到底卡在哪一层。这些断层在平时写业务代码的时候可能感觉不到，一旦遇到性能瓶颈、诡异 bug 或者需要做底层优化的时候，就会变成致命的短板。

我之所以对这个方向特别有感触，是因为我自己就经历过这个阶段。早些年做推荐系统的时候，模型训练慢得离谱，我第一反应是加机器、换更好的 GPU，结果折腾了一圈发现瓶颈根本不在硬件上，而是数据加载的 pipeline 写得有问题，CPU 到 GPU 的数据拷贝成了瓶颈。当时如果有人带着我从最底层的数据流开始梳理一遍，能省下我至少两周的试错时间。所以当我看到 "ai-engineering-from-scratch" 这个标题的时候，我第一反应就是：这东西如果做扎实了，对中级工程师往上突破是非常有价值的。

适合参考这个内容的人，我大致分三类。第一类是有一定编程基础、用过至少一个深度学习框架、但总觉得心里没底的工程师；第二类是想从传统后端或者数据方向转到 AI 工程方向、需要补齐底层认知的开发者；第三类是在做 AI 相关系统优化、需要理解每一层开销来源的架构人员。如果你是完全零基础、连 Python 都没写过，那这个方向的内容可能会让你有点吃力，建议先把编程基础和线性代数补一补再来看。

2. 从零搭建 AI 工程知识体系的整体设计思路

2.1 为什么"从零"比"从框架"更值得投入时间

我先说说为什么我认同 "from scratch" 这个思路，而不是直接教你用现成的框架。这里有个很关键的认知：框架是别人对底层逻辑的抽象，而抽象是有信息损失的。当你用nn.Linear(784, 256)的时候，你看到的是一个黑盒，你知道它做了一次线性变换，但你不清楚它内部是怎么初始化权重的、前向传播时矩阵乘法的维度是怎么对齐的、反向传播时梯度是怎么算出来的。这些细节在 99% 的场景下确实不需要你操心，但在那 1% 的关键场景下——比如你要自己实现一个自定义算子、要调试一个梯度消失的问题、要把模型量化部署到边缘设备上——这些细节就是决定成败的东西。

从零搭建的好处在于，你会建立起一套完整的因果链条。你知道数据从哪来、经过哪些变换、每一步的计算代价是什么、最终结果是怎么产生的。这种认知不是靠看文档能获得的，必须自己动手实现一遍。我自己的经验是，当我把一个最简单的两层神经网络用纯 NumPy 实现一遍、手动推导完反向传播的每一个偏导数之后，再看 PyTorch 的代码，感觉完全不一样了——我不再是在"使用"一个工具，而是在"理解"一个系统。

2.2 知识体系的层次划分

如果要系统地做这件事，我建议把整个 AI 工程的知识体系分成几个层次来推进，每个层次都有明确的"从零"目标。

最底层是数学与数值计算层。这一层要解决的是：标量、向量、矩阵、张量到底是什么关系，矩阵乘法为什么是那个计算方式，梯度是什么、为什么梯度下降能work，数值稳定性为什么重要（比如为什么 softmax 要做减最大值的处理）。这一层的"从零"意味着你要用纯 Python 或者 NumPy 把这些基础运算实现一遍，不依赖任何深度学习库。

往上一层是模型与算法层。这一层要解决的是：一个神经元是怎么工作的，多层网络是怎么组合起来的，损失函数是怎么定义的，反向传播的链式法则具体怎么推导，优化器（SGD、Adam）的内部逻辑是什么。这一层的"从零"意味着你要手写一个完整的训练循环，包括前向传播、损失计算、反向传播、参数更新，全部用 NumPy 实现。

再往上是训练工程层。这一层要解决的是：数据怎么高效加载和预处理，batch 怎么组织，学习率怎么调度，训练过程怎么监控，显存怎么管理，多卡怎么并行。这一层的"从零"意味着你要理解 DataLoader 的内部机制、理解梯度累积的原理、理解混合精度训练为什么能省显存。

最上面是部署与推理层。这一层要解决的是：训练好的模型怎么保存和加载，推理服务怎么搭建，延迟和吞吐怎么优化，模型怎么量化压缩。这一层的"从零"意味着你要理解模型序列化的格式、理解推理引擎的基本原理、理解量化的数学本质。

2.3 技术选型的考量

在"从零"实现的过程中，技术选型有几个关键决策点，我逐个说一下我的思考。

语言选择上，Python + NumPy 是几乎唯一合理的选择。Python 的语法足够简洁，不会让你在语言特性上分心；NumPy 提供了基础的数组操作和线性代数运算，但又没有封装到让你看不懂的程度。你完全可以从纯 Python 的 list 开始，然后逐步引入 NumPy 来加速，这个过渡过程本身就能让你理解为什么需要 NumPy 这样的库。

要不要用自动微分。我的建议是：第一阶段绝对不要用。自动微分（比如 PyTorch 的 autograd）虽然方便，但它恰恰把最需要你理解的东西——梯度的计算过程——给封装掉了。你必须先手推一遍反向传播，手写一遍梯度计算，才能建立起对梯度的直觉。等到你对手动求导已经非常熟练了，再去用自动微分，你就能理解它帮你省了什么、代价是什么。

要不要碰 GPU。初期不建议。CPU 上的 NumPy 足够你理解所有核心概念了，GPU 编程（CUDA）引入的额外复杂度（线程、block、shared memory）会分散你的注意力。等到你把 CPU 版本的完整流程跑通了，再考虑用 CuPy 或者自己写 CUDA kernel 来加速，那时候你对"为什么要用 GPU"会有更深刻的理解。

框架的学习时机。我的建议是：先自己实现一遍，再去学框架。这样你学 PyTorch 的时候，看到的不是一堆 API，而是一堆你曾经手写过的逻辑的封装。你会知道loss.backward()背后发生了什么，你会知道optimizer.step()到底更新了什么。这种"看穿"的感觉，是直接学框架永远得不到的。

3. 核心模块的从零实现与关键细节

3.1 张量与基础运算的手写实现

一切从张量开始。张量这个概念听起来高大上，说白了就是一个多维数组。但"从零"实现的时候，你要考虑的东西比想象中多。

最朴素的实现就是一个嵌套的 Python list，比如[[1, 2], [3, 4]]就是一个 2x2 的矩阵。但用 list 做矩阵乘法会非常慢，因为 Python 的循环开销很大。所以第一步的优化是引入 NumPy 的ndarray，它底层是连续的 C 数组，运算速度快几个数量级。但这里有个关键细节：NumPy 的数组在内存里是行优先（row-major）存储的，也就是说一个 2x3 的矩阵在内存里是[a00, a01, a02, a10, a11, a12]这样排列的。理解这一点对后面理解转置、reshape、广播等操作至关重要。

矩阵乘法是核心中的核心。假设你有两个矩阵 A（形状 m×n）和 B（形状 n×p），它们的乘积 C（形状 m×p）中每个元素的计算方式是：

C[i][j] = sum(A[i][k] * B[k][j] for k in range(n))

这个三重循环的朴素实现，时间复杂度是 O(m×n×p)。我建议你第一遍就用这个朴素实现，亲手感受一下它的慢。然后你可以对比 NumPy 的np.dot或者@运算符，感受一下优化后的速度差异。这个对比会让你深刻理解为什么底层库要用 BLAS（基础线性代数子程序）这样的高度优化库。

注意：手写矩阵乘法的时候，循环的顺序对性能影响巨大。Python 里for i: for j: for k和for i: for k: for j的速度可能差好几倍，因为后者对内存的访问更连续，缓存命中率更高。这个细节在写高性能代码的时候非常关键。

广播（broadcasting）是另一个必须理解的机制。当你用一个形状 (3, 4) 的矩阵去加一个形状 (4,) 的向量时，NumPy 会自动把向量"广播"成 (3, 4) 再相加。这个机制让代码简洁了很多，但也容易出 bug。我踩过的坑是：本来想按行归一化，结果广播的维度搞错了，变成了按列归一化，模型训练了半天 loss 不降，排查了好久才发现是这里的问题。所以我的建议是，在关键的地方显式地写reshape或者expand_dims，不要过度依赖隐式广播。

3.2 前向传播与反向传播的完整推导

这是整个从零实现里最硬核的部分，也是最能体现"理解深度"的地方。我拿一个最简单的两层全连接网络来举例。

网络结构是这样的：输入层有 784 个节点（对应 28x28 的图片），隐藏层有 256 个节点，激活函数用 ReLU，输出层有 10 个节点（对应 10 个类别），最后接一个 softmax 得到概率分布。

前向传播的过程：

z1 = x @ W1 + b1 # 线性变换，W1 形状 (784, 256) a1 = relu(z1) # 激活，形状 (batch, 256) z2 = a1 @ W2 + b2 # 线性变换，W2 形状 (256, 10) y_pred = softmax(z2) # 概率分布，形状 (batch, 10)

反向传播的核心是链式法则。我们要计算损失 L 对每个参数的偏导数。以 W2 为例：

dL/dW2 = dL/dz2 * dz2/dW2

其中dL/dz2就是 softmax 加交叉熵损失的梯度，有一个非常优雅的结论：它等于y_pred - y_true，也就是预测概率减去真实标签的 one-hot 编码。这个结论我建议你自己推导一遍，推导过程会让你对 softmax 和交叉熵的配合有深刻理解。

dz2/dW2就是 a1，因为 z2 = a1 @ W2 + b2，对 W2 求导就是 a1。所以：

dL/dW2 = a1.T @ (y_pred - y_true) / batch_size

继续往前面传，dL/da1 = (y_pred - y_true) @ W2.T，然后经过 ReLU 的反向：ReLU 的导数是 z1 > 0 时为 1，否则为 0，所以dL/dz1 = dL/da1 * (z1 > 0)。最后：

dL/dW1 = x.T @ dL/dz1 / batch_size

这些公式看起来简单，但真正手写代码实现的时候，维度对齐是最容易出错的地方。我的经验是：每写一行矩阵运算，都在注释里标清楚每个变量的形状。比如# x: (batch, 784), W1: (784, 256), z1: (batch, 256)。这样一旦维度对不上，你一眼就能看出来是哪一步出了问题。

实操心得：反向传播的调试有个非常实用的技巧——数值梯度检验。对于某个参数，你可以用(L(w+eps) - L(w-eps)) / (2*eps)来近似它的梯度，然后和你反向传播算出来的梯度对比。如果两者差异在 1e-6 量级以内，说明你的反向传播实现是对的。这个技巧帮我抓出过无数个 bug。

3.3 优化器的内部逻辑

很多人用 Adam 优化器用得很顺手，但问他 Adam 和 SGD 的区别是什么、为什么 Adam 通常收敛更快，就说不太清楚了。从零实现一遍优化器，这些问题就都清楚了。

SGD 最简单，就是w = w - lr * grad。它的缺点是：如果不同参数的梯度尺度差异很大，用同一个学习率就很难让所有参数都收敛得好。梯度大的参数会震荡，梯度小的参数会走得太慢。

Momentum 引入了动量概念，相当于给梯度加了一个"惯性"：v = beta * v + grad; w = w - lr * v。这样在梯度方向一致的维度上会加速，在梯度方向来回震荡的维度上会相互抵消。

Adam 则更进一步，它同时维护了梯度的一阶矩（均值）和二阶矩（方差）的估计：

m = beta1 * m + (1 - beta1) * grad v = beta2 * v + (1 - beta2) * grad^2 m_hat = m / (1 - beta1^t) # 偏差修正 v_hat = v / (1 - beta2^t) w = w - lr * m_hat / (sqrt(v_hat) + eps)

这里的偏差修正是个很精妙的设计。因为 m 和 v 初始化为 0，在训练初期它们的估计是有偏的（偏向 0），除以(1 - beta^t)正好能修正这个偏差。t 是训练步数，随着 t 增大，beta^t趋近于 0，修正项就趋近于 1，不再起作用。

我自己实现 Adam 的时候踩过一个坑：忘了做偏差修正，结果训练初期模型几乎不动，因为 m 和 v 都被初始的 0 拉得太小了。加上偏差修正之后立刻就正常了。这个细节在文档里往往一笔带过，但自己实现一遍就再也不会忘了。

3.4 数据加载与批处理

数据加载看起来是个"脏活累活"，但它对训练效率的影响可能比你想象的大得多。我前面提到过我自己踩过的坑：数据 pipeline 成了瓶颈，GPU 利用率只有 30%。

从零实现一个 DataLoader，核心要解决几个问题。第一是批处理：把数据集分成若干个 batch，每个 batch 包含固定数量的样本。batch size 的选择是个权衡——太小了梯度噪声大、训练不稳定，太大了显存吃不下、泛化可能变差。第二是打乱：每个 epoch 开始前把数据顺序打乱，避免模型学到样本顺序带来的虚假规律。第三是预取：在 GPU 计算当前 batch 的时候，CPU 提前准备好下一个 batch 的数据，这样两者可以并行，不会互相等待。

预取这个机制我要特别说一下，因为它是很多性能问题的根源。如果你用的是同步加载，流程是这样的：CPU 读数据 → 传给 GPU → GPU 计算 → CPU 读下一批数据 → ...。GPU 在 CPU 读数据的时候是空闲的，这就是浪费。预取的做法是用一个后台线程或者进程提前把数据读好放到队列里，GPU 算完当前 batch 立刻就能拿到下一批，几乎不需要等待。

注意：用多进程做数据加载的时候，Windows 和 Linux 的行为不一样。Linux 用 fork 创建子进程，可以共享父进程的内存；Windows 用 spawn，每个子进程都要重新导入模块。如果你在 Windows 上调试多进程数据加载，记得把主逻辑放在if __name__ == '__main__':里面，否则会无限递归创建进程。

4. 实操过程中最容易踩的坑与排查方法

4.1 梯度相关的典型问题

梯度问题是手写神经网络时最高频的 bug 来源，我整理了几种最常见的情况。

梯度爆炸：梯度的数值变得极大，参数更新后直接飞掉，loss 变成 NaN。原因通常是网络太深或者学习率太大。排查方法是打印每一层梯度的范数，看看是从哪一层开始爆炸的。解决方法有梯度裁剪（把梯度范数限制在一个阈值内）、降低学习率、加 BatchNorm。

梯度消失：梯度的数值变得极小，参数几乎不更新，loss 降不下去。原因通常是用了 sigmoid 或 tanh 这类饱和激活函数，或者网络太深。排查方法同样是打印梯度范数。解决方法有换用 ReLU 系列激活函数、加残差连接、用 BatchNorm。

梯度为 None：某个参数的梯度是 None，说明它在计算图里没有被用到。这种情况常见于你定义了某个层但前向传播时忘了调用它，或者变量名写错了导致实际用的是另一个变量。

下面这张表是我总结的梯度问题速查表，遇到问题的时候可以对照着排查：

4.2 数值稳定性问题

数值稳定性是另一个容易被忽视但影响巨大的问题。最典型的就是 softmax 的溢出。

softmax 的定义是exp(x_i) / sum(exp(x_j))。如果 x 的某个元素是 1000，exp(1000)直接溢出成 inf，整个计算就废了。解决方案是减去最大值：softmax(x) = softmax(x - max(x))。数学上这是等价的，因为分子分母同时乘了exp(-max(x))，但数值上安全多了，因为减完之后最大的元素是 0，exp(0) = 1，不会溢出。

交叉熵损失也有类似的问题。如果你先算 softmax 再算 log，log(0)会变成 -inf。正确的做法是用 log-softmax 直接计算，把 softmax 和 log 合并成一个数值稳定的操作。PyTorch 里的CrossEntropyLoss内部就是这么做的，这也是为什么官方推荐用CrossEntropyLoss而不是自己写softmax + NLLLoss。

实操心得：判断数值稳定性问题的一个简单方法是在代码里加断言，比如assert not np.isnan(loss)和assert not np.isinf(loss)。一旦出现 NaN 或 inf，立刻中断训练并打印相关信息，比等到训练完发现结果不对再回头排查要高效得多。

4.3 维度不匹配的排查技巧

维度不匹配是另一个高频问题，尤其是在手写反向传播的时候。我的经验是建立一个"维度日志"的习惯：在关键的计算步骤后面打印或者注释每个张量的形状。

比如前向传播的时候：

# x: (batch, 784) # W1: (784, 256), b1: (256,) z1 = x @ W1 + b1 # z1: (batch, 256) a1 = np.maximum(0, z1) # a1: (batch, 256) # W2: (256, 10), b2: (10,) z2 = a1 @ W2 + b2 # z2: (batch, 10)

反向传播的时候，每一步的形状应该是前向传播的"镜像"：

# dz2: (batch, 10) dW2 = a1.T @ dz2 # (256, batch) @ (batch, 10) = (256, 10)，和 W2 一致 db2 = dz2.sum(axis=0) # (10,)，和 b2 一致 da1 = dz2 @ W2.T # (batch, 10) @ (10, 256) = (batch, 256)，和 a1 一致

一个非常实用的检查规则是：每个参数的梯度形状必须和参数本身的形状完全一致。如果dW2的形状和W2不一样，那肯定是某一步的矩阵乘法顺序或者转置搞错了。这个规则能帮你快速定位大部分维度问题。

4.4 训练不收敛的系统性排查

训练不收敛是最让人头疼的问题，因为可能的原因太多了。我一般按照下面的顺序系统性地排查。

第一步，检查数据。把 batch 里的几张图片可视化出来看看，标签对不对，像素值范围是不是正常的（比如归一化到 0-1 或者 -1 到 1）。我遇到过好几次数据预处理写错导致模型完全学不动的情况，比如图片通道顺序搞反了、归一化用了错误的均值方差。

第二步，检查损失函数。用一个极小的数据集（比如 10 张图片）去训练，看看模型能不能过拟合。如果连 10 张图片都过拟合不了，那肯定是代码有 bug，而不是模型能力不够。这个"小数据集过拟合测试"是我最常用的调试手段，能快速区分"代码问题"和"模型/数据问题"。

第三步，检查学习率。学习率太大 loss 会震荡甚至爆炸，太小 loss 降得极慢。可以试试用学习率扫描：从 1e-5 到 1e-1 取几个值分别跑几百步，看哪个学习率的 loss 下降最快。

第四步，检查初始化。如果权重全部初始化为 0，所有神经元的输出都一样，反向传播的梯度也一样，网络永远学不到东西。正确的做法是用随机初始化，比如 Xavier 或者 He 初始化。Xavier 适合 tanh 激活，He 适合 ReLU 激活，因为 ReLU 会把一半的神经元置零，需要更大的初始方差来补偿。

5. 从手写实现到工程落地的衔接

5.1 什么时候该切换到框架

手写实现是为了理解原理，但真正做项目的时候，你不可能什么都从零写。那么什么时候该切换到框架呢？

我的判断标准是：当你对某个模块的原理已经足够清楚，手写实现不再能给你带来新的认知的时候，就该用框架了。比如你已经手写实现过一遍完整的训练循环，理解了前向、反向、更新的每一个细节，那再做新项目的时候就没必要再手写一遍了，直接用 PyTorch 效率高得多。

但有些东西我建议你始终保持手写实现的习惯，比如自定义的损失函数、自定义的评估指标、数据预处理逻辑。这些部分往往和业务强相关，框架提供的通用实现不一定满足你的需求，而且这些部分的逻辑通常不复杂，手写反而更清晰可控。

5.2 性能优化的层次

当你把功能跑通之后，下一步就是性能优化。性能优化也是有层次的，从高到低依次是：算法层面、数据层面、模型层面、算子层面、硬件层面。

算法层面的优化收益最大，比如换一个更高效的优化器、用更好的学习率调度策略、减少不必要的计算。数据层面的优化包括更高效的数据加载、更好的数据增强策略、更合理的 batch 组织。模型层面的优化包括剪枝、量化、知识蒸馏。算子层面的优化包括用更高效的算子实现、融合多个算子减少内存访问。硬件层面的优化包括用更适合的硬件、优化内存布局、提高缓存命中率。

我自己的经验是，大部分性能问题其实出在数据层面和算法层面，而不是算子层面。很多人一上来就想着写 CUDA kernel 优化算子，结果发现瓶颈根本不在那里。先用 profiler 找到真正的瓶颈，再针对性地优化，这个顺序不能反。

5.3 从实验代码到生产代码的差距

实验代码和生产代码之间有巨大的鸿沟，这个鸿沟往往被低估。实验代码只要能跑出结果就行，生产代码要考虑的东西多得多：错误处理、日志记录、配置管理、版本控制、可复现性、可扩展性、监控告警。

我踩过的最大的坑是可复现性。实验阶段随机种子没固定，跑出来的结果每次都不一样，调参的时候根本分不清是参数改了起的作用还是随机性导致的。后来我养成了习惯：所有涉及随机的地方都固定种子，包括数据打乱、权重初始化、dropout。这样至少能保证同样的代码跑出同样的结果。

另一个坑是配置管理。实验阶段超参数都是硬编码在代码里的，改一个参数要翻半天代码。后来我改成了用配置文件管理所有超参数，代码里只读配置，这样调参的时候只改配置文件就行，代码完全不用动。这个习惯在项目变大之后能省下大量时间。

实操心得：从实验代码到生产代码，我建议做一次"代码审查"式的重构。把所有的硬编码提取成配置，把所有的 print 换成 logging，把所有的 assert 换成显式的错误处理，把所有的魔法数字加上注释说明来源。这个过程虽然枯燥，但能帮你发现很多隐藏的问题。

6. 我在这条路上的一些真实体会

写到这里，我想分享几个我自己在这条"从零"路上摸爬滚打出来的体会，可能比具体的技术细节更有价值。

第一个体会是：不要追求一次就写对。我刚开始手写反向传播的时候，总想着一次推导正确、一次写对代码，结果卡在一个地方好几天。后来我改变了策略：先写一个最粗糙的版本，用数值梯度检验确认正确性，然后再逐步优化。这个"先跑通再优化"的思路，让我后面的效率高了很多。

第二个体会是：理解比记忆重要。反向传播的公式我可以背下来，但背下来的东西遇到变体就不会用了。只有真正理解了链式法则的本质——"沿着计算图反向传播，每一步乘以局部梯度"——才能应对各种复杂的网络结构。所以我在学习的时候，会刻意去推导不同结构的反向传播，比如带残差的、带注意力的、带循环的，每推导一次理解就深一层。

第三个体会是：工具是手段不是目的。NumPy、PyTorch、TensorFlow 这些都是工具，它们的存在是为了让你更高效地实现想法。但如果你不理解工具背后的原理，你就只能被工具牵着走，工具不支持的功能你就做不了，工具出问题你就束手无策。从零实现一遍，本质上是在夺回对工具的掌控权。

第四个体会是：教别人是最好的学习方式。我在学这些东西的时候，会强迫自己把理解写成笔记、讲给同事听。每次讲的过程中都会发现自己理解不到位的地方，然后回去补。这个"输出倒逼输入"的循环，是我进步最快的方式。

最后说一个具体的建议：如果你打算走这条路，给自己定一个明确的项目目标，比如"用纯 NumPy 实现一个能识别手写数字的神经网络，准确率超过 95%"。有了具体目标，学习就有了方向，遇到问题也知道该往哪个方向找答案。漫无目的地看教程，效果远不如带着目标去实现一个东西。