别人问我怎么入门 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[fW{i}] rng.standard_normal((layer_sizes[i], layer_sizes[i - 1])) * 0.01 params[fb{i}] np.zeros((layer_sizes[i], 1)) return params def forward_propagation(X, params, activationrelu): cache {A0: X} for i in range(1, len(params) // 2): Z params[fW{i}] cache[fA{i - 1}] params[fb{i}] cache[fA{i}] np.maximum(0, Z) if activation relu else Z Z_final params[fW{len(params)//2}] cache[fA{len(params)//2 - 1}] params[fb{len(params)//2}] cache[fZ{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_model128注意力头数4编码器和解码器层数4batch size64学习率1e-3配合 warmup 线性衰减梯度裁剪最大范数设为 1.0优化器Adambeta1 0.9beta2 0.98epsilon 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。顺着这个思路我的排查顺序一般是序号检查项可能的原因与处理方式1数据与标签是否对齐检查 shuffle 和读取代码很多“loss 不降”其实是标签错位2损失函数是否出错数值验证输出随机权重下的 loss跟“理论期望值”对比3梯度是否正常打印每层梯度范数若出现 NaN 或指数级增大检查输入标准化4学习率是否合适用小批量数据做学习率扫描从 3e-4 到 1e-1 粗筛5模型权重初始化尝试减小初始化方差或用推荐默认值不要盲调有一回我训练的文本分类 loss 在 2.2 附近纹丝不动折腾了一天最后发现是数据加载的一个低级错误标签做了 shuffle 而文本没有相当于模型一直在看完全错配的配对。这类 bug 在框架里不会报错只能靠“抽样打印输入输出”来检查。所以后来我养成一个习惯每次训练前一定要可视化 5 到 10 条训练样本人工确认“数据进去了且对应的标签是对的”。4.2 数据质量问题的三个隐蔽大坑第二个高频问题是数据质量。眼看过拟合的曲线引起了注意其实问题往往不只出在模型复杂度上更有可能在数据里。三个隐蔽的坑必须拉出来遛遛。第一个坑是标签噪声。标注人员或者爬取脚本难免会带来一批错误标签。处理办法是对训练集做一个“难例挖掘”先用当前模型对所有训练样本做一次预测把模型置信度高但标签相反的样本抽出来人工复审。这个办法每次都能发现至少 2%-5% 的脏标签而这几个点的标签噪声很可能就是耗时数天的调参时间被浪费的根源。第二个坑是数据泄漏。你以为模型学得好其实它抄了答案。常见泄漏场景包括做特征工程时用了目标变量的未来信息、去重时把同一个样本的 train/test 双份保留、文本分类中对全文做了词频统计而测试时也用了同样的全局词汇表。防止办法其实很简单做数据划分时把 test 集放在一个彻底独立的文件夹里任何统计特征都只在 train 内计算然后用验证集来确认。第三个坑是类别不平衡。在一个 99:1 的二分类任务里全预测为多数类就能刷到 99% 准确率但这没有任何工程价值。这时候血泪教训是不仅要用 PR 曲线看效果还要在训练里使用类别权重或者用重采样策略。有一个项目里我只把少数类权重调到了 3.0F1 就从 0.22 升到了 0.67代价仅仅是多调了一下损失函数的 weight 参数。4.3 显存不足与训练速度的实战优化手记“CUDA out of memory”是每个 AI 工程师都熟悉的红色恐怖片。我的第一个深度学习项目batch size 设成 3212G 显存直接爆掉。起初我以为只有换卡一条路后来发现这是几十个优化点可以慢慢挤出来的。第一梯队方案是梯度累积。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_memoryTrue我的数据加载时间从每 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 学习中的一大阻碍但不是逃不掉的门槛。我按预算整理了三档配置方案每档都能支撑前面五个阶段的学习只是体验不同。档位配置参考能做什么注意事项入门档16G 内存 GTX 1660 6G所有经典模型、小型 Transformer、推理部署流程训练大模型只能靠云 GPU配 CPU 训练不行等待时间很长标准档32G 内存 RTX 4070 12G/3080 10G微调中小模型、常规 CV/NLP 项目基本可以覆盖 90% 的学习和实验场景舒适档64G 内存 RTX 4090 24G可跑 13B 级别模型的低精度微调、本地推理注意电源和散热攒机别省没有本地显卡的同学我的建议是优先白嫖 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 的迷茫期与其收藏更多教程不如选一个小问题把整条链路走通。那在你亲手跑通第一个模型部署接口的深夜你会明白这些折腾全部值得。