从传统后端切到AI工程的第一周我就被一个简单问题问住了你的系统准确率到底是多少以前做支付接口我可以拍胸脯说“这笔交易要么成功要么失败绝不重账不漏账”但面对一个LLM应用我连怎么定义“准确”都说不清楚。同一个 prompt 昨天回复得漂亮今天换了个说法明天可能就多出两句废话。这就是AI工程和传统软件开发最本质的区别——我们面对的是概率系统而不是确定性系统。这篇内容是一次完整的“AI工程从零开始”的复盘总结。它适合两类人一类是刚接触LLM应用开发、想系统化搭建自己项目的开发者另一类是已经在调API做Demo、但总觉得离“工程化”还差一步的工程实践者。我会把从选型、Prompt设计、Agent化、测试评估到部署成本的真实经验拆开讲也会把踩过的坑原原本本摆出来希望能帮你少走几段弯路。1. AI工程与传统软件工程的本质差异先搞清楚自己在做什么1.1 确定性系统与概率系统的思维冲突传统软件工程的核心假设是“输入决定输出”。同一个接口传同样的参数返回永远一样。你可以用断言来测试用回归用例来守护甚至用形式化方法去证明某些性质。这套方法论的前提是系统行为可重复、可穷举、可预期。AI工程完全不是这么回事。一个LLM应用哪怕prompt一字不改、参数不变同样的输入也可能输出不同的结果——temperature不为0时尤其如此。就算把temperature设成0模型的解码路径也存在不确定性。这带来一个连锁反应你没法用“写死逻辑”的方式保证质量只能通过“数据 评估 反馈”的方式逼近质量。我见过不少从Java/Go转过来的团队第一个月都在疯狂给LLM输出写正则、写规则修复试图把概率输出“掰成”确定性输出。结果就是补丁越打越多规则越叠越厚最后变成一座维护地狱。方向从一开始就反了AI工程要做的是“在概率输出上建立确定性流程”而不是“消灭概率”。1.2 AI工程的最小闭环数据、模型、评估、部署AI工程和传统开发的另一个差异是——传统开发上线后进入维护期AI工程上线后才是真正的工作开始。一个完整的AI应用应该是一个闭环最少包含四个环节数据层包括Prompt样本、知识库切片、微调数据集、评测集。这一层决定AI的行为边界。模型/应用层可以是调用外部大模型API也可以是微调后的开源模型还可以是多轮Agent编排。评估层离线评测、线上监控、用户反馈回收。部署与迭代层推理服务、缓存、成本控制、模型或Prompt的更新。一个合格AI工程的核心指标不是“功能是否跑通”而是“闭环是否跑通”。换句话说你能不能在发现模型回答变差时迅速定位到是数据问题、Prompt问题还是模型版本问题并快速修正后再上线。这个过程必须形成回路否则回退永远靠随缘。我之前做过一个智能客服项目前两个月团队全在调Prompt谁调谁上线结果每次都是修好一个坏两个。后来把评测集建起来所有Prompt修改都先跑一遍评测集效果稳定后再灰度回归率立刻降下来了。这就是闭环的力量。2. 从零搭建AI工程动手前必须想清楚的三个问题2.1 调用大模型API还是自己微调开源模型很多人一上来就纠结“要不要微调”其实这个决定和你的应用场景高度相关。先做一组对比维度调用商用大模型API微调开源模型开发速度快几天能跑通慢需要数据准备和训练效果上限高尤其复杂语义受限于底座模型能力成本按Token付费长期使用可能贵GPU一次性投入运行时成本较低数据隐私数据出域需合规评估数据不出域私有化部署技术门槛低中高需要训练和推理经验维护复杂度低模型厂商负责更新高自己要跟进新版本我的建议很直接如果你的业务语义比较复杂且预算充足优先用API跑通闭环如果数据高度敏感、离线要求在边缘部署、或者你的交互模式非常固定才考虑微调。微调的坑特别多我见过有人用几百条数据微调7B模型结果回答模板化严重还不如直接写好prompt。微调不是万能药数据量不够反而损坏底座能力。2.2 框架选择别被LangChain绑架AI工程领域现在有太多“全家桶”框架LangChain、LlamaIndex、Semantic Kernel还有各种新生代Agent框架。圈里人经常争哪个框架好但我真实的体感是——先从原生SDK开始理解原理后再决定要不要上框架。用原生SDK写一个LLM应用无非就是构造prompt、调用接口、解析输出。这个流程控制力最强也最容易调试。等你的应用开始出现多步工具调用、多个知识库来源、需要复杂上下文管理的时候再引入框架来抽象公共逻辑。哪怕引入了框架也要把核心链路自己掌控住否则框架升级、API变动会直接卡死你。我现在的习惯是核心Agent编排自己写知识检索用成熟工具工具调用靠模型原生function calling能力。框架只负责解决非核心的通用问题比如持久化、限流、队列。2.3 数据从哪里来没有数据集就是空中楼阁很多人做AI工程时犯的最大错误就是先调prompt再做评测集。顺序应该反过来——先把评测集建立起来哪怕只有20条。最笨但有效的方法是手工记录真实用户问题然后人工写出理想回答。不需要多先30条覆盖典型场景10条覆盖边界场景。这40条就是你的第一版评估集。每一次修改prompt、调整参数都拿这40条去跑一遍对比输出质量你就能立刻知道改动是变好还是变坏。等应用上线后再持续从日志中抽取低分案例、抽样用户反馈逐步扩充评测集。没有数据集你的AI工程就是“靠感觉飞行”今天好明天差根本不知道差在哪。3. 提示词工程的核心不是把话说漂亮是设计一个稳定的输入输出协议3.1 System Prompt的结构化模板很多教程讲Prompt时只强调“让AI扮演角色”。真实工程里只有这些远远不够。Prompt的本质是给LLM下发的“协议”它要同时定义行为边界、输入格式、输出要求和交互规则。我用下来比较稳定的一个五段式结构分享给你角色定义一句话说明AI是什么、擅长什么、不做什么。任务目标明确本次交互要完成的具体任务越具体越好。输入说明定义输入数据的结构比如“用户消息为JSON可能包含以下字段”。输出约束输出格式、长度、语气、是否允许反问、是否必须按JSON结构返回。示例给两个完整的输入输出示例尤其给反例——告诉它“这种情况下不要回答/回答什么”。举个例子一个客服助手模板大致长这样你是XX产品的客服助手。你只能回答与产品使用相关的问题不闲聊、不编造功能、不给出法律承诺。 用户输入为用户原话可能是问题、反馈或投诉。 输出要求 1. 首先判断是否与产品相关不相关时回复“抱歉这个问题超出我的范围。” 2. 回答不超过50字使用简体中文。 3. 如果无法确定明确请用户转人工。 示例 用户你们的软件能帮我一天写日报吗 输出可以你可以在“自动日报”模块设置模板系统每天17点自动生成日报。这个模板看起来简单但每一行都有作用角色定义限制行为边界输出约束控制回复质量示例让模型跟着样本走而不是自己发挥。工程化的Prompt必须当成接口定义来维护而不是灵光一闪的句子。3.2 上下文窗口管理塞不下的时候怎么办LLM的上下文窗口越来越大但“能塞下”和“适合塞下”是两回事。长上下文既抬高成本又会引入注意力漂移——模型会忘掉中间的细节。工程上对超长内容有几种主流处理方案滑动截断只保留最近N个片段最简单但丢失前文关键信息。摘要压缩用一个小模型把前面的聊天记录或文档摘要成要点塞回上下文。检索增强RAG按语义相关性抽取指定片段拼进上下文适合知识库问答、文档理解场景。RAG的本质是“用检索换取上下文质量”而不是把整本手册全塞给孩子。这里有一个常见误区以为RAG只需要做一个向量库相似度查询就行。实际上分块大小、重排策略、混合检索关键词语义、甚至引文回源都会直接影响最终回答质量。工程上我习惯的做法是先用简单命中率评估RAG召回质量再调生成端的Prompt不要一上来就追求复杂的排序模型。4. Agent工程化从Demo到可用的血泪教训4.1 为什么Demo里的Agent总是一跑就废Agent相关的Demo是现在最热闹的方向但Demo和可用的产品之间隔着一条很大的河。我见过太多Agent demo用户说一句“帮我订机票”Agent自动规划、调用API、输出结果现场演示倍儿有面子。一旦放进真实环境立刻翻车——用户需求描述含糊工具返回格式变化中途网络超时Agent开始不停地重复调用同一个失败接口。根本原因是Demo只展示了“只走通一条路的剧本”而真实工程必须处理“无数条非预期分支”。这也是Agent不能直接在业务中裸奔的原因。4.2 工具调用与状态管理的关键设计把Agent做成工程化的第一步是给Agent划定“能力清单”。不要让它什么都自由发挥而是明确定义它可调用哪些工具、每个工具的输入输出结构、哪些场景下被禁止调用。同时接收工具调用的返回结果必须有超时和重试策略。我的做法是在Agent的System Prompt里内置一张工具表并配一个“计划器”节点先让模型产出行动规划再执行工具调用每次行动前验证必要参数是否齐全。状态管理又是另一个重点。Agent多轮交互时必须维护一个状态记录了当前用户目标、已获取信息、待确认事项、已失败的尝试。我推荐用一种轻量做法在Session中维护一个JSON结构每次循环后更新状态而不是把全部历史一股脑塞给模型。模型只需要在每轮开始前读取当前状态即可。4.3 兜底机制别忘了留后门再聪明的模型也会有不靠谱的时候。Agent工程的铁律是必须有人工兜底和自动化熔断。具体来说最大迭代限制比如最多执行5次工具调用超过后就转人工。置信度阈值如果模型产出计划时置信度低于某个阈值直接要求用户确认。转人工开关任何环节用户都可以主动要求人工介入。操作可撤销性关键动作执行前必须经过用户确认。这些机制听起来简单但很多项目都没有做。我接手过一个内部辅助Agent没有兜底有一次把“删除测试配置”理解成了“删除生产配置”还好我们当时做了权限校验拦住了。不要相信模型会做正确判断要相信流程设计能让错误及时暴露。5. AI应用测试与评估没有指标就不叫工程5.1 离线评测集的建设方法评估是AI工程和传统开发最容易忽略、也最关键的环节。离线评估做得好线上翻车概率能打对折。建设评测集要从业务维度拆解而不是笼统问“好不好”。以问答系统为例至少分这四个维度正确性回答是否准确、有没有编造事实。完整性是否覆盖了用户问题的核心方面。格式合规是否按约定的JSON结构、字数、语气输出。安全性有没有包含不适合生成的内容有没有拒绝回答范畴外问题。评分上我推荐双轨制先用LLM-as-judge批量打分再用人工抽检校准。LLM打分不能完全信任需要定期抽样对比“LLM分数”和“人工分数”之间的一致性。一旦发现偏差变大说明评分prompt需要调。这里有个实操技巧评测集每条样本都应该记录“修改基线版本号”也就是说每次上线前你要同时跑“旧版本”和“新版本”对比得分后才决定是否发布。没有基线的评估等于没有标准。5.2 线上监控看的不只是日志传统开发线上看错误日志和调用链AI工程除了这些还必须监控“模型输出轨迹”。我建议起码建立一个监控面板包含以下指标指标含义异常信号Token消耗每次请求的输入输出Token量突然大幅上涨说明Prompt膨胀/循环响应延迟首Token延迟、总延迟P95波动异常工具调用失败率Agent各工具的失败比例频繁重试失败用户反馈率点赞/点踩/转人工比例转人工率持续上升输出内容哈希重复率大量相同输出可能触发安全或缓存异常与预期不符我给每个线上会话都会打上版本标签记录是哪版Prompt、哪个模型、哪套参数配置在服务。这样一旦线上出现质量问题可以快速复现、定位到是哪个版本造成的。这也是“AI可观测性”最基础的一步。6. 部署与成本推理、响应速度、费用之间的取舍6.1 三种部署形态怎么选很多中型团队会卡在部署形态上到底用托管API、自己在GPU上部署开源模型、还是两边混着来这里没有银弹我用了个三角形来取舍——快、好、便宜只能三选二。部署形态速度效果成本典型场景商用API中高受限于网络和限流高模型能力强按Token计费量大会贵通用问答、智能客服私有化GPU部署高内网中取决于底座模型GPU硬件贵运行成本相对可控数据敏感、离线环境混合架构中高高可优化如简单任务用小声复杂任务用大声大规模生产环境混合架构是目前比较务实的方案。把高频、简单的任务如分类、抽取、格式化交给小模型或缓存把复杂推理、长文生成交给大模型。既控制成本又不牺牲难度高的环节质量。6.2 成本控制的实际经验Token费用是AI工程里最容易被低估的成本。我见到过企业客户一个月跑出几万块账单的案例。分享几个实实在在的省钱手段Prompt瘦身把System Prompt里的废话删掉只保留必要的协议和示例动辄能省20%-30%输入Token。缓存完全相同请求面向相同用户、相同问题的请求做语义缓存直接命中缓存不调模型。批量离线任务错峰跑非实时任务如日报生成、批量摘要放到API低峰期跑价格更便宜还能避免限流。用小模型处理简单任务很多分类和抽取任务根本不需要大模型的推理能力用7B-13B级别模型完全能胜任成本能降一个量级。控制Agent循环次数Agent每多一次循环就是多耗一次Token一定要设置最大步数并且把中间结果写紧凑不要每次都把完整历史塞回去。这些看起来都是小细节但叠加起来效果惊人。我之前把一个日报助手从每月600美元降到了180美元核心就一句话让模型少干活、省着说话。7. 实际项目中的三次失败教训7.1 教训一过度依赖全自动Agent没有兜底第一个教训来自一个自动化工单系统。当时我们信心满满地做了个Agent用户提交工单后自动分类、自动分配、自动生成答复草稿。结果有一次模型把“退款申请”识别成“技术咨询”还自动生成了一封牛头不对马嘴的答复发送给了用户。用户直接投诉到客服整个流程暴露出一个严重问题——我们把“自动”做成了“完全没有人工确认环节”。修复也很直接所有Agent生成的外部动作发送邮件、修改状态都必须经过人工确认才能执行只有内部查询类动作可以自动完成。这个改动上线之后投诉率直接归零。工程不是追求极致自动而是在每个风险点加一道闸门。7.2 教训二忽略评估直接上线导致回归第二个教训是我们做审核辅助系统时老板看完Demo觉得效果不错直接要求上线。当时的评测集也就十来条都是精心挑选的正面案例。上线后遇到一个特别刁钻的营销变体模型直接放行了违规内容。复盘时会发现根因不是模型不行而是我们连“失败案例集”都没有等于让模型裸奔。后来我们花了整个周末从历史工单里挖了300条真实案例包含正常案例、恶意变体、边缘模糊案例给每条打了标签再重新跑离线评估模型立刻现出原形。从那以后我定了一个死规矩没有评测集不许谈上线。7.3 教训三忽略数据隐私被迫临时更换模型第三个教训是我们早期图方便直接把用户对话内容发到第三方大模型API后期才意识到这些数据涉及客户隐私合规审查过不去。被逼着临时切换成私有化部署的开源模型前后花了一个多月的时间中间还出现了一周的效果回退。这件事的教训有两层一开始选型时就要把隐私边界划清楚如果必须走API先做字段脱敏把用户ID、联系方式、业务敏感词全部替换成占位符等模型返回后再映射回来。这不是技术难题但你不提前规划迟早会变成紧急事故。8. 关于“从零开始”最后想说的体己话翻了这些经验核心其实就一句话AI工程没有那么多玄学它仍然是工程只是多了一点概率性、不确定性和演化性。你必须用工程的方式去对待它——建评测集、写分阶段测试、做监控、保留回滚能力、给模型上花式保险。一个非常实用的小技巧接手新AI项目第一件事不是写代码而是把“最希望AI做到的一件事”和“最怕AI搞砸的十件事”列出来。前者就是你的核心评测维度后者就是你兜底机制的设计清单。把这两张纸画完整个系统怎么搭心里就有底了。这条路并不轻松但它是值得的。别怕从零开始只要你的闭环是通的每个版本就都会比上一版更接近“可用”这两个字。