指令遵循对决：格式严谨度与鲁棒性平衡

52JinY 助手

这两年看了不少大模型在“指令遵循”上的对比，发现一个很有意思的取舍：格式严格度越高，往往越容易牺牲鲁棒性；而鲁棒性越强，又常常会在格式上“跑偏”。很多评测喜欢用可解析的 JSON、固定要点清单来打分，这当然有必要，但如果只盯着格式，就会错过真实使用场景里最关键的：当用户模糊、冲突、甚至自相矛盾时，模型能不能稳住不失真，能不能把任务救回来。

先说“格式严格度”。这是工程侧最爱的特质：输出可预测、字段稳定、标点不乱。对接流程引擎、自动化脚本、数据库落库，一旦格式抖了一下，后面就全线翻车。所以很多团队会给模型套强约束：系统提示里穷举 schema、加函数调用、甚至在后处理里做正则纠错。短期看有效，但有两个隐患：其一，过拟合模板后，模型容易“自信瞎编”填满字段，把未知当已知；其二，面对用户增补的新需求（比如临时让它顺带做风险评估），模型被格式夹住，反而不知所措。换句话说，格式严格度解决的是“可解析性”，却可能压缩“表达的真度”。

再看“鲁棒性”。我更愿意把它理解为对不完美输入的容忍度与自救能力：歧义识别、冲突消解、主动澄清、边界承认、降级策略。一个鲁棒的模型，遇到不合理要求会明确提出假设与不确定性，必要时拆解任务、分阶段输出，甚至先给出保底结果再提示风险。这类能力在开放场景如客服、研究辅助、创作协同中特别重要，因为真实世界里，完美需求几乎不存在。但鲁棒性强的模型，经常被吐槽“话多”“不听话”，尤其在被要求“只返回 JSON”时，偶尔还是会夹带解释，破坏了自动化链路的洁癖。

如何权衡？我的经验是分层与可回退。面向机器消费的链路，优先保证格式严格度，同时在系统里内置“失败即降级”的兜底：若主回复不可解析，自动触发一次“只返结构”的重试；仍失败，则把原文与错误原因一并抛给

人工审核或备用模型。这样把“可解析性”的刚性需求放在第一层，用机制而不是一次性赌注去保证稳定；而在人机混合或探索型场景，让模型有说“不确定”的空间，允许它以自然语言补充假设与限制条件，再由人来裁决取舍。

另一个实用做法是“语义先行、格式后置”。也就是让模型先在隐藏思路里完成任务推理与风险标注，最后一步再渲染为所需结构。很多人把这理解成“让它先想再说”，关键在于把“想”的结果与“说”的外壳解耦。实践里可以用两段式调用：第一次获取要点与不确定项，第二次把要点投影进 schema，仅在必要时用占位符或空值，并显式标记置信度和缺口来源。这样既不鼓励编造，也不至于因格式压力把含糊当确定。

评测也该分账。对自动化工作流，测“严格度通过率”“可恢复率”（一次重试能否修正）；对开放对话，测“歧义捕获率”“错误承认时延”“降级质量”。把分数拆开看，比把所有能力挤进一个综合分更能指导工程取舍。尤其要警惕那种在干净提示下分数很高、但一加噪就崩的“易碎优秀生”。

最后，团队文化同样重要。产品侧别把“只返 JSON”当唯一真理，工程侧也别把“多说两句”视为罪过。把场景切清楚：流水线要的是确定性，协作要的是诚实与自洽；把机制设计好：失败可回退、信息可溯源、风险有标记。接受一个现实：没有同时极致严格又极致鲁棒的万能形态，只有针对场景的最优解。能在两端之间自如切换的系统，才算真正懂“指令遵循”。