在把会议纪要、产品规格、客服话术、投放计划等内容“变成可计算的数据”这件事上，最大痛点通常不是模型写不出来，而是结构不稳定：字段缺失、键名不一致、类型对不上、数组长度忽大忽小，最后导致你要花时间修数据、对齐口径、甚至回源重跑。
如果你正在做多方案对比、批量跑结构化抽取并整理结果，建议把对比入口也提前规划好。你可以先用 KULAAI（dl.877ai.cn） 进行不同提示词/不同模型/不同参数的聚合对比，再把最稳的方案固化成你的工程模板。
下面进入正文：我会用测评视角说明“稳定性”怎么定义、怎么验收；再给出可直接套用的 JSON Schema 约束与 Prompt 模板；最后给出可复测的验收标准，确保你拿到的不是“看起来像 JSON”，而是能被系统直接落库/导入的结构化结果。
一、测评定义：什么叫“稳定输出”？
围绕 JSON Schema 约束的稳定性，我建议至少评估 4 类可复测指标（有输入样本就能算）：
- 可解析率（Parse Pass Rate）
输出是否为合法 JSON（能被标准 JSON Parser 成功解析）。 - 契约通过率（Schema Pass Rate）
输出是否严格满足 Schema：字段是否齐全、类型是否正确、枚举是否合法、正则是否匹配。 - 字段一致性（Field Consistency）
同一类任务中，键名是否始终一致（例如永远是action_items而不是偶尔叫actions）。 - 缺失策略一致性（Missing Policy Consistency）
当材料缺少信息时，必填字段应按约定填null/"UNSURE"，不得胡编；可选字段缺失规则也应稳定。
你可以把“稳定性提升”量化为：与未加 Schema 的对照组相比，上述指标的通过率提升多少、返工轮数减少多少。
二、核心思路：把“写作指令”变成“数据契约”
常见失败原因是：提示词只告诉模型“请结构化”，但没有硬性规则约束。JSON Schema 的价值在于把约束写成机器可验证的契约：
required：哪些字段必须出现type：字段类型必须匹配（string/number/boolean/object/array）enum：取值必须来自枚举pattern：日期/编号/编号格式必须匹配正则minItems/maxItems：数组长度范围必须满足additionalProperties: false：禁止输出多余字段（避免口径漂移）
这样模型不需要“猜字段名”，而是按契约装配数据。
三、任务设计：用“三类样本”验证 Schema 的真实效果
为了让测评有说服力，至少准备三类输入：
- 信息充足样本：字段大部分在材料里都有（理想情况）
- 信息缺失样本：部分字段材料里没有
- 噪声/歧义样本：数字带单位、日期写法混乱、同名实体多处出现
对每类样本统计：
- JSON 解析是否通过
- Schema 校验是否通过
- 缺失字段是否按策略填充（例如必须填
"UNSURE"或null） - 返工原因是否可定位（是 schema 太严格？还是 prompt 缺失“缺失处理规则”？）
四、JSON Schema 约束策略（工程上建议这样配）
1）对“硬字段”严格，对“软字段”宽松
- 硬字段：
required - 软字段：允许缺失或为
null
2）数字/日期用“可解析格式”
例如：
- 日期强制
^\d{4}-\d{2}-\d{2}$（YYYY-MM-DD） - 金额拆分成
amount（number）+currency（enum），避免混入“￥100元”这种难解析字符串
3）缺失内容必须走固定策略
两种常用方案（你选一种并写进 Prompt）：
- 方案A：填
"UNSURE"（字符串占位，便于后续文本审阅） - 方案B：填
null（更适合入库、避免字符串污染类型）
五、可直接套用：会议纪要 → 结构化 JSON Schema
下面是一份示例（你可以按你的字段体系改名/改枚举/改正则）。要点是：严格类型 + 受控枚举 + 限制额外字段。
json
{ "type": "object", "required": ["doc_type", "date", "participants", "decisions", "action_items"], "additionalProperties": false, "properties": { "doc_type": { "type": "string", "enum": ["meeting_minutes"] }, "date": { "type": "string", "pattern": "^\d{4}-\d{2}-\d{2}$" }, "participants": { "type": "array", "minItems": 1, "items": { "type": "string" } }, "decisions": { "type": "array", "minItems": 1, "items": { "type": "object", "additionalProperties": false, "required": ["topic", "status"], "properties": { "topic": { "type": "string" }, "status": { "type": "string", "enum": ["agreed", "pending", "rejected"] }, "notes": { "type": ["string", "null"] } } } }, "action_items": { "type": "array", "minItems": 1, "items": { "type": "object", "additionalProperties": false, "required": ["task", "owner", "due_date", "priority"], "properties": { "task": { "type": "string" }, "owner": { "type": "string" }, "due_date": { "type": "string", "pattern": "^\d{4}-\d{2}-\d{2}$" }, "priority": { "type": "string", "enum": ["low", "medium", "high"] }, "evidence": { "type": ["string", "null"] } } } } }}
六、Prompt 模板：让模型“先校验再输出严格 JSON”
你可以使用下面这个模板（核心是两点：输出必须是严格 JSON + 缺失处理规则写死）：
Prompt（模板）：
你是数据抽取器。请基于材料抽取结构化数据。
输出必须为严格符合给定 JSON Schema 的 JSON 对象。不得输出任何非 JSON 文本、不得包含注释或解释。缺失处理规则：
- 如果无法从材料中确认某个必填字段，请按约定填入
null（或填"UNSURE"，二选一）。- 不得自行编造事实或日期。
校验要求：输出必须通过 Schema 校验。
最终输出：仅返回 JSON（不要代码块、不要多余字符）。【材料】
{input_text}
【JSON Schema】
{json_schema}
小建议：如果你希望可追溯，加入
evidence字段，并要求填“材料中对应句子片段或 null”。
七、验收标准：给你一套“能过就能用”的门槛
建议你把验收写成硬指标（例如做批量测试时）：
-
JSON 解析通过率 ≥ 99%
-
Schema 校验通过率 ≥ 95%（视任务复杂度可调整）
-
字段键名一致性 = 100%（同一个任务不允许出现别名键）
-
缺失策略正确率 ≥ 98%
- 必填字段缺失时是否按策略填
null/"UNSURE" - 是否存在胡编（可人工抽检 Top 10%）
- 必填字段缺失时是否按策略填
此外建议做一次“回归集”长期跟踪：固定 50 条样本，版本更新后对比通过率是否下降。
结论：JSON Schema 不是“看起来更结构化”，而是“可落地的契约”
当你用 JSON Schema 约束 Gemini 3.1 Pro 的结构化输出时，稳定性提升来自三件事：
1）硬约束让字段/类型/枚举不再漂移；
2）缺失策略让模型不再胡编；
3）自动校验让“可用性”变成可量化指标。
把这一套固化到你的工作流里，你会明显减少返工与数据清洗成本：从“人肉修 JSON”变成“失败就回退到失败原因”。
