企业官网建设流程全解析

收到一个很有意思的项目命名：ai-engineering-from-scratch。直译过来是"从零开始做AI工程"。这个名字不花哨，但分量很重——它不是让你去调别人的现成接口，而是要求你把AI落地的完整链路亲手走一遍：数据怎么处理、模型怎么训、怎么评估、怎么上线、线上出了问题怎么排查。

这两年想进AI领域的人太多了。我身边有刚毕业的校招生，有写了好几年后端准备转方向的老同事，也有做数据分析想更进一步的同行。大家普遍卡在同一个点上：资料囤了一大堆，道理都"懂了"，可真拿到一个需求时，不知道第一步该干什么。这篇文章把我自己趟出来的路径完整讲一遍，适合打算系统性入行AI工程的人，也适合已经在做但想回头补短板的人。

说明一下，我默认你有基础编码能力，但不需要机器学习和深度学习背景。文中涉及的数学概念，我会尽量用大白话解释，你暂时不求甚解也能跟着做一遍；但长期来看，前面的基础课还是得自己补上，后面我会讲到补到什么时候算够。

1. AI工程的核心范围：六个环节一次拆透

1.1 会调接口和会做工程，差的不只是一个API

很多人把AI工程理解成"会调大模型接口"。拿个API key，拼一段prompt，把返回结果贴给用户就完事了。这种体验离真实工程差着十万八千里——调API是消费一个成熟产品，做工程是生产一个产品。

我习惯用一个类比：调API像点外卖，AI工程像开餐厅。点外卖你只关心好不好吃、送得快不快；开餐厅你得处理供应链、后厨排班、口味标准化、食客差评怎么复盘，出餐高峰期怎么保证不崩。数据的上下游、模型服务、评估反馈、运维监控，这些全部要管。

真实项目里，模型的训练或者调用往往是整个链条里最"轻松"的一环。真正吞噬时间的是：业务需求说不清楚，数据又脏又乱，效果没法定量评估，上线之后bad case源源不断冒出来。这些都是工程问题，不是算法问题。换句话说，AI工程的核心是一种把不确定性慢慢磨成确定性的能力。

1.2 AI工程链路六段：每一段都不能跳过

我把自己做过的项目抽象成一条六段链路，也正好构成了ai-engineering-from-scratch的主线：

1. 需求定义：把业务问题翻译成技术问题。老板说"提高客服效率"，你要翻译成"工单自动分类准确率达到多少、人工复核率降到多少"。
2. 数据工程：采集、清洗、标注、切分。这是决定模型上限的地方，也是大多数人最忽视的地方。
3. 模型开发：选基座模型、做提示工程、微调、蒸馏，产出候选模型。
4. 评估与调优：离线指标评测、bad case分析、反复迭代，直到达标。
5. 部署上线：服务化封装、推理优化、成本控制、灰度放量。
6. 监控迭代：线上指标、数据漂移、效果衰减、按需重新训练。

这六段不是线性走完就收工，而是螺旋式循环。网上大部分教程只讲第3段，所以很多人学完才发现只看到了冰山一角。而"from scratch"的深层含义，就是让你从头到尾把六段都经历一遍。每一段都亲手做过，后面不管接手什么项目，心里都会有张完整地图，不会被某个环节的意外卡死。

1.3 为什么坚持从零开始：三点理由和一条边界

有同学问过我：现在工具那么多，跑通一个demo不就行了，何必从底层开始？我的观点是：工具能让你飞起来，也能让你摔得很惨。你完全不懂内部机制时，出了问题只能到处碰运气。

从零开始学有三个实实在在的好处。第一，不容易被某个平台锁定。今天用这家的向量库，明天换那家的模型，底层逻辑如果你清楚，迁移成本很低。第二，排查问题能一路追到底层。线上效果突然暴跌，到底是数据变了、模型被回滚了、还是推理环境的依赖出了问题，这些都得靠底层理解来定位。第三，面试和协作时能讲清楚"为什么"。只讲得出"我调了这个参数所以好了"的人，和能讲出"这个参数影响了什么机制"的人，在同一个团队里干两个月，差距会非常明显。

当然要说明一点边界：from scratch不是让你从手写反向传播开始。我的建议是学原理，但不必重复造轮子。自己动手实现过一个小规模训练循环、一条RAG流程，理解就到位了，没必要连优化器都自己重写。把精力花在真正影响项目成败的地方，才是一个工程人该有的判断。

2. 从零开始的技能地图：按工程优先级排学习顺序

2.1 数学学到什么程度：够读懂训练日志就够

一听到数学，很多人先慌了。其实AI工程需要的数学，比想象中少得多，也具体得多。

线性代数，核心是向量、矩阵、矩阵乘法。神经网络本质上就是一堆矩阵运算，理解shape怎么变换，很多报错一眼就能定位。你不需要独立推导奇异值分解，但至少得知道两个矩阵能不能相乘、乘出来是几维。概率统计，核心是条件概率、分布、期望和方差。分类任务的输出就是一个概率分布，评估指标里的精确率和召回率也是概率视角。微积分，核心是导数、链式法则、梯度。梯度下降是训练一切模型的引擎，你不需要手算复杂导数，但要知道"学习率"为什么存在、梯度到底指向哪里。

我的结论是：能达到"看懂训练日志、理解框架文档里的公式"的程度就够用了。学习顺序建议看3Blue1Brown的线性代数和微积分系列动画，配合一本入门书，每天半小时，两个月基本够用。别一上来就啃大部头，那只会把兴趣磨光。等真遇到需要更深入数学的场景，你自然会有动力回头补。

2.2 编程与工程工具：最低门槛要过这几关

AI工程首先是工程，编程能力是地基。这里说的不只是"会写脚本"，而是要有能力维护一套持续演进的代码。

Python功底要扎实到：装饰器、生成器、上下文管理器能看懂；会写类型注解；知道什么时候该拆模块。然后Git得熟练，一个人做项目也需要版本回退和分支管理。再就是Linux命令和Shell脚本，至少要能独立操作一台不带界面的服务器——AI任务通常要跑GPU机器，而GPU机器绝大多数是Linux。

Docker我建议尽早学。它解决的核心问题是环境一致性：把代码和依赖一起打包成镜像，在任何机器上跑结果都一样。本地跑得好好的，上服务器就跑不起来，大概率是环境问题，Docker基本能填平这个坑。实操上有个小技巧：建一个自己的项目模板，包含requirements.txt、Dockerfile、README和config目录，每开新项目直接抄模板改。这个习惯帮我省了大量时间。

2.3 机器学习和深度学习：动手跑通一个小模型再谈其他

在碰大模型之前，先把经典机器学习的基本盘打牢。不是让你当算法研究员，而是至少要理解这些术语背后的场景：训练集、验证集、测试集为什么必须分开；过拟合是什么现象；精确率、召回率、F1、AUC各在什么时候用；类别不均衡会对指标造成什么影响。

深度学习这块，核心概念包括：层是什么、激活函数为什么存在、损失函数在衡量什么、优化器大概在做什么、batch size和epoch对训练的影响。然后上手PyTorch训练一个最经典的模型，比如手写数字识别，把训练曲线画出来，亲眼看一次过拟合长什么样。

我实测下来，这一步的价值比读十篇文章都大。你亲自经历过loss下降又反弹、验证准确率停在某个值上不去，后面看大模型训练的各种日志才不会慌。这个阶段完成后，你就有最基本的模型判断力：效果不好时，能分辨是欠拟合还是过拟合，是学习率问题还是数据问题。这个能力在后面非常值钱。

2.4 大模型新增技能：提示、RAG、微调与评估

经典基础打完后，就是当下最热的大模型工程技能。这块变化很快，但有几条主线是稳定的。

提示工程：理解 system、few-shot、思想链这些基本手法，核心是知道怎么把任务描述清楚、怎么给示例。提示词不用玩得花里胡哨，先掌握可复用的模板化写法。检索增强生成（RAG）：要理解离线切块、embedding入库、在线检索、把检索结果和问题一起喂给模型的完整链路。关键点在于切块策略、embedding选型、检索结果怎么排序，以及怎么单独评估检索环节的质量。

微调（Fine-tuning）：至少要会用LoRA这类参数高效微调。要懂训练数据的组织格式、超参怎么设、微调后会不会破坏通用能力。我建议先在小数据集上把流程跑通，再上规模。大模型评估则是最容易被忽略的一块：怎么构建黄金测试集，怎么用规则、语义相似度或另一个模型来打分，怎么人工抽检。不做评估的AI项目都是空中楼阁，后面我会专门展开。

还有一个被低估的能力：推理成本意识。同样的效果，小模型加提示工程能解决，就不要上大模型；能批量处理，就不要在线逐条调用。这些都是落地时实打实的价值。

3. 完整实操流程：把一个AI项目从需求跑到上线

理论说再多，不如完整走一遍。我拿一个非常经典的场景——客服工单自动分类来演示。这个场景门槛低、效果可量化、业务价值明显，特别适合作为from scratch练习的载体。

3.1 先把"要什么"翻译成技术指标

拿到需求的第一件事不是选模型，而是和业务方把目标对齐。我每次都会追着问三个问题。

输入是什么：工单的标题、正文，还是附带截图？只有文本，还是有结构化字段？输出是什么：要分到预设的几十个类别，还是要抽取关键信息，还是要生成自动回复？成功标准是什么：准确率多高算达标？愿意接受多少人工复核？处理速度要求是多少？

最容易踩的坑是"什么都想要"。我见过一个项目，既要分类、又要抽取、还要生成回复，结果模型很臃肿，每项都一般。正确做法是先定一个最小可行版本：首期只做分类，把链路跑通，后面再加能力。同时，一定要把成功标准量化并写进文档。否则每次迭代，业务方都可能凭感觉说"好像好了一点"或"好像没变化"，项目就没办法推进了。

3.2 数据准备：这里吃掉60%的工期

这个环节通常要花掉我60%的时间。不是因为它难，而是因为琐碎，且每一步错误都会传导到后面。

第一步采集与探查：先写脚本做统计，看总量、类别分布、文本长度分布、空值和缺失情况。类别如果严重不均衡，比如90%都是"咨询"类，那评估指标就不能只看准确率，否则你把所有样本都判成"咨询"，准确率也有90%。第二步清洗：工单数据里常见的脏东西包括HTML标签、全角半角不统一、重复工单、隐私信息需要脱敏。清洗规则要逐条验证，并保留清洗前后的对照日志。第三步标注：如果没有现成标签，就制定标注规范。两个标注员对同一批数据的一致性很重要，一致性低说明任务定义本身不清晰。第四步划分数据集：训练、验证、测试按比例切分。

注意：数据泄漏是评估虚高最常见的原因。如果数据带有时间属性，不能随机切分，要按时间切分；重复或高度相似的样本不能同时出现在训练集和测试集里。否则离线指标会严重失实，上线立刻打回原形。

3.3 基线、选型与微调：一次讲清判断逻辑

选模型之前，先做一个最简单的基线。比如"标题里出现某关键词就归到对应类别"的手写规则，或者一个词频加逻辑回归。基线的意义是给后面所有复杂模型一个对比锚点：如果大模型只比规则高两个点，你要仔细掂量值不值得上。

基线上来之后，再决定用哪个方案。我通常对着这个判断框架选型：

没有绝对最优的方案，只有当下最合适的。如果调用大模型接口的成本可控，提示工程和RAG是冷启动最快的路径；如果要求毫秒级响应、数据要私有化，那微调一个本地小模型更合适。

实际走微调路线时，我建议先用小规模数据验证流程。以LoRA为例，常用的起始配置长这样：

# LoRA 微调起始配置，以 PEFT 库为例 peft_config = { "r": 8, # 秩，越大容量越高，过拟合风险也越高 "lora_alpha": 16, # 缩放系数，和 r 配合调节 "target_modules": ["q_proj", "v_proj"], # 只作用部分注意力层 "learning_rate": 1e-4, "batch_size": 8, "epochs": 3, "warmup_ratio": 0.1, "weight_decay": 0.01, }

训练时重点盯两条曲线：训练损失和验证指标。训练损失降得很快但验证指标不涨，是过拟合信号；两个都不动，先检查学习率和数据，再看loss有没有数值异常。这个判断套路那个阶段都一样。

3.4 评估体系：没有评分就没有迭代

评估是AI工程和AI玩具最大的分水岭。玩具只看"跑通没"，工程要看"多好多稳"。

离线评估的核心是黄金测试集：从真实数据里留出一批标注充分的样本，任何模型上线前都要在这批样本上评分。分类任务不能只看总体准确率，还要看每个类别的精确率和召回率，尤其是样本少的类别。光看总体指标，你完全发现不了某些类别一个都没分对。

比指标更重要的是bad case分析。我每轮迭代都会随机抽100个错误样本，逐个看到底错在哪：是标注错了，还是类别定义模糊，还是文本里出现了训练时没见过的写法。很多时候答案不是换模型，而是补数据或者修清洗规则。我印象最深的一次，客服数据里"退款"和"退货"两个类别定义重叠，人工标注都经常分不清。后来跟业务方重新划清定义，准确率直接涨了十几个点，跟模型一毛钱关系都没有。

大模型场景下评估更麻烦，生成结果没有标准答案。我的做法是：先定义维度，比如信息完整度、准确性、格式合规，再构建评分prompt，让一个表现稳定的模型当评委，同时定期人工抽检做对齐。要记住，机器评分和人工评分的一致性需要持续验证，否则自动评估会变成一个自欺欺人的摆设。

3.5 部署、监控与迭代：上线才是真正的开始

模型训完只是中场，部署上线后才会暴露真正的工程问题。

服务化封装，最简单是FastAPI包一个推理接口。但一个关键点是：不能每次请求都现场加载模型，要启动时预加载；大模型推理不能同步硬扛，要做排队或异步处理。上线初期建议只放内部流量，灰度再放全量。

推理优化方面，如果延迟超标，除了换小模型，还可以做量化，把模型参数从FP16压到INT8；可以做批处理，把多个请求攒一起推理；还可以加缓存，相同或相似的请求直接返回历史结果。我实测过，量化在多数任务上能提速2到4倍，效果损失往往可以接受。

监控至少要看三个层面。服务层面看响应时间、错误率、并发；数据层面看输入分布有没有变化，比如用户话术突然换了风格；效果层面做抽检或看线上指标，比如人工复核率。监控的目的不只是"有事报警"，更是让你能及时发现模型何时开始失效。迭代上，每次模型更新都要记录训练数据版本、代码版本、配置版本，这样线上出问题能快速回滚——这是工程底线，不是可选项。

4. 高频问题与排查经验：这些坑我替你踩过了

4.1 模型效果差：先查数据再查训练

效果不好是常态，真正的问题是很多人一上来就换更大的模型，完全跳过了排查。我给自己定了一条铁律：先质疑数据，再质疑模型。排查顺序固定如下：

1. 先查数据。标注对不对？类别定义清不清楚？有没有脏数据？有没有数据泄漏？数据问题通常占bad case的一半以上。
2. 再查评估方式。测试集是从真实分布抽出来的吗？指标选对了吗？是不是样本不均衡导致指标虚高？
3. 然后查训练过程。是欠拟合，训练集上也很差？还是过拟合，训练集好、测试集差？batch size和学习率有没有问题？
4. 最后才考虑换模型架构或者加数据。

这条顺序我踩过无数次。最蠢的一次，我花了一周微调一个模型，效果始终不达标，最后发现是上次清理数据时不小心把标签和文本错位了。那一周的时间完全白费。从那以后，每次训练前我都会抽20条样本人工核对一遍数据对齐情况，这个习惯帮我挡掉了大量低级事故。

4.2 训练崩溃三件套：OOM、NaN和不收敛

训练阶段最常见的三类问题，我放到一起说。

显存溢出，也就是CUDA Out of Memory。处理方法按优先级排序：调小batch size、开梯度累积、用混合精度、必要时开梯度检查点。有个容易被忽略的事实：不只模型参数占显存，中间激活值也占，所以batch size减半往往立竿见影。

loss不降或者出现NaN。先看学习率是不是过大，大模型微调的学习率一般不要超过2e-4；再看数据里有没有NaN或无穷值；再加梯度裁剪，默认设1.0能挡住大多数训练发散。

模型不收敛。先确认损失函数选对了，分类任务用交叉熵而不是MSE；再确认标签和数据是对齐的；最后把学习率拉回一个合理范围。注意，小批量下loss波动是正常的，别因为曲线跳来跳去就乱调参。我见过有人隔几分钟改一次学习率，最后整个训练完全失控。

4.3 从原型到生产：落差在哪里，怎么补

在Jupyter里跑通一个流程，和把模型丢进生产环境，中间隔了好几座山。

首先是延迟和吞吐。原型阶段没人管推理耗时，生产环境你得在几百毫秒内返回，还得扛住并发。解决办法通常是换小模型、量化、批量推理、加缓存。我处理过一个文本分类服务，在GPU上推理只要2毫秒，在CPU上大概40毫秒，按业务量完全够用，最后整个服务直接跑CPU，成本省了一大截。

其次是降级方案。任何AI服务都可能挂，要提前设计兜底：模型服务挂了就返回规则结果，规则也挂了就返回默认模板。用户拿到稍差的结果，好过服务直接报错。第三是输入输出约束。用户输入任何文本，你都要做长度截断和格式校验；模型输出要加schema约束和后处理。大模型输出尤其要小心，可能带格式、带偏见、甚至带幻觉，上线前必须设计好护栏逻辑。

4.4 工程规范：个人项目也要有纪律

一个人干活可以随意，但只要涉及长期维护，规范就是生产力。

实验追踪：每次训练都要记录数据版本、模型版本、超参、指标结果。用MLflow这类工具也好，用Excel也好，关键是可复现。两个月后有人问你"上次那个87.5%的模型是怎么训出来的"，如果翻不出记录，等于白干。代码评审：即使是小团队，也建议走review。很多坑当时发现不了，过几周回看才会暴露。模型代码的坑特别隐蔽，一个数据预处理函数在不同脚本里版本不一致，就能让你白跑两天实验。

文档方面，项目背景、成功标准、数据schema、模型卡，包括训练数据、适用场景、已知局限，都应该写。写文档不是给领导看，是给三个月后的自己看。我吃过太多"这代码当时明明能用"的亏，后来才意识到，不是我记忆差，是我根本没留记录。

5. 三条实操体会：写在项目最后

这个项目做到现在，我最想留下的不是技术清单，而是三条朴素的经验。

第一条，数据永远值得花最多时间。模型迭代快，数据迭代慢。你花一周整理出来的干净数据，会让后面每一次实验都受益；而你花一周调出来的参数，换一批数据可能就失效了。第二条，先做端到端最小闭环，再做优化。不要一开始就想着把系统做到完美，先把"一个请求进来，经过处理，返回结果"的完整链路跑通，哪怕用的是最简单的规则。闭环通了之后，再逐个环节升级。没有闭环之前，所有优化都是空中楼阁，因为你根本不知道瓶颈在哪。第三条，实验记录是你最重要的资产。凭感觉调参，调好了不知道为什么好，调坏了也不知道为什么坏，这是新手最大的浪费。养成随手记录的习惯之后，你的进步速度会明显不一样。

ai-engineering-from-scratch这个项目名字一直没改，但它承载的内容，从一开始的"我要学会AI"，慢慢变成了"我要搭建一个可靠、可迭代、可解释的AI系统"。如果这篇文章能帮你少走一小段弯路，我就觉得很值了。说到底，AI工程的核心不是追新，而是把每一件朴素的小事做到位。