材料该用什么格式喂给模型

设计一个可重复的流程时，有个问题绕不开：这批材料用什么格式装？

一份访谈稿直接粘进去，还是先转成结构化的？四十份问卷回答，是做成表格还是一条条列？编码框架写成清单，还是写成字段？

选错了，模型读岔的概率会明显上升。而这件事有相当清楚的判断标准。

先分清两件事

几乎所有困惑都源于把这两件事混在一起：

职责一：序列化。 把信息编码成一段文本。JSON、CSV、YAML 主要解决这个。

职责二：定界。 让模型在一大堆输入里分清「哪一段是什么」。Markdown 标题、XML 标签擅长这个。

这两件事是正交的，可以叠加。 比如用 XML 标签划出区块，区块内部放 Markdown。

想清楚这一层，很多看起来矛盾的选择就顺了：你可以既要结构清晰（定界），又不必把叙述性内容硬塞进 JSON（序列化）。

一句话结论

实践中绝大多数情况归为两类：

• 叙述性内容（访谈稿、报告、笔记）→ Markdown；需要在提示词里分区时，外面再套 XML 标签
• 字段化数据（问卷结果、指标、清单）→ JSON；需要人工编辑用 YAML，大量同结构记录用表格 / CSV

下面是为什么。

结构化强度谱系

从弱到强排一下：

左边 token 效率高、容错好；右边无歧义、可校验。往右走要付 token 代价，所以别无脑选最结构化的那个。

研究咨询场景的具体建议

访谈稿 → Markdown + XML 定界

访谈稿是典型的叙述性内容，不要转成 JSON。转完之后你会发现原话被切碎了，而原话恰恰是最有价值的部分。

正确的做法是用 Markdown 保持可读，外面套 XML 标签让模型知道边界：

以下是三份访谈的完整转录稿。

<interview id="A-07">
## 受访者背景
35 岁，一线城市，家庭月收入 2–3 万

## 转录
Q：您平时买这类产品会看什么？
A：说实话我先看牌子……
</interview>

<interview id="A-08">
……
</interview>

请按下面的框架对每份访谈打标：
<framework>
1. 购买驱动因素
2. 信息来源
3. 价格敏感度
</framework>

要求：每条结论后面标出访谈编号。材料里没有依据的写「未涉及」，不要推断。

三个要点：

• id 属性让追溯成为可能。 之后每条结论都能指回是哪份访谈说的
• 框架也用标签包起来。 和材料区分开，模型不会把框架误读成材料的一部分
• 访谈内部用 Markdown。 保留原有的问答结构，不做破坏性转换

问卷数据 → 表格

四十份问卷、每份十几个字段，这是最典型的同构记录，表格是最省 token 的选择。

Markdown 表格直接粘就行，不用转 CSV：

| 编号 | 年龄 | 城市 | 品牌认知 | 购买频次 |
|---|---|---|---|---|
| A01 | 35 | 上海 | 高 | 每月 |
| A02 | 28 | 成都 | 中 | 每季 |

什么时候该转成 JSON？ 当字段本身有层次的时候——比如每个受访者下面还挂着多个购买记录。扁平表格装不下嵌套结构，硬塞会让关系丢失。

编码框架、术语表 → Markdown 清单

这类东西是给模型读的规则，不是给程序解析的数据。Markdown 清单最合适，也最好维护——你自己改起来不用担心括号配对。

放进 CLAUDE.md 或 .claude/rules/ 里，它就成了每次自动加载的规范。

需要程序接着处理 → JSON

只有一种情况必须用 JSON：输出要被另一个程序读走。

比如你要模型把打标结果导进 Excel 或统计软件，那就明确要求 JSON 输出，并把字段定义清楚：

输出为 JSON 数组，每份访谈一个对象，字段如下：

{
  "id": "访谈编号",
  "drivers": ["购买驱动因素，数组"],
  "sources": ["信息来源，数组"],
  "price_sensitivity": "high | medium | low | unknown",
  "evidence": "支撑上面判断的原话摘录"
}

不确定的字段填 unknown，不要猜。只输出 JSON，不要有任何解释文字。

最后那句很重要。 不加的话，输出前面常常带一段「好的，我来帮您分析……」，程序解析会直接失败。

三个常见错误

一、把叙述性内容硬塞进 JSON。 一份两千字的访谈记录塞进一个 "content" 字段里——转义符满天飞，token 翻倍，而模型读到的还是那段文字。没有任何收益。

二、什么都不定界。 把背景资料、任务要求、示例一股脑粘进去，中间只用空行分隔。模型分不清哪段是要处理的材料、哪段是指令。长输入必须定界。

三、为了“更规范”选了最重的格式。 YAML 和 JSON 是给机器的，人读起来累、token 也贵。如果这份内容的最终读者是模型而不是程序，Markdown 通常就够了。

一个判断顺序

1. 这份内容是叙述，还是字段？ 叙述 → Markdown；字段 → 表格或 JSON
2. 输入里有几个不同角色的部分？ 超过一个 → 用 XML 标签定界
3. 输出要不要被程序读走？ 要 → 明确 JSON 结构，并要求只输出 JSON
4. 这份东西我以后要手工改吗？ 要 → 别用 JSON，用 Markdown 或 YAML

大部分工作停在第 1 和第 2 步。