Schema 驱动的 Prompt 设计：让你的数据模型主导 Prompt 结构

你的数据模式（schema）就是你的提示词。大多数工程师将这两者视为独立的事物——你设计数据库模式是为了满足范式规则，而你设计提示词是为了清晰和具描述性。但实体模式的形状对 LLM 输出质量有着直接且可衡量的影响，忽视这种关系是生产环境 AI 系统中最昂贵的错误之一。

一家中型电子商务公司的团队在他们的产品提取流水线开始生成幻觉模型年份时发现了这一点。修复方法并不是更好的提示词，而是将 {"model": {"type": "string"}} 更改为一个具有明确描述和正则表达式约束的字段。这单一的模式更改——记录在 PARSE 研究中——在他们的提取基准测试中带来了高达 64.7% 的准确率提升。

问题比字段描述更深。它触及了规范化、字段排序、嵌套深度、枚举设计，以及一个根本问题：LLM 能从你提供给它的结构中推断出什么，以及不能指望它推断出什么。

规范化陷阱

关系数据库设计教导你要进行规范化：消除冗余，将关系推入外键，将每条数据保存在一个地方。一个 orders 表通过 product_id 引用 products 表。整洁、高效、规范。

对于 LLM 提示词来说，这恰恰相反。

当你的模式要求模型在大脑中重构一个连接——找出哪个 category_id 对应哪个类别名称，或者哪些属性属于哪个产品类型时——模型会利用其训练分布来填补空白。它会进行猜测。而在复杂的模式中，它猜错的概率会不断累积。

PARSE 研究（发表于 EMNLP 2025）分析了针对 LLM 使用优化模式时究竟发生了什么变化。在所有提高提取准确率的修改中，55% 是结构扁平化——即将规范化的模式进行去规范化，从而使模型永远不必推断关系。另外 34% 是增强的字段描述，使字段范围更加明确。

实际影响是：如果你的数据模型为了存储效率而进行了规范化，你需要一个独立的、为 LLM 使用而优化的去规范化“提示词模式”。模型应该接收 product_name、category_name 和 category_type 作为兄弟字段——而不是指向它无法访问的查找表的 product_id 和 category_id。

嵌套深度如何破坏准确率

现代 JSON Schema 支持任意深度的嵌套。LLM 无法统一处理。

DeepJSONEval 基准测试测试了跨嵌套层级的提取准确率，并发现了一个陡峭的下降悬崖。在中等嵌套（深度 3–4）时，严格准确率得分在 54% 到 71% 之间。在困难嵌套（深度 5–7）时，得分下降到 43–53%。即使是该研究中表现最好的模型，在深层嵌套模式上的严格准确率也仅为 52.63%。

故障模式是不对称的。格式错误——如缺少键或类型错误等结构性问题——在参数超过 70 亿的模型中基本消失了。LLMStructBench 研究（22 个模型，2026 年 2 月）发现，大型模型中 97–98% 的剩余错误是错误值错误——即结构完美但内容虚假或归因错误的语义失败。更深的嵌套增加了模型必须解决的语义模糊性，而它通过编造听起来合理的数值来解决。

可操作的阈值：将提取模式保持在 2–3 层嵌套。当你的领域需要更强的复杂性时，将提取分解为流水线：

1. 先分类：使用一个带有文档类型枚举的小型专注模式。
2. 按类型提取：使用一个仅包含与该文档类别相关的字段的特定类型模式。
3. 验证交叉引用：运行最后一遍以验证提取的值是否一致。

每个阶段都使用更简单的模式。更简单的模式在每个层级都能产生更高的准确率。

字段顺序是因果性的，而非修饰性的

LLM 按顺序处理令牌。它们无法预测未来。这使得模式字段顺序在因果上处于输出质量的上游，这在传统软件开发中是无法比拟的。

具体例子：如果你的模式将 answer 字段放在 reasoning 字段之前，模型在生成任何思维链推理之前就已经确定了答案令牌。随后出现的推理是事后合理化——它是从答案开始的，而不是导向答案。

反转顺序——先 reasoning，后 answer——迫使模型在回答之前进行思考。这是在提取和分类任务中提高语义质量的最具杠杆作用的模式更改，且除了意识到字段顺序很重要之外，不产生任何成本。

同样的原则也适用于更广泛的模式设计。为后续字段提供上下文的字段应该更早出现。一个缩小 status_value 含义的 document_type 字段应该出现在 status_value 之前。模型对每个字段的理解都取决于它之前的所有内容。

枚举是安全护栏，而非风格选择

当你为分类值定义字段为 {"type": "string"} 时，你是在告诉模型任何字符串都是可以接受的。在约束解码（OpenAI 的 Structured Outputs、Guidance 及类似框架背后的机制）下，模型的 logits 在每一步都会被过滤，以便只有有效的 token 才能被产出。如果没有枚举约束，有效 token 的词汇表是无界的。

有了枚举约束，无效值将变得在语法上无法生成 —— 而不仅仅是可能性低。这就是“希望模型选择 'pending'”与“保证它无法选择 'in-progress'、'PENDING' 或 'awaiting'”之间的区别。

来自 JSONSchemaBench 的基准测试显示，约束解码框架在它们支持的 schema 上保持了近 100% 的格式合规性。更广泛的影响是：一项跟踪生产案例的研究发现，JSON schema 在结构化提取任务中将解析错误从 40% 降低到 2%，而函数调用（function calling）在金融服务应用中将审核准确性从 70% 提高到 95%。

设计上的启示是：审计你的 schema 中每一个具有有限有效值集合的字段，并将其转换为显式枚举。状态字段、类别字段、优先级、文档类型、操作代码 —— 每个可以界定的分类字段都应该被界定。即使在非约束解码的上下文中，模型的概率分布也会果断地向有效值偏移，因为枚举兼作领域的文档说明。

对于具有结构化格式的字符串字段 —— 订单 ID、产品代码、日期字符串 —— 请添加正则表达式 pattern 约束。PARSE 论文记录了一个具体案例：在模型年份字段中添加 "^(19[5-9][0-9]|20[0-2][0-9]) [A-Za-z0-9 -+]+$"，完全消除了幻觉产生的自由格式字符串。

缺失字段问题

这是一种比幻觉受关注更少的失败模式：当源数据不包含你的 schema 中标记为 required 的值时会发生什么？

模型会填充它。它不会返回错误，不会返回 null，也不会跳过该字段。它会根据其训练先验生成一个听起来合理的值，因为 schema 告诉它必须存在一个值。

如果你的 schema 包含 required: ["customer_email"]，而输入文档是一张未提及电子邮件的发票，你将得到一个电子邮件地址。它看起来很真实，但它是错误的。

修复方法很明确：对于源数据中可能不存在的字段，使用 type: ["string", "null"]。在 Pydantic 中，使用 Optional[str]。在 Zod 中，使用 .nullable()。这向模型 —— 以及约束解码语法 —— 发出了信号，即 null 是一个有效的输出状态。

另外，PARSE 研究引入了一种称为 SCOPE 的“溯源验证”（grounding verification）模式：在任何提取值的旁边，包含一个 source_quote 字段，要求模型引用提取该值所依据的准确文本段。必须为其提取结果提供引用的模型会被约束在源数据中出现的值上。与没有溯源的提取相比，这种模式实现了 92% 的错误减少。对于任何幻觉代价高昂的特定事实提取，都值得在 schema 中添加此模式。

Schema 分解即架构

可靠的单次调用提取的实际上限比大多数团队预想的要低。超过大约 50 个字段的 schema 会导致明显的质量下降。LLMStructBench 的发现很直接：深度为 4 且每个对象级别有 10 个键的 schema “甚至无法生成中等质量的示例”。Outlines（一个流行的约束解码库）在为包含大型枚举和复杂数组约束的 schema 编译语法时，可能需要 40 秒到 10 分钟。

这不是一个可以通过更好的提示词来修复的模型能力问题，而是一个架构问题。

多步提取流水线不是一种变通方法 —— 它们是复杂数据模型的正确设计。每个阶段做得更少，做得更可靠，并产出一个后续阶段可以依赖的有类型工件。分类阶段产出文档类型。提取阶段利用该类型选择正确的重点 schema。验证阶段检查跨字段的一致性。

一项多智能体失败研究（2025 年，涵盖五个框架的 150 多个执行轨迹）发现，规范和 schema 失败约占所有多智能体系统失败的 41.8%。流水线阶段之间的格式不匹配 —— 例如规划器输出 YAML 而执行器期望 JSON，或者分类阶段产生无约束字符串而下游代码期望特定枚举值 —— 会级联成破坏工作流的错误，这些错误很难诊断，因为失败看起来像是模型错误而非契约失效。

解决方案是将阶段间的 schema 视为 API 契约，而非建议。在每个智能体边界处使用具有约束类型的显式 schema，等同于分布式系统中的有类型函数签名。

在调优提示词之前，先审计你的 Schema

在修改提示词文本的一个字之前，请先运行此 schema 审计：

• 是否反规范化（Denormalized）？ 模型是否需要推断一种并未作为兄弟字段显式存在的关系？
• 嵌套深度？ schema 中的路径是否有超过 3 层的？能否将其扁平化？
• 字段顺序？ 推理或上下文是否排在依赖它们的字段之前？
• 是否存在枚举？ 每个分类字段是否都有显式的枚举？
• 可选字段是否已标记？ 所有源数据中可能缺失的字段是否使用了 null 联合类型？
• 溯源挂钩（Grounding hooks）？ 对于高风险的提取，是否有 source_quote 或等效字段？
• Schema 大小？ 总 schema 是否对于单次调用来说太大，或者是否可以分解？

PARSE 研究发现，通过分析字段描述的歧义性、嵌套复杂性的结构深度以及缺失的验证规则，可以自动检测出 89% 的 schema 问题。你不需要自动化分析也能手动应用同样的清单。

约束解码无法弥合的语义鸿沟

一个关键的警告：约束解码保证了句法合规，而不是语义准确性。一个情感分类器可以在连续两周内为每个输入生成有效的 JSON，并带有 0.99 的置信分数，但在情感判断上却是错误的。Schema 是正确的，但内容并非如此。

约束解码是必要的，但并不充分。剩下的故障模式——结构正确的输出中包含错误的值，这占了大模型 97–98% 的错误——需要语义验证层：置信度分布跟踪、跨字段一致性检查以及针对源数据的落地（grounding）验证。

思维框架的转变至关重要：一旦你的 Schema 消除了结构错误，所有剩下的失败就都是语义失败。这是一个更清晰的待解问题，但它仍然是一个问题。

对于生产系统，错误预算发生了变化：你不再把时间花在“模型返回了错误类型”上，而是开始花在“模型返回了一个看似合理但错误的值”上。Schema 设计能让你更快地触及真正的问题。

---

在生产环境中交付可靠 LLM 功能的团队已经内化了这样一个原则：Prompt 不仅仅是你写的文本，它是你交给模型的完整上下文——包括你预期的输出形态。重新设计这种形态通常比重新措辞指令更有效。你的数据模型与 Prompt 工程并不是孤立的。它是它的基石。