企业官网建设流程全解析

ai-engineering-from-scratch 这个标题，最近在开发者圈子里撞见频率不低。先泼一盆冷水：如果你是被热搜里的 scratch 编程小游戏、scratch 植物大战僵尸、scratch 中秋节作品吸引进来的，那你多半走错门了——这里的 from scratch 不是那个积木式少儿编程工具，而是英文里“从零开始”的意思。我要聊的，是把一条完整的 AI 工程链路从零搭起来：数据怎么来、模型怎么选、训练怎么调、评估怎么定、上线之后怎么维护。这门手艺适合两类人：一是已经会写 Python、想系统建立 AI 工程能力的开发者；二是刚入行、被各种“三天学会大模型”洗脑、需要有人拉一把别走偏的新手。如果你只是好奇 AI 和搭乐高似的拖拽编程有啥关系，可以关掉了；如果你真想从零到一做出一个能用的 AI 应用，这篇可以当作你的第一份路线图。

1. 重新理解“from scratch”：AI工程与零基础入门的真相

1.1 一个热词背后的双重世界：此 scratch 非彼 Scratch

先说个挺有意思的观察。搜索引擎里搜“scratch”这个单词，前排结果几乎被少儿编程生态承包了：scratch desktop for windows、scratch jr desktop、scratch编程枪战小游戏、scratch植物大战僵尸代码、scratch中秋节画月饼……这些都是图形化编程社区里的东西。而在技术圈，“build a large language model from scratch”“build a reasoning model from scratch”是另一条完全不同的检索路径，有人甚至到处找《Build a Large Language Model from Scratch》这本书的资源。两拨人搜同一个词，需求天差地别。

造成这种混乱的原因很简单：scratch 既是麻省理工那个积木式编程工具的名字，也是一个英文短语，意思是“从零开始、白手起家”。AI 工程里说的 from scratch，指的是后者。所以当你看到 ai-engineering-from-scratch 这个标题时，正确的读法是“从零开始做 AI 工程”，而不是“用 Scratch 做 AI 工程”。这不是抠字眼，因为这两条路的学习路径、工具链、思维模型完全不同：少儿编程那边重点是逻辑启蒙和项目创意，AI 工程这边重点是数据、模型、训练、部署的工程闭环。如果你带着“AI 工程”的预期误入了少儿编程的内容，你会觉得太简单；反过来也一样。

1.2 “从零开始”的真实含义：工程不是学术复现

再拆一层：很多人一听到 from scratch，第一反应是“那我得自己实现反向传播、自己写 Transformer、自己从空白文档开始构建一切”。这种理解其实是把“从零开始”和“从零发明”搞混了。AI 工程里的从零开始，意思是：从只有一个业务问题、一块数据、一个空项目目录开始，通过你的设计和组合，最终交付一个能实际运行的系统。至于底层那些梯度下降、注意力机制，它们是工具，不是你必须徒手重造的零件。

打个比方：你要从零开始做一张桌子。一个方法是先去森林里砍树、晒木头、自己刨板子；另一个方法是买来现成的板材和五金件，自己设计尺寸、切割、组装。前一种当然能让你更懂木头，但你大概率一年都做不出一张能坐的桌子。工程实践里，多数人应该走第二条路：用现成的框架和预训练模型当“板材”，把精力花在理解业务、处理数据、设计评估、调试系统上。等你真的吃透了工程流程，再回头去啃“自己实现一个 Transformer”这类东西，效率会高得多。这就是为什么我一直跟新入行的朋友说：别一上来就钻进源码深水区，先把手上的项目跑起来。

1.3 把 AI 工程拆成一条可执行的路线图

真正高效的 from scratch，是心里先有一张全局地图，再按顺序推进。我做了这些年 AI 项目，总结下来一条稳妥的六阶段路线：

1. 业务问题定义：先把“想解决什么问题”翻译成“可以量化的指标”。比如用户差评预警，指标就是“识别出所有差评的准确率和召回率”。
2. 数据工程：采集、清洗、标注、划分。这一步通常占整个项目 60% 以上的时间。
3. 基线建模：先用最简单的模型跑通全流程，拿到一个不算太差的下限。
4. 调优与评估：在基线基础上逐步加入更复杂的模型和特征，用统一指标衡量每一步的收益。
5. 部署上线：把模型封装成接口，嵌入真实业务流。
6. 监控迭代：跟踪线上表现，收集新数据，定期重训。

为什么是这个顺序？因为它把所有决策建立在“可度量的信号”上。很多人一上来就选模型、调参，结果数据质量一塌糊涂，模型再先进也是垃圾进垃圾出。先定义指标、先做好数据、先跑通基线，看起来慢，实际上是最快能拿到可靠结果的路径。下面我就按这条路线，挑几个最关键的环节展开讲。

2. 从第一个能跑的项目起步：最小可行AI工程基座

2.1 为什么强烈建议从文本分类而不是大模型开始

现在所有人的注意力都被大模型吸走了，一开口就是“我要微调一个 LLaMA”、“我要用大模型做 Agent”。我理解这种冲动，但作为一个想建立 AI 工程能力的新手，我强烈建议你从文本分类这类小而明确的任务开始。原因有三条。

第一，数据可控。文本分类的数据集到处都是，你自己业务里的评论、工单、反馈都能用。数据量几百到几千条就能启动，不需要花几个月攒百万级语料。第二，评估清晰。分类任务有标准答案，预测对错一目了然，你可以用一个 F1 分数明确判断模型好不好。反观聊天机器人和 Agent，评估模糊得像玄学，你很难知道改了一版是变好了还是变差了。第三，迭代快。小模型在 CPU 上几分钟训完，预训练模型在免费 GPU 上半小时内也能看到结果。大模型的微调和推理，一次实验可能要烧掉几小时甚至几天，错一步成本极高。

打个比方：你想开餐厅，先别急着租三层楼、雇二十个厨师、设计复杂菜单。先在自家厨房把一道红烧肉做到稳定好吃，再谈扩张。文本分类就是你 AI 工程生涯里那道红烧肉——流程完整、反馈直接、进步看得见。

2.2 数据准备阶段最容易翻车的三个细节

很多新手拿到数据就急着喂给模型，结果后面连环踩雷。数据准备阶段有三个细节，几乎决定项目成败。

第一个：标注标准必须先固定。我见过不少项目，标注员对“这个评论算正面还是负面”的理解都不一致。比如“物流一般但质量很好”，有人标正面，有人标中性，有人标负面。不统一的标签会让模型无所适从。正确做法是开工前写一页标注规范，把边界情况列清楚。哪怕只有你一个人标注，也要这么做，因为你会发现自己上午和下午的判断都可能漂移。

第二个：划分数据集时一定要用分层抽样。拿 sklearn 的 train_test_split 举例，一定要传 stratify 参数，让训练集、验证集、测试集的类别比例保持一致。否则划分出来的测试集可能全是一个类别，你的模型得分会虚高或虚低，根本没法作为决策依据。

第三个：防止数据泄漏。这是最隐蔽的坑。比如你做电商评论情感分类，原始数据里带“评分”字段，模型只要学会“评分是5星就预测正面”，就能拿到满分——但这属于作弊，因为你在实际预测场景里可能拿不到评分，或者评分本身才是你真正想预测的目标。同理，文本里混入日期、订单号、价格等字段，都可能成为模型的“小抄”。记得在清洗时把这些信息剥离干净。

2.3 baseline 思维：先跑通笨办法，再谈聪明模型

数据准备好之后，第一件事不是上深度学习，而是跑一个“笨办法”当基线。我常用的组合是 TF-IDF 特征加上逻辑回归。TF-IDF 把文本变成词频向量，逻辑回归在此基础上做线性分类。它模型简单、训练飞快、可解释性强。

import pandas as pd from sklearn.model_selection import train_test_split from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.linear_model import LogisticRegression from sklearn.metrics import classification_report # 假设 df 已加载，包含 text 和 label 两列 df = pd.read_csv("reviews.csv") # 划分训练/验证/测试集，注意 stratify 保证类别比例一致 train_text, temp_text, train_label, temp_label = train_test_split( df["text"], df["label"], test_size=0.3, stratify=df["label"], random_state=42 ) val_text, test_text, val_label, test_label = train_test_split( temp_text, temp_label, test_size=0.5, stratify=temp_label, random_state=42 ) # TF-IDF 特征 vectorizer = TfidfVectorizer( max_features=20000, ngram_range=(1, 2), stop_words="english" ) X_train = vectorizer.fit_transform(train_text) X_val = vectorizer.transform(val_text) X_test = vectorizer.transform(test_text) # 逻辑回归基线 model = LogisticRegression(max_iter=1000, C=1.0) model.fit(X_train, train_label) # 评估 pred_val = model.predict(X_val) print(classification_report(val_label, pred_val, target_names=["负面", "正面"]))

跑这个基线有几个目的：一是验证你的数据管道没问题，从加载到评估整个链路通顺；二是拿到一个“下限”分数，后续任何模型的改进都必须超过它，否则就是在浪费时间；三是给你一个对照物，让你看清复杂模型到底带来了多少真实提升。我第一次带项目的时候，团队里有人主张直接上 BERT，我先用逻辑回归跑了个 0.87 的 F1，后来 BERT 微调完是 0.92——虽然涨了，但你也得知道这 0.05 是用多少训练时间换来的，值不值，由业务场景说了算。

3. 核心细节拆解：训练、评估与迭代的工程闭环

3.1 训练环节最容易踩的三个坑

训练环节看似人人都会，但工程经验往往体现在细节上。有三次踩坑经历，每次都是血泪教训。

第一次踩坑是不划分验证集就反复调参。早期我做项目图省事，直接在测试集上调参数，调一版测一版，很快测试集上的分数“涨”上去了，心里还挺美。后来才发现，这等于考试前先看了答案，测试集的评估价值被彻底污染了。正确的做法是：留出训练集、验证集、测试集三份数据，用验证集做模型选择和调参，全部确定之后，才允许碰一次测试集。测试集是期末考试卷，只能考一次。

第二次踩坑是类别不平衡直接训。有次做工单分类，90% 的工单是“咨询”，剩下 10% 是“故障报修”。模型学了个偷懒策略：把什么都预测成“咨询”，准确率直接 90%。你说它错了吗？从准确率看没错，但业务上一张故障单被误判成咨询，用户要被多晾好几天。解决思路有两个：一是用 class_weight 参数给少数类加权，二是在评估指标上换成 F1 而不是准确率，让模型没有偷懒的余地。

第三次踩坑是随机种子不固定。同样的代码，跑两次结果不一样。一开始我还以为环境坏了，后来才意识到是没设随机种子。AI 里面到处是随机初始化、随机抽样、随机 dropout，不固定住，你根本无法定位“这次效果变好到底是因为改动，还是因为运气”。所以我在所有项目的开头都会加这一行：

import random import numpy as np import torch def set_seed(seed: int = 42): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed)

别嫌这一步麻烦，等你要写实验报告、要复现之前的结果时，你会感谢当初固定了种子。

3.2 评估指标别只看“正确率”

“准确率”是新手最爱挂在嘴边的指标，但在 AI 工程里它往往是最容易骗人的一个。原因在于类别不平衡：当 95% 的样本都是负类时，模型什么都不学，把全部预测成负类，准确率就有 95%。所以评估指标的选择，必须跟业务目标和数据分布对齐。

我个人的习惯是：每版模型都输出 classification_report，把精确率、召回率、F1 按类别列出来，而不是只盯一个总分。这样你能快速定位“模型到底哪一类不行”。比如做差评识别时，F1 总体 0.93 很好看，但点开细看，负类召回率只有 0.61——也就是说近四成的差评漏掉了，业务上这就是事故。指标只有拆到类别粒度，才有指导意义。

3.3 实验追踪：用一张表管住你的所有尝试

做 AI 项目，最大的隐形浪费是记不住自己试过什么。大部分人的真实状态是：上周跑了个实验，效果不错，但这周想回去复现，发现代码里的参数已经被改成别的了。为了避免这种“失忆”，我从第二个项目开始强制自己做实验记录。早期没上什么高大上的工具，就是一张 Markdown 表格：