为什么你的 Claude 还在”单线程”修 bug？

为什么你的 Claude 还在“单线程”修 bug？

你有没有这种感觉：明明给了 AI 编程助手一整排并行失败的任务，它却像老黄牛一样一个接一个啃？明明三个报错互相独立，它硬要串行处理，等你分钟数烧完，才告诉你“第二个问题根因其实是第一个”。

如果你用的是 Claude Code 这套工具体系，obra/superpowers 里的 dispatching-parallel-agents 这个 Skill，可能会改变你的工作流。

这个 Skill 到底做了什么？

一句话：把多任务并行拆给多个子代理，而不是让主代理一个个排队处理。它的触发条件很清晰——当你有 3 个以上互相独立的失败、子系统或 bug，而且彼此之间没有共享状态，就该 dispatch 了。

• 按域分组：把失败按模块 / 测试文件 / 根因切分，每块变成一个独立任务。
• 精确 prompt：每个子代理只拿到它需要的信息，不会继承主会话的历史上下文。
• 一次性并发：在同一轮对话里同时发出多个 subagent 调用，而不是串行等待。
• 回整合并：读取各代理的总结，检查改动冲突，再跑全量测试做最终集成。

谁该用？

如果你是团队里负责多模块调试、批量测试修复、或架构评审的人，这个 Skill 的价值最明显。典型场景：

• CI 里同时挂了 5 个测试文件，报错点完全不相关
• 多个子系统分别被不同 PR 改崩
• 同一份需求要拆成前端 / 后端 / 数据层三个子任务并行推进

我在实际使用中发现，最反直觉的点是：不用怕子代理“少看上下文”。恰恰因为上下文被裁剪到最小，它们反而更专注，不会像主代理那样被历史对话带偏。

注意避坑

它不是银弹。当失败彼此耦合、需要共享状态才能判断根因时，强行并行反而会增加冲突和回滚成本。Skill 里的决策流程图已经帮你把“该不该并行”写得很清楚——先判断独立性，再判断是否需要共享状态。

另一个经验：prompt 质量决定并行效率。任务描述越具体、预期输出越明确，子代理返工的概率越低。

总结

dispatching-parallel-agents 本质上是把“人怎么拆任务”教给了 AI。你负责按域切分，代理负责专注执行，主代理只做协调和合并。对于开发者工具和框架类项目，这种“分而治之”的思路真的很能打。

如果你想给自己的 Claude Code / Cursor / Codex CLI 装上一套更工程化的开发方法论，这个 Skill 值得放进你的 skills 目录。

GitHub：https://github.com/obra/superpowers/tree/main/skills/dispatching-parallel-agents

整个 superpowers 框架主页：https://github.com/obra/superpowers

GitHub: https://github.com/obra/superpowers/tree/main/skills/dispatching-parallel-agents