跳到正文
docai.cc

DOCAI · 课程 · L1 · 20 分钟 · 学会用 Claude 对话

Claude 输出格式控制:列表、表格、JSON 格式指定方法

拿到回答还要重新排版,等于把时间花在搬运上。这一节给出五种常用容器的写法、可检查的字数条件,以及三个高频格式毛病的修法。

Claude 入门 · 提示词进阶技巧

你将学会

  • 能按用途选择合适的输出格式并写出具体要求
  • 会给 JSON 和报告类输出定骨架
  • 能把「简短一点」改写成可以逐项核对的条件

格式不对,等于白写

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

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

先选容器,再定字段

常见容器就几种,按用途选:

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

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

用骨架锁定结构

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

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

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

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

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

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

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

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

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

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

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

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

字数要写成可检查的条件

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

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

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

三个高频毛病

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

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

JSON 前后带话。 明确起点和终点,告诉它从第一个花括号写到最后一个,中间只放数据。需要更稳的结构化输出,可以看结构化输出和 JSON 模式。

平台不认 Markdown 怎么办

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

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

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

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

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

把下面的会议记录整理成两部分:

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

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

[粘贴会议记录]

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

把格式要求写成最后一段

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

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

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

下一节讲怎么用示例把标准固定下来,减少来回修改:少样本提示。

自测

先自己回答,再展开对照;答不上来就回到对应小节。
  1. 01为什么给程序用的输出一定要在提示里限定开头和结尾?看答案

    多一句客套或解释,解析就会失败。明确从哪个符号开始、到哪个符号结束,能减少后处理。

  2. 02控制字数时,哪种说法最可靠?看答案

    给出分段和每段范围,例如四段、每段 70 到 90 字,比笼统写「简短一点」稳定得多。

查看 Markdown

涉及的概念

在知识树上