刚刚带完一个小团队做完一个 AI 问答产品的上线，后台还有一堆私信问我同一个问题：不是科班出身，想转 AI 工程，到底从哪开始？说实话，市面上讲 prompt 技巧、讲模型原理的教程一抓一大把，但真正告诉你“从零开始搭起一套 AI 工程能力”的完整路线，反而很少见到。这也是我看到“ai-engineering-from-scratch”这个项目标题时眼前一亮的原因——它切中的不是某一个模型怎么调参，而是 AI 工程这个岗位的完整能力栈。
这篇文章就来拆解一下，这类“从零开始学 AI 工程”的项目到底在讲什么、为什么值得跟、以及按什么顺序学才能少走弯路。无论你是后端工程师想转方向，还是刚毕业想做 AI 应用，又或者是已经会用 API 但感觉老在边缘试探、始终进不了核心，这条路线应该都能帮上忙。
1. 项目定位：为什么从零学 AI 工程，而不是从零学 AI 算法
1.1 先搞清楚 AI 工程到底解决什么问题
很多人的第一个误区，就是把 AI 工程和机器学习研究混为一谈。研究者关心的是“这个模型能不能再涨两个点”，工程师关心的是“这个模型能不能稳定跑在线上、能不能扛住流量、能不能被业务方快速调用”。同样是做 AI，两者的工作内容完全不是一回事。
AI 工程要解决的核心问题，说白了就是三件事：第一，把模型变成可用的服务；第二，让这个服务在真实业务里表现得稳定可靠；第三，在模型效果和成本之间找到平衡。所以你会发现，AI 工程岗位的日常工作里，写 Python 代码、搭接口、处理数据、看监控指标、调推理性能，这些常常比“训练模型”占的时间还多。
回到这个项目标题，它强调的“from scratch”不是为了把你培养成一个能从零推导 Transformer 公式的算法大牛，而是让你从零建立起工程落地所需的完整技术栈。一个合格的 AI 工程师，要懂一点算法以便和算法同学沟通，但更重要的是懂工程：懂系统设计、懂部署、懂评估、懂怎么让模型真正跑起来。
1.2 项目的内容架构与主线设计
把这类学习项目打开看，主线其实非常清晰，基本都会按四层递进的结构来组织：软件工程基础、机器学习基础、LLM 应用开发、生产环境部署与运营。这个顺序不是随便排的，它符合“从地基到房顶”的客观规律。
第一层软件工程基础，解决的是“你能不能写健壮代码”的问题。第二层机器学习基础，解决的是“你能不能理解模型在做什么”的问题。第三层 LLM 应用开发，解决的是“你能不能基于大模型做出真实功能”的问题。第四层生产部署与运营，解决的是“你的功能能不能上线赚钱”的问题。四级跳完，你才算是真正入了 AI 工程的门。
这套设计和市面上大部分“三天上手大模型开发”的课程有个本质区别：它不急着让你先跑通一个 demo，而是先把地基补齐。实测下来，凡是跳过工程基础直接玩 LLM 的人，前期看起来跑得很快，一旦遇到并发问题、数据问题、版本问题，马上就卡住。这就是为什么这个项目强调“从零”，先从工程基本功开始，看起来慢，其实是快。
2. 第一阶段：把软件工程基本功补到位
2.1 需要掌握的编程与工程能力清单
第一阶段的内容看起来不“AI”，但恰恰是筛掉最多人的一关。你需要掌握的东西，如果用一句话概括，就是“能写出可以被别人维护、可以被系统稳定调用的代码”。
具体来说，Python 基本功是跑不掉的，但这里说的不是会写 for 循环那种水平，而是要对类型注解、装饰器、生成器、上下文管理器、异步编程都足够熟悉。尤其是异步编程，做 AI 服务几乎天天要打交道——模型推理是耗时操作，你不能让用户请求一个个排队等着；用 asyncio 做并发控制、用消息队列做异步任务，这些是 AI 服务的家常便饭。
除此之外，还有几个平时容易被忽略但从零就绕不开的工具：Git、Docker、Linux。Git 解决的是协作和版本管理问题，Docker 解决的是环境一致性，Linux 是绝大多数 AI 服务的运行平台。这个阶段的目标很朴素——给你一台空服务器，你能把代码部署上去并让它稳定运行，这就过关了。
这里给一个实用的检查清单：
- 能在命令行里完成文件操作、进程管理、日志查看，不依赖图形界面
- 能独立编写一个带类型注解的 Python 类，并用 pytest 写单元测试
- 能写一份像样的 Dockerfile，把项目打包成镜像并跑起来
- 能理解 Git 的分支、合并、回滚，并在实际项目里准确使用
2.2 数据结构和算法在 AI 工程里的正确打开方式
不少从非科班转过来的人，一听到“数据结构与算法”就头皮发麻，以为要像准备大厂算法面试一样刷几百道 LeetCode。在 AI 工程这条路上，刷题很重要，但方向要调整。
我的建议是：重点掌握数组、哈希表、链表、栈、队列、树这几个核心结构的特性和常见操作，理解时间复杂度的含义，就够了。AI 服务里最常见的数据操作无非就是查缓存、做去重、维护一个队列、处理嵌套的 JSON 数据，这些用到的数据结构非常有限，不需要把红黑树手写一遍。
相比之下，更值得花时间的是“如何组织代码”这件事。工程和算法的分界线就在这里：算法题给你一个明确的问题，你只需要写出正确解法；但工程给你的是一个模糊的业务需求，你需要拆解成模块、设计接口、考虑异常路径。所以这个阶段除了数据结构，我强烈建议同步看一下设计模式里最简单实用的几个——单例、工厂、观察者，然后刻意练习“把一个需求拆成多个函数/类”的习惯。
我见过太多人栽在这一层，不是因为代码写不出来，而是因为写得像一坨一次性脚本：没有分层、没有异常处理、没有日志。这种代码训练模型的时候自己用还凑合，一旦要上生产，谁来维护谁崩溃。从零开始学 AI 工程，第一步就是把“代码洁癖”养出来。
3. 第二阶段：机器学习与深度学习的地基怎么打
3.1 最小必要知识集：传统机器学习学到什么程度
第二阶段进入到机器学习本身，这里也要有一个清醒的认识：你不必成为一个能发论文的机器学习专家，但你必须建立起对模型的直觉。什么叫直觉？就是看到一个任务能判断适不适合用机器学习，能说出大致用什么模型、特征怎么处理、结果怎么评估。
传统机器学习里，我建议优先吃透这几个模型：线性回归、逻辑回归、决策树（以及随机森林或 GBDT 系列）、K-Means 聚类。它们几乎覆盖了回归、分类、聚类三大基本任务，而且背后的核心思想——损失函数、梯度下降、过拟合与正则化、评估指标——会原封不动地迁移到深度学习里。
实际操作层面，用 scikit-learn 就够了，不需要从零手推矩阵求导。每个模型找一个小数据集跑一遍，习惯一下fit / predict / score这套工作流，再认真理解一下准确率、精确率、召回率、F1 这几个指标的区别。评估指标这东西，后面做 LLM 应用的时候还会反复用到，而且经常被误解，现在打好底子非常划算。
3.2 深度学习核心组件：从张量到反向传播
深度学习的部分，主线只有一个：PyTorch。倒不是说 TensorFlow 不好，而是现在无论是学术开源还是工业应用，PyTorch 生态的占比都太高了，尤其是 LLM 相关的项目，几乎全网都是 PyTorch。学它，遇到问题搜解决方案的时候会顺利很多。
入门不要一上来就啃 Transformer 原论文，先搞清楚四个核心概念就行：张量（Tensor）、自动求导（Autograd）、优化器（Optimizer）、损失函数（Loss Function）。把这四样东西的原理和用法弄明白，你就已经能看懂大部分模型的训练代码了。
很多人有个执念，一定要手动实现一遍反向传播才能安心。我个人的看法是，了解原理是必要的，但不要陷进去。反向传播的本质就是链式法则，理解这个思想之后直接交给框架就行。你的时间应该花在更有杠杆效应的事情上，比如怎么把数据组织成 DataLoader、怎么设计训练循环、怎么做模型保存与加载——这些才是日常工作中天天要用的。
这个阶段可以给自己定一个代表项目：用 PyTorch 从零训练一个简单的图像分类模型（比如 CIFAR-10 或者一个小的自定义数据集），训练完导出模型文件，再用 FastAPI 包装成一个 HTTP 接口，跑通“训练-部署-调用”的闭环。这个项目做完，你第二阶段就毕业了。
3.3 不要沉迷于手写神经网络
说了几段，关于手写神经网络这事我再泼一盆冷水。网上很多教程喜欢让你从零写一个 MLP 或者 CNN 练手，锻炼思维是好的，但有的学习者会陷入一种“必须能默写全部代码才继续学”的自我要求里，这是典型的进度杀手。
工业界的现实是：你要用现成框架写一个模型，通常只需要继承某个基类、定义好网络结构、选好优化器、调用现成的损失函数，真正需要你手动实现的部分很少。把精力放在“如何用框架高效完成训练和部署”，而不是放在“如何对抗自动求导”上，才是符合工程岗位实际需求的投入。
打个比方，你会用计算器做乘除，不等于你必须能自己设计计算器芯片。懂原理是让你在结果出问题的时候有排查方向，但大可不必为了“显得专业”而把所有底层都手搓一遍。节省下来的时间，投入到后面的 LLM 项目里，收获会大得多。
4. 第三阶段：LLM 应用工程的核心技能
4.1 Prompt Engineering 是基本功，但不是全部
第三阶段进入大模型应用开发，这是目前整个 AI 工程领域人才需求最旺盛的方向。这个阶段的起点，确实是提示工程（Prompt Engineering），但你要清醒地知道，这只是入场券，不是护城河。
提示工程的基本功包括：学会结构化地组织提示词（给模型明确角色、背景、任务要求、输出格式），学会用少样本示例（few-shot）稳定输出格式，学会把复杂任务拆成多步提示来降低单次难度。这些技巧学会了马上能用，也确实能让你的应用效果肉眼可见地变好。
但如果你只会写 prompt，那你的竞争力会很有限。因为 prompt 这个技能的门槛太低了——任何会用 ChatGPT 的人经过几小时学习都能上手。AI 工程的核心竞争力在于，把大模型集成到真实的业务系统里，解决模型输出的不可控、数据安全、成本、延迟等一系列工程问题。这也是项目把 RAG 和 Agent 放在这个阶段的根本原因。
4.2 RAG 系统：从文档切分到向量检索的完整链路
RAG（检索增强生成）是目前落地范围最广的 LLM 应用模式，简单说就是先根据用户问题检索出相关资料，再把这些资料连同问题一起交给模型生成答案。它解决的是大模型“不知道你的私有数据”和“胡说八道”两大核心痛点。
从头实现一个 RAG 系统，你会遇到几个非常工程的细节问题。第一个是文档切分，一份 PDF 要切成多大一块？切得太小，上下文信息不完整；切得太大，检索噪音又多。经验上，中英文混合文档常见做法是 500 到 800 个 token 左右作为一个块，块之间留 50 到 100 的 overlap，但这个数值一定要根据你的文档类型实测调整。
第二个是 Embedding 模型的选择。目前常用的本地方案有 BGE、bge-m3 系列，商用 API 也有不少选择。选型没有一个绝对的最好，主要看三件事：检索效果在你自己数据集上的表现、向量维度对应的存储成本、推理延迟。给自己留一个可切换的接口抽象，别把 embedding 模型写死在业务代码里，是我能给你最重要的建议之一。
第三个是向量数据库选型。这里有一个朴素但容易纠结的选择：FAISS、Chroma、Milvus、Qdrant，还有关系型数据库自带的 pgvector。做原型，Chroma 起步最快；数据量大并且需要分布式，Milvus 或 Qdrant 更稳；如果你整个后端已经在用 PostgreSQL，pgvector 是侵入性最小的方案。至于 FAISS，它其实不是数据库而是一个检索库，适合对检索部分做深度定制的人。
第四个是检索后的结果排序。初版 RAG 直接用向量相似度取 Top-K 通常效果一般，可以考虑加上重排（Rerank）环节，用交叉编码器模型对初选结果做二次精排。加一个 10 分效果的重排，往往比换个更大的底板模型更划算。
4.3 Agent 开发的关键点与工程陷阱
如果说 RAG 是“让模型更准确”，那 Agent 就是“让模型能干活”。Agent 的核心机制并不神秘——通过函数调用，模型根据用户意图选择并触发你预先定义好的工具函数。一个订机票的 Agent，本质上就是“识别用户想订票的意思，然后调用你的机票查询接口”。
做 Agent 最忌讳的是把“模型自主规划”想得太神。现实中的 Agent 系统，绝大多数是流程编排 + 有限状态判断的组合。我的经验是，在设计 Agent 时先把业务流程画出来，哪些步骤是固定的、哪些分支需要模型做决策，只在必要的分支点调用模型判断，其他环节全部用确定性代码控制。这能大幅提升系统的可靠性，也让你排查问题的时候有迹可循。
另外两个容易踩的坑：第一是上下文管理，Agent 调用多轮工具时，对话记录会快速膨胀，你要设计好历史消息的截断或摘要策略，否则 token 成本和模型输入超限会让你欲哭无泪；第二是可观测性，Agent 的失败往往藏在某一次工具调用里，强烈建议从第一天就把完整执行链路记录下来，包括模型输入输出、工具调用参数、耗时和报错，否则线上出了问题只能抓瞎。
5. 第四阶段：部署、评估与持续迭代
5.1 模型服务部署的三种常见形态
模型做出来了，应用写完了，怎么让它稳定对外服务是第四阶段的主题。这阶段第一课就是：部署方案怎么选。
第一种是最轻量的形态，直接调用大模型厂商的云端 API。这种方案的优势是省心，不操心算力、不操心模型运维，按量付费，适合业务初期的快速验证。缺点是受限于厂商限流策略，单位成本相对高，而且数据要过第三方，对部分业务有合规压力。
第二种是本地部署开源模型，用 vLLM、TensorRT-LLM 这类推理框架拉起一个兼容 OpenAI 接口格式的服务。这个方案把数据留在自己手里，单次调用成本更低，但你要自己管理 GPU 资源、处理并发和排队、做模型版本更新。对大多数有技术团队的公司来说，这是性价比最高的长期形态。
第三种是混合架构，把高频简单任务用云端 API 处理，把复杂敏感任务用本地模型处理，中间通过一层统一网关做路由。这种架构最灵活但也最复杂，适合业务稳定、流量分布清晰的阶段。
工程上落地时有一个细节：不管底层部署什么，尽量把你的业务代码和底层模型接口解耦。哪怕一开始先用云端 API 写好上层业务，未来切换到本地模型，只需要换掉网关层的实现。这个设计习惯能让你不被任何单一厂商或单一模型绑死。
5.2 从 0 搭建一套 LLM 应用评估体系
很多人把一个 RAG 或 Agent 应用开发完就开始庆祝，上线之后才发现效果忽好忽坏，用户反馈乱七八糟。原因只有一个：没有在开发阶段建立评估体系。评估，是 LLM 应用从“能用”走向“好用”的分水岭。
评估体系搭建分三层。第一层是评测集，找业务方要或自己整理一百到两百条带标准答案的真实问题，覆盖各种典型场景和边界刁难场景。第二层是评测指标，常规任务用准确率、召回率这类传统指标，生成类任务用 BLEU、ROUGE 做自动化参考，更接近真实感受的方式是用 LLM 做裁判——让一个更强的模型按你设定的维度给回答打分。第三层是回归机制，每次修改 prompt、更换模型、调整检索参数后，都要跑同一套评测集，记录分数变化，防止“修好一个 bug、引出三个新 bug”。
这个评估体系不用很花哨，但一定要沉淀成脚本和记录。我见过最崩溃的团队，是改了半个礼拜的 prompt，最后问效果到底提升没有，竟然没人能说出一个量化结论。没有评估体系的 LLM 开发，本质上就是在碰运气。把评估脚本当作工程资产来维护，它的投入产出比高得惊人。
5.3 成本控制与响应延迟优化
最后一块硬骨头是上线后的持续运营。LLM 应用里最常见的两个“隐形成本杀手”，一个是 Token 消耗，一个是响应延迟。
Token 消耗的优化有很多常规操作：减少输入侧的冗余内容、用摘要替代完整历史、用小模型处理分类任务只把生成任务留给大模型。有时候你只需要把输入历史从“完整对话”改成“最近三轮对话+前面的摘要”，成本就能直接砍掉一半，效果还不一定下降。
响应延迟的瓶颈通常在模型推理本身。先确认你的并发模式和当前模型的吞吐量是否匹配，如果推不动，先上量化或者用更小的模型，而不是盲目加机器。用 vLLM 的 continuous batching 功能可以有效提升在线服务的吞吐，这已经是目前本地部署的事实标准了，建议熟练掌握。
另外，监控指标至少覆盖这几个：请求延迟的 p50/p95/p99、Token 消耗趋势、服务错误率、用户反馈里“答非所问”的占比。这些数据里藏着你的下一次优化方向。做 AI 工程，上线只能算完成了 50%，剩下 50% 是持续观察、评估、调优的日常。
6. 学习路线中的常见误区与时间规划建议
6.1 几个我见过太多次的学习误区
先说说这段时间里我观察到最多的几个坑。
第一个坑是“模型焦虑”。每周都有新模型发出来，有些人就忍不住今天追这个、明天换那个。这种焦虑的代价是，你在“试新模型”上花的时间远超“优化系统”的时间，而系统优化才是工程价值的核心。认清一个现实：业务效果是模型、数据、提示词、流程设计共同作用的结果，单换模型解决不了系统性问题。
第二个坑是“只学 API 不学原理”。会用大模型 API 很容易，但这会让你停留在“调包侠”的层面。当你的业务并发高了、效果不行了、成本超了，如果你不理解模型推理为什么要 GPU、为什么输出是随机的、为什么上下文越长越慢，你根本不知道从哪下手优化。原理不需要学得多深，但基础的运行机制一定要懂。
第三个坑是“跳过评估直接上线”。这个坑在上一节详细说过了，这里再强调一次——没有评估就谈不上迭代，没有迭代就谈不上工程。做 AI 工程的人，必须培养的第一职业习惯就是量化思维。
第四个坑是不写文档、不做分享。做技术的人很多不屑于写 README 和项目总结，但在 AI 工程这个快速迭代的领域，文档就是你和未来自己的通信录。你三个月后回看一个项目，如果没有任何记录，基本等于重新开始。
6.2 普通上班族可执行的时间规划参考
结合带人经验和不少成功转行的案例，我整理了一个参考时间表。每天能投入两小时左右的，半年到一年期比较现实。
| 阶段 | 主要内容 | 建议时长 |
|---|---|---|
| 第一阶段 | Python、Git、Docker、Linux 基础 | 4-6 周 |
| 第二阶段 | 机器学习基础 + PyTorch 实践 | 8-10 周 |
| 第三阶段 | Prompt、RAG、Agent 项目实战 | 10-12 周 |
| 第四阶段 | 部署评估 + 完善一个完整项目 | 6-8 周 |
这个时间表适合有一定编程基础的人。如果完全零基础，Python 基础阶段要再拉长一倍。整个过程中最重要的一件事，是每个阶段都要有“拿得出手的作品”：第一阶段是一个部署在服务器上的脚本服务，第二阶段是一个能调用的模型接口，第三阶段是一个完整的 RAG 问答产品，第四阶段是一个扛得住基本并发访问并在持续迭代的正式项目。
做学习笔记的时候，也建议刻意练习“输出驱动输入”——每学一个模块，写一篇短文或者录一段十分钟的讲解。教是最好的学，这句话在 AI 工程这条路上特别灵。整个项目“from scratch”的路线，说短不短，说长也不长，关键是别停在收藏夹里。
最后分享一个个人体会。我见过太多人拿着同一份学习路线，有人半年后做出像样的作品顺利转行，有人一年后还在问“新模型出来了我该学哪个”。差别不是聪明程度，而是有没有真正动手把项目跑通、有没有遇到问题就死磕到底。AI 工程这个领域，看十遍教程不如跑通一遍代码。从零开始不难，难的是每天都往前拱一点，然后在一两个完整项目里把那些零零碎碎的知识焊接起来。
