语法层优化：写给机器的提示词
YAML vs JSON、CSV vs 数组、压缩 JSON 输出，格式性 Token 省 10-30%
本页解决的问题
先给结论「语法层优化：写给机器的提示词」要解决的关键问题是什么？
YAML vs JSON、CSV vs 数组、压缩 JSON 输出，格式性 Token 省 10-30%
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
「四个优化策略」为什么要看操作
「YAML vs JSON、CSV vs 数组、压缩 JSON 输出，格式性 Token 省 10-30%」把结构落到了一个具体动作。这里真正要比较的不是名词谁更高级，而是数据如何被放置，以及最常发生的操作需要走多远。
读懂结构，要同时看访问方式和变化方式
「YAML vs JSON、CSV vs 数组、压缩 JSON 输出，格式性 Token 省 10-30%」揭示了一个容易被忽略的取舍：按位置读取、按键查找、从两端进出、插入新元素和遍历关系，适合的组织方式并不相同。一个结构在某个操作上很快，不代表它在所有操作上都快。
把规模和更新频率一起算进去
实践时可以把「YAML vs JSON、CSV vs 数组、压缩 JSON 输出，格式性 Token 省 10-30%」当作边界提醒：先写下数据量、最常用的操作和允许的延迟，再看 AI 给出的结构是否真的匹配。
从「四个优化策略」走到「格式对比演示」
「四个优化策略」先把问题落在「1 复杂对象：YAML 代替 JSON 用缩进代替闭合符号，信噪比更高 省 15-30% 2 扁平列表：CSV 代替 JSON 数组 字段名重复 N 遍是最大浪费 省 30-60% 3 后台输出：强制压缩 JSON 机器读数据不需要美观，只需要合法 省 10-20% 4 去掉 Markdown 装饰符号 ** 加粗、### 标题占用额外 Token 省 8-13%」上；到了「格式对比演示」，讨论继续推进到「YAML vs JSON：同样的数据结构 ❌ JSON（高 Token 消耗） ✅ YAML（省 Token） 💡 实测：Lyra 提示词中， ** 加粗符号就吃掉 8.5% Token；算上列表、标题、JSON 格式化缩进，整体格式性 Token 达 13% 。千万级调用量下，每月 20% 预算花在「让产品经理看着舒服」上」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
遇到一个新的数据结构时，不要从定义开始背。先写出最频繁的操作，再估计数据量和更新方式，最后检查结构是否让这三个条件同时成立。
- 「四个优化策略」：1 复杂对象：YAML 代替 JSON 用缩进代替闭合符号，信噪比更高 省 15-30% 2 扁平列表：CSV 代替 JSON 数组 字段名重复 N 遍是最大浪费 省 30-60% 3 后台输出：强制压缩 JSON 机器读数据不需要美观，只需要合法 省 10-20% 4 去掉 Markdown 装饰符号 ** 加粗、### 标题占用额外 Token 省 8-13%
- 「格式对比演示」：YAML vs JSON：同样的数据结构 ❌ JSON（高 Token 消耗） ✅ YAML（省 Token） 💡 实测：Lyra 提示词中， ** 加粗符号就吃掉 8.5% Token；算上列表、标题、JSON 格式化缩进，整体格式性 Token 达 13% 。千万级调用量下，每月 20% 预算花在「让产品经理看着舒服」上
最后的「最后把结论落到实践」把讨论落到「YAML vs JSON、CSV vs 数组、压缩 JSON 输出，格式性 Token 省 10-30%」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。