面向程序员 · LLM 工程基础课

结构化输出：让 AI 输出表格、JSON、评分表

AI 只会写一段自然语言还不够。进入企业系统后，它的输出要能被程序解析、校验、保存、展示、审批和回放。结构化输出就是把“看起来不错的回答”变成“系统能接住的数据”。

表格适合对比 适合风险清单、需求差异、方案对比、面试复盘。人读起来快。

JSON 适合系统集成 字段明确，能校验，能入库，也能作为工具调用或后续流程输入。

评分表适合评审 把“好不好”拆成维度、权重、证据和分数，减少主观拍脑袋。

结构化不等于正确 格式对了只是第一步。事实、来源、字段、权限仍然要校验。

structured_output parseable

Table 适合人读和横向比较

字段风险 SKU高

JSON 适合程序解析和校验

{ "ok": true,
"score": 86 }

Scorecard 适合评审和打分

01 · 先给定义

结构化输出是让模型按约定格式交付结果

普通回答像一段文章，适合阅读。结构化输出像接口返回值，适合系统处理。它不要求所有内容都变成 JSON，而是根据任务选择合适的格式。

Table

表格

用行和列组织信息，适合对比、清单、风险、任务拆解。

JSON

字段、类型和层级明确，适合系统解析、保存和校验。

Scorecard

评分表

把评价拆成维度、权重、分数、证据和建议。

Schema

契约

规定输出必须长什么样，失败时怎么处理。

一句话记住 结构化输出不是让 AI 写得更整齐，而是让 AI 的结果能进入工程链路：解析、校验、保存、展示、审批、重试。

02 · 为什么需要结构化输出

系统不喜欢“差不多能看懂”

人可以读懂一句含糊的话，程序不行。只要 AI 输出要接后续系统，就必须减少歧义。字段名、类型、枚举、缺失值、来源都要说清楚。

自由文本

人读可以，系统难接

这个需求整体还可以，但字段规则不够清楚。
建议补充 SKU、价格和失败处理。

程序很难知道“还可以”是多少分。
字段是否存在无法自动判断。
缺失项、建议项、风险项混在一起。

结构化结果

能解析，能校验，能流转

{
  "score": 72,
  "missingFields": ["skuRule", "failureHandling"],
  "risks": [
    {
      "level": "high",
      "reason": "未定义导入失败后的错误明细"
    }
  ]
}

系统可以按字段渲染、报警、保存，也能把高风险项送人工审核。

03 · 输出契约

先定义输出，再让模型生成

很多结构化输出失败，是因为一开始没有定义清楚输出契约。Prompt 里只说“用 JSON 输出”还不够，最好把字段、类型、枚举、空值、来源和错误处理写清楚。

1 用途给人看，还是给系统用。

2 字段每个字段叫什么，含义是什么。

3 类型 string、number、boolean、array。

4 枚举风险等级、状态、分类不能乱写。

5 空值缺资料时写 null、[] 还是 openQuestions。

6 校验失败时重试、修复还是转人工。

输出要求：
- 只输出 JSON，不要 Markdown 代码块。
- riskLevel 只能是 low、medium、high。
- 没有资料依据的字段写入 openQuestions。
- 每条 businessRule 必须包含 sourceId。
- 如果无法满足 schema，返回 validationNotes 说明原因。

04 · 表格输出

表格适合对比，但列要设计好

表格不是把内容塞进格子里。好的表格要有明确的行粒度和列含义。每一行代表一个对象、一个风险、一个需求点，还是一个评审维度，必须先定。

表格 Prompt 示例

请把下面需求拆成风险清单表格。
表格列固定为：
1. riskId
2. riskDescription
3. impact
4. evidence
5. owner
6. suggestedAction

如果没有证据，evidence 写“待确认”。

riskId	riskDescription	impact	evidence
R-01	未定义导入失败后的错误明细	测试无法验收，用户无法自助修正	待确认
R-02	覆盖已有 SKU 的权限不明确	可能导致商品数据被误覆盖	权限文档 P-12

列名要固定

不要让模型一会儿写“风险”，一会儿写“问题”。后续程序不好解析。

行粒度要统一

一行一个风险，就不要把解决方案和开放问题混成另一种行。

缺失值要约定

空白、未知、待确认含义不同。生产系统里要固定写法。

05 · JSON 输出

JSON 适合程序解析，但要防“像 JSON”

模型很容易输出看起来像 JSON 的内容，但里面有注释、尾逗号、额外文本、类型错误或枚举乱写。生产系统不能只看外观，要真的解析和校验。

容易失败

像 JSON，但不一定能解析

```json
{
  "score": "高", // 这里表示不错
  "risks": [],
}
```

有 Markdown 包裹、注释、尾逗号，score 类型也不清楚。

更稳

严格 JSON，字段可校验

{
  "score": 86,
  "grade": "good",
  "risks": [],
  "openQuestions": []
}

没有额外解释文本，字段类型稳定，程序能直接解析。

JSON 输出的 Prompt 规则 明确写：“只输出 JSON，不要 Markdown 代码块，不要解释文字，不要注释。字段不存在时使用 null 或空数组，不能省略必填字段。”

06 · Schema 校验

Schema 是结构化输出的验收门

Prompt 里写规则是第一层，程序校验是第二层。Schema 可以检查字段是否存在、类型是否正确、枚举是否合法、数组长度是否符合要求。

{
  "type": "object",
  "required": ["summary", "score", "risks", "openQuestions"],
  "properties": {
    "summary": { "type": "string" },
    "score": { "type": "number", "minimum": 0, "maximum": 100 },
    "risks": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["level", "reason", "sourceId"],
        "properties": {
          "level": { "enum": ["low", "medium", "high"] },
          "reason": { "type": "string" },
          "sourceId": { "type": "string" }
        }
      }
    },
    "openQuestions": { "type": "array", "items": { "type": "string" } }
  }
}

Schema 校验格式

它能发现 JSON 不合法、字段缺失、类型不对、枚举不在范围内。

业务校验事实

字段存在、接口存在、权限点存在，要查真实系统，不是 schema 能解决。

人工审核高风险

涉及删除、覆盖、发布、资金和权限时，结构正确也要人工确认。

07 · 评分表

评分表把主观判断拆成可讨论的维度

“这个需求写得怎么样”太主观。评分表把问题拆成几个维度，每个维度有分数、权重、证据和建议。这样评审更稳定，也更容易沉淀评测集。

30% 业务清晰度：目标用户、触发条件、成功结果是否明确。

25% 系统贴合度：字段、权限、接口是否符合现状。

25% 边界完整度：异常、失败、权限、并发是否覆盖。

20% 可交付性：研发和测试能否据此拆任务和验收。

评分表 JSON 示例

{
  "totalScore": 78,
  "dimensions": [
    {
      "name": "业务清晰度",
      "weight": 0.3,
      "score": 82,
      "evidence": "目标用户和主流程清楚，但成功指标未定义。",
      "suggestion": "补充导入成功率和失败处理时限。"
    }
  ],
  "decision": "revise",
  "openQuestions": ["失败明细是否需要下载？"]
}

08 · 失败与重试

结构化输出失败后，不要只让用户重来

模型输出不合法很正常。生产系统要有处理策略：解析失败、schema 失败、业务校验失败分别怎么做。重试也要带着错误原因，不要盲目再问一遍。

1 解析 JSON 失败则要求模型修复格式。

2 Schema 校验 缺字段、类型错、枚举错。

3 业务校验 字段、接口、权限点是否存在。

4 带错重试 把错误信息交给模型修正。

5 降级处理 多次失败转人工或输出草稿。

6 记录样例 失败样例进入回归评测。

if (!isValidJson(output)) {
  retryWith("只修复 JSON 格式，不改变业务内容");
}

if (!schemaValid(output)) {
  retryWith(validationErrors);
}

if (!businessValid(output)) {
  routeToHumanReview(output);
}

09 · 常见坑

结构化输出最怕“看起来对”

很多错误不是一眼能看出来的。JSON 能解析，不代表业务正确。表格列齐了，不代表行粒度正确。评分表有分数，不代表证据可靠。

多余文本

JSON 前后夹解释

“好的，以下是 JSON”会让解析失败。Prompt 要要求只输出 JSON。

类型漂移

数字一会儿是字符串

score 有时是 86，有时是“较好”。Schema 要限制类型。

字段省略

没有内容就不输出字段

生产系统更喜欢空数组或 null，而不是字段消失。

枚举乱写

high 写成 severe

Prompt 和 schema 都要固定枚举值，后端要拒绝非法枚举。

证据缺失

评分没有依据

评分表必须带 evidence，否则只是模型主观判断。

事实未校验

结构对了，内容是编的

接口、字段、权限点要查真实系统，不能只相信模型输出。

10 · 企业案例

用结构化输出评审商品导入 PRD

假设我们要让 AI 评审一份“商品批量导入 PRD”。自由文本只能给建议，结构化输出可以直接驱动评审面板：总分、维度分、风险、待确认项、是否通过。

{
  "reviewId": "prd-import-2026-06-12",
  "decision": "revise",
  "totalScore": 76,
  "dimensionScores": [
    {
      "dimension": "系统贴合度",
      "score": 68,
      "evidence": "PRD 提到错误明细下载，但接口文档未找到对应接口。",
      "sourceId": "openapi-product-v4"
    }
  ],
  "risks": [
    {
      "level": "high",
      "description": "覆盖已有 SKU 的权限规则未定义",
      "owner": "product",
      "suggestedAction": "补充覆盖策略和审批规则"
    }
  ],
  "openQuestions": [
    "失败明细是否需要支持下载？",
    "导入任务结果保留多久？"
  ]
}

产品看到决策

decision 是 revise，说明可以进入修改流程，而不是直接评审通过。

研发看到依据

sourceId 指向接口文档，能快速核对模型判断是否站得住。

测试看到风险

risks 和 openQuestions 可以直接转成测试关注点和评审问题。

11 · 面试问答

回答要说明格式、校验和业务闭环

结构化输出的面试重点不是“会让模型输出 JSON”，而是知道怎么设计输出契约，怎么校验，怎么处理失败。

什么是结构化输出？

结构化输出是让模型按约定格式返回结果，比如表格、JSON 或评分表。它的目的不是让内容更好看，而是让程序能解析、校验、保存和流转。

在企业系统里，我会先定义输出契约，再写 Prompt，并用 schema 和业务规则做校验。

什么时候用表格，什么时候用 JSON？

表格适合给人看，尤其是对比、风险清单、评审结果。JSON 适合给程序用，比如抽取结果、工具参数、结构化 PRD、评分结果。

如果后续要入库、触发流程或做自动校验，我会优先用 JSON。如果主要是给评审会阅读，可以用表格或 Markdown。

怎么保证模型输出的 JSON 可用？

Prompt 里要写清只输出 JSON，不要 Markdown 代码块，不要解释文字。字段、类型、枚举、空值处理也要明确。

后端还要做 JSON 解析、Schema 校验和业务校验。解析失败可以带错误重试，业务校验失败则进入人工审核或待确认流程。

评分表怎么设计？

评分表要有维度、权重、分数、证据和建议。只给一个总分意义不大，因为别人不知道分数从哪里来。

比如评审 PRD，可以分成业务清晰度、系统贴合度、边界完整度、可交付性。每个维度都要求 evidence 和 suggestion。

结构化输出能解决幻觉吗？

不能完全解决。结构化输出能让错误更容易被发现，但不能保证事实正确。

比如模型输出了合法 JSON，但里面的接口路径是编的。这个时候需要查 OpenAPI、字段字典、权限系统等真实来源。格式校验和事实校验都要做。

12 · 练习和速查

把“回答”变成“数据”

练习结构化输出时，不要只看模型能不能写出格式。要看格式能不能被解析、字段能不能被校验、结果能不能进入下一步流程。

练习 A：选择输出格式

生成风险清单给评审会阅读 优先表格，列固定为风险、影响、证据、负责人、建议动作。

从合同中抽取付款条款入库 优先 JSON，字段、类型和空值规则必须明确。

评审一份 PRD 是否达标 用评分表，包含维度、权重、分数、证据和建议。

调用工具查询订单状态 用严格 JSON 作为工具参数，服务端再做鉴权和校验。

练习 B：用一句话说清楚

解释结构化输出和普通回答的区别。
解释为什么“像 JSON”不等于合法 JSON。
解释评分表为什么必须有 evidence。
解释 Schema 校验和业务校验的区别。
解释结构化输出为什么不能完全消除幻觉。

结构化输出速查表

问题	推荐做法	检查点
给人看还是给程序用？	给人看可用表格，给程序用优先 JSON。	是否需要解析、保存、入库、触发流程？
字段是否稳定？	定义字段名、类型、枚举和必填项。	字段是否会漂移、缺失或改名？
缺失信息怎么写？	用 null、[] 或 openQuestions，不要让字段消失。	后端是否能区分未知和空？
评分是否可信？	每个维度要有 evidence 和 suggestion。	分数是否能追到依据？
输出失败怎么办？	解析、schema、业务校验分层处理。	是否有重试、降级和人工审核？
内容是否真实？	查字段字典、OpenAPI、权限系统、知识库来源。	结构正确不代表事实正确。