GitHub Copilot Plan Mode 结合多模型路由的复杂项目实战

三、高阶玩法：'模型路由' (Model Routing) 策略

这是我在实战中摸索出的'独家秘籍'。Gemini Conductor 虽然强大，但目前只能绑定 Gemini 系列模型。而 GitHub Copilot 的最大优势在于它的开放性——你可以根据不同的任务阶段，自由路由到最合适的模型。

我总结了一套 '架构师 + 工匠' 的组合拳：

🧠 Plan 阶段：聘请'严谨架构师' —— GPT-5.3-Codex

• 角色定位：逻辑推理、API 契约制定、异常路径分析。
• 为什么选它：
  • 带有 Codex 后缀的模型通常指令依从性（Instruction Following）极强。
  • 它逻辑严密，能像老法师一样考虑到数据一致性、NATS 消息丢失等架构风险。
  • 在 DDD 架构中，它能守住'领域边界'，不让业务逻辑泄露。

🛠️ Implement 阶段：聘请'优雅工匠' —— Claude Sonnet/Opus 4.6

• 角色定位：代码落地、细节优化、单元测试。
• 为什么选它：
  • 代码品味（Code Taste）极佳：它生成的代码不仅能跑，而且符合现代 Java 风格（Stream 流、Optional 处理等）。
  • 有'代码洁癖'：它会主动检查并移除多余的 Import，生成的代码往往能直接通过 Spotless 检查。
  • 懂'人话'：变量命名清晰，注释写得非常人性化，便于后续维护。

四、实战复盘：企业微信 SaaS 动态 Server 改造

为了证明这套模式的威力，分享一个最近的真实案例。 背景：我们的 SaaS 客服系统基于 Spring Boot + NATS + DDD 架构。 需求：需要将一个动态的 server 参数，从 API 回调入口，穿透 DTO、Listener、Event、Service，一直透传到下游的 API Client。

Step 1: 交互式规划 (GPT-5.3-Codex)

我将 WeComPayload 和 WeComApiClient 的代码发给 Copilot，输入需求。GPT-5.3-Codex 并没有急着给代码，而是先生成了 Decisions（关键决策） 列表供我确认：

Decisions:已定：字段路径 payload.attributes.server 已定：server 值为 host:port，客户端负责补协议并组装 URL关键点：server 缺失时'跳过 + 记录错误'，不回退 wecom.api.base-url 已定：sendTextMessage 与读取接口保持同一动态 server 规则

这一步非常关键！如果它不问，直接回退到旧的 base-url，系统逻辑就乱了。

Step 2: 生成蓝图

确认决策后，AI 生成了包含 5 个大步骤的详细计划：

1. 在消息 DTO 增加 attributes.server 建模。
2. 在入口监听器补齐 server 校验与透传起点。
3. 扩展异步事件模型（GroupSyncEvent 等）承载 server。
4. 让消费服务全链路使用动态 server。
5. 重构 API 客户端为'按次 URL'。

Step 3: 落地执行 (Claude Opus 4.6)

确认 Plan 无误后，我切换模型为 Claude 4.6 点击 "Start Implementation"。Claude 开始分批执行修改。最让我惊喜的一个细节是：在修改 WeComPayload 时，它引入了一个 Map 类，但随即在编译检查时发现该引用实际上未被使用。Claude 主动 发出提示：

'检测到 java.util.Map 引用多余，虽然编译器忽略了，但我将其移除以保持代码整洁。'

Step 4: 结果

最终，整个重构涉及 11 个文件。 编译通过，Spotless 格式化通过，单元测试全绿。 全程没有人工修改一行代码，一次性通过。

五、总结

AI 编程工具正在经历从'玩具'到'工业级武器'的转变。

• 如果你在做 新项目或者存量的小项目， Gemini Conductor 依然是效率之王。
• 但如果你像我一样，正在维护 大型、复杂的存量系统，那么 Copilot Plan Mode + 模型路由 绝对是目前的版本答案。

这套模式不仅让我写代码更快，更重要的是它带给了我久违的**'掌控感'**。我不再担心 AI 会悄悄搞乱我的代码，因为每一个步骤、每一个决策，都在 Plan 阶段经过了我的确认。

拒绝 AI 幻觉，从学会'Plan'开始。 强烈推荐大家在复杂的后端开发中尝试这套打法，体验真正的丝滑开发。