企业官网建设流程全解析

很多人问我，AI工程这条路从零开始到底怎么走。我自己折腾下来的答案是：别急着报课，先搞清楚你要成为的"AI工程师"究竟是干什么的。我见过太多人兴致勃勃买了上千块的课程，学完三个月连一个能跑的端到端项目都拿不出来；也见过数学系出身的朋友，算法理论背得滚瓜烂熟，到写生产级推理服务时却不知道从哪下手。ai-engineering-from-scratch这件事，难点从来不在某一个环节，而在整条链——从问题定义、数据准备、模型选型，到评估、部署、监控，每一环都得能接住才算真的入了门。

这篇东西不是课程大纲，也不是求职攻略。它是我从零开始做AI工程的真实路径复盘：哪些基础绕不开、哪些热门技术其实可以缓一缓、一个端到端项目应该怎么拆、新手最容易在哪几个坑里反复横跳。如果你正准备进入这个方向，或者已经在路上了但总觉得学得很散、很虚，那这篇文章应该能帮你把整个地图拼出来。

1. 先搞清楚"AI工程师"到底在做什么

很多人对AI工程师的想象是"训练模型的人"，或者是"写论文调参数的算法大牛"。但真实岗位里，AI工程师的日常跟你想象的差别很大。我当年入行第一年，真正花在"训练模型"上的时间可能不到三成，剩下七成都耗在数据清洗、接口对接、排查线上推理异常、跟业务方对齐需求这些琐碎但致命的事情上。

1.1 这个岗位不是"调包侠"，也不是纯算法研究员

先做一个定位：AI工程师站在算法研究员和软件工程师之间的位置上。研究员关心的是"这个新方法能不能work"，软件工程师关心的是"这个服务能不能稳定跑一年"，而AI工程师要把两者缝合起来——既要懂模型和数据的脾气，又要懂工程约束，让整个系统在真实环境里可运行、可维护、可迭代。

有个特别反直觉的点：这个岗位对"造轮子"的要求极低，但对"拆轮子"的要求极高。你很少需要从零实现一个Transformer或者手写反向传播，大多时候你是站在开源模型和框架的肩膀上工作。但你经常需要做这些事：把别人的模型代码调通、把格式乱七八糟的数据归拢成训练/评测集、在显存不够的时候想办法节省内存、把推理延迟从2秒压到200毫秒。这些活拼的不是数学天赋，而是工程判断力。

1.2 实际工作里最常见的三类AI工程任务

我以自己的经验为样本，把日常任务粗分成三类，你可以对照一下自己正处在哪一类：

第一类是"套壳落地"型。业务方说"我要一个能自动总结客户反馈的功能"，你评估后选用一个现成的模型API，做提示词、做前置数据处理、做后置结果校验、做成本控制，然后上线。这类任务占新手期的大头，难点在于把非结构化需求和工程约束揉在一起。

第二类是"微调优化"型。通用模型在某些专业场景下表现不够好，你需要收集领域数据、做微调（Fine-tuning）、用评估集验证效果提升、再灰度上线。这类任务考的是数据质量和评测设计，不是模型架构本身。

第三类是"系统设计"型。比如做一个知识库问答系统，你要决定检索用什么、排序怎么算、生成怎么接、多轮对话状态怎么管理、失败兜底怎么处理。这已经到了架构层面，需要你对整个AI技术栈有全局观。

想清楚这个分工之后，你就能理解为什么我总劝新手不要把时间全砸在啃论文上——工程场景里"能用"压过"先进"，稳定压倒性能增益。这不是说理论不重要，而是说理论要为工程服务，顺序别搞反了。

2. 从零起步：哪些基础真的绕不开

这一节写给完全零基础的读者。我见过不少人的学习路线是线性推进的：先刷半年数学，再刷半年Python，再学一个月Pandas……然后就没有然后了，因为根本坚持不到建模就已经劝退了。正确做法我认为是"最小必要基础"+"立刻动手"的组合，缺哪块补哪块，而不是把前置知识全部囤完再开工。

2.1 数学要学到什么程度才够用

先说结论：入门阶段，微积分、线代、概率统计三块的高等数学课内容，够用到你把第一个端到端项目跑通。你不需要证明收敛性，不需要推导泛化界，但你需要做到三件事：能看懂损失函数和梯度下降在做什么；能理解矩阵乘法的维度为什么对得上；能看懂准确率、精确率、召回率、AUC这些指标的含义和适用场景。

我自己的经历是，当年线性代数几乎忘光了，靠《3Blue1Brown》的线代本质系列配着实战补回来的。真到日常工作中，90%的数学需求其实集中在"看懂文档和论文里公式说的是什么"。比如你看一份LoRA的代码，里面那句low_rank_matrix = base_matrix + A @ B，如果你知道@是矩阵乘法、知道A和B的低秩形状带来的参数节省，就已经足够理解它在做什么了。更深的推导，用到再查，效率反而高。

2.2 编程基础该打到哪里

AI工程的默认语言是Python，但"会Python"和"能干活"之间有一条不大不小的鸿沟。我建议零基础的朋友按这个顺序练：先把Python语法、函数、类、列表推导式过一遍；然后贴着一个真实数据源练Pandas和NumPy，这一步是为了建立"数据操作手感"；接着学HTTP请求和JSON处理，因为你迟早要调用别人写的服务；最后花时间搞懂虚拟环境（conda或venv）和依赖管理，这个后面单独说，因为它坑了无数新手。

有个我特别想强调的点：不要一头扎进面向对象设计和设计模式里面去。AI工程里的代码大多是脚本形态和胶水逻辑，你把"读别人代码、改别人代码、把代码块拼起来"这三件事练熟，比写出优雅的抽象更有用。我见过太多新手代码写得跟教科书一样工整，结果功能跑不起来；反而那些"丑但能跑"的脚本，在团队里更能顶事——当然，能跑之后还是建议学一点工程规范，但那是后话。

2.3 机器学习入门路线的取舍

这里我想说点反主流的话：传统机器学习（sklearn那一套）和深度学习（PyTorch那一套）都很重要，但对AI工程来说，优先级取决于你的目标场景。

如果目标是做NLP和LLM应用，我建议把sklearn的常用模型、交叉验证、特征工程基本概念快速过一遍，然后在PyTorch上花更多功夫：张量操作、DataLoader、模型定义、训练循环、保存加载。这些是理解后面微调工作的物理基础。如果目标是做传统预测类项目（风控、推荐、运维异常检测），那sklearn和树模型（XGBoost/LightGBM）的优先级更高，深度学习反而是加分项。

一个实用的建议：找一份带完整代码的经典任务（比如MNIST手写识别或Kaggle上的Titanic），自己从头到尾复现一遍，不要看答案，卡住了再看。这个过程能一次性逼出你漏掉的所有环节——数据划分、归一化、训练验证、指标评估、结果可视化。很多后来你觉得"理所当然"的工程习惯，都是这一遍练出来的。

3. 当前AI工程的核心技术栈：选型思路

到了这个阶段，你已经具备基本盘了，接下来是技术栈选型。我注意到这两年有个趋势是大家一股脑扑向LLM，把之前的经典ML完全丢下，结果碰到一些并不适合大模型的问题时抓瞎。选型这件事，本质是"用最合适的工具解决真实约束下的问题"，而不是"什么新潮用什么"。

3.1 经典ML和LLM的权重怎么分配

做一个简单的分场景对照表，你一看就明白：

我的建议是两条腿走路：把树模型工具练熟（XGBoost/LightGBM各跑通一个项目），同时把LLM调用的基本路径跑通（API、开源模型部署、提示词工程）。这两者不矛盾，很多真实系统是两者混用的：经典模型做召回和粗排，LLM做理解和生成。

3.2 调API和本地部署模型怎么选

新手最容易纠结的一个问题是：到底直接用API，还是自己部署开源模型？我见过不少人一上来就非要本地部署一个7B或13B模型，折腾两天显存问题终于搞定了，结果生成质量还不如调API。选型要看得失，我总结几个参考因素：

第一看数据隐私。客户数据不能出内网，那本地部署没得商量。第二看成本结构。API按token收费，如果你每天处理百万级请求，单次调用哪怕便宜，累计也吓人；本地部署吃硬件成本，但一次性投入后边际成本低。第三看定制空间。API能调的旋钮很有限，微调更是想都别想；本地模型你能微调、能改采样参数、能上量化，折腾空间大。第四看工程质量要求。本地部署给你完整的trace能力，好排查问题；API的排障则要依赖服务商的日志。

我给新手的实操建议是：第一、第二个项目一律用API，先把业务链路和评估体系跑通，别在部署上卡进度。等确认方案可行、量也上来了，再评估要不要自己部署一个更小的量化模型来降成本。这个顺序能帮你少走很多弯路。

3.3 RAG、Agent和微调，先学哪个

这可能是当下被问得最多的问题。我的排序是：先学RAG（检索增强生成），再做Agent，最后才考虑微调，而且很多场景里微调可以不学。

为什么RAG优先？因为它解决的是"大模型不懂你业务私域数据"这个最高频的问题，而且工程链路清晰——文档解析、切块、向量化、检索、重排、生成。这个链路你能独立搭建一遍，几乎等于把数据工程和LLM应用的最核心一环吃透了。Agent是RAG之上的能力放大：多轮推理、工具调用、任务拆解。它很炫，但工程复杂度也高，新手容易陷在"让Agent稳定不乱跑"的泥潭里。微调则是在RAG和提示词都优化到位、还是达不到要求时才动用的终极大招。它成本高、周期长，而且评估做不好的话你根本说不清微调到底带来了什么。

一句话总结：2025年前后这个时间点上，最稀缺的能力不是训练大模型，而是"让已有模型在具体业务里稳定发挥"。RAG-评估-提示词优化，这套组合拳打好了，你已经能解决大量真实问题了。

4. 一个端到端项目的完整拆解：从需求到上线

说了一堆理论，下面用一个我实际做过的知识库问答项目做案例，把这套东西串起来。我尽量保留当时的踩坑过程，因为我知道很多教程都是把成功路径讲得干干净净，反而误导了新手。

4.1 选题：从一个真实痛点出发

当时的需求很简单：一个企业内部有多份操作手册，客服每天要翻几十个文档回答重复问题，想做一个"能自动回答操作类问题"的助手。这就是一个典型RAG场景。

我特别想强调选题的原则：不要为了练技术而编需求，一定要找一个你自己能接触到数据、也能接触到真实反馈的场景。哪怕规模小也没关系，真实反馈才是最贵的训练材料。我当时找了三份真实的PDF手册，大概两百多页，还让客服同事列了二十个高频问题作为种子问题集。这二十个问题后来就是评估集的雏形。

项目拆解成五个子任务：文档解析与清洗、文本切块与向量化、检索与重排、生成与引用、评估与兜底。每个子任务单独出可验收的中间产物，千万不要想着一步到位搭完所有模块再测试。

4.2 数据与评估：最容易糊弄也最致命的环节

这一步是整个项目里我花了最多时间、也最后悔前期没做好的部分。

先说文档解析和切块。第一批数据是PDF，我直接用了原生的PDF解析库抽取文本，结果发现表格全乱、页眉页脚混进正文、代码块碎得不成样子。这个问题的解法是老老实实针对文档类型做定制：表格用专门的方式转成Markdown，页眉页脚靠规则去掉，长文档按标题层级和段落语义做切块，而不是死板地按固定字数截断。切块大小我后来调了好几轮：512字左右配合50字重叠在检索效果上比较稳定，具体数字要根据文档结构调。

更关键的是评估设计。我一开始只是凭感觉看答得"像不像样"，后来发现这种方式完全不可靠——同一个问题换一种问法，系统就答得不知所云了。正确的做法是提前建一个二十到五十条的问题-参考答案评估集，每轮改动之后都用同一套评估集跑一遍，分别看检索命中情况和生成质量。检索侧可以看"前k个结果里有没有包含正确答案"，生成侧我做的是分维度打分：事实准确性、完整性、是否引用了正确来源。没有这套评估，后面的每一步优化都是在盲人摸象。

4.3 落地上线的工程细节

评估效果满意了不代表能上线，工程细节才是"能跑"和"能用"的分水岭。

第一个细节是引用来源。这个功能看起来不起眼，但对企业场景几乎等同于刚需——用户需要核对答案出处，业务方需要追责链路。我实现了从生成内容反查原文片段，并在回答末尾带上文档号和页码。第二个细节是拒绝机制。系统必须能在"检索结果不足以回答问题"的时候直接说"我无法回答"，而不是硬编一句，这是很多RAG系统最让人诟病的地方。第三个细节是性能。检索用向量库能做到几十毫秒，生成是大头，我通过限制最大输出长度、用流式输出先把前置内容展示出来，体感上快了很多。

第四个细节是监控。我把每一条线上问题的检索耗时、生成耗时、检索命中得分、以及用户是否点击"不满意"都记了下来。这套监控数据后来帮我发现了两个隐藏问题：一是某个业务文档被频繁检索但生成的引用不是那里，说明切块有问题；二是某个时间段回答质量明显下降，查了半天发现是文档源更新后向量索引没重建。没有监控，这些问题大概率要被用户骂了才发现。

5. 新手最容易踩的五个坑：实战排雷

这个章节算是我自己掏心窝子的总结。很多坑不是技术多难，而是"你根本不知道这里有坑"。我按踩坑频率排了序，后面几条几乎每个项目中都会出现，早看到早省事。

5.1 把训练/推理代码写得不工程化

很多新手第一次跑通模型后，代码就是一个几百行的脚本，所有配置写死在文件里，换一个数据集就得改源代码，加一个模型参数就要动逻辑。这个问题的本质是没把配置和数据、逻辑分开。哪怕是小项目，也要养成三个习惯：参数走配置文件或命令行、数据路径不硬编码、随机种子固定住。这三个习惯的成本极低，收益却是几何级的——尤其是随机种子，不固定的话你连"改动到底有没有效果"都判断不了。

5.2 只调提示词，不设计评估体系

这是我见过最普遍的低效努力。很多人拿着几个case翻来覆去调提示词，调完感觉棒极了，一上线上看看全翻车。原因是你在过拟合那几个case，而不是在优化整体效果。破解方法前面已经讲了：建评估集、定指标、量化对比。提示词工程的正确姿势是批量跑评估集，看统计结果而不是看个例感受。我当时就有个深刻的教训：某个"效果很好"的提示词版本在20个测试集上平均分反而跌了5%，因为我潜意识里在挑那些适合新写法的case去看。

5.3 忽视成本和延迟这两个隐形围墙

AI工程的预算约束比传统软件工程更硬。模型推理要花钱花算力，效果每提升一个点可能意味着延迟翻倍。新手很容易只顾效果，上线前才发现成本扛不住。我给的建议是：预估链路时把成本建模当作一个必须交付的工件。定一个预算上限（比如单次回答不超过一分钱），再反过来倒推模型大小、缓存策略、要不要用更便宜的模型做粗筛。延迟也一样，把P95延迟当作指标而不是平均值——平均延迟好看，但线上抖动发生在尾部。

5.4 环境与依赖管理混乱

这个坑太常见了。今天跑通了一个项目，下个月复现不了了，原因十有八九是环境变了。AI项目尤其严重，因为PyTorch/CUDA/各种包之间的版本兼容性极其拧巴。我的经验是坚决用环境隔离：每个项目一个虚拟环境，requirements或conda环境描述文件必须入库，关键时候再把容器化（Docker）用起来。还有一条：GPU相关的依赖，版本一定要精确到小版本号，比如CUDA 11.8和12.1在某些场景下就不是一回事。你自己踩一次"昨天还能跑今天跑不了"，就知道这个坑有多疼了。

5.5 什么都想自己造

如果说前面是"不会造"，这个坑是"非要造"。有些朋友一上来就想自己实现一个RAG框架、自己写个模型加载服务，我理解那种想彻底掌握底层的心情，但在工程效率上这是近乎愚蠢的选择。成熟的开源工具（向量库、编排框架、推理服务）已经帮你处理了无数边界情况——断电恢复、并发控制、元数据管理——这些你花三个月自己写都未必写得好。正确的姿势是先用成熟方案跑通，再在具体的薄弱环节上自己动手优化。自己造的轮子，只有在你已经理解它解决的问题之后才值得造。

6. 从"会做"到"能交付"：我的进阶路线体会

最后一个章节，讲点更虚但是更重要的东西。技术能力到了一定程度之后，继续拉开差距的往往不再是代码本身，而是你"交付"的方式和"判断"的水平。

6.1 用作品集而不是证书来证明自己

我面试人的时候从来不看证书，只看一个东西：你亲手做的项目里，遇到问题是怎么分析和解决的。所以我的建议很直接：早点开始维护自己的项目作品集，不求大、但求完整。每一个项目都要能回答三个问题：业务/场景是什么？我用了什么方案，为什么是这个方案？最后的效果怎么衡量？这三个问题能答清，基本上就能证明你有独立的工程能力。

作品集还有一个隐藏价值：它就是你最好的面试素材。哪怕项目规模不大，只要链路完整、评估清晰、踩坑复盘到位，比背一百道八股文有用得多。我当时靠一个"企业内部文档助手"的复盘拿到了第一个AI工程方向的offer，那个项目的代码本身很简朴，但复盘文档里写清楚了我怎么发现问题、怎么设计评估、怎么一步步优化。

6.2 持续学习的信息源与节奏

这个领域的变化速度堪称离谱，如果不主动管理信息输入，很容易陷入两种极端：一种是什么新东西都追，一天不看推文就焦虑；另一种是彻底封闭，守着两三年前的技术栈不动。我的做法是分三层：第一层是官方文档和release notes，凡是实际用到的工具，就给自己的知识库做更新；第二层是高质量论文和技术博客，每周固定时间读几篇，重点不在于读完，而在于"这个技术如果我要用，我需要知道什么"；第三层是社群和讨论区，看别人踩坑的帖子，很多实战经验就藏在评论区的抬杠里。

我自己的节奏是：手头项目用什么，就深挖什么；新东西出来，先花十分钟读概览，判断跟自己的方向有没有关系。有关系就排进学习计划，没关系先让子弹飞一会儿。这个筛选能力本身也是经验的一部分。

6.3 关于AI工程学习节奏的几点个人体会

最后分享几条我反复体会到的原则，不指望你立刻理解，但希望你在遇到对应场景时能想起来。

第一条：评估优先于优化。任何改动之前，先想清楚"我拿什么判断这次改动是有效的"。这条贯穿我所有项目，怎么强调都不过分。

第二条：先把链路拉通，再追求局部最优。很多新手喜欢把某一步做到极致（比如调提示词调到完美），但整体系统可能根本不平衡。正确的节奏是先把端到端链路跑通，有一个可以吐槽的粗糙版本，然后再根据评估找到最值得优化的那个环节。

第三条：给未来的自己留退路。所有代码、文档、数据版本，假设一个月后的你会忘掉一切，因此写清楚README、记录好复现步骤、把环境锁死。这听起来不酷，但业界最值钱的能力之一就是"让你的成果可以被别人、被未来的你稳定复现"。

我自己回头看这段从零到能独立交付AI工程项目的路程，最大的感受是：这个领域没有速成，但确实有路径。核心不是去追每一个新名词，而是把"数据进——答案出"这条链路的每个环节都用实践摸一遍，然后在真实问题里反复迭代评估、成本、可靠性这三件事。把这些基本功打扎实了，不管未来模型怎么换代、工具怎么更替，你都能快速接住——因为你掌握的是一套稳定的工程思维方式，而不是某个版本的API用法。