很多人一提到AI工程第一反应就是“调API、写提示词、接个大模型就完事了”。真在项目里滚过一圈你就会发现这套想法撑不过第一周。无论是做个客服问答、内容分析工具还是搭建一个带工具的Agent应用真正决定项目生死的从来不是“模型多聪明”而是你有没有一套工程化的方法把提示词、数据、模型调用、评估、日志这些环节管起来。我写这篇分享的目的很直接把我自己从零开始整理AI工程实践经验的过程完整拆给你看覆盖提示工程、模型选型、本地部署、Agent工作流、评估测试这些核心环节用踩坑换来的经验和可直接照搬的操作步骤说清楚一件事——具备工程思维的AI能力是怎么一步步长出来的。这篇内容适合所有正在做AI应用开发、准备搭建自己的智能体项目、或者被大模型搞得既兴奋又焦虑的人。不管你是还在纠结从哪开始还是已经在填坑的路上这篇东西都有值得抄的作业。1. AI工程的真面目从“会调用模型”到“构建系统”1.1 工程思维和调接口思维的差别在哪里我把这两年开始做AI项目以来的一个观察放在最前面很多人被卡住的点不是不会写代码而是把AI工程理解成了“API调用工程”。一个最典型的例子——收到需求后第一件事就是注册模型平台、研究接口文档、试Prompt折腾几天发现效果不稳定就开始怀疑是模型不行换个更强的模型继续折腾。这个循环我见过太多次了。真正应该先做的是把问题剥开这个功能到底要解决什么问题输入长什么样输出要什么格式允许出错的比例是多少延迟和成本上限在哪用户是拿来辅助还是直接采信这些问题没有答案之前选什么模型都是盲选。打个比方你会先搞清楚要铺的是停车场还是跑道再决定买哪种沥青而不是先买一堆材料回来试。AI工程里的“从零开始”真正难的不是“从零学会调API”而是“从零建立一个能稳定交付效果的体系”。1.2 一个AI项目工程师的能力全景图经过几个项目的反复打磨我认为一个合格的AI应用开发者能力结构至少包含六个层面优先级从高到低需求具象化把模糊的“做一个智能助手”拆成描述清晰的、可验收的功能点这是隐藏技能点。数据与上下文控制知道该给模型喂什么、不该喂什么如何管理外部知识库的状态。提示词与策略设计理解指令、示例、上下文窗口的关系知道什么时候该“加话术”什么时候该“改架构”。模型工程化选型能根据任务难度、成本、延迟、私有化程度要求在API模型和开源模型中做合理取舍。评估与回归体系有一套固定的测试用例能在修改Prompt或替换模型后快速判断效果是变好还是变坏。可观测与持续优化对线上调用做日志、监控和错误追踪让问题能从“我不知道它为什么错”变成“我知道它在哪个环节错的”。我见过不少做得不错的朋友共同特点是前两项异常扎实。反而是那些天天追新模型、收藏各种炫酷Prompt的人项目反而没什么实质进展。这不是说追新不好而是说AI工程的核心是“把可控的东西做扎实”不是“把模型换成更强版本”。模型在升级但你的评测集、数据管道、输出解析这套工程底座才是真正沉淀下来的资产。2. 提示工程第一课理解采样和输出控制2.1 采样参数背后的直觉不只是“调温度”聊提示工程先从模型输出的基本原理讲起因为很多参数折磨过所有人。大模型生成文字本质上是在概率分布上做采样每次选一个token再根据这个token重新计算下一步的概率。温度temperature和top_p这两个参数控制的就是这个采样过程的“保守程度”和“发散程度”。温度越低模型越倾向于选择概率最高的token输出越稳定、越保守适合提取信息、生成结构化数据、分类判断这类任务。温度越高低概率token被选中的机会越大输出越随机、越有“创意”适合头脑风暴、文案生成。top_p则是另一种思路把概率从高到低累加直到累计概率超过你设定的阈值然后只从这些高概率的token里采样。你把它理解成“把候选名单截短”就行。我在实际项目里的默认组合是结构化输出任务temperature设0.2甚至0top_p设0.9左右创意生成任务temperature设0.8到1.0top_p看情况。但这只是起点不是银弹真要确定参数还得靠你的评估集跑一轮对比。别嫌麻烦这一步省了后面无穷无尽的返工等着你。2.2 写好Prompt的四个可复用策略关于Prompt本身网上铺天盖地都是长文我只讲我真正在项目里反复用到的、效果稳定可复用的四条。讲解原因和操作示例。第一用“脑内彩排”代替抽象指令。不要只写“请总结这篇文章”而是把读者和格式关系写清楚“你是一个技术编辑请用通俗的语言为没有AI背景的读者总结这篇文章的三个核心观点每个观点附带一个生活化类比。”模型没有“理解”你的意图它是根据你的描述去预测最合适的回答方式你的描述越具体预测空间越小效果越稳。第二给出“反面边界”。告诉模型不要做什么往往比告诉它做什么更有效。比如“不要输出任何特定型号的推荐如果信息不足直接说明无法判断”这一招可以让模型少一本正经地胡说八道。第三用示例锁定输出格式。需要输出JSON、Markdown表格或有固定字段的结果时最佳做法是给一个完整的输入输出示例。有一次我做一个信息抽取任务无论怎么描述字段格式模型总在备注里多输出废话最后直接在Prompt里附上了输入和期望输出各一条问题立刻消失。原因在于示例激活了模型“模仿”模式比文字描述的控制力强得多。第四拆分任务让模型逐个执行。一次完成多步任务最后一步出错的可能性会叠加。与其让模型“先分析再翻译”不如第一次调用让它分析第二次调用把分析结果作为输入再做翻译。这个思路会自然衔接后面的“工作流设计”部分。2.3 结构化输出让模型接口接上你的代码Prompt工程里我最推荐优先掌握的技能就是把模型输出变成程序能直接处理的结构化数据。别让用户拿回一段自然语言去二次解析那是对自己和后续维护的折磨。现在主流模型平台都支持JSON模式你可以在系统指令里明确要求返回JSON对象并附上字段schema。更好的方式是使用函数调用function calling机制把输出定义成函数参数。我自己偏爱的方法是在代码层定义好数据模型比如用Pydantic的BaseModel定义字段和类型再把模型描述转换成JSON Schema塞进请求。这样不仅保证输出结构合法还能在解析失败时得到明确的报错信息方便后续处理。实际操作中我会加一道保险拿到输出后先做一次JSON解析校验失败就重试一次带上上一次的错误信息再失败就降级为人工标错。这一整套下来模型输出的不确定性才真正被工程系统“接住”。3. 从单次调用到完整系统工作流和Agent搭建3.1 先分清Workflow和Agent别一上来就整复活的很多刚接触AI工程的人一听到Agent就兴奋恨不得所有功能都做成多智能体协作系统。结果做出来之后系统路径完全不可控出了错都不知道该看哪个环节。我的建议非常朴实能通过预定义工作流解决的问题绝不上Agent动态决策。两者之间的差别可以这样理解。工作流是把任务拆成固定步骤然后一步步线性执行每步做什么是预先编码写死的可控性极强出错也容易定位。Agent则是让模型循环思考要做什么自己规划步骤、调用工具、根据结果调整后续动作灵活性高但不可预测性也随之增加。实际项目的选型建议数据清洗、文档解析、多步翻译、信息提取合并这类流程固定的任务用Workflow。需要在多步之间动态判断、需要根据环境反馈不断调整策略的开放任务比如一个能自己查询数据库、跑代码、搜索资料的通用研究助手再用Agent。性能稳定性和可控性之间你要做个现实主义者。3.2 Agent到底是怎么工作的剥开看核心循环关于Agent的运作机制我自己理解成一个四步循环每一项都值得单独安排架构设计。规划Plan模型理解任务后生成一个行动方案方案里通常包含思考、执行动作、更新状态等步骤。工具调用Act根据方案选择一个注册好的工具并传入参数工具的调用结果就是模型做进一步决策的依据。观察与记忆Observe模型拿到工具返回结果之后“读懂”这个结果意味着什么、离最终答案还有多远。再规划Re-plan如果需要继续就回到第一步如果任务完成就组织最终答案给用户。这个循环每一步都在消耗token每一步都可能出错。所以搭建Agent时最大的工程挑战不在于“把循环写出来”——几百行代码就能做到——而在于你怎么定义好工具清单、怎么让模型在工具调用出错时有合理的重试策略、怎么给Agent设定“什么时候该停止”的限制条件。3.3 实操搭一个能调用工具的极简Agent这里我把一个最小可用的Agent循环骨架写出来用的是OpenAI函数调用格式和LangChain的简化模式但思路对所有框架通用。第一步注册工具。给模型提供工具描述包括名称、参数说明和一段清晰的“什么时候该用这个工具”的说明。tools [ { type: function, function: { name: sql_query, description: 执行只读SQL查询适用于回答用户关于数据的问题, parameters: { type: object, properties: { query: {type: string, description: 完整的SQL查询语句} }, required: [query] } } } ]第二步写循环。第一次调用传入用户问题和工具列表返回结果若包含函数调用请求就执行该工具把结果作为一条工具消息接回去再调一次模型如此反复直到模型返回普通文本或达到最大轮次。def run_agent(user_query, max_rounds5): messages [{role: user, content: user_query}] for _ in range(max_rounds): response client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolstools ) msg response.choices[0].message messages.append(msg) if msg.tool_calls: for tc in msg.tool_calls: result execute_tool(tc.function.name, tc.function.arguments) messages.append({ role: tool, tool_call_id: tc.id, content: str(result) }) else: return msg.content return 达到最大轮次会话中止第三步兜底异常。工具报错时不要直接把堆栈信息丢回模型而是先捕获异常把精简后的错误信息传回去让它重新生成参数或换一种解法。这一小步能把Agent的自愈能力提升一大截。这套极简骨架能让你理解Agent的核心路径。至于用LangGraph也好用AutoGen也好用自己手写的Loop也好本质都是在这个循环上加记忆、加状态、加可视化调试别被花哨框架迷了眼。4. 模型选型和本地部署当预算和隐私受限时4.1 从三个维度拆解模型选型问题做AI工程绕不开的经典问题用闭源API模型还是用开源模型自己部署。我以前也纠结过后来总结成三个决策维度每次选型都拿这三个问题过一遍。任务难度决定模型能力下限数据隐私决定能否使用公网API成本结构决定调用量大的方案是否可持续。任务难度任务涉及复杂推理就选最新旗舰或接近旗舰的模型任务偏格式化提取、分类、摘要则选择性价比够用的中等型号甚至小模型。数据敏感度客户数据能不能出域聊天记录能不能被平台留存训练这些不是技术问题是合规底线。数据敏感度高就走私有化部署路线。调用频率与预算API模型按token计费日均百万token级别得提前权衡成本本地部署的GPU成本和带宽成本也要摊进总账。经常有朋友说“我本地部署一个7B模型就够了吧”真想反问一句“够不够拿你的评估集跑过才知道”。选型不是一个静态决策它需要你的评估集来支撑。4.2 本地部署的前置准备硬件和量化原理以开源模型为例部署前你最需要理解的概念是量化Quantization。像Qwen、Llama这类模型默认fp16精度跑一个70亿参数的模型仅模型参数就需要约14GB显存还得给推理过程和KV Cache留空间所以硬件要求很高。模型量化之后权重用更小的整数或低精度表示比如fp32变int8显存需求可以几乎减半。我实测过Qwen2.5-7B的int8量化和fp16相比在文本摘要、信息抽取这类任务上质量下降幅度可以接受但在数学推理这类任务上会有可感知的精度损失。部署工具现在最省心的我认为是Ollama它内置了量化支持一条命令就能跑起来。硬件起步建议是7B级别模型至少12GB显存实际建议16GB做并发服务想要流畅体验32GB以上更稳妥。显存不够的情况下CPU部署可以跑但速度感人只适合本机体验和离线分析不适合服务线上业务。4.3 本地部署实操用Ollama跑一个7B模型如果你想快速上手本地部署我建议用Ollama配合Open WebUI亲测这条路从零到能聊、能测试大概半小时。第一步安装Ollama。Windows直接下载安装包macOS用brew install ollamaLinux用官网脚本装完打开服务。第二步拉取模型。在终端执行ollama run qwen2.5:7b-instruct-q4_K_M这条命令会自动下载并启动一个量化过的7B对话模型交互模式直接能聊。第三步提供API服务。执行ollama serve或Ollama默认后台运行它默认监听本地11434端口支持OpenAI兼容的接口格式这意味着你的代码可以无缝从API模型切换到本地模型。我曾经一套业务代码改一个base_url参数就切换了模型服务这个体验非常舒服。后续如果要给团队用、做更多模型管理就装Open WebUI把它连到Ollama的API上。你会发现本地部署的门槛没有想象中高真正费精力的反而是模型效果本身是否满足业务需求。5. 工程化的重头戏评估、测试与可观测性5.1 别靠“感觉”判断效果建一套用例集我在项目里的第一条铁律是没有评估集的AI项目一律算玄学开发。为什么这么说因为大模型输出有随机性你测试时凭“感觉还行”下次改个Prompt你根本分不清是变好了还是变坏了。用一套固定的测试用例每次改动后都跑一遍才能看到真实的回归情况。用例集怎么建我建议从三个来源收集线上真实用户问题脱敏后、历史业务里遇到的困难case、以及人工构造的边界case超长文本、空输入、特殊符号、多轮上下文干扰等。每个用例配上预期行为描述不一定是一段标准答案而是“应该包含关键信息A和B”“不应该出现敏感内容”这类可判定的准则。规模上初期50到100条就够用了关键是覆盖度和可维护性。5.2 评估的两种实操方法规则判分和LLM裁判有了用例集怎么打分我常用两种方法结合。第一种是规则判分适合可客观检验的任务。输出是否为合法JSON、是否包含必填字段、答案中是否出现指定实体、分类结果是否等于标签——这些用脚本就能自动判断效率高、稳定性强。我的信息抽取项目里80%的评估case是这类规则判分。第二种是用LLM当裁判适合主观质量评估任务。比如文案是否贴合品牌调性、摘要是否忠实原文、回答是否条理清晰。方法很简单写好一份评分标准Prompt把用户问题、模型回答一起发给一个评判模型让它按标准打分并给出理由。需要注意两个坑一是裁判模型和被测模型尽量分开否则容易偏袒自己的输出二是裁判Prompt本身也要固定不然你今天觉得8分明天觉得6分样本之间没法比。5.3 日志和追踪让每次调用都有迹可循线上AI应用和普通后端应用最大的不同是模型的每次输出都没有确定性保证所以必须有日志和追踪机制。我一度被这种问题折磨一个功能偶尔出错但本地复现不出来因为你根本不知道线上那次调用到底发了什么Prompt、模型返回了什么、温度设的多少。从那时起我就定了线上调用的“三必须”必须记录请求完整信息入参、Prompt、模型参数必须记录响应完整信息原始输出、解析后的输出、耗时和token消耗必须记录业务结果用户最终是否采纳、人工是否纠正。工具层面轻量方案直接结构化日志存起来全链路追踪方案可以上LangSmith之类的链路跟踪体系这些都能做到。关键是养成这个习惯别让AI应用成为黑盒。你未来排障、优化Prompt、评估模型升级全都依赖这些日志数据。6. 实战复盘从零搭一个私有化知识库问答助手6.1 需求拆解和技术选型过程拿我最近完整做过一遍的项目来复盘。需求是给一个内部团队做一个知识库问答助手把分散几十份的PDF和文档变成可聊天查询的系统。约束条件有三条文档内容敏感不能出域需要私有化部署团队人数不多硬件有限问题形式以“某个规范里是怎么规定的”“某个流程的步骤是什么”这类事实问答为主。因为这个需求本质是“从外部文档中检索信息并回答”选用了非常成熟的RAG检索增强生成架构而不是微调模型——原因是预算不够、信息更新频繁而检索方案的迭代成本更低。模型上选了7B级别的开源中文模型走本地部署向量检索选了轻量级方案因为文档总量不大约2万段不必上重型分布式向量库。这个选择的思路就是先用最可控、最低成本的方案验证全链路再根据实际体验决定是否升级。关于RAG简单解释一下它不是一次调用就完成的。整个过程分两步先离线把文档切成片段、用向量模型算出每段文字的向量存进向量数据库用户在线上提问时先把用户问题转成向量和库里的向量做相似度检索取Top N个相关片段再把这些片段连同用户问题一起包进Prompt发给模型。这样模型回答时就有“参考资料”可以做依据。6.2 落地的关键坑切分、召回与上下文管理我觉得RAG落地最坑的环节不是模型而是文本切分。之前想当然地按固定字符数切分结果一个技术名词被硬生生劈成两半检索能搜到时好时坏。后来改成“先按段落标记切、超限再补切到句子边界”召回质量才明显稳定下来。能不能设计好“语义完整片段”直接决定了检索的精度上限。另一个容易踩的坑是召回数量与上下文长度的平衡。我一开始取Top 5片段都给模型发现回答开始混乱因为上下文被无关噪音占满。后来调整成“先取Top 10再用简单的交叉编码排序压缩到Top 3”的分级策略效果好了很多。宁可给模型看更少但是更相关的片段也别塞一堆若即若离的内容让它自己找重点。关于上下文管理还有一个容易被忽视的细节用户在多轮对话里追问“那第二步呢”模型要看的是上一轮回答里提到的内容但新问题本身缺少主语。解决这个问题我在线上服务增加了“历史对话摘要”模块在用户问题进入检索之前先把最近几轮的对话做一次压缩摘要辅助生成新的检索query。这一步做完多轮问答的体验才真正可用了。6.3 上线之后的最真实经验关于效果的持续调优系统上线后我的工作没有结束而是进入了另一个阶段效果持续调优。用户的真实问题和我的测试用例差异极大。有人问“这个表格里的数据口径是什么”检索系统拿“表格”“口径”去召回效果很差经过排查发现关键词不在最常见的文档里而在一个数据说明附录中。这类case只能靠持续收集真实问题进评估集然后针对性优化切分策略和检索权重。还有一个让我印象深刻的教训解析PDF时不同排版双栏、表格、扫描件处理方式完全不同。一开始我天真地以为通用解析库全都能搞定结果表格数据被识别成乱序文本检索出来的答案根本没法看。后来专门引入了版面分析逻辑先检测页面结构再有针对性地抽表格内容对扫描件走OCR路线。这一步做完质量提升巨大但它又不在“调模型”这个环节里。AI工程的事真的是做完一个环节才发现下一个环节藏得更深。7. 高频问题速查我踩过的坑都列在这里7.1 十个必看问题与处理建议现象可能原因排查方向与建议模型输出空内容或报错上下文过长超出模型窗口限制截断或摘要历史内容缩短系统指令JSON解析偶尔失败模型偶尔在JSON前后输出废话用函数调用/JSON模式代码层做“剥出代码块再解析”的兜底同一个问题两次答案差异大采样温度高结构化任务把temperature调到0.2以下Agent在工具调用后停不下来缺少停止条件模型认为自己没完成任务设置最大轮次在Prompt里写清“达到目标就结束”记录意图信号RAG检索召回率低切分粒度不合适或query表达不清改语义完整切分对用户query做改写扩展回答出现幻觉检索片段无关或上下文过载减少喂给模型的片段数量增强“信息不足就明说”指令本地部署响应太慢模型太大、硬件不足或量化不够换更小的量化模型开启GPU加速做并发控制更换模型后效果下降同等规格不同模型的指令遵循能力差异大保留新旧模型版本跑同一套评估集对比再决定是否更换测试时好、线上崩线上输入分布和测试集差异大收集线上日志backlog持续补充进评估集多轮对话越来越乱历史消息无限累积上下文稀释了当前指令滚动摘要历史只保留最近N轮原文加上文摘要这些问题的共性答案只有一句话不要让AI应用处于不可观测的状态。日志、评估集、链路追踪这“三件套”比任何花哨的Agent框架都值得优先建设。7.2 一个提高开发效率的实操技巧最后分享一个让我省了很多时间的习惯每个项目都维护一个迭代实验记录表。每改一次Prompt或模型就记一条当时的动机是什么、改了什么、评估集跑出来的关键指标是多少、线上观察结果如何。这个记录的逻辑和Prompt版本管理完全一致没有它你很快就会忘了“上一个版本为什么被弃用”。养成这个习惯之后你回溯问题时能省下大量时间也有助于沉淀出自己的最佳实践方法库。做AI工程很多功夫其实花在“面向过去总结”和“面向未来评估”上。结尾一些个人想法我对AI工程这个领域越来越觉得它本质上是在训练一套朴素的实践方法论尊重不确定性、用证据说话、持续迭代、把过程管起来。模型本身依然会进化但工程化的思维框架不会有太大变动。当你手头同时握着评估集和历史日志的时候再大的模型变化你都不会慌因为你能判断它、影响它、跟踪它。希望在读这篇分享的你也能从自己的第一个小项目开始把这条工程之路一步步走扎实。