企业官网建设流程全解析

别人问我怎么入门 AI 工程，我从来不会甩一个“快跑”的表情包，也不会直接丢一个课程链接。我会告诉他：别急着上框架，先写一次线性回归，再手推一次反向传播，把整个训练循环在 Numpy 里跑通一遍，然后再去用 PyTorch。

这个项目标题“ai-engineering-from-scratch”之所以被我记到现在，是因为它的内核不是“教你调 API”，而是“把 AI 工程这条链路，从地基到天花板上所有承重墙，亲手搭一遍”。它解决的问题很具体：为什么你的模型在验证集上表现不错，上线之后就垮掉？为什么别人的显存只占 6G，你的 12G 都不够用？为什么开源的代码你照着复现，loss 就是下不去？这些问题的答案，都不在框架文档里，而在你对底层原理和工程细节的掌握程度里。

这篇文章我会把整个项目的完整学习路径、关键实践环节、还有我踩过的坑，全部分享出来。适合正在转型 AI 方向的开发者、刚入门的算法工程师、以及想建立工程化思维而不是只会跑通 demo 的人。

1. 从“调 API”到“自己造轮子”：这个项目到底在做什么

很多人会有疑问：2025 年了，LLM、工具调用、RAG 这些东西满天飞，还有必要从零开始学 AI 工程吗？我的判断是，这件事不仅有必要，而且比任何时候都有必要。原因是：工具的易用性在提高，但问题的复杂性也在提高，你不会修车，车坏了就只能被撂在路上。

1.1 直接调 API 和懂 AI 工程的本质区别

直接调 API 解决的是“有没有”的问题，AI 工程解决的是“好不好、稳不稳、贵不贵”的问题。我用一个开车的类比来解释。调用现成模型、套用开源代码，就像你拿到一本驾照，能把车从 A 点开到 B 点。AI 工程能力则像是修车和改装车的技能，车一旦在荒郊野岭抛锚，你能打开引擎盖，判断出是火花塞的问题还是油路的问题，甚至顺手做一个临时修复让车重新上路。

具体到工作场景，区别会变成几个非常现实的问题。第一，当 prompt 怎么调都不稳定、模型输出一会儿好一会儿坏的时候，你能不能从数据层面找到根因？第二，当模型推理时延太高、吞吐量上不去，你能不能通过量化、剪枝、算子融合、并发改造等手段来优化？第三，当数据分布发生漂移，线上表现持续下滑，你有没有监控指标和持续训练的策略来应对？

这些能力没有一样是“调 API”能得到的。如果只是在应用层做胶水开发，那么你会永远被模型能力、框架性能、硬件资源这三座大山压住，没有任何主动权。

1.2 从零开始构建带来的三层回报

把整个 AI 工程链路从头做一遍，我觉得回报至少有三层，而且每一层都直接对应到实际能力。

第一层是“永不迷路”的理解力。当你手写过一个反向传播，你就能回答“为什么 ReLU 比 Sigmoid 更适合深度网络”——不是背答案，而是你能在梯度传导的数值过程中直观地看到原因。当你自己实现过注意力机制，你才能真正读懂大模型的 KV Cache 到底在缓存什么，为什么能省那么多算力。这种理解力，是你面对任何新模型、新架构时快速上手的底层支撑。

第二层是“问题定位”的工程直觉。这个项目的每个阶段都有自己的产出物，不是看完就算了。手写模型之后要做训练实验、要做数据增强、要用一个真正的部署方案把模型跑起来。当你完整走过一遍之后再遇到线上问题，你会有一种直觉：“这个现象我以前见过，大概是哪个环节出了问题。”这种直觉不是天赋，是你亲手犯过错之后形成的肌肉记忆。

第三层是“成本可控”的方案能力。你从零训练过模型，你知道训练成本主要耗费在哪里；你从零搭过推理服务，你知道瓶颈可能出现在 GPU、显存、数据加载、网络传输、后处理等不同环节。这些认知会让你在做技术选型的时候趋近最优解：什么时候该用 7B 模型，什么时候 3B 就够了，什么时候只需要把规则写好不需要模型，这些都是“从零开始造过轮子”的人才能做出的判断。

1.3 项目和“教程”最大的不同：它以问题为驱动

市面上的 AI 教程大多是以知识点为章节来组织的，比如“第一章：线性代数”“第二章：机器学习算法”。而 ai-engineering-from-scratch 这个项目的组织方式，是以“亲手完成一次完整的 AI 工程任务”为驱动的。

我会从一个具体问题出发，比如“用 5000 条数据训练一个文本分类器”。这个问题会逼迫你从头走完整个链路：数据清洗、特征工程、建立基准模型、训练、评估、错误分析、迭代、再部署。每遇到一个环节缺失，就补一个环节。每遇到一个不知道的概念，就停下来搞懂它。这种方式很像搭积木，但你搭出来的不是一个静态的模型演示，而是一条能够持续迭代的流水线。

这也是为什么我建议所有想转行做 AI 工程的人，不要只收藏教程，要亲手把项目完整做一遍。收藏 100 个教程不能让你解决问题，但亲手完成一个从数据到部署的闭环项目，能。

2. 五阶段路线拆解：每个阶段具体学什么、做到什么程度

从零开始最怕的就是漫无目的。我在做这个项目的时候，把整条路线拆成了五个阶段，每个阶段都有明确的输入、输出和验收标准。你可以花两到三周跑完第一阶段，也可以花一个季度走完前三个阶段，但千万别跳步。

2.1 第一阶段：数学与编程地基，做到够用就行

第一个拦路虎通常是数学。很多人的误区是：我要先学完四本数学教材再开始写代码。完全不需要。AI 工程真正高频用到的数学工具，范围其实相当有限。

线性代数方面，你至少要能看懂矩阵乘法的计算过程，理解向量的点积、矩阵的转置，知道矩阵乘法为什么在神经网络的视角里代表“加权求和”。微积分方面，重点是链式法则，因为它就是反向传播的全部基础。你得能够求出一个复合函数的导数，并且能用数值梯度的方法验证解析梯度是正确的。概率统计方面，理解条件概率、贝叶斯公式、正态分布、最大似然估计的基本概念就足够起步了。

编程方面，除了 Python 的基本语法和数据结构之外，还有一个很多人忽略但极其重要的能力：Numpy 向量化。你需要习惯于不去写三层嵌套循环，而是用 Numpy 的广播机制、矩阵运算一次搞定。这不仅仅是性能问题，它塑造的是你用“张量思维”来看待数据的方式。这个阶段做完，你应该能独立实现矩阵乘法、softmax、交叉熵损失函数，并且用 Numpy 跑通一遍“前向传播—计算损失—反向传播—参数更新”的完整循环。

2.2 第二阶段：机器学习核心原理，学会选模型和判好坏

第二阶段的核心不是学会几个算法的名字，而是建立起一套用于模型选型和性能诊断的框架。我建议从线性回归和逻辑回归入手，然后是决策树和随机森林，最后是 SVM 和支持向量机的核技巧。这些经典算法在今天看来似乎不够时髦，但它们是理解偏差-方差权衡、正则化、特征重要性等核心问题的最佳载体。

每个算法你都要问自己三个问题：这个模型解决什么问题？它的损失函数是什么？它的正则化方式是什么？把这三个问题搞清楚了，你就会发现其实所有机器学习模型的骨架都是相通的。比如线性回归用平方误差损失，逻辑回归用交叉熵损失，本质上都是在找一个最优的参数分布，使预测和真实标签之间的差异最小化。

这一个阶段还要认真做评估指标的学习和实践。从哪里看出一个模型真的变好了？准确率还是 F1-score？在样本不平衡的情况下，准确率会产生什么样的误导？混淆矩阵应该怎么看？这些知识会在你后续每个项目里反复用到。我的建议是用 scikit-learn 把至少三个不同算法跑在同一份数据集上，做一次系统的对比实验，把实验结果整理成一张表格，你就能直观感受到不同模型的差异。这种表格整理的功夫，在今后的 AI 工程工作中会频繁用到。

2.3 第三阶段：深度学习与模型实现，手写是从零开始的精髓

到了深度学习部分，很多人的学习方式是从 PyTorch 的教程开始：“定义网络结构”“写训练循环”。我坚持认为，你至少要用手写的方式把一个小型神经网络跑通，再上框架。这一步补的不是知识，而是对万事万物的确信：你确信框架的做法是对的，因为你用 Numpy 手动实现过完全一样的事情。

建议的学习顺序是：先用手写的方式实现一个两层神经网络（MLP），解决一个二分类问题。在这个过程里你要手写正反向传播，包括 softmax 的导数、交叉熵的导数，以及每一层权重和偏置的梯度计算。当你看到手写的模型也能在 MNIST 上达到 90% 以上的准确率时，这种踏实感是任何教程都给不了的。

接下来是卷积神经网络（CNN），重点理解卷积操作、池化、感受野这些概念；然后是循环神经网络（RNN）和 LSTM，理解序列建模的问题和梯度消失的原因。最后，在有足够基础的情况下，着手实现一个简化版的 Transformer，理解自注意力、多头注意力、位置编码这些核心机制。

我特别要提醒的是，这个阶段每完一个部分，都要有一个可运行、可复现的项目作为产出。哪怕只是 200 行代码的迷你模型，它也是你之后自信心的来源。手写 Transformer 不是让你去挑战 GPT，而是让你在读懂大模型论文时不再是走马观花。

2.4 第四阶段：工程化与部署，补上最后 20% 的硬功夫

模型训练完毕，只算完成了 AI 工程的 80%，剩下的 20% 才是真正区分业余和专业的分水岭。如果你只会在 Jupyter Notebook 里跑通模型，那你依然还是一名“实验室研究员”。工程化要求你把模型变成一个持续运行、可控、可观测的服务。

这个阶段要掌握的内容主要包括：数据处理 pipeline 的建设，也就是从原始数据到特征向量的每次转换，都可复现、可追踪；训练流程的版本管理，即每次实验用到的代码、数据、超参数都必须记录下来，方便回滚和对比；模型推理服务的构建，包括用 FastAPI 或者 Flask 搭建模型接口、把模型导出为 ONNX、使用 GPU 推理等；以及基本的监控报警，例如请求延迟、吞吐量、模型返回质量指标等。

同时，你要具备一个意识：“部署”不等于“结束”。模型上线之后，你要思考如何应对数据分布漂移、如何收集反馈数据、如何安排定期的重新训练。这里有一个非常实用的小习惯：用 flow 的方式去记录数据版本和模型版本。当你发现线上效果变差，第一步应该想到的是“训练数据变了吗”，而不是“模型坏了”。

2.5 第五阶段：系统设计与性能优化，学会像架构师一样思考

最后一个阶段，是把 AI 模型放回整个系统当中去看。你要处理的不只是模型这个单点，还有特征服务、模型服务、缓存、降级、熔断、监控等周边模块。

举个例子，你在做一个推荐系统，模型本身做了千万级参数的排序，但真正影响用户体验的很可能是特征获取的延迟：如果某个实时特征要从多个内部服务去拿，拿到完整特征向量就要 200 毫秒，那么不管模型的精排有多准，最终效果都会被这种延迟拖累。这个阶段你要学会把整个链路拆开来看，从端到端的视角对每一个环节做性能分析和优化。

优化手段上，你至少要熟悉：模型量化的几种常见方案（动态量化、静态量化、半精度）、推理框架的选择、批处理（batching）策略，以及用 TensorRT 做服务化推理时怎么调整模型输入形状来提升吞吐。每条优化策略都要懂它节省了什么、代价是什么。量化自由省显存，但精确度会损失一点；增大 batch size 能提高吞吐，但会增加延迟，你要记得在两个指标之间做好取舍。

3. 实操复盘：手写神经网络、训练 Transformer、部署服务的完整记录

理论说再多，不如把项目实际操作的过程放上桌来看。整个项目里我印象最深的三个关键实践，分别是手写神经网络、训一个简化版 Transformer、以及把模型部署成真实服务。我挑重点讲讲，每一步的具体方案和背后的考量。

3.1 从线性回归到手写神经网络：那些“原来如此”的时刻

第一个关键实践是手写一个两层神经网络。我在做这个实验的时候，选择的数据集是 sklearn 自带的乳腺癌数据集，它只有 30 个特征、二分类任务，非常适合观察模型从随机到收敛的完整过程。

整个实现的核心是一个两层全连接网络，代码骨架如下：

import numpy as np def initialize_parameters(layer_sizes): rng = np.random.default_rng(42) params = {} for i in range(1, len(layer_sizes)): params[f"W{i}"] = rng.standard_normal((layer_sizes[i], layer_sizes[i - 1])) * 0.01 params[f"b{i}"] = np.zeros((layer_sizes[i], 1)) return params def forward_propagation(X, params, activation="relu"): cache = {"A0": X} for i in range(1, len(params) // 2): Z = params[f"W{i}"] @ cache[f"A{i - 1}"] + params[f"b{i}"] cache[f"A{i}"] = np.maximum(0, Z) if activation == "relu" else Z Z_final = params[f"W{len(params)//2}"] @ cache[f"A{len(params)//2 - 1}"] + params[f"b{len(params)//2}"] cache[f"Z{len(params)//2}"] = Z_final cache["A" + str(len(params)//2)] = 1 / (1 + np.exp(-Z_final)) return cache

我特别想说的是初始化参数时的“乘以 0.01”：这是一个极其微小但又极其重要的工程决策。如果不做这个缩放，模型的前向传播在每一层的输出方差会迅速变大，到了深层之后数值可能会溢出，梯度也会不稳定。这个 0.01 在我的项目里是一个人物化身的教学场景，它让模型从第一步训练开始就处于一个合理的数值区间。很多初学者直接上手框架的时候，对初始化策略的意义毫无感知，因为框架会自动处理好这些细节——但这恰恰是“从零开始”的价值。

训练过程中的“原来如此”时刻发生在验证数值梯度的时候。我手写了反向传播的数学推导，然后用数值梯度法去验证它：梯度近似等于损失函数在参数微小偏移后的差值除以偏移量。当这个数值和解析梯度的偏差降到 1e-6 以内时，我第一次从数字层面确认了“链式法则”在每个隐藏层逐一折叠的过程。这种从公式到数字再到代码的“三级确认”，是建立直觉最可靠的路径。

3.2 训练一个简化版 Transformer 的关键配置与避坑

第二个关键实践是从零实现并训练了一个简化版的 Transformer，在句子分类任务上验证了效果。这个实验的工程记录会很有参考价值，尤其是对于理解超参数的协同作用。

关键的训练配置可以整理如下：

• 序列长度：64，超出部分截断，不足部分用 padding token 补齐
• 词表大小：10000，用 SentencePiece 做子词切分
• 特征维度 d_model：128
• 注意力头数：4
• 编码器和解码器层数：4
• batch size：64
• 学习率：1e-3，配合 warmup + 线性衰减
• 梯度裁剪：最大范数设为 1.0
• 优化器：Adam，beta1 0.9，beta2 0.98，epsilon 1e-9

这里我想展开讲讲几乎所有人都会踩的坑：学习率的设置。Transformer 对学习率极其敏感，一个在 CNN 上毫无问题的 0.01 学习率，放到 Transformer 初始化初期就可能让 loss 一路跑飞。我在复现过程中第一次跑的 loss 前 50 步就从 4.3 崩到了 11.7，看了曲线图一眼就能判断是数值爆炸了。我采用了论文里经典的“warmup 之后再衰减”策略：前 1000 步学习率从 0 线性增长到峰值 1e-3，之后再按照步数的倒数衰减。这个设计的原因在于Transformer 底层的 LayerNorm 和残差结构在初始化阶段比较敏感，需要一段“预热期”把各层激活的分布稳定下来。

梯度裁剪也是我后期加上去的。如果不裁剪，偶尔几个特别大的梯度会让嵌入层和注意力矩阵的参数发生震荡，虽然不会让 loss 完全崩坏，但会导致训练曲线的尾巴出现毛毛躁躁的波动。把最大范数设为 1.0 之后，曲线立刻平稳很多，最后的验证准确率也提升了 1.4 个点，效果非常直观。

训练完之后，我没有直接拔掉模型跑路，而是记录了每一层注意力的可视化结果。这个检查非常必要：你会发现有些注意力头几乎完全退化，永远在关注同一个位置，这提示模型容量分配有问题，或者在训练时该层的学习率太大了。这类诊断手段，比单纯看准确率更能帮你理解“模型是不是真的学对了东西”。

3.3 模型部署的完整链路：从权重文件到线上服务

部署这一步，是我认为最容易踩坑、也最考验工程能力的环节。训练好的模型如果直接保存权重二进制，然后硬写一个 Flask 服务，这最容易出问题，因为你没有隔离训练环境和推理环境的差异。

正确的部署链路是这样的：训练好的模型先转换成 ONNX 格式，再通过推理加速引擎（我用的是 ONNX Runtime）加载，最后封装成 FastAPI 接口对外服务。转换过程里最常出的幺蛾子是“动态形状”问题。同一批次的推理请求长度可能不同，这就要求模型在转换时对序列长度这一维度设置成动态维度，否则一个 65 个 token 的请求会被拒绝。

还有一个非常微妙的细节：训练时大开速度的 Dropout 和 BatchNorm 在推理时必须关掉。你如果在导出模型时不把模型切到 eval 模式，BatchNorm 层的均值和方差使用的是当前 batch 的统计量，而不是训练积累的全局统计量，这个差异会让推理结果和训练结果有几分的偏差。别问我怎么知道的，我第一次部署就是这么翻车的。

服务化之后，我还会加上一些最基础的监控：把推理耗时、输入长度分布、每 batch 的响应数记录到日志里。看起来是微不足道的习惯，但当你需要排查线上问题时，这些日志就是救命的稻草。上线第一周我就发现 p99 延迟在下午四点之后明显升高，日志一看就知道是因为该时段输入文本长度变长了，触发了更长的序列处理路径，于是我做了一个预处理限长策略，把长文本截断，延迟立刻降了下来。

4. 踩坑实录：训练不收敛、数据脏、显存爆掉等问题排查速查表

做过真实项目的朋友都知道，AI 工程 80% 的时间不是在研究新算法，而是在排查问题。这里我把实战中最常遇到的四类问题整理成速查表，每条都是我自己或者身边同学血泪换来的经验。

4.1 训练损失不下降，问题到底出在哪

遇到损失曲线不动，不要立刻去改模型结构。先用一个“小数据过拟合测试”：从训练集里抽 100 条数据，用固定的学习率让模型硬跑，看损失能不能降到接近 0。如果连喂进去的数据都记不住，说明模型的表达能力或者数据流有问题；如果能记住，说明问题出在“泛化侧”，比如学习率太大、正则化太强、或者数据处理有 bug。

顺着这个思路，我的排查顺序一般是：

有一回我训练的文本分类 loss 在 2.2 附近纹丝不动，折腾了一天最后发现是数据加载的一个低级错误：标签做了 shuffle 而文本没有，相当于模型一直在看完全错配的配对。这类 bug 在框架里不会报错，只能靠“抽样打印输入输出”来检查。所以后来我养成一个习惯：每次训练前，一定要可视化 5 到 10 条训练样本，人工确认“数据进去了，且对应的标签是对的”。

4.2 数据质量问题的三个隐蔽大坑

第二个高频问题是数据质量。眼看过拟合的曲线引起了注意，其实问题往往不只出在模型复杂度上，更有可能在数据里。三个隐蔽的坑必须拉出来遛遛。

第一个坑是标签噪声。标注人员或者爬取脚本难免会带来一批错误标签。处理办法是对训练集做一个“难例挖掘”：先用当前模型对所有训练样本做一次预测，把模型置信度高但标签相反的样本抽出来人工复审。这个办法每次都能发现至少 2%-5% 的脏标签，而这几个点的标签噪声，很可能就是耗时数天的调参时间被浪费的根源。

第二个坑是数据泄漏。你以为模型学得好，其实它抄了答案。常见泄漏场景包括：做特征工程时用了目标变量的未来信息、去重时把同一个样本的 train/test 双份保留、文本分类中对全文做了词频统计而测试时也用了同样的全局词汇表。防止办法其实很简单：做数据划分时把 test 集放在一个彻底独立的文件夹里，任何统计特征都只在 train 内计算，然后用验证集来确认。

第三个坑是类别不平衡。在一个 99:1 的二分类任务里，全预测为多数类就能刷到 99% 准确率，但这没有任何工程价值。这时候血泪教训是：不仅要用 PR 曲线看效果，还要在训练里使用类别权重，或者用重采样策略。有一个项目里我只把少数类权重调到了 3.0，F1 就从 0.22 升到了 0.67，代价仅仅是多调了一下损失函数的 weight 参数。

4.3 显存不足与训练速度的实战优化手记

“CUDA out of memory”是每个 AI 工程师都熟悉的红色恐怖片。我的第一个深度学习项目，batch size 设成 32，12G 显存直接爆掉。起初我以为只有换卡一条路，后来发现这是几十个优化点可以慢慢挤出来的。

第一梯队方案是梯度累积。GPU 不够就 CPU 来凑，模型不更新，先把梯度攒几个 mini-batch 再统一更新。注意，我建议在调整“梯度累积”时同步把“lr”也调大一些：假设你累积 4 个 step 再更新一次，那相当于有效 batch size 变成了原来的 4 倍，学习率也可以适当放大，但需要做 warmup 过渡，否则开头会不稳。

第二梯队方案是混合精度和显存优化。使用 AMP 自动混合精度，让 float16 的矩阵乘法大幅降低显存占用，同时用梯度缩放避免精度丢失。我做一个 7 亿参数的模型时，开启 AMP 之后显存占用从 11.2G 降到了 6.8G，训练速度快了约 40%，效果没有明显变化。另一个实用技巧是设置梯度检查点，用计算换显存，把中间激活值在反向传播时重新计算，对于长序列模型，这个技巧能把显存占用再压掉 50% 左右，代价是训练时间变长。

最后一个技巧是深挖数据加载。很多人没意识到 CPU 预处理过慢也会拖慢 GPU 训练。把 num_workers 从 0 调到 4，配合 pin_memory=True，我的数据加载时间从每 epoch 120 秒降到了 35 秒，瓶颈立刻转移到了 GPU 计算。很多时候你们遇到的“GPU利用率只有 30%”的问题，根子大概率不是 GPU 不行，而是 CPU 加载数据和数据增强的并行度不足。

5. 工具链选型与环境搭建：个人学习项目的保姆级建议

聊完硬件性能优化，自然就回到一个很多入门读者朋友常问的问题：到底该用什么工具、要不要买显卡、有没有必要自己搭服务器。这里给一套我在这个项目中验证过的配置方案。

5.1 框架选型：主学 PyTorch，但要保留手写功底

AI 工程层面的框架选择，我的排序很明确：PyTorch 是首选，TensorFlow/Keras 可以了解但无需深耕，JAX 有兴趣再做拓展。PyTorch 的动态图机制让调试极其方便，你在 forward 函数里可以随时打印任何中间张量的 shape 和数值。这一点几乎是我衡量一个框架体验好不好的第一标准。

从学习路径上看，我建议你在手写完成 Numpy 版本的模型之后，再转到 PyTorch 重写同一个模型。因为你有过手写版本做参照，一眼就能看出框架帮你封装了什么、哪些地方做了额外优化。这种“先造轮子再用轮子”的顺序，会让你在排查 bug 时更容易知道问题出在框架层面还是模型层面。

另外要提醒的是：不要同时学超过两个框架。我在项目早期见过太多人今天学 PyTorch，明天又去看 MindSpore，最后停留在“语法都会一点、debug 完蛋”的尴尬状态。先集中精力把 PyTorch 训练、导出、部署流程完整跑通，之后再迁移自然水到渠成。

5.2 硬件和学习环境配置的三档方案

硬件确实是 AI 学习中的一大阻碍，但不是逃不掉的门槛。我按预算整理了三档配置方案，每档都能支撑前面五个阶段的学习，只是体验不同。

没有本地显卡的同学，我的建议是优先白嫖 Google Colab 的免费 T4 或者 Kaggle Notebooks 的 P100。这些环境已经预装了 PyTorch 和 CUDA，基本能满足你完成这个项目全流程。我看到过不少新手在本地安装 CUDA 上浪费掉三天时间，然后一个 epoch 都没跑过，这完全是本末倒置。初学阶段，网速比显卡更重要，能跑就行。

5.3 学习进度管理：怎么安排时间、怎么做实验记录

最后聊聊比工具更重要的东西：管理你自己。AI 工程内容量很大，如果没有节奏管理，很容易在中途产生“我是不是不适合这行”的挫败感。我的经验是把学习拆成“每周产出”而不是“每周学了多少课”：每周末必须有一个可运行的东西跑出来，比如一个训练好的模型、一个部署好的接口、一张效果对比图。这些看得见摸得着的产物，是抵抗焦虑最有效的工具。

另一个我被坑过很多次的经验是：每次实验要认真记录实验参数和结果，哪怕只是把种子、学习率、batch size、最终 loss 写进一个 Markdown 文件。最开始我觉得记录很麻烦，直到有一次我调参调出比之前好 3 个点的一版模型，但怎么也想不起来那次的参数是什么，我才意识到“玄学调参”其实是“没记录调参”。从零开始的项目，最重要的产出不是代码，而是你对“参数-行为-结果”三者关系的理解，而这理解只能靠系统记录来沉淀。

在多轮实验中，我还习惯使用实验管理工具来替代自己记笔记。如果你嫌这类工具入门曲线太长，也可以在命令行跑完 PyTorch 训练后把一行 JSON 配置打印出来，再和指标一起手动汇总到一份表格里，这一招已经能解决 60% 的混乱问题了。

一些最后的实在话

把 ai-engineering-from-scratch 这个项目从头走到尾之后，我对 AI 工程这件事有了一个更落地的看法：它不是一门能“学会”的知识，而是需要你反复“回来修修补补”的能力栈。从数学到编程，从建模到部署，从因果到成本，任何一个薄弱环节，都会在未来某个具体项目中成为你的瓶颈。

我个人体会最深的，其实是“从零开始”这四个字本身就极具价值。它让你因为原理受阻而不至于被工具绑架；因为亲手造过代码而不至于在黑盒面前彻底失语；更让你在面对新模型、新框架、新硬件时，不是看不懂和害怕，而是“这个我大概知道它底层在做什么，可以拆开看看”。如果你正处在入门 AI 的迷茫期，与其收藏更多教程，不如选一个小问题，把整条链路走通。那在你亲手跑通第一个模型部署接口的深夜，你会明白这些折腾全部值得。