Prompt 工程实践：让大模型稳定输出结构化结果的六个方法

很多大模型应用不是回答得不好，而是输出格式每次都不一样：这次是 JSON，下次多了几句解释，再下次字段名换了写法，下游一解析就报错。解决办法不是把提示词写得更长，而是把“结构”变成契约：先定好字段、类型和取值范围，再让模型只在契约内填空。本文用一个“会议纪要结构化”的例子，讲六个可以直接落地的方法。

一、先定结构，再写提示

不要只说“输出 JSON”，要把每个字段写死：字段名、类型、是否必填、取值范围。例如会议纪要固定为：meeting_date（日期，格式 YYYY-MM-DD）、topics（字符串数组）、decisions（每条含 decision、owner、due_date 三个字段）、open_issues（字符串数组）。字段名一旦定下来，全文只用这一套写法，禁止同义词替换。枚举值也要写全，例如优先级只能是高、中、低三档，不能出现“比较高”“紧急”等自由写法。

二、用“角色、任务、约束”三段式组织提示词

第一段写角色：你是一名会议纪要整理员，只做信息抽取，不做评价和推测。第二段写任务：从给定的会议记录中抽取上述字段。第三段写约束：只输出 JSON，不要输出解释、不要用 Markdown 代码块包裹、缺失信息用空数组或 null 表示，不要编造。把约束放在最后一段，模型更容易在生成末尾遵守。

三、给一个正确示例，再给一个边界示例

只讲规则不够直观，示例最能定型。正确示例展示完整字段和嵌套结构；边界示例展示“没有待办事项时 open_issues 为空数组、没有明确日期时 due_date 为 null”，而不是让模型自己发明默认值。示例中的字段顺序、命名和标点都要和正式要求完全一致，避免示例本身引入第二套写法。示例不要太长，覆盖关键字段即可，否则模型容易照搬示例内容。

四、把“不许做的事”写进负面清单

模型最常见的漂移都来自没有说清的边界：多写解释、把数字写成带单位的字符串、把日期写成“下周三”、在枚举外自造新值。直接写出负面清单：不输出解释；金额和数量只写数字，不带单位和千分位逗号；日期只用 YYYY-MM-DD；不确定的信息写 null，不猜测。负面清单比正面要求更容易被执行，因为它对应了具体的检查点。

五、校验失败不要重问，要把错误原文还给模型

再好的提示词也不能保证百分之百合规，所以下游必须先校验再使用。校验分四步：能否解析为 JSON；必填字段是否齐全；字段类型是否正确；枚举和日期格式是否在允许范围内。校验失败时，不要直接换一个提示词重跑，而是把“哪一项校验失败、期望是什么、实际是什么”原样发回，让模型只修这一处，最多修两轮。两轮仍失败就走人工兜底或标记为待复核，不要让错误结果悄悄进入业务流程。

六、拆大任务、降随机性

一次让模型同时抽取十几个字段，出错概率会明显上升。把大结构拆成两到三次小任务：先抽主题和决议，再抽待办和负责人，最后合并校验。需要稳定输出时，把温度调低；如果调用方支持，固定随机种子并记录模型版本和提示词版本，同一批样本用同一版本跑，便于复现和对比。

上线前检查清单

准备二十条真实样本，覆盖正常、缺失信息、口语化表达三种情况；统计 JSON 解析成功率、必填字段缺失率、枚举越界次数；把失败样本归类到字段漂移、格式错误、编造信息三类，逐类补一条对应的约束或示例，再跑一轮。解析成功率稳定在可接受水平后，再把结构接入下游；上线后继续抽查，把新出现的漂移写回负面清单，提示词和校验规则要同步更新。