做AI工程这三年我最大的感受是真正难的从来不是模型本身而是怎么把一个模糊的“老板说要做个AI功能”拆成能落地、能评估、能上线、能长期维护的系统。市面上讲模型的文章铺天盖地但“ai-engineering-from-scratch”这条路上缺的不是模型知识而是工程化思维。这篇内容我按自己从零搭建AI项目的完整流程来写从需求拆解、技术选型、提示词工程、Agent架构到模型部署、性能优化、测试排障把关键决策的来龙去脉和踩过的坑一次说清楚。不管你是刚入行的算法工程师、转岗的后端开发还是带团队的技术负责人这份实操路径应该能帮你少走至少半年的弯路。1. 到底什么才是“从零开始做AI工程”1.1 我见过的AI项目翻车现场先说我亲身经历的三个反面案例。第一个案例团队接到一个“智能文档问答”需求技术负责人二话不说选了当时最强的通用大模型直接调APIPrompt写了三行就上线。结果呢Demo阶段拿精心准备的几篇文档演示效果惊艳。上线后用户丢进去的是各种扫描件、表格、带水印的PDF模型要么答非所问要么直接说“文档里没有相关信息”。前后折腾两个月最后发现根因是文档解析环节就没做对而不是模型选错了。第二个案例某团队做AI客服模型对话能力没问题但用户问“我要退订”时AI回复了一大段暖心话术就是没有触发真正的退订流程。业务方气到拍桌子说这不是AI客服这是AI复读机。问题出在团队只做了“对话”没做“行动”——AI识别意图之后调用业务接口这个环节完全缺失。第三个案例最可惜一个做内容生成的产品模型输出质量已经不错了但团队没有建立评测集。每次调一次Prompt全凭肉眼感觉“好像好了一点”上线后用户投诉内容质量波动大又退回到人工审核AI变成了一个昂贵的打字机。这三个案例指向同一个本质问题AI工程不是“把一个模型接进来”而是要把需求、数据、模型、工具、评测、部署、运维串成一条完整的链路。任何一个环节断裂前面做的所有工作都会归零。1.2 从零开始的真实起点不是框架而是需求拆解很多人以为“从零开始”的第一步是选框架选模型跑通一个Demo。我现在的看法完全不同第一步是把业务需求翻译成工程规格。怎么翻译拿上面那个文档问答举例需求拆解要回答这些具体问题输入是什么纯文本、PDF、图片、扫描件单文档还是多文档单轮还是多轮输出是什么摘要、抽取式答案、生成式答案、带引用的答案数据范围知识库多大更新频率多高内容是否涉及权限隔离性能指标首token响应时间有没有要求用户能容忍多少秒评估标准什么算“答对了”谁来定义正确答案兜底策略模型不确定时怎么办拒答还是给相似问题成本上限单次调用预算多少月成本有没有红线这些如果不在动手之前想清楚后面每一步都是盲人摸象。我自己的习惯是写一份“AI项目需求卡”把上面所有项填满再进入技术方案阶段。这不是流程主义而是因为AI项目的变量比传统软件多得多需求不明确后面改动的成本是几何级上升的。另一个关键点AI工程的需求拆解要额外定义“非完美场景”。传统软件需求描述的是“正常流程”但AI系统必须描述“模型胡说八道时怎么办”“用户乱输入时怎么办”“知识库过期时怎么办”。这部分需求不写进文档上了生产环境就会变成事故。2. 技术选型模型、框架、向量库到底怎么捏在一起2.1 模型选择先别着急上私有化大模型模型选型是我见过最容易走极端的一步。一种是“什么贵上什么”直接上最强闭源模型API另一种是“什么省上什么”拿一个7B小模型本地部署结果能力不够项目推倒重来。我个人的选型逻辑分四步。先看场景复杂度。简单分类、抽取、改写类任务中小模型完全够用复杂推理、多轮对话、代码生成必须上大模型。一个简单的判断方法拿3个典型测试用例分别跑小模型和大模型如果小模型在关键用例上达到95%的效果就别花大模型的钱。再看数据敏感性。数据能不能出域如果能优先考虑闭源API成本低、迭代快如果绝对不能出域那就别纠结直接规划私有化部署路线选开源可商用模型。然后看团队能力。如果团队没有懂部署调优的人强行私有化部署会把所有精力耗在工程问题上业务进展为零。这种情况就老老实实用API把核心资源花在业务场景打磨上。最后看成本模型。不要只看API单价要把人力成本、GPU成本、迭代成本全算进去。我之前做过一次测算一个小团队用开源模型私有化部署单次推理成本看似比API低但加上运维人力、GPU闲置率、模型升级成本实际总成本反而高出30%。私有化只有在规模化调用量上来之后才有成本优势。目前国内环境下中文场景我建议优先考虑几档Qwen系列、DeepSeek系列、GLM系列闭源则按预算选。不要盲目追新稳定可用比参数大更重要。2.2 Agent方案和编排框架怎么定Agent是这个领域最热也最容易踩坑的词。很多团队一上来就上LangChain或者这类那类的Agent框架结果出了问题都不知道是哪一层出的。我的看法很直接能用原生代码解决的就不套重框架。先说两个主流框架的特点。LangChain生态全、组件多但抽象层级多调试时调用链特别长LlamaIndex强在文档处理适合做RAG但Agent编排能力偏弱。如果你只是做文档问答、知识库助手LlamaIndex这类文档为中心的方案更省心如果你要做多工具调用、复杂任务拆解我建议你直接手写Agent逻辑把模型调用、工具调用、上下文管理、错误处理这四件事自己做清楚反而比套框架更容易排查问题。Agent架构上新手最容易犯的错是设计得太复杂。什么规划、记忆、反思、多角色协作全往上堆最后系统跑得又慢又贵效果还不稳定。我的经验是先用最简单的ReAct范式跑通即“推理一步调用一个工具观察结果再推理下一步”这个结构能解决80%的任务。只有当简单结构明显不够用时才引入更复杂的规划器、子Agent这类设计。工具注册这块也特别重要。给模型暴露工具时工具描述写得越具体模型用对的概率越高。比如一个“查询订单状态”的工具描述要写成“根据用户提供的订单号字符串精确查询订单当前状态待支付/已支付/已发货/已完成/已取消仅在用户确实提供订单号时调用”而不是简单写“订单查询”。这个细节直接影响工具调用的准确率。2.3 向量库与RAG的关键选择做AI工程基本绕不开RAG。向量库选型我的建议是数据量小、功能简单的项目直接用pgvector就够不用额外引入重组件数据量大、查询并发高的项目再考虑Milvus这类专业向量库。不要为了“架构先进”把一个重向量库塞进最简单的项目里。RAG链路里坑最多的其实是文档解析和切分而不是向量检索。我见过太多项目在Embedding模型、向量库参数上反复调优结果问题出在PDF解析出来是一堆乱码。文档解析做完之后要人工抽检这一步千万别省。文本切分也有讲究。固定长度切分是最省事的但会把语义完整的段落拦腰截断。我的做法是优先按Markdown结构、段落、句号这样的自然边界切分每个chunk控制在300到500个字左右并保留20%的overlap也就是重叠部分防止边界语义丢失。检索时配合BM25关键词检索做混合召回能明显提升命中率。Embedding模型的选择中文场景我建议用基于中文语料训练的模型英文场景另说。别为了省事直接用通用模型硬跑中文召回效果差别很大。日常可以通过几个测试query做召回质量对比肉眼能直接看出差距。3. 提示词工程和Agent工作流的核心细节3.1 提示词的三个层次角色、约束、输出结构很多人以为提示词工程就是“把需求描述清楚”实际远不止如此。我写生产级提示词分三个层次。第一层是角色和任务边界。角色定义不是“你是AI助手”这种废话而是要明确说清楚你的能力范围和行为边界。比如“你是一个电商售后客服只负责处理退款、退货、物流查询三类问题。如果用户问价、问库存、问优惠活动请直接转接人工不要自行回答”。边界定义清楚能大幅减少模型越权输出。第二层是约束条件和输出格式。这是最实用的一层。约束要具体到“只能使用知识库提供的信息回答禁止编造”“如果知识库没有答案请回复‘我暂时无法回答这个问题’”。输出格式可以用JSON结构约束告诉模型每个字段的含义和取值规则这样下游解析几乎不用做容错。对于需要稳定格式的场景few-shot示例比纯文字描述有效得多——直接给两三个符合要求的问答示例模型的输出稳定性立刻提升。第三层是质量兜底机制。我常用两个技巧一是让模型在输出前先做自查给出类似“在最终回答前先判断用户问题是否包含足够信息若信息不足必须反问澄清”的指令二是设置复审指令在模型给出答案后强制它重新分析一遍“我的回答是否严格基于提供的信息”这一步能显著降低幻觉率。有个参数上的经验要分享一下。很多人在所有场景都把temperature设为默认值这是不对的。抽取、分类、工具调用这类确定性任务temperature直接设到0到0.1输出稳定性会大幅提升创意文案、头脑风暴这类任务可以放宽到0.7以上。没有“万金油参数”只有按任务类型调出来的参数。3.2 Agent工作流拆解从单轮到多轮Agent和普通ChatBot的本质区别在于ChatBot只是说话Agent还要做事。一个生产级的Agent工作流我通常拆成六个阶段。第一个阶段是意图识别。这一步不一定要启动大模型很多场景用正则、关键词、意图分类模型提前拦截一部分请求成本低、速度快、确定性高。只有模糊请求才交给大模型处理。第二个阶段是任务规划。把用户请求拆成可执行的子步骤。这里的关键是控制规划粒度拆得太粗执行不了拆得太细浪费token。我的标准是“每一步都能对应到具体工具或知识检索动作”。第三个阶段是工具调用。这一步要处理好参数提取。用户说“帮我查一下上周的订单”模型要能把“上周”换算成日期范围把“订单”映射到订单查询工具的参数。参数的格式校验必须在工程侧做不能依赖模型自觉。第四个阶段是结果汇总。工具返回的数据往往是结构化的、冷冰冰的Agent要把这些数据组织成用户能看懂的答案。第五个阶段是异常处理。工具调用失败、模型输出格式不对、多次循环没有结果都要有预设的降级方案。最省事的降级方案是“重试一次然后回复无法完成”。第六个阶段是记录反馈。把每一次用户问题、模型输出、工具调用结果全部留存这是后续评测和优化最宝贵的数据资产。很多团队忽略这一步导致系统上线后出了质量问题根本无从排查。3.3 多AI协作的实际用法多AI协作是目前非常热的方向但我要泼一盆冷水不要为了“多”而“多”大多数场景单Agent加工具调用已经足够。多Agent适合的是那些需要不同专业视角的复杂任务。我实际跑通的一个场景是商品文案生成。一个Agent做“策划”负责分析商品卖点和目标人群一个Agent做“写作”根据策划输出文案初稿一个Agent做“审核”检查文案是否符合广告法、是否有虚假宣传风险。三个Agent各有专职审核Agent发现问题后打回给写作Agent修改形成一个小闭环。这个案例给我几个经验。第一多Agent协作里的“角色分工”必须通过提示词的强边界来实现不能让两个Agent职责重叠否则会互相干扰。第二Agent之间传递的信息必须是结构化文本比如约束好的JSON而不是自由对话这样流程可控、可回溯。第三一定要给整个协作流程设置最大轮次限制防止Agent之间无限循环对话烧token还出不了结果。4. 模型部署与全链路性能优化4.1 部署形态选型API、私有化、边缘端到底怎么选部署选型我总结为标准答案看数据能不能出域看调用量有多大。数据能出域、调用量中低直接走API。这是最推荐的起步方案零运维成本模型升级也由服务商负责。唯一的风险是供应商锁定应对办法是在代码层做好多供应商兼容把模型调用封装成统一接口随时可以切换。数据不能出域就必须走私有化部署。国内主流的推理引擎是vLLM吞吐量高、兼容性好。硬件方面7B到14B模型量化后一般单张24G显存的卡能跑72B模型需要至少两张80G卡成本要提前算清楚。GPU配置可以按下述逻辑估算一个7B模型在FP16精度下权重约占14GB显存加上KV Cache、CUDA上下文、输入输出token缓存单卡24G勉强够用如果用4bit量化权重降到4GB左右资源占用大幅下降但推理质量会略有损失需要在效果和成本之间做取舍。还有一类场景是边缘端部署比如手机离线运行小模型。这类场景受限于硬件算力只能用极小的量化模型200M到1B之间质量有限一般只适合关键词抽取、意图分类这类轻任务。千万不要在边缘端部署大模型却期待桌面级效果物理规律摆在那里。4.2 推理性能和成本优化实操部署完了性能优化是重点。我先列三个性价比最高的优化手段。第一是流式输出。默认情况下模型生成完整回答才返回用户要等好几秒。改成流式输出后首token延迟能压到几百毫秒用户体验直观提升一大截接口改造成本不高建议必做。第二是Prompt缓存。同一类用户的Prefix通常比较长且重复可以在服务端做前缀缓存命中后能省大量计算。像超长系统提示词、长文档上下文这类重复内容占用的开销很大缓存带来的省幅很可观。第三是语义缓存。对用户的高频重复问题直接把整条答案缓存起来下次命中直接返回完全不走模型。比如“怎么退货”“开发票流程”这类问题命中率往往不低这是降本最直观的手段。成本测算也必须细算。很多人只盯着API单价没算过一次完整的RAG会话实际消耗多少token。我算给你看假设知识库文档塞进去3000个token作为上下文用户问一个问题占100个token模型回复300个token单次请求就是3400个token。月调用10万次按当前主流大模型API价格粗略估算光token费用就在大几千到几万这个量级。如果把上下文减到1500个token成本几乎砍半。所以RAG场景一定要控制上下文长度检索的时候只挑最相关的片段别一股脑全塞进去。4.3 评估与评测闭环没有评测就等于盲人开车AI工程和传统软件最大的差异之一就是“无法从代码正确性来判断系统好坏”。传统软件写一个函数输入输出完全可预期AI系统同样的Prompt这次答对下次可能答错。所以评测闭环是AI工程的生死线。我的建法是项目第一天就从真实数据里抽出500到1000条测试用例标注好标准答案。每次改动Prompt、模型、切分逻辑都在这套集子上跑一遍。测试集要覆盖三类场景正常场景、模糊场景、边界场景。正常场景验证基础能力模糊场景验证理解能力边界场景验证兜底能力。评测指标也要分层。业务指标看任务完成率比如客服场景用户问题是否被成功解决质量指标看答案准确性、相关性和幻觉率成本指标看单次会话token消耗性能指标看首token延迟和完整响应时间。单一指标往往有误导性比如回答变长了相关率可能上升但客户满意度可能下降。人工抽检和自动评测要配合使用。自动评测可以做语义相似度、关键词覆盖、格式校验、内容安全检测人工抽检每周做一次重点看那些模型“看似正确实则错误”的答案也就是所谓“一本正经胡说八道”。这类错误自动评测很难发现必须人来判断。5. AI测试、问题排查与避坑实录5.1 AI测试和传统测试到底差在哪传统测试的前提是确定性同样的输入必须得到同样的输出。AI测试的第一个难题就是不确定性。同一个Prompttemperature不为0时每次输出都不同。这就决定了不能用简单的断言来写测试。我常用的办法有三类模糊断言就是只看输出是否包含关键实体和信息不逐字比对语义相似度断言用模型来判断输出是否与标准答案语义一致人工评审集对重要场景保留人工抽检机制。另一个差别是测试数据的来源。传统测试用例由开发人员编写而AI测试要尽可能从真实用户日志里挖。用户不会按测试数据的方式提问真实问题里各种口语、错别字、上下文缺失、长句碎片应有尽有。拿真实数据做测试集才能逼出系统的真实水平。回归测试也值得多说一句。AI系统改一个Prompt可能影响的是全部场景而不仅仅是当前改的那个。所以我要求团队每次升级模型或改全局Prompt后全量回归测试集必须跑一遍哪怕耗时较长也不能省。测出质量回退就立刻回滚宁可不升级也不要带伤上线。5.2 高频问题排查速查表实战中我整理了一张高频问题速查表每次出问题先对着排查一遍大部分都能解决。问题现象可能原因排查方向与解决办法模型答非所问上下文信息不完整、Prompt任务描述模糊检查传入的上下文内容是否完整优化Prompt明确任务目标与边界知识库答案没被引用检索召回质量差、chunk切得太大检查Embedding是否匹配中文场景检查chunk是否跨段落混合召回是否开启输出JSON格式频繁出错Prompt缺少格式示例、模型能力不足在Prompt中给出JSON示例改用JSON模式降低temperature工具调用参数总是错的工具描述不清、参数约束未定义重写工具描述在Prompt中明确参数取值范围增加参数后校验Agent陷入死循环缺少最大轮次限制、反思逻辑无限触发设置循环上限给反思设置单次机会监控token消耗异常首token延迟太高未开流式输出、前缀未缓存开启SSE流式配置Prompt前缀缓存检查网络链路用户反馈答案和之前不一样模型未固定版本、temperature太高固定模型版本对确定性任务温度调低记录Prompt版本号内容审核漏检安全提示词不够强硬、模型绕过增加内容安全策略多轮校验接入专用安全审核服务对高风险类别做额外拦截排查AI系统问题有一个总原则先看输入再看输出最后看配置。先确认传给模型的上下文和Prompt是否符合预期是不是模型本身跑偏了再确认模型输出后工程侧有没有正确处理最后才怀疑模型配置和参数。不要一上来就怀疑模型能力多数问题的根因其实在工程链路里。5.3 我的几条经验教训最后分享几点用钱和时间换来的教训。第一评估集一定从第一天建。等项目上线再补评估集就晚了因为你已经失去“改动前后对比”的机会根本不知道哪个改动是好是坏。第二不要过度工程。我见过团队在MVP阶段就做多Agent协作、上复杂框架、搞微调结果连基本流程都没跑通。先做最简单的闭环验证业务价值再逐步加复杂度这是AI项目最稳妥的推进方式。第三数据质量大于提示词技巧。再好的Prompt也救不了错误百出的解析结果。花时间把文档解析、数据清洗做到位收益远大于反复优化提示词。第四模型调用层一定要做统一封装。无论是API还是私有化部署模型提供方、模型版本、调用参数都封装成可配置的工程模块。这样做的好处是换模型和升版本时只动配置不动业务代码而且不同模型对比测试的成本大幅降低。第五日志和反馈闭环是企业的隐形资产。每一次用户交互、模型输出、工具调用结果都要结构化埋点。这套数据不仅是排查问题的拐杖更是后续做数据飞轮、评估模型迭代效果的底牌。没有数据AI工程就没有持续进化的可能。做AI工程这件事说到底就是在不确定性里建立确定性。模型输出天生不可控但我们可以通过需求拆解、评测闭环、灰度上线、日志追踪把不可控的部分约束在可控的边界里。我个人的体会是与其追每一个新模型、每一个新框架不如把一个简单的闭环打磨到极致——需求定义清楚评测做扎实部署稳定可观测然后在这个基础上一点点迭代。这套方法论才是“从零开始做AI工程”真正值得沉淀下来的东西。