前言¶
面对复杂重构、难缠 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，流程可以概括为四步。
-
先定策略，再开跑
启动前写清 2～3 条互不相同的方案。官方举例：优化慢 SQL 时，可以分别尝试「复合索引 + 改写查询」「物化视图做反范式」和「应用层 Redis 缓存」。 -
并行启动
best-of-n-runner
通过 Task 工具，为每条方案指定subagent_type: "best-of-n-runner"，并在同一条消息里一并发起，让它们并发执行。每个 runner 获得独立分支与 worktree，互不看见对方改动。 -
按统一标准对比结果
全部跑完后评估：谁通过测试、谁实现更干净、谁性能更好、谁长期更易维护。Prompt 里应写明成功标准（例如「跑测试并报告是否通过」「测量查询耗时」）。 -
合并赢家，清理其余
检出获胜分支后 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 文档，技能还会从这些位置加载：
| 位置 | 作用域 |
|---|---|
.agents/skills/、.cursor/skills/ |
项目级 |
~/.agents/skills/、~/.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
