企业官网建设流程全解析

1. 项目开题：ai-engineering-from-scratch 究竟要解决什么问题

几年前如果有人问我"AI 工程师应该学什么"，我会推荐一堆数学、经典机器学习论文、深度学习课程。但这两年我在实际工作中发现，市面上最缺的不是能推导公式的算法研究员，而是能把模型接进真实业务、让它在生产环境里稳定跑起来的工程型人才。

我自己整理这个 ai-engineering-from-scratch 项目的初衷很简单：把"从刚接触 AI 到能独立交付 AI 应用"这条路上的所有关键节点，拆成一套可以照着执行的学习路线。它不是一个课程大纲，更不是论文导读，而是一份“从零开始动手做 AI 系统工程”的实践地图。标题里的 from scratch 有两层含义：一是从编程基础开始补，二是从模型背后的工程逻辑开始理解，而不是只会调现成的接口。

这篇文章适合两类人。一类是转行的开发者，你写过 Web 服务、会点 Python，但不知道 AI 工程该从哪里切入。另一类是算法背景的同学，你能跑通训练脚本，但对部署、服务化、评测、监控这些"工程味"很重的事觉得陌生。两种人读完之后，应该都能清楚地知道下一步该做什么、做到什么程度算合格。

很多人把 AI 工程理解成"会用几个框架、能调几个模型"，这是最大的误区。我在项目里反复强调一个观点：AI 工程不是模型工程，而是系统工程能力 + 模型知识 + 数据意识的复合体。你构建的是一个有模型参与的软件系统，模型只是系统的一部分。想明白这件事，"从零开始"的路线图就自然清晰了。

1.1 这两年 AI 工程和传统机器学习工程有什么本质变化

如果你翻三年前的岗位描述，"机器学习工程师"要求的东西大多是：特征工程、模型训练、调参、离线评测。整个流程以模型为中心，上线节奏按周甚至按月算。但现在"AI 工程师"面对的是完全不同的局面。

首先是模型获取方式变了。以前想用一个能处理自然语言的模型，要么自己从预训练开始训，要么拿开源模型做微调，成本和门槛都很高。现在有大量开源权重模型和成熟的推理框架，你可以直接基于一个能力很强的底座模型构建应用，不碰训练环节也没关系。这意味着 AI 工程师的核心工作从"怎么把模型训好"变成了"怎么把模型用好、用稳"。

其次是系统复杂度上升了。一个典型的现代 AI 应用，除了模型本身，还涉及数据接入、向量检索、结构化输出、上下文管理、评测反馈、成本控制、并发调度、可观测性。模型占的代码量可能不到 20%，剩下全是工程活。如果不具备系统思维，只懂模型，做出来的东西几乎无法交付。

第三是迭代速度完全不同。大模型应用的开发节奏是以天甚至小时计算的。Prompt 改动、检索策略调整、工具调用链路的变更，都需要快速验证。这就要求工程师手上有非常顺畅的本地开发、测试、评测基础设施。你在 Notebook 里玩模型的那套流程，放到这种节奏下完全不够用。

1.2 "从零开始"到底要补齐哪些底层认知

这里说的"从零"，不等于完全没有编程经验。我的建议是：先把 Python 写到能独立完成 Web 请求、文件读写、基础数据处理这三件事的水平，再开始进入 AI 工程的正题。这不难，一两个月集中练习就能做到。

有了编程基础之后，真正需要建立的底层认知有三块。

第一块是数据视角。AI 应用的输入输出本质都是数据，你必须对数据的形态、规模、质量、流动方式有感觉。很多人做检索增强应用效果差，根因不是模型不行，而是对知识库里文本的结构化程度、切分粒度、噪声比例完全没有概念。数据认知不到位，后面每一步都会带病前进。

第二块是工程视角。怎么把一段脚本变成可以被稳定调用的服务？接口怎么设计？异常怎么兜底？日志和监控怎么埋点？成本怎么估算和控制？这些能力不是模型知识能替代的，必须通过写完整项目来练。

第三块是评测视角。这也是最容易被忽略的。模型应用不像传统软件有明确的输入输出断言，它没有标准答案，那你怎么知道这一次改动是变好了还是变坏了？必须建立一套评测方法论：从用例集设计、评价维度定义，到人工评估流程和自动化评分。没有评测意识，做 AI 工程就像蒙眼开车。

2. 技能地图：AI 工程师需要掌握的六大能力块

2.1 Python 和软件工程基础：不是会写脚本，是会写产品代码

我在项目的第一阶段只安排了一件事：把 Python 从"能跑"练到"能交付"。很多人会写脚本，但脚本和产品代码之间隔着好几道坎。

第一道坎是工程组织。你会不会用虚拟环境管理依赖？会不会用 Git 做分支管理和代码回滚？能不能把一段逻辑拆成合理的函数和模块？这些看起来很基础，但在 AI 项目里，依赖冲突和代码混乱是消耗时间最多的问题之一。

第二道坎是错误处理。AI 应用里模型输出可能超时、返回格式可能非法、外部接口可能限流。你没有做好异常捕获和重试策略，线上就会频繁报错。起步阶段不用学得很深，但至少要知道 try/except 的正确用法、日志模块怎么配置、超时和重试的基本模式。

第三道坎是性能意识。Python 本身不算快，但 AI 工程里真正需要高性能的环节往往可以通过向量化操作、并发调用、异步 IO 来解决。你不需要成为 Python 性能调优专家，但要对哪些操作是 IO 密集、哪些是 CPU 密集有基本判断，这直接影响你做服务化时的并发设计。

我用一个很直白的标准来判断基础是否合格：给你一个文本处理任务，你能不能写出一个带命令行入口、有日志输出、有错误处理、能处理批量的工具脚本，并且把它放到 GitHub 上让任何人 clone 下来就能跑。如果能，基础这关就过了。

2.2 机器学习与深度学习：知道原理，但不用成为推导专家

很多自学 AI 的人卡在数学上，觉得线性代数、概率论、微积分不精通就学不下去。我的看法比较务实：数学基础要有，但不需要学到数学系水平。

你对以下概念要有直觉理解：梯度下降是"沿着损失下降的方向调整参数"；过拟合是"模型把训练集背下来了，遇到新数据就懵"；embedding 是"把文字变成一组有语义方向的数字向量"。如果你能用大白话解释这几个概念，并且知道它们在模型训练和模型应用里分别起什么作用，就够用了。

深度学习部分，重点理解 Transformer 架构的核心思想——自注意力机制。你不需要能手推 attention 公式，但要理解"模型为什么能根据上下文关系来理解一个词"。这对你后面做 Prompt 设计、上下文管理有直接帮助，因为你会知道模型对输入顺序、信息重复、指令清晰度的敏感度到底来自哪里。

另外我要强调一个方向：别花太多时间在训练模型上。除非你想成为算法研究员，否则对一个 AI 工程师来说，理解训练流程、知道什么时候需要微调、怎么评估微调效果，远比亲手训练一个大模型重要。我在项目里建议的路线是：跑通一个小的文本分类微调示例即可，重点是理解训练流程和评价流程，然后把精力放到应用层工程上。

2.3 数据工程基础：检索增强和微调都依赖它

AI 工程师最容易忽略的就是数据能力。市面上很多教程都在讲模型、讲框架，但真实业务里，你的数据往往是脏的、碎的、格式混乱的。

你需要掌握的数据技能包括：常见格式的读写与转换，包括 JSON、CSV、Markdown、PDF 等；文本清洗的基本套路，比如去重、去噪、格式统一、敏感信息过滤；还有数据切分与分块，这对检索增强应用至关重要。你可能不需要精通 Spark 这类大数据框架，但要熟练处理百万字级别的文本语料。

我在实际项目里遇到过最典型的情况：客户给了一堆扫格式混乱的文档，有扫描图片、有表格、有手写批注。如果直接把这些文档拿去做向量化，检索质量会非常差。后来我花了大量时间做解析、清洗、结构化，才把应用效果提上来。数据工程的投入产出比，在所有 AI 工程环节里几乎是最高的。这也是为什么我在学习路线里专门划出三周时间给数据处理练习。

2.4 模型服务化：把模型跑起来只是第一步

模型在 Notebook 里能跑，不代表它能上线。服务化是整个 AI 工程里最考验综合能力的环节。

服务化的核心目标有三个：让模型可以被程序稳定地调用，让调用延迟可控，让并发量可扩展。这需要你至少了解：HTTP 接口设计的基本规范、请求和响应的数据结构怎么定、怎么用缓存减少重复计算、怎么做并发控制、怎么处理模型加载和显存管理。

以做大模型推理服务为例，你可能需要考虑：模型是常驻内存还是按需加载？单请求的响应时间能不能接受？每秒能处理的请求数是多少？如果超过负载，是排队、降级还是限流？这些问题，没写过真实服务的同学基本没概念，但每一个都是生产环境的必答题。

Docker 是我强烈建议尽早掌握的工具。你不需要成为容器专家，但至少要会用 Dockerfile 把一个模型服务打包成镜像、能在本地跑起来。它可以帮你解决最头疼的环境一致性问题——你机器上能跑，别人机器上跑不了，这种问题在 AI 项目里太常见了。

2.5 LLM 时代的应用技能栈：Prompt、检索增强、Agent

这是 AI 工程师区别于传统后端工程师最明显的能力块。整个大模型应用开发的基本功可以概括为三件事。

第一件事是 Prompt 工程。它的本质不是"写提示词"，而是理解和控制模型的输出行为。你要知道怎么把任务描述清楚、怎么给出示例（few-shot）、怎么限定输出格式（比如要求 JSON）、怎么处理模型"不听话"的情况。这些听起来简单，但真正做到可靠，需要大量实验和积累。

第二件事是检索增强。核心思路是：不把大模型当作唯一的"知识源"，而是先从一个外部知识库里检索相关信息，再把这些信息拼接进上下文，让模型基于这些资料回答。这套方案能解决模型知识陈旧、产生幻觉、无法引用来源等问题。它的工程难点在于：文档怎么切分、向量怎么建索引、检索的精度怎么评估、检索结果和 Prompt 怎么组合。我后面会用实际项目详细拆解。

第三件事是 Agent。简单说就是让模型具备调用工具完成多步骤任务的能力。模型决定"下一步调用什么工具、传什么参数"，程序执行工具并把结果返回给模型，模型再决定下一步。这里的关键不是框架用得有多花哨，而是怎么设计可靠的工具接口、怎么控制模型在循环里不跑偏、怎么设定任务终止条件。

2.6 评测与可观测性：AI 工程里最容易被偷工减料的 20%

我在带项目时发现一个规律：前面所有环节大家都有热情学，一到评测和监控就开始敷衍。但实际上，评测能力决定了你能不能持续改进，监控能力决定了你敢不敢上线。

评测体系从三个层面搭。第一层是用例集，你得有几十上百个覆盖典型场景的测试问题，每个问题有预期答案或者参照答案。第二层是评价维度，常见的有准确性、完整性、相关性、格式合规性、安全性。第三层是评估方式，初期靠人工打分，形成稳定标注后可以逐步用模型来做辅助评分。

可观测性包括三件事：日志记录每次请求的输入、输出、耗时、Token 消耗；指标统计响应时间分布、成功率、成本趋势；追踪记录一个请求完整的处理链路，比如"检索用了哪些文档 → 拼接了什么内容 → 模型输出了什么"。这三件事做好，你在线上遇到问题就不是靠猜，而是靠数据定位。

3. 实操路线：我建议的三阶段学习方案

3.1 第一阶段：工具链打磨与环境建设（2~3 周）

这个阶段不做复杂项目，目标是把工具链练到顺手的程度。

我建议从头配一遍开发环境：装好 Python 环境管理工具、配好代码编辑器、装好 Git 并和远程仓库打通。然后刻意练习一套标准的"AI 工程师工作流"：在本地建一个干净的项目目录，用虚拟环境管理依赖，写一个调用大模型接口的脚本，跑通之后再改成命令行工具，最后推送到 GitHub。

这个阶段还要解决一个关键问题：本地模型还是 API 服务。我的建议是两条腿走路。API 服务上手快、效果稳定，适合学习 Prompt 和业务逻辑；开源模型可以用自己的消费级显卡推理，适合学习部署和深入理解模型行为。两者都要会用，因为你工作中很可能都要接触。

第一个小里程碑：做一个命令行版本的"智能翻译工具"。你输入一句话，程序调用模型翻译成指定语言，要求输出结构化的 JSON 结果，并且有日志和错误处理。这个小项目能一次性练到 API 调用、参数设计、结构化输出、异常处理这四个核心技能。我实测下来，多数人一周内能完成。

3.2 第二阶段：完成第一个完整的 AI 小应用（4~6 周）

第二个阶段开始进入应用开发。我的推荐项目是个人知识库问答系统，也就是常说的检索增强应用。为什么选这个项目？因为它几乎覆盖了 AI 工程的所有核心环节：数据处理、向量化、检索、上下文组合、模型调用、接口封装。

这个项目的完整实现路径是这样的。第一步是数据准备：找一批你自己熟悉的文档，比如你的学习笔记、工作文档，转成纯文本，做清洗，然后切分成合适大小的块。切分多大会适？这个要实验，我常用的经验是 300 到 800 字一块，但具体要看文档类型。第二步是向量化：把文本块通过嵌入模型转成向量，存入向量数据库。第三步是检索：用户提问后，先把问题转成向量，在库里做相似度搜索，拿到最相关的几块内容。第四步是生成：把用户问题和检索到的内容拼接成一个 Prompt，交给模型生成回答，并要求它标注答案来源。

完成这个项目后，你要额外做两件事来强化工程意识。一是把它封装成一个 Web 服务，让用户可以通过 HTTP 接口提问。二是建立一份评测用例集，记录下每个用例的检索结果和最终回答质量。做完这两件事，你就算真正入门了。

3.3 第三阶段：生产化改造与系统设计（6~8 周）

最后一个阶段是最接近真实工作的部分。前两个阶段做的是"能用"的应用，这个阶段要把它改造成"能上线"的系统。

生产化改造的第一件事是服务化升级：用成熟的 Web 框架重构接口层，定义清晰的请求响应模型，实现异步处理，再加上超时控制、限流和错误码规范。第二件事是容器化部署：写 Dockerfile 把应用打包，学会用容器管理本地和服务器的运行环境。第三件事是加评测和监控：把之前积累的用例集变成自动化评测脚本，让每次改动后都能跑一遍回归测试；接入日志采集和监控大盘，能看到在线请求的成功率和平均延迟。

如果还有余力，我建议做一个小型 Agent 应用。给模型配置两三个工具，比如"查天气工具"和"查日历工具"，让它学会根据用户指令决定调用哪个工具、传什么参数。这个练习能帮你理解 Agent 的循环机制、工具描述怎么写才容易被模型理解、怎么做多轮对话的状态管理。做完这个，你对现代 AI 应用的整个技术版图就有完整的认知了。

4. 项目实战拆解：三类练手项目的完整思路

4.1 入门练手：命令行版文档问答工具

这类项目的定位是"小而全"：功能简单，流程完整。核心价值在于让你第一次把模型调用嵌入一个真实可用的程序里。

设计思路上，我建议把程序拆成三层。输入层负责接收命令行参数、读取文件；处理层负责组装 Prompt、调用模型；输出层负责格式化结果、写日志。这个分层看起来简单，但能帮你在早期就建立模块化思维，避免以后所有逻辑堆在一个文件里。

实操中有一个关键细节：让模型输出结构化数据。比如要求它回答时同时给出"答案""置信度""所依据的原文片段"三个字段，并用 JSON 格式返回。这个习惯能极大方便你后续做结果评估和展示，也能帮你练习如何设计清晰的 Prompt。解析模型返回的 JSON 时要注意容错，模型偶尔会输出多余的解释文字，你需要写可靠的后处理逻辑来提取 JSON 部分。

还有一个容易被忽略的点：Token 消耗计算。每一次调用都在花钱，命令行工具特别适合做这种实验，因为你可以直观地对比不同 Prompt 写法、不同输入长度下的 Token 用量，建立起成本意识。我在教学里发现，很多新手对 Token 完全没有概念，等到做生产系统才会发现预算超支，这个毛病最好从入门项目就纠正过来。

4.2 进阶练手：带检索增强的 Web 知识库系统

这是整个学习路线里含金量最高的一个项目。它的价值在于，你能亲眼看到"模型能力不足"如何被系统工程弥补。

举个我实际遇到的例子：用底座模型直接问"我们公司的报销流程是什么"，模型大概率会胡编一个流程。但加上检索增强之后，系统先从公司制度文档里检索出相关的几条制度，再让模型基于这些制度内容作答，回答准确率会从不到一半提升到九成以上。这个提升不是模型本身变强了，而是系统工程起作用了，这正是 AI 工程师的价值所在。

做这个项目时，我建议你重点关注三个实验。第一个实验是切分粒度对检索效果的影响：分别用 200 字、500 字、1000 字的切分长度建索引，比较同一个问题的检索结果，你会发现切分太碎会丢失上下文，切分太大又容易混入噪声，不同文档类型的最优切分长度差异很大。第二个实验是检索数量对回答质量的影响：给模型喂 3 段上下文和喂 10 段上下文，回答质量不一定更好，有时反而会变差，你要找到合适的中间值。第三个实验是 Prompt 模板的作用：同一份检索结果，用不同的指令措辞让模型"只依据资料回答、不要使用内部知识"，输出风格和准确性会有明显区别。

工程实现上的核心难点有两个。一是文档更新的同步问题：知识库内容变化后，向量库的索引怎么增量更新？这是一个非常实际的线上问题。二是并发请求下的性能优化：向量检索和模型调用哪个环节是瓶颈？要不要加缓存？这两个问题能回答清楚，你的工程能力就明显超过只看教程的人。

4.3 高阶练手：可评测、可观测的 Agent 服务

三阶段项目的进阶形态是 Agent。但我的建议是：不要一开始就用很重的框架，先自己手写一个最简单的 ReAct 循环，也就是"思考 → 调用工具 → 观察结果 → 再思考"的循环。

手写循环的好处是让你理解 Agent 的本质，而不是被框架封装的黑盒带跑。你只需要一个模型接口、一个"可用工具列表"的定义、一个执行工具的函数、一段循环判断逻辑。整个核心代码不超过两百行，但跑通之后，你对 Agent 的理解会比用过十个框架的人深刻得多。

工具定义的细节很重要。模型是看"工具描述"来决定调用哪个工具的，所以描述必须准确：工具是做什么的、参数是什么格式、什么情况下该用这个工具。描述写得含糊，模型就会乱来。我在项目里试过把工具描述从一句话扩成一段带示例的说明，工具调用的准确率立刻上升了十几个百分点，这个优化几乎零成本。

高阶项目还要求你做两件事：一是设计评测方案。给 Agent 准备一组包含多个工具调用的复杂任务，看它能否正确规划步骤、能否在出错后恢复。这类评测不能只看最终结果，还要看中间过程的合理性。二是做可观测性。记录每一轮"思考、行动、观察"的日志，一旦 Agent 行为异常，你能从日志里完整还原它当时的决策依据。没有这个基础，Agent 上线基本等于碰运气。

5. 高频踩坑实录与排查方法

5.1 环境与依赖的坑：版本不匹配引发的连锁崩溃

AI 生态的依赖更新极快，框架之间版本不兼容是家常便饭。我见过太多人把时间浪费在装环境上，最后对项目失去兴趣。

我总结了一套比较靠谱的应对方法：每个项目都用独立的虚拟环境，不确定的依赖关系先查兼容性表再安装；把环境配置写清楚，让仓库里的 README 直接列出安装命令；遇到诡异报错，先怀疑是版本问题，主动查看版本对应关系而不是盲目搜索错误信息。这类问题的排查思路比具体命令重要得多：先最小化复现，再逐个排除可变因素，不要每次都从头开始重装一遍。

5.2 数据处理的坑：文本质量决定应用上限

如果把做检索增强应用的过程复盘一遍，你会发现大量问题出在数据处理阶段。比如 PDF 解析后文字顺序错乱、表格内容丢失、页眉页脚混入正文，这些问题不解决，向量化和检索环节做得再好也是白费。

我的教训是：在项目早期就要对数据质量做抽样检查。别只看前几段正常就继续跑流程，要随机抽查不同的文档类型、不同页面的解析结果。还要注意清洗逻辑不能过度，比如有的文档含有重要的表格数据，盲目丢行会导致信息缺失。数据处理好之后，建一个简单的质检报告：记录了总文档数、切块数、空块率、平均块长度，这样后续效果变差时能快速定位是不是数据侧的问题。

5.3 模型输出不可控的坑：格式、幻觉、自我矛盾

模型输出不等于程序返回值，它经常不按你的要求来。这是 AI 工程里最需要适应的一点。

格式问题最常见。你要求 JSON 输出，它给你在 JSON 外面包了段解释文字。应对方法是多层防护：Prompt 里强约束、后处理时提取 JSON 片段、解析失败时尝试修复或重试。幻觉问题是另一个高频坑：模型会自信地输出知识库里没有的内容。缓解手段是 Prompt 明确约束"只依据给定资料回答"，同时要求模型在资料不足时直接说"不知道"，再加上答案溯源机制，让用户可以查看依据。

我踩过最深的坑是只优化"单次示例"，忽视了整体稳定性。模型对输入措辞很敏感，同一个问题换种问法结果可能完全不一样。所以建立覆盖面广的评测集非常必要，你要以"一组用例的平均表现"为优化目标，而不是盯着某一个漂亮案例反复调。

5.4 评测与迭代的坑：没有基线，改进就是空谈

很多人在做模型应用时改了一版 Prompt，觉得效果"看起来好一点"，然后就上线了。这是非常危险的习惯。没有量化对比，你怎么确定改动是真正变好而不是其他因素在起作用？

正确的做法在一开始就要定好评测基线。先跑一遍全部用例集，记录各项指标作为基线。每次代码或 Prompt 改动后，重新跑一遍，对比指标变化。如果时间紧张，至少保证每次只改动一个变量，避免多个因素混在一起导致无法归因。评测跑得越频繁，迭代效率反而越高，因为你能立刻知道哪些改动是有效的。

5.5 学习心态的坑：知识焦虑和工具追逐

最后聊一个非技术问题。AI 领域变化太快，每周都有新框架、新论文、新工具，很多人陷入收藏教程永不行动的状态。

我的建议是：只看三类资料。第一类是你当前项目需要的技术资料，第二类是公认的底层原理讲解，第三类是经典项目的完整复盘。其他的一律先存着不看。工具方面，坚持"能用现有技术解决就不换新工具"的原则，等你真的遇到瓶颈，再考虑引入新框架。这条原则能帮你省下大量时间，把精力用在真正提升能力的地方。

6. 最后分享几点我的体会

这个项目我自己一路做下来，最大的感受是：AI 工程的门槛不在模型有多深奥，而在于它要求你同时具备数据敏感度、工程严谨性和系统思维，这三样东西都没法跳过，只能靠真实项目慢慢积累。

如果你正在走这条路，我有三个具体的建议。

第一个建议是从小闭环开始，不要贪大。哪怕只是跑通一个命令行问答工具，也要让这个闭环包含调用、输出、日志、错误处理这四个环节。小闭环跑顺了，才有资格谈更大系统。

第二个建议是把评测当作开发基础设施而不是额外负担。我见过太多人做好了功能却不做评测，结果上线后用户反馈的问题五花八门，根本不知道从哪修起。花时间搭一个哪怕不太完善的评测集，回报都会超出你的预期。

第三个建议是定期回头审视自己的项目。每隔几周看一遍自己上个月写的代码，你会明显看到设计权衡的进步。把项目里踩过的坑记录下来，这也是一份属于你自己的工程经验资产。

这些内容后续还可以继续扩展，比如模型微调实战、推理性能优化、多模态应用集成，都是很值得探索的方向。但不管怎么扩展，底层的工程思维、数据意识和评测习惯，永远是 AI 工程师最值钱的看家本领。