过去大半年我一直在做AI方向的技术评审和团队带教简历上写着“熟练掌握AI应用开发”的候选人见过不少可一上机深聊大部分人的真实水平其实停留在“调API、写Prompt、跑通一个Demo”这个阶段。我不是说这不对——所有从零开始的人都得先过这一关。但如果你想把自己从“会用AI的人”升级成“AI工程师”中间还隔着一整段路这段路的名字叫工程化。这篇文章就是写给打算认真走这条路的人的。我不给你列一堆课程链接也不堆概念名词只讲我实际带人、踩坑、复盘后沉淀下来的东西从怎么理解大模型到Prompt工程怎么做才算合格再到RAG、Agent这些词背后真正的工程含义最后落到测试、评估和一条能照抄的12周路线图。适合两类人看一是刚入门、想系统建立AI工程知识体系的开发者二是已经在写业务代码、但想把AI能力真正集成进产品里的后端或全栈工程师。1. 先搞清楚AI工程不是“会用AI”也不是“啃论文”很多人一听到“从零开始学AI工程”第一反应是去买深度学习的课从反向传播、Transformer结构开始啃。我的建议恰恰相反如果你目标是用AI解决业务问题而不是去大模型实验室做研究那你不需要先把数学推倒一遍。那AI工程到底是什么我把它拆成三层。模型层大模型本身包括怎么选模型、怎么买API、怎么部署开源模型。这一层你只需要懂“怎么用”不需要懂“怎么训”。应用层Prompt工程、RAG、工具调用、Agent编排。这是AI工程师的主战场也是本文重点。工程层评估体系、链路稳定性、成本控制、迭代流程。这一层最容易被忽略但恰恰决定了你从“做Demo”到“上线生产”之间能不能跨过去。我见过不少团队的惨痛教训花两周时间用LangChain搭了一个看起来很酷的聊天机器人结果一到真实用户场景就崩——要么答非所问要么同一个问题两次回答完全不一样要么上下文一长就出错。问题不在模型而在他们压根没建立“工程化”的思维。工程化和写Demo的区别在哪写Demo关心的是“能不能跑通”工程化关心的是“能不能一直跑通”。具体来说工程化意味着四件事可评估每次改动都有量化指标、可回滚出问题能快速定位、可维护代码结构清晰、Prompt能版本管理、可降级模型服务挂了系统还能给用户一个体面的错误。带着这四条标准去学你会发现自己对“会AI”的定义会完全不一样。所以这篇文章的路线是先建立对大模型的正确直觉然后依次攻克Prompt工程、RAG与Agent、工程化落地、测试评估最后给你一条踩着我踩过的坑铺出来的学习路径。2. 基础层像认识一个新同事一样认识大模型我第一次接触大模型API时也犯过新手病上来就传一段很长的对话然后发现返回结果越来越差还以为是模型变笨了。后来才想明白——模型不是数据库它是一个没有记忆的“每次重新读题”的同事。你要想用好它得先理解它工作的几个基本参数和概念这些是后面一切的基石。2.1 Token、上下文窗口和“翻旧账”的代价模型处理文本的单位是Token不是字数。一个中文汉字大约对应1到2个Token一篇800字的文章可能就是1000多个Token。这件事的直接后果是你的所有输入包括历史对话、系统设定、检索到的资料都会被计入上下文窗口超出上限最古老的内容就会被“遗忘”。不同模型窗口大小差异很大有4K、8K的入门款也有128K、200K的长上下文款。但我的经验是窗口大不等于可以无脑塞东西。一方面长上下文会让单次请求变慢、变贵另一方面模型对埋在超长文本中部的信息注意力其实会衰减。所以AI工程的一个基本功课就是想尽一切办法让每次请求的内容“短而精”。该用的放前面不该用的别进来。这个思路在后面的RAG里会反复体现。2.2 Temperature不是调得越高越“聪明”新手经常会把Temperature调得很高幻想模型能“更有创造力”。这是个普遍误解。Temperature控制的是输出概率分布的随机性值越低模型越倾向于选概率最高的词输出越稳定、越“保守”值越高越容易选冷门词输出越多样但胡说八道的概率也同步上升。我的经验值是做客服、问答、信息抽取这类任务设0.1到0.3做文案改写、头脑风暴设0.7到0.9。绝对不要把Temperature当“聪明程度”来调那不是它干的事。顺带说一句如果你希望系统行为可复现除了把Temperature压低还可以固定seed参数部分API支持并且用system消息把所有规则写清楚。我实际测下来即便这样也不能保证100%一致所以测试环节不能依赖“结果必须完全一样”而是要做语义级的匹配判断这一点在第六节展开。2.3 Embedding让文本变成可以计算的数字如果说大模型是一个“会说话的同事”那Embedding就是把文本变成坐标位置的能力。它的核心思想是把一句话或一段文字转换成一串浮点数向量语义相近的文本在向量空间里距离也近。这句话翻译成人话就是你可以用“计算距离”来代替“全文搜索”。比如用户问“怎么退款”系统里有“退货流程说明”和“账户注销方法”向量检索会把前者排前面因为它语义上更接近“退款”。这是后面RAG的地基你现在只需要理解一个概念Embedding模型和对话模型往往是两个东西别混用。常见的Embedding服务有OpenAI的text-embedding系列、智谱的embedding-3、阿里的text-embedding-v3等国内模型也都有对应版本。选型时关注两个指标维度数决定存储开销和MTEB基准分数决定语义效果。2.4 第一段能跑通的生产级代码说了这么多概念动手才是硬道理。我建议你的第一个练习不是写Prompt而是写一个“带错误处理的最小调用函数”。我用Python举个例子import time from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlhttps://your-endpoint/v1, # 换成你的服务商地址 ) def call_llm(system_prompt: str, user_content: str, temperature: float 0.2): for attempt in range(3): try: resp client.chat.completions.create( modelyour-model-name, messages[ {role: system, content: system_prompt}, {role: user, content: user_content}, ], temperaturetemperature, timeout30, ) return resp.choices[0].message.content except Exception as e: print(fattempt {attempt 1} failed: {e}) time.sleep(2 ** attempt) # 指数退避重试 raise RuntimeError(LLM call failed after 3 attempts)这段代码里有三个工程细节值得注意重试机制因为模型服务经常有偶发超时、超时控制防止请求卡死、System和User消息分离这是Prompt工程的基础操作。等你跑通它基础层就算过关了可以进入真正的Prompt工程学习。3. Prompt EngineeringAI工程师的第一份“可交付物”很多人觉得Prompt工程就是“把话问清楚”太低估它了。我面试时常用的一个题是“请设计一个系统Prompt让模型扮演一个只会输出JSON的客服信息抽取助手。”能答好这道题的人通常已经理解Prompt工程的核心不是“写话术”而是给模型建立一套可执行的约束协议。3.1 三条消息的角色分工一次标准调用里有三类消息很多人只会用user和assistant来回倒system基本没用。system消息定义模型的身份、任务边界、输出格式、行为准则。它应该只写规则不写具体对话内容。user消息当前这次请求的具体输入可以理解为“待办事项”。assistant消息历史回复主要作用是给模型提供对话上下文或者做few-shot示例。我的习惯是把所有规则全部写进systemuser只放本次要处理的数据。这样后续维护时你只需要改一处也方便对Prompt做版本管理。3.2 一个能让输出“稳定”的System Prompt模板经过大量项目磨合我沉淀了一个好用的信息抽取类System Prompt模板结构是这样的你是[角色定义]负责[任务描述]。 【输入格式】 用户会提供原始文本内容。 【输出要求】 1. 只输出JSON对象不要输出任何解释性文字。 2. JSON结构必须严格遵循以下Schema { intent: string, // 用户意图从[退款,咨询,投诉,其他]中选 entities: [], // 实体列表格式为{name: 实体名, type: 类型} sentiment: string // 情感倾向从[正面,中性,负面]中选 } 3. 如果信息缺失字段填null不要编造。 4. 所有枚举值必须严格取给定列表中的值。 【禁止行为】 - 禁止输出Markdown代码块包裹的JSON。 - 禁止在JSON外添加任何内容。这个模板的关键在于“把约束变成协议”明确允许什么、禁止什么、缺失怎么办。比“请你帮我提取一下意图和实体注意要输出JSON”这样一句模糊指令靠谱太多。3.3 Few-shot让“说教”变成“示范”System Prompt再长也属于“抽象规则”。有些任务规则很难描述清楚这时候就得用few-shot示范。比如你想让模型把一篇技术文章改写成“小红书面风格”与其写十条文风要求不如直接给两个例子user: 原文RAG系统通过检索增强生成显著提高了回答的准确性和时效性。 assistant: 姐妹们RAG真的绝了回答准到离谱还特别及时我真的会谢 user: 原文该模型支持128K上下文窗口。 assistant: 谁懂啊128K上下文长文档直接一口气读完效率拉满模型对例子的模仿能力远强于对抽象指令的遵循能力这是我在实际项目中反复验证过的。原理也好理解Transformer的注意力机制会把“示例中的输入输出映射关系”当作隐形规则来泛化。3.4 什么时候你该意识到“Prompt工程到头了”这是我最想强调的一点。Prompt工程有天花板当你发现以下迹象时就该往RAG和Agent方向走了。为了让模型记住某些事实你把几千字的背景资料写进Prompt结果发现又贵又慢你要求模型“根据内部知识回答”结果它开始一本正经地编造你需要模型执行“检索资料→查数据库→调用接口”这种多步操作但用Prompt描述得再清楚模型也做不利索。第一类问题的解药是RAG第二类是函数调用第三类是Agent编排。我们一个个说。4. 真正的分水岭RAG、工具调用与Agent循环如果你只学会调API和写Prompt你本质上还是在跟模型“单轮对话”。但真实业务里用户需要的是系统能回答“我今天订单到哪了”“帮我对比这两款产品的参数”这种必须结合实时数据的问题。这时你就得迈过第二个台阶让模型学会使用外部工具。4.1 RAG给模型配一个“可检索的记忆库”RAG检索增强生成的思想非常朴素模型不知道的事你先查好资料喂给它它基于资料回答。一个最小可用RAG链路包含四步文档切块、向量化入库、检索召回、拼接生成。我把一个我在生产环境验证过的简化流程写一下# 步骤1文档切块注意重叠窗口 def chunk_text(text, size500, overlap50): chunks [] for i in range(0, len(text) - overlap, size - overlap): chunks.append(text[i:i size]) return chunks # 步骤2向量化并入库以Chroma为例 import chromadb chroma_client chromadb.Client() collection chroma_client.get_or_create_collection(knowledge_base) def index_document(file_id, text): chunks chunk_text(text) embeddings embedding_model.encode(chunks).tolist() collection.add( ids[f{file_id}-{i} for i in range(len(chunks))], documentschunks, embeddingsembeddings, metadatas[{file_id: file_id} for _ in chunks], ) # 步骤3检索并拼进Prompt def retrieve(query, top_k3): q_emb embedding_model.encode([query]).tolist() results collection.query(query_embeddingsq_emb, n_resultstop_k) return \n.join(results[documents][0]) def rag_answer(question): context retrieve(question) return call_llm( system_prompt你是一个知识库助手只能基于提供的资料回答资料里没有的信息就说不知道。, user_contentf资料\n{context}\n\n问题{question}, )这段代码里最容易被新手忽略的是“切块策略”。切得太小语义不完整切得太大检索命中率下降。我的经验值是中文场景按500字左右切块、带50字重叠比较稳。切块时尽量按段落和章节边界切别硬生生把一个句子劈成两半。另一个关键点是“资料里没有的信息就说不知道”这句系统指令它直接降低了模型“拿着资料瞎编”的概率。真实项目里我还会加一步“检索相关性判断”如果召回的片段和问题根本不相关宁可让系统直接说“没有找到相关信息”也不要硬答。4.2 Function Calling让模型学会“调接口”RAG解决的是“读资料”Function Calling解决的是“做动作”。它的原理是你向模型声明一批工具模型在回答时如果判断需要调用某个工具会返回一个结构化的函数调用请求而不是直接给出最终文本。你的代码负责真正执行这个函数再把结果回传给模型让它继续生成。下面是一个最小示例tools [ { type: function, function: { name: query_order_status, description: 查询用户的订单物流状态, parameters: { type: object, properties: { order_id: {type: string, description: 订单编号} }, required: [order_id] } } } ] messages [ {role: system, content: 你是订单助手。查询订单状态时必须调用工具。}, {role: user, content: 帮我看看订单20250101到哪了} ] resp client.chat.completions.create( modelyour-model-name, messagesmessages, toolstools, tool_choiceauto, ) # 模型可能返回 tool_calls需要你执行后把结果回传 if resp.choices[0].message.tool_calls: tool_call resp.choices[0].message.tool_calls[0] result query_order_status(order_id20250101) messages.append(resp.choices[0].message) messages.append({ role: tool, content: result, tool_call_id: tool_call.id, }) final_resp client.chat.completions.create(modelyour-model-name, messagesmessages) print(final_resp.choices[0].message.content)这个示例看着简单但很多人第一次写会踩两个坑一是忘了把模型返回的tool_calls消息追加进对话历史导致第二次请求时上下文断裂二是工具的真实执行结果没做异常处理传了个报错文本回去模型就会开始胡言乱语。我的习惯是工具函数内部先做try/except返回给模型时要么给干净的结构化结果要么给“查询失败”的明确状态。4.3 Agent从“单次调用”到“循环决策”当你同时拥有“读资料”和“调工具”的能力把它们串成一个循环就得到了Agent。它的本质不是某个神秘框架而是一个很朴素的循环模型判断下一步做什么 → 执行动作检索/调API/算结果 → 把结果反馈给模型 → 模型再判断……直到它认为任务已经完成。我在第一阶段项目里写过一个极简Agent循环骨架是这样的def run_agent(goal, max_steps5): messages [{role: system, content: 你是一个任务代理可以调用工具。每步只输出一个动作。}] messages.append({role: user, content: goal}) for _ in range(max_steps): resp client.chat.completions.create(modelyour-model-name, messagesmessages, toolstools) msg resp.choices[0].message if msg.tool_calls: messages.append(msg) for tool_call in msg.tool_calls: result execute_tool(tool_call) messages.append({ role: tool, content: result, tool_call_id: tool_call.id, }) else: return msg.content # 模型认为任务完成 return 达到最大步数任务未完成这个骨架虽然简单但它揭示了Agent工程的三个关键控制点最大步数限制防止模型陷入无限循环、上下文管理每步都在追加消息很快会撑爆窗口、失败兜底到步数上限时怎么收场。真实生产里前两个问题几乎必然会遇到。我见过最夸张的一次测试Agent为了一句“继续”在错误循环里转了20多轮烧掉了几万个Token。所以我对Agent的建议是克制能用Prompt加RAG解决的任务不要硬上Agent。Agent引入的复杂度是几何级上升的——你开始要处理循环终止、步骤回滚、子任务拆分、成本控制等问题。只有当任务确实需要多步决策时才动手做Agent编排。5. 工程落地框架选型、向量库与本地部署当你把RAG、Function Calling这些能力写完下一步就是怎么让它像正经软件一样跑起来。这一节我聊三个绕不开的选型问题。5.1 框架Spring AI、LangChain还是自己写选框架前先想清楚一个问题你的技术栈和团队维护能力是什么。Java/Spring全家桶团队优先考虑Spring AI。它模仿了Spring Data、Spring Integration的抽象风格把ChatClient、EmbeddingModel、DocumentRetriever这些概念对象化Java程序员上手几乎没有学习成本。Python团队且项目偏研究探索可以考虑LangChain或LlamaIndex。但要清醒LangChain的抽象层级很多出问题时排查链很长。我团队曾经因为LangChain内部某个版本升级导致DocumentLoader行为变化整整排查了两天。核心链路我更推荐自己封装。AI应用的本质是“少量Prompt工程 大量业务胶水代码”胶水代码根本不需要框架。我的做法是用框架做初期原型验证一旦方向确认核心链路立刻用自己写的薄封装替换。这个习惯让我少踩了非常多的版本升级和黑盒问题。5.2 向量库从Chroma到Milvus向量库选型和数据量强相关。个人项目、几千条知识用Chroma或LanceDB开箱即用。生产环境、百万级向量用Milvus或Qdrant。如果企业已经有Elasticsearch也可以考虑它的向量检索能力但要注意ES的向量性能和数据量强相关别指望一台小机器扛住千万级检索。选型还有两个容易忽略的指标持久化能力和混合检索能力。很多向量库光存向量不支持对metadata比如文档来源、时间、权限做过滤这会直接影响检索精度。我建议优先选支持“向量检索 标量过滤”组合查询的库因为生产环境里“只要某个渠道的知识”“只要最近三个月的数据”这类过滤条件太常见了。5.3 本地部署不是必须但要懂原理很多人一上来就想本地部署Llama 3或Qwen我理解的动机无非是数据敏感和成本控制。但本地部署是有代价的硬件门槛、运维成本、模型效果打折。我给你的决策建议是先在云API上把业务链路跑通再用数据脱敏方案处理敏感信息最后才考虑局部私有化。如果确实要本地部署从Ollama开始体验一把它是目前对新手最友好的本地推理工具一条命令就能拉起模型。ollama run qwen2.5:7b跑起来之后你会迅速遇到两个问题并发能力极低和显存占用巨大。此时再考虑上vLLM这类推理框架做批量推理和PagedAttention显存优化。但说实话如果没有GPU运维人才我不建议非专业团队在初期自建推理服务——把精力花在应用层ROI高得多。6. 评估与测试让AI系统从“感觉能用”到“确实能用”这一节我要说一句可能得罪人的话我见过的AI项目十个里有七个死在“没有评估体系”上。团队凭感觉改Prompt改完觉得“好像好了一点”上线后用户反馈却更差了。为什么会这样因为大模型输出有随机性没有量化指标你根本分不清改善是真实的还是运气。6.1 先建一个“黄金测试集”评估的第一步是攒一批覆盖典型场景的测试样例。这个集合不求大但必须有代表性。我的做法是拿三个月真实用户问题按意图归纳出50到100条再人工写好“标准答案”或“必须包含的关键点”。这些测试样例进代码仓库后任何Prompt改动都要跑一遍全集对比前后输出差异。这是AI工程和“写脚本调接口”的分水岭之一。6.2 两个层级的量化评估评估要分两层来看。第一层是“字面质量”回答是否完整、格式是否符合要求、是否包含关键实体。这些可以用规则自动判断。我常用正则检查JSON格式是否可解析、是否包含必填字段准确率能到100%因为它是纯规则。第二层是“语义质量”回答是否准确、是否忠于资料、是否答非所问。这必须用模型来评也就是所谓的LLM-as-Judge。做法是写一个评测Prompt让一个强模型通常用比生成模型更强或同级的模型对输出打分重点看三个维度正确性、忠实度是否基于给定资料、完整性。judge_prompt 你是一个严格的评测员。请根据以下标准为AI的回答打分0-10分。 【评分维度】 1. 正确性回答是否准确无事实错误 2. 忠实度回答是否严格基于给定资料没有编造 3. 完整性是否覆盖问题所有方面 【待评内容】 资料{context} 问题{question} AI回答{answer} 请输出JSON{correctness: 分数, faithfulness: 分数, completeness: 分数} 别嫌这个方案粗糙它已经能帮你挡住九成以上的回归问题。我团队每次发版前跑一遍黄金测试集靠它抓出过不少“Prompt改了之后某类问题开始瞎编”的隐蔽问题。6.3 可观测性每个请求都要能“翻案”线上问题迟早会来问题是你能不能快速定位。我给自己的项目定的规矩是每个AI请求都要记录四样东西——输入的完整消息、输出内容、Token消耗、延迟。如果当时判断质量不行把这三件套调出来十分钟内就能定位是Prompt的问题、检索的问题还是模型本身的问题。成本观测也在这一环。Token消耗不是小数目线上系统跑起来之后我见过有人一个月API账单烧掉小一万块钱。开通服务商的用量看板给每个功能模块打上标签这事尽早做越晚越难追。7. 一条可以照抄的12周自学路线图最后我把前面的内容压缩成一条可执行的路线图。这是我带过几批从零基础学员后反复调整过的版本节奏和项目安排都是实测过靠谱的。第1-2周把API当成玩具玩透目标不是学完所有功能而是完成三个小任务跑通一次对话补全尝试调整Temperature观察输出变化用System Prompt实现一个“只输出JSON的标准回复格式”写一个带重试和超时处理的调用函数。这个阶段就一个指标你随手写一个调用函数的代码不看文档也写得出来。第3-4周Prompt工程系统化用你自己的手工测试集练习写System Prompt、做few-shot、设计输出约束。每改一次Prompt记录它对测试集的通过率变化。这四周结束你应该能独立设计出一个“结构化输出协议”并且能解释每个约束条款的作用。第5-6周完成第一个RAG项目挑一个你熟悉的领域比如你自己的博客文章、公司产品文档做一个知识库问答机器人。重点练习文档切块、向量检索、上下文拼接三个环节并主动制造干扰项测试检索质量。第7-8周实现工具调用和简单Agent给上面的问答机器人加上“查天气”“算数学题”这类外部工具能力。不用追求复杂重点是把“模型决定调工具 → 执行 → 回传结果 → 生成最终回答”这个循环跑熟。第9-10周搭评估体系为你前八周做的东西建立黄金测试集写评测脚本量化评估效果。然后做一个“回归实验”故意改坏一个Prompt验证评估体系能不能抓出它。抓不出来就说明你的评测粒度还不够细。第11-12周做一个端到端产品这最后两周的目标是把前面所有能力整合成一个能给别人用的产品。我的建议是做一个“个人知识库助手”上传自己的资料支持问答、支持调用工具、有基本评估和日志。这个项目做完你的简历上就真正有一行“AI工程”相关的内容了而不是一句空泛的“熟悉Prompt工程”。整个过程走下来你会发现自己的视角已经变了不再关心“这个模型多聪明”而是关心“我这个系统在真实场景下能不能稳定交付结果”。这个视角的转变就是“从零开始学AI工程”这条路真正到站的那一天。