---
title: "Claude 输出格式控制：列表、表格、JSON 格式指定方法"
description: "拿到回答还要重新排版，等于把时间花在搬运上。这一节给出五种常用容器的写法、可检查的字数条件，以及三个高频格式毛病的修法。"
updated: 2026-11-13
canonical: https://docai.cc/learn/output-format-control/
markdown_mirror: https://docai.cc/learn/output-format-control.md
---
## 格式不对，等于白写

内容再好，如果拿到手还要重新排版，时间就花在了搬运上。更麻烦的是给程序用的输出：多一句"好的，以下是结果"，解析就失败。

格式问题多数时候不是能力问题，而是提示里没说。花几行字描述你要的结构，比事后整理省事得多。先说清楚用途，再动手写提示。

## 先选容器，再定字段

常见容器就几种，按用途选：

| 用途 | 格式 | 关键要求 |
|---|---|---|
| 粘到聊天工具 | 纯文本 | 明确说不要任何标记符号 |
| 给人快速扫读 | 列表 | 每条一行，控制条数 |
| 多对象对比 | 表格 | 先定列名，再限每格字数 |
| 程序读取 | JSON | 给字段名和类型，只要结果 |
| 导入表格软件 | CSV | 第一行列名，一行一条 |

选错容器会让后面所有要求失效。比如要导入表格却让它写成段落，再强调格式也没用。

## 用骨架锁定结构

描述结构最省字的方式是直接给骨架。以 JSON 为例：

```json
{
  "name": "产品名",
  "category": "分类",
  "price_note": "计价方式，一句话",
  "risks": ["风险点"]
}
```

配上一句"只输出这段 JSON，从第一个花括号写到最后一个，前后不加解释"，多数情况下可以直接使用；对稳定性要求高时，再考虑 schema 约束。字段名用英文还是中文，看下游怎么读；一旦定了，后续所有请求保持一致。

报告类任务同样可以给骨架：

```
# 标题
## 结论（三句以内）
## 依据（分点，每条不超过两句）
## 风险与未知（没有就写「无」）
## 建议行动（编号列表）
```

骨架的作用是替你决定"写什么、不写什么"，模型不用猜，你检查时也有对照。

对比类任务也可以照这个办法，先要一句结论，再要一张固定列的对照表：

```
结论：___
| 比较项 | 方案甲 | 方案乙 |
| 成本 | | |
| 上手难度 | | |
| 后续维护 | | |
建议：___（写明适用前提）
```

表头固定之后，第二份、第三份输出可以直接拼在一起看，不用每次重新对齐。

同类的还有问答和时间线。需要整理访谈或常见问题时，直接规定每组的写法：

> 输出六组问答。每组以「问：」开头，问题不超过十五字；「答：」后面写两到三句，不超过一百字。

时间线同理：每行先写时间节点，再写一句事件描述，按先后排序。格式定得越具体，后期整理越少。

## 字数要写成可检查的条件

"简短一点"只是方向，"300 字左右"是范围，"分四段、每段 70 到 90 字"才是可以逐段核对的条件。要求越结构化，偏差越小。

| 说法 | 可控程度 |
|---|---|
| 简短一点 | 低 |
| 300 字以内 | 中 |
| 三个要点，每个一句话 | 较高 |
| 四段，每段 70–90 字，总字数 350 以内 | 高 |

表格、清单这类输出，除了总字数，还要限制单条长度，否则会出现一条占半屏的情况。

## 三个高频毛病

**开头打招呼。** 加一句"直接给结果，不要开场白"，多数情况能消掉。

**代码和解释混排。** 要求先给完整代码块，再用分隔线隔开说明，复制时就不会带走解释。

**JSON 前后带话。** 明确起点和终点，告诉它从第一个花括号写到最后一个，中间只放数据。需要更稳的结构化输出，可以看[结构化输出](/concepts/structured-output/)和 [JSON 模式](/concepts/json-mode/)。

## 平台不认 Markdown 怎么办

同样一段内容，发到文档平台和发到聊天工具，格式要求不一样。聊天窗口、部分邮件客户端不渲染 Markdown，星号和井号会原样露出来。给这类渠道，直接写「纯文本，不要星号、井号、短横线」，用空行分段，编号写成「一、二、三」。

表格在窄窗口会折行，超过五列基本没法读。把表格换成一行一条的清单，每行格式是「名称：结论」，反而更适合手机上看。

CSV 还要多一句：字段内部出现逗号时用引号包住，否则地址里的逗号会把一列拆成两列。代码段在纯文本里没有折叠和高亮，发之前先在上一行写明用途，比如「清洗脚本」，接收方才知道该复制哪一段。

## 一次改写：从会议记录到结论加待办

格式控制最常见的用法不是让它写新东西，而是把已有的材料改成能转发的样子。输入一段会议记录，要求输出两部分：

```text
把下面的会议记录整理成两部分：

一、结论：三句话以内，只写已经达成的决定。
二、待办：表格四列——事项 | 负责人 | 截止时间 | 依赖。

规则：
- 记录里没提到的负责人写「待定」，不要推测；
- 重复出现的议题合并成一条；
- 有争议、没结论的内容单独列在「未决事项」，不要混进结论。

[粘贴会议记录]
```

这类改写最容易出的毛病，是它顺手把没定的事替你定了。所以「待定」和「未决事项」两栏必须写进要求里，复核时只看这两栏，几十秒就能判断它有没有越界。这套骨架可以存成模板，下次换材料直接套，做法见[提示词模板](/concepts/prompt-template/)。

## 把格式要求写成最后一段

一个顺手的习惯：在提示末尾固定放一段格式说明。

> 输出要求：中文；表格三列，每列 20 字以内；先给结论再给依据；不要开场白和总结句。

它和任务描述分开，改格式时不用动正文。任务越常做，这段越值得存成模板。

下一节讲怎么用示例把标准固定下来，减少来回修改：[少样本提示](/learn/few-shot-prompting-guide/)。