聊到AI工程这个话题我算是从零开始踩了不少坑也积累了一些真实可复用的经验。ai-engineering-from-scratch这句话其实道出了很多人的现状大模型火了两年多AI工程师成了热门岗位但真正从头系统学一遍的人并不多。我见过太多人停留在调API、复制提示词的阶段也有人一上来就啃论文结果被数学公式劝退。这篇文章想给两条路的人一个中间地带——既讲清楚AI工程的核心拼图大模型基础、提示工程、RAG、Agent、工作流、评估也给出可以直接照做的实操路径。如果你正准备转行或者公司里需要你来牵头做AI应用落地这篇文章应该能帮你把零散的知识串成一条清晰的线。我不会按教科书的方式讲只讲我实际做过、验证过、也踩过坑的东西。全文分四块先拆解AI工程到底在学什么、整体的学习思路怎么搭再逐个拆核心技术点说清楚每个东西解决什么问题、在什么场景下非用不可然后给你一个完整的实操案例从选型到上线一步步走最后整理我遇到的高频问题和排查方法。看完你至少能知道下一步该学什么、第一个项目做什么、遇到问题去哪找原因。1. 整体思路拆解AI工程到底在学什么1.1 先搞清楚AI工程和调API的区别很多人以为AI工程就是调大模型的API这个误解会直接导致学习路线走偏。调API是消费能力工程是构建能力。打个比方会开车的司机不叫汽车工程师AI工程是那个既懂车的运行原理、又能动手改装、还要保证车在复杂路况下稳定跑的人。具体来说AI工程的核心任务是把大模型从一个聪明的玩具变成一个可靠的生产工具。这中间涉及四件调API完全覆盖不了的事第一是上下文管理模型能接收的token有限怎么把用户的问题、背景资料、历史对话塞进去又不撑爆窗口第二是输出控制模型天生是概率生成怎么让它的输出格式稳定、内容可控第三是外部系统对接让模型能调用工具、查数据库、读写API从只会说变成会干活第四是质量保障怎么评估模型输出的好坏、怎么兜底、怎么在出问题时降级。所以我的建议是不要以学会某个开源项目为目标要以能独立交付一个AI功能为目标来安排学习。后者会倒逼你把上述四件事全部走一遍。1.2 从零开始的三个关键阶段根据我带过的新人也根据我自己走过的路我把学习路径分成三个阶段每个阶段对应一个可以拿得出手的成果物。阶段一地基期2到3周——目标是用代码调通一个大模型并且理解token、上下文窗口、temperature这些基础参数的意义。这个阶段不要追求花哨搭一个CLI对话脚本就够。关键是亲手改变参数亲眼看到输出的变化建立对模型的直觉。阶段二能力期4到6周——目标是不靠现成框架手写一个RAG检索增强生成流程和一个小型Agent。RAG解决的是模型不知道你行业的知识这个问题Agent解决的是模型无法自动执行任务这个问题。这两个是现在AI应用落地最核心的两个模式绕过它们直接学别的都是空中楼阁。阶段三工程化期持续——目标是把做出来的原型变成能上线的系统。这个阶段要关注流式输出、缓存、限流、日志、评估集、安全过滤这些东西。很多人在阶段二就停了结果原型漂亮、上线翻车恰恰是漏了这一层。我见过最快的路径是什么一个完全没有AI基础、但有Python经验的同事三个月从零做到了能独立交付一个AI客服项目。他没有追任何新模型就是把上面三个阶段老老实实走了一遍。慢的路径是什么到处收藏教程、囤了上百个提示词模板、天天刷AI资讯半年了还在调API。2. 核心技术点拆解AI工程必须拿下的五块拼图2.1 大模型基础别被参数吓住开始学AI工程时大模型这个词容易让人有距离感。其实工程视角下你不需要懂Transformer的每一个数学细节但有几个概念必须吃透否则后面全绕不开。Token是所有问题的起点。模型不是按字计费是按token计费。粗算中文场景下1个汉字大概对应1到1.5个token英文一个词往往是一个token有的词会拆成多个。这个概念重要因为它决定你的成本预算和上下文规划。我在实际项目中做过一个很典型的计算企业知识库QA平均每个用户问题200字、检索到的上下文资料1500字、系统提示词500字一轮对话大概是2200到2500个token。如果一个用户每天问20轮一个月下来按当时的API价格算单用户成本大约是几十块钱。这个数在立项时要能脱口而出才不会被老板问倒。上下文窗口是空间上限。模型能一次处理的token总量是固定的比如8K、32K、128K。超过这个数只有两条路截断或压缩。这就引出了RAG的必要性——不是所有检索到的内容都要塞进去塞进去的必须是经过筛选的、和当前问题最相关的内容。temperature和top_p是输出确定性控制。temperature控制随机性越低越保守适合分类、抽取、格式化输出越高越有创造性适合头脑风暴。top_p控制候选词的累积概率范围和temperature一起调。我的经验是生产环境里大部分任务把temperature设在0.2以下需要创意生成时才调高。很多人开箱默认用1.0发现输出飘得没法用其实就是这个参数没调。System Prompt和Function Calling是工程抓手。System Prompt是模型的人设和约束Function Calling函数调用让模型可以按结构化参数调用外部工具。这两样东西是后面Agent的地基第2.4节会展开。2.2 提示工程性价比最高的技能提示工程Prompt Engineering被讨论得很多但真正会用的人不多。我的定义是通过设计输入文本稳定地引导模型输出你想要的格式和内容。它不深奥就是一套和经验有关的方法论但有四个技巧在所有场景下都有效。第一个技巧是角色任务约束三段式。先给角色再给任务最后给约束。不要只说帮我写个文案要明确你是资深营销编辑角色根据下面产品信息写一篇公众号推文任务要求800字以内、口语化、包含一个勾起好奇心的开头和明确的行动引导约束。就这么简单的一个改动输出质量天差地别。第二个技巧是Few-shot少样本示例。这是目前最稳的提示技巧没有之一。给模型2到3个输入输出对它能极快地模仿你的格式和语气。我做结构化抽取任务时几乎没有一次是靠描述说服模型的都是直接给示例给完模型立马规矩。第三个技巧是思维链Chain of Thought, CoT。让模型一步步思考再给出答案处理推理类任务时效果显著。工程上不需要搞那些复杂的花样在提示里加一句请先逐步分析再给出最终答案很多逻辑问题就能明显改善。第四个技巧是输出格式约束。直接用必须输出JSON、不要输出其他任何内容并附一个JSON示例。注意要配套设置response_format这类结构化输出参数各家API都有双保险比单靠提示词稳得多。提示工程也有一层重要的分寸感不要试图用提示词解决一切。如果同一个问题改十版提示词还是不稳定多半是方案本身的问题——该上RAG的用RAG该用代码校验的输出用代码校验该拆步骤的就拆步骤。提示词是放大器不是万能钥匙。2.3 RAG给大模型装上外挂知识库RAGRetrieval-Augmented Generation检索增强生成是AI工程落地里最常用也最容易做半吊子的技术。它的思路一句话先基于用户问题去检索你已有的知识库把检索到的相关内容拼进提示词再让模型基于这些内容回答。为什么需要它因为大模型的训练数据里没有你公司的规章制度、你的产品文档、你客户的私有数据微调又贵又不灵活RAG是让模型知道这些知识成本最低、更新最快的方案。一个完整的RAG管线包括四步加载与切分Chunking、向量化Embedding、存储与检索Vector DB、生成Generation。每一步都有坑。切分是最容易被低估的一步。很多教程直接按固定长度切比如每500字一块。但切出来的块可能把一段完整的意思拦腰截断检索到的内容语义残缺模型答什么都像断章取义。我实际用的策略是先用段落结构来判断边界比如标题、换行、Markdown的分区再设定一个目标长度比如300到500个汉字做二次调整。遇到表格、代码块这类非连续文本单独处理不混切。向量化就是把文本变成一串数字向量。这一行的核心是选对Embedding模型。选型标准不是效果排名第一而是它对你这个领域的效果是否验证过、服务稳定性如何、单个向量维度导致的存储成本你能不能接受。理论上维度越高越精细但存储和计算成本也线性上升128维和1024维在实际效果上可能只差几个点成本却差好几倍。存储与检索这里有一个常见的认知误区很多人以为相似度检索真的能理解语义。它本质是文本形态相似度的近似对同义词、口语表达很敏感。所以工程上要在检索策略上下功夫——多路召回关键词检索与向量检索并行、重排序用RRF或专门的rerank模型、混合查询结合元数据过滤。我做的第一个RAG项目就是纯向量检索用户问报销流程匹配不到文档里的费用报销制度后来加了关键词检索做兜底才缓解。生成阶段要防止模型脱轨。模型可能不按照检索到的内容回答自己一通乱编。三条经验第一系统提示词里明确只能基于提供的资料回答资料中没有的如实说不知道第二把检索到的内容标注来源编号让答案带引用第三在代码层做合规过滤——如果检索结果和问题的相关性分数低于阈值直接走查不到分支不让模型瞎编。很多人忽视了第三条其实这是最防幻觉的杀手锏。2.4 AI Agent让模型从回答问题到完成任务如果说RAG解决的是知识问题Agent解决的是行动问题。Agent的核心不是模型本身而是思考—行动—观察的循环模型根据用户目标决定调用什么工具执行完工具看结果再根据结果决定下一步直到目标完成。这个过程业界一般叫ReAct模式。工程上实现Agent最重要的抓手就是第2.1节提到的Function Calling。模型并不真的执行代码它是输出一个结构化的调用意图——比如调用函数search_order参数order_idA10086——你用代码接管这个输出、执行真实的函数、再把结果作为新的消息喂回模型。这套模型决策程序执行的分工既安全又可控。从小到大的落地路径我认为分三级第一级最简单——带工具的单轮助手。模型负责从用户话里抽取参数你的代码负责查订单、查天气、查库存。一个函数对应一个能力函数描述写得越清楚模型选得越准。第二级——多步骤任务代理。让模型自己决定先调用A再看结果再调用B。我做过一个周报生成Agent模型先从团队管理后台拖取本周任务完成情况再汇总成要点最后按格式生成周报。整个链路四五个工具调用模型自己编排完成。第三级——多Agent协作。多个Agent各司其职比如一个负责拆解问题、一个负责检索资料、一个负责审查答案。这个模式适合复杂任务但工程复杂度也最高——Agent之间的消息格式、任务白板、终止条件都得自己设计。我的建议是不要为了多Agent而多Agent单Agent能解决单Agent解决加Agent意味着加故障点。我见过不少项目把多Agent吹得上天实际跑起来错误率翻倍、token费用翻三倍最后又改回单Agent加流程控制。无论哪一级你都要建立代码兜底思维。Agent的强项是灵活性弱项是确定性。关键动作一定要有程序层面的确认调用支付接口前必须二次确认金额和收款方删除操作前必须让用户输入确认删除四个字这些不能只靠模型的自觉。2.5 工具链与工作流从手搓代码到组装流水线学AI工程绕不开工具链我的建议是先用代码理解原理再用工具提升效率。很多人一上来就用低代码平台结果平台封了或者满足不了需求代码又不会写直接卡死。反过来如果你手写过一个RAG管线再用那些可视化工具会发现里面每一步你都知道在干什么配置起来毫无障碍。当前主流的方向是工作流引擎多家大厂和创业公司都在做。工作流的核心是把提示词调用、知识库检索、代码运行、条件分支、人工审批这些节点用可视化画布连接成一条自动化流水线。它的价值不是让你不写代码而是让非技术人员也能参与流程设计比如运营同学自己调整话术产品同学自己改判断条件。这在我实际项目里特别省事——AI功能上线后的迭代频率很高每次都等开发改代码开发会疯运营会骂。编程辅助工具也要提一句。现在主流的AI编程助手包括IDE自带插件和独立产品已经在日常开发中帮了我大忙。写样板代码、生成单元测试、解释看不懂的代码片段这些场景下它们非常靠谱。但我的原则是你至少要能读懂它生成的每一行代码。把AI当高级自动补全是可行的把AI当外包员工是会翻车的——它生成的代码有概率是错的没有审查能力就只能被它带沟里。2.6 评估与测试AI工程最容易被跳过的一环传统软件有明确的预期输出测试就好写AI应用是概率输出同一个输入每次结果都可能不一样所以评估是AI工程里最反直觉、也最容易被偷工减料的一环。但没有评估你的系统就是一个失控的黑盒。我现在的做法是三层评估第一层指标评估。对客观任务定义若干自动指标在线下评估集上跑。比如回答准确率、抽取字段的精确率和召回率、分类任务的F1等。这一步必须有它给你一个量化的基线。第二层回归测试。准备50到100条典型的用户问题作为回归集。每次改动提示词、切换模型、调整检索参数之后都用这组问题跑一遍人工或半自动地看有没有这次修好A问题、结果搞坏了B问题。没有这个回归集你就是在雾里开车。第三层A/B对比。两个方案实在分不出高下时把流量随机分一部分给新方案在线上用真实用户的实际行为点击率、采纳率、投诉率来判断。这是最终裁决。除了这三层日志和追踪必须从第一天就做好。用户问题、检索到的上下文片段、模型原始输出、最终答案、消耗的token全部落日志。AI应用的排查比如用户反馈回答不对你没有日志就只能猜有日志就能精确看到是检索环节失效还是模型生成环节跑偏。很多生产事故的定位时间可以因为一手好日志从小时级降到分钟级。3. 实操过程从零构建一个可用的AI问答助手3.1 项目选型和功能定义我建议你的第一个项目不要选聊天机器人——太泛了评价标准模糊做完了自己都不知道成功没有。选一个边界清晰、有明确知识来源、结果容易判断的场景。我带新人最常用的练手项目是《企业内部规章制度问答助手》知识来源是一堆HR制度文档用户问年假怎么休出差报销标准是什么系统从文档里检索并回答还要标注出处。这个项目功能明确、数据好获取、成败一眼可见能把RAG全流程走一遍。功能定义阶段先写清楚三件事输入用户会怎么问收集20到30个真实或模拟的问题注意口语化表达不要只写标准问法。输出期望的回答形态是什么一段话带编号的步骤是否必须附来源引用边界哪些问题不该回答文档范围之外的问题怎么回应这些写清楚后面评估集直接就有雏形了。3.2 环境准备与模型选型工具上我用的是Python生态最全文档最多。基础依赖就三个库OpenAI兼容的官方SDK、一个Embedding接口、以及向量数据库起步阶段直接用轻量级的不建议一上来上分布式重引擎。模型选型上给不同预算阶段三个层次的选择首次练手用各家大模型服务商的免费额度或最低配模型即可。目的是跑通流程不是刷分。预算有限的生产用中等尺寸模型做主要任务Embedding模型选性价比款。预算充足且有专业需求在关键链路上用能力最强的模型次要链路可以降级。选型有一个实用原则核心决策路径用好模型非核心冗余通路用便宜模型。比如用户意图识别可以交给小模型但最终的答案生成必须用大模型。我第一次做项目时全程用大模型上完线发现80%的token花在了不值得的地方优化后成本直接砍掉一半。3.3 核心代码实现与参数选择下面是我反复验证过的一个最小RAG问答骨架刻意去掉了复杂配置只保留核心逻辑方便你理解每行在干什么。from openai import OpenAI import json client OpenAI() # 这里指向你用的推理服务配置好API Key和环境变量 # 1. 切分按段落切分一段企业制度文档 def split_document(text: str, max_chunk_size: int 400) - list[str]: paragraphs [p.strip() for p in text.split(\n\n) if p.strip()] chunks [] current for para in paragraphs: if len(current) len(para) max_chunk_size: current current \n\n para else: if current: chunks.append(current) current para if current: chunks.append(current) return chunks # 2. 入库调用Embedding接口把切块向量化 def build_index(chunks: list[str], collection): for i, chunk in enumerate(chunks): resp client.embeddings.create(modelyour-embedding-model, inputchunk) vector resp.data[0].embedding collection.add(ids[str(i)], embeddings[vector], documents[chunk]) print(f已入库 {len(chunks)} 个文本块) # 3. 检索取用户问题的向量在库里找最相似的几个块 def retrieve(query: str, collection, top_k: int 3) - list[str]: resp client.embeddings.create(modelyour-embedding-model, inputquery) query_vector resp.data[0].embedding results collection.query(query_embeddings[query_vector], n_resultstop_k) return results[documents][0] # 每个结果建议连索引号和来源一起保存 # 4. 生成把检索结果、用户问题、系统约束拼在一起让模型作答 def generate_answer(query: str, retrieved_chunks: list[str]) - str: context \n\n---\n\n.join(retrieved_chunks) messages [ {role: system, content: 你是一名企业制度问答助手。只能根据提供的资料回答资料中没有的信息要如实说明不要编造。回答末尾标注信息来源。}, {role: user, content: f资料\n{context}\n\n问题{query}} ] resp client.chat.completions.create( modelyour-chat-model, messagesmessages, temperature0.2, # 生产环境压低保证稳定 max_tokens800 ) return resp.choices[0].message.content # 串联起来 if __name__ __main__: docs [企业年假制度入职满一年可享受5天年假……, 差旅报销标准……] collection create_vector_collection() # 初始化向量库 for doc in docs: build_index(split_document(doc), collection) while True: q input(请输入问题) if q.lower() in (exit, quit): break chunks retrieve(q, collection) print(generate_answer(q, chunks))这段代码有三个参数值得专门说明top_k检索返回的块数取3到5是常见起点少了信息不够答不全多了塞进上下文既浪费token又可能引入噪声max_chunk_size切块目标长度我通常取300到500个汉字太小了块内信息量不足太大了容易混入不相关内容temperature设0.2是稳定输出和自然表达之间的平衡点。3.4 调优迭代与上线前检查原型跑通之后真正的工程工作才开始。我的调优顺序是先检索后生成如果检索到的块与问题不相干再怎么调提示词都白搭如果检索靠谱但答案质量差才轮到调生成侧。调优过程中最有用的工具就是第2.6节说的评估集。我建了一个20条的迷你评估集每次改动都跑一遍用三档打分好、中、差记录结果。有一次我调了切分策略在20条里好答案从12条涨到15条我以为成功了但仔细看发现其中3条涉及过期制度的问答全变了好跑偏——评分表掩盖了那个角落的问题。所以建议评分时按问题的类别分组统计别只盯总分。上线前的检查清单我这些年反复用分享给你用户输入有长度上限吗没有的话恶意超长输入会让token爆炸。有脏话和敏感内容的过滤吗大模型服务商基本都有内容审核接口要接到链路上。有兜底分支吗检索分数低于阈值时怎么回应用户日志里有没有记录检索块和模型原始输出这决定你事后能不能排查。并发量评估过吗按峰值流量测算API调用频率别上线被扛不住打回来。隐私边界确认过吗用户输入的内容会不会进入模型服务商的训练数据要开启相应的数据保护选项或走私有化部署。4. 常见问题与排查技巧实录4.1 模型输出不稳定、时好时坏这是被问到最多的一个问题。我的排查顺序是先看temperature是不是过高生产环境建议0到0.3再看是否缺少Few-shot示例纯靠描述约束的输出必然飘再看上下文里是否塞了不相关的内容噪声输入会带偏生成最后再看任务本身的定义是否清晰写个介绍和用三句话向新用户介绍产品核心优势、每句不超过30字这两种任务的可控性完全不在一个量级。走完这四步绝大多数不稳定都能解决。4.2 回答幻觉严重一本正经地胡说八道幻觉问题的根治手段不在提示词在架构。我前面提到的相关性阈值兜底是最有效的一招检索结果与问题的相似度分数低于某个阈值时不进入生成环节直接回复知识库中没有找到相关信息。另一个有效手段是要求答案带引用来源模型在需要标注出处的压力下会明显更克制。比如提示词强调每个关键结论后面的引用编号必须在提供的资料中找到对应依据否则删除这个结论——实测下来幻觉大幅减少。4.3 Token消耗高、成本失控成本问题最容易被忽略等账单出来才慌。三个实用做法第一缓存。完全相同的用户问题可以直接命中答案缓存很多问答场景的重复率远比你想象的高第二压缩上下文。系统提示词反复精简检索结果只保留最相关的前两三条去掉每次都带的废话模板第三模型分层。简单的意图识别、文本分类用便宜的小模型只有复杂生成才用大模型。我那个周报Agent优化前单次任务消耗约1.2万token优化后降到约4000效果几乎没有变化。4.4 上下文越来越长、对话越聊越慢多轮对话场景历史消息全塞进去窗口迟早被撑爆。常见解决方案是滑动窗口只保留最近的N轮对话作为记忆更进一步是摘要记忆把早于窗口的历史对话压缩成一段摘要放在新对话前面更精细的方案是关键信息抽取从历史对话中抽取用户常驻信息比如用户是采购部的张经理上次问过办公用品报销每次只带这些浓缩信息。这个优化很多项目上线后才会痛到。4.5 检索不到相关内容用户问报销流程库里有费用报销制度可就是检索不到。我的排查清单确认Embedding模型对口语化查询的适配度必要时换模型或加同义词扩展检查切分策略是否把关键信息切碎或切错边界确认检索的Top K数量3条不够就加到5条最后一定记得做混合检索BM25这类传统关键词检索对精确匹配非常有效和向量检索结合能补上很多漏洞。4.6 可用性速查表我把高频问题的排查顺序汇总成一张表你也可以把它当作自己的排障手册症状首要排查项常见解法回答不稳定temperature过高降到0.2加Few-shot示例一本正经编造缺乏检索兜底相关性阈值判断无结果不生成上下文撑爆历史消息全量携带滑动窗口、摘要记忆检索不准单一向量检索混合检索、重排序、调Top K成本超标全链路使用大模型模型分层、缓存、压缩上下文答案逻辑混乱任务没有拆解提示词里引导逐步分析或拆成多步流程上线后出错难查日志缺失全链路日志保留检索块和模型原始输出5. 后续可以拓展的方向如果上面的内容你都能消化接下来有几条路可以根据兴趣选。一是往更深的模型能力走。学会用微调处理提示词搞不定的场景比如让模型学习特定文风、特定领域术语。注意微调不能替代RAG它学的是行为和风格知识更新还是要靠检索。二是往更复杂的工程架构走。异步任务队列、流式输出、多租户隔离、灰度发布……这些传统后端工程的东西放到AI应用里会让你从能跑进步到能扛。三是往多模态方向走。图片输入、语音交互、视频理解这些领域的大模型能力还在快速迭代但底层思路和文本场景一模一样上下文管理、提示设计、检索增强、评估体系全都能复用。四是往评估与质量体系走。会做AI功能的人多了能把AI功能的好坏度量清楚、持续跟踪的人还很缺。把这个方向做深你在团队里的位置会非常稳。我自己走这条路时最大的体会是AI工程的门槛不在数学、不在资源在于你能不能把模型的黑盒和工程的确定性之间的冲突处理好。模型会飘你的代码就要稳模型会错你的架构就要能兜。这种和不确定性共处的能力没有捷径只能靠一轮轮做项目磨出来。如果你刚开始别犹豫现在就找一个边界清晰的小问题按这篇文章的路径动手做。做完第一个项目你会发现后面其实都是水到渠成。