语法层：Prompt 是写给机器的
加粗的 ** 就吃掉 8.5% Token；复杂对象用 YAML、扁平列表用 CSV、后台输出强制 Minified JSON
本页解决的问题
先给结论「语法层：Prompt 是写给机器的」要解决的关键问题是什么？
加粗的 ** 就吃掉 8.5% Token；复杂对象用 YAML、扁平列表用 CSV、后台输出强制 Minified JSON
把成本看成形状，不是一个数字。 把一次请求拆成输入、输出、重试、工具和等待时间。使用量的形状，通常能告诉你是哪项设计选择最贵、哪里值得先改。
优化想象中的平均值之前，先测一次真实请求。
调用便宜了，却悄悄增加了重试、延迟或人工复核。
作者做了一个 Token 可视化分析工具（yusuan.ai/analyzer），把一段精简版 Lyra 提示词丢进去分析：光是加粗用的 ** 符号，就吃掉了 8.5% 的 Token。算上列表、标题符号、JSON 缩进换行，这份提示词 13% 都是格式性内容。一般产品的 Prompt 里，10%–20% 都是这种装饰性 Token。
把 50 条用户记录喂给模型，三种格式点开对比。字段名重复 50 遍的 JSON 数组，是 RAG 场景的重灾区。
1、复杂对象用 YAML（或 TOON），别用 JSON。JSON 的信噪比太低：每个 Key 双引号包裹、每层嵌套花括号闭合，而这些符号往往独立计费。YAML 用缩进代替闭合符号、冒号代替「引号+冒号」，Token 通常省 10%–15%，多的能到 40%。TOON 是专为省 Token 设计的新格式，但作为新格式 LLM 不一定支持得好——所以更稳的组合是 YAML + CSV。
2、扁平列表用 CSV，别用 JSON 数组。带表头的表格把重复键名全干掉，长列表场景砍 30%–60%，同样的上下文窗口还能塞更多数据。
3、后台输出强制 Minified JSON。输出端的 Token 比输入端更贵，还直接影响接口返回速度。面向用户的流式输出可以宽松点，但纯后台任务（提取标签、情感分析、数据清洗）不需要任何排版——在 System Prompt 里显式约束：
机器读数据不需要美观，只需要合法。批量任务加上这条约束后，生成耗时显著下降。
先去 yusuan.ai/analyzer 量一下你的 Prompt：装饰性 Token 通常占 10%–20%，这是最容易拿的一笔钱。
数据结构按场景选：复杂对象 YAML、扁平列表 CSV、后台输出 Minified JSON。
输出比输入贵，管住输出格式既省钱又提速（第 12 节还有三招）。
内容来源：整理自作者团队内部分享《AI Token 降本增效策略分享》实战篇「01｜语法层」。工具：yusuan.ai/analyzer；YAML 规范见 yaml.org。
「这笔税有多重：13% 都是格式」的完整成本怎么算
「作者做了一个 Token 可视化分析工具（ yusuan.ai/analyzer ），把一段精简版 Lyra 提示词丢进去分析： 光是加粗用的 ** 符号，就吃掉了 8.5% 的 Token 。算上列表、标题符号、JSON 缩进换行，这份提示词 13% 都是格式性内容。一般产品的 Prompt 里，10%–20% 都是这种装饰性 Token」提醒我们，AI 成本不是单价乘一次调用这么简单。输入、输出、重试、工具调用、等待时间和人工收尾，会共同决定一次任务到底贵不贵。
先找出账单里不断重复的部分
「把 50 条用户记录喂给模型，三种格式点开对比。字段名重复 50 遍的 JSON 数组，是 RAG 场景的重灾区」对应的关键变量通常是上下文是否每轮重复发送、输出是否过长、失败是否触发重试，以及每次调用是否真的带来有用结果。减少无效 Token 往往同时降低费用、延迟和并发压力。
便宜的单次调用可能换来更贵的全流程
以「数据结构按场景选： 复杂对象 YAML、扁平列表 CSV、后台输出 Minified JSON」为起点做一张小表：输入、输出、重试、工具和人工复核分别花了什么，再比较优化前后的质量，避免只看某一项价格。
从「这笔税有多重：13% 都是格式」走到「交互演示 · 同一份数据的三种账单」
「这笔税有多重：13% 都是格式」先把问题落在「作者做了一个 Token 可视化分析工具（ yusuan.ai/analyzer ），把一段精简版 Lyra 提示词丢进去分析： 光是加粗用的 ** 符号，就吃掉了 8.5% 的 Token 。算上列表、标题符号、JSON 缩进换行，这份提示词 13% 都是格式性内容。一般产品的 Prompt 里，10%–20% 都是这种装饰性 Token」上；到了「交互演示 · 同一份数据的三种账单」，讨论继续推进到「把 50 条用户记录喂给模型，三种格式点开对比。字段名重复 50 遍的 JSON 数组，是 RAG 场景的重灾区」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
分析成本时，先画出完整交互，再找每轮重复的输入、无效输出和失败重试；单次调用便宜，并不代表整个任务便宜。
- 「这笔税有多重：13% 都是格式」：作者做了一个 Token 可视化分析工具（ yusuan.ai/analyzer ），把一段精简版 Lyra 提示词丢进去分析： 光是加粗用的 ** 符号，就吃掉了 8.5% 的 Token 。算上列表、标题符号、JSON 缩进换行，这份提示词 13% 都是格式性内容。一般产品的 Prompt 里，10%–20% 都是这种装饰性 Token
- 「交互演示 · 同一份数据的三种账单」：把 50 条用户记录喂给模型，三种格式点开对比。字段名重复 50 遍的 JSON 数组，是 RAG 场景的重灾区
- 「最后的要点」：数据结构按场景选： 复杂对象 YAML、扁平列表 CSV、后台输出 Minified JSON
最后的「最后的要点」把讨论落到「数据结构按场景选： 复杂对象 YAML、扁平列表 CSV、后台输出 Minified JSON」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。