Skeleton-of-Thought
Skeleton-of-Thought（SoT，Ning et al., 2023）的核心目标不是“让推理更强”，而是让生成更快：把一次长回答拆成“骨架（skeleton）+ 多段并行填充”，从而用并行调用减少总等待时间（wall-clock latency）。
1) SoT 在做什么：先搭骨架，再并行补全
SoT 把生成过程分成两步：
-
Skeleton 生成（骨架阶段）
用一个提示词让 LLM 先输出回答的大纲/结构，把完整回答拆成若干独立段落或子问题（相当于“要写哪些部分、每部分回答什么”）。 -
Parallel fill（并行填充阶段）
把骨架里的每一项，当作单独的小任务，同时（并行）发给 LLM（通常是多次 LLM 调用）。
等所有段落都返回后，把它们按骨架顺序拼接/整合成最终回答。
因为很多段落之间相对独立（例如“优点”“缺点”“步骤”“注意事项”“示例”等），并行后总耗时接近“最慢那一段”的耗时，而不是所有段落耗时之和。
2) 它和 DECOMP / ToT / RoT 的区别
- SoT（加速）：关注并行化与降低延迟；子任务往往是“回答的不同部分”。
- DECOMP（分解求解）：关注把不同子问题派给不同函数/工具以提升能力/准确性。
- ToT（搜索）：关注多分支探索与评估选择。
- RoT（递归）：关注遇到难点就递归调用解决并回填。
SoT 的典型场景是：答案很长、但结构清晰、各段可独立写。它不一定提升正确率，但能明显提升“端到端响应速度”。
3) SoT 的典型 Prompt 设计（骨架 Prompt + 填充 Prompt）
(A) 骨架 Prompt（让模型只产出结构）
请先不要写完整答案，只输出“回答骨架（skeleton）”。
要求：
- 用编号列出 5-8 个要点/段落标题，每个标题后写一句该段要回答的子问题。
- 标题之间尽量相互独立，便于并行展开。
- 不要展开细节，不要写结论。
问题：{用户问题}
输出格式：
1) 标题：子问题
2) ...
(B) 填充 Prompt（针对骨架某一项展开）
你将撰写最终回答的第 {i} 部分。
总问题：{用户问题}
本部分标题：{title}
本部分要回答的子问题：{subquestion}
要求：
- 只写本部分内容（不要写其他部分）
- 内容尽量自洽、可直接拼接到总回答中
- 100-200 字（可按需调整）
(C) 可选：整合/润色 Prompt（拼接后再统一风格）
并行拼接后常会出现重复、风格不一致、前后术语不统一，因此常加一个“整合器”：
下面是按骨架并行生成的各段内容。请做轻量整合：
- 去重与合并重复点
- 统一术语与语气
- 保留结构不大改写
输出最终完整回答。
{拼接内容}
4) 一个直观例子：写“如何做用户调研”长回答
用户问题：如何做用户调研？给步骤、方法、注意事项、产出物模板。
Skeleton 可能是：
- 目标与范围：本次调研要解决什么决策问题、覆盖哪些人群与场景？
- 招募与抽样：如何定义目标用户、样本量、招募渠道与筛选问卷？
- 方法选择：访谈/问卷/可用性测试/日记研究分别适用什么？
- 访谈提纲设计：问题结构、追问技巧、避免诱导的方法？
- 执行与记录：如何安排流程、录音记录、伦理与隐私告知？
- 分析与归纳：如何做编码、主题提炼、证据链与优先级？
- 产出物：报告结构、洞察写法、行动建议与模板？
然后把 1-7 并行生成，最后拼起来，再做一次统一润色。
5) SoT 为什么能“加速”：并行降低总延迟
假设写 7 段，每段平均 2 秒：
- 串行：约 14 秒
- 并行（理想）：约 2~3 秒（取决于最慢段 + 调度开销）
所以 SoT 的收益主要体现在“长答案、多段落”的场景。
6) 局限与常见坑
- 段落之间会重复或矛盾：并行生成缺少全局协调。→ 需要整合器/最终校对。
- 骨架质量决定上限：骨架漏了关键段，后面并行写得再好也不完整。
- 不适合强依赖顺序的推理：比如一道数学证明，后一步依赖前一步结果，硬并行容易错。
- 成本更高：并行多次调用意味着 token/费用上升，用“时间换钱”。
7) 什么时候用 SoT 最划算？
适合：
- 报告/教程/对比评测/方案书/产品文档这类结构化长文本
- FAQ 汇总、面试题讲解、课程大纲扩写
- 你最关心的是 响应速度 和 吞吐量
不适合：
- 必须一步步推导、强依赖中间结果的题（更像 ToT/RoT/PoT 的用武之地）
如果你告诉我你希望加速的回答类型（例如“写一篇科普文章”“输出一份技术方案”“做对比表格”），我可以给你一套更贴近你场景的 SoT 骨架提示词，并给出“并行子任务切分到几段最合适”的建议。