4.4 高级提示策略：JSON格式强制与约束条件设计

少林码僧
2 阅读6分钟

4.4 高级提示策略：JSON格式强制与约束条件设计

一、格式强制的价值

要求模型输出为JSON、XML等结构化格式，便于程序解析、校验与后续处理。是构建可靠自动化流程的基础。

《大模型应用开发极简入门》第4章「提示工程」中的 4.1.3 高级提示策略 明确提到：分步思考、示例引导、约束条件、格式强制（JSON/XML）。本节聚焦格式强制与约束条件设计，与书中「约束条件、格式强制」一一对应，是生产级提示设计的关键一环。

二、JSON格式示例

2.1 基础示例

请将以下用户反馈分类，并以JSON格式输出，包含字段：category（类别）、sentiment（情感：positive/negative/neutral）、summary（一句话摘要）。
用户反馈：这个产品物流快，但质量一般。

期望输出：

{"category": "物流与质量", "sentiment": "neutral", "summary": "物流快但质量一般"}

2.2 在 API 中的使用

在 system 或 user 中明确写出「请仅输出合法 JSON，不要包含其他文字或 markdown 代码块」。若模型仍返回 markdown 代码块包裹的 JSON，可在后处理中用正则提取 \{.*\} 再解析。

import json
import re

def parse_json_response(text: str) -> dict:
    """从模型回复中提取 JSON"""
    match = re.search(r'\{.*\}', text, re.DOTALL)
    if match:
        return json.loads(match.group())
    raise ValueError("未找到合法 JSON")

2.3 多字段与嵌套结构

对复杂输出可给出完整 schema 示例，例如：

请根据用户输入输出JSON，严格遵循以下结构（不要增加未列出的字段）：
{
  "intent": "用户意图分类",
  "entities": [{"type": "实体类型", "value": "实体值"}],
  "confidence": 0.0-1.0
}
用户输入：明天北京天气怎么样？

三、约束条件设计（与书 4.1.3 对应）

  • 明确字段名、类型、可选值：如 sentiment 仅允许 "positive" / "negative" / "neutral"，避免模型自造取值。
  • 限制长度：如 summary 不超过 50 字，避免冗长。
  • 禁止内容：如不输出敏感信息、不输出解释性文字只输出 JSON。
  • 数值范围：如 confidence 为 0–1 的浮点数，便于下游阈值判断。

书中「约束条件」与「格式强制」常一起使用：先强制格式（JSON/XML），再在说明中列出约束（字段、类型、长度、禁止项）。

四、XML 格式作为替代

部分场景下 XML 更易被模型稳定遵守（标签明确）。示例：

请用以下XML格式输出，不要输出其他内容：
<result>
  <category>类别名</category>
  <sentiment>positive|negative|neutral</sentiment>
  <summary>一句话摘要</summary>
</result>

解析时用标准 XML 库即可，注意处理模型可能多出的换行或空格。

五、输出校验与重试

即使明确要求 JSON，模型偶尔仍会输出非 JSON 或格式错误。建议：

  1. 后处理校验：try/except json.loads，失败时记录原文并告警或重试。
  2. 重试策略：同一请求带「请仅输出上述 JSON，不要添加任何其他文字」再试一次。
  3. 降级：若多次失败，可降级为「输出纯文本」或转人工。

六、与书中「示例引导」的结合

书中 4.1.3 还提到示例引导。对 JSON 输出可给 1–2 个完整示例（Few-shot），减少格式偏差。例如在提示中写：

示例输入：这个产品很好用。
示例输出：{"category": "产品评价", "sentiment": "positive", "summary": "产品好用"}
请对以下输入按相同格式输出：...

七、常见问题与排查

问题原因解决
输出带 markdown 代码块模型习惯后处理正则提取 JSON，或明确写「不要用 markdown」
多出字段未严格约束在提示中写「仅输出以下字段，不要增加」
类型错误未说明类型在约束中写明 "integer"、"string"、"array of..."
中文乱码编码问题确保请求与响应均为 UTF-8

九、生产环境实践建议

在实际项目中，建议将「格式强制 + 约束」与下游流程统一设计：（1）契约先行：先定义好 JSON schema 或 XML DTD，再在提示中写清字段与类型，与接口文档保持一致；（2）版本管理：提示模板与 schema 随需求变更时，做好版本标记与回归测试，避免格式变更导致下游解析失败；（3）监控：对解析失败率、重试次数做监控，超过阈值时告警并排查是模型输出不稳定还是约束表述不清。书中 4.1.5「提示优化」中的迭代测试、版本管理与本节的格式强制结合，可形成稳定的结构化输出管线。

十、与思维链（CoT）的配合

当任务需要「先推理再输出 JSON」时，可在提示中要求：先写出简要推理步骤（如「分析：…结论：…」），再在最后一段输出符合约束的 JSON。这样既保留可解释性，又便于程序从回复末尾提取 JSON。解析时可用正则匹配最后一个 \{.*\} 或按「最终结论」后的内容截取，与 4.3 节思维链结合使用。

十二、多语言与特殊字符

当输出内容包含中文、emoji 或特殊符号时，需确保请求与响应均使用 UTF-8 编码，且后端解析 JSON 时使用支持 Unicode 的库（如 Python 的 json 模块）。若模型偶尔在 JSON 中输出未转义的换行或引号，会导致 json.loads 失败，此时可先做简单清洗（如将 \n 替换为空格）或要求模型「不要在多行字符串中使用未转义的换行」。书中 4.1.3 的「约束条件、格式强制」在本节已细化为可落地的校验与重试策略，多语言场景下同样适用。

十一、小结

格式强制与约束条件是生产级提示设计的关键，与《大模型应用开发极简入门》4.1.3「高级提示策略」中的约束条件、格式强制（JSON/XML）完全对应。结合输出校验与重试，可确保下游系统稳定运行。下一节将介绍防御性提示与幻觉抑制。

十三、与 4.1、4.5 节的组合

4.1 节结构化模板：JSON 输出要求可写入四要素中的「输出要求」；角色与任务描述不变，仅将输出格式固定为 JSON 并给出 schema 或示例。4.5 节防御性提示：事实类任务常要求输出 {"answer": "...", "confidence": "high/medium/low"}，即 4.4 的格式强制与 4.5 的置信度结合；解析后可据 confidence 触发人工复核。与 4.3 CoT 的配合：若需「先推理再给 JSON」，可要求最后一段仅输出 JSON，前文为推理步骤，解析时用正则取最后一个 \{.*\} 即可。

十四、小结（复述）

JSON/XML 格式强制与约束条件设计是书中 4.1.3 高级提示策略的核心落地。掌握 schema 描述、后处理提取与重试策略，即可为下游自动化与 RAG、Agent 提供稳定结构化输出，与 4.1、4.3、4.5 形成完整提示工程链路。与第 5 章 RAG、Agent 的关系：RAG 的问答结果若需程序化处理（如填充工单、触发工作流），可要求模型输出 JSON；Agent 的工具调用结果也常以结构化形式返回，与本节格式强制一致。在实际项目中建议将常用 JSON schema 与解析函数封装成公共模块，便于 RAG、Agent 等多处复用。

下一节预告：4.5 防御性提示：幻觉抑制与事实校验实战技巧

avatar
文章
阅读
粉丝