这两年“AI工程”这个词越来越热，但很多人其实是被吓住的——总觉得要懂分布式系统、要会写CUDA、要能调千亿参数大模型，门槛高得离谱。我自己当初也是从“只会调库”的状态一步步走过来，踩了不少坑，才慢慢摸清楚这条路的真实面貌。所谓ai-engineering-from-scratch，说白了就是一套从零开始、不打酱油的系统性学习路径，核心不是让你背多少篇论文，而是让你动手把一个模型从训练跑到部署，真正落在地上。

这个项目适合三类人：一是刚入门的算法工程师，想补工程短板；二是后端或全栈开发，想往AI方向转；三是已经在做AI应用、但对底层原理总感觉心里发虚的人。这篇文章把我自己的完整思路、选型逻辑、实操细节和排查经验都整理出来，希望能给正在这条路上摸索的你一个清晰的地图。

1. 项目基调：为什么“从零”不等于“从理论”

很多人听到“from scratch”就以为要把神经网络从零写一遍，这其实是个误解。我的理解更务实：从零指的是不依赖那些封装过度的平台，亲手把一套AI应用的基本链路走通。

这种定位有几个现实原因。第一，现在市面上的AutoML、低代码平台很多，但越是这种工具，越容易让你变成“只会点按钮的人”。一旦遇到边界情况，比如数据分布变了、模型效果达不到业务要求，没有底层认知根本无从下手。第二，工程能力的核心是“拆解问题”，而这只有通过亲手做、亲手调、亲手debug才能练出来。第三，AI工程本身包含的环节非常多——数据准备、模型训练、性能优化、服务部署、监控迭代——每个环节都有大量细节，这些东西不亲手碰一遍，光看文档是记不住的。

所以这个项目的设计原则很简单：用最少的外部依赖，把最重要的事情亲手做一遍。模型就用开源的小模型（比如百亿参数以下），框架就用PyTorch，部署就用自己的服务器或者便宜的云主机，把环节走通比把规模做大重要得多。

整个项目我把它拆成五个阶段，对应AI工程的核心链路。

每阶段都有明确的“能做出来的东西”作为验收标准，这是项目能够持续推进的关键。

1.1 核心技能地图

既然叫AI工程，技能树就不能只盯着模型本身。我把需要的能力分成三层。

最底层是基础设施能力：Linux操作、Docker容器化、Python工程化（虚拟环境、类型注解、单元测试）、基本网络知识（HTTP协议、并发模型）。这些看起来很“不AI”，但恰恰是工程稳定性的根基。我见过很多算法出身的人，代码能跑但工程一塌糊涂——没有版本管理、没有测试、依赖冲突频发，这种代码根本走不到生产环境。

中间层是模型全链路能力：数据处理（清洗、采样、增强）、模型训练（分布式训练基础、超参数调优）、评估体系构建（离线指标与线上效果的关系）、模型部署（推理优化、服务框架选型）。这一层是AI工程的核心，也是这个项目投入时间最多的地方。

最上层是系统化思考能力：如何在资源有限的情况下做取舍、如何设计数据闭环、如何建立监控体系、如何评估一个模型真实的上线价值。说实话，这一层靠上课很难学会，必须在真实项目中反复历练。

1.2 技术选型的底层逻辑

围绕技能地图，技术选型上我有几条经过验证的原则。

第一，深度学习框架选PyTorch而不是TensorFlow。原因很实际：PyTorch的调试体验更友好，出错信息可读性强，整个生态的惯例也是“先出PyTorch版再出其他版”。对于从零开始的人来说，这种即时反馈能节省大量学习成本。

第二，部署方向上优先考虑Triton Inference Server + ONNX Runtime，而不是图省事用Flask包一层。Flask虽然写起来快，但高并发下性能瓶颈明显，且缺乏动态批处理、模型版本管理等机制。而Triton虽然是NVIDIA家的产品，但对CPU/GPU混合部署、多模型管理、动态批处理这些工程痛点的解决都很成熟，值得花时间学。

第三，数据层面直接上Polars而不是Pandas。Pandas的API虽然熟悉，但大规模数据处理的性能和内存占用都不理想。Polars借用Rust底层，性能接近Spark但使用成本低得多，对单人项目和中小团队非常友好。

核心原则：不要追新，不要追大，选那些生态成熟、文档清晰、社区活跃的“常规选项”。

2. 环境搭建与数据集准备

2.1 可复现开发环境的三件套

环境的坑我一共踩了大概三次：第一次是本机装了CUDA后系统崩了，第二次是conda环境依赖冲突导致整个项目报废，第三次是在服务器上配好了环境、结果换了一台机器又抓瞎。后来我固定下来一套“三件套”方案，基本没有再出过问题。

三件套就是：Docker + Poetry + Makefile。

Docker负责把操作系统级依赖锁死。我把CUDA、cuDNN、Python版本、系统库都写进Dockerfile，这样不管是在自己的笔记本还是租来的服务器上，跑起来的都是同一个环境。Poetry负责锁Python包版本，和requirements.txt相比，它能区分“直接依赖”和“间接依赖”，并且自动生成锁文件。Makefile则是给人类用的入口，把一长串命令压缩成make train这样简单明确的指令。

Dockerfile的关键写法我分享一个经验：基础镜像不要用带完整CUDA的（比如nvidia/cuda:12.0-devel），那个镜像体积太大，反而容易出问题。更好的是先用pytorch/pytorch:2.1.0-cuda12.0-cudnn8-devel作为基础，然后在此基础上只追加自己需要的系统库。

FROM pytorch/pytorch:2.1.0-cuda12.0-cudnn8-devel # 设置工作目录并创建非root用户 WORKDIR /workspace RUN useradd -m -u 1000 appuser && chown -R appuser:appuser /workspace # 系统依赖（保持最小化） RUN apt-get update && apt-get install -y git curl && rm -rf /var/lib/apt/lists/* # 切换用户，后续操作不再以root运行 USER appuser # 安装Python依赖管理器 RUN pip install --user poetry==1.7.1

这里有两个细节值得注意：一是创建非root用户，很多人在容器里直接以root跑，这样权限太宽，迟早出事；二是每次apt-get后要清理缓存，否则镜像体积会越积越大。

2.2 数据集构建三板斧

数据是AI工程里最容易被低估的环节。很多新手拿到个数据集就急着开训，恨不得立刻看到loss下降，但这样往往会掉进“模型很准、一上线就废”的大坑。我在项目里固定下来一套流程：先探查、再清洗、后增强。

探查阶段，用Polars做快速统计：字段缺失率、分类字段分布、数值字段的min/max/分位数。这个步骤的意义在于，如果你连数据长什么样都不知道，后面所有决策都可能是空中楼阁。我见过一个真实案例，有人在训练集上效果很好，结果上线就拉胯，最后定位到的问题是训练集和线上数据的字段分布严重不一致——训练集里用户年龄集中在20-30岁，线上真实人群却是全年龄段的。

import polars as pl df = pl.read_csv("data/raw/train.csv") # 快速概览：缺失率、唯一值、样本量 total_rows = df.height null_stats = df.null_count().transpose(include_header=True).rename({"column": "字段", "null_count": "缺失数"}) null_stats = null_stats.with_columns( ((pl.col("缺失数") / total_rows * 100).round(2)).alias("缺失率(%)") ) print(null_stats)

清洗阶段要处理的就是脏数据：去重、修正格式、处理缺失值。处理缺失值不要一上来就填均值或众数，先搞清楚缺失机制。如果某个字段缺失率超过60%，这个字段大概率属于信息泄露很少或者系统采集本身有问题，填了反而引入噪声。

增强阶段则要根据任务性质来定，图像任务做旋转/裁剪/颜色扰动，文本任务做同义词替换/回译，表格数据则主要做特征工程、构造组合特征。但增强不是越多越好，过度增强会把模型训练时间拖长，还可能让模型学到不真实的模式。我的习惯是：先不加增强训练一个baseline，再加增强训练一个对比版本，用数据说话，看增强是否真的有效。

2.3 建议从这里开始：一个最小数据集实验

第一次尝试时，建议你别直接碰那些几十GB的大数据集，先用一个小数据集把闭环跑通。我用的例子是Kaggle的IMDb影评情感分类，大概几万条文本，大小刚好能在普通笔记本上训练。这样环境配置、数据处理、模型训练的整个链路能在半天内完全跑通，给你建立信心。

先从一个很小的模型跑通流程，再逐步放大数据和模型规模，是经验最少的试错路径。

3. 模型训练的工程化实践

3.1 从baseline到训练脚本的演进

所有训练都要从baseline开始，这个原则我一直坚持，它是判断后续所有改进是否有价值的基准线。对分类任务，baseline可以是“sentence-transformers embedding + 逻辑回归”；对序列任务，baseline可以是一个只有一两层的LSTM。这些baseline模型的参数量很小，跑一个epoch只需要几分钟，但足以让你验证数据处理流程、评估代码、保存恢复流程是否都正确。

拿情感分类任务举例，我用一个预训练的BERT-base模型做baseline。

import torch from transformers import AutoTokenizer, AutoModelForSequenceClassification from torch.utils.data import DataLoader, Dataset class TextDataset(Dataset): def __init__(self, texts, labels, tokenizer, max_len=256): self.texts = texts self.labels = labels self.tokenizer = tokenizer self.max_len = max_len def __len__(self): return len(self.texts) def __getitem__(self, idx): encoded = self.tokenizer( self.texts[idx], truncation=True, max_length=self.max_len, padding="max_length", return_tensors="pt", ) return { "input_ids": encoded["input_ids"].squeeze(0), "attention_mask": encoded["attention_mask"].squeeze(0), "labels": torch.tensor(self.labels[idx], dtype=torch.long), } model_name = "bert-base-uncased" tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForSequenceClassification.from_pretrained(model_name, num_labels=2) train_ds = TextDataset(train_texts, train_labels, tokenizer) train_loader = DataLoader(train_ds, batch_size=32, shuffle=True) optimizer = torch.optim.AdamW(model.parameters(), lr=2e-5)

这里的几个参数值得解释一下：max_len我选了256，是因为大多数IMDb影评的有效信息都在前100-150个token内，更大只会白白增加计算量；batch_size取32是我在验证集上比较过16/32/64之后的结果，32在这个任务上稳定性和显存占用最平衡；学习率2e-5是fine-tuning场景的标准值，这个初始值是基于预训练模型的参数空间已经比较平滑，太大的学习率容易把参数一下子带偏。

3.2 训练流程中的关键机制：Logger / Checkpoint / Early Stopping

训练脚本不能是“跑完就完”，必须有日志记录、断点保存和早停机制。

日志记录我用Weights & Biases，不只是因为它能画曲线，关键是它能把每次实验的超参数、代码版本、环境信息、模型结构全都固化下来。这比本地画几个matplotlib图实用得多——三个月后你再回头看，能清楚知道当时为什么这么做。如果不想用外部服务，完全可以用本地TensorBoard或MLflow，只要能解决“记录可回溯”这个核心问题就行。

Checkpoint的保存策略要谨慎，每轮都存会占太多磁盘，只存最后一轮又容易追悔莫及。我的做法是：每轮保存一次，但是只保留最近三次的权重，同时记录一个“历史最优”的权重单独保存——如果验证集指标突破了历史最高值，就把这个权重同步到best_model路径。

best_f1 = 0.0 for epoch in range(epochs): model.train() for batch in train_loader: batch = {k: v.to(device) for k, v in batch.items()} outputs = model(**batch) loss = outputs.loss loss.backward() optimizer.step() scheduler.step() optimizer.zero_grad()

这里要特别注意optimizer.zero_grad() 的调用位置，很多人习惯放在backward之后，这没问题，但必须保证每个batch都执行。如果忘了清零，梯度会在多个batch之间累积，导致训练崩坏。早期踩过这个坑，现象是loss不稳定、大幅震荡，排查了很久才发现是梯度累积的问题。Early stopping也是必要手段：设定一个耐心值（比如3轮），连续3轮验证指标没提升就停止训练，防止过拟合且节省时间。

3.3 超参数调优的“人力替代方案”

超参数调优是AI工程里极容易陷入“手动瞎试”的部分。虽然贝叶斯优化、网格搜索这类方法会让调参更科学高效，但很多人还是不自觉地开始手动调——改个学习率，跑一轮，看一下，再改回来。

我的建议是：除非有充分的先验信息，否则别用纯手动调参。至少用Optuna做一次中等规模的搜索。它对算力的消耗可控，大约几十次试验就能把主要超参数的合理范围找出来。定义搜索空间的好处是，你反而会去思考“哪个超参数对这个任务影响最大”这样的问题，这比盲目试更有价值。

import optuna def objective(trial): lr = trial.suggest_loguniform("lr", 1e-5, 1e-4) batch_size = trial.suggest_categorical("batch_size", [16, 32, 64]) warmup_ratio = trial.suggest_uniform("warmup_ratio", 0.05, 0.2) # 用这些超参数训练，并返回验证集F1 model = create_model() trainer = Trainer(model, lr=lr, batch_size=batch_size, warmup_ratio=warmup_ratio) val_f1 = trainer.train_and_evaluate() return val_f1 study = optuna.create_study(direction="maximize") study.optimize(objective, n_trials=30)

调参过程中有一条经验值得分享：很多情况下学习率warmup比例和batch size的关联性比想象中大，batch size翻倍的时候，学习率一般也应该跟着翻倍或做平方根缩放。这不是绝对真理，但确实比“调完batch size、其他一律不动”要有效得多。

4. 把模型变成真正的服务

4.1 选择推理框架：Triton的完整落地方案

训练完的模型是“死”的，服务的价值在于把它变成“活”的API。这部分的工程深度，直接决定项目的完成度。

我最终选择的是NVIDIA Triton Inference Server，原因很简单：它同时解决了并发性能、动态批处理和版本管理三个核心问题。Flask/FastAPI方案我并不是说不行，适合原型验证，但一旦流量上来，Python GIL会卡死并发量。Triton用C++实现的核心调度，底层性能优势明显，而且能直接加载ONNX Protocol Buffers格式的模型，不需要改写推理代码。

完整的部署分三步。第一步：把PyTorch模型导出为ONNX格式。

import torch from transformers import AutoModelForSequenceClassification model = AutoModelForSequenceClassification.from_pretrained("best_model") model.eval() dummy_input = { "input_ids": torch.randint(0, 30000, (1, 256)), "attention_mask": torch.ones(1, 256, dtype=torch.long), } torch.onnx.export( model, tuple(dummy_input.values()), "model.onnx", input_names=["input_ids", "attention_mask"], output_names=["logits"], dynamic_axes={ "input_ids": {0: "batch_size"}, "attention_mask": {0: "batch_size"}, }, opset_version=14, )

这里的dynamic_axes配置是重点。我刚开始导出模型时忽略了它，导致出来的ONNX模型batch size被固定为1，Triton的动态批处理完全派不上用场。指定dynamic_axes之后，推理服务才能在不同batch size间自由组批。

第二步：写Triton的模型配置文件。每个模型在模型仓库下都有一个目录，里面是model.onnx和config.pbtxt。

model_repository/ └── bert_sentiment/ ├── 1/ │ └── model.onnx └── config.pbtxt

name: "bert_sentiment" platform: "onnxruntime_onnx" max_batch_size: 64 input [ { name: "input_ids" data_type: TYPE_INT64 dims: [256] }, { name: "attention_mask" data_type: TYPE_INT64 dims: [256] } ] output [ { name: "logits" data_type: TYPE_FP32 dims: [2] } ] dynamic_batching { max_queue_delay_microseconds: 100 }

动态批处理的核心参数是max_queue_delay_microseconds，意思是当请求到达后，最多等100微秒，让更多请求凑成一批再一起推理。这个参数既可以把微小的请求碎片合并成较大的batch，又不会让用户等待太久。具体值需要根据你的流量特征来测——流量大时这个值可以设大一些，流量小时设太大会增加延迟。

第三步：启动服务，客户端调用。

docker run --gpus 1 -p 8000:8000 --rm \ -v $(pwd)/model_repository:/models \ nvcr.io/nvidia/tritonserver:23.10-py3 \ tritonserver --model-repository=/models

客户端用tritonclient发请求：

import tritonclient.http as httpclient client = httpclient.InferenceServerClient(url="localhost:8000") inputs = [ httpclient.InferInput("input_ids", [1, 256], "INT64"), httpclient.InferInput("attention_mask", [1, 256], "INT64"), ] inputs[0].set_data_from_numpy(input_ids_np) inputs[1].set_data_from_numpy(attention_mask_np) outputs = [httpclient.InferRequestedOutput("logits")] result = client.infer("bert_sentiment", inputs, outputs=outputs) logits = result.as_numpy("logits")

4.2 自建服务架构的流量控制

当你的API要把吞吐量做上去，光有Triton还不够，前面通常还需要一个接入层做鉴权、负载均衡和流量控制。如果不想引入Kubernetes这么重的方案，也可以保持在“一台服务器上通过docker-compose编排多个容器”的规模。

我常用的方案是三容器架构：Nginx处理TLS和限流，Python服务层（FastAPI）做鉴权和预处理，Triton负责模型推理。三者通过docker-compose链接，单机部署，结构简单可靠。

version: "3.8" services: gateway: image: nginx:1.24 ports: - "8080:80" volumes: - ./nginx.conf:/etc/nginx/nginx.conf:ro depends_on: - api api: build: ./api environment: - TRITON_URL=triton:8001 depends_on: - triton triton: image: nvcr.io/nvidia/tritonserver:23.10-py3 command: ["tritonserver", "--model-repository=/models"] volumes: - ./model_repository:/models deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu]

Nginx层做限流的配置方法比较简单：

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=20r/s; server { location /v1/ { limit_req zone=api_limit burst=40 nodelay; proxy_pass http://api:8000; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

rate=20r/s表示平均每秒最多20个请求，burst=40表示允许短时突发。我自己测试下来，如果业务方并不需要超低延迟，这个参数就能很好地保护后端，防止恶意刷量或异常流量把服务打挂。

4.3 延迟与吞吐量的真实平衡

很多人在做服务优化时只盯着一个指标，要么无脑追求低延迟，要么只关心高吞吐，这其实是误解了系统优化。正确思路是：在满足延迟约束的前提下最大化吞吐量。

我把自己的实践跑了一遍，列出延迟和吞吐量的关系表。

从表格可以看出，纯粹关闭动态批处理虽然延迟最低，但吞吐能力只能用惨烈来形容。把等待时间从100us提高到500us，延迟只增加了约20ms，但吞吐提升了50%。实际生产环境可以根据对延迟的容忍度调整这个值。

我在调优时发现，Triton模型配置里还有一个可以开启的引擎优化项：ONNX Runtime的graph optimization level，切到ORT_ENABLE_EXTENDED之后，模型推理速度大约能快10%-15%，这个白嫖的优化千万别漏了。

5. 效果评估、性能诊断与迭代闭环

5.1 离线评估和线上反馈的两条线

模型上线之后，很多人就以为任务结束了，其实真正的工程挑战才刚刚开始。要建立一套可信任的反馈机制，必须同时跑两条评估线：离线评估和线上监控。

离线评估的意义在于快速迭代，但不能只看准确率/精确率/召回率这几个热闹指标。我至少会追加看分位误差、错误分布象限、混淆矩阵。比如在情感分类里，模型在“较长文本+带有讽刺意味”的样本上错误率更高，这个信息不通过错误结构化分析是看不出来的。

线上监控则是确认“离线好的模型上线也好的”唯一证据链。我在架设推理服务时，必然会在API侧记录三项指标：平均响应延迟、P95延迟、错误率。但更关键的是输出置信度分布的变化——正常业务的置信度分布应该是相对稳定的，如果发生肉眼可见的偏移，那就要警惕数据分布发生了变化。

上面的监控方案不需要特别复杂的平台，用Prometheus + Grafana搭一套最基础的就可以覆盖这些需求。

5.2 性能诊断的经典案例

说一个真实遇到过的案例：模型用Triton部署后，压测发现吞吐量上不去，GPU利用率只有30%左右。我当时排查步骤是这样的。

第一反应是看模型是否发生了CPU-GPU数据传输瓶颈。如果输入文本的长度很长且模型本身很小，推理时间可能还没传输时间多，导致整条链路的瓶颈在I/O而非计算。

第二步，我用nvprof或NVIDIA Nsight Systems跑了一次profiling分析。发现模型在GPU上推理阶段仅占总时长的20%，而数据预处理占据了50%，其中80%的时间花在了tokenizer的Python循环上。

问题定位后，我用两种方法解决。一是用了tokenizers库的batch_encode_plus，而不是单条encode循环；二是把tokenizer的预处理从前端API层挪到客户端执行，服务端只接收编码后的input_ids。这样服务端只做张量分发和推理，压力立刻小了很多。

经过优化，吞吐提升了约3倍，GPU利用率从30%提到了70%以上。这个案例想说明的是：很多AI系统的瓶颈，压根不在模型计算，而是在数据处理和传输链路。

5.3 数据漂移检测与模型再训练机制

业务跑起来之后，最隐蔽的问题就是数据漂移——线上的数据分布和训练时不一样了。检测方法有很多种，从简单的“字段均值突变检测”到“KS检验、PSI稳定性指标”都有。

我建议先用量化方法代替肉眼：比如对每个特征字段记录其训练集的统计分布（均值、分位数、缺失率），在线上实时计算当前窗口的统计量，与训练集分布做比对，超出阈值就告警。

from scipy import stats def detect_drift(reference, current, threshold_pvalue=0.05): # 用KS检验检测两个样本是否来自同一分布 ks_stat, p_value = stats.ks_2samp(reference, current) drifted = p_value < threshold_pvalue return { "ks_stat": ks_stat, "p_value": p_value, "drifted": drifted, "magnitude": ks_stat * (1 + threshold_pvalue - p_value) }

检测到漂移后，传统做法是“重新收集数据、标注、训练、上线”，整个周期动不动要好几周。更轻量一些的处理是：如果漂移只是局部特征，可以先做特征适配或样本加权，优先把服务救回来。如果是全局分布变了，那就只能走重训练流程了。

我自己的经验是：永远不要等漂移严重了才做模型更新，设置一个定期（比如每两周）用增量数据做一次微调的计划，是成本最低的维护方式。

6. 常见问题速查与项目复盘

6.1 从零开始的避坑清单

有一些问题几乎每个从零到一的项目都会遇到，整理成速查表：

说几个我亲身踩过、尤其痛的坑。PyTorch的DataLoader多进程在Windows上会反复启动，卡死训练流程；Linux上要用ifname== "main"保护代码，但很多人只写脚本不注意到这点。另一坑是中文字符编码：在读取CSV或JSON时，如果忘记指定编码，数据直接变成乱码，而模型居然还会“学到”乱码的模式——也就是说，你甚至可能不会发现数据是错的，直到某个指标诡异到不得不查数据。

还有浮点精度的坑：模型保存和加载时，如果用fp32训练但部署时压缩到fp16，算子整体会有毫秒级的计算差异，个别情况下精度会掉很多。所以启用fp16推理前，最好先在离线验证集上跑一遍对比结果。

6.2 项目整体复盘：这套路径给我带来了什么

把这个项目完整做完一遍后，我对“AI工程师”这份工作的理解完全变了。以前我的认知是“把模型训出来就是成功”，做完整条链路之后才发现那真的只是冰山一角。真正决定系统价值的，是数据质量、工程稳定性和迭代机制。

学到的最重要的东西，是五个字：用数据说话。每个改进都依赖实验对比——加不加这个特征、换不换这个优化器、用不用动态批处理——这些都通过对照组数据来决定，不靠感觉。AI工程如果有什么“银弹”，那就是“可衡量的实验”。

另一点体会是：工程效率的根在环境隔离和自动化。在这个项目之前，我的时间大概有三分之一花在“想不起当时怎么装的包”和“为什么别人的机器上跑不通”上。把Docker和统一命令入口搭好之后，这部分浪费时间几乎归零。

6.3 内容还能怎么扩展

这个框架本身是高度可复用的。面向不同的业务场景，只要替换数据和模型，整个链路不需要大改。我目前正在做的一个方向是把这套流程迁移到业务数据上，针对内部场景做垂直化微调。

后续扩展可以考虑的方向有三个：第一，把单机训练换成多机多卡分布式训练，配合DeepSpeed或PyTorch FSDP；第二，加入自动化的CI/CD流水线，每次代码提交后自动跑训练和评估，把质量和效率卡在源头；第三，加上完整的监控告警体系接入已有运维平台，让模型服务真正成为基础设施的一部分。

对我个人而言，这个项目更像是一张地图：起点是“只会训练模型”，终点是“能独立支撑一个AI系统的完整生命周期”。你现在看到的每一个小节，背后都是当时某次手忙脚乱的排错经历。最后送给大家一条我自己的实践原则：不要怕慢，不要怕错，每一步都把它背后的为什么弄明白，你的成长速度会远超那些只跑通流程就觉得自己会了的人。

这套东西做完，你再去看现在的各种“AI应用”，就不会只看到热闹，而是能看到每一层背后到底在做什么。那感觉挺上头的。