一个周末我接了一个大模型需求让AI根据用户描述自动生成一份工单摘要然后调用内部系统创建记录。模型接入的代码真的只要3行——一个客户端初始化、一个请求方法、一个返回值解析。但等我把它推到测试环境第一周就翻车了明明要求输出JSON模型偶尔夹带一句“好的我来帮您生成”要求只返回low/mid/high三档优先级它给我返回“高因为客户语气比较激动”。最后统计真正干活的调用代码占不到30行剩下200多行全是我用来防它“不听话”的约束输出格式的、校验字段的、重试的、兜底降级的、记日志的。这篇文章我想认真聊聊这件事。大模型本身接入不难难的是它天然会“胡说”而你要在业务里用它的输出就得用工程手段把它的自由限制在你划定的范围内。下面从设计思路、底层原因、落地代码、监控评估、踩坑实录五个部分展开适合那些已经会调API、但还没在实际业务系统里“驯服”过模型的同学参考。1. 先看全局3行代码接进来250行到底在防什么1.1 接入本身确实不难难的是“信任边界”先给你看三行调用长什么样。我用的是最常见的OpenAI兼容接口随便一个支持Chat Completions的模型都能跑from openai import OpenAI client OpenAI(api_keyapi_key, base_urlbase_url) resp client.chat.completions.create(modelqwen-plus, messages[{role: user, content: prompt}]) answer resp.choices[0].message.content三行真的三行。单看“把模型接进程序里”这件事确实没有更高的门槛甚至比接一个普通HTTP接口还简单。但这三行解决的是“把问题发出去、把答案拿回来”解决不了“答案能不能直接用”。你要把模型输出当成业务数据去处理第一反应应该是它凭什么可信传统接口返回的是结构化数据字段、格式、取值范围都在接口文档里程序可以假设它合法。大模型返回的是概率采样出来的字符串它不保证格式、不保证字段存在、不保证值在预期范围内、甚至不保证事实为真。所以模型接入本身只是一个起点真正的工作在于建立一条“信任边界”边界外侧允许模型自由发挥边界内侧必须经过验证与清洗。这个边界就是那250行代码。我个人习惯把防御代码按功能分成四层输出格式约束、业务语义校验、运行节奏控制、失败兜底降级。顺序很重要缺一层都可能让前面几层白做。1.2 250行防御代码的功能拆解我把自己实践下来的一份“防不听话”能力清单放在这里你可以拿它当模板去评估自己的接入方案缺了什么防御层级核心目标典型手段一般代码量输出格式约束让模型输出合法且可解析的结构JSON Mode、函数调用、提示词强约束30-50行业务语义校验让内容符合业务流程的预期Pydantic/自定义校验、枚举值检查、正则60-100行运行节奏控制防止请求失控拖垮系统timeout、max_tokens、重试退避、熔断40-60行失败兜底降级模型不行时服务也不能倒固定文案返回、规则引擎兜底、人工队列40-80行我见过不少项目只做了第一层——让输出变成JSON然后就上生产了。结果呢模型反手给你输出一个格式完全合法、但业务上完全不能用的字段比如日期填“明天”而不是“2025-04-19”优先级填“中高”而不是枚举里的high。格式约束只会让输出“看起来像机器语言”语义校验才能让输出“真正能进业务”。一句话总结3行代码是把模型“请进门”剩下250行是给这尊大佛“划线”告诉它哪些能做、哪些不能做、超出边界怎么处理。2. 模型的“不听话”到底从哪来三个让输出失控的底层机制2.1 解码过程是概率游戏不是逻辑推理想防住模型的“不听话”你得先理解它为什么会“不听话”。大模型生成文本时每一步都在从一个概率分布里采样下一个词而不是在做严格的逻辑推演。温度参数temperature高一点它更随机低一点它更保守但依然有波动。用生活化类比说传统程序像按图纸施工的工程队你画了楼梯它就修楼梯大模型像一个“看多了书但很有主见”的实习生它知道你大概要什么但细节上总会自己发挥哪怕你反复交代过。同一个问题你问两遍第二遍可能就换个说法、换种格式、甚至换个结论。这就是第一个失控来源模型输出不是一个确定性函数。你无法通过“写对请求”来保证“结果正确”只能在程序里对结果做校验。2.2 提示词是“软约束”约束力全看你怎么写提示词是约束模型行为最直接的手段但它的本质是“软约束”。你写“请严格输出JSON”模型大概率会遵守但概率不是100%。模型没有“遵守”和“不遵守”的开关只是倾向于顺着你的指令走。所以提示词的工程含量体现在两个层面一是让模型更容易理解边界少一点“自由创作”的空间二是给模型提供足够多的上下文锚点让它不容易跑偏。比如你让它做分类最好给枚举值和示例你让它抽取字段最好给字段定义和输出样例你让它必须在某个场景下拒绝回答就必须把拒绝条件写得非常具体。需要注意的一点是提示词写得再精密也不能直接当作校验逻辑使用。它是“降低出错的概率”而不是“保证出错的次数为零”。因此优秀的提示词会与代码校验一起使用前者减少出错后者兜住残余错误。2.3 上下文窗口与“记忆漂移”有一次我让模型处理长对话记录指令明明放在系统提示词里结果处理到后半段它愣是把格式忘了开始用自然语言回答。这就是第三个失控来源上下文太长之后模型对早期指令的注意力会稀释就好像开了一个超长的会议主持人开场说“都记到A类”结果讨论到第40分钟发言者早已忘了。这个现象在长文档总结、多轮对话、RAG场景里特别常见。缓解手段包括把指令同时放在系统提示词和每次用户消息里、压缩上下文、将关键规则放在离生成位置更近的地方。另外可以开启一些平台的“重复指令跟随”类参数但这不能完全解决问题最重要的还是让每轮请求的上下文足够精简、关键约束足够显眼。3. 防“不听话”的核心实操从提示词到代码的全链路约束3.1 把系统提示词升级成“行为契约”很多人写system prompt就一句话“你是智能助手请帮助用户解答问题。”然后指望模型能稳定输出业务需要的格式——这是把锅全部甩给概率。想让模型稳定第一条就是把提示词写成一个“行为契约”包含角色、任务、输出规范、约束边界、异常处理策略。我实际使用的系统提示词模板大体长这样示例是一套工单优先级识别任务你是一个客服工单分级引擎。你的唯一任务是根据用户的描述将工单判定为 low / mid / high 三个优先级之一。 输出要求 1. 只输出一个 JSON 对象禁止输出任何额外说明、前后缀或 Markdown 代码块。 2. JSON 结构为 {priority: low|mid|high, reason: 不超过20字的简要理由}。 3. priority 必须取三个枚举值之一reason 使用简体中文。 禁止行为 - 禁止对输入内容做出任何业务决策以外的分析。 - 禁止使用低/中/高这类中文词语替代枚举值。 - 如果用户输入与工单分级无关输出 {priority: low, reason: 非工单内容}。为什么这套写法有用关键不在“严格”“必须”这些强硬的措辞而在给模型提供了足够的锚点角色锚、输出结构锚、枚举锚、异常锚。这四点齐全后模型几乎没有自由发挥的余地它只是在一个很小的选择空间里做决定。3.2 用结构化输出把自由文本关进笼子里如果平台支持JSON模式或结构化输出不要仅仅依靠提示词。让代码层面强制模型输出合法JSON比让模型“自觉”靠谱得多。多数兼容OpenAI接口的平台都支持response_format{type: json_object}或函数调用方式。实际做法是在messages里加上这个参数并配合一段包含“输出JSON对象”字样的提示词两者共同生效。这是一次质的提升模型生成时被限制在JSON语法框架内不太会出现“好的我这就来~”这种混在JSON里的垃圾文本。如果你的平台支持函数调用Function Calling更推荐用函数定义来代替JSON Mode因为函数定义的语义更清晰模型会更自觉地填充参数。定义一个函数create_ticket参数priority是枚举类型、reason是字符串模型生成时就会往这两个参数槽里填内容而不是自由对话。一个附件提示即使开了JSON Mode也仍要校验返回内容。我见过JSON解析成功但内部多了一个意外字段的情况也可能遇到空的content对象。校验逻辑永远是最后一道防线格式约束只是减小校验压力。3.3 输出校验与二次纠错最后一道防线当你拿到模型输出先做三步走第一步用JSON解析器解析失败则重试或降级第二步解析成功后做字段级校验字段缺失、类型不对、枚举值不合法一律按“校验不通过”处理第三步把失败结果重新塞回模型带上具体的报错信息要求它修正。这是什么思路不是让模型“重新自由发挥一次”而是给它当裁判告诉它“你刚才输出的priority是高但合法值只有low/mid/high请重新输出”。模型看到纠错信号后重新生成时通常能自动修正。我在实践中发现二次纠错的成功率还挺可观大概有七八成。下面这段是我常用的代码结构你可以直接拿过去改成自己的import json from pydantic import BaseModel, Field # 1. 定义期望的输出结构 class TicketPriority(BaseModel): priority: str Field(..., pattern^(low|mid|high)$) reason: str Field(..., max_length50) # 2. 请求模型开启JSON Mode def ask_model(prompt, messages): messages.append({role: user, content: prompt}) resp client.chat.completions.create( modelqwen-plus, messagesmessages, response_format{type: json_object}, timeout30, max_tokens200 ) return resp.choices[0].message.content # 3. 校验 重试 降级 def safe_classify(user_text, max_retries2): messages [{role: system, content: SYSTEM_PROMPT}] raw ask_model(user_text, messages) for attempt in range(max_retries): try: obj json.loads(raw) parsed TicketPriority(**obj) return parsed.dict() except Exception as e: # 把校验错误喂回去告诉模型哪里不对 fix_prompt f你上一次的输出未能通过校验错误{e}。请按规则重新输出。 messages.append({role: assistant, content: raw}) raw ask_model(fix_prompt, messages) # 降级返回一个安全的默认值 return {priority: low, reason: 模型输出多次校验失败已降级处理}这30多行代码就是防御体系的核心把“模型可能出错”当成既定事实所有流程都在假设它会错的前提下设计。校验失败不是异常而是正常路径的一部分。3.4 运行时熔断与超时控制受控地失败除了防止模型“说错话”还得防止它“不回答”或“答太慢”。很多人在本地调试时输入很简单模型响应很快可一旦上了生产环境prompt变长、并发上来延迟和失败率立刻暴露。我的建议是在调用处统一设置三个参数timeout连接和等待响应的时间上限我一般设10-30秒看业务容忍度超时直接算失败。max_tokens控制模型最多生成多少token防止它停不下来产生巨额费用。根据输出需要设定工单场景50-100就够。重试次数和退避策略对网络错误连接失败、5xx可以重试2次指数退避但对内容校验失败按前文的三段式处理不要无脑重试同一个请求否则模型会在同样的坑里反复跌倒。另外强烈建议做一层简单的“并发熔断”逻辑当监控到模型接口连续失败或重大延迟时直接切换降级策略——返回固定文案、走规则引擎、投入人工队列。记住一个原则宁可让用户看到一条明确的失败信息也不能让系统无限等待或返回一个看似成功实则错误的假结果。4. 效果评估与监控怎么才能知道模型“没跑偏”4.1 先定义“听话”的度量指标防“不听话”做得再多如果不上指标你永远不知道模型是稳定还是只是“这段时间心情好”。我建议每个接入大模型的项目都要定义一组基础指标团队内部至少看到以下三个数格式通过率原始输出可被正确解析含JSON语法和关键字段检查的比例。约束遵循率解析成功且所有字段值合法枚举、长度、类型的比例。有效服务率返回结果被业务系统真正接受并成功处理的比例。这三个指标从松到严构成了一个漏斗。如果格式通过率高但约束遵循率低说明模型“长了机器的样子还没长机器的脑子”如果约束遵循率高但有效服务率低问题可能不在模型本身而在提示词与真实业务语义之间有偏差。4.2 日志记录与线上回放再往前一步要对每一次调用做完整日志记录。最少都要落四个字段原始请求含prompt版本、模型原始输出、校验结果、最终返回结果。这四个字段缺一不可。为什么要记录版本因为prompt一改模型行为可能全变。不记录版本线上出了诡异问题你根本不知道是哪一批prompt引入的。我习惯在日志上加一个prompt_version字段每调整一次prompt就递增一个版本号后面分析问题非常方便。有了原始输出和校验结果才能做“回放”从日志里导出不合格样本逐条看模型为什么错了是提示词没写清楚还是模型本身抽风。4.3 用自动化测试集跑回归模型接入和传统接口最大的不同在于它有行为漂移。这个月稳定下个月平台更新模型版本输出风格可能就变了。因此要有一套自动化回归测试集在每次调整prompt、切换模型版本、上线新功能时自动跑一遍。构建测试集不复杂挑50-100条代表真实业务的样本标注好期望输出写一个脚本循环调用服务然后比对结果。评判可以分成两个维度结构化字段是否符合预期、理由内容是否合理。第一个维度可以自动计算第二个维度我建议初期用关键词/人工抽检后期可以引入更强的模型做裁判但要注意裁判模型本身也有漂移问题。回归测试的阈值怎么定我的经验是核心字段的准确率低于95%时不要上线。模型不是100%可靠不可怕可怕的是你根本不知道当前版本的它有多少概率会出事。回归测试就是把这个概率测出来让你每次上线前心里先有底。5. 上线后踩过的坑大模型应用常见问题与排查5.1 模型突然开始“复读机”或者输出一段废话现象请求没报错但内容是一段循环重复的话、或者跟问题无关的套话。多数情况下是两个原因一是温度设置太低模型陷入局部重复二是max_tokens设得太小导致模型在生成中途被截断产生语义不完整的输出。排查方法先看日志里的原始输出判断是否是截断还是重复再确认采样参数。解决思路把温度调回0.3左右太低确实容易复读同时把max_tokens放宽到输出上限的1.5倍以上但也要限制总长度防止费用失控。5.2 返回了合法JSON但业务字段不对最阴间的场景格式校验全过了但日期填“明天”、优先级是“高紧急”、金额写成“约123元”。这种问题从代码层面查不到因为语法完全合法。原因在于模型对“值”的精确性天生缺乏感知。它觉得“高紧急”是合理的表达因为它见过类似写法。解决办法有两步第一步在提示词里给出枚举值定义和若干个“错误→正确”的对照示例第二步在代码校验中不仅查类型还要把值映射到业务允许的范围内比如用枚举判断、用正则过滤单位、用日期解析器验证。任何字段只要业务上可枚举就直接枚举校验绝不给模型自由发挥的空间。5.3 提示词越长效果反而越差很多人觉得提示词写得越详细模型越明白。真的不一定。有一次我为了“防跑偏”把系统提示词写到2000字结果模型反而开始遗漏关键格式要求。原因就是上下文变长之后关键指令的反差度变低模型反而无法注意到最重要的约束。经验法则是把提示词拆成“指令区、示例区、禁区”让每段都短而清晰把不重要的背景信息尽量通过RAG按需注入而不是一股脑堆进提示词。系统提示词最好控制在600字以内如果内容确实多把最关键的输出规则在最后再重复一次因为靠近生成位置的指令权重更高。5.4 快速排查速查表症状可能出现的原因优先排查动作输出夹杂自然语言未开JSON Mode / 函数调用检查请求参数response_format与messages是否完整JSON合法但字段缺失提示词没有给字段定义与示例补充字段说明、类型、取值范围、示例枚举值出现中文/复合词提示词未给出严格枚举及禁止项枚举旁增加“只允许以下值”的硬声明延迟突然拉高prompt膨胀或模型服务繁忙看日志中的token数压缩上下文检查熔断配置同样prompt结果不稳定温度过高或上下文过长调低温度精简指令避免长上下文稀释注意力模型复读温度过低或max_tokens截断微调temperature范围检查输出长度上限语义幻觉编造数据模型知识盲区关键事实必须靠检索/数据库注入不依赖模型记忆最后再多说一次很多人接大模型第一反应是研究提示词技巧第二反应才是工程质量。但真正上线跑过业务就会发现稳定的服务体系比花哨的提示词重要得多。我现在的习惯是任何大模型功能接入之前先写降级文案再写校验逻辑最后才调模型。这套顺序倒过来做的项目基本都会在某个深夜被模型的一句“呃好像不太对”教做人。AI应用的宿命不是追求模型永远说对话而是让它在说错时系统依然冷静、得体、不崩。