在去年年初还是一名“转行观望者”的时候我在网上搜过无数次“ai-engineering-from-scratch”这个关键词。它看起来像是一个仓库名又像我给自己定的一条路线代号可真正开始推进时才发现大多数教程只告诉你“怎么训练一个模型”几乎没有人告诉你“要把哪些能力补上才算一个真正合格的 AI 工程师”。这篇文章是我从零基础一步步走到能独立负责线上 AI 服务的完整复盘包含各阶段的具体动作、用到的工具、踩进去过的坑以及一些拿过来就能用的建议。我写这篇内容的预设读者不是已经能手推 Transformer 源码的算法研究员而是像我当初那样写过一点 Python高等数学基本还给老师在“要不要先补数学”和“教程收藏了就是学会了”之间反复横跳的普通人。不管你是想转行、想给自己的产品加一个 AI 功能还是在公司里被迫接了一个和机器学习相关的内部需求这条路径都可以直接用。唯一的前提是你真的愿意每周挤出至少十个小时动手敲代码。1. 被问烂的“零基础”问题我先把范围说清楚1.1 到底什么是 AI 工程它和算法研究、数据分析有何不同大多数人在起步阶段最容易被名词困住。数据分析、机器学习、深度学习、AI 工程听起来好像一回事实际干起来差别非常大。我当时对 AI 工程的理解是“训练一个准确率很高的模型”。后来真正上手才发现AI 工程更接近“软件工程 模型应用”的交叉岗位。它的核心任务不是发明新算法而是把现有模型稳定、高效、可维护地集成到真实系统里。可以这样类比模型是一个发动机AI 工程师负责的是整车——不仅仅是把发动机装上去还要考虑燃油系统、刹车、仪表盘、售后保养甚至要考虑司机怎么开最顺手。一条完整的 AI 工程链路至少包含以下环节业务问题到数据问题的翻译客户说“帮我识别垃圾评论”你要能把它转成一个文本分类任务并确定用什么样的数据、什么样的指标来衡量效果。数据获取、清洗、版本管理没有干净可靠的数据模型精度再高也是空中楼阁。模型训练、调优或微调这部分绝大多数人最熟悉但它只是五分之一的工作。离线评估和线上回归怎么在发布前就知道改动是否更好怎么防止模型悄悄退化。部署、监控、迭代把模型变成持续提供价值的服务而不是一次性交付物。算法研究员的核心产出是“论文里多刷几个点”数据分析师的核心产出是“看得懂的报表和结论”而 AI 工程师的核心产出是“稳定运行在业务里的 AI 能力”。想清楚这个定位你就知道自己该怎么分配学习时间。1.2 零基础进来到底需要什么前置条件网上很多资料都会甩出一张数学清单线性代数、概率论、最优化、微积分。我当时被这张清单直接劝退过好几个月现在回头看这些知识非常重要但绝不是起步阶段必须学完的。真正需要的前置条件只有三个第一能独立写一点 Python熟悉基本语法、函数、循环、列表字典操作第二遇到报错会用搜索引擎或查官方文档而不是立刻放弃第三有持续折腾的耐心。如果你现在 Python 完全不会也没关系花两周过一遍基础语法再回来看这篇文章效果会好很多。数学知识可以在项目里逐步补。比如你遇到梯度下降再去补导数概念遇到损失函数再去查概率分布。用应用倒逼理论效率和记忆深度远高于顺序啃教科书。我身边成功转行 AI 工程岗的朋友几乎没有一个是“把数学书啃完才动手”的。1.3 零基础起步时最该盯住的目标“从零开始学 AI 工程”这个方向太宽容易让人选择困难。我给当时的自己定过一个极其具体的目标在三个月内独立完成一个从数据清洗到模型部署的小系统哪怕这个系统只解决一个非常小的业务问题。这个目标为什么比“学完某某课程”更有效因为它强制你走完所有环节。很多人在“训练模型”这一步反复打转模型调参调得差不多就停了结果一遇到部署、接口封装、请求延迟的问题就抓瞎。如果你一直停留在练习阶段就很难体会到 AI 工程真正困难的地方在哪儿。第二个月之后我还给自己加了一条规则每个项目都必须写一篇复盘记录“我本来想做什么、实际做了什么、哪里卡住了、下次怎么改进”。这条规则后来成了我成长速度最快的杠杆因为写出来迫使我把模糊感觉变成清晰判断。2. 第一阶段实操第一周跑通首个模型别先碰理论2.1 为什么我拿“房价预测”开刀而不是图像识别刚开始选练习项目的时候我曾想过直接做“猫狗图像分类”因为看起来炫酷、有成就感。但实际尝试后我发现一个残酷的事实图像分类虽然原理不难但要处理的数据体量、训练时间、环境依赖都远超新手承受范围。一个 GPU 版本的依赖冲突就能耗掉一晚上模型还没跑起来热情先被磨没了。后来我把第一个项目换成了“房价预测”结构化数据、几千行记录、不需要 GPU一个最基本的全连接网络或线性模型就能跑出结果。它完整覆盖了 AI 工程的必经步骤加载数据、清洗缺失值、特征分析、训练模型、评估指标。这个选择背后的逻辑是第一次项目的目标不是复杂度而是让你完整地走通一条流水线获得最直观的正反馈。模型预测得准不准还在其次关键是“我从原始数据一路搞到了指标输出”的完整感。有了这次成功后面学深度学习时会更有底气。2.2 我实际使用的最小环境组合在第一阶段我坚持一个原则能用最简单工具完成的绝不引入高门槛框架。我当时的组合是这样的Python 3.10 或 3.11装好 pip 和 venvJupyter Notebook 或 VS Code用于交互式探索pandas处理表格数据scikit-learn提供大量现成模型和评估函数matplotlib 或 seaborn做简单的可视化安装命令可以浓缩成一行pip install pandas scikit-learn matplotlib seaborn jupyter我当时看到教程里一上来就配 PyTorch、CUDA 驱动、Docker 镜像特别焦虑觉得自己环境不够“专业”。实际上scikit-learn 在中小型结构化数据任务上非常可靠接口设计也足够经典。用它的另一个好处是你能在完全不懂反向传播的情况下先理解“机器学习到底在做什么”后续再深入框架会很顺。2.3 第一个模型的完整过程复盘以加州房价数据集为例它的目标是给定 8 个维度的特征预测某区域的房价中位数。我当时的流程大概是import pandas as pd from sklearn.model_selection import train_test_split from sklearn.ensemble import RandomForestRegressor from sklearn.metrics import mean_squared_error df pd.read_csv(housing.csv) df df.dropna(subset[total_bedrooms]) X pd.get_dummies(df.drop(median_house_value, axis1)) y df[median_house_value] X_train, X_test, y_train, y_test train_test_split( X, y, test_size0.2, random_state42 ) model RandomForestRegressor(n_estimators200, max_depth15, random_state42) model.fit(X_train, y_train) pred model.predict(X_test) print(RMSE:, mean_squared_error(y_test, pred, squaredFalse))这个代码不是最优的但它完整体现了机器学习的关键思想把数据切分成训练集和测试集用训练集学习规律用测试集判断泛化能力。我当时把这个 demo 跑通之后又花了大量时间做了两件事一是画特征重要性图看看哪些因素对房价影响最大二是尝试调整随机森林的深度和数量观察指标怎么变化。这个过程看起来简单但它帮我建立了两个极其重要的直觉第一模型的性能上限很大程度由数据质量决定而不是由花哨算法决定第二评估指标和切分方式会影响你对模型的判断。没有这些直觉后面学深度学习的时候容易被网络结构牵着走。2.4 这一阶段最容易踩的三个坑第一个坑是“资料囤积症”。我收藏过十几篇“零基础入门机器学习”的文章却一个示例都没亲手跑过。收藏行为给人“我在学习”的错觉但脑子其实没动。破法很简单严禁只收藏每收藏一个教程必须输出一段自己实现的代码。第二个坑是“过早补数学”。我一上来就买了本厚书的线性代数部分边看边怀疑人生。后来才发现在模型代码跑通之后再回头看梯度下降和矩阵运算原先死活记不住的概念忽然变得清晰了因为你对“它用在哪”已经有了具象认知。第三个坑是“追求模型指标而忽略流程”。新手很容易反复调参总希望 RMSE 再小一点却忘了记录自己每一步做了什么。没有实验记录就没有可复现性后面做任何调整都会变成玄学。从第一个项目开始就养成记录实验的习惯受益会持续到很久以后。3. 第二阶段关卡亲手写出神经网络才真正看懂上层框架3.1 从调库到手写这条坎我卡了两周用 scikit-learn 跑完几个项目后我开始接触深度学习也学着用 PyTorch 搭了几个模型。那时我只是照着教程复制代码稍微改一改结构看着准确率变化就觉得“会了”。直到有一天朋友问我损失函数里有几个参数每层的数据形状是怎么变化的我发现自己居然答不出一个完整的推导过程。于是我决定停下来用 NumPy 从零写一个最简单的两层神经网络去解决一个二维点的分类问题。这个过程极其痛苦我大概花了两个星期断断续续才把正向传播和反向传播的代码完全调通import numpy as np def sigmoid(x): return 1 / (1 np.exp(-x)) def sigmoid_deriv(x): return x * (1 - x) # 以反向传播的核心步骤为例 # 假设已经计算出输出层误差 error_output # 隐藏层误差 输出误差乘权重再乘激活函数导数 error_hidden error_output.dot(W2.T) * sigmoid_deriv(a1) W2 a1.T.dot(error_output) W1 X.T.dot(error_hidden)这段代码的数值结果可能远不如 PyTorch 干净高效但它逼我搞清了每一个张量的形状、每一步梯度的流向。之后再回过来看 PyTorch 的模型代码映入眼帘的不再是抽象 API而是一块块我能对应上的具体操作。框架只是把我手工算过的事情封装好了而已。3.2 从零到一搭分类神经网络的实操套路我的练习方法是这样的先从一个完全确定的问题出发比如“二维平面上的点分为红蓝两类”它是可视化且容易判断对错的。然后我按顺序完成以下步骤手动实现一层线性变换加激活函数实现交叉熵损失和准确率计算实现梯度下降更新参数把训练过程跑起来画出决策边界尝试加深一层观察训练曲线变化。这里有一个非常关键的操作在每一步都拿自己实现的结果和小步框架给出的结果做对照。比如你用 PyTorch 搭同一个模型看看最终精度是否接近训练若干轮后的损失曲线是否趋势一致。如果差异巨大说明实现里某个环节有问题可以倒回去检查。3.3 没有 GPU 的日子我不是放弃模型而是改变了练习负载很多零基础的人都有个误区没有显卡就没法学深度学习。实际上在入门阶段要处理的全都是小规模玩具问题训练量少得可怜CPU 完全足够。我用了好几个月免费的云端开发环境训练了各类小模型没有遇到任何瓶颈。我对这段经历最深的体会是入门阶段的核心任务是理解模型机制和训练流程而不是追求惊人的训练速度。真正需要 GPU 的场景是后面处理图像、大模型微调或大规模数据实验时。那时候你自然会有办法不论是使用云端 GPU 服务还是升级硬件网络环境和工作流都已经成熟到不需要你提前焦虑。3.4 我的练习套路和复盘方法第二阶段我保持了一个固定节奏每天至少写三十分钟的模型代码不追求跑出大项目只追求把一个小机制搞明白。比如今天只研究 Dropout 是怎么按概率把神经元置零的明天只研究 BatchNorm 在训练和推理时的差异。每个小知识点都写一段能运行的代码然后把结论记到一条“实验日志”里。长远来看这种“小块积累”比分几次熬夜突击有效得多。AI 工程涉及的知识面太广如果没有持续稳定的输入很容易前面学了后面忘。我也不建议把所有时间都放在阅读论文上那是在已经掌握基本工程能力之后才做的事情。这个阶段结束时给自己做了个小测试不看任何资料用一个周末实现一个手写数字识别模型。当年的我做到了那一刻才真正觉得“从零开始”这四个字有了分量。4. 第三阶段重点大模型时代AI 工程的重心变成了对接与评测4.1 为什么我会建议你尽早接触大模型相关 API传统机器学习流程中你要自己搞定特征工程、模型训练、部署每一步都有不低的门槛。可近年来大模型服务的出现把其中很大一块工作直接外包出去了。你不是必须从零预训练一个模型更多时候是站在已有巨人的肩膀上做好上下文管理、任务拆解、输出校验和系统集成。有人觉得这是“投机取巧”我恰恰认为这是 AI 工程能力重心的迁移。以前你的竞争力体现在“会不会训练”现在更体现在“能不能把模型的潜力挖掘出来并把坑填平”。你可以更早地接触实际业务场景而不是花几个月时间在大规模训练上。具体到实操尽早去申请一个大模型的 API 访问权限做一个最简单的对话机器人把接口调用调通。然后用同样一个模型去完成不同任务比如摘要、分类、实体提取。这时候你会很快发现决定输出质量的因素不只是模型本身还有你怎么写提示词、怎么组装输入上下文、怎么在输出层做校验和纠正。4.2 一个最小可用 RAG 知识库助手的搭建笔记RAG检索增强生成应该是目前最值得掌握的 AI 工程模式之一。它解决的问题是让模型基于你自己的文档回答问题时不产生严重虚构能给出有依据的答案。它的原理可以用一句话说清楚先在你自己的知识库中找到与问题最相关的片段再把这些片段拼进上下文交给大模型。我当时搭建最小助手的流程如下把几十份 Markdown 文档切分成文本块每块大概 500 到 1000 个字符用一个向量化模型把每个文本块变成向量存入向量数据库或直接存在内存里用户提问时把问题向量化在库里做近似检索找出最相关的 3 到 5 个文本块把检索结果和原始问题组合成提示词发送给大模型服务得到最终回答。这四步里每一步都有坑。文本分块大小会影响检索质量我当时按句子硬切结果切碎了很多完整语义后来改成按段落和标题层级切明显变好。相似度阈值也不能拍脑袋阈值太高会漏掉有效信息太低则会把大量无关内容塞进上下文反而干扰模型输出。调阈值的过程是一个非常典型的工程任务你必须准备几十个测试问题反复试。4.3 评测集、回归测试、成本控制这些细节比模型本身更影响成败我见过太多人做 AI demo 时觉得效果惊艳一上真实场景就崩。原因很一致只用几个精心挑选的测试用例做评估没有建立系统化的评测集。我的做法是为每个项目维护一个“评测问题集”把典型场景、边缘场景、反例场景都写进去。比如做一个客服问答机器人评测集里就必须包含常见问题、模糊表述、包含错别字的问法、别的问题迁移进来的干扰项。每次修改提示词或切换模型都会跑一遍这个评测集记录准确率变化。这个习惯让我避开了很多陷阱。有次我升级到一个性能更强的模型几个日常测试样例的效果明显提升我差点直接上线。结果评测集一跑发现它在某个特定领域问题上的表现反而变差了。这就是典型的“偏科”模型升级没有评测集根本发现不了。成本控制同样是 AI 工程里绕不开的议题。每次调用模型都会产生费用一个高频服务如果每次请求都塞入过长上下文成本会快速失控。你需要为每个功能设定上下文长度上限对用户输入做摘要压缩对高频相似问题建立缓存。这些工程细节看起来不起眼但在真实业务里常常决定一个项目能不能长期活下来。5. 从本地笔记本到真实服务生产环境里真正要命的问题5.1 我曾经经历过的“本地一切正常上线就出事”做个模型在 Jupyter 里跑和在线上变成一个别人可以调用的服务完全是两种难度。我上线第一个推荐接口时本地测试一切正常可部署到服务器后请求频繁超时还时不时报内存错误。排查过程让我明白笔记本环境给了太多“隐性保护”数据已经全部加载在内存里调用顺序由我手动控制依赖版本也固定在自己机器上。而线上服务必须处理并发请求、冷启动、模型加载时长、单次请求超时等一堆新问题这些都是 AI 工程的正经课题。解决思路有三条把模型加载做成进程启动时一次完成而不是每次请求加载一次对输入长度和超时时间做显式限制接口设计成无状态调用避免不同用户之间的数据互相污染。5.2 数据版本控制和可复现性不用就会出大问题我在第三个月开始感受到一个极其痛苦的时刻某天重新整理数据时不小心覆盖了最初用的那份版本结果同一个模型训练出来的效果回不到当时成果了。数据集可能包含预处理的很多细节删除哪些行、填充什么值、做了哪些编码每一步都会被记录在清洗脚本里而脚本本身也拥有不同版本。后来我养成了几个习惯原始数据一律只读任何清洗操作都在副本上完成每个实验记录下完整的数据哈希值或日期时间戳模型训练后会导出一个包含参数、指标和对应数据版本的配置文件。这些做法的本质不是追求仪式感而是为了让你在三个月后还能把实验结果原样复现出来。这在调试线上问题时几乎是救命能力。5.3 部署选项对照怎么选最省心把模型变成服务有各种不同方案我用一个简单表格记录我自己的选型对比部署方式适合场景优点我踩过的坑原生推理框架大模型、高性能要求的场景吞吐高、推理优化好对显存和工程配置要求高初期容易卡在环境安装Python Web 框架封装中小模型、快速上线灵活、易调试并发能力弱需要自己处理加载和线程问题平台托管服务想快速验证不想运维省心、弹性伸缩长期使用成本较高需要评估配额和限流离线任务批量推理非实时、分析类任务逻辑简单、失败可重试延迟高不能服务于实时交互场景如果你阶段目标只是做一个能演示的小项目完全可以从第二种方案起步。用一段简洁的代码把训练好的模型包一层接口from fastapi import FastAPI from pydantic import BaseModel import joblib app FastAPI() model joblib.load(model.pkl) class Item(BaseModel): features: list[float] app.post(/predict) def predict(item: Item): pred model.predict([item.features]) return {prediction: float(pred[0])}这样的服务虽然简单却可以完整覆盖从模型加载、参数校验到结果返回的全流程。真正的部署坑排查比如如何配置线程安全、如何处理高并发、如何监控模型漂移可以留到你有真实需求时再深入研究。6. 给三个月前的自己的六条防坑建议6.1 别把收藏文章当成学习动作我收藏过两百多篇和 AI 相关的文章真正打开回顾的不到十分之一。“收藏”会制造一种“我已经掌握了”的幻觉但知识并不会因为你收藏了它而进入大脑。建议给自己定一个规则每收藏一篇东西必须产出至少一条自己的笔记或代码。没有产出的收藏就是囤积最终只能躺在文件夹里造成焦虑。6.2 手写代码比看视频重要十倍视频的优势是让你快速了解全局它的劣势是让你误以为自己会了。我看完一个“用 PyTorch 训练图像分类器”的视频后信心满满合上电脑自己写才发现连数据加载器的逻辑都没理顺。从此我的规则很粗暴凡是看过的代码必须关上视频盲写一遍写不出来就一直看回放直到能写出来。6.3 早一点建立属于自己的评测集这个建议怎么强调都不为过。我不希望你在上线前才手忙脚乱地找测试用例。从第一个小模型开始就准备一份固定测试集每次修改都重跑一遍。你会发现它不仅能提前发现问题还会反向帮你明确项目到底要达到什么效果减少无方向的调参行为。6.4 不用等数学全部学完再动手但核心数学要逐步补上前面说别被数学劝退不是说不学数学。这里的度很关键起步阶段完全不懂可以动手写代码但写到反向传播、损失函数、梯度下降这些环节时你必须停下来搞懂背后的微积分和线性代数常识。不然你就是在盲人摸象出了问题不知道怎么排查。边做边补、用到哪补到哪是最好的节奏。6.5 先跑通一个笨方案再谈优化和炫技很多人卡在一个地方的原因是希望一开始就采用最优雅的方案。我建议你先接受一个“有点笨但能用”的方案哪怕先用规则匹配解决 80% 的需求也比花三周设计一个大而全的方案最后烂尾好。这个原则放在任何 AI 项目里都成立。系统先动起来你才知道真正的瓶颈优化才有的放矢。6.6 坚持写简单复盘哪怕只是一个小项目我后期进步最大的转折点是开始认真写项目复盘。格式根本不需要复杂就三块内容我本来想做什么实际花了多长时间、遇到什么问题下次如果再做会采取什么不同做法。这些复盘会逐渐沉淀出你自己的方法论它们比任何公开课笔记都更贴合你的实际弱点。最后一点个人体会从完全零基础走到能独立负责一个 AI 服务我最深的体会是AI 工程不是一座需要你焚香沐浴之后才敢攀登的高峰它更像一片有路标也有岔路的森林。只要方向正确哪怕走两步退一步也远比停在原地焦虑强。回头看我最大的弯路不是“学得太慢”而是“总想准备好再开始”。如果你也正站在“ai-engineering-from-scratch”这条路的起点我的建议很简单把你收藏的第一篇教程打开把你打算“周末就开始”的计划改成今晚跑通一行 pip install然后跑一个小到不能再小的模型把这次成功记下来。那一步跌跌撞撞的代码会成为你之后所有 AI 工程能力的种子。