tree-of-thoughts

tree-of-thoughts 技能總覽

tree-of-thoughts 的用途

tree-of-thoughts 是一種推理工作流程技能，適合不能只看一眼、也不能只給一個答案就收工的任務。它會引導代理探索多種做法，透過 meta-judge 規則進行評分，剪除較弱的分支，最後整合出最佳結果，而不是直接跳到單一解法。

適合誰使用

當任務存在明顯取捨時，就該使用 tree-of-thoughts 技能：像是架構選擇、棘手除錯、規劃、分析，或任何「第一個想法通常不是最好答案」的請求。它特別適合 Agent Orchestration，因為它能把含糊的多步工作轉成「比較後再選擇」的流程。

為什麼它不一樣

它的核心價值不是抽象地「想更多」，而是結構化思考。tree-of-thoughts 會加入明確的探索、評估標準與分支選擇，讓最後輸出比一般 prompt chain 更容易信賴。當你需要更少的幻覺式跳躍、更多站得住腳的決策時，這點尤其重要。

如何使用 tree-of-thoughts 技能

安裝並找到這個技能

先依照 repo 的技能安裝流程操作，然後先打開 plugins/sadd/skills/tree-of-thoughts/SKILL.md。這個技能本體就是行為的主要來源；它沒有可展開的 helper scripts 或 reference folders，所以真正重要的指引都在這個檔案裡。

先給正確的任務輸入

tree-of-thoughts 只有在你的任務被清楚表述為「決策」或「綜合」問題時才真正有用。請提供明確目標、限制條件、成功標準，以及任何固定輸入。好的 prompt 會像這樣：「比較 X 的三種實作方式，以可維護性與延遲為優先，並用明確取捨說明為什麼選這個方案。」不好的 prompt 會像這樣：「幫我處理 X。」

把工作流程當成 prompt 結構

要把 tree-of-thoughts 用得好，最好要求分階段輸出：先產生候選方案，再定義評估規則，接著對各分支評分，最後綜合選定路徑。如果你要把 tree-of-thoughts 用在 Agent Orchestration，還要加入 agent 角色、投票規則，以及分數接近時該怎麼處理。這能避免模型把探索壓縮成單一的泛用回答。

先讀這些部分

先從 SKILL.md 裡的任務、脈絡，以及 phase structure 看起。特別留意描述探索、評判與調整的段落，因為它們最會影響輸出品質。如果你要把這個技能套到自己的技術棧上，先把它的各個 phase 對應到你 repo 裡實際的決策點，再拿去正式使用。

tree-of-thoughts 技能 FAQ

tree-of-thoughts 比一般 prompt 更好嗎？

通常是，前提是問題有多條合理路線，而且你在意的是如何做選擇。一般 prompt 很適合直接回答；tree-of-thoughts 則更適合需要比較、篩選，以及最後做出有理由的選擇時。

這個 tree-of-thoughts 技能適合新手嗎？

可以，只要你能把任務講清楚。你不需要先懂研究文獻也能用得好，但你確實需要提供限制條件，並接受模型應該先探索、再決策。

什麼情況下不該用它？

簡單事實查找、一步式修改，或答案本來就已知的任務，不適合用 tree-of-thoughts。它會增加額外流程，因此最適合用在「值得多花一點推理成本換更好結果」的情境。

它適合 Agent Orchestration 工作流程嗎？

適合。tree-of-thoughts 很適合 orchestration，因為它支援分支提案、多 agent 評估，以及受控的整合步驟。這讓你更容易管理彼此競爭的 agent 輸出，而不是只靠直覺判斷。

如何改善 tree-of-thoughts 技能

給這個技能更強的決策輸入

最大的升級，來自更好的任務框定。請把目標、限制、非目標，以及你要回傳的精確格式都寫清楚。對 tree-of-thoughts 而言，當模型能比較具體選項，而不是從零發明選項時，表現會更好。

把評估標準講明白

如果你希望分支能被有效剪枝，就要告訴這個技能什麼叫「好」。例如：先看正確性，再看速度，最後看實作簡單度。明確的 rubric 能提升 tree-of-thoughts 的使用效果，因為 judge 階段可以用較機械的方式排序，而不是靠猜。

注意常見失敗模式

最常見的失敗，是過度探索卻沒有清楚的決策規則。如果發生這種情況，請縮小分支數量、限制深度，或要求最後一定要提供一個主要建議加上一個備案。這樣可以避免 tree-of-thoughts 變成一場過度繁複的腦力激盪。

透過收緊簡報反覆迭代

如果第一次輸出太寬泛，就沿用同一份 tree-of-thoughts 指引，但補上缺少的脈絡：目標受眾、技術棧、限制條件，以及哪些內容必須保留。若是針對 Agent Orchestration，特別要加入角色邊界與衝突規則，讓最後的綜合結果真的反映你的 agents 實際運作方式。