Bugfix / Refactor / Test Tooling
维护型任务的工具组合不该靠偏好拍脑袋，而该根据“问题发生在哪、验证发生在哪、最终谁收口”来选。多数时候你不需要最重的工具栈，只需要最短的证据链。
默认组合
| 场景 | 默认工具 | 为什么合适 | 什么时候切换 |
|---|---|---|---|
| 终端内维护 | Claude Code | 最适合仓库内读代码、跑命令、保留验证证据。 | 需要更长执行链时切到 OpenAI Codex。 |
| IDE 内小步修复 | Cursor | 适合局部实现和快速验证。 | 需要更强 repo pairing 时回终端。 |
| 平台内交接 | GitHub Copilot | 适合把 issue、PR 和 review 串起来。 | 本地探索价值大于平台 流时先别上平台。 |
选择顺序
- 先看问题发生在哪里，是终端、IDE 还是平台任务系统。
- 再看验证发生在哪里，是命令、测试、截图还是 reviewer 判断。
- 最后再决定是否需要平台补位，而不是一开始就把所有入口混进来。
默认搭配建议
- 终端内小步维护优先走 Claude Code。
- IDE 内局部改动优先走 Cursor。
- 需要把结果回收到平台 review，再补 GitHub Copilot。
- 如果任务从“局部修复”变成“长链路执行”，及时切到 OpenAI Codex。
最小落地包
- 一个能稳定复现或定位问题的入口。
- 一组固定验证命令或回归步骤。
- 一种默认执行入口，不要三种工具同时起步。
- 一种默认收口方式，例如 PR、issue comment 或变更说明。
什么时候换组合
- 当验证已经明显依赖命令链和 worktree，终端优先。
- 当主要成本在交互式编辑和局部试错，IDE 优先。
- 当主要成本在 reviewer、任务系统和审批，平台优先。
- 当同一任务开始需要并行 lane，改读 Parallel Worktrees / Multi-Agent Tooling。