sequential-thinking

已弃用 — Opus 4.7 使用自适应思考（每一步均可选择是否启用），而 Sonnet 4.6 原生支持结构化思维链。对于大多数任务，提示“请仔细、循序渐进地思考；这比看起来 更难”即可引出所需的推理深度。无论模型选择何种自适应思考方式，在需要确定性且 可审查的推理轨迹时（审计、证明、事后分析），仍保留此方法作为参考模式。

顺序思考

一种结构化、反思式的问题解决方法，用零成本的指导性提示取代 Sequential Thinking MCP 服务的 sequentialthinking 工具。

取代：@modelcontextprotocol/server-sequential-thinking（每轮 1 个工具，可节省约 1,800 个令牌）

快速参考

能力	旧 MCP 工具	新方法
分步推理	sequentialthinking(thought, thoughtNumber, ...)	按照下文的方法执行
修订思路	sequentialthinking(isRevision=true, revisesThought=N)	内联修订协议
探索分支	sequentialthinking(branchFromThought=N, branchId=...)	分支标记协议
动态调整范围	sequentialthinking(needsMoreThoughts=true)	范围重新评估检查点
验证假设	sequentialthinking 循环，直到 nextThoughtNeeded=false	先验证再下结论协议

前提条件

无。这项技能纯粹是方法论，不需要 CLI 工具、API 或身份验证。

核心方法

结构化问题解决协议

遇到复杂的多步骤问题时，请遵循此协议。MCP 工具以机械方式强制执行的关键行为， 现在已转化为明确的步骤。

1. 评估范围

开始之前，估算问题的复杂度并明确说明。

“这大约需要 N 个步骤。我的拆解如下：……”

将问题分解为 3–7 个子目标。如果无法拆解，说明问题可能需要先澄清——请先提问， 再继续处理。

2. 按编号逐步执行

按照明确的结构逐步完成：

• 第 N 步，共 M 步 — 说明此步骤的子目标
• 展示推理或工作过程
• 说明中间结论
• 明确衔接下一步：“这意味着第 N+1 步需要……”

不要跳步。每一步都必须产出具体、可验证的中间结果。

3. 修订检查点

每完成 3–4 步后，必须进行一次自我检查：

**检查点：**我是否仍在正确的轨道上？

• 根据目前学到的信息，之前的结论是否仍然成立？
• 问题范围是否发生了变化？
• 我的假设是否仍然有效？

如果需要修订，请明确说明：

**修订第 N 步：**我先前关于 [X] 的结论是错误的，因为 [Y]。 修正后的结论是 [Z]。这会影响后续步骤 [列出受影响的步骤]。

这取代了 MCP 的 isRevision 和 revisesThought 参数。关键做法是：说明发生了什么变化、 原因是什么，以及这会使哪些后续结论失效。

4. 探索分支

如果存在多种可行方案，不要默默选择其一。要清楚展示分歧点：

分支点（来自第 N 步）：

方案 A — [标签]：[简要说明及可能结果] 方案 B — [标签]：[简要说明及可能结果]

评估：[用 1–2 句话比较关键权衡] 选择方案 [X]，因为[理由]。

这取代了 MCP 的 branchFromThought 和 branchId 参数。其价值在于明确展示决策点及理由， 而非机械地创建分支。

对于影响尤为重大的分歧，可以先简要探索两个分支（每个分支 2–3 步），再做出选择， 而不是一开始就选定方案。

5. 动态调整范围

如果在分析过程中发现问题的规模比预估的大或小：

**范围更新：**最初预估为 N 步，现在预估为 M 步，因为[原因]。

这取代了对 needsMoreThoughts 和 totalThoughts 的调整。不要为了符合最初的预估而刻意压缩推理过程——准确性比预估更重要。

6. 验证与结论

在给出最终答案之前，务必：

1. 重述：用自己的话重述原始问题
2. 梳理：追溯解决路径：“步骤 1→3→5 确立了[X]，步骤 4→6 确立了[Y]”
3. 验证：对照所有明确提出的约束和要求进行检查
4. 标明：指出尚存的不确定性或假设
5. 总结：仅在满足所有约束后得出结论

**验证：**此解决方案是否满足所有要求？

• [要求 1]：✓ 已满足，依据为[步骤引用]
• [要求 2]：✓ 已满足，依据为[步骤引用]
• [要求 3]：⚠ 部分满足——[说明缺口及补救措施]

这取代了 nextThoughtNeeded=false 这一终止条件。MCP 要求明确说明思考已完成；该方法通过验证清单实现这一点。

输出格式

顺序思考会话的输出包含以下结构：

• 编号思考——每条标记为 Step N of M，包含子目标陈述、推理过程和中间结论
• 修订标记——内联的 Revising Step N: 区块，说明更改内容、原因，以及会影响哪些后续步骤
• 分支指示——Branch Point (from Step N): 区块，列出不同方案，并说明选定方案及其理由
• 范围更新——当对步骤数量的预估在分析过程中发生变化时，使用 Scope Update: 行
• 验证区块——最终清单，逐项确认每个要求均已满足，并注明步骤引用；在得出结论前标明尚未解决的不确定性

校准规则

• **深度与复杂度匹配：**简单问题（单一决策、约束明确）适合 3–5 条思考。中等问题（多步骤且需要权衡）适合 5–10 条。复杂问题（架构、级联故障调试、形式化推理）适合 10 条或更多——不要刻意压缩。
• **修订体现质量：**会修订早期步骤的思考会话，比不加自我纠正、一路线性推进的会话更可靠。修订并非失败，而是方法按预期发挥作用。
• **深度优先于广度：**与其浅尝辄止地列出许多选项，不如更深入地探索较少的分支。只有当不同方案的选择会实质性改变结果时，才值得探索该分支。
• **如实说明范围：**如果最初估计的步骤数量有误，应明确更新。中途准确修正，胜过强行让结论符合过时的估计。

常见工作流

深度调试

诊断复杂错误或系统问题时：

1. 复现——准确描述观察到的行为与预期行为
2. 假设——提出 2–3 个候选根因，并按可能性排序
3. 缩小范围——针对最可能的假设，确定能够证实或证伪它的最小测试
4. 测试——执行测试并观察结果
5. 迭代——如果假设被证伪，则转向下一个假设；如果得到证实，则追溯根因
6. 验证修复——确认修复解决了根因且未引入回归问题

在第 2 步使用分支探索，明确列出相互竞争的假设。

架构决策

进行系统设计或技术选型时：

1. 界定 — 说明决策、约束条件，以及带权重的评估标准
2. 列举 — 列出可行方案（建议 3–5 个）
3. 评估 — 根据标准为每个方案打分；使用决策矩阵
4. 压力测试 — 针对排名前 1–2 的方案，探查失效模式和边界情况
5. 决策 — 明确作出选择，并说明理由和已记录的权衡
6. 记录 — 说明哪些情况会促使你重新审视此决策

数学／形式化推理

进行证明、推导或形式验证时：

1. 陈述 — 精确表述命题或目标
2. 确定 — 确定证明策略（直接证明、反证法、归纳法、构造法）
3. 推导 — 逐步进行，并用具名规则或引理为每一步提供依据
4. 检查 — 继续之前，检查每一步是否有效
5. 验证 — 确认证明完整（覆盖所有情况，没有遗漏）

积极使用修订检查点——形式化推理存在较高的级联错误风险。

错误处理

问题	原因	修复方法
推理陷入循环	缺少修订检查点	强制设置检查点：重述目标，检查是否重复了之前的结论
范围不断扩大	问题定义不充分	暂停并拆分为相互独立的子问题；先解决最小的子问题
无法在不同分支间选择	评估标准不明确	比较方案前，明确评估标准并设定权重
结论不满足约束	跳过了验证步骤	给出答案前，运行完整的验证检查清单
先前步骤被推翻	新信息与假设矛盾	明确修订：指出相关步骤、错误以及所有下游影响

局限性

• 不同对话之间没有持久状态。 MCP 服务会在会话内维护思路历史记录。此方法依赖对话上下文窗口；在单次对话中，这与之等效，但无法跨会话持久保存。
• 没有程序化的思路图。 MCP 会为每个思路步骤返回结构化 JSON，理论上可供其他工具使用。此方法改为生成自然语言。实际上，MCP 的 JSON 输出很少以程序化方式使用。
• 需要自律。 MCP 会机械地强制执行步骤编号和检查点结构。此方法依赖 Claude 遵循协议。实际上，对于推理模式，明确的指令与工具调用强制执行同样可靠。

Token 节省分析

指标	MCP（每轮）	Skill（每轮）	节省量
Schema 开销	~1,800 tokens	0 tokens（按需加载）	~1,800 tokens/轮
20 轮对话	~36,000 tokens	~300 tokens（一次性加载）	~35,700 tokens
工具调用开销	~200 tokens/调用	0（原生推理）	~200 tokens/调用

Sequential Thinking MCP 是投资回报率最高的转换之一，因为它每轮都会消耗大量 schema token，而 Claude 通过提示词便可原生复现其功能。