结构化思考的“脚手架”：利用 Markdown 模板强制 LLM 进入深度思考模式

在与大模型（LLM）协作时，很多用户习惯于通过一段长长的描述（Paragraph Prompt）来要求模型输出。然而，即使是目前最强的模型，在面对复杂逻辑或需要严谨结构的任务时，依然容易出现“思维跳跃”或“细节丢失”的问题。

要解决这个问题，最高效的手段不是增加形容词（如“请详细地”、“请专业地”），而是为模型提供一个结构化的输出脚手架（Output Scaffold）。

什么是“输出脚手架”？

输出脚手架是指在 Prompt 中预先定义好一套严格的 Markdown 模板，强制要求模型在生成最终答案之前，必须先填充特定的思考模块。这本质上是在引导模型进行一种“显式推理”（Explicit Reasoning），将潜意识的计算过程转化为可见的文本步骤。

为什么它有效？

1. 强制路径依赖：当模型必须填写 ## 分析维度 时，它会被迫扫描输入信息中所有相关的维度，而不是直接跳到结论。
2. 减少幻觉：通过要求模型先列出 ### 事实依据 $\rightarrow$ ### 推理逻辑 $\rightarrow$ ### 最终结论，任何逻辑断层在生成过程中都会变得明显，从而降低凭空捏造的可能性。
3. 标准化交付：对于团队协作，脚手架确保了无论谁在操作 LLM，产出的结果在结构上是一致的。

---

实战案例：深度竞品分析工作流

假设你需要对一个新产品进行竞品分析。

❌ 低效 Prompt (Paragraph Style)

“请帮我分析一下 A 产品和 B 产品的区别，重点看功能、价格和用户体验，最后给我一个建议。”
结果：模型通常会给出一个泛泛而谈的对比列表，缺乏深度挖掘。

✅ 高效 Prompt (Scaffold Style)

“请按照以下 Markdown 模板分析 A 与 B 产品。在填写每个部分前，请确保已检索所有已知事实。”

[模板开始]

1. 核心价值主张 (Value Proposition)

• 产品 A: [一句话描述其解决的核心痛点]
• 产品 B: [一句话描述其解决的核心痛点]
• 差异点: [两者在定位上的根本分歧]

2. 功能矩阵对比 (Feature Matrix)

功能维度	产品 A 实现方式	产品 B 实现方式	胜出方/评价
[维度1]	...	...	...

3. 用户体验摩擦点 (UX Friction)

• 产品 A 的痛点: [具体场景 $\rightarrow$ 用户感受 $\rightarrow$ 原因]
• 产品 B 的痛点: [具体场景 $\rightarrow$ 用户感受 $\rightarrow$ 原因]

4. 推理结论与策略建议

• 逻辑链条: [事实 A + 事实 B $\rightarrow$ 推论 C]
• 最终建议: [基于上述分析的具体行动项]
  [模板结束]

---

构建脚手架的 Checklist

当你设计自己的工作流模板时，请检查是否包含以下元素：

• [ ] 强制约束项：是否使用了 [ ] 或 ... 来明确提示这里需要填充内容？
• [ ] 逻辑递进关系：模板的顺序是否符合人类思考逻辑（例如：观察 $\rightarrow$ 分析 $\rightarrow$ 结论）？
• [ ] 格式化要求：是否指定了表格、列表或特定标题级别以增强可读性？
• [ ] 反向验证环节：是否包含一个“自我审查”模块（例如：## 自我纠错：上述分析是否有矛盾之处？）？

Gotchas & 注意事项

1. 避免过度约束：如果模板过于死板（例如要求每个段落必须正好三句话），会限制模型的语言流畅度，甚至导致其为了凑字数而产生废话。
2. 动态调整：没有万能模板。建议先用一个简单的脚手架跑一次，根据模型的错误点（例如它总是漏掉价格分析），再将该项升级为独立的一级标题。
3. Token 开销：复杂的模板会增加输入 Token 数，但在绝大多数场景下，由此带来的质量提升远超成本增加。

何时使用 vs 何时不用

使用场景 (Use it when...)	不使用场景 (Avoid it when...)
需要严谨逻辑、深度分析、标准化报告时	进行创意写作、头脑风暴、随意的聊天时
处理多维度对比、复杂决策树时	执行简单指令（如“翻译这段话”）时
需要将 LLM 输出直接对接至下游文档系统时	需要模型自由发挥、探索未知方向时