企业官网建设流程全解析

从刚收到这个项目标题"ai-engineering-from-scratch"的时候，我其实挺有感触的。因为单看这个名字，像是一个GitHub仓库的目录名，又像是一个人给自己定下的学习路线图。在AI领域待久了你会发现，真正卡住大多数人的不是"学不会某个模型"，而是"不知道怎么把学到的零散知识点串成一条能落地的工程链路"。这篇内容就是想围绕这个标题，把我自己走过的那条路——从只会调包、到能独立搭出一套完整AI应用的路径——拆开揉碎了讲清楚。无论你是有编程基础刚开始接触AI，还是已经在做算法但总觉得工程化能力不够，这篇文章应该都能给你一张还算清晰的地图。

1. 重新理解"from scratch"：不是从零实现，而是从底层打通

1.1 AI工程不等于调模型，更不等于写论文

先泼一盆冷水。很多人听到"AI工程"四个字，第一反应是"我要去训练一个大模型"，第二反应是"那我是不是得先把线性代数、概率论刷一遍"。这两个想法都容易把人带偏。

我见过太多这样的案例：一个人花了几周时间啃完了《机器学习》前五章，觉得梯度下降懂了、反向传播懂了，结果一上手TensorFlow，连数据管道怎么搭都不知道。反过来也有一类人，GitHub上收藏了几百个仓库，能跑通各种开源项目的README，但问他"这个模型上线之后怎么监控效果"，他完全没概念。

AI工程的核心，是把"模型能跑"变成"系统能用"。这里面包含了数据怎么来、特征怎么算、模型怎么训练、怎么评估、怎么部署、怎么监控、怎么迭代。它是一个完整的闭环，而大多数人只盯住了"训练"这一步，而且是带着"训练就是写个fit()函数"的理解去盯的。

所以"from scratch"这个表述，我理解的不是"从零手写Transformer"，而是说：你要从最底层的数据流和工程机制开始理解，把你之前依赖的现成框架、云服务、AutoML工具一层层剥开，搞清楚每个环节里到底发生了什么。这个"剥开"的过程，才是真正建立起AI工程能力的过程。

1.2 为什么现在特别值得走一遍完整的落地链路

一句话：因为工具越来越便宜，而工程判断力越来越值钱。

现在随便一个开源模型，推理能力都比三年前的付费API强。你可以在几小时内用现成工具调出一个不错的模型，甚至不用写训练代码。这说明什么？说明"做一个模型"的门槛已经被打得很低了。但问题反而变得更难了：你的数据质量行不行？你的评估指标选对了吗？你的上线方案能不能扛住真实流量？模型精度掉了你知不知道是怎么掉的？这些问题，没有任何工具能替你回答。

我之前帮一个团队做项目，他们的算法工程师花了两周微调模型，离线指标涨了三个点，兴冲冲要上线。我问了一句：你的线上评测集跟训练集的分布差距多大？他愣住了，因为他的训练数据是从公开数据集拼的，实际业务的用户行为数据根本没接进来。结果一上线，线上效果肉眼可见地崩了。这不是模型的问题，是工程链路的问题——数据流根本没打通。

这就是为什么"from scratch"走一遍这么重要。你需要亲手搭数据管道、亲手写评测脚本、亲手部署一次服务、亲手处理一次线上事故，你才能真正理解那些开源工具解决了什么问题，也才能在你的业务场景里做出"这里该用什么、那里为什么不行"的判断。

1.3 这条路径适合什么人

坦诚地讲，不是所有人都需要走这条路。如果你只是想在简历上多写一个"熟悉AI"的关键词，那没必要让自己遭这个罪。但如果你是这几类人，我强烈建议你认真把这条路走完：

• 有两年以上后端或数据工程经验，想往AI方向转型的工程师。
• 刚读完机器学习相关课程，但不知道下一步该干什么的学生。
• 已经在用AI API做业务，但觉得"调接口"天花板太低、想做更深入方向的人。
• 小团队里唯一要负责AI能力的"全干工程师"，没人帮你兜底，你只能自己把链路打通。

如果你是这些人，那接下来的内容基本就是为你准备的。

2. 打好地基：AI工程基础技术栈的搭建顺序

2.1 先别急着学框架，把Python工程能力补上

很多人一上来就PyTorch、TensorFlow、Transformers轮着上，学了两个礼拜，发现单独看每个API都懂，一组合起来就报错。原因不是框架难，而是Python工程能力不过关。

AI工程的代码和普通后端代码有一个显著区别：它混合了IO密集和计算密集的逻辑，而且数据离线流程和在线服务的形态差异很大。没有扎实的Python基础，你连数据管道里一个简单的generator用不好，就可能导致内存炸掉。

我个人建议在进入框架之前，先把这几块吃透：

• 虚拟环境管理（venv、conda、uv这些至少得会用一种，而且要理解为什么需要隔离依赖）。
• 文件IO与路径处理（os.path、pathlib、glob，这些基础但天天用）。
• 数据处理的基本功（用纯Python处理结构化数据的常见模式，别一上来就用pandas）。
• 装饰器、上下文管理器、迭代器生成器（这决定了你能不能写出优雅的数据管道代码）。
• 日志和异常处理（训练跑了两天崩了，你要是连日志都不会打，就只能干瞪眼）。

注意：这一步不需要达到Python开发专家的水平，但至少要能在不查资料的情况下写出一个体面的数据处理脚本。我见过太多人败在这一步，后面所有环节都跟着拖累。

2.2 Git、Linux和Docker：绕不开的工程三件套

如果说Python是你的"脑子"，那Git、Linux和Docker就是你的"手和脚"。AI工程不是单机游戏，你要跟数据集打交道、要跑分布式训练、要把模型部署到服务器上，这些东西一样都躲不开。

Git这一关，重点不是背命令，而是理解合作模式。你在开发时一定会遇到这种场景：你改了一个训练脚本，你同事改了另一个，你们俩同时commit，冲突了，怎么办？这种问题面试不会问，但实际干活儿天天碰到。你需要熟练使用分支管理、cherry-pick、rebase这些操作，并且养成每个commit都有清晰信息的习惯。

Linux方面，至少要做到在服务器上不慌。文件权限搞不定、磁盘满了不知道怎么清、nvidia-smi输出的信息看不懂、日志不会用grep管道去筛——这些看起来很小的问题，在实际训练和部署时都会变成大坑。

Docker则是个分水岭。能不能写出一个干净的Dockerfile，基本决定了你的模型能不能在别人的机器上重现。我见过一个项目，算法工程师本地跑得好好的，交付给部署团队的时候，环境装了两天都没跑起来——就是因为没有容器化。

从工程实操的角度，我建议你按下面这个顺序来练手：先在一台Linux机器上装好Python和GPU驱动，然后用Git管理你的第一个代码仓库，最后把整个环境打包成一个Docker镜像，推到镜像仓库里。这一步做完，你才算有了"别人能用你代码"的基础。

2.3 数学知识补到"够用"就行

接着说说数学。这可能是很多人最焦虑的一块，但我想给你吃颗定心丸：做AI工程，数学不需要学到数学系的深度，但有几个概念必须扎实到"直觉化"：

• 向量和矩阵运算：因为你的数据本质上都是张量，理解shape的变化规则能帮你避免大量报错。
• 梯度与反向传播的直觉：不需要会手动推导完整的链式法则，但你要理解loss下降和参数更新是怎么回事。
• 概率论的基本统计量：均值、方差、分布、采样，这些在数据处理和评估时天天用。
• 损失函数的几何含义：为什么回归任务用MSE，分类任务用交叉熵，这不是随便选的，你要理解背后的概率解释。

说白了，工程需要的数学是"给它一个公式你能大概知道它想干什么"的程度。更重要的是你要会做数值验证——当你怀疑某个实现不对，你可以拿一个小例子手算一遍，再跑代码对比结果。这种验证能力，比背公式实用得多。

3. 工程化核心技能：数据和训练不能只靠跑通

3.1 数据管道设计的"四段论"

数据是AI工程的起点，但也是最容易被低估的部分。很多新手拿到数据之后第一件事是数据清洗，然后直接丢给模型训练。这个流程本身没问题，问题在于少了一个关键环节：理解数据的来源和语义。

我自己的经验是，一条好的数据管道应该分成四段：

第一段，数据接入。不管数据在数据库、云存储还是日志文件里，都要有一套稳定的方式把它们拉下来，并且保证拉取过程可重入——就是说断了可以重来，而不是跑了一半数据交叉了。

第二段，数据校验。这一步很多人跳过，但恰恰是最省时间的。你需要检查字段是否有缺失、类型是否符合预期、数值范围是否合理。别小看这一步，训练时出现的各种奇怪问题，大概率是数据校验没做好。

第三段，特征工程。把原始数据转换成模型能用的形态。这里有个经验是，特征处理逻辑必须在训练和上线时保持一致。如果你在训练时用了一个特征工程的类，上线时又为了性能重写了一遍，几乎必然会出现"线上线下不一致"的bug——这可比模型精度低了麻烦得多。

第四段，样本存取。把处理好的样本存成统一格式。一般建议直接用TFRecord或Parquet这类列式存储，而不是CSV。不仅能节省大量存储空间，加载速度也是天壤之别。

我之前接过一个项目，他们一直说模型的效果时好时坏。我一看他们的数据处理代码，每次训练前都从原始日志里现做特征，结果不同日期的数据分布波动很剧烈。后来我帮他们改成"每日批处理生成特征快照 + 训练时直接读快照"的方案，问题彻底解决——因为特征分布的可复现性回来了，你才知道模型表现变了是数据变了还是模型变了。

3.2 训练脚本的正确打开方式

训练这块，新手最常见的错误是把训练代码和业务逻辑搅在一起，或者在一个Jupyter Notebook里又训练又画图又存储，结果代码跑完一遍，根本没法复现。

一个合格的训练工程流程，至少要有这些组成部分：

• 配置管理。超参数、数据路径、模型结构这些全部外部化，用一个配置文件控制，而不是把参数硬编码在代码里。即使你是一个人写代码，三个月后再来看这个项目，你也会感谢当时的自己做了这个决定。
• 可复现性。随机种子固定好了，环境依赖记录好了，数据版本固定了。做到这一步，你才能放心地说"我这次训练效果变差了，是因为我改了模型结构，而不是因为运气不好"。
• 实验记录。每一组实验的参数、指标、模型文件、日志都要有地方存下来，并且有统一的命名规则。不要把实验记录放在聊天记录或者本地文件名里。哪怕早期用个CSV记录都好，但一定要有。
• 训练循环的可视化。loss曲线、学习率变化、梯度范数，这些值在训练时要实时能看到。不是说你必须盯着屏幕看，而是出了问题你能第一时间发现，而不是等两天的训练结束了才知道早就跑偏了。

我看到不少开源项目的训练代码其实写得一塌糊涂，靠的是框架的默认行为和运气在跑。但你要按工程标准来做，该拆的模块拆开，该留的日志留好。这样你调模型的效率会高出一个档次——因为你永远知道上一次做对了什么、做错了什么。

3.3 评估不只是算个准确率

评估这一块，我想多说两句，因为这是区分"调包侠"和"AI工程师"的分水岭。

很多人在一两个公开数据集上看到点指标就兴冲冲觉得模型能用了，但放到真实场景里完全不是一回事。关键是你的评估方式要对齐你的业务目标。举个例子：你做的是一个商品推荐系统，离线你算AUC，0.75看着还行。但业务上真正关心的是曝光转化率，AUC涨了0.01跟转化率之间是什么关系？如果回答不了这个问题，你的离线评估再严谨，业务方也不会认可。

评估指标之外，更重要的是构建一个维度丰富的评测集。除了标准测试集，你至少要分出来这几类：

• 正常场景集：用来回归验证整体性能没有退化。
• 边界场景集：包含各种罕见的但真实可能发生的输入，看看模型在极限情况下表现怎么样。
• 噪声场景集：故意加入一些脏数据、乱序数据，模拟线上真实输入。
• 分群体评估：如果你的用户群体有明显的子群，按子群分别算指标，防止"平均指标好看但某些群体全崩"。

这些工作很繁琐，但它是你能在模型上线前发现问题的最后一道防线。花两三天把评测集建好，能帮你省下上线后踩坑的一整个月。

4. 部署与监控：模型上线才是工程真正的开始

4.1 模型部署的三种典型形态

模型训练完了，离线评估也过了，接下来就是上线。部署方式没有标准答案，取决于你的业务场景，但大致可以分为三种形态。

第一种是离线批量推理。比如每天的报表预测、批处理打标签。这种场景不需要在线服务，跑一个定时任务就行。工程重点在于任务调度和结果可追溯，模型输出要落库，方便事后分析。

第二种是在线API服务。模型作为一个HTTP服务对外提供推理能力。这种形态的技术栈很成熟，FastAPI这类工具负担得起大部分场景。重点在于服务的吞吐、延迟和可用性设计，模型推理通常要和业务代码分开部署，这样模型升级时不用重新发布整个业务应用。

第三种是边缘或嵌入式部署。如果模型要跑在手机或IoT设备上，你就需要做模型压缩，用量化、剪枝、蒸馏这些手段把模型变小变快。这是最考验工程能力的一种，因为资源约束极其紧张，一个算子一个算子的性能都要抠。

我在实际项目里最推荐的做法是：一开始就用容器把模型服务包起来，通过一个统一接口对外暴露推理能力。这个接口的内部实现是可以替换的——今天用PyTorch，明天换ONNX，后天换Triton，只要接口协议不变，对上层业务没有影响。这样一个小的架构决策，能让你后续持续优化模型的路径顺畅很多。

4.2 性能调优：不只是加GPU

部署完之后你大概率会遇到性能问题。这时候很多人第一反应是"加机器"或者"上更好的GPU"。但你应该先搞清楚瓶颈到底在哪里。

按我的排查习惯，顺序是这样的：

第一，看数据预处理占了多久。很多模型服务慢，不是因为推理慢，而是因为请求里的JSON解析、特征拼接这些Python代码太慢了。有时候把这些逻辑优化一下，性能能翻倍。

第二，看推理过程的batch策略。GPU是并行计算设备，一次处理一个请求和一次处理八个请求的时间差不了太多。所以有条件的场景可以做动态batching——攒几个请求一起推理——这是提升吞吐最有效的手段之一。

第三，看模型本身的优化空间。比如推理时关掉梯度计算、用torch.no_grad()、开启cudnn.benchmark、尝试FP16推理、把模型转成ONNX再优化一遍。这些操作都不复杂，但很多人根本没想到要去用。

如果这几个层面都看过了还是慢，这时候再考虑上多实例或者分布式推理也不迟。总之核心原则是：先定位瓶颈，再谈资源扩容，不要一拍脑袋砸钱。

4.3 监控：必须处理的三类信号

模型上线后，你的工作才真正开始。因为线上的环境不是静态的，今天的数据分布和明天的可能就不一样。不做好监控，模型在线上烂了几天你可能都不知道。

我建议至少监控三类信号：

第一类是系统指标。服务QPS、延迟P50/P99、错误率、GPU利用率。这些指标告诉你服务还"活着"没有。

第二类是数据指标。在线输入特征的分布和训练时的分布差异有多大。这是数据漂移的早期信号，你可以通过统计每个特征的均值、方差、取值频率来做监控。

第三类是业务指标。转化率、点击率、用户满意度这类真实业务指标。这个需要跟业务方配合定义清楚。

监控建立起来之后还有一个配套动作：模型版本管理。每次上线的模型要有独立的版本号，要能快速回滚到上一个版本。模型文件和配套的特征处理代码、评测结果都要绑定在一起。没有这套机制，一旦线上出问题，你连"现在跑的是哪个版本的模型"都说不清，排查起来就是灾难。

5. 一次完整的AI工程实操：三阶段路线图

5.1 阶段一：完成一个带API的端到端小项目

很多人会纠结"我应该先做个什么项目"，其实答案很简单：先做你日常能用一个小时写出来的、最无聊的AI应用。比如图片分类、文本情感分析，或者做一个API调用开源模型做摘要。

这个阶段目的不在"做着玩"，而在于打通流程。你需要经历：

• 用Python写一个数据下载和预处理的脚本，把数据从原始状态变成模型输入。
• 用现成框架训练一个模型，或者直接加载一个预训练模型做推理。
• 把推理逻辑封装成一个FastAPI服务。
• 在本地用curl测试接口，确认输出符合预期。
• 写一个Dockerfile把整个服务打包，跑通容器化部署。

完成这一步，你就算跨过了AI工程的门槛——因为你已经经历了一次完整的从数据到服务的流转。

5.2 阶段二：做一个需要自己处理数据的项目

第一阶段做完之后，你需要找一个"数据比较脏"的场景来练手。最典型的是爬一些公开的文本数据，或者用你工作里真实的数据（脱敏后）。这个阶段你不再用别人整理好的数据集，而是要自己处理数据获取、清洗、质量校验这一整套流程。

核心训练目标有三点：

• 你会真的遇到"数据里全是噪声"的情况，逼着自己写清楚数据校验逻辑。
• 你会意识到特征工程在真实数据上没那么轻松，而且特征逻辑的一致性问题会第一次暴露出来。
• 你会开始考虑"数据版本管理"，因为你会发现自己改了一版清洗逻辑后，之前的结果无法复现了。

这个阶段可以多花点时间，因为数据能力是AI工程区别于纯算法能力的核心差异。

5.3 阶段三：做一个包含训练、部署、监控的完整系统

第三步就是把之前的能力全部串起来，做一个完整系统。我的建议是做一个推荐系统或搜索排序类的项目，因为这类项目天然包含完整的闭环：数据回流、特征更新、模型周期性重训练、在线推理、效果监控。

具体来说，这个系统至少包含这些模块：

• 离线任务管道：每天定时拉取数据，生成特征快照，触发训练或增量微调。
• 模型仓库：记录模型版本、训练配置、评测结果。
• 在线服务：读取最新模型版本，对外提供推理接口。
• 监控与报警：定期检查线上特征分布和业务指标，发现异常时自动告警。
• 回滚机制：当监控发现效果下降时，能快速切回前一版模型。

做完这个系统，你能自信地在简历上写"具备从数据到模型到上线监控的完整AI工程实践经验"，这句话比任何单个模型比赛的获奖都有说服力。

5.4 贯穿全程的关键能力：代码设计意识

最后再补一个贯穿三个阶段的底层能力——代码设计。

AI工程代码跟写算法题不一样，它是长时间演化、多人协作、不断改动的"活系统"。如果一开始没有设计好代码结构，后面每次改需求都是一次灾难。

我给你几个具体的建议：

• 把数据读取、特征转换、模型定义、训练循环、评估逻辑拆成独立模块，接口尽量清晰。
• 不要全局修改变量，所有配置通过传参或者配置对象传递。
• 给自己写一个常用的项目模板，每个新项目从模板起步，可以在模板基础上快速迭代。
• 关键节点留出日志，尤其是数据处理和评估环节，方便排查问题。

代码设计这件事没有标准答案，但有一条红线：让未来的人（包括你未来的自己）在接手代码时，不会想要砸掉电脑重写。

6. 踩坑实录：AI工程路上最常见的五个问题

6.1 训练Loss不降反升，是怎么回事

这是新手最容易懵的问题。模型训练了两千步，loss不仅没降，还越来越高。我的排查顺序一般是：

先排除代码bug。最常见的是数据没做归一化，或者标签跟特征对不上，尤其要注意数据shuffle的时候特征和标签是不是同步的。

再排除学习率问题。如果loss直接爆到NaN，大概率是学习率太大了，可以试着把学习率调小十倍看看反应。

然后观察不同阶段的loss。如果前几步降得很快，然后突然不降了甚至反弹，那可能是模型结构问题或者优化器参数没调好。

最后再怀疑"模型本身是否能收敛"。有时候拿一个很小的样例数据先过拟合一下，如果小样例都学不到理想效果，那就是模型结构或数据本身有问题，不用浪费算力在大数据集上瞎试。

6.2 GPU利用率很低，核弹显卡用出了集显的效果

很多人一看自己的GPU利用率只有20%，就慌了。先说结论：不是所有场景都适合追求GPU高利用率。NLP里很多操作是逐token处理的，本身并行度就有限。

但如果你确实觉得需要榨干GPU，可以从这几个方面检查：

• DataLoader的num_workers设了没有，默认是0，意味着主进程在同步加载数据。设成4或8往往有明显改善。
• 训练循环里有没有在GPU和CPU之间频繁来回拷贝数据。
• 是不是模型太小，计算量还没数据加载的时间长。
• Batch size是不是太小，GPU没有足够的计算任务来填充。

有一个经典的经验是：GPU利用率低于50%的时候，先不要急着优化模型结构，大概率是数据管道拖了后腿。

6.3 数据泄漏：评估指标虚高的头号嫌疑人

数据泄漏是AI工程里最隐蔽的坑之一。表现形式千变万化，但本质只有一个：模型在评测时看到了它"不应该看到"的信息。

最常见的是时间序列场景的数据泄漏。比如你用某段时间的数据做训练集，后面时间的数据做测试集，如果特征里包含了未来窗口的统计值，那评估结果就是假的。

还有一种泄漏发生在数据预处理阶段。如果你在划分数据集之前就做了全局的标准化，那测试集的信息已经通过均值方差混进了训练集，指标虚高几乎是必然的。

对付数据泄漏，唯一的办法就是建立一个严格隔离的数据处理流程：把数据划分放在所有操作之前，一切预处理只基于训练集统计信息。养成这个习惯，能帮你避免90%的泄漏问题。

6.4 本地能跑通，上线就出错

这是一个让人血压飙升的场景：代码在本地明明跑得好好的，一部署到服务器就报错。排除环境问题之后，最可能的原因是：

• 数据输入的形态不一致。本地文件读出来的参数和线上请求的格式在类型、维度上有细微差别。
• 环境配置硬编码了本地路径。这是最经典的，模型加载路径写死成了本地的绝对路径。
• 依赖版本不一致。本地装的是PyTorch 2.1，线上还是1.13，API行为可能完全不同。

解决办法也很直接：从一开始就坚持所有路径用相对路径，依赖用lock文件管理，每次部署前先在一个全新的容器环境里跑一遍测试用例。这个习惯能救你很多次。

6.5 模型精度掉线，Az***下线时才发现

模型上线一段时间后效果逐渐下降，这是必然而不是偶然——因为数据分布一定会漂移。关键是你能不能及时发现、能不能定位原因、能不能快速恢复。

我的建议是：从一开始就要建立定期评估机制。哪怕是一个最简单的每日任务，把线上采样的数据打上标签，计算指标，画趋势图。数据的漂移越早发现，代价越小。

如果发现指标下降了，先核对这些：数据源变了吗？上游特征逻辑改了吗？模型版本有没有被误替换？如果这些都没变，那就基本确定是环境数据漂移了，触发重训练流程。

这一套流程的完善程度，才是AI工程能力真正高低的体现。

7. 工具选型心得与学习资源配置

7.1 框架怎么挑：从PyTorch出发

现在这个阶段，如果你不是有特殊的历史包袱，我建议直接从PyTorch入手。原因不是PyTorch比TensorFlow更厉害，而是它的社区生态、学习资料、模型库都更加匹配当前的实际需求。

用一句话概括：TensorFlow当年是"为了工业部署而设计"，PyTorch是"为了研究而设计"。但风水轮流转，现在PyTorch的部署生态也赶上来了，ONNX、Triton这些工具的成熟让PyTorch模型的落地变得很轻松。

在你把PyTorch用得比较顺手之后，至少要了解一次ONNX或者TensorRT。不用很深入，但要理解"模型导出为通用中间表示再优化"这件事的存在——它是模型高性能部署的重要一环。

7.2 MLOps工具别贪多，一个做精就够了

现在的MLOps工具琳琅满目，MLflow、Weights & Biases、Neptune、Kubeflow，每个都能说一堆优势。但我的建议很直接：前期别贪多，选一个能解决核心问题的做精。

如果你是一个人在做项目，MLflow是个不错的起点。它同时覆盖了实验记录、模型打包、注册管理这几个环节。你在本地先用它跑起来，理解"实验记录 + 模型仓库"这个概念，后面换任何企业级工具，底层逻辑都是相通的。

关键是自己要会思考：这个工具解决了什么问题，它留下什么没解决，你的流程里还缺什么。工具永远比流程迭代得快，但流程能力是你自己的，工具不是。

7.3 学习资源怎么选：官方文档优先于速成课

关于学习资源，我只有一个核心建议：优先看官方文档，不要沉浸在短视频和速成课程里。这不是说那些内容没用，而是它们有自己的局限——为了让人"快速上手"，它们会省略大量关键细节，而这些细节恰恰是工程上区分好坏的要点。

我自己的习惯分三步走：先快速看看官方Tutorial了解基本概念；然后带着自己的问题去读官方API文档，不要求全读，但相关的页面要精读；最后是读一到两个高质量开源项目的源码，重点关注数据管道和训练脚本的组织方式，这比读一千篇"经验帖"都管用。

当然，理论也得补一点基座。如果你有一定的精力，最简单的入门书建议一本李航的《统计学习方法》，一本书够了。不用题海战术，重要的是建立"机器学习方法在解决什么问题"的框架感。之后你再去看任何新模型新框架，都能快速归位到它属于"特征提取"还是"模型优化"还是"评估策略"的哪个环节里。

8. 写在最后：做AI工程，保持"从零开始"的心态

说到这儿，我想起来最初这个项目标题"ai-engineering-from-scratch"其实还有另一层意思。即便你已经做了很多年AI工程，每一个新项目依然值得你"从零开始"审视一遍：你的数据从哪来、经过了怎样的变换、模型帮你做了什么决策、这个决策出了错会有什么后果。

我自己的体会是，AI工程这个领域，每一个具体技术都会过时，但"搭链路、做评估、控风险"的底层能力永远不会过时。今天你花时间搭的数据管道、写的可视化脚本、建的监控告警，可能在下一个项目里全都重构重写，但你在搭建这些过程中建立起的工程直觉和经验判断，才是你真正的积累。

最后分享一个小技巧：无论你正在做什么AI项目，都养成写"项目日志"的习惯。每天在项目日志里记三件事——今天准备解决什么问题、用什么方法、遇到了什么障碍、最终结论如何。坚持下来你会发现，三个月后回看这些日志，它们比任何代码注释都更能帮助你快速进入状态，也更容易找出问题出现的根源。

AI工程这条路很长，从零开始并不可怕。真正需要担心的是一路走一路丢，失去了对系统的整体感知。希望这篇梳理对你有一点点帮助，能让你在这条路上走得更踏实一点。