用Prompt让大模型输出结构化JSON，总是崩格式怎么办？

后处理其实比调prompt更省心，我一般用正则先把json和剥掉，再拿json.loads硬解析，失败就丢给模型重试一次。动态字段的话可以试试在prompt里声明“不要输出任何解释，只输出纯净JSON”，然后把temperature拉到0，few-shot里故意放一个带markdown的错误例子，模型会学得比较快。另外field大小写问题，干脆在后端统一做key映射，别指望模型100%听话。

试试用XML标签包住JSON，比如

...

，后处理直接正则提取，比纯靠prompt稳多了。

后处理其实比调prompt更划算，我一般用正则先把json和剥掉，再拿JSON.parse硬解析，失败了就丢给模型让它只输出修正后的内容，这样能兜底不少。function calling动态字段的话可以试试把所有可能字段都定义成optional，让模型自己选填，我这边这么搞之后基本没崩过。另外你temperature调到0.2以下，再加一条“禁止输出任何非JSON内容”的system指令，成功率能上去不少。

试试在prompt末尾加一句“只输出JSON，不要用代码块”，再配合正则把多余的反引号剥掉，能压到1%以内。

你这5%-10%的失败率其实已经算不错了，GPT-4o偶尔抽风真没法完全避免。我自己的土办法是让模型先输出一个宽松的中间格式，比如纯文本的字段列表，再用正则和json.loads去兜底解析，比直接硬刚JSON稳定多了。另外有个冷门技巧，在prompt里加一句“不要用代码块，直接输出原始JSON”，对某些模型特别管用。你要是动态字段多，可以试试把schema定义放在user消息里而不是system里，有时候模型会更听话。

后处理其实比调prompt更划算，我一般先正则剥掉```json标记，再抽第一个{到最后一个}之间的内容，最后用json.loads包个try，失败就丢给模型重生成一次，成本也不高。字段名大小写问题可以在few-shot里故意放两个反例，模型对边界情况敏感很多。另外你可以试试在prompt末尾加一句“不要输出任何解释，直接返回原始JSON”，对GPT-4o管用。function calling动态字段确实难绑，但你可以搞个宽松的schema，把params定义成object类型，里面允许任意key，这样既走函数调用又保留灵活性。

试试把few-shot里的示例直接写成一个完美的JSON对象，别放代码块，再加条“只输出纯文本”的硬性规则，能压到2%以内。

我这边是正则兜底+json.loads失败就重试一次，比纯靠prompt稳多了，动态字段用占位符替换也够用。

后处理兜底最实在，正则抽JSON块再json.loads，失败就重试一次，比调prompt省心多了。

试试把schema塞进system message里，再加个输出前自检的步骤，让模型自己纠错，能压到2%以内。

这事儿我太有同感了，之前调输出格式也是被折磨到崩溃。后来我干脆写了个正则清洗层，先把json和剥掉，再对字段名做统一小写化映射，就算模型抽风也能兜住底。另外你可以试试在prompt里强调“不要输出任何解释性文字”，有时候崩格式是因为它自己脑补了注释。动态字段确实绑function calling不现实，但如果你能预先定义好字段类型枚举，哪怕让模型自由填值，稳定性也会好很多。

这问题太真实了，我最近也在跟这个死磕。你试过把few-shot里的示例直接改成“失败案例”吗？就是故意给一个带markdown和错误字段名的输出，然后标注“这是错的”，再给一个干净版本，模型反而会更警觉。另外，别只靠prompt，后处理那层建议写个正则先把json和结尾的```剥掉，再扔给json.loads，失败就再走一次修复逻辑，比如把单引号替换成双引号、补全缺失的逗号。我实测这样能把成功率拉到98%以上，剩下那2%直接让用户重试一次，比在prompt里死磕性价比高多了。还有个偏方，你试过在system message里加一句“你是一个严格的JSON序列化器，任何非JSON字符都会被判为错误”吗？对GPT-4o有时比少样本管用。不过说实话，动态字段用function calling确实不灵活，我后来改用输出一个JSON schema描述再让模型填值，比直接约束字段稳定，你感兴趣的话可以聊聊具体做法。

试试输出前加“直接给纯JSON别带任何说明”，再用正则把首尾的json和剥掉，基本能压到1%以内。

试试在后处理时用正则剥掉```再json.loads，配合异常重试一次，基本能把失败率压到1%以内。

我一般直接在prompt里强调“只返回原始JSON，不要代码块”，然后temperature设0，剩下的交给解析兜底。

我之前也踩过这个坑，后来发现与其死磕prompt，不如直接在后端做一层容错处理，比如用正则把json和多余的反引号剥掉，再用json.loads去解析，失败的话就抛给模型重试一次。另外你提到动态字段的需求，其实可以试试让模型输出一个带schema描述的JSON，然后再用代码去校验和补全字段，比单纯靠嘴硬提示要稳得多。我试过把few-shot里故意加一个错误示例，模型反而更警觉，格式崩的概率会降一点，你可以试试看。

试试后处理兜底吧，先正则剥掉```再json.loads，失败就重试一次，比调prompt省心多了。

试试用正则先把json和剥掉再json.loads，剩下的错误基本都能兜住，别指望模型100%听话。

后处理其实比调prompt更治本，我一般是正则把json剥掉，再拿json.loads硬解析，失败就丢给一个修复小模型重排。另外你试试在prompt里强调“不要用代码块包裹，直接输出纯文本JSON”，再加一条“字段名严格使用小驼峰，枚举值只能取xxx”，失败率能压到2%以内。动态字段那个场景，其实可以用JSON Schema描述允许的字段集合，让模型自己选填，比绑死schema灵活得多。

试试用正则把json和直接剥掉再json.loads，剩下那点错误率基本能兜住。

老实说5%-10%的失败率已经算不错了，我这边之前试过让模型输出嵌套的复杂JSON，崩的更惨。你可以试试在prompt里加一个“不要输出任何解释，只输出JSON对象本身”，然后把few-shot示例里的markdown标记也去掉，让模型模仿纯文本格式。另外后处理时写个正则先把json和剥掉再走json.loads，能兜住大部分情况。动态字段这块我之前也头疼，后来干脆让模型输出一个包含schema和data两部分的JSON，解析时再动态重组，比完全自由格式稳很多。

试试在prompt里直接声明“不要markdown，不要代码块，直接输出纯JSON”再加一个反例，能压掉一部分问题。但说实话5%的失败率靠prompt很难清零，我一般会在后处理用正则先把```剥离，再用JSON.parse硬解析，解析失败就丢给一个轻量修复函数，比如补引号或者把字段名批量转小写，比反复调prompt省心。你动态字段的场景或许可以试试“输出一个带schema版本的JSON”，让模型把字段定义塞进去，比纯靠上下文约束稳一些。

说实话这个问题我太有同感了，之前做NL2SQL的时候也被这5%的随机崩格式折磨过。我的经验是，与其跟prompt死磕，不如把后处理当成第一道防线——先正则扒掉所有```和json标记，再暴力解析一遍，如果失败就丢给一个专门修复JSON的小模型或者用json5库去兜底，基本能把失败率压到1%以下。

另外你提到的function calling嫌绑死schema不灵活，其实可以试试把动态字段设计成一层嵌套的“模糊参数”，比如params里只定义类型和描述，让模型自己填充，这样既有结构约束又保留弹性，我后来这么做之后格式错误几乎绝迹了。

还有个小技巧，在prompt末尾加一句“不要输出任何解释性文字或代码块标记，直接以{开头”，配合few-shot里故意放一个带markdown的反例，模型对负样本的学习有时比正例更管用。不过说实话，大模型输出本质还是概率问题，指望100%稳定不如接受现实，把重试机制也加上，比如检测到解析失败就自动重生成一次，成本也不高。