这两年AI项目热度一直没降圈子里的朋友聊得最多的早就不是哪个模型能力强而是怎么把一个AI想法真正落地成能跑、能维护、能创造价值的工程系统。我自己从最早写几行Prompt调接口到后来完整搭出带Agent、带检索、带评估监控的AI应用中间踩过的坑足够写一本书。这篇就以从零开始做AI工程为主线把一条完整的落地路径拆开讲透给准备入局或者已经在做AI工程化项目的同学一份可复用的参考地图。1. 先别急着选大模型AI项目的需求拆解比技术选型更急很多团队找我聊项目开场白永远是我们现在打算用GPT-4或者我们准备微调一个模型。这种思路最大的问题在于——你连问题都没定义清楚就开始谈解决方案了。AI工程的第一步从来不是选模型而是把需求拆到能动手的程度。1.1 判断这个问题到底需不需要AI我习惯把需求分成四类规则可解、机器学习可解、大模型可解、大模型也不一定解得了。比如订单金额超过1000元自动标记高优先级这是个if-else就搞定的规则。比如识别图片里有没有穿红色衣服的人传统视觉模型就能做好。真正需要大模型介入的是开放式的语言理解和生成——理解用户一段含糊的工单描述并分类或者根据上下文生成一份回复草稿。判断标准很简单如果输入和输出的边界是明确的、规则能穷举的就别上大模型。大模型带来灵活性也带来不可控的成本和延迟。我一个客户做客服工单系统最初想让AI自动回复全部工单拆完发现50%的工单是忘记密码如何退款这类标准化问题用检索匹配加模板回复就能解决根本不需要大模型。最终架构变成规则处理标准化问题大模型处理开放式问题整体成本降了七成。1.2 把模糊愿望翻译成可验收指标需求拆解的第二个要点是把业务方的模糊愿望翻译成技术指标。让AI帮我们提高效率这种话没法开发。你要追问的是处理一个工单的耗时从多少降到多少算成功准确率最低容忍线是多少回答错误的代价是什么我常用的做法是拉一张需求指标表和业务方逐条确认。指标项现状目标值验收方式工单分类准确率人工85%AI达到90%以上抽样标注对比首次回复时长平均40分钟5分钟内线上数据统计人工介入率100%低于40%Agent无法处理时转人工回复兜底率无100%知识库覆盖范围内模拟测试集这张表的价值在于它强制所有人在开工前对齐了什么算成功。我见过太多项目开发做了三个月业务方说这不是我要的本质就是没有在第一天定义清楚验收标准。记住一句话AI工程的需求拆解交付物是一份可测试的行为规范不是一份功能清单。1.3 数据盘点没有验证集的项目注定烂尾需求拆完后下一个现实问题你有没有数据来验证效果这也是从零开始做AI工程最容易翻车的地方。很多团队兴致勃勃选好模型开始调Prompt到了评测阶段才发现根本没有一份标注好的测试集只能凭感觉说好像效果还行。我个人的经验是在写第一行Prompt之前先从过往日志、工单记录、客服聊天记录里收集200到500条真实样本找业务方标好标准答案。这批数据就是黄金评估集后续所有Prompt调整、模型切换、Agent逻辑变更都要在这同一批数据上回归验证。没有评估集的项目后期每个改动都提心吊胆。2. 技术选型模型能力、成本与可控性的三角博弈需求拆清楚之后才轮到技术选型。这个环节最常见的选择题是用闭源API还是开源模型用通用大模型还是微调要不要上Agent框架我的建议是先认清一个核心现实AI工程里没有完美的技术方案只有在你当前约束下最合适的取舍。2.1 模型选择的三个硬指标我不会因为某个模型在排行榜上分数高就选它。实际评估一个模型是否适合生产我只看三件事关键任务上的效果、单位成本、以及可控程度。效果测试要贴合你的真实场景不要拿公开benchmark说事。我会提前构造30到50条刁钻样本覆盖边界情况——比如工单里有错别字、用户情绪激动、问题涉及多个子主题时——然后分别用不同模型跑一遍对比输出质量。这个环节叫小样本人工评估花一天时间就能把候选模型筛掉一大半。成本测算容易被忽略的是隐性成本。除了API调用的token费用还有错误输出导致的人工复核成本、延迟过高带来的用户流失、以及数据出境或隐私合规的风险。我做过一个金融行业的项目因为数据无法出域最终只能选择私有部署的开源模型。闭源模型再好在这个场景下就是不可选项。2.2 Prompt工程与微调的边界线另一个常被问的问题是效果不好是不是应该微调我的回答通常是先别。Prompt工程解决的是模型知道该怎么说微调解决的是模型知道你不知道的知识。绝大多数业务场景尤其是通用理解和生成任务通过高质量Prompt加少量示例就能达到90分的水平。只有当你发现无论如何调整Prompt模型都无法学会某种特定的输出格式或领域行话时才值得考虑微调。微调的成本不只是训练费还有维护负担——每次基座模型升级你都要重新训练和回归。所以我给团队的默认建议是第一版全部基于Prompt工程实现跑通完整链路并积累足够的bad case之后再评估微调的必要性。这个顺序能避免大量无效工作。2.3 框架选型警惕过度工程化市面上Agent框架和编排工具层出不穷但我的建议是第一版尽量少依赖重型框架。框架帮你封装了工具调用、记忆管理、多步编排的细节但同时把调试复杂度和黑盒程度拉高了。从零开始做AI工程关键是先把链路跑通让每个环节都在你的掌控之下。我自己第一版Agent就是纯用代码写的循环加调用整个核心逻辑不到两百行。不用框架的好处是每次出错都看得见根因——是模型判断错了还是工具返回格式没解析好——而不是在框架的抽象层里找一个看不见的bug。等链路稳定了再根据实际需要引入框架来减少重复劳动这时候框架的抽象才是有益的。记住框架是帮你省事的不是帮你背锅的。3. Prompt工程落地把提示词当代码维护而不是当作文写Prompt Engineering这个词从出现起就被包装得太玄了。实际做了几年AI工程我的感受是Prompt本质上是写给模型的行为规范书它应该像代码一样有版本、有注释、有测试用例。这一章我把自己的Prompt工程方法论完整拆一遍。3.1 一个结构化Prompt的分层写法我写Prompt从来不会自由发挥而是固定分成六个区块角色定位、任务描述、执行步骤、约束条件、输入输出格式、示例。以我们客服工单分类的Prompt为例我会这样写[角色] 你是一名有十年经验的客服工单分类专员擅长理解用户的真实诉求。 [任务描述] 给定一条用户提交的工单内容你需要在规定类别中选择最合适的一个分类并输出一个简短的处理建议。 [执行步骤] 1. 判断用户的表面诉求和潜在诉求 2. 结合业务规则排除明显不合理的分类 3. 选择最合适的分类并说明理由 [约束条件] - 只能输出JSON格式不要输出任何其他内容 - 分类必须从给定列表中选择不得创造新类别 - 如果用户表达不满或情绪激动分类仍按内容逻辑判断不要被情绪误导 [输入输出格式] 输入为工单原文输出JSON格式如下 {category: 分类名, confidence: 0到1之间的小数, reason: 不超过30个字的理由, suggestion: 给客服的处理建议} [示例] 输入: 我上周买的东西现在还没到快递单号一直查不到客服电话也打不通气死我了 输出: {category: 物流查询, confidence: 0.95, reason: 用户核心诉求是查询快递进度, suggestion: 安抚用户情绪并核实物流状态}这样写的好处是每个区块各司其职。角色定位决定模型的口吻和判断视角执行步骤把推理链路显式化约束条件划定行为边界输出格式保证后续程序能稳定解析示例则建立了输出的参照系。调试的时候哪个环节出了问题就去改哪个区块而不是整段推倒重来。3.2 示例选择的门道异常样本比黄金样本价值更高很多人写Prompt时喜欢放完美样本——输入清晰、类别明确、输出规范。但实际跑下来你会发现真正影响模型稳定性的是那些边界样本和异常样本。比如我的订单怎么还没发货这句话客户服务团队的标准分类是订单状态查询但线上真实工单里它还混着投诉意图。我在示例里会刻意加入这种歧义样本并在reason字段展示模型应该如何拆解歧义。模型是通过模式识别的它在示例里见过越多边界情况线上遇到诡异输入时就越不容易崩。我还习惯在few-shot示例里混入一两条错误的示范比如输出格式不符合要求被系统纠正的案例。这相当于告诉模型这条路走不通比只说不要做什么有效得多。3.3 关键参数调优温度、top_p和max_tokens的真实影响技术选型阶段大家关心模型落地阶段真正调试的是参数。以下是我在实践中的基准值参数分类/抽取任务生成/创作任务说明temperature0到0.30.7到0.9越低输出越确定分类任务必须低top_p0.1到0.30.8到0.9与temperature二选一调节不要同时猛调max_tokens根据格式上限合理设定按需设定有条件的话用response_format强制约束presence_penalty00.2到0.5生成任务防止重复内容时有用我踩过一个具体的坑一个分类系统模型时不时输出一些额外的话——比如分类完了还在reason里写如果您还有其他问题请随时联系。这导致下游JSON解析偶发失败。后来我做了两件事把temperature调到0.1同时用response_format强制JSON输出。从那以后解析失败率几乎归零。很多看似模型不稳定的问题其实是参数和格式约束没做到位。3.4 Prompt的版本管理与回归测试Prompt改一次生效一次这是最容易翻车的地方。你可能今天为了让一个bad case变好改了半句话结果五个原本正确的case也开始跟着变。所以Prompt必须纳入版本管理和代码走同一套流程。我在项目里维护一个prompts目录每个文件带版本号改动时记录变更原因。每次改动后跑一遍黄金评估集对比前后准确率。这听起来麻烦但有一次正是这套流程救了我——上线前一个优化让准确率从91%掉到87%回归测试立刻发现了问题我们迅速回退了版本避免了线上事故。4. Agent不是调个API工具调用与执行编排的落地细节从单次Prompt到Agent是从模型会说话到模型会做事的跨越。很多人以为Agent就是把Prompt包装一下加上工具调用实际落地时你会发现有无数的细节决定这个Agent是玩具还是生产力工具。这一章我用自己的实践拆开讲。4.1 核心循环模型决策与工具执行的协作机制一个最简Agent的核心循环只有四步接收任务、模型决定下一步、执行工具、返回结果给模型。这个循环看起来简单但每一步都有讲究。第一模型决定下一步时你要给它清晰的工具清单和使用说明。以下是一个订单查询Agent的工具定义{ tools: [ { type: function, function: { name: query_order_status, description: 查询订单当前状态。仅当你需要知道订单物流或处理进度时使用。, parameters: { type: object, properties: { order_id: { type: string, description: 用户提供的订单号形如 ORD20240101XXX } }, required: [order_id] } } }, { type: function, function: { name: refund_order, description: 发起订单退款。注意必须先查询订单状态确认订单尚未发货且需要用户明确同意退款后才可调用。, parameters: { type: object, properties: { order_id: {type: string}, reason: {type: string} }, required: [order_id, reason] } } } ] }工具描述写得细不细直接决定Agent用工具的准确率。我不止一次见过Agent把一个工具用错根因是description写得含糊。比如query_order_status如果你只写查询订单状态模型在用户催退款时可能直接理解成这个工具能退款导致工具误用。工具描述里写明什么时候用、什么时候不能用、有哪些前置条件比调十次Prompt都管用。第二模型返回的工具调用指令是结构化数据但解析时你会遇到格式漂移——说好的JSON偶尔会带上markdown标记、多余换行、甚至注释。所以在执行工具前必须做一个容错解析层尝试标准解析失败后用正则提取关键字段再失败就归入重试分支。4.2 防止Agent跑飞步数上限、决策兜底和人工熔断Agent跑飞是每个AI工程师都经历过的噩梦——模型陷入死循环连续调用同一个工具或者在一个任务上不断发散最终耗尽token还给出个莫名其妙的答案。我从实战里总结了三层防护。第一层是步数上限。我通常把Agent的最大迭代步数设在5到8步超过就直接中断转交人工处理或返回默认兜底话术。不要指望模型能自觉收敛你要在架构上限制它的自由度。第二层是关键动作确认。涉及修改操作——比如发退款、删数据、对外发送消息——必须在工具定义和代码中双重确认。我的实现是Agent执行这类工具前必须先进入一个确认状态将待执行动作和参数呈现给用户得到明确确认后才真正执行。这一条救过我一次一个测试Agent在模拟环境里连续调用了五次退款接口如果这套确认机制没拦着上了生产就是事故。第三层是审计日志。Agent每走一步模型思考内容、工具输入输出、耗时、token消耗都记录到结构化日志里。出了任何问题你能直接回放Agent的决策轨迹而不是面对一个黑盒结果猜。harness engineering里的可观测性核心就是这个。# 简化的Agent循环骨架伪代码 def run_agent(task, tools, max_steps6): messages [{role: system, content: SYSTEM_PROMPT}] messages.append({role: user, content: task}) for step in range(max_steps): response llm_chat(messages, toolstools) # 解析响应如果是需要调用工具 tool_calls extract_tool_calls(response) if not tool_calls: return response.content # 模型直接给出了最终回答 # 执行工具并收集结果 for call in tool_calls: tool_result execute_tool(call[name], call[arguments]) messages.append({ role: tool, tool_call_id: call[id], content: json.dumps(tool_result, ensure_asciiFalse) }) return fallback_answer # 超步数后的兜底4.3 看似聪明的执行策略 vs 真正可靠的确定性优先这是我做Agent工程最重要的心得之一能用确定性逻辑解决的就不要让Agent去临场发挥。很多人喜欢让Agent去决定下一步用什么工具、以什么顺序执行但这在工程上是危险的——模型的判断有随机性同一个任务今天走A路径明天可能走B路径这在生产环境里是不可接受的。我更推荐编排优先、Agent兜底的混合模式。比如一个工单处理流程先用规则判断工单类型标准流程走固定步骤只有当规则判断不了或者遇到异常分支时才交给Agent去做自由决策。这样既保留AI的灵活性又把大部分操作收敛在可控轨道上。很多业务场景根本不需要一个全自由的Agent需要的是一个有明确边界、带了自动兜底的执行器。5. 让模型记住该记住的上下文工程与RAG落地的真实面貌不是所有AI应用都需要RAG但只要涉及私有知识、实时信息或超长文本RAG就有用。问题是RAG的落地效果方差极大——有的项目检索准确率高达95%有的项目明明数据都在知识库里模型却总是答非所问。这一章我讲RAG落地中被反复低估的几个细节。5.1 什么时候触发检索什么时候不检索RAG的第一个决策点是检索触发机制。很多团队的做法是——所有用户问题都先检索再生成。这导致一个典型问题用户只是闲聊一句你好系统也跑到知识库里捞一段不着边际的内容最后生成的回复前言不搭后语。我的做法是在检索前加一道判断当前问题是否需要知识库支持。比如问候、闲聊、对对话本身的追问直接用模型内建能力回答不走检索涉及事实性、即时性、私域知识的问题才进入检索链路。这道判断可以用一个小模型做意图分类也可以用规则加关键词兜底。别小看这一步它直接决定RAG的输出质量和检索成本。5.2 分块策略不是切得越短越好知识库里的文档不能整篇塞进上下文必须切成块但分块策略直接影响检索命中率。无脑按固定字数切块是新手最容易犯的错误——可能会把一句话拦腰截断检索的时候语义就不完整了。我实践下来最稳的分块策略是优先按文档语义结构切——标题、段落、列表天然就是一个语义单元如果文档没有清晰结构才退而求其次用固定窗口但要做重叠前后各重叠一两句话保证上下文衔接。块的大小通常在300到500 token之间切得太细检索噪音大切得太粗则既浪费上下文窗口又降低命中精度。分块之后还有一块是每个块配metadata——来源文档、章节路径、更新时间等。检索时可以按metadata做过滤比如只查2025年之后更新的内容只查售后政策板块。没有metadata的RAG就像没索引的数据库检索效率和准确性都无从谈起。5.3 检索不是靠Embedding一把梭混合检索为什么是常态Embedding向量检索对语义相似很有用——怎么退货和退款流程是什么语义相近就能关联上。但向量检索不等于万能的它处理不好精确匹配的场景订单号、型号、人名这类关键词向量空间里偏差一点就无法命中。所以我在生产里几乎都是用混合检索BM25关键词检索和向量检索并行跑各取TopN再合并去重送入一个重排序模型把最可能相关的几个块挑出来。这个检索-合并-重排的链路能显著提升命中率。重排这一层很容易被省略但它的价值非常明显——第一轮粗筛的TopN里往往混着不少噪音重排序模型能帮你把真正有用的信息压到最前面。我还有一个习惯每次检索至少要保证查得全。宁可多召回几个块让模型去筛也不要只召回一两个块导致标准答案根本不在上下文里。召回率不够生成效果必然打折这是常识。提示RAG里最难的坑不是技术方案而是知识库本身的质量。如果你的知识文档本身就矛盾百出、过时过期RAG做得再好也是垃圾进垃圾出。上线前先花时间做一轮知识库清洗。5.4 上下文的组织方式把检索结果摆盘给模型检索到内容之后怎么放进提示词里也影响生成效果。我的做法是在系统提示词中固定一块参考资料区每次把检索结果以结构化方式放进去并明确标注来源。[参考资料] source iddoc_001 title2025年退换货政策 updated2025-03-10 用户自签收之日起7天内可申请无理由退货商品需保持完好… /source source iddoc_002 title退款到账时间说明 updated2025-04-01 退款审核通过后款项将在1至3个工作日内原路退回… /source [要求] - 优先依据参考资料回答不要使用参考资料之外的信息 - 如果参考资料不足以回答明确说当前知识库中未找到相关信息不要编造 - 回答末尾用依据doc_001的方式标注引用来源把引用来源显式地放进输出规范是抑制幻觉最有效的手段之一。模型知道每一个信息点都能追溯到具体来源在编造时会变得更谨慎。这比单纯说不要编造有用得多。另外上下文长度也要控制。检索回来的块如果超过模型上下文窗口的一半效果反而会下降——关键信息被淹没在大量文字里。我会先做一轮压缩去掉冗余句子只保留和问题强相关的段落。6. 没有评估就没有工程Eval与线上监控的最小闭环在AI工程里感觉效果不错是最危险的一句话。和传统软件不同AI系统的行为是概率性的你必须用数据和指标来管理它。这一章我讲怎么从零搭一套不复杂但真正有用的评估监控体系。6.1 黄金评估集你最重要的资产前面需求拆解时提到过黄金评估集这里展开讲它的用法。我们团队的做法是从真实数据里标出200到500条样本覆盖常见场景、边界场景、异常场景三类。每条样本包含输入、期望分类/输出、备注。评估集的价值在于同一把尺子量所有改动。每次改Prompt、换模型、调检索参数都用同一批样本跑一遍对比关键指标变化。改模型从A换到B指标升了还是降了加了一段Prompt约束哪些case变好哪些case变坏——这些判断都必须靠数据而不是靠翻几条输出凭感觉。维护评估集有个隐藏工作量业务在变、数据分布会漂移评估集要定期在新数据里抽样扩充把线上新出现的bad case补充进去。我一般每两周做一次评估集增量更新保持它的代表性。6.2 分层指标体系从单一准确率到多维度质量只盯一个准确率指标容易失真。我习惯把评估指标分成三层。第一层是任务成功率——比如分类准确率、抽取F1值。第二层是生成质量——忠实度回答是否基于资料而非编造、相关性回答是否针对用户问题、格式合规率输出是否按约定格式。第三层是成本与效率——单次请求的平均延迟、token消耗、低置信度转人工的比例。类别指标衡量内容建议监控阈值任务成功分类准确率、F1核心任务做对没有按业务定义无通用值生成质量忠实度回答是否源于知识库大于90%生成质量格式合规率JSON/限定格式是否严格大于99%成本效率平均延迟端到端响应耗时小于业务可接受值成本效率转人工率Agent无法处理的比例小于40%第三层的忠实度评估我推荐用额外的LLM做裁判打标——让一个独立的模型去判断回答内容是否在给定参考资料中有据可查这比人肉抽查效率高得多。当然裁判模型本身也要偶尔抽样复核避免它自己产生偏见。6.3 从开发到上线的评估闭环没有回滚方案就不上线AI工程上线前必须回答一个问题上新版本时如果效果变差怎么办我们的流程分四步先在黄金评估集上做离线评测通过后部署到预发环境小流量验证同时开启详细日志再按10%、30%、50%的节奏逐步扩量最后全量上线。每一步都盯着核心指标任何一个指标明显下探立即回滚到上一版本。这套流程最大的价值是你永远知道自己手里的版本在什么水平。哪天业务方来问AI现在做到了多少分打开仪表盘就能答而不是支支吾吾说应该还行。6.4 线上日志AI系统唯一的真相来源很多AI项目上线后最缺的不是功能是完善的操作日志。我要求线上系统必须记录每次请求的输入、模型输出、检索命中的知识块、置信度、链路的每一步耗时和token消耗、是否转人工。这些日志有几个用途。第一出问题时能回放全链路快速定位是检索没召回还是模型生成错乱。第二积累新bad case——每周从低置信度和转人工的样本里捞一批人工标注后补充进评估集。第三做成本分析——哪个环节token消耗高哪里可以优化。没有日志的AI系统运营起来就像一个不记项目的团队只能靠记忆办事必然会出乱子。7. 回看整条链路最值得记住的几条实践心得这篇从需求拆解一路写到了监控评估最后聊几句个人感受。做AI工程和做传统软件有一个根本不同传统软件的行为是可预见的AI系统的行为只能被管理。所以AI工程师的核心能力不是写Prompt的文学素养而是把这个不确定性锁进笼子里的工程能力——用评估集量化它用版本管理约束它用监控日志追踪它用人工兜底承接它。我自己的项目初期也走过一段每天调Prompt、每改一下都心惊胆战的弯路。后来踩够了坑慢慢把节奏固定下来先定数据再定基线然后小步迭代——每次只改一个变量必须跑回归上线必须带监控。这套流程看着笨但确实让项目从碰运气变成了可推进。最后分享一个我很受用的小习惯每跑一批样本就把模型输出和人工标准答案一起存下来定期做diff。这个习惯养成了你对系统哪里有瑕疵、改了什么会产生什么影响会越来越有感觉。AI工程没有银弹但只要你让每一次改动都留下痕迹每一份数据都被有效利用项目就一定能从demo长成真正可靠的生产系统。