← Back to all guides

让 LLM 稳定输出 JSON：可落地的 7 步教程

让 LLM 输出格式稳定，先把“自由回答”改成“可验证协议”

很多开发者第一次接入大语言模型时，会在测试环境看到漂亮的 JSON、列表或表格；上线后却遇到字段缺失、额外解释、引号错误、语言混杂等问题。要获得一致输出，关键不是反复说“请严格遵守格式”，而是把输出设计成可验证、可重试、可监控的协议。下面用一个“从用户评论中抽取情绪、主题和行动建议”的场景，给出一套可直接落地的步骤。

步骤 1：先定义最小可用格式

不要一开始就要求模型输出十几个字段。字段越多，越容易失败。先定义业务真正需要的最小结构，例如：sentiment、topics、summary、next_action。每个字段都要有明确类型和边界。

• sentiment：只能是 positive、neutral、negative 三选一。
• topics：字符串数组，最多 3 个主题。
• summary：不超过 40 个中文字符。
• next_action：给客服或运营的一句话建议。

这一步的目标是减少模型自由发挥空间，让输出从“文章”变成“数据对象”。

步骤 2：在系统提示词中写清不可违反的规则

把格式约束放在 system 或 developer message 中，而不是只放在用户输入后面。规则应具体、短、可执行。例如：你是信息抽取器，只输出一个合法 JSON 对象；不要输出 Markdown；不要添加解释；无法判断时使用 null 或空数组；所有键名必须固定。

如果你使用 59API，可以通过兼容 OpenAI SDK 的方式调用 Claude 或 GPT 模型，base URL 设置为 https://api.59api.com。这样你能用同一套代码测试不同模型对格式约束的遵守程度，成本也更可控。

步骤 3：给一个“正确样例”，但不要堆太多样例

Few-shot 示例能显著提升格式一致性，但样例过多会增加上下文成本，也可能让模型模仿样例内容而不是抽取真实输入。建议提供 1 个正常样例和 1 个边界样例。

• 正常样例：评论内容清晰，情绪明确，主题明显。
• 边界样例：评论很短或信息不足，展示 null、空数组如何使用。

样例要覆盖字段类型，而不是覆盖所有业务场景。这样既节省 token，也降低输出漂移。

步骤 4：使用 JSON Schema 或函数调用能力

如果模型和 SDK 支持结构化输出、tool calling 或 JSON Schema，优先使用。相比纯提示词，Schema 能告诉模型字段名、类型、枚举值、必填项和数组长度，是稳定格式的核心手段。

实践中建议把 Schema 放在代码里版本管理，而不是散落在提示词文本中。每次改字段都更新版本号，例如 review_extraction_v1、review_extraction_v2，方便排查线上问题。

步骤 5：降低随机性，但不要迷信 temperature

结构化任务通常把 temperature 设为 0 或较低值，例如 0 到 0.2。这样可以减少同一输入多次调用时的差异。但要注意，低 temperature 不能修复模糊字段定义，也不能保证永远输出合法 JSON。真正可靠的方案仍然是：清晰 Schema、服务端校验、失败重试。

步骤 6：在服务端做解析、校验和自动重试

上线时不要直接信任模型输出。后端至少做三层检查：第一，能否解析为 JSON；第二，字段是否齐全且类型正确；第三，枚举值、长度、字符数是否符合规则。如果失败，把错误信息和原始输出作为上下文发起一次修复请求。

修复提示词可以很短：下面的输出不是合法结果，请只根据错误原因修复为符合 Schema 的 JSON，不要改变原始语义。通常一次修复就能解决大部分格式问题。如果连续两次失败，应记录日志并返回兜底值，而不是让异常扩散到用户界面。

步骤 7：用多模型低成本回归测试

不同模型对格式约束的服从程度不同。Claude Sonnet 可能在长文本理解上更稳，Haiku 适合低成本批量抽取，GPT 模型在工具调用生态里很方便。使用 59API 这类按量付费的 AI API 中转服务，可以用统一入口测试 Claude Opus、Sonnet、Haiku、Fable 以及 GPT 模型，并兼容 Claude Code、Codex 和常见 OpenAI SDK。

建议准备 50 到 200 条真实样本作为回归集，统计 JSON 解析成功率、字段完整率、业务正确率和平均成本。59API 提供接近官方质量的原生模型访问，不做降级转发，同时价格在同类中很有竞争力，还支持推荐返利。对于需要反复调提示词和跑测试的团队，这能明显降低试错成本。你可以在项目早期注册试用，把格式稳定性测试纳入 CI 或发布前检查。

最终检查清单

• 字段是否最小化，并且每个字段都有类型、范围和示例？
• 系统提示词是否明确禁止 Markdown、解释文本和额外字段？
• 是否使用 JSON Schema、结构化输出或函数调用？
• temperature 是否适合结构化任务？
• 服务端是否做了解析、校验、修复重试和日志记录？
• 是否用真实样本比较了不同模型的稳定性、准确率和成本？

获得一致的 LLM 输出不是单个提示词技巧，而是一套工程流程。把格式定义清楚，把模型输出当作需要验证的外部输入，再用低成本 API 平台持续测试，你就能把“看起来可用”的 Demo 变成“线上可靠”的功能。

Pricing · Docs