前言¶

面對複雜重構、難纏 bug 或架構選型時，開發者常會陷入「先分析再動手」還是「先試再說」的糾結：一條路走到底，容易被錯誤假設鎖死；串行試幾種方案，又會把上下文和時間都耗在來回切換分支上。

best-of-n-solving 正是爲此設計的 Agent Skill：先定下 2～3 條互不干擾的策略，再借助 Cursor 的 best-of-n-runner 子代理，在隔離的 git worktree 裏並行嘗試，最後對比結果、合併贏家。它收錄在 spencerpauly 維護的 awesome-cursor-skills 中，歸類爲 Cursor-Native 工作流。

這是什麼¶

best-of-n-solving 是一份標準的 SKILL.md 技能說明，教 Agent 在難題上採用「Best-of-N」求解流程：每種方案獨佔分支與工作目錄，互不覆蓋，跑完後按測試通過率、實現整潔度、性能與可維護性擇優合併。

官方目錄：

https://github.com/spencerpauly/awesome-cursor-skills/tree/main/resources/best-of-n-solving

Skill 的 YAML 描述寫得很直接：用隔離 git worktree 並行嘗試多種方案，每個 attempt 有獨立分支，再選出最佳解法；適用於複雜重構、棘手 bug，或多種策略都可能成立的架構決策。

需要注意：該 Skill 明確依賴 Cursor 的 best-of-n-runner 子代理類型。SKILL.md 本身可按 Agent Skills 通用格式安裝到其他工具，但「隔離 worktree + 並行 runner」這一能力以 Cursor 側文檔與 Skill 原文爲準。

核心功能與亮點¶

根據官方 SKILL.md，流程可以概括爲四步。

1. 先定策略，再開跑
   啓動前寫清 2～3 條互不相同的方案。官方舉例：優化慢 SQL 時，可以分別嘗試「複合索引 + 改寫查詢」「物化視圖做反範式」和「應用層 Redis 緩存」。

2. 並行啓動 best-of-n-runner
   通過 Task 工具，爲每條方案指定 subagent_type: "best-of-n-runner"，並在同一條消息裏一併發起，讓它們併發執行。每個 runner 獲得獨立分支與 worktree，互不看見對方改動。

3. 按統一標準對比結果
   全部跑完後評估：誰通過測試、誰實現更乾淨、誰性能更好、誰長期更易維護。Prompt 裏應寫明成功標準（例如「跑測試並報告是否通過」「測量查詢耗時」）。

4. 合併贏家，清理其餘
   檢出獲勝分支後 merge，或 cherry-pick 關鍵提交；再清理其他 worktree 分支。分支都是真實 git 分支，必要時可人工檢視。

亮點在於：把「多策略試錯」從串行心智負擔，變成可並行、可回看的工程流程，特別適合「分析成本高、試一把更快」的場景。

安裝與啓用¶

方式一：用 skills CLI 安裝（推薦）¶

社區常用的安裝方式是 vercel-labs/skills 提供的 CLI。只裝這一條 Skill：

npx skills add spencerpauly/awesome-cursor-skills --skill best-of-n-solving

若當前環境以 Claude Code 爲主，可指定 agent：

npx skills add spencerpauly/awesome-cursor-skills --skill best-of-n-solving --agent claude-code

也可用 GitHub 目錄地址作爲源：

npx skills add https://github.com/spencerpauly/awesome-cursor-skills/tree/main/resources/best-of-n-solving

方式二：手動放入技能目錄¶

awesome-cursor-skills 的 README 說明：把現成的 SKILL.md 拷進項目的 .cursor/skills/，Agent 會自動發現。目錄結構建議如下：

.cursor/skills/best-of-n-solving/SKILL.md

按 Cursor 官方 Skills 文檔，技能還會從這些位置加載：

Cursor 爲兼容也會讀取 .claude/skills/、.codex/skills/ 以及對應的用戶目錄。裝好後，可在 Agent 對話裏用 / 搜索 best-of-n-solving 手動調用；描述匹配時，Agent 也可能自動選用。

典型用法示例¶

以下示例直接來自官方 Skill 的步驟說明，可按自己的問題改寫 Prompt。

1. 先列出策略（以慢查詢爲例）

• Approach A：加複合索引並改寫查詢
• Approach B：用物化視圖做反範式
• Approach C：加應用層 Redis 緩存

2. 同一條消息裏並行發起 runner

Task 1: { subagent_type: "best-of-n-runner", prompt: "Approach A: ..." }
Task 2: { subagent_type: "best-of-n-runner", prompt: "Approach B: ..." }
Task 3: { subagent_type: "best-of-n-runner", prompt: "Approach C: ..." }

每個 Prompt 建議寫清：相關文件路徑、問題陳述、成功標準（測什麼、怎麼判定通過）。

3. 對比與合併

runners 結束後，按測試、代碼質量、性能、可維護性選型；然後：

git checkout <winning-branch>
git merge <winning-branch>
# 或 cherry-pick 所需提交後，刪除其餘 worktree / 分支

適用場景與注意事項¶

官方列出的適用場景包括：

• bug 可能有多種根因，需要並行驗證
• 重構時在組合式 vs 繼承等模式間猶豫
• 性能優化存在多種策略
• 同一功能要試不同庫或實現路徑
• 「先試一把」比繼續紙面分析更划算的情況

注意事項（均來自 Skill 原文）：

• 各 runner 完全隔離，看不到彼此的改動，不要假設可以共享中間結果。
• Prompt 要具體：路徑、問題、成功標準缺一不可。
• 簡單問題不必上 Best-of-N，單 Agent 即可，否則是過度設計。
• 產物是真實 git 分支，可人工 git log / git diff 複查後再合併。
• 核心並行能力綁定 Cursor 的 best-of-n-runner；在其他 Agent 中僅安裝 SKILL.md，並不等同於自動具備同一套 worktree runner。

小結¶

best-of-n-solving 把「多方案試錯」寫成可複用的 Agent 工作流：定策略 → 並行 runner → 對比 → 合併贏家。對複雜重構、疑難 bug 和架構分叉尤其有用，也是理解 Cursor 並行子代理與隔離 worktree 的一個清晰案例。

官方地址：

• Skill 目錄：https://github.com/spencerpauly/awesome-cursor-skills/tree/main/resources/best-of-n-solving
• 合集倉庫：https://github.com/spencerpauly/awesome-cursor-skills
• Cursor Skills 文檔：https://cursor.com/docs/skills.md