第一次真正把大模型塞进业务代码的人十有八九会经历这么一幕接口调通了、提示词写得像模像样、本地Demo演示时同事连连点头——然后一上真实数据就翻车。要么答案语气不对要么引用来源驴唇不对马嘴最崩溃的是同一个问题隔五分钟问回答差了十万八千里。这不是模型不行也不是你代码写错了而是你跳过了LLM工作流这个核心环节。我见过太多刚接触大模型开发的程序员把全部精力放在怎么调通一个模型接口上以为只要拿到返回结果就完事了。但真实的大模型应用根本不是一次性的输入-输出而是一连串环环相扣的流程任务怎么拆、模型怎么选、上下文怎么组织、知识怎么进来、工具怎么调用、结果怎么评测、上线之后怎么监控迭代。把这些环节串成一条可控制的流水线才是大模型应用开发真正的样子。这篇文章就是给还没建立起完整工作流概念的小白程序员写的。我会从最底层的认知讲起把LLM工作流拆成可操作的前、中、后三段每个墙点会给具体的参数和判断标准最后分享三个我实际踩过、也看别人反复踩的坑。读完不敢说你能成为架构师但至少拿到一个需求时能画出属于自己的那条流水线而不是对着模型接口发呆。1. 为什么会调模型接口还不算会开发大模型应用1.1 一个看似能用、一压测就崩的典型翻车现场先还原一个很典型的项目场景。某团队要做一个内部知识问答机器人数据是几百篇产品文档和使用手册。第一个版本很简单把文档拼进提示词调一次模型接口把回答返回给前端。Demo阶段效果惊艳演示用的二三十个问题几乎全部答对领导当场拍板要上线。然后真实用户进场了。问题从怎么导出数据变成上个月报表里的字段和这个月怎么对不上用户开始追问细节、要求给出来源、甚至同一句话换个说法再问一次。系统开始频繁出现三类问题一是回答内容对但格式乱该给表格的时候给了一堆文字二是引用的文档片段和结论对不上明显是检索到了但没读进去三是一旦超出文档范围模型就开始自己编编得还挺像那么回事。这个翻车现场的根源不是某一行代码写错了而是整个开发过程只完成了工作流里的一个节点调模型。要做一个能用的大模型应用你得让数据进来、上下文组织、结果生成、质量判断、异常回退这些环节协同起来缺一个都会在上线前排雷。1.2 概率输出与确定性工程之间的范式鸿沟传统程序员的思维里一个函数输入固定参数输出就应该固定。你不光可以单元测试还能断言某个分支永远不会走到。这套思维在大模型应用里首先就失效了——大模型的输出本质是概率采样同一个Prompt问两遍结果可能不完全一样温度调高之后差异更明显。这就带来三个层面的转变。编程范式变了以前靠if/else控制逻辑分支现在靠提示词和上下文去引导模型行为以前函数返回的是结构化的确定数据现在返回的是自然语言文本你得自己再解析成结构化数据。调试范式变了以前报错会给你堆栈信息现在报错是模型一本正经地胡说八道不抛异常、不报错误只会自信地给出一个错误答案。你要排查的不是代码而是上下文里到底哪块信息把它带偏了。测试范式变了以前断言等于某个值现在没有办法断言回答正确只能规定回答必须来自给定文档置信度低于某个阈值就拒答。测试从精确匹配变成了按标准打分。我常跟刚入门的同事打一个比方传统开发像是在搭积木每一块都是确定形状大模型开发像是在做菜食材、火候、调料都得管你做出来的菜不能保证和上次一模一样但必须保证这道菜是合格的。工作流就是那套保证合格的流程规范。1.3 工作流的本质把不可控约束成可控大模型本身是一个高度不可控的组件但它擅长的事情非常明确理解自然语言、生成自然语言、进行一定程度的推理。工作流要做的事情就是把这个擅长但不稳定的组件放在一个尽量稳定的框架里。具体来说一个完整的LLM工作流一般围绕三个问题展开第一模型什么时候该出场什么时候不该出场。比如简单分类、关键词匹配、规则判断没必要让模型参与只有需要理解语言、梳理逻辑的时候再调用。第二模型出场的时候怎么给它最好的上下文。上下文包括任务说明、背景知识、历史对话、检索结果、工具返回的数据。上下文组织不好换更强的模型也救不回来。第三模型给出结果之后怎么判断结果能不能用。常见做法是加校验层格式校验、关键词校验、引用来源校验、置信度评分不合格就走重试或拒答分支。这套约束机制合在一起才是LLM工作流的真正含义不是某一个框架或工具而是一套把不可控组件的风险逐层降低的设计思路。理解了这一点后面所有的环节都是在给这条主线添砖加瓦。2. 大模型应用工作流到底包含哪几个环节2.1 一条主链从需求到上线的八个环节我自己习惯把LLM应用的工作流拆成八个环节它们从需求出发一直到上线运维构成一条完整的主链。你不用每一步都做得尽善尽美但至少要知道自己处于哪个环节、下一步该往哪走。这八个环节分别是任务定义明确应用要解决的问题、输入输出边界可行性分析判断这个问题适不适合用大模型解决还是规则就能搞定模型选型根据任务复杂度、成本、延迟选合适模型上下文构建设计系统提示词、组织对话状态、注入业务知识知识接入内部文档通过检索接入外部能力通过工具接入应用编排把上面的环节串成流程处理异常和回退评测回归建立测试集和评分标准每次改动都跑一遍上线监控跟踪成本、延迟、结果质量形成迭代闭环很多人一上来就从第三个环节开始闷头接模型、写提示词前面没想清楚后面也没验证结果自然不稳定。八个环节里三和四做得最多但决定成败的往往是一、二、七、八。2.2 每个环节要交付什么产物工作流之所以叫工作流是因为每个环节都应该有明确的产物。我列个表把每个环节的输入、核心动作和输出讲清楚方便你对照检查自己当前卡在哪环节核心动作输出产物常见误区任务定义梳理用户问题类型与回答边界需求清单、边界说明把需求写得太宽泛可行性分析对比规则方案与大模型方案技术选型结论大材小用或硬造需求模型选型用测试样例跑多模型对比模型对比记录直接选最强最贵上下文构建写提示词模板并纳入版本管理Prompt模板、示例集提示词一次写死不改知识接入清洗文档、建索引、接工具知识库索引、工具清单文档不做清洗直接灌应用编排串接流程、处理异常回退流程代码、错误处理逻辑所有逻辑写在提示词里评测回归构造测试集、定评分标准测试集、评测报告靠感觉判断好不好上线监控埋点、看日志、设告警监控面板、迭代计划上线后就不管了我特别想强调任务定义和可行性分析这两个环节。它们在很多团队里被压缩成一句做个机器人就带过了但等后面模型怎么调都不对劲的时候回头一看往往是任务边界没划清楚。边界不清后面所有环节都在给这个模糊埋单。2.3 不同应用类型的工作流侧重差异不是所有LLM应用都要把八个环节做同样重。根据应用类型工作流的重点会明显偏移。我拿三类最常见的应用举例第一类是对话助手比如客服机器人、销售助手。它的重点在上下文构建和对话状态管理核心难点是长期记忆和轮次控制模型回答得好不好反而次要一些——真正难的是多轮对话里别把上一轮的信息用错。第二类是知识问答也就是RAG应用。它的重点在知识接入文档清洗、切分、检索质量直接决定了下限。我在后面第四章会专门讲这里先说结论这类应用80%的问题出在知识根本没能被正确召回而不是模型生成能力不够。第三类是任务执行Agent比如数据分析助手、自动报表工具。它的重点在应用编排和工具调用要给模型明确的可选步骤、强制校验每一步的结果还要设定最大执行步数防止失控。工作流不是一条笔直的轨道而是一套可以按应用类型调整重心的框架。你先知道自己属于哪类应用再分配精力才不会在次要环节上死磕。3. 工作流前段任务拆解、模型选型与上下文设计3.1 先回答三个问题再写代码接到任何一个大模型应用需求我都先逼自己回答三个问题写完答案才允许碰代码。第一个问题这个任务的边界是什么具体说哪些输入是应用必须处理的哪些输入应该明确拒答。我见过很多机器人翻车不是因为不会答而是因为什么都敢接。边界不清的下场就是用户问一句你觉得我该不该辞职客服机器人真给你分析上了。在系统提示词里写清楚本助手仅回答与产品使用相关问题其他问题请转人工不是一句空话它是在给整个工作流划安全线。第二个问题知识从哪里来是内部文档、业务数据库、还是实时网络这个问题的答案直接决定了要不要做RAG、要不要接工具。如果答案是知识都在文档里那你第一步不是写提示词而是把文档整理干净、建立索引。如果答案是知识都在数据库里那你需要的是工具调用让模型去查库。第三个问题需要模型执行哪些工具动作比如查订单、发通知、改配置。这里要额外想清楚权限边界哪些动作允许模型直接执行哪些必须人工确认。这三个问题回答完任务的形状基本就出来了。后面所有技术选型都是顺着这三个答案往下走的。3.2 模型选型的三条判断标准很多小白一上来就问哪个模型最强然后选了参数最大、价格最贵的那个。但在真实工作流里模型选型从来不是选最强而是选刚刚好。我一般按三条标准来判断第一条是能力匹配度。把任务里最难的20个问题攒成一个测试集分别用不同模型跑一遍看谁的输出最稳定。不是所有任务都需要最强推理能力比如简单的意图分类、文本改写一个轻量模型就能达到九成效果没必要浪费成本。第二条是成本约束。大模型应用的成本不是按次算的是按Token算的。一个高强模型处理同样的请求成本可能是轻量模型的十倍。日活上千之后这个差距直接决定你能不能赚钱、项目能不能活下去。第三条是延迟体验。交互场景要求首字延迟低异步批处理场景对延迟不敏感。如果应用是给用户实时对话用的模型推理太慢再聪明的回答也没意义。这里我特别推荐一个技巧模型分层。同一个应用里不同难度的请求走不同的模型简单问题走轻量模型复杂推理才升级到强模型。这就是常说的模型路由。起步阶段可以先写死规则比如根据问题长度或关键词分流后面再逐步做得精细。3.3 系统提示词与Few-shot的工程化写法上下文设计里最容易被低估的是系统提示词。很多人写提示词跟写作文一样想到哪写到哪从不版本管理改一次就覆盖一次。我的做法是把它当成正式代码来维护。一个稳定的系统提示词一般包含三块角色与边界、任务与流程、输出格式要求。我用一个客服场景示例来展示基本结构你是某产品的客服助手。 【任务目标】 回答用户关于产品使用、计费、故障排查的问题。 【边界规则】 - 只回答与产品相关的问题无关问题请用户联系人工客服 - 不确定答案时明确说我无法确认禁止编造 - 如果用户情绪激烈先道歉并引导至人工渠道 【回答格式】 - 结论在前解释在后 - 需要步骤时使用编号列表 - 涉及账单相关问题必须提示用户核对订单号 【参考知识】 仅可使用如下文档片段回答不得使用文档外的信息 {context}第三部分的参考知识注入在RAG应用里是动态替换的记住不要把整篇文章都塞进去而是只注入检索回来的相关片段。Few-shot示例也是同样的道理。不要简单堆例子每个示例都要覆盖一种典型的难点输入比如一个边界问题、一个多轮指代问题、一个需要拒答的问题。示例集和提示词一起放在Git里管理每次更新都要跑一遍评测集确保没把原来的能力改没了。还要提一下采样参数。大多数场景下温度设置在0.2到0.5之间比较稳追求事实性就偏低需要创意写作才调高。不要给用户开放调节温度的入口那是给开发调试用的小门不是给用户玩的门。4. 工作流中段检索增强与外部工具怎么接才稳4.1 RAG不是简单塞文档完整链路有五步RAG检索增强生成大概是LLM工作流里被误解最深的一个词。不少人以为把PDF往系统里一扔模型就能自动学会文档里的知识。实际根本不是这样。RAG的完整链路至少包含五步文档解析、内容清洗、切片分块、向量化索引、检索召回。每一步做不好最后生成的答案都会出问题。文档解析是最容易被忽视的。PDF不转文字、表格直接丢进文本、扫描件不做OCR这些情况会让后续所有环节拿到一堆乱码。内容清洗要处理掉页眉页脚、重复正文、目录章节等噪声否则检索的时候它们会干扰相关性判断。切片分块是最影响召回效果的一步。切得太小块语义不完整答案被拦腰截断切得太大块检索噪声多上下文塞爆。我常用的经验值是普通叙述文本按400到600个字符切一块块与块之间保留80到120个字符的重复确保切在句子边界而不是句子中间。遇到有明显标题层级的长文档优先按章节标题切把目录章节这样的结构边界当作天然的切片点。向量化索引和检索召回是最后一步但前面的准备决定了它们的上限。整个RAG的质量模型是木桶效应解析和切分是短板后面的向量化做得再好也补不回来。4.2 切分参数怎么定召回效果怎么验证这里分享一个我自己常用的切分验证方法先挑20个有代表性的问题每个问题在文档里找到标准答案所在的段落然后检查不同切分参数下这些标准段落能不能被成功召回。如果答案段落经常被切碎、跨了两个块就需要把chunk调大一些如果召回结果里夹着大量无关片段、答案反而被挤到后面就需要把chunk调小或者改成按章节结构切。你可以把切分参数当成一个旋钮来回试几轮看召回率从多少升到多少而不是凭感觉拍脑袋。具体操作上还有一个容易被忽视的点query和文档的语言鸿沟。用户问的是白话口语文档写的是书面技术词直接做向量检索相关性会偏低。解决办法是混合检索同时跑关键词匹配和向量匹配把两组结果合并去重后再做重排。关键词匹配保证用户的原话能命中向量匹配保证语义相近的文档能进来最后用一个重排阶段把最相关的几条顶到前面。召回验证阶段我习惯打印只看召回不看生成的调试输出把一次问答中最终拿到的三条文档片段完整打出来再看模型有没有忠实使用它们。九成情况下你会发现不是模型不会答是喂给它的文档片段本身就不对。4.3 工具调用和Agent的边界什么任务才值得上规划RAG解决的是知识从文档里来的问题。还有一类任务知识不在文档里而在系统里——查订单、调接口、写数据库这时候需要的是工具调用。工具调用的第一步是工具定义。别急着让模型自由发挥先把每个工具的能做什么、不能做什么、参数是什么、返回是什么描述清楚。描述写得越具体模型选对工具的概率越高。我见过太多工具描述写一句查询用户信息模型根本分不清该传用户ID还是订单号。接下来说Agent。Agent比工具调用多了一个规划环节模型根据目标自己拆解步骤、决定先调用哪个工具、根据中间结果调整下一步。听起来很强大但代价是行为不可预测、成本不可控。我的建议很简单能用固定流程跑通的不要上Agent。比如查A→查B→汇总C这种顺序固定的任务直接写代码编排就行同时调用三次工具成功率100%成本还低。只有当步骤顺序本身需要根据中间结果动态决策时才值得引入Agent式规划。如果真要用Agent一定要给它装上安全带最大步数限制、每步工具的调用白名单、单次调用的Token上限、超时降级到普通问答或人工介入。没有这些约束的Agent上线之后每一分钟都在烧钱还会做出你完全意想不到的操作。5. 工作流后段评测、监控与迭代闭环5.1 没有评测体系之前一切上线都是碰运气我见过很多团队改提示词全靠我觉得这样更好上线之后好坏全靠用户骂不骂。这是大模型应用开发里最致命的一个习惯。因为模型是概率性的没有评测体系你根本分不清这周回答变好是改对了、还是运气好下周变差也不知道是哪次改动惹的祸。我在团队里一直强调在写第一版应用的同时就要把评测集合建起来。评测集不需要一开始就很大50到100条高质量测试用例就够用了。关键是要覆盖典型问题、边界问题、容易幻觉的问题这三类。然后把应用跑一遍把输出结果存档每次改动后再跑一遍对比差异。这一套流程看起来繁琐但它是迭代和瞎调的分水岭。有了评测基线你才能放心大胆地做实验这个提示词版本不行回滚到上一个新加的重排策略让召回率掉了3%那就检查是不是策略参数不对。5.2 建立最小可用回归集真值、指标、阈值评测集要发挥作用还得配上明确的指标和阈值。我把指标分成三类来说。客观题类有标准答案直接对比正确性。比如用户问退款规则是否引用到了正确的文档条目。这类题量不需要多但答案要绝对可靠用来做硬性回归。主观质量类答案没有唯一标准打分评估。常见维度是相关性回答是否切题、忠实度是否基于给定上下文而非自由发挥、完整度该回答的点都回答了吗。打分可以用人评起步阶段也可以用另一个更强的模型来评但要注意标准要稳定别今天宽松明天严格。安全拒答类最容易被人忽略。比如超出范围的问题模型应该拒答而不是硬答。把这部分单独列为负向用例一旦模型在这类问题上开始自由发挥说明上下文约束松了要立刻检查。阈值方面我给一个粗糙但能落地的参考主观质量类平均分不低于4分5分制客观题正确率不低于95%拒答率控制在5%到15%之间。低于5%说明边界画得太松高于15%说明该答的都被拦了。这些数字不是金科玉律但可以作为你建立自己基线的起点。5.3 上线之后盯哪几个指标评测解决的是每次改动是否变好的问题上线之后还需要实时监控。至少要看五个指标请求量级、Token消耗、平均延迟、拒答率、用户反馈。Token消耗是最容易被忽略的隐性成本炸弹。一次问答如果检索注入太长加上多轮历史平均每次请求可能消耗几千甚至上万Token日活一万就是几十万Token成本按月计很可观。给每次请求做Token埋点按天聚合设置成本告警是第一优先级的事情。延迟要盯分位数而不是平均值p95才有意义。平均值好看但p95慢意味着有5%的用户体验很差该优化的是检索耗时和模型推理并发。拒答率偏低说明模型开始瞎答了偏高说明业务范围收得太紧。这个指标要结合具体业务去设定警戒线。用户反馈埋点则要能区分回答错误和应用故障两者处理路径完全不同。有了这些数据你的工作流才算真正闭环上线——监控——发现异常——补评测用例——修改策略——回归测试——再上线。这个循环转起来应用质量才能稳步往上走。6. 小白最容易翻车的三个工作流节点踩坑实录6.1 坑一提示词里堆指令不如把约束放到数据层某团队做一个客服机器人业务方给了20多条规则要求写进提示词包括回答要礼貌不能承诺赔偿遇到发票问题先查订单状态用户骂人要安抚……开发把它们一股脑全写进系统提示词里。结果发现模型经常顾此失彼记住这条忘了那条回答风格一天一个样。这其实是把程序逻辑错误地塞进了语言指令里。提示词越长各条规则之间的优先级越模糊模型只能靠概率去猜你要它重点遵守哪一条。正确做法是把可以通过代码强制的规则拿出来比如查订单状态不是靠模型自觉而是靠工作流里先调用订单查询工具、拿到结果再拼进上下文承诺赔偿这类高风险动作直接在输出后校验检测到赔偿类关键词就拦截转人工。我现在的原则是能用数据结构表达的不用自然语言表达能在代码层强制校验的不指望模型自律。提示词只放模型必须理解才能完成任务的指令其余的交给工作流。6.2 坑二RAG检索每一步都做了但答案还是错的排查过一次整条链都做了但效果很差的案例文档清洗了、切分做了、向量库建好了A同学跑出来的答案还是驴唇不对马嘴。后来我们打开只看召回的调试模式发现召回的三个文档片段里有两个是并列标题下的内容关键词高度匹配语义却完全不相关。这个问题在知识库里特别典型。解决方法分两步第一步把切分逻辑从按字符固定切改成按文档结构语义切让每一块都对应一个完整的小主题第二步检索召回后加一轮重排把关键词命中但语义无关的结果压下去。混合检索加语义重排是当前做RAG应用性价比最高的组合。另外还有一个底层问题容易被忽略召回源里本身没有正确答案时再怎么调参数都是白搭。排查顺序应该是——先人工确认答案在文档里存不存在再查能不能被召回最后才查模型生成环节。6.3 坑三Agent能不用就不用用了就给安全带某项目做一个数据分析助手希望用户用自然语言提问系统自动生成图表。开发为了显得智能直接上了Agent方案让模型自己决定查哪个表、做哪种分析。结果演示时模型连续调用了十几次工具有一次还试着把整张订单表拉出来做聚合分析Token烧掉一大半回答还超时了。Agent的失控风险来自它把规划权交给了模型。模型每走一步都要重新读一遍上下文、重新决策一次成本和不确定性指数级上升。我的经验是能给模型画好路径的就画好固定步骤就写死必须动态规划的场景也要把步数限制在五步以内每一步的工具结果都要校验格式超时就走兜底回复。把Agent用在它该用的地方——比如多条件模糊检索、跨数据源自行联动这类路径不确定的任务——上限确实高但前提是你已经把护栏装齐了。没有护栏的Agent就像没绑安全绳的攀岩看起来刺激摔下来也狠。最后补一句实实在在的经验做LLM工作流跟写传统业务代码最大的不同是会逼着你把每个环节都变成可验证、可回滚的部件。我自己带过很多同学最明显的分水岭就是有人把应用当成一次模型调用有人把应用当成一条可以复盘的流水线。后者哪怕第一个版本做得很糙迭代空间也是无限的。如果你现在还是零基础我建议不要一上来就搭一个什么都要的Agent平台。挑一个最小的真实场景——哪怕是做一个内部工具的文档问答——把任务定义、上下文构建、检索召回、基础评测、上线监控这条最小闭环完整跑一遍比看十篇教程都管用。等你跑通了自然就理解哪些环节要加缓存、哪些环节要换模型、哪些环节要拆成微服务了。工作流这东西看着是流程其实全是实战喂出来的判断力。