用 JSON 而不是自然语言要输出

我以前让模型列点东西，提示词永远少不了一句：「请列出几点，每点简明扼要。」

模型也很配合，每次都给我一串带「1. 2. 3.」的东西。看起来挺好。直到我要把它喂给下游程序处理，噩梦开始了。

自然语言输出，人读着舒服，机器读着要命

我拿那串输出做解析，发现它一会儿用「1.」，一会儿用「（1）」，一会儿冒号在标题后，一会儿在标题里。我以为的「简明扼要」，模型理解成「1. 标题：内容 2. 标题：内容」，又理解成「1、标题 2、标题」——全角数字、半角数字、顿号、冒号，花样百出。

我写了个正则，补补打打，越写越长，最后那个正则比我业务逻辑还复杂。而且每次模型换个「花样」，我的正则就崩一次。这不是模型的问题，是我让它在自然语言里自由发挥，它当然发挥。

换成 schema，世界清净了

后来我把提示词改了，不说「请列出几点」，改成给一个明确的 JSON 结构：

「输出一个 JSON 数组，每个元素是一个对象，包含 title（字符串）和 desc（字符串）两个字段。」

就这一改，下游解析失败的次数从「经常」直接归零。模型不再自由发挥了，它照着结构填，填出来我能直接 parse，一个正则都不用。

我后来才想明白这次改动为什么这么彻底——它不是让输出「好看」了，是消除了歧义。

结构化的本质是消除歧义

自然语言是模糊的。「列出几点」里的「几点」，模型不知道是 3 点还是 8 点；「简明扼要」，它不知道多短算短。每个模糊，模型都得猜一次，猜对了皆大欢喜，猜错了你就得补丁。

JSON schema 把这些模糊全干掉了。「数组」就是数组，「两个字段」就是两个字段，「字符串」就是字符串，没有理解空间。模型照着填，你照着读，中间不需要猜。

自然语言适合给模型说任务，结构化适合让模型交作业。前者要的是它理解你的意图，后者要的是它给你能直接用的东西。这俩不是一回事，但很多人混着用，于是又难又脆。

几个落地细节

用结构化输出我踩过几个坑，列出来：

• 用 schema 约束，别用形容词。「输出 JSON」不够，要说清楚字段名、类型、是否必填。形容词留给任务描述，结构交给 schema。
• 能要数组就别要分隔符。别让它用「；」分隔返回一个字符串你自己再 split，直接要数组，省一个出 bug 的环节。
• 复杂结构分两层。嵌套太深模型容易乱，超过两层我宁可拆成多次调用。

收尾

那次改动之后，我给自己立了个规矩：只要输出要给程序处理，就一律结构化；只有给人看的最终文案，才用自然语言。

这个规矩让我少写了一堆脆弱的解析代码，也让模型少犯了一堆格式相关的错。它不是个技巧，是个原则——别让模型猜你想要什么，也别让你猜它给了什么。把模糊消灭在提示词里，下游就清净了。