输出约束校验与重试机制：让 AI 从“口无遮拦”到“照单上菜”

可视化演示

展示AI输出→格式校验→失败重试→成功输出的完整闭环流程，通过环形流程和校验规则面板直观理解Pipeline中的自动纠错机制。

输出约束基础

餐厅里，顾客最怕说“随便”，因为“随便”意味着厨师有无限发挥空间。反过来，你给 AI 下的指令越模糊，它输出的“菜”就越五花八门。有一次我让模型“帮我整理一下客户反馈”，结果一次返回 Markdown 表格、一次返回散文、一次直接甩了三个感叹号。这一切的根源，就是输出约束没立住——AI 不知道你要它“长什么样”。

输出约束，本质上是在请求阶段就圈定模型的输出空间。你告诉模型：“你只能做青椒肉丝，不能做鱼香肉丝，更不能做甜点。”模型作为概率生成器，会顺着你给出的轮廓寻找答案。在实际开发中，最常用的限定手段是结构化格式：要求返回 JSON、指定字段名、限定取值范围。

一个典型的约束实例长这样：“请返回 JSON，包含 name（字符串）、amount（数值）、category（只能取 electronics / grocery / clothing 之一）。”这就相当于在菜单上写死：主菜必须装盘、主料必须在清单内、缺任何一项都不许上桌。约束越早、越具体，后续的校验就越轻松。

菜单立住了，后厨就不再自由发挥。但菜单只是第一步——光有约束还不够，因为模型有时会“看错菜单”。

约束写作技巧

同样一张菜单，写法不同，效果天差地别。你写“牛排七分熟，不要辣”，厨师永远做不错；你写“做点好吃的”，他就开始抽象发挥了。给 AI 写约束，踩的就是这个坑。我见过最失败的约束是“请返回合理的 JSON”——六个字里三个词都是模糊概念。

指令明确是第一要义。与其说“返回 JSON”，不如说“只返回 JSON 对象，键为 status 与 message，不要 Markdown 代码块包裹”。对，连“不要用代码块包裹”都要写出来，因为模型真的会包。其次是示例引导：给一个正确的成品样例，就像给厨师一张实拍菜品图，他照着摆盘就赢了一半。最后是边界框定，主动告诉模型什么不能做：“不要解释、不要寒暄、不要输出无关内容。”

写约束的本质是在做可复现的限定：约束的空间越小、边界越清楚，模型越没有自由发挥的余地。它就像 GPS 终点：精确到门牌号、不能跨省，导航就有极高的把握。

菜单写得越精细，顾客就越满意。但这还只解决了一半问题——因为就算你写清了，AI 偶尔还是会“上错菜”。

校验机制实现

有了菜单，还得有品控。后厨把菜端出来，你总不能闭眼就端给顾客——得先对照菜单检查一遍。AI 流水线同样如此：模型的输出，必须先经过程序化校验，合格才允许进入下游。校验的粒度，可以分为三层，就像品控人员从上到下扫视整道菜。

第一层是结构检查：用 JSON Schema 或字段存在性检查，逐级比对“有没有这些键、嵌套层级对不对”。第二层是类型检查：quantity 就应该是整数，price 就应该是浮点数，字符串混进数字区直接亮红灯。第三层是内容审查：枚举值在不在允许列表里？数值在不在合理区间？情感标签是不是真的只有 positive / negative / neutral 三种？这三层合起来，就是一道完整的“验菜关卡”。

我在项目里通常会封装一个 validate_order() 函数，传入模型输出，返回 ok 与 errors 两个字段。这样上游出错，下游只 “收到一个明确的警报”，而不会被脏数据带崩。

品控把不合格的菜扣下来，接下来就要打发回后厨——这叫“退菜返工”。

失败重试触发

品控扣下菜，总不能把菜倒掉就完事——得送回后厨，告诉厨师“哪道工序出了问题，重新做”。。失败重试的触发逻辑与此完全一致：校验器发现输出不合格，立刻把“不合格原因”打包，连同修正提示一起返回给模型，让它重新生成。

触发重试的前提是错误信息要具体。如果校验器只返回“解析失败”，模型还是一脸懵；如果返回“第二行缺少 order_id 字段，且 total 必须是数值”，模型就能精准修正。我在项目里常把错误字符串直接拼进下一次请求的 prompt 末尾，让“退菜理由”清晰可见。

重试不可能是无限的。必须设次数上限，否则模型一直失败，你的 API 账单就一路走高、服务也卡死不动。设定 max_retries，一旦达到上限，就返回最后一次错误信息，交给人工兜底。这就像餐厅有个规矩：一道菜返工三次还没做好，就换主厨或干脆退钱。

退菜返工很重要，但返工也要讲策略——不是让你疯狂乱试，而是有节奏地重来。

重试策略设计

重试不是“再来一次”这么简单。回想后厨返工时：如果厨师因为系统过载才做错菜，你立刻催他重做，多半还是做错——得让他喘口气。指数退避就是给 AI 的“喘息时间”：第 1 次失败等 1 秒、第 2 次等 2 秒、第 3 次等 4 秒……间隔指数翻倍，有效避开高峰期，也给服务端恢复的时间。

除了等待，重试时还要带上修正指令。把校验器返回的错误消息拼进 prompt，明确告诉模型“上一次错在哪”。这也叫“少样本纠错”——每次失败都在给模型补课。比如：“上次生成的 JSON 缺少 price 字段，请补充后再输出。”这种带反馈的重试，成功率远高于盲目重发。

此外必须设置成本上限：最大轮数、最长等待时间、最大 token 消耗。这三个“封顶值”就像一个保险丝，保证系统在极端情况下不会失控。退一步说，重试的成本曲线是线性甚至指数上升的，不封顶的项目十有八九要被账单教做人。

等到了第 N 轮，后厨已经形成一套完整的返工节奏——这就是闭环的多轮纠错。

多轮纠错流程

把约束、校验、反馈、重试串成一个闭环，就得到了多轮纠错流程。在一个成熟的上菜流水线里，一道菜在品控与后厨之间可能来回好几个回合，每一回合都在逼近最终标准。

多轮纠错的第一步是错误分类：把校验失败的原因分成“语法错误”（JSON 都解析不了）、“结构错误”（缺 key）、“语义错误”（值不在枚举内）。分类后就可以针对性修复——语法错误就强调格式；结构错误就给出模板；语义错误就把合法值列表再贴一次。这就像品控大声报告：“不是菜咸了，是盘子裂了，换个盘子！”

每一轮循环，都是“生成 — 校验 — 反馈 — 再生成”的迭代，直到通过校验或达到终止条件。终止条件像一个总指挥，看三样东西：是否通过校验、是否达到最大轮数、是否超出预算。三个条件任何一个命中，循环立即收工。我在代码里经常写 for attempt in range(max_rounds):，然后配合 break，逻辑清晰又安全。

从菜单、品控到返工，这家“AI 餐厅”终于运转得井井有条。你再也不用担心厨师端上来一盘邪门料理——因为门被焊死了。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""模拟 LLM 输出约束 + 校验 + 重试的迷你流水线。"""import jsonimport timefrom random import random, randint, choice CONSTRAINT_PROMPT = """你是工单分类器。只输出 JSON，不要输出任何解释。JSON 必须包含三个字段:- order_id: 字符串- category: 只能是退款|物流|售后|其他- priority: 只能是高|中|低示例: {"order_id": "A001", "category": "物流", "priority": "中"}""" def fake_llm_generate(order_id, error_hint=""):    """模拟大模型生成结果，30% 概率产生某种缺陷。"""    roll = random()    if roll < 0.30:        return '{"order_id": ' + order_id + ', "category": "未知", "priority": "超高"}'    if roll < 0.10:        return "抱歉，我无法解析该工单。"    if error_hint:        print("      携带纠错信息:", error_hint)    return json.dumps({        "order_id": order_id,        "category": choice(["退款", "物流", "售后", "其他"]),        "priority": choice(["高", "中", "低"])    }, ensure_ascii=False) def validate_order(text):    """三层校验: 解析、类型、枚举范围。返回 (ok, errors)。"""    errors = []    try:        data = json.loads(text)    except json.JSONDecodeError as exc:        return False, ["JSON解析失败: " + str(exc)]    if not isinstance(data, dict):        return False, ["最外层必须是对象"]    if data.get("order_id") is None:        errors.append("缺少 order_id")    if not isinstance(data.get("category"), str):        errors.append("category 必须是字符串")    elif data.get("category") not in ["退款", "物流", "售后", "其他"]:        errors.append("category 不在合法枚举内")    if data.get("priority") not in ["高", "中", "低"]:        errors.append("priority 取值越界")    return (not errors), errors def try_place_order(order_id, max_retries=3):    """带重试的生成入口，内部完成约束+校验+反馈循环。"""    hint = ""    for attempt in range(1, max_retries + 1):        print("第 %d 次生成..." % attempt)        text = fake_llm_generate(order_id, hint)        ok, errors = validate_order(text)        if ok:            print("  校验通过, 结果:", text)            return True, text        hint = "; ".join(errors)        print("  校验失败, 误差:", hint)        time.sleep(0.5)    return False, "达到最大重试次数" if __name__ == "__main__":    ids = ["A001", "B002", "C003"]    success = 0    for order_id in ids:        ok, result = try_place_order(order_id)        if ok:            success += 1        print("---")    print("流水线成功率: %d/%d = %.0f%%" % (success, len(ids), 100.0 * success / len(ids)))

1. CONSTRAINT_PROMPT输出约束菜单：明确要求 JSON 结构、枚举值和示例，相当于给后厨立规矩。
2. fake_llm_generate()模拟大模型生成：用概率注入 JSON 解析失败和枚举越界等缺陷，模拟真实模型的不可控。
3. validate_order()三层校验器：先 json.loads 验证语法，再检查字段类型和枚举范围，输出 (ok, errors)。
4. try_place_order()重试主控：最多 max_retries=3 轮，超限即回退失败，避免死循环。

常见误区

面试题