LLM 推理：Chain-of-Thought vs Structured Output 两种方案的适用场景与实测对比

很多人在选 LLM 推理策略时会纠结：Chain-of-Thought（CoT）听起来更智能，但 Structured Output（SO）更可控。到底该用哪个？

我跑了三个真实任务，把两种方案的坑和适用场景全标清楚了。

做数学题的时候，你大概率会先在草稿纸上写几步推导，再给答案。大模型也是这样——Chain-of-Thought 就是让模型把思考过程显式说出来，再给最终答案。Structured Output 则是直接约束模型必须按某个格式输出，比如 JSON schema。

这两种方案解决的是不同问题。

CoT 解决的是模型想不清楚。复杂推理任务里，模型直接给答案往往会在中间步骤出错。显式输出思考过程相当于让模型说出来，研究发现这能让推理准确率提升 15%~40%，尤其在数学、逻辑和多步规划任务上效果明显。

但 CoT 有个根本问题：你拿到的思考过程不等于真实推理。模型完全可能编一个听起来合理但逻辑不通的过程，最后给一个错的答案。你没办法验证，只能信。

Structured Output 解决的是模型输出不可控。当你需要把模型能力接进下游系统——比如提取字段、驱动工作流、做 RAG 的结构化检索——CoT 的自由文本根本没法解析。强制 JSON schema 输出后，解析错误率能从 20%~30% 降到 2% 以下。

但 SO 的代价是截断思考。模型被逼着直接给答案，省略了中间推理，在需要真正推理能力的任务上，准确率反而可能下降 10%~20%。

实测数据（三个任务）

我拿了三个任务跑对比：数学题（GSM8K 子集）、商品信息抽取（50 条电商文本）、多步骤规划（旅行日程生成）。

数学题：CoT 准确率 78%，SO 准确率 61%。差距主要在多步推导题，SO 模型会跳步。

商品信息抽取：CoT 解析错误率 22%，SO 错误率 1.8%。字段越结构化，SO 优势越大。

多步骤规划：两者差不多，CoT 略优（73% vs 68%），但 SO 输出可直接作为下游 API 参数，自动化场景直接赢。

结论很简单：需要真正的推理能力、用的人要理解过程、用完还要人工审核的，选 CoT。需要接进系统、需要可解析输出、需要自动化的，选 SO。

两个都用也行——先让模型用 CoT 思考，再用 SO 提取结构化结论。但 token 消耗会增加 2~3 倍，要不要付出这个成本，看你的场景值不值。

下次在 prompt 里纠结要不要让模型一步步想的时候，先问自己：我的输出是给人看还是给系统看？