企业官网建设流程全解析

1. 先把"从零"的定义搞清楚：AI工程和 AI 研究不是一回事

有朋友在评论区问我：你那个"ai-engineering-from-scratch"到底是从哪个零开始？是数学零基础，还是编程零基础，还是完全没接触过大模型？

我特别想回答这个问题，因为大多数人学 AI 半途而废，问题不在能力，而在没有定义清楚自己的起点和终点。

先亮个观点：AI Engineering 和 AI Research 是两个方向。研究岗每天在琢磨模型能力的天花板，琢磨论文里的新机制，训练更大的模型；工程岗每天在琢磨怎么把别人训练好的模型稳定地跑起来，怎么跟现有系统对接，怎么在真实的数据和真实的用户反馈里把它调得越来越好用。

从这个角度说，AI 工程的"零"不是数学的零，不是算法的零，而是**"能不能把一个能用的AI系统交付出去"这个能力上的零**。你不需要自己发明 Transformer，你不需要手写反向传播，但你需要知道模型输入输出长什么样，需要知道怎么把文档切碎灌进向量库，需要知道用户问了一个问题模型答错了要往哪个环节查。

所以这份从零开始的内容，本质上是一个能力清单和路线图，让一个有一定编程基础、想进入 AI 应用开发领域的人，用尽可能短的时间走完"会用模型"到"能交付AI功能"的这段路。

这篇内容是我把自己过去几年带人、做项目的思路整理出来的产物。适合几类人看：刚转行的前端/后端工程师，想把 LLM 接到业务里的产品技术负责人，以及在读学生想绕过论文式学习、直接上手做 AI 应用的人。看完之后你可以照着章节顺序一步步操作，也可以挑自己缺的模块跳着看，东西都是互相独立的。

2. 奠基期：编程、数据处理与数学到底要学到什么程度

AI 工程的地基不是数学公式，是你处理数据的能力。这里我按实操倒推，说说真正够用的标准。

2.1 Python 与工程习惯：不是"会写"就行

Python 语法谁都能在两周内上手，但很多人写的 Python 只能自己跑通，换个环境就崩。AI 工程是团队协作和长期演进的事情，从第一天起就要养成几个习惯：

• 用虚拟环境管依赖，而不是一股脑 pip install 到全局
• 从第一个脚本开始就用 Git 管理，每次改动附带清晰 commit 信息
• 代码优先做到模块化：数据加载、特征处理、模型调用、结果输出各自独立成函数

我自己现在统一用 uv 来管理 Python 环境和依赖，它比传统 pip + venv 的组合快得多，锁文件机制也能保证不同机器上复现出同一套环境。项目里固定放一个requirements.txt或者pyproject.toml，标注核心依赖的版本范围，这比什么都重要。

工程习惯还包括：不依赖 notebook 写业务代码。Jupyter 适合做探索性分析和可视化，但真正进入开发阶段，请把逻辑迁移到.py文件中，保留 Notebook 作为实验记录。

2.2 数据处理日常：AI 工程师的 80% 时间在这里

很多人被"AI"两个字吸引，结果真正做起来发现自己整天在洗数据。这不是异常，这是常态。

所谓工程化的数据处理，核心就四件事：获取、清洗、转换、验证。

以最常见的表格数据为例，你需要能用 pandas 做这些操作：

• 读入 CSV、Excel、JSON 等不同格式，并处理编码问题
• 识别缺失值、异常值、重复行，并决定是删除还是填充
• 做特征工程：分箱、编码、标准化、构造交叉特征
• 用assert或专门的校验函数确认数据质量（比如数量匹配、数值范围合理）

到文本和图片场景，则是解析 PDF/HTML、去除噪声（页眉页脚、广告、脚本标签）、映射到统一 schema。这些能力没法靠看书获得，只能靠大量的实际数据喂出来。

我建议新手第一个月的训练材料直接上真实场景数据，比如自己积累的日志、公开的政府数据集、Kaggle 里的经典表格赛题。不要嫌数据脏，脏数据才是真实的，过干净的数据集反而学不到该学的本事。

2.3 数学到底要不要补？补多少？

关于数学，我给的是"够用主义"标准，如果你的目标不是研究岗，以下程度就可以开始做项目了：

• 线性代数：理解矩阵乘法代表一组线性变换，理解向量的点积跟相似度的关系。这足够让你看懂嵌入模型（embedding model）的基本逻辑。
• 概率统计：理解均值、方差、概率分布的概念，知道什么是采样，能够读懂准确率、召回率、AUC 这些指标的含义。
• 微积分：不用会求复杂积分，知道梯度下降的方向来自导数/偏导，能看懂"损失函数在某个点下降"这句话就够了。

更深入的部分，比如矩阵分解的证明、随机过程的推导，等你在项目中真的碰到再回来补。太早陷入数学会彻底消磨掉动手的兴趣，这是我在无数人身上看到的真实教训。

数学知识的作用不是让你推导模型，而是让你在模型表现不佳时，有一个能判断"问题大概率出在哪个环节"的逻辑框架。

3. 模型层实践：从经典机器学习到深度学习的过渡逻辑

很多人一上来就抱着 PyTorch 啃，看完了整本《动手学深度学习》却还是不知道从哪里开始写自己的训练代码。我在整理内容时特意把经典机器学习放在前面，这不是复古，是给后续一切模型能力建立直觉。

3.1 先用经典模型建立"基线思维"

"基线"（baseline）是我认为整个 AI 工程里最重要的概念。任何项目动手之前，先做一版能跑通的最简单方案，记录它的效果，然后在它的基础上逐步改进。没有基线，你后续做的所有优化都无法回答"到底变好了没有"这个问题。

以分类任务为例，逻辑回归和随机森林就是完美的基线工具：

from sklearn.ensemble import RandomForestClassifier from sklearn.model_selection import cross_val_score model = RandomForestClassifier(n_estimators=200, random_state=42) scores = cross_val_score(model, X_train, y_train, cv=5) print(f"基线准确率: {scores.mean():.4f} (+/- {scores.std() * 2:.4f})")

这段代码五秒钟跑完，但是它会告诉你一个关键信息：**在不做任何花哨处理的情况下，一个通用模型的底线在哪里。**如果之后你上了深度网络、上了大模型，但是效果提升不超过两三个点，你就得认真考虑是不是数据或特征出了问题，而不是模型的锅。

交叉验证的使用习惯也建议从这时建立起来。它比单一 train/test split 更可靠地反映模型泛化能力，尤其是数据量不大的时候。新手最常犯的错误是反复用同一份测试集调参，最后骄傲地报出一个"完美指标"，放到真实场景却立刻崩掉，就是因为过拟合到了测试集上。

3.2 深度学习的"最小可运行闭环"

从经典 ML 跨到深度学习，核心是理解神经网络怎么对数据"自动找特征"。PyTorch 里一个训练闭环通常就五个步骤：

1. 构建 Dataset 和 DataLoader，把数据批量喂给模型
2. 定义网络结构（哪怕是最简单的多层感知机）
3. 选择损失函数和优化器
4. 前向传播算预测、算损失，反向传播算梯度
5. 按固定 epoch 数迭代，并在每次迭代后评估验证集

import torch import torch.nn as nn model = nn.Sequential( nn.Linear(20, 64), nn.ReLU(), nn.Linear(64, 1) ) loss_fn = nn.BCEWithLogitsLoss() optimizer = torch.optim.Adam(model.parameters(), lr=1e-3) for epoch in range(30): for x_batch, y_batch in train_loader: optimizer.zero_grad() pred = model(x_batch).squeeze() loss = loss_fn(pred, y_batch) loss.backward() optimizer.step()

这个闭环本身不难，难在出现问题的排查能力：loss 变成 NaN 了怎么办？收敛太慢是学习率问题还是特征缩放问题？过拟合在哪一个 epoch 开始出现？这些都需要在真实项目里磨。

我强调"最小可运行闭环"的另一个原因，是它给出了调试的边界。很多人在配置环境、装 CUDA、解决版本冲突上花的时间比写代码还多，而一旦你掌握了一套"能跑起来"的最小流程，剩下的事情都变得可以迭代。

3.3 为什么我建议用小型数据集而非"玩具项目"练手

学习深度学习时选择一个合适的数据集非常重要。MNIST 手写数字这类数据集太"干净"了，每个图都是 28x28 像素、中心对齐、背景纯净，你在这个数据集上怎么做都能得到不错的结果，根本练不出处理真实噪声的能力。

我推荐用中小型但真实的数据集，比如：

• 图像：CIFAR-10/100，图像尺寸适中且包含真实物体的形变和背景
• 文本：IMDB 影评，涉及变长序列、停用词、情感极性等真实问题
• 表格：贷款违约预测类赛题，特征间高度混杂且有缺失，需要做很多预处理

你在这些数据集上会遇到的第一个坎通常是：为什么验证集表现远低于训练集？然后你开始研究正则化、数据增强、早停、调学习率。这些恰恰是网上千篇一律的教程不会教你的、真正决定模型能否落地的部分。

注意一点：这阶段不是要你把 SOTA 刷到多高，而是要完整地走过一遍"加载数据 → 建立基线 → 尝试改进 → 记录实验 → 得出教训"的过程。一个跑完整流程、效果一般的项目，比一个直接用别人调好权重、效果华丽但不知其所以然的项目有价值得多。

4. LLM 时代，AI 工程的重心转移到了哪里

如果说经典 ML 和深度学习解决的是"从数据中学会规律"的问题，那么 LLM 时代 AI 工程的核心，则是"如何优雅地把一个预训练好的强大模型嵌入到业务流程中"。你不需要训练它，但你需要知道在什么场景下用什么方式让它发挥最大价值。

4.1 RAG 和 Agent：把 LLM 变成产品能力的两种主流形态

RAG（检索增强生成）是目前企业落地 LLM 性价比最高的范式。它的工作流非常清晰：

1. 离线阶段：把知识文档解析成文本，切分成合理大小的片段（chunk），用嵌入模型转成向量并存入向量数据库
2. 在线阶段：用户提问 → 同样转成向量 → 在向量库中检索最相关的若干片段 → 把这些片段和用户问题一起发送给大模型 → 模型基于检索内容生成答案

这一套看起来简单，真正别扭的地方全在细节。我踩过的坑包括：PDF 表格解析后文本乱序、切分粒度太大导致召回不精准、嵌入模型与检索文本的语言不匹配、知识库更新后旧向量没有及时清理。

Agent（智能体）是更进阶的形态。本质上是让模型具备调用外部工具的能力：查数据库、调用 API、执行代码、访问网页。实现上通常采取 ReAct 模式：让模型基于用户目标思考接下来该调哪个工具，观察工具返回结果，再决定下一步动作，直到达成目标。

# Agent 工具调用的核心循环（伪代码） while not task_finished: thought = llm.reason(history, available_tools) if thought.action == "call_tool": result = tools[thought.tool_name].run(thought.tool_args) history.append(result) elif thought.action == "respond": return thought.answer

诚实地讲，Agent 的可靠性问题至今仍然棘手——模型可能在工具调用格式上出错，可能陷入循环，可能被错误反馈误导。工程化的应对是三个：做好校验和重试机制、设定最大迭代次数兜底、关键路径上用人工审核收口。

4.2 提示工程只是一半，评估才是另一半

我从大量项目里悟出一个道理：可评估才能可优化。很多团队把精力全放在设计提示词上，结果改来改去全凭感觉——这版好像好一点，换一版又好像差一点，最后没法判断谁是对的。

正确的做法是先建评估集。你准备 50～200 个有代表性的真实问题，每个问题标注期望的答案要点，形成一个 golden set。每次修改 prompt、换模型、改 RAG 参数，都跑一遍这个评估集，观察通过率的变化。

评估落地有两条路：

• 规则评估：检查答案中是否包含关键实体、关键短语，适合答案比较确定的场景
• LLM-as-Judge：用另一个能力较强的模型，按你给定的评分标准给答案打分，适合开放式问答

LLM-as-judge 不是完全可靠的，它也存在偏好偏差、对事实错误不够敏感的问题。我的做法是两者结合：规则先筛一遍明显不合格的，大模型再对通过的项目做质量评级。另外，定期从线上用户反馈中抽一份新样本加入评估集，防止评估集跟真实场景逐渐脱节。

4.3 上下文工程与模型选型

Prompt、RAG 参数、工具调用这些都属于一个更大的概念——上下文工程（context engineering）。简单说，你决定让模型"看到什么"，几乎决定了它输出的质量上限。

实践中要注意的几个点：

• 把用户问题包装成结构化指令时，系统提示词应明确角色、任务边界、输出格式、知识盲区时该怎么办
• 检索出的文档片段要按相关性排序，并在提示模板中明确"只能基于以下资料回答，资料不足以回答时直接说明"
• 上下文长度不是越多越好，垃圾进垃圾出，检索结果超过 5 条以后边际效益会急剧下降

模型选型现在也很有讲究。不是最贵的模型就适合所有场景：

选型没有绝对标准，最好的办法是拿着你的评估集，在候选模型上跑一遍，看效果和成本交叉点在哪里。这个过程会逼你养成一套自己的模型评估习惯，也是工程量感的重要来源。

5. 工程化落地：从本地脚本到可靠系统的四道坎

项目原型跑通了是第一步，要成为可交付的系统，还差得远。我总结为四道坎：可复现性、测试、可观测性、部署。

5.1 依赖与可复现性管理

AI 项目最大的特点就是结果受环境影响：Python 版本不同、CUDA 版本不同、依赖库版本漂移，都可能导致结果变化。甚至同一个模型文件在不同架构的机器上推理结果都可能有一丁点差异。

工程上的对策是：

• 用锁文件锁定依赖精确版本
• 记录实验相关的所有元数据：数据版本、模型版本、代码 commit hash、关键参数、运行环境
• 输出目录按实验命名规范归档

这里说实话，很多团队一上来就整 MLflow、Kubeflow 这类重型平台，结果运维成本比实验本身还大。我更推荐渐进式方案：先用一个 CSV 记录每次实验的参数和结果，再配合目录命名规范；当项目发展到需要多人协作、大量对比实验时，再引入专门的实验追踪工具。工具永远是为流程服务的，流程不清晰之前，工具只会添乱。

5.2 测试你的 AI 代码：不只是单元测试

传统软件的单元测试在 AI 项目里当然要做——工具函数、数据解析、API 封装都需要确认逻辑正确。但 AI 项目额外需要两类特殊测试：

• 数据质量测试：写入一个校验数据的函数，比如列数量、缺失率、数值范围、类别取值集合。数据源头一变，测试第一时间报警。
• 模型回归测试：拿固定评估集，给新旧模型各跑一遍，保证新模型没有把老的能力搞退化。这跟传统开发的回归测试一个道理，只是这里的"用例"是问题-答案对。

还有一类更贴近用户的测试叫影子测试：把新模型部署在线上但只记录输出、不对用户生效，与当前生产模型做 A/B 对比。这是我心中最符合工程精神的验证方式，因为它用的是真实流量。

5.3 可观测性：日志、追踪与评估一体化

AI 应用是典型的不确定系统，模型偶尔说错话是常态，所以你不能只靠监控系统"是否崩溃"来判断健康状况，你必须观察到每一次请求的质量。

我建议至少给每个 AI 请求记录以下信息：

• 输入参数（用户问题、检索到的上下文片段ID、所用的提示词版本）
• 输出结果（生成的答案、命中的工具、推理耗时）
• 性能指标（延迟、Token 消耗、成本）
• 结果评价（规则评分、人工反馈标记）

拥有这些数据之后，你才能回答"最近准确率为什么下降了"这类灵魂拷问。像 Langfuse、LangSmith 这类工具提供了现成的追踪和标注面板，项目早期就能接上，成本不高，收益巨大。如果你不想引入额外服务，也可以用结构化日志和定时任务做评估报表，效果差不多，只是可视化差一些。

5.4 部署模式：批处理、在线推理与流式输出

不同的业务场景对应不同的部署模式，让我用几句话分别说清楚：

• 离线批处理：适合数据分析、报表生成、定时摘要等任务。特点是数据一次性灌入，任务串行或并行跑完，结果落库。实现最简单，直接用 Python 脚本加定时调度。
• 在线推理：用户请求实时到达，需要低延迟响应。通常用 FastAPI 包一层 HTTP 服务，路由到推理逻辑。要注意：模型加载一次常驻内存、请求队列和超时策略、并发上限保护。
• 流式输出：让模型一个字一个字或一段一段输出，体验更好。实现上需要把流式接口（如 SSE，Server-Sent Events）从后端一路透传到前端。

# FastAPI 流式输出示例片段 from fastapi import FastAPI from fastapi.responses import StreamingResponse app = FastAPI() @app.post("/chat") async def chat(request: dict): def generate(): for token in llm.stream(request["message"]): yield f"data: {token}\n\n" return StreamingResponse(generate(), media_type="text/event-stream")

部署层还有一个最容易忽略的点：提示词和模型参数的配置化管理。我见过太多团队把 prompt 硬编码在代码里，产品经理想调一句话都得发版。正确做法是把 prompt 模板放在配置文件或数据库里，线上支持热更新，发布代码和调 prompt 解耦。这样可以快速迭代优化，出错时也方便回溯版本。

6. 我给自己排的一条可执行的实战路线（附避坑清单）

理论讲再多不如动手，下面这条路线是我在设计这份内容时结合实际经验梳理出来的。如果你拿到这份专栏不知道从哪下手，直接照着走。

6.1 三个月阶段划分与项目建议

• 第一阶段（约第 1 个月）：夯实数据与基线能力

  每天保证 1~2 小时写代码。动作包括：用 pandas 处理一份真实数据（如某城市的共享单车骑行记录），完成清洗、统计、可视化；训练逻辑回归和随机森林两个模型，用交叉验证对比效果；写一份实验记录文档。

• 第二阶段（约第 2 个月）：打通一个深度学习闭环

  选一个中等规模的数据集（上面推荐的三个任选其一），用 PyTorch 实现"数据加载→训练→评估→调参"完整流程，尝试至少三种优化手段（调整学习率、增加层宽层深、加入丢弃层或正则化），并把每次实验的效果记录在表格中。

• 第三阶段（约第 3 个月）：完成 2~3 个 LLM 应用原型

  第一个做 RAG 问答，用自己的资料库（比如个人博客文章、公司产品文档）搭一个知识问答服务；第二个做一个具备工具调用能力的最小 Agent，让模型能查询 SQLite 里的数据并回答相关问题；第三个可以根据前两个遇到的问题自选方向（比如重排序优化、多轮对话记忆）。

  每个原型都按"评估集 + 部署接口 + 记录日志"的工程标准来做，不要只停留在 notebook 演示。

6.2 阶段目标与心态调整

这里我想多说两句，因为实操中最容易崩溃的恰恰不是技术点，而是心态。你会发现 RAG 检索回来的片段明明是对的，模型还是答非所问；你会遇到调了一下午学习率，效果反而更差；你会遇到部署时环境报错，网上搜到的解决方案又与其他库冲突。

所有这些都是正常现象。我观察到一个规律：能在 AI 工程这条路上走远的人，不是学得最快的人，而是把问题拆小、一次只解一个、并且坚持记录的人。每次遇到报错，把报错信息、当时的环境、尝试过的方案都记在笔记里，三个月后你就有了一份属于自己的排错手册，这份手册的实用价值远高于任何付费课程。

6.3 资源筛选原则

最后分享一个重要判断标准：

• 官方文档 > 教程文章：不会过时、准确、有例子。建议把官方文档当第一资源。
• 一个领域只选一本书或一门课学透：网上信息太多，容易陷入"收藏了许多内容但什么都没学会"的状态。
• 写代码时以开源项目的源码和 README 为参照：比看转述的评价文章更直观、更真实。
• 远离包装味浓厚的营销性课程和刷屏短视频：它们往往把复杂问题过度简化，学习后遇到实际问题依然毫无头绪。

我平时也会定期去 GitHub 刷一些高星的 AI 工程相关项目，观察它们怎么组织代码、怎么写 README、怎么处理测试和部署，这比任何速成班都有用。

7. 每天都值得做的三件小事

如果要在众多建议里再提炼几条，我建议你从今天开始养成这三个习惯。

第一，每天跑一段最小代码。无论多忙，保持手感和对工具链的熟悉。AI 工程的上手门槛不算高，但生疏得非常快，尤其工具链更新频繁。

第二，每天记录一个错误和它的解法。不用写长篇，把报错关键词、环境信息、解法链接存下来就行。我亲测这个习惯让第二年的排错效率提升了一倍以上，那些当年折腾一下午的问题，后来往往扫一眼笔记就能定位。

第三，每周用真实项目向自己提问一次。比如：这个 RAG 方案在 1000 篇文档时没问题，到 10 万篇文档时检索延迟会不会崩？这个 Agent 如果用户输入了恶意指令，尝试连调用内部 API 怎么办？模型的输出如果被截断了，系统能不能感知并自动重试？这些问题没有标准答案，但逼自己去想一遍，能力增长比读十篇文章都有效。

我在整理这份"ai-engineering-from-scratch"路线时最大的体会是：这条路不缺资料，缺的是结构化的路线和持续动手的习惯。希望这篇内容提供的框架刚好够你迈出第一步。你在跟着实践的时候碰到具体报错或者拿不准的选型，欢迎在评论区留言，我看到之后会尽量回复。