最近有朋友问我说想从零开始做AI工程但网上的教程要么是纯调API的“helloworld”要么是直接甩一堆论文看不懂。我自己在这条路上踩过不少坑从最开始只会调ChatGPT接口到后来能本地部署模型、做Agent工作流、把杂活自动化处理前后折腾了大半年。这篇就把我总结的AI engineering的完整思路、实操步骤和坑位记录写下来希望能帮准备入坑或刚入坑的人少走弯路。先说清楚一个事情AI engineeringAI工程不是让你去训练大模型也不是帮你搞清楚Transformer背后的数学原理。它更偏向“如何把AI能力稳定、可靠、低成本地集成到真实系统里”包括模型选型、数据准备、Prompt设计、Agent编排、接口封装、性能优化、评估和部署。说白了就是让AI从“能跑demo”变成“能在生产环境干活”。这个方向非常适合有软件开发基础、但没系统学过机器学习的同学切入因为大部分工作不需要写模型代码而是拼装、调试和治理AI组件。我后面的内容会覆盖从环境准备到核心环节拆解再到一个完整的本地问答助手案例最后梳理常见坑位和工程化要点。内容偏实践所有代码和命令都是我自己跑过的。就算你完全没碰过AI工程只要会一点Python和Git也有机会跟着做出来。1. 内容整体设计与思路拆解1.1 先搞清AI工程的边界不只是“写几行调用代码”很多人以为AI工程就是把OpenAI的API包一下加个密钥返回结果就完事了。真这么简单的话那些AI应用就不会频繁出现回答乱七八糟、费用失控、接口一挂就全瘫的问题了。AI工程的核心矛盾在于模型是非确定性的而工程要求确定性。你没法保证同一个Prompt每次都返回一模一样的答案没法保证模型不胡说八道也没法保证外部API永远稳定。所以工程上要做的事情就是用流程、约束、校验、缓存、回退机制把不可控的模型行为“框”在可控的业务逻辑里。我见过不少团队把AI功能直接写死在业务代码里出了质量问题只能靠加Prompt硬调。这就是典型的“demo思维”带进生产环境。真正的AI工程会分成几个层次模型层选择用什么模型托管在哪用什么版本。能力层把模型能力封装成工具比如文本生成、意图识别、结构化抽取、向量检索。编排层用工作流把多个工具和模型调用来完成复杂任务比如“先判断用户意图再决定调用哪套工具”。接入层对外提供稳定的API接口或交互界面处理鉴权、限流、日志。可观测层记录每一次模型调用的输入输出、延迟、成本方便后续评估和调优。这个分层思路跟传统后端的分层架构很像只是把“数据库操作”换成了“模型调用”。理解这一点你就知道AI工程并没有那么神秘它本质上是“软件工程模型外壳”。1.2 为什么从零开始时建议先做本地部署刚开始学AI工程我强烈建议你先把模型跑在本地而不是一上来就花钱调云端API。原因有几个第一本地部署能让你直观看到模型的加载过程、资源占用和推理瓶颈这种感知对后续做性能优化太重要了第二本地推理没有网络延迟和费用压力你可以无限次地测Prompt、调参数不用心疼钱包第三云端API是一层黑盒出了奇怪问题你根本不知道是网络、服务端还是模型本身的原因本地环境一切都可控。热词里经常看到“本地部署AI”其实就是把自己选定的开源模型用推理框架跑起来然后通过HTTP接口调用。对一个学习者来说这个过程的收获远超“用一个SDK”那么轻飘飘。我自己的路线是从Ollama开始Windows/Mac都能用装完就能拉模型逐步过渡到vLLM这类高性能推理框架。Ollama虽然性能不是最好的但胜在零门槛非常适合上手。还有一个容易被忽略的点本地部署让你有机会接触到模型文件本身。比如你能看到GGUF量化格式是怎么把几十GB的模型压到几GB的能理解为什么量化后的模型回答质量会略有下降。这些认知在云端API时代根本不会遇到但对工程选型很有帮助。毕竟你要负责的系统可能要在有限算力下跑出可以接受的效果。2. 核心细节解析与实操要点2.1 模型选型背后的真实逻辑别只盯着参数数量选模型的时候大多数人第一反应是看参数量70B一定比7B强。这个说法在算力充足时基本成立但工程上要综合考虑硬件条件、延迟要求和任务复杂度。我自己常用的选型逻辑是这样的场景推荐模型显存要求说明本地问答、代码生成Qwen2.5-7B-Instruct8GB左右量化后中文能力强社区生态好轻量任务、意图分类Llama-3.2-3B4GB左右响应快适合做Agent的“小脑”高质量长文本总结Qwen2.5-14B16GB左右准确率明显提升但速度下降极端资源受限Phi-3-mini4GB以下微软出品网上评价不错这里要提醒一个容易踩的坑别只看跑不跑得动还要考虑上下文长度。比如你的业务经常要处理几千字的长文档7B模型只有4K上下文那就得做分段处理或RAG这属于架构层面的妥协不是换模型就能解决的。另外注意“指令跟随能力”和“知识储备”是两回事。有些小模型知识量不够但指令跟随很好适合做流程控制有些大模型知识丰富但系统提示词稍微复杂就犯迷糊。工程上要做的是“给不同的任务选不同的模型”而不是一个模型打天下。我做过一个项目用1.5B的小模型做意图识别用7B模型做内容生成整体效果和延迟都远好于拿一个大模型包办所有事情。2.2 Prompt Engineering的本质把需求变成指令再把指令变成协议Prompt Engineering提示工程在百度热词里出现频率很高。很多人觉得它无非是“把话说清楚一点”但工程意义上的Prompt远不止如此。工程化的Prompt是一份“协议”它要保证模型在千变万化的输入下输出格式稳定、内容边界清晰。我自己的Prompt模板通常包含五部分角色设定告诉模型它是什么限定它的知识范围和行为准则。任务描述用一句话说明要做什么避免歧义。约束条件列出禁止事项比如“不要编造数据”“只基于给定材料回答”“如果不知道就说不知道”。输出格式必须给出明确的结构化模板比如JSON或Markdown表格方便程序解析。输入数据把待处理的内容放在明确的标记块中比如使用input标签包裹。这里分享一个实操技巧构建Prompt时先用自然语言写好草稿然后逐步增加“限定词”和“示例”。尤其重要的是“少样本示例”给模型一两个输入输出对它就能学会你期望的格式。别指望模型猜出你想要什么格式你不给示例它就自由发挥。我也建议大家把Prompt当成代码来管理存到单独的文件或配置中心里而不是散落在业务代码里。改Prompt就是改代码要留痕、要版本管理、要评审。很多线上事故就是对Prompt改了没测就上线。2.3 AI Agent的工程实现思路工具调用和状态管理现在到处都在聊AI Agent但很多人把它想得太玄。工程视角下Agent就是一个不断循环的“推理-行动-观察”流程模型分析当前状态决定调用哪个工具拿到工具结果后再次推理直到完成目标。核心组件只有三个模型、工具集、循环控制。工具调用Function Calling是Agent的骨架。主流做法是给模型声明一组JSON结构的“工具描述”模型根据自己的理解返回一个JSON对象指定要调用哪个工具和参数然后你的程序去执行这个工具把结果塞回对话上下文模型再继续推理。我早期在实现这个功能时犯过一个错把工具结果直接拼在历史消息里结果模型越聊越乱。后来发现要给工具结果加上清晰的标记比如tool_result标签并明确告诉模型“这是你已经执行的工具结果不是用户说的话”。Agent的状态管理是另一个容易翻车的地方。无状态地调用模型会丢失中间推理过程全量把历史传给模型又会导致上下文爆掉。工程上的常见做法是用固定长度的滑动窗口保留最近几轮对话把重要的中间结果抽取成“记忆摘要”必要时再恢复。如果你做的Agent涉及多步工具调用我强烈建议画一张状态流转表出来把每一步的输入、输出、错误处理都写清楚。别让Agent自由发挥去处理异常你要提前定义好重试、放弃和降级策略。3. 实操过程与核心环节实现3.1 本地部署AI模型Ollama从装到跑我用的环境是Windows 11显卡是RTX 408016GB显存。如果你的显卡显存小于8GB可以把模型换成更小的量化版本。下面是完整步骤。第一步安装Ollama。直接去官网下载安装包装完在终端里验证ollama --version第二步拉取模型并运行。我选的是Qwen2.5-7B-Instruct因为它对中文支持好指令理解能力强适合后面做问答。ollama run qwen2.5:7b-instruct等待下载完成后你会发现进入了交互式对话框。在终端里输入一句话模型就有反应了。这一步就说明本地模型已经跑起来了。如果你不想进入交互模式想通过API调用它Ollama默认会在11434端口启动服务。可以另开一个终端用curl测试curl http://localhost:11434/api/generate -d {\model\:\qwen2.5:7b-instruct\,\prompt\:\你好\}这里有个细节值得注意Ollama会把模型常驻内存如果你同时加载了多个模型显存不够时它会自动卸载。你可以在命令里添加OLLAMA_KEEP_ALIVE0关掉常驻也可以设置环境变量调整并发处理数量。我建议学习阶段就用默认设置先跑通再说。第三步测试流式输出。这个对做聊天机器人很重要因为人类等待3秒就会焦虑流式输出能显著提升体验。Ollama的API支持stream: false默认是true。你在Python里只要用requests库配合streamTrue就能一点一点接收文本。记得自己在本地部署时第一次加载模型会非常慢因为需要把权重读入显存。之后再做推理就快了。如果你发现“每次调用都很慢”看看是不是内存被其他程序占用了。3.2 用FastAPI封装模型服务模型已经能通过HTTP访问了但Ollama的接口格式偏底层直接给业务用不够方便。这一步我们来写一个FastAPI服务把模型调用封装成业务友好的接口。创建一个项目目录装依赖mkdir my-ai-service cd my-ai-service python -m venv venv source venv/bin/activate # Windows下用 venv\Scripts\activate pip install fastapi uvicorn requests pydantic新建main.py先写一个最基本的问答接口import asyncio import httpx from fastapi import FastAPI from pydantic import BaseModel app FastAPI() OLLAMA_URL http://localhost:11434/api/generate class AskRequest(BaseModel): question: str system_prompt: str async def call_ollama(prompt: str, system_prompt: str): payload { model: qwen2.5:7b-instruct, prompt: prompt, system: system_prompt, stream: False, options: { temperature: 0.7, max_tokens: 2048 } } async with httpx.AsyncClient(timeout120) as client: resp await client.post(OLLAMA_URL, jsonpayload) resp.raise_for_status() data resp.json() return data.get(response, ) app.post(/ask) async def ask(req: AskRequest): answer await call_ollama(req.question, req.system_prompt) return {answer: answer} if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)几个工程细节解释一下为什么用async因为模型调用是长耗时操作同步调用会阻塞整个服务导致并发能力下降。为什么设置timeout1207B模型在无GPU的机器上生成几百字可能要几十秒默认5秒超时一定不够。temperature参数的用意是控制随机性做创意写作可以调到0.9做信息抽取建议调到0.2以下越低越稳定。system_prompt允许用户传入系统提示词但要注意并把它设计成接口参数以后可以动态切换角色。写完启动服务python main.py然后新开终端测试curl -X POST http://localhost:8000/ask -H Content-Type: application/json -d {\question\:\什么是AI工程\}返回的JSON里就是模型生成的答案。到这里你的本地AI服务就完成了第一版它已经可以集成到任何业务里了。3.3 提示词工作流实操结构化抽取与多步调用光做问答还不够我们来看一个更接近实战的场景从用户评论里抽取结构化信息然后把结果整理成表格。开始之前先说清楚思路大模型直接输出的文本程序难以解析和加工所以要让模型输出JSON再用Python解析。新建一个prompts.py把抽取任务封装成可复用的函数def extraction_prompt(text: str) - str: return f 你是电商评论分析助手。请从用户的评论中提取以下信息 1. 情感倾向正面/中性/负面 2. 提到的产品缺点如果没有填无 3. 用户建议如果没有填无 请严格按JSON格式输出不要有多余说明文字。 示例 输入这个耳机佩戴很舒适但蓝牙连接偶尔会断。 输出{{sentiment: 中性, cons: [蓝牙连接偶尔会断], suggestion: 无}} 输入 {text} 输出 注意到提示词里包含了一个“示例”这很重要。有了示例模型输出的格式基本不会跑偏。接着在接口里调用import json import re def parse_json_response(resp: str): # 模型偶尔会在JSON外面包一层Markdown代码块先把它们去掉 match re.search(r\{.*\}, resp, re.S) if match: return json.loads(match.group()) return {} app.post(/extract) async def extract(req: AskRequest): resp await call_ollama(extraction_prompt(req.question), req.system_prompt) try: result parse_json_response(resp) except json.JSONDecodeError: result {error: 模型输出无法解析, raw: resp} return result这里面我预设了一个容错逻辑一旦模型输出的JSON解析失败就返回原始文本和错误标记。这在生产环境特别关键因为模型不保证100%符合格式你得给下游一个明确的降级方案而不是直接让程序崩溃。多步调用怎么做比如“先判断意图再决定是回答问题还是执行工具”。这种场景下你的工程代码里应该有一个循环第一次调用模型让它在几个候选意图里选一个选完之后根据意图拼接不同的提示词再调用第二次。不要试图在一个Prompt里完成所有步骤步骤越多越容易翻车。小步快走每一步都是可测试的。我踩过一个坑为了省一次模型调用把“意图识别”和“答案生成”放在同一个Prompt里结果模型在判断意图时犹豫不决还影响了答案质量。后来改成两步意图识别用一个1.5B小模型答案生成用7B模型速度和效果都好了。3.4 做一个带记忆的AI Agent实现自动工具调用接下来我们做一个简易Agent它的任务是根据用户的问题决定是否需要查询本地的一个“库存数据”工具还是直接回答。这里我们模拟工具# mock_tools.py def query_inventory(item_name: str) - str: inventory {显卡: 5, 键盘: 0, 显示器: 12} stock inventory.get(item_name, -1) if stock 0: return f{item_name}目前缺货 elif stock -1: return f没有{item_name}这个商品 return f{item_name}还有{stock}件库存Agent的循环控制逻辑如下import json from mock_tools import query_inventory TOOLS_DESC [ { name: query_inventory, description: 查询商品的库存数量。当用户询问某个商品是否有货、库存多少时使用。, parameters: { type: object, properties: { item_name: {type: string, description: 商品名称} }, required: [item_name] } } ] TOOL_SYSTEM_PROMPT 你是库存助手。如果用户想查询库存请输出 {tool: query_inventory, arguments: {item_name: 商品名}} 如果用户问的是其他问题直接用自己的知识回答。 要求不要输出多余内容只输出JSON或回答。 def run_agent(user_input: str): prompt f用户问题{user_input} resp call_ollama(prompt, TOOL_SYSTEM_PROMPT) # 尝试解析成工具调用请求 try: action json.loads(resp.strip()) if action.get(tool) query_inventory: result query_inventory(action[arguments][item_name]) final_prompt f用户问{user_input}\n工具返回结果{result}\n请用自然语言回答用户。 return call_ollama(final_prompt, 你是一个友好的库存助手。) except json.JSONDecodeError: pass return resp这个例子虽然简单但已经具备Agent的原型模型可以选择调用工具工具执行结果再反馈给模型形成最终回复。真实项目里工具可能是数据库查询、搜索引擎接口甚至是另一个模型但框架完全一致。需要强调一点Agent的工具调用结果必须有“格式校验”。工具返回的是一个字符串但下游模型在理解它时容易出错比如数字写成“5件”和“库存5”都可能造成歧义。最好统一成标准JSON比如{item: 显卡, stock: 5, status: available}让模型容易解读。4. 常见问题与排查技巧实录4.1 显存不足、模型加载失败怎么处理本地部署最常遇到的就是显存爆掉。最直观的表现是模型刚下好一跑就报CUDA out of memory。这不是模型本身的问题而是加载了过大的量化版本或上下文设置过大。排查思路分三步先看显存占用情况Windows任务管理器或nvidia-smi确认模型加载前后显存变化再检查模型文件的量化位数如果用的是Q8_0还报错就换Q4_K_M版本体积几乎能小一半最后看上下文长度Ollama默认num_ctx是2048如果你在启动时设置成很大的值显存占用会成倍增长。我自己的经验值8GB显存跑7B模型量化用Q4_K_M上下文控制在4096以内稳定运行。如果你的显卡只有6GB那就老实选择3B模型不要硬撑不然每次推理都像在刀尖上行走。还有一个容易忽视的点集成显卡和独立显卡同时存在时Ollama可能默认使用错误设备。可以在启动命令中指定GPU设备CUDA_VISIBLE_DEVICES0避免模型被加载到核显上导致慢得离谱。4.2 模型回答质量差到底该调哪里“模型回答不准确怎么办”这个问题在我后台被问过几百次。大多数人的第一反应是换更大的模型但更大的模型意味着更贵的成本和更慢的速度。工程上应该先做这几件事检查Prompt是不是足够明确。如果问题含混不清模型只能靠猜。试着把问题拆细加上边界条件。增加少样本示例。一个示例能让模型的输出风格、格式和深度发生明显变化。降低温度参数。做事实性问答时把temperature从0.7降到0.1会显著减少编造。检查上下文是否足够。如果系统提示词和用户输入混在一起模型会失去重点。把关键信息放在对话末尾最新一条效果更好。还有一个很多人不知道的技巧模型在系统提示词里包含“如果你不知道答案请直接说不知道”这句话。别小看这个约束它能把模型的“幻觉率”降低不少。商业应用里“让模型承认不知道”比“让模型硬答”更安全。4.3 提示词引起的数据格式错误怎么兜底前面提到用正则表达式抽JSON这只是最基础的兜底。真实场景里模型可能输出带前后缀的JSON、多层嵌套的JSON甚至反引号包裹的Markdown。我的建议是做一个“解析器组合”层层降级第一层直接json.loads()。第二层去掉Markdown代码块标记后json.loads()。第三层用正则找到最外层大括号后解析。最后一层直接返回错误标记让上游重试或人工处理。另外对于关键业务我还会加一层“字段校验”。用Pydantic定义一个数据模型解析后验证必填字段是否存在、类型是否正确。格式不对就认为是模型异常记录日志并退回默认值。这在生产环境能救你一命。别觉得麻烦AI本身的随机性决定了你必须有完善的兜底设计。4.4 并发和性能问题一次请求耗时20秒怎么办模型推理本身就慢如果接口设计不合理并发会直接拖垮服务。第一个优化点是流式输出让用户看到内容一点点出来而不是干等一个完整的JSON。第二个是增加缓存对于重复性高的请求把模型输出按Prompt哈希缓存起来能省掉大量重复推理。第三个是控制上下文长度上下文越长生成越慢尽量精简。我做过一个粗略基准在RTX 4080上Qwen2.5-7B生成100个token大约需要1.2秒但如果你一次性传入5000个token的上下文首token时间会明显上升。所以对长文档场景建议做“先检索后生成”也就是RAG的思路而不是把整篇文档都塞给模型。5. 从项目走向产品工程化思维比模型更重要5.1 评估与回归测试没有度量就没有优化很多AI项目“开发一时爽上线火葬场”就是因为没有建立评估体系。传统软件有单元测试、集成测试AI系统也需要一套“回归测试集”。你应该准备一批固定的输入比如200条真实用户问题每次改Prompt、换模型之后都跑一遍这批输入人工或半自动地评价输出质量。只有这样你才能放心地说“这次改动没有让效果变差”。我习惯把评估集分成三类基础正确性答案有没有明显错误、格式合规性输出能不能被程序解析、边界鲁棒性恶意输入和无关输入会不会导致崩溃。每次迭代都把这个评估集跑一遍记录通过率。不要相信“我感觉变好了”要看数字。5.2 日志、监控和成本控制上生产前的最后一步本地模型没有按token计费但一旦切换到云端API成本控制就变得极其重要。你要在工程代码里记录每次调用的输入长度、输出长度、延迟、模型版本、Prompt版本这样才知道钱花在哪、慢在哪。日志结构推荐用JSON行格式方便接入日志平台。监控方面除了传统服务的CPU、内存指标还要关注“模型相关指标”token吞吐量、首token延迟、工具调用成功率、上下文溢出次数。这些指标能帮你定位是最外层网络问题还是Prompt设计问题还是模型本身能力不足。我之前就碰到过工具调用成功率从95%跌到70%排查半天发现是某次更新把工具描述格式改了模型不认识新格式了。5.3 继续学习的方向从“能用”到“好用”写完这几个demo你已经跑通了一条完整的AI工程链路剩下的就是往纵深发展。我个人建议按顺序深入学习先掌握RAG检索增强生成学会用向量数据库给模型接入私有知识再学LangChain或自己写一套工作流引擎理解Agent的复杂状态管理然后去研究模型微调理解怎么用LoRA低成本让模型适应自己的业务最后才是分布式推理和部署优化比如用vLLM提升吞吐量。不要看到什么都想学。AI工程的重点是用工程方法把不完美的模型变成可靠的产品你的核心竞争力不在于比别人懂更多模型细节而在于能不能在混乱中搭建出有序、可维护、可演进的系统。这跟传统软件开发最终要解决的问题是一样的只不过多了一些动态的、概率性的对象。我个人在实际操作中的体会是AI工程里最耗时间的其实不是写代码而是调Prompt和排查“这次为什么效果不好”。过程很磨人但当你把一条原本要人工处理十几分钟的任务压缩成几秒钟自动完成的流程时那种踏实感是纯调API体会不到的。如果你也想从零开始走一遍别犹豫先把本地模型跑起来然后试着让它帮你完成一个小任务哪怕是格式化一段文字。从第一个能跑的demo开始后面的事情会越做越顺。