Local -> Background -> Cloud Tooling
这条主线的工具组合不是“哪个最强”，而是“哪一个最适合 discovery，哪一个最适合长执行，哪一个最适合正式收口”。三层只要有一层选错，handoff 成本就会抵消全部收益。
默认组合
| 角色 | 默认工具 | 作用 | 什么时候切换 |
|---|---|---|---|
| 本地发现 | VS Code Agents | 在本地读代码、缩边界、写 brief。 | 如果 discovery 主要发生在终端，改用 Claude Code。 |
| 后台执行 | OpenAI Codex | 承担更长执行链和异步推进。 | 只做轻量后台补位时可用更轻入口。 |
| 平台收口 | GitHub Copilot | 在 PR、任务系统和 review 流里收口。 | 若团队不以 GitHub 为主系统，则需换平台层。 |
选择顺序
- 先确认 discovery 发生在哪里，是 IDE、终端还是平台。
- 再确认后台执行入口和验证要求。
- 最后确认最终 review 和 merge 发生在哪里。
默认搭配建议
- 不要让后台阶段重新做 discovery。
- 不要让平台阶段承担理解任务边界的责任。
- 三层之间传递的核心产物始终是 brief、日志、diff 和验证结果。
- 如果本地和后台边界切不出来，就别强行套三层模型。
最小落地包
- 一个本地阶段输出模板。
- 一个后台阶段日志和阶段总结模板。
- 一个平台层 PR 或任务更新模板。
- 一套明确的“什么时候停、什么时候交、什么时候切回本地”的规则。
什么时候换组合
- discovery 需要强 IDE 控制面时，VS Code Agents 更自然。
- 长链路推进和并行执行更重时，Codex 之类执行栈更合适。
- 团队最终收口不在 GitHub 时，平台层要按真实工作系统调整。
- 如果三层模型开始拖慢节奏，改回 Terminal-First Repo Pairing Tooling 或 Bugfix / Refactor / Test Tooling。