结构化输出和后处理解析怎么配合？

让 DeepSeek 吐出一段规整的 JSON 只是前半程，程序里怎么把它接住解析好，是同样要紧的后半程。纳米AI、WPS AI 的扩展开发里都绕不开这一步，生成端与解析端各管一段，配合起来才是完整管线。

生成端和解析端的分工

生成端的职责是把输出约束到大概率合法：格式模板、字段清单、禁止附加说明。解析端的职责是处理剩下的小概率意外：容忍空值、剔除代码围栏、报错重试。指望生成端做到万无一失，或者指望解析端包打一切，都会在某个环节吃亏。

提示端要把约束写到什么程度

• 字段名逐字给出，连顺序也定死。
• 每个字段的类型和取值范围写清，日期用什么格式要点名。
• 明确「只输出 JSON，不要解释」，并把这句放在末尾压阵。

解析端最常见的失败点

排在前列的失败点都很朴素：输出被代码块围栏包住导致直接解析报错；字段值里混入未转义的引号；模型在 JSON 前后加了「好的，以下是」之类客套话。解析前先做一次清洗——剥围栏、截取首个大括号到末个大括号之间的内容——能消掉大部分意外。

三类高频失败的来源与对应处理，可以并排对照。

两端配合的对照清单

• 提示端说「只输出 JSON」，解析端就要真的按纯 JSON 接。
• 提示端定义了可选字段，解析端就要容忍缺键。
• 提示端允许数组，解析端就要兼容空数组。

约束怎么写才抗忽略，机制见提示里的标点和符号有用吗？过程拆开看；固定前缀与解析稳定性的关系见是怎么写才能命中提示缓存的？关键步骤一次讲清；模式级约束的边界见JSON 模式下还能自然表达吗？；函数参数的解析见函数调用场景的提示是怎么写的？。

管线调稳之后，还有两件工程化的收尾动作。一是给解析失败分级：围栏没剥、引号没转义、字段缺失是三类高频失败，各自配一条自动修复规则，比如围栏自动剥、缺字段按默认值补并打标记，只有修不了的才走重试，重试量能压到一成以下。二是留观测：每次解析记录原始输出与错误类型，攒一周就能看出模型在哪类字段上最不可靠，回头把那几个字段的描述再收紧，形成循环改进的套路。对接旧系统时还要兼容历史格式，解析端留一层适配比让提示迁就旧格式更干净——提示面向模型，适配层面向系统，各自维护各自的边界。灰度切换格式版本时，解析端按版本号分流，旧格式慢慢退场，避免一刀切造成批量失败。验收标准也要两端统一：用同一份字段契约文档，改字段先改文档再改两端，防两头悄悄错位。

解析管线分工对照

• 生成端管形状：模板、字段、禁附加语。
• 解析端管意外：剥围栏、清杂质、可重试。
• 两端对字段的理解要逐字对齐。

管线两端像插头和插座，形状对齐才通电。

上线前还有一次全链路彩排：用线上真实样本过一遍生成、清洗、解析、重试全流程，重点看长尾样本——字段值里有引号、日期格式混杂、空值扎堆的那批。彩排通过的管线，上线后大概率安静。彩排样本要覆盖新旧两版格式，切版期间的兼容表现也在验收范围；彩排报告留档，出问题时能快速对比是哪一环变了。

解析管线快问快答三则

• 提示里写了「只要 JSON」，为什么还带说明文字？：约束是倾向不是开关，解析端保留剥壳逻辑更稳。
• 解析失败就直接重发原提示吗？：更好的做法是带着错误信息重试，让模型修正上一次的输出。
• 字段越多解析越容易失败吗？：字段多出错面就宽，必要字段之外能砍则砍。

收一句：管线跑得稳，靠的是两端对得上，不是单端拼命。