結構化思考的「鷹架」：利用 Markdown 範本強制 LLM 進入深度思考模式

在與大型語言模型（LLM）協作時，許多使用者習慣透過一段長篇大論的描述（Paragraph Prompt）來要求模型輸出。然而，即使是目前最強大的模型，在面對複雜邏輯或需要嚴謹結構的任務時，依然容易出現「思維跳躍」或「細節遺漏」的問題。

要解決這個問題，最有效的手段不是增加形容詞（如「請詳細地」、「請專業地」），而是為模型提供一個結構化的輸出鷹架（Output Scaffold）。

什麼是「輸出鷹架」？

輸出鷹架是指在提示詞（Prompt）中預先定義好一套嚴格的 Markdown 範本，強制要求模型在生成最終答案之前，必須先填寫特定的思考模組。這本質上是在引導模型進行一種「顯式推理」（Explicit Reasoning），將潛意識的計算過程轉化為可見的文字步驟。

為什麼它有效？

1. 強制路徑依賴：當模型必須填寫 ## 分析維度 時，它會被強迫掃描輸入資訊中所有相關的維度，而不是直接跳到結論。
2. 減少幻覺：透過要求模型先列出 ### 事實依據 $\rightarrow$ ### 推理邏輯 $\rightarrow$ ### 最終結論，任何邏輯斷層在生成過程中都會變得明顯，從而降低憑空捏造的可能性。
3. 標準化交付：對於團隊協作，鷹架確保了無論誰在操作 LLM，產出的結果在結構上都是一致的。

---

實戰案例：深度競品分析工作流程

假設你需要對一個新產品進行競品分析。

❌ 低效提示詞 (段落風格)

「請幫我分析一下 A 產品和 B 產品的區別，重點看功能、價格和使用者體驗，最後給我一個建議。」
結果：模型通常會給出一個泛泛而談的對比列表，缺乏深度挖掘。

✅ 高效提示詞 (鷹架風格)

「請按照以下 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$ 結論）？
• [ ] 格式化要求：是否指定了表格、列表或特定標題層級以增強可讀性？
• [ ] 反向驗證環節：是否包含一個「自我審查」模組（例如：## 自我糾錯：上述分析是否有矛盾之處？）？

常見陷阱與注意事項

1. 避免過度約束：如果範本過於死板（例如要求每個段落必須正好三句話），會限制模型的語言流暢度，甚至導致其為了湊字數而產生廢話。
2. 動態調整：沒有萬能範本。建議先用一個簡單的鷹架跑一次，根據模型的錯誤點（例如它總是漏掉價格分析），再將該項升級為獨立的一級標題。
3. Token 開銷：複雜的範本會增加輸入 Token 數，但在絕大多數場景下，由此帶來的品質提升遠超成本增加。

何時使用 vs 何時不用

使用時機 (Use it when...)	不使用時機 (Avoid it when...)
需要嚴謹邏輯、深度分析、標準化報告時	進行創意寫作、腦力激盪、隨意的聊天時
處理多維度對比、複雜決策樹時	執行簡單指令（如「翻譯這段話」）時
需要將 LLM 輸出直接對接至下游文件系統時	需要模型自由發揮、探索未知方向時