☰
从零开始学AI工程:先跑通项目,再补数学原理
2026/11/3 4:51:11 网站建设 项目流程

2023年我决定系统学习AI工程(ai-engineering)时,周围人给我的建议几乎整齐划一:先读《深度学习》、把Transformer论文啃透、复现一次ResNet。我照着做了三个月,挫败感直线上升——数学推导翻到第十五页就弃书了,GitHub上跑通一个高star模型,却发现离真正能用还差十万八千里。后来我换了个思路,把“from-scratch”理解成“从零开始搭一套能跑的AI系统”,而不是“从神经元网络最底层开始复现”,学习进度一下子拉了起来。这篇文章会把这条路径完整展开,写给正在纠结入门方式的人,尤其是零基础转行者、在校学生,以及想往AI方向靠拢但还没动过手的开发者。

1. 为什么我把“工程思维”当作AI入门的第一课

1.1 我见过太多人倒在“原理先行”的路上

先说我观察到的现象。身边想入行的人,几乎都经历过同一个循环:囤资源、记笔记、看课程,然后放弃。有人从吴恩达的机器学习课程开始,有人买了《动手学深度学习》,还有人买了全套花书,结果一模一样——知识和代码之间始终隔着一层窗户纸。最典型的困境是:学完了梯度下降,知道参数怎么更新,可当真实需求摆在面前,比如“做一个能自动总结公司会议纪要的工具”,大脑一片空白,完全不知道从哪下手。

这不是个别现象。我把原因归结为一句话:很多人把“理解原理”和“工程落地”这两件事搞混了。原理当然重要,但对一个初学者来说,地基挖多深,应该由你要盖多高的楼来决定。你只是想先搭一个能跑的业务系统,却非要去啃最底层的数学推导,等于把地基挖到了二十米深,而房子只盖了两层。这不是努力,这是资源错配。

1.2 “from-scratch”在AI工程里的真实含义

这里必须先澄清一个概念。很多人看到from-scratch就以为必须从零手写神经网络,在裸CPU上实现Transformer的前向和反向传播才算入门。我不否定这种做法的价值,它在面试和学术研究里确实有意义,但它绝对不该是多数人的第一步。

在AI工程这个语境下,from-scratch更合理的解读是:一个没有任何AI背景的人,从零开始,逐步搭建出一个能处理真实任务的系统。它包含API调用、数据准备、Prompt设计、模型选型、结果评估、服务部署这一整套工程动作。你不需要自己写Transformer,也可以完全不碰PyTorch底层算子,但你必须要知道怎么让一个模型输出稳定可用的结果,并且把这个结果接入到现有业务流程里。

1.3 工程思维的第一个产物:一个能跑的Hello World

我自己真正的转折点,是完成了第一个微小但完整的项目。当时我抓取了写作平台近一年的文章,调用模型API做自动分类。整个脚本只有几十行,但当我看到文章标题被自动标上“技术”“生活”“随笔”这样的分类时,第一次有了“AI真的能为我所用”的感觉。从那以后我给自己定了条规矩:每接触一个新概念,必须把它落到一个能运行的小系统里。

这条规矩真的很值钱。它能把学习从被动接收变成主动构建。你不是在“学CNN”,你是在“做一个用CNN识别猫和狗的页面”;你不是在“学RAG”,你是在“做一个回答自己PDF资料的问答机器人”。有了明确的目标物,学习动机就解决了一大半,人也就不容易半途而废。

2. 从零开始的路线图谱:先学什么、后学什么

路线问题没有一个标准答案,但有一条经过验证的路径可循。下面我把它拆成三段来讲。

2.1 Python和SQL:AI工程的基本功

Python在AI工程里绕不开,但多数人根本不需要学得很深。我建议只掌握最常用的那一小块子集:变量、列表、字典、循环、函数、类、异常处理,再加上文件读写和json库,就够了。装饰器、生成器、元类这些,等你真的遇到场景再学不迟,这绝不是入门阶段该花时间的地方。

真正被很多人低估的是SQL。进了AI工程之后你会立刻发现,现实世界的数据几乎都存在数据库里。不管是统计最近七天的用户反馈、从订单表里算客单价分布,还是构造一份训练集和验证集,SQL每天都跑不掉。我建议学完Python基础后,立刻花一周时间把SQL刷到能独立完成多表关联查询的水平。这周时间的回报远超你后来省下的所有手动处理表格的时间。

2.2 经典机器学习:值得学,但别陷入调参马拉松

接下来是经典机器学习这一大块。这块的核心价值不在于马上能做什么应用,而是建立“数据、特征、模型、评估”这套思维框架。线性回归、决策树、随机森林、逻辑回归,配合过拟合、偏差方差、交叉验证这几个核心概念,足够打下很好的底子。

但这里必须刹一下车:不要在调参上耗着。Kaggle比赛很吸引人,精确率提升0.1%很快乐,但对入门者来说,把时间砸在特征工程和参数微调上,投入产出比非常低。原因很简单——今天的深度学习和大模型已经帮你处理了大部分特征工程的工作,你的核心战场不在那里。

2.3 LLM应用开发:投入产出比最高的切入点

经典机器学习有个大概认知之后,我最推荐直接跳到LLM应用开发。为什么?因为现在的模型能力足够强,你可以用非常少的代码做出来一个有真实价值的应用,这是五年前完全不敢想的事。我见过不少学员,在完成上面两层基本功之后,不到两周就做出了基于大模型的文档问答系统——因为真正要写的代码,主要是API调用和Prompt编排。

这条线具体的学习顺序是:先学会调用主流大模型的API,再学Prompt结构化写法,然后把外部上下文塞进Prompt(也就是RAG的雏形),最后学Function Calling和工具调用。这一圈走下来,你已经能独立解决公司里很多自动化、信息抽取、文本生成类的问题了。

3. 数学与算法原理:够用就行,但“够用”的边界要划清楚

数学门槛是AI领域劝退话题里的重灾区。我给一个偏现实的回答:数学不是从零开始做AI工程的门槛,而是天花板。意思是,你完全可以先动起来,等遇到具体问题——比如“为什么学习率要这样设”“为什么生成结果总是重复”——再回头补数学,效率反而远高于先硬啃三个月教材。

3.1 一份可以执行的数学学习清单

如果你真想系统补一下,按这个顺序来就行。首先是高等数学里的函数、极限、导数、偏导数,用来看懂梯度下降到底在干什么;然后是线性代数里的矩阵乘法、向量空间、特征值,用来看懂权重和Embedding是怎么回事;再然后是概率论里的条件概率、贝叶斯公式、期望与方差,用来看懂评估指标和生成模型里的概率解释。这三块不需要啃完整本书,用到哪查到哪,配合代码实践消化,比纯看书有效得多。

3.2 数据结构与算法:比微积分更常用

我个人判断,对多数AI工程师来说,数据结构与算法比微积分更常用。设计Prompt要用到“分治”思想,把大任务拆成多个小步骤让模型依次处理;构建RAG要处理向量检索和相关性排序;优化服务性能要处理缓存、队列、并发控制。这些全是计算机基础知识的范畴,不是数学。

所以我建议的学习顺序是:先把数据结构和算法基础打牢,数组、链表、栈、队列、树、哈希表、简单的递归和动态规划。这些东西在你后面写Agent、做RAG、优化系统的时候,每天都用得到。数学则可以等需求出现时再定向补齐。

3.3 什么时候才真正需要啃论文

对绝大多数做AI应用的人来说,你不需要啃论文。原因很简单:模型的内部改进由模型厂商完成,你关注的是怎么用这个模型解决业务问题。真正需要读论文的时刻,是当你准备深研某个模型原理以便做定制优化、打算调整模型架构,或者要长期跟跑最前沿技术的时候。如果你只是要在业务里用AI,读高质量的技术博客和二手解读就够了。

这个认知能帮你省下大量时间。我见过太多人把时间花在读论文上,最后既没做成应用,对原理的理解也只停留在抽象层面。与其这样,不如先跑通一条业务线,再带着问题回头翻论文。

4. 第一个AI项目的标准动作:从API调用到完整闭环

规划再好,不动手还是等于零。我把自己第一个项目拆成几个标准动作,你可以按顺序照做。

4.1 选模型:先借用成年人,不要自己养孩子

我见过一些新人,心里憋着一股劲——“我要自己训练一个模型”。这个执念在入门阶段真的会害了你。训练一个能用的模型需要的数据量、算力和时间,远超个人开发者的承受范围。你现在看到的大多数AI应用型创业项目,都是搭在别人提供的模型之上。所以第一步很简单:注册一家主流模型提供商的账户,把API跑通,用几行代码体验一次“输入文字—输出文字”的最小闭环。这个体验本身就是最好的启动器。

4.2 一个最小可用产品的设计样本

我当时的第一个完整项目,是做一个“技术文章自动打标签”的小工具。需求来自我自己的真实痛点——博客每周要发几篇长文,发布前需要给编辑提供候选标签。整个结构异常简单:脚本批量读取文章标题和开头两段,拼接成Prompt发给模型,解析JSON结果,最后输出一个CSV。整个流程不到一百行代码,但它覆盖了AI工程的完整闭环:输入、处理、调用、解析、输出。

项目不一定多酷,关键是它真实地减轻了我的重复劳动。当这个项目对你自身有实际价值时,你的动力会完全不一样。别老想着做一个“别人也会用”的产品,先从解决你自己手边最烦人的那件事开始。

4.3 要建立一个粗糙但存在的评估集

新手最容易卡住的一个问题是:模型输出质量忽高忽低,很难判断到底行不行。我今天觉得“看起来还行”,明天换个参数又全变了,没有判断依据。我的建议是从第一个项目就养成“建评估集”的习惯——选20个固定的测试输入,之后每次改Prompt、换模型、调参数,都在同一批输入上跑一遍,看输出是否符合预期。评估集可以很粗糙,但必须存在。

有了评估集,你才能谈优化。比如同一个打标签任务,你可以测试“把标签数量限制改成3个”对准确率的影响,也可以试“在Prompt里强制输出JSON”对解析稳定性的帮助。这些对比全部依托于那一份小小的固定输入集,它给你的确定性远超你反复拍脑袋试错。

4.4 成本和延迟:两个容易被忽略的隐形指标

除了准确率,AI工程师从第一天起就要盯成本与延迟。成本很容易算:每次请求消耗多少token、月调用多少万次、费用大概是多少。延迟决定了产品体验:模型一次回答要15秒,用户大概率已经关了页面。我自己的习惯是,每个项目启动前先把这两个数字记录下来,它们会影响后续的模型选型和技术路线决策。

举个最简单的例子:做实时客服机器人时,如果模型延迟压不下来,就可以在架构里加一层缓存和检索,把高频问题提前准备好固定答案,而不是每次都让大模型从头生成一遍。这种权衡能力,恰恰是做第一个项目时要刻意培养的。

5. 进阶路线:规则系统、RAG、Agent与微调的分层推进

完成第一个MVP后,就能往更深的地方走了。我把进阶路径分成四个层次,每层的学习量和收益都不一样。

5.1 第一层:提示词工程与规则外挂

第一层是提示词工程。现在这部分技术已经被反复整理得相当结构化,要掌握的不只是“把话说明白”,而是一套系统性技巧。比如few-shot,在Prompt里给模型一两个示例再让它干活;比如CoT,引导模型先解释思路再给答案;再比如结构化输出,要求模型输出JSON并用解析器强制校验。另外一个习惯特别值得注意:能用代码预先处理的步骤,就不要丢给模型。

我拿简历解析举例。Job Title这种字段,用正则表达式抓取就行,完全不需要模型出马;只有Job Description这种语义复杂的字段才值得交给大模型。规则和模型混排,是真实系统里性价比最高的架构。很多人迷信“智能”,什么东西都想塞给模型,结果成本和稳定性双双失控。

5.2 第二层:RAG与数据准备

到第二层,我建议系统学习RAG。它的动机非常容易理解:大模型只知道训练时见过的数据,不了解你公司内部资料,也不掌握最新信息。RAG的做法是先把资料切片、向量化、存入向量数据库;用户提问时把问题向量化,在库里检索最相关的几个片段,拼进Prompt,再让模型回答。一句话总结:与其让模型记住所有内容,不如让它在需要时查到并阅读。

这个阶段要学的东西不少:文本怎么切分、Embedding模型怎么选、向量检索的相似度怎么调、检索质量怎么评估。我建议用一个小而真实的项目练手,比如把自己所有历史文章做成一个问答库。多数人在这里踩的坑是:答案不对,不是因为模型差,而是因为“根本没检索到对的内容”。数据预处理才是RAG系统里最决定成败的部分。

5.3 第三层:Agent与多工具编排

第三层是Agent。这词近年被反复炒,但我要给新人泼盆冷水:Agent不是搞一个循环把所有工具拼起来就完事。它的核心工程问题是——让模型在正确的时机使用正确的工具,并且能处理工具返回的意外结果。这需要深入理解Function Calling的机制、认真设计工具描述、还要处理错误恢复、重试、超时控制这些工程细节。否则Agent在演示场景下很酷,一碰到真实世界的多样性,立刻崩给你看。

学Agent我建议从单工具开始。先做一个能查数据库的Agent,跑通后再逐步加日历工具、邮件工具。每一步亲手摸一遍“模型决定调用什么工具、怎么传参数、拿到结果后怎么办”的完整链路,比看一百个项目Demo都有用。Agent能力的高低,往往取决于你工具描述写得多清楚,而这个功夫需要在做中学。

5.4 第四层:微调,什么情况下才值得做

最后我来说微调。我在这个环节踩过大坑,所以格外认真提醒:如果你发现Prompt写了又写、示例加了又加,模型还是做不到你要的效果,这时才值得考虑微调。微调的成本极高——要准备上千条高质量数据,要做训练、验证、测试集划分,还要防止微调后模型“忘记”原本的能力。数据质量差的话,微调不但不会改善效果,反而会加速模型退化。

大多数场景下,RAG加提示词工程已经足够。微调真正适合做两件事:一是让模型固化成某种特定输出格式,比如公司内部病历的固定总结模板;二是让模型吸收一小片专用知识并固化下来。入门阶段别急着碰微调,先把前三层稳扎稳打地走完,再根据真实的业务需求决定要不要碰它。

6. 避坑与认知:我已经替你走过的弯路

最后聊聊几个认知层面的纠偏。这些是我个人踩过的坑,如果早几年有人跟我说清楚,我至少能少浪费半年时间。

6.1 “看完再动手”是最拖延的学习状态

我观察到一个规律:永远有一批人停在“准备阶段”。等Python学完就学数学,数学学完就学框架,框架学完又回头看机器学习,每一步都有充分的理由,但始终没进入“完整做一个项目”的阶段。拖延的本质不是懒,是怕——怕自己产出的东西不够好、不够完整。但AI工程恰恰是“先完成,后完美”的手艺。我的土办法是每两周强制自己提交一个小项目,无论代码多烂,先让它跑通再说。

6.2 岗位认知:AI工程师不是“会调API”就结束了

如果你把AI方向当作职业目标,有个越早想清楚越好的认知:真实的AI工程师岗位,大量时间花在数据清理、工程对接、业务指标推动上,而不是每天研究最新模型。模型调用只是能力下限,数据敏感度、系统设计能力、业务理解才是真正的分水岭。所以学习的时候,别只顾着追新模型和热门论文,花点时间研究数据清洗、评估体系建设和系统设计,这些“不酷”的内容在职场上反而更值钱。

6.3 关于学习节奏:每天两小时,雷打不动

最后说节奏。很多人一上来就定“每天八小时”的计划,结果一周就崩。我建议把目标降下来,降到你闭着眼睛也能稳定坚持的量,比如每天两小时。第一小时做一个小练习、调通一个小脚本;第二小时复盘今天踩的坑,写几十字的记录。这个节奏听着慢,但拉长三个月看,你会跑赢绝大多数“三分钟热度”的人。我自己的大部分进度就是在这样一个低强度但高稳定性的节奏里完成的,没有靠熬夜,没有靠突击。

如果让我从这段经历里挑一个最想分享的体会,那就是:AI工程这条路,拼的不是爆发力,是持续把一个个小系统跑通、跑稳。别收藏一百个教程了,从今天开始,先跑通你的第一个脚本,它会替你打开整扇门。

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询