企业官网建设流程全解析

大模型思考的范式正在从“把过程写完整”走向“先把骨架搭对，再并行展开”，这就是本篇要拆解的SoT与T2S-Bench。SoT（Skeleton-of-Thought，骨架思维）针对的是思维链（CoT）最让人头疼的延迟问题，而T2S-Bench则为“骨架质量”这件事提供了一套可量化的评测思路。我会从CoT的成本讲起，把SoT的原理、T2S-Bench的评测逻辑、最小可复现的工程实现以及我在实际评测中踩过的坑都过一遍，适合正在调大模型推理速度和质量的工程师、研究者，以及想深入理解LLM推理范式的爱好者。

1. CoT之后的下一个范式：SoT到底想解决什么问题

1.1 先回忆一下CoT带来的改变与代价

思维链（Chain-of-Thought，CoT）大家都不陌生：遇到复杂问题时，不给模型直接输出的机会，而是先让它“把思考过程一步步写出来”，再基于这些中间步骤给出最终答案。这个方法在过去两年里几乎成了处理数学题、逻辑推理、复杂知识问答的默认策略，效果也确实明显——模型不容易“跳步”，出错率大幅下降。

但CoT有一个很现实的代价：回复变长了，等待时间也跟着变长。一个原本一两句话就能回答的问题，加上中间推理后可能变成几百个token。在大模型自回归解码的机制下，这些token必须一个接一个地生成，输出越长，用户感受到的延迟就越线性增长。尤其在那些需要多轮推理的问答、报告生成、代码解释场景里，等待十几秒甚至几十秒非常常见。

我在实际项目里的感受是：模型能力越强，用户对它“答得好”的期望就越高，但同时也默认“答得快”。一个要等半分钟才能出结果的助手，哪怕内容质量很高，使用体验也会被打折。延迟问题已经不只是工程优化问题，而是产品体验的核心指标。

1.2 SoT的核心思路：先搭骨架，再并行填充

SoT的思路不太一样。它默认一个规律：回答越长，串行生成的等待越长；如果能把回答拆成若干相对独立的段落，让这些段落同时生成，那整体延迟就不等于所有段落的生成时间之和，而近似等于最慢的那一段的生成时间。

具体做法分两阶段：

• 第一阶段：让模型先生成一个“骨架”，也就是答案的要点列表，每条要点非常简短，类似8到15个字的标题。
• 第二阶段：对骨架里的每一条要点，并行发起独立的生成请求，让模型把该要点扩展成完整的段落。

这个过程很像写文章时的“先列提纲，再分头写稿”：你不再要求一个人从头到尾一口气写完几千字，而是让一个主编出提纲，然后再把各个章节分给几个人同时写。第一个阶段虽然也占用时间，但骨架本身非常短，通常几十个token就够了；第二个阶段虽然要生成的内容总量没变，但因为是并行展开，墙钟时间被大幅压缩。

1.3 骨架长什么样：一个完整示例

为了直观理解，我拿一个典型问题做演示。

问题：为什么基于大语言模型的智能助手比早期聊天机器人更像“人”？

CoT的答案可能是：“要回答这个问题，首先要从自然语言理解能力说起……然后对话管理……最后个性化……”整篇可能300个token。

SoT先生成的骨架则类似：

- 第1点：语义理解深度不同 - 第2点：多轮上下文记忆能力 - 第3点：生成策略与个性化 - 第4点：知识广度与推理辅助 骨架结束

这个阶段差不多40到60个token。然后第二阶段的四个展开请求可以同时发给同一个模型，每个请求长这样：“请把‘语义理解深度不同’这一点扩展成一段内容，不要展开其他点，不要重复上下文”。等四个请求都返回后，把结果按骨架顺序拼接起来。

我特别提醒一句：骨架不是简单的“小标题列表”，它承担着规划作用。骨架每一条都要能独立撑起一段内容，并且彼此之间不能严重重叠。骨架的质量直接决定了最终答案的连贯性和覆盖度。这也是为什么后面要引入T2S-Bench这种专门评测骨架的任务。

2. SoT能提速的根因：一次串行解码与并行展开的账

2.1 自回归生成的真实瓶颈

大模型生成文本的过程本质上是自回归：每生成一个token，都要依赖前面所有token。也就是说，一段600token的回答，必须经历600次前向计算，而这次数是串行的，不能因为显存够大、卡够多就把600个token同时算出来。

真正卡住速度的往往还不是算力，而是内存带宽。生成每个token时，模型参数要从显存搬运到计算单元，token数据量不大，但参数搬运动作本身很耗时。你可以把自回归生成想象成一条流水线：传送带上的零件必须一个一个经过同一个工位。零件总数就是输出token数，工位效率就是单token生成延迟。

所以，CoT后等待时间变长的原因很朴素：输出token变多了，串行链条变长了。哪怕模型参数没有变，用户等待时间就是输出长度乘上每token耗时。

2.2 从600次串行到170次串行：一个具体账本

假设同样一个复杂问题，CoT最终输出了600个token。在纯串行解码下，墙钟时间约等于600次单token生成。

换成SoT后，假设骨架用了60个token，骨架被切分成5个要点，每个要点的展开内容约110个token。如果5个展开请求完全并行，那么实际串行长度就是：

骨架阶段（60次串行） + 展开阶段中最长的那条路径（110次串行） = 170次串行

理想情况下的加速比就是600除以170，约3.5倍。当然这是理想值，实际还要扣掉请求调度、网络往返、服务端排队等开销，但即使打个六折，也能到2倍左右的端到端提升。我按不同的骨架点数算过一笔账，感受会更直观：

这里有个容易误解的点：SoT并没有减少总生成token数。上面那个例子中，SoT的总输出是60加5乘110，约610个token，和CoT的600个差不多。它省的是“墙钟时间”，不是“币”。理解这一点很重要，因为它意味着SoT不会帮你省API费用，它解决的是延迟体验和用户感知速度。

2.3 并行展开的边界条件

并行展开之所以成立，依赖一个前提：骨架里的每个点之间足够独立。如果各要点之间有强依赖关系，比如第3点的展开必须依赖第2点的计算结果，那并行就会出问题。

实践中，开放式的论述类、解释类、综述类问题非常适合SoT，因为知识性要点之间的依赖较弱。而涉及数值计算、严格逻辑推导、流程编排的问题则要谨慎，这些场景下各步骤是强串联的，强行并行会导致后面的点“无米下锅”或胡编乱造。

第二个边界是并发上限。API服务通常有速率限制，无脑把展开请求全部并发出去，很容易触发限流。展开条数一般在3到6条比较合适，超过8条后，最后拼接出的答案往往碎片化严重，而且并行调度压力也会变大。

3. T2S-Bench：如何给“思考骨架”建立可量化的质量标准

3.1 T2S-Bench要解答的核心问题

SoT把回答质量的一部分责任交给了“骨架生成”这个阶段，但怎么判断一个骨架是好是坏？骨架是不是够全、够简、够可展开？这不能只靠人肉眼观察，T2S-Bench就是为了回答这些问题而设计的一套评测框架。

T2S，我在这里把它完整解读为Text-to-Skeleton，即“从文本生成骨架”的任务。它在SoT范式中对应第一阶段：给定一个问题或一段材料，模型需要输出一份结构合理、覆盖充分、适合继续展开的骨架。T2S-Bench则是围绕这个任务建立的评测基准，提供标准化的数据、评测指标和统计口径。

如果你之前接触过BLEU、ROUGE这类文本生成指标，会发现它们不太能直接用于骨架评测，因为它们只衡量字面相似度，不衡量“结构质量”。一个骨架可能和参考答案措辞完全不同，但要点覆盖恰当；反过来，措辞最接近的骨架也可能漏掉了关键维度。这也是T2S-Bench存在的意义：为骨架这种半结构化输出设计专门的评价方式。

3.2 评测维度拆解：骨架质量、展开忠实度、速度收益

我理解T2S-Bench的评测体系应该围绕三个维度展开。

第一个维度是骨架本身的质量。具体包括四点：覆盖度，即骨架是否涵盖了参考答案中的关键要点；简洁度，即每条要点的长度是否克制，如果一条骨架点写成了完整段落，那骨架就失去了“压缩”的意义；粒度，即切分粒度过粗会漏信息，过细则并行展开的成本和碎片化风险都上升；独立性，即各条之间是否有大面积语义重叠。

第二个维度是展开忠实度。SoT的最终答案由展开内容拼接而成，评测时必须关注：展开后的段落是否忠于原骨架点、是否忠于原问题；各展开段落之间是否存在明显矛盾；有没有展开内容偏离主题，把其他点的内容也带进来了。

第三个维度是速度收益。同样一批问题，分别用CoT和SoT跑，记录墙钟延迟、首token延迟、端到端加速比，看骨架质量与加速比之间是否存在关联。速度评测不能只看一次结果，服务端排队、网络抖动都会影响数据，一般要多次运行取中位数或均值。

3.3 评测流程与指标计算

一套标准的评测流程大致分四步。

第一步是准备测试集。测试集要覆盖足够多的任务类型，比如知识问答、多跳推理、开放论述、规划类问题，每类几十到上百道。问题难度也要分档，不然容易得到“简单问题骨架本来就好生成”这种过于片面的结论。

第二步是统一生成骨架。所有被试模型使用相同的SoT骨架Prompt，固定temperature和max_tokens。这里有一点需要注意：骨架阶段的随机性会对后续展开产生放大效应，所以每个问题最好生成多次，取稳定结果。

第三步是解析骨架并并行展开。骨架输出的格式要尽量约束成“- 第N点：……”这种机器易解析的格式。解析后按点并行展开，再把结果按原顺序拼接成最终答案。

第四步是指标统计。骨架覆盖度和简洁度可以通过与人工标注的要点集合求交集比例得到。展开忠实度可以用语言模型作为自动判官，或者抽样本做人工标注。速度指标则在日志里记录时间戳。

我贴一段当时做评测时写的最小脚本思路，方便理解统计口径：

import json, time, statistics def evaluate_one(question, ref_points, use_sot): t0 = time.time() if use_sot: final_answer = sot_answer(question) # 复用第4章的SoT实现 else: final_answer = cot_answer(question) wall_time = time.time() - t0 # 覆盖度：骨架提取出的要点与参考要点集合的匹配比例 skeleton_points = extract_skeleton(eval_log[question]["skeleton"]) matched = len(set(skeleton_points) & set(ref_points)) coverage = matched / max(1, len(ref_points)) # 简洁度：平均每条骨架点的字符数 concise = sum(len(p) for p in skeleton_points) / max(1, len(skeleton_points)) return {"coverage": coverage, "concision": concise, "latency": wall_time} results = [evaluate_one(q, refs[q], use_sot=True) for q in sample_questions] print("平均覆盖度:", statistics.mean(r["coverage"] for r in results)) print("平均骨架长度:", statistics.mean(r["concision"] for r in results)) print("平均端到端延迟:", statistics.mean(r["latency"] for r in results))

这类评测有个老生常谈的坑：指标维度之间存在对抗。骨架点越短，简洁度越高，但覆盖度可能下降；展开越自由，忠实度越低。最后通常要看“给定覆盖度阈值下的延迟收益”，或者“给定延迟预算下的覆盖度损失”，不要只盯单指标。

3.4 从评测结果反推的SoT适用规律

用T2S-Bench思路做过几轮测试后，我观察到一些比较稳定的规律。

第一，骨架质量高的任务，SoT的收益显著。开放论述和综述类问题，覆盖度可以轻松做到0.8以上，加速比常见在2倍上下；而数学推理类问题，骨架覆盖度往往只有0.4到0.6，加速比也不稳定，有时甚至比CoT还慢，因为展开后要额外拼接和修复矛盾。

第二，小模型更容易产出过粗的骨架。参数量较小的模型在骨架阶段经常漏点，尤其是知识面不广的时候，它会把几个不同要点强行合并到一句话里。这种情况下可以适当提高骨架Prompt的示范数量，或者限制骨架条数下限，强制模型给出不低于4条。

第三，骨架生成的复现性比预想中好。普通答案生成时，反复跑同一道题结果差异很大；但骨架生成因为约束强、格式固定，多次生成的稳定性反而更高。利用这个特点，可以对骨架做简单的self-consistency：同一问题生成多次骨架，投票选出最稳定的版本，再进入展开阶段，质量会更稳。

4. 最小复现路径：从Prompt到并发展开的完整实现

4.1 三条实现路线怎么选

实现SoT不复杂，核心就两个动作：调一次接口生成骨架，再并发调用接口展开各点。我梳理过三条路线。

路线A是“最朴素的两轮调用”：先用骨架Prompt请求一次，拿到骨架字符串，然后写循环逐点展开。适合快速验证SoT效果，代码量最小，但展开阶段是串行的，加速效果有限。

路线B是“多线程并发展开”：用线程池把各点展开请求并发出去，这是性价比最高的路线，大部分人应该从这条线开始。

路线C是“封装成可复用组件”：把骨架生成、展开、拼接、重试、限流全部封装成类似answer_async(question)的函数，集成到机器人或RAG系统里。适合已经确定要把SoT落到业务中的人。

我推荐从路线B开始，跑通后视需要再演进到路线C。

4.2 骨架Prompt的打磨细节

骨架Prompt是整个流程里影响最大的部分。我打磨过一版比较稳定的中文模板，你拿去可以直接改参数用：

请先用最简洁的要点列出你回答的骨架，不要写完整答案。 要求： 1. 每一条用“- 第N点：要点标题”的格式，要点标题不超过15个字。 2. 骨架必须覆盖问题的所有关键维度，不要遗漏重要侧面。 3. 各要点之间尽量独立，不要重复表达同一个意思。 4. 只输出骨架本身，最后一行写“骨架结束”。 问题：{question}

这个模板里有三个细节值得展开说。

为什么要求“每一条不超过15个字”？因为骨架点一旦写长，就相当于提前生成了部分答案，不仅浪费串行时间，还会给展开阶段带来重复感。15个字左右的压力会迫使模型做真正的概括。

为什么要限定“覆盖所有关键维度”？不加这句话时，模型容易只挑它最有把握的两个点，尤其小模型会偷懒。加限定之后，骨架的覆盖度有明显提升。

为什么要输出“骨架结束”这个终止标记？这能让解析逻辑更可靠，也避免模型在骨架阶段惯性生成完整答案。解析时直接按这个标记截断即可。

4.3 并发展开的Python代码与注释

下面是我在项目里用过的最小实现，基于兼容OpenAI接口的客户端，你也可以换成其他推理API，只要做好接口适配。

import concurrent.futures import re from openai import OpenAI client = OpenAI(base_url="这里填你的服务地址", api_key="这里填你的密钥") SKELETON_PROMPT = """请先用最简洁的要点列出你回答的骨架，不要写完整答案。 要求： 1. 每一条用“- 第N点：要点标题”的格式，要点标题不超过15个字。 2. 骨架必须覆盖问题的所有关键维度，不要遗漏重要侧面。 3. 各要点之间尽量独立，不要重复表达同一个意思。 4. 只输出骨架本身，最后一行写“骨架结束”。 问题：{question}""" EXPAND_PROMPT = """请根据下面的骨架，只展开指定的那一点，写一段完整、自包含的内容。 骨架： {points} 要展开的点：{point} 要求： 1. 不要复述整份骨架，也不要展开其他点。 2. 直接把这一点说透，可以补充必要例子。 3. 控制展开内容在150字以内。""" def chat_once(prompt, max_tokens=200, temperature=0.3): resp = client.chat.completions.create( model="这里填模型名", messages=[{"role": "user", "content": prompt}], max_tokens=max_tokens, temperature=temperature, ) return resp.choices[0].message.content def generate_skeleton(question): raw = chat_once(SKELETON_PROMPT.format(question=question), max_tokens=200) # 截断到“骨架结束” head = raw.split("骨架结束")[0] if "骨架结束" in raw else raw points = re.findall(r"-\s*第\d点\s*[：:]\s*(.+)", head) return points def expand_point(point, points): skeleton_text = "\n".join(f"- 第{i+1}点：{p}" for i, p in enumerate(points)) prompt = EXPAND_PROMPT.format(points=skeleton_text, point=point) return chat_once(prompt, max_tokens=250, temperature=0.4) def sot_answer(question): points = generate_skeleton(question) if not points: return "骨架生成失败，请重试" # 关键：线程池并发展开，串行路径=骨架生成+最长单点展开 with concurrent.futures.ThreadPoolExecutor(max_workers=len(points)) as pool: futures = [pool.submit(expand_point, p, points) for p in points] expansions = [f.result() for f in futures] # 按原骨架顺序拼接 return "\n\n".join(expansions) # 使用示例 print(sot_answer("为什么大语言模型适合做文本总结？"))

这个版本有两点需要明确：一是并发度max_workers设为要点数，但实际项目中我建议上限设为5，超过部分排队，避免触发限流；二是所有展开请求必须携带完整骨架作为上下文，否则模型不知道其他点讲了什么，重复率会很高。

4.4 参数选择的经验值

参数不是玄学，核心是把握好“骨架阶段要稳，展开阶段要活”的原则。

骨架阶段的temperature建议设在0.2到0.3之间。骨架是规划产物，需要稳定可复现，温度太高会导致骨架飘移，经常换角度。max_tokens设200够用，骨架一般不会超过150token。

展开阶段的温度可以稍微抬高到0.4到0.5。展开需要一定的表达自由度，温度太低会让每段像复述标题，内容干瘪。max_tokens按每条展开内容量设定，我通常设250到300，写得长一点的要点也能容纳。

并发数的经验值：展开条数少于等于5时，直接全并发；超过5时，按每5个一批分批展开。还要为展开请求加重试机制，遇到限流或超时至少重试两次，间隔用指数退避，否则某个点超时会导致整轮失败。

5. 我在实际评测中踩过的坑：骨架粒度、重复展开与场景边界

5.1 骨架太粗：展开内容在“注水”

第一次把SoT跑在内部知识问答系统上时，我最直观的翻车点是：展开出来的段落特别像在“注水”。

骨架只有“- 优点：效率高”这种极短描述，展开请求拿到后，模型只能硬凑内容，于是写出来的都是“效率高意味着可以更快完成任务，节省时间，提高用户体验”这类正确的废话。原因很清楚：骨架点携带的信息量太少，展开阶段没有可发挥的指向性。

后来我在骨架Prompt里加了一个隐性约束：每条骨架点必须写成“角度加对象”的形式。比如“优点：效率高”改成“并行展开机制带来高吞吐”，这样展开阶段就有具体论述方向了。调完之后，展开内容的实质信息量上升非常明显。

还有一个同样有效的方法是分层骨架：先只对一级要点做展开，如果一级要点本身很宽泛，就先让它吐出二级要点，再对二级要点展开。这个方案质量更好，但延迟会变长，适合对质量要求高的场景。

5.2 并行展开的一致性：重复与观点冲突

第二个坑是并行展开后的答案经常“各说各话”。

最典型的表现是每个展开段落都从“首先，我们需要理解……”开始，整份答案像四个独立回答硬拼在一起。另一个问题是观点冲突，比如某一点说“应该优先采用方案A”，另一点却说“方案A成本高不可行”。

这个问题要从两个方向同时修：一个是在展开Prompt里明确“不要复述骨架、不要重复背景、默认其他段落已经解释了其他部分，你只需要聚焦当前点”；另一个是在拼接后加一个极轻量的“统一收尾”步骤——让模型读一遍各段，给答案补一个简短开头或过渡，必要时调整重复表述。注意这个收尾步骤不能太重，否则又引入了串行延迟。

5.3 哪些场景不要用SoT

跑了半个多月后，我总结出三类不适合SoT的场景。

第一类是纯事实性短问答。比如“某城市的首都在哪里”，这类问题只需要二三十个token，根本不需要骨架，SoT的固定开销反而让它比普通回答慢。SoT的目标是长文本和复杂结构化回答，不是所有问题都适用。

第二类是强顺序推理。典型代表是数学应用题和多步骤逻辑推导。这类任务的每一步都依赖前一步结果，骨架无法真正切分这些依赖。强行用SoT，要么展开阶段重复计算，要么后一点依赖前一点的具体数值时直接编造。

第三类是高度依赖全局氛围或连贯性的创作型文本。比如写一篇需要前后呼应的短文，SoT并行展开的段落各自为政，最后拼出来的整体感很差。这类场景更适合让模型一次生成，或者在SoT骨架阶段就要求每条骨架点标注好分段之间的衔接关系。

5.4 让SoT和CoT协同的两个进阶组合

SoT和CoT不一定是二选一的关系。我实际用下来有两个组合思路很稳。

第一个组合是“SoT做规划，CoT做局部”。先用骨架完成全局规划，不让骨架点直接展开成独立段落，而是对每个骨架点内部再要求做一次简短思维链推理。这样既享受了并行展开的速度，又不牺牲局部推理质量，适合那些需要证据链的论述题。

第二个组合是“Self-Consistency选骨架”。同一问题生成多版骨架，用简单投票或语言模型评分选出最稳定的一版，再进入展开。骨架生成本身很快，多跑几次的额外消耗不大，但换来的是更可靠的最终答案。尤其在高价值业务场景里，这个组合很值得。

6. SoT打开的思考范式空间：从CoT、ToT到未来的方向

6.1 范式转变的本质：从“写全”到“写对再写全”

CoT的思路是在生成过程中边想边写，把思考过程当作答案的一部分，本质是“一次写完”。SoT把过程拆成“规划”和“执行”两步：先用最少的token把策略定下来，再分头并行执行。这个转变的本质其实是把串行的大块思考压缩成更短的串行规划，再用并行执行换取墙钟时间。

这和项目管理很像。一个合格的负责人不会自己把所有细节全部写出来，而是先定大纲，把任务分给几个人同时推进，最后统一合稿。SoT就是把这个流程搬到了大模型推理里。它带来的启示是：我们优化推理速度时，不一定要追求“每一步都更快”，而是可以思考“哪些步骤本来就不该串行”。

6.2 一张表看懂CoT、ToT、Self-Consistency、SoT的区别

这几个范式经常放在一起比较，我整理了一个对照表：

从这张表能看出，SoT的定位不是替代其他范式，而是补上了“速度”这个维度。它和Self-Consistency还能组合，因为SoT的骨架阶段本身采样成本很低，多采几次做投票的边际代价很小。ToT则更像是SoT的“超集”：如果ToT的中间节点用骨架表示，再把每个分支并行展开，两者可以融合成更复杂的规划搜索体系。

6.3 往前走：层级骨架、Agent规划与训练对齐

SoT最让我兴奋的是它打开的扩展空间。

层级骨架是显而易见的第一步。现在的骨架只有一层，复杂问题时可以拆成两级：一级要点管章节，二级要点管章节内段落。层级骨架能进一步压缩串行时间，也给未来自动生成“长文档目录”提供了训练目标。

另一个方向是Agent规划。Agent在执行多步任务时，目前普遍用ReAct思路边观察边决策，每一步都串行等待。如果先用骨架生成一版“宏观计划”，然后并行执行其中可并行的子任务，Agent的任务完成速度会有质的改变。这个思路已经有一些框架在探索，SoT相当于给它们提供了底层的“计划压缩”语言。

训练对齐层面更有意思。既然SoT依赖模型生成优质骨架，那完全可以在监督微调阶段加入“骨架标注”样本：给定问题和完整答案，标注出最优骨架，让模型学会“先规划再执行”。一旦模型把骨架生成内化成一种能力，推理阶段再配合并行解码，速度和质量的组合空间会更大。公开研究里已经能看到围绕这个方向的工作，Meta相关研究线把SoT推到了前台，让更多人开始认真思考“思考本身如何被压缩与并行”。

我在实际使用中还有个体会：不要一开始就对着一堆复杂问题跑SoT。先拿最熟悉、答案结构最稳定的一批问题，手工写几份“理想骨架”，看看模型自己生成的骨架和理想骨架差在哪，再决定是调Prompt、加拆分规则，还是换更大参数量的模型。这种从基准问题入手的做法，比盲目调参数可靠得多。

最后分享一个小技巧：如果最终答案对排版有强需求，比如需要分节、标题、摘要，你可以直接在拼接阶段把骨架点映射成文档结构，让“展开”和“排版”一步完成。我在知识库问答产品里就是让每个展开请求顺带输出一段带小标题的Markdown块，省掉了一次额外的格式化调用。SoT的扩展点非常多，建议你先从自己的一个长回答场景入手，把延迟数据跑出来，再决定往里挖多深。