用途
Best-of-N Problem Solving 适用于面对一个难题、且存在多种可能解法的情况,例如复杂重构、棘手的 Bug、性能优化,或你不确定哪种策略最有效的架构决策。
主要能力
该技能使用 Cursor 的 best-of-n-runner 子代理类型创建隔离的 git worktree——每次尝试都拥有自己的分支和工作目录。多种方案可以并行运行而互不干扰。你随后对比结果并选出胜出者。
使用方式
步骤
-
确定方案——在启动之前,定义 2-3 种不同的策略。例如,如果要优化一条缓慢的数据库查询:
- 方案 A:添加复合索引并重写查询
- 方案 B:通过物化视图对模式进行反规范化
- 方案 C:使用 Redis 添加应用层缓存
-
启动并行运行器——对每种方案使用 Task 工具并设置 subagent_type: "best-of-n-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: ..." }每个运行器都会获得自己的分支和 worktree。在提示中包含明确的成功标准(例如“运行测试并报告是否通过”“测量查询时间”)。
-
对比结果——当所有运行器完成后,评估:
- 哪种方案通过了所有测试?
- 哪种实现最整洁?
- 哪种性能特征最好?
- 哪种最易于长期维护?
-
合并胜出者——检出胜出的分支并合并,或挑选特定提交。清理其他 worktree 分支。
适用场景
- 一个可能有多个根因的 Bug
- 在多种模式之间做选择的重构(例如组合 vs. 继承)
- 具有多种策略的性能优化
- 为同一功能尝试不同的库或方法
- 任何“直接试一下”比分析更快的场景
限制与注意事项
- 每个运行器完全隔离——它们无法看到彼此的改动。
- 保持提示具体:包含文件路径、问题陈述和明确的成功标准。
- 对于较简单的问题,这属于过度设计——直接使用单个代理即可。
- 这些分支是真实的 git 分支,因此如有需要,你可以手动检查它们。