1. 先别急着写代码AI工程和调接口完全是两回事我从去年开始带一个AI工程方向的小团队招进来的新人里十个有九个都跟我说过同一句话“我天天在用大模型会调API也会写提示词这不就是AI工程了吗”结果做真实项目不到两周全部老实了。套壳Demo很容易聊天机器人丢个对话接口进去就跑了可真要做一个内部知识库问答、一个客服工单自动分类、一个多轮对话状态管理你很快就会碰壁——上下文怎么控制、检索怎么召回、回复怎么评估、异常怎么兜底、成本怎么核算、反馈怎么回流。这些问题光会调大模型API的人根本答不上来。“ai-engineering-from-scratch”这件事我自己的判断是从零开始学AI工程重点不在“AI”而在“工程”。大模型本身是现成的真正难的是把它嵌进业务系统里还能稳定、可控、成本可接受地运转。这篇文章不聊套话按我这些年的实操经验拆清楚AI工程从零起步到底要学什么、怎么做第一个能拿得出手的项目、会遇到哪些典型的坑每一条都是我在真实项目里踩过的。适合谁来读两类人一类是传统后端、数据、测试背景想转AI应用开发的同学另一类是自己折腾过几个GPT脚本、想往专业AI工程师方向走的人。如果你已经是大厂多年做LLM底层训练的这篇文章可能帮不上你我主要聊的是业务侧AI工程也就是大多数人入行和就业真正面临的方向。2. AI工程到底在解决什么问题凭什么值得单独学2.1 它不是套壳API而是用系统思维做模型应用先给一个我自己的定义AI工程是把AI能力大模型、小模型、检索、多模态作为组件嵌入到真实业务流程中并保障其稳定性、可维护性、安全性和成本可持续性的系统工程。这个定义里最关键的两个字是“组件”。传统软件工程里你调一个数据库、调一个消息队列组件是确定的给定输入输出可预期。但大模型不是这样的组件——同一个Prompt同一个模型今天和明天的输出可能连长度都不一样。这意味着你不能用“调接口接数据库”的思维来搭建AI系统你需要设计容错边界、评估标准、回退机制。这就是为什么我说AI工程需要一套完整的学习路径而不是看几个教程就完事。很多人问我Python会用、OpenAI也会调是不是就入门了我的回答是你只完成了AI工程里最表层的那20%。剩下80%是工程问题——数据管道怎么建、系统架构怎么设计、效果怎么评估、出了问题怎么排查。这也是为什么各类招聘里“AI工程师”挂了那么久还缺人缺口不在“会用模型”而在“能带项目落地”。2.2 和传统后端开发的本质差异用一个表格说清楚会比长篇大论更直观对比维度传统后端工程AI工程核心组件数据库、缓存、消息队列大模型、提示词、向量检索、评估系统输出确定性高度确定概率性输出同样的输入结果可能不同调试方式日志断点需要评估集链路追踪多版本对比性能瓶颈数据库/网络Token上下文、检索召回率、推理延迟上线标准功能通过测试效果达到阈值成本可控边界行为可兜底这个差异直接改变了实践的底层逻辑。举个例子一个传统的接口写完了自测通过就能部署一个AI功能上线前你可能需要准备几百条测试样本、定一个准确率红线、设计好模型输出不符合预期时的兜底流程。这套东西没有任何一个后端框架会替你做但AI工程要学而且要当成必修课。3. 零基础往上垒核心技能底座到底要搭到什么程度3.1 Python、数据能力和一点统计学压舱很多教程告诉你人工智能要学一堆数学概率论扎到底、线性代数搞明白、梯度推导手写。我不反对这些但对于“从零开始”搞业务型AI工程的人我不建议一上来就陷进数学推导更合理的路径是“先用起来反哺理论”。你真正需要的最低限度的技能底座我按优先级排一下Python基础文件读写、面向对象、装饰器、async异步这是基本功。至少做到看文档能写、遇错能查的水平。数据处理三件套Pandas、Numpy、JSON操作。大量真实AI应用的落地最花时间的是清洗数据、转格式、切分文本。SQL别小看它AI项目里检索增强RAG的数据源大概率在数据库里你连表都查不明白谈何优化。一点统计学常识准确率、召回率、F1、置信区间不求推公式但求看到一个评估报告能看懂指标怎么算的为什么这个指标升了那个降了。这不是制造焦虑我是真的见过太多只学Prompt Engineering的新手一上来就调上下文窗口但我们第一步永远是写脚本处理清洗了几万条PDF文档。数据这块不扎实后面全崩。3.2 LLM基础原理不是让你推公式但你必须懂机制“工程”思维的核心是知道自己操作的组件有什么脾气。你不懂大模型的脾气就调不好它。基本要搞明白这么几件事Token模型读文本的最小单位不是按字数算是按Token算。实践中中文字大概1到2个字符一个Token英文大概4个字符一个Token。成本计算、上下文长度控制全建立在这个概念上。有次我带一个项目客户非要处理超长合同负责人一直抱怨“模型不支持超长文本”但其实问题是他没做切片和摘要直接把全文塞进去了。上下文窗口这是模型看得见的“工作记忆”。窗口有限不可能无限塞信息。工程上常见的解法是检索、摘要、分层压缩而不是无脑扩容。Embedding和向量化模型把文字变成一堆坐标向量语义相近的内容坐标距离近。这是做相似度检索、知识库匹配的地基。理解到这个层面就足够了硬要自己去手写Embedding算法完全没有必要。在大模型时代的AI工程里Prompt Engineering当然是重要技能但只停留在“写提示词让模型输出更好”是远远不够的。真正做工程时Prompt更像一个需要持续版本管理的敏感参数它和环境变量一样需要测试、沉淀、回归。3.3 把RAG检索增强生成搞成肌肉记忆RAG是业务型AI工程最简单、最常用的落地模式。核心是三个环节离线切分把知识库文档切成片段Chunk。嵌入向量把每个片段向量化存进向量数据库。在线问答用户提问后把问题向量化检索出最相关的片段再把“检索结果问题”拼进Prompt交给模型生成最终回答。这个流程看似简单我做得越久越发现里面全是调优空间切块多大重叠多少检索TopK取多少相关性阈值怎么设这些参数每一项都直接影响回答质量。RAG为什么被如此看好胜过直接训微调小模型因为业务知识是动态更新的今天客户上新政策明天公司发新制度RAG只需重新灌入新文档马上就能生效。如果靠重新训练模型成本高、周期长线下环境根本玩不转。工程上RAG就是更优的默认答案。4. 从零手写一个可落地的AI应用完整拆解一个知识库问答系统4.1 项目定位我不做Demo做一个真能上线的系统很多教程爱拿“宠物名生成器”“旅游攻略助手”当案例说实话我不推荐。我建议的第一个完整项目直接往真实场景靠——做一个内部知识库问答机器人。这个项目不挑行业对公司企业、法律、金融甚至教育都成立而且它几乎覆盖了AI工程所有核心环节。假设场景一家公司有大量制度文件、产品文档、客服标准回复散落在几十个PDF和表格里。员工想知道请假流程、报销标准、某产品参数翻文件夹翻到崩溃。我们要做的就是让员工在对话框里输入问题机器人给出答案并附上出处。4.2 系统构成与架构选择我的做法是搭一个极简但五脏俱全的结构包含五个模块数据导入模块读PDF、Word、TXT文本切分模块按结构块切分设定重叠向量化与索引模块Embedding 存储问答服务模块接受用户输入完成检索增强评估与日志模块记录每一次问答和检索结果这个架构你可能觉得简单但它是RAG最经典的生产级骨架。往大了扩展不过就是给它加权限控制、加缓存、加监控本质上流程不变。在V1阶段我建议你直接用主流成品组件不要自己写Embedding用OpenAI接口或者更便宜的国产开源Embedding模型向量库用开源工具后端用自己的FastAPI包一层。4.3 关键参数和代码级别的实操记录要用可复现的方式走一遍核心流程我用最直接的方式给你看关键步骤。文本切分时到底怎么切我的经验是按标题结构切而不是按固定长度切然后设置一个重叠区间防止语义断裂。from langchain_text_splitters import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , ], is_separator_regexFalse, ) chunks splitter.split_text(document_text)为什么chunk_size设500因为在中文语境下500个字符大约覆盖一个完整的要点或制度条目再大检索到的片段就可能混入无关信息再小又容易语义不完整。这个值是经验值你换了文档类型可能就要改但起始点先定在这里。向量化这一步也有讲究。我建议至少跑一遍两种Embedding对比效果不要无脑用同一个模型from sentence_transformers import SentenceTransformer encoder SentenceTransformer(BAAI/bge-m3) query_vec encoder.encode(请假三天需要走什么流程) doc_vecs encoder.encode(chunks)用国产开源Embedding的好处是中文适配好、免费、可商用。部署起来没坑不存在网络问题省掉一大堆麻烦。如果你要做线上部署我强烈建议先换成它。检索增强层是核心写得更清楚一点。用户问题进来之后不是直接丢给大模型而是先走检索from sentence_transformers import util scores util.dot_score(query_vec, doc_vecs).cpu().tolist()[0] top_indices sorted(range(len(scores)), keylambda i: scores[i], reverseTrue)[:4] context_parts [chunks[i] for i in top_indices] context \n\n.join(context_parts)这里TopK4同样不是随手定的。我实测过TopK太小时答案容易缺信息TopK太大时冗余信息挤占Token窗口反而拉低回答准确率。对于制度文档类内容TopK取4到6是一个比较稳妥的范围。最后拼Prompt的环节核心原则是“先给角色再给任务然后把原始参考资料贴进去最后要求引用出处”并且强制限定“资料里没有的内容就说不知道”prompt f 你是一个企业知识库问答助手。请只依据提供的参考资料回答问题。 如果参考资料中没有相关内容请直接回答资料库中无相关信息不要自行编造。 回答末尾请列出信息来源序号。 参考资料 {context} 用户问题{question} 这里最容易被忽略的是那句“不要自行编造”很多人觉得模型当然不会说谎但实测下来没有这条约束幻觉概率高到吓人尤其是知识库里查不到的时候模型会一本正经地给一个经典错误答案。这句话我建议每个RAG项目的Prompt里都强制保留。4.4 评估和反馈没有这条链路等于白做很多AI应用死在哪个环节不是开发是上线之后没人管效果。做第一个项目时就要养成习惯给每次问答留日志记录用户问题、检索到的文档、模型答案、用户是否点“有用”。然后每周做一次样本分析统计准确率把错误的案例拿出来倒推是检索没召回还是模型生成跑偏还是切块不合理。这个闭合迭代的链路是我认为真正区分“AI工程师”和“AI调用者”的分水岭。5. 工具选型LLM应用开发的工程决策实录5.1 框架工具其实没有你想的那么必要现在市面上很流行说“用LangChain/LlamaIndex”但我个人的意见稍微不一样对于刚入门做第一个项目你完全可以不用重量级编排框架就用基础Python代码串联逻辑。我们自己生产环境的早期版本很长一段时间就是纯Python写流程没有引入框架。为什么因为现成框架封装好了很多内容但出错时你完全不知道内部是怎么运转的。尤其是面对检索、拼接、调用框架版本升级换个包名你连改哪里都不知道直接卡死在工具上。那团队现在用不用这些框架用。但如果你从零起步请先把原生的控制流逻辑跑通了再去看框架帮开发省了哪些重复劳动你会瞬间明白框架存在的意义。5.2 向量存储横向对比按场景选别跟风很多分享让你直接上高级向量数据库我非常怀疑他们有没有跑过真正的知识库场景。我的对比结论是向量存储适用阶段优点缺点Chroma本地开发/小型知识库部署简单零配置生产稳定性一般FAISS纯检索场景性能好、内存索引快需自己管理持久化Milvus高并发生产环境分布式、功能全运维成本高要吃架构知识pgvector已有PostgreSQL的项目复用现有库事务一致性好大数据量检索性能需调优第一条建议别一上来就选择分布式向量库先用SQLite或Chroma跑通整套链路。等检索量真的上万了再迁移不迟。我在项目里见无数人把时间浪费在“先搭环境”这一步上结果两周过去了对应逻辑一行没写。5.3 模型选型API调用不等于必须用同一个模型做AI工程经常被问到“你用的是GPT还是DeepSeek”。事实上生产环境中你完全可以使用多个模型配合检索排序用轻量Embedding模型复杂推理问答用强模型简单分类、信息抽取用便宜小模型大文档摘要用支持长上下文的模型多模型协同是个很值得研究的方向核心逻辑是每类任务匹配一个性价比最优的模型。这不仅是为了省钱更是为了延迟可控。不要为了非核心步骤拉动一个大模型真实工程里一步接口调用的额外延迟可能直接毁掉产品体验。6. 常见问题与排查技巧实录全是你自己试过才能发现的6.1 检索效果差关键词不对还是向量不对信号症状用户问“请假流程”系统拼了命也找不到相关内容。排查步骤我通常按这个顺序走先把用户问题和库里已有文档直接用肉眼比对确定内容到底在不在库。查接口召回日志看TopK里到底召回了什么。做一个简单的AI润色把用户口语问题重写成一个更符合书面表达的问句再做检索。检查切块粒度比如“请假流程”这个标题可能被切分到不同Chunk里导致关键词分散。真实排查中最常见的坑不是向量模型差而是切块时把问题相关的信息切散了。一条制度规则可能跨了几个Chunk的边界检索时两边都不完整导致召回结果永远差一口气。解决办法是把重叠区间调大一点试用不同chunk_size对比测试准确率。6.2 大模型输出幻觉不是模型没救是你没做防御有一回同事开发一个招聘岗位解析功能模型把“要求本科学历”硬说成“要求硕士学历”气得招聘专员直接跑过来投诉。我没换模型只做了三件事Prompt里加“如果资料中未提及该字段请输出‘未知’”。后端加了一道校验要求模型强制输出JSON格式字段值做枚举校验不合法就默认“未知”。输出端再做一个相似度关联校验如果模型答案和检索片段没有重合内容直接拦截。三层防御一上幻觉率从肉眼可见的“乱编”降到可接受的极低水平。很多人以为幻觉是模型层面的无解难题但工程层面的应对手段其实很多关键在于你有没有意识去做系统性防御。6.3 链接超时和异常回调你早晚要处理真实生产环境中第三方模型接口随时可能不稳定超时、限流、返回格式错误。你需要做的不是求着它稳定而是设计兜底逻辑。我自己的兜底三板斧是调用前设置超时上限宁可失败不让整个请求无限挂起。失败后做指数退避重试最多重试2到3次。模型接口不可用时返回“系统正在维护请稍后再试”而不是给用户一个报错的裸接口。这三板斧做下来模型API挂掉的那半个小时里业务侧无感知这就是工程价值。6.4 成本失控不是不给你用是你不会省计算Token成本一定要养成习惯。我做项目喜欢做一张“每次请求成本估算表”单次问答消耗Prompt多少Token、生成多少Token再乘以模型单价。压成本的办法我也列几个实测好用的对用户历史对话做摘要而不是无限塞原文当上下文。检索回来的片段做重排序把最相关的整合到一起控制Prompt输入量。简单分类任务不用强模型用小模型先跑一遍不行再升级强模型。做缓存完全相同的用户问题在30秒内直接返回历史结果。这里我特别提醒一点不要在每一轮对话里反复把整套Company简介塞进去。我们曾有个项目固定Prompt里放了一份三千字的公司简介每个请求都要计费一个月下来光这部分多烧的钱就够买两台开发机了。把固定知识做成离线检索而不是常驻上下文这一条就足够省下一大笔费用。7. 从零开始到底要多久怎么规划你自己的路线总有人想要一个确定的时间表。根据我带人和自己踩坑的实践经验一个完全零基础、但每天能投入3小时的人按合理路线走大概3到4个月具备独立开发一个知识库问答系统的能力再花1到2个月补评估测试和性能优化就能去投AI应用开发的初级岗位了。我推荐的自学时间分配是这样的第1个月Python基础数据处理SQL。目标不是精通而是能流畅写脚本工具。第2个月LLM基础原理、Prompt工程、API调用把几个主流大模型全都调一遍做对比。第3个月RAG全流程动手做知识库问答项目完成从切分、向量化、检索到生成的闭环。第4个月评估、监控、成本调优、多模型协同把上面这些常见问题方法全部过一遍再重构一遍自己的项目。每个阶段都要留出至少30%的时间做“写代码走出来”的实战而不是只看文章和视频。看十遍别人的教程不如自己跑一次报错日志。这几个月里个人经验是用一个笔记工具把每个问题和对应解决方案记录成知识卡片最后你会收获一本比别人厚几倍的排错手册这本手册在面试里比履历上的项目名字要有说服力得多。8. 一点收尾的实践心得最后聊点更私人的体会。很多人学AI工程会焦虑觉得这个领域更新太快今天学的框架明天就过时。我自己也经历过这个阶段。做了几年之后回头看真正保值的东西反而不是某个框架、某个库而是你在反复实战里建立起来的工程直觉知道一个系统哪里会崩、知道怎么拆解一个问题、知道用什么手段防御不确定性。如果你现在恰好正处在“文档看了不少代码一行没写”的状态我的建议是找一个贴近业务的场景哪怕是帮家里人整理一份健康知识库老老实实从切文档开始跑通一遍。你只有在真实数据上被切块质量坑过一次、被幻觉回答坑过一次、被Token成本坑过一次才算是真正入了AI工程的门。文字教程给不了这种感觉只有亲手写出来的报错日志会给你留下肌肉记忆。方向是清晰的路是长的但走到“能独立解决问题”的那一天你会发现所有繁琐的迭代都变成了底气。