企业官网建设流程全解析

一个周末我接了一个大模型需求：让AI根据用户描述自动生成一份工单摘要，然后调用内部系统创建记录。模型接入的代码真的只要3行——一个客户端初始化、一个请求方法、一个返回值解析。但等我把它推到测试环境，第一周就翻车了：明明要求输出JSON，模型偶尔夹带一句“好的，我来帮您生成”；要求只返回low/mid/high三档优先级，它给我返回“高（因为客户语气比较激动）”。最后统计，真正干活的调用代码占不到30行，剩下200多行全是我用来防它“不听话”的：约束输出格式的、校验字段的、重试的、兜底降级的、记日志的。

这篇文章我想认真聊聊这件事。大模型本身接入不难，难的是它天然会“胡说”，而你要在业务里用它的输出，就得用工程手段把它的自由限制在你划定的范围内。下面从设计思路、底层原因、落地代码、监控评估、踩坑实录五个部分展开，适合那些已经会调API、但还没在实际业务系统里“驯服”过模型的同学参考。

1. 先看全局：3行代码接进来，250行到底在防什么

1.1 接入本身确实不难，难的是“信任边界”

先给你看三行调用长什么样。我用的是最常见的OpenAI兼容接口，随便一个支持Chat Completions的模型都能跑：

from openai import OpenAI client = OpenAI(api_key=api_key, base_url=base_url) resp = client.chat.completions.create(model="qwen-plus", messages=[{"role": "user", "content": prompt}]) answer = resp.choices[0].message.content

三行，真的三行。单看“把模型接进程序里”这件事，确实没有更高的门槛，甚至比接一个普通HTTP接口还简单。但这三行解决的是“把问题发出去、把答案拿回来”，解决不了“答案能不能直接用”。

你要把模型输出当成业务数据去处理，第一反应应该是：它凭什么可信？

传统接口返回的是结构化数据，字段、格式、取值范围都在接口文档里，程序可以假设它合法。大模型返回的是概率采样出来的字符串，它不保证格式、不保证字段存在、不保证值在预期范围内、甚至不保证事实为真。所以模型接入本身只是一个起点，真正的工作在于建立一条“信任边界”：边界外侧允许模型自由发挥，边界内侧必须经过验证与清洗。

这个边界就是那250行代码。我个人习惯把防御代码按功能分成四层：输出格式约束、业务语义校验、运行节奏控制、失败兜底降级。顺序很重要，缺一层都可能让前面几层白做。

1.2 250行防御代码的功能拆解

我把自己实践下来的一份“防不听话”能力清单放在这里，你可以拿它当模板去评估自己的接入方案缺了什么：

我见过不少项目只做了第一层——让输出变成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_length=50) # 2. 请求模型（开启JSON Mode） def ask_model(prompt, messages): messages.append({"role": "user", "content": prompt}) resp = client.chat.completions.create( model="qwen-plus", messages=messages, response_format={"type": "json_object"}, timeout=30, max_tokens=200 ) return resp.choices[0].message.content # 3. 校验 + 重试 + 降级 def safe_classify(user_text, max_retries=2): 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 快速排查速查表

最后再多说一次：很多人接大模型，第一反应是研究提示词技巧，第二反应才是工程质量。但真正上线跑过业务就会发现，稳定的服务体系比花哨的提示词重要得多。我现在的习惯是，任何大模型功能接入之前，先写降级文案，再写校验逻辑，最后才调模型。这套顺序倒过来做的项目，基本都会在某个深夜被模型的一句“呃，好像不太对”教做人。AI应用的宿命不是追求模型永远说对话，而是让它在说错时，系统依然冷静、得体、不崩。