Skeleton-of-Thought：先搭骨架再填内容

让模型写长回答，常有两个毛病：要么结构松散像流水账，要么生成慢得让人等。Skeleton-of-Thought（SoT，骨架提示）一招治两个。

思路特别简单：先让模型列出回答的提纲（骨架），再把每个提纲点分别展开（填肉）。

为什么这样更好

结构更清楚：先有骨架，模型就不会写着写着跑题，每一段都对应一个明确的点。

还更快：这是反直觉的地方。骨架列出来后，各个点的展开是相互独立的，可以并行生成。原本要顺序写完的长文，拆成几段并发，总耗时能压下来。这也是 SoT 论文最初的卖点——加速。

两阶段

阶段一，列骨架：

针对问题「{问题}」，先只列出回答的要点提纲，
每条一句话，不要展开，3-7 条。

模型可能返回：

定义与背景
核心优势
主要局限
适用场景
实操建议

阶段二，逐点填充：对每个骨架点，单独发一个请求让它展开（这些请求可以并发发出去）：

就「{骨架点}」这一点，结合问题「{问题}」展开 2-3 句。

最后把展开的内容按骨架顺序拼起来，就是一篇结构清晰的完整回答。

适合什么

结构化长回答：评测、对比、方案、清单类。

对延迟敏感、又要长内容：靠并行把时间压下来。

要求条理性的场景：报告、文档、知识梳理。

不适合什么

强逻辑链条的推理别用。 数学证明、需要一步推一步的题，各点不独立，硬拆并行会断了逻辑。这类还是老老实实用思维链。

短回答没必要。 就答一两句话的，搭骨架是杀鸡用牛刀。

并行带来工程复杂度。 要真正享受到提速，得在代码里并发调多次 API、再按序拼接。如果你只是在对话框里手动用，那就只剩「结构更好」这一个好处，提速享受不到。

一个简化版

不想搞并行的话，单次 prompt 也能用 SoT 的思想：

回答「{问题}」时，请：
1）先用一行列出 3-5 个要点提纲；
2）再逐条展开每个要点。

虽然没有并行加速，但「先骨架后展开」这个结构约束，本身就能让回答明显更有条理。

和别的技巧搭配

骨架提示管「结构」，思维链管「推理」，两者解决不同问题。需要既有结构又要推理时，可以先 SoT 列框架、框架里需要推理的点再套 CoT。想打牢提示工程基础，建议先看 提示工程入门。

小结

Skeleton-of-Thought 的价值是「结构 + 提速」两手抓。手动用，吃结构红利；工程化并行调用，才能把提速也吃到。