Copilot Plan Mode + 多模型协同实战：让复杂项目开发丝滑起飞
在 AI 辅助编程普及的今天，我们似乎习惯了'Tab 键一路狂飙'的快感。但在面对大型存量项目（Legacy Code）时，这种快感往往会变成惊吓——AI 生成的代码看似完美，实则破坏了原有的架构逻辑，或者引入了难以排查的幻觉（Hallucinations）。
作为一名后端开发者，我在工具链的探索上走了不少弯路。从 Spec Kit 到 Gemini Conductor，再到如今的 GitHub Copilot Plan Mode，我终于找到了一套适合 复杂业务架构 的'最佳实践'。
今天想和大家分享这套 'Plan + Implement' 模式 配合 '多模型路由' 的打法，它让我的开发体验发生了质变。
一、引言：寻找大型复杂项目的'银弹'
在探索 AI 编程工具的过程中，我经历了三个阶段的心态变化：
1. Spec Kit 的严谨与繁琐
起初，为了保证代码质量，我尝试过 Spec Kit。它确实严谨，能强制 AI 遵循规范。但它的配置过程实在是太'重'了，写代码前要先写一堆 Spec，感觉像是在给 AI 打工，很难在日常快速迭代中坚持下来。
2. Gemini Conductor 的惊艳与局限
后来，Google 推出的 Gemini Conductor 让我眼前一亮。
- 优点：对于 从零开始的新项目或者 独立的小脚本，它简直是神器。你给它一个指令，它能全自动把文件建好、代码写好、测试跑通。
- 痛点：但当我把它用到 现有的、庞大的 SaaS 系统中时，问题来了。Conductor 缺乏对旧系统的整体认知。要让它在百万行代码里精准修改一个逻辑，我需要前期人工积累大量的 Skills（技能）和 Tools（工具）来辅助它。对于老项目来说，这个'冷启动'成本太高了。
3. 发现新大陆：Copilot Plan Mode
就在我苦恼于'新项目太爽，老项目太累'的时候，GitHub Copilot 推出的 Plan + Implementation 模式 完美填补了这个空白。
它不需要预先配置复杂的 Skills，却能通过**'交互式规划'**快速理解复杂的业务上下文。这正是我在维护复杂老项目时最需要的——手术刀般的精准度，而不是推土机般的破坏力。
二、核心模式解析：'Plan + Implement' 为何如此好用？
1. 痛点：Ask + Agent 模式的'最后一公里'迷失
以前我们用 Copilot 的 Ask + Agent 模式时，流程通常是：先在 Chat 框里和 AI 聊（Ask），聊得差不多了，再让 Agent 去执行。
但这中间存在一个致命的断层：没有一个'最终确认'的环节。 虽然我在 Ask 阶段聊了很多，但到了 Agent 实现阶段，AI 可能依然存在理解盲区。因为它没有显式地总结出一份'行动指南'让我确认，一旦它在某个不懂的细节上开始'自由发挥'，就会产生幻觉。这种不确定性，导致我在 Code Review 时经常还要回头去修它生成的 Bug。
2. 解法：Plan Mode 的'契约精神'
Plan Mode 的核心价值在于，它在 Thinking（思考）和 Coding（编码）之间，插入了一个**'达成共识'**的步骤。
在 Agent 写下一行代码之前，它必须先交出一份 Plan（计划书）。
- 如果 Plan 里有我想法不一样的地方（比如异常处理策略），我直接在 Plan 阶段修正。
- 只有当我和 AI 对 Plan 达成一致后，它才会进入 Implement 阶段。
这相当于在施工前先签好了图纸，极大地降低了返工率。
三、高阶玩法：'模型路由' (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 个大步骤的详细计划：
- 在消息 DTO 增加 attributes.server 建模。
- 在入口监听器补齐 server 校验与透传起点。
- 扩展异步事件模型（GroupSyncEvent 等）承载 server。
- 让消费服务全链路使用动态 server。
- 重构 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'开始。 强烈推荐大家在复杂的后端开发中尝试这套打法，体验真正的丝滑开发。
