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 个大步骤的详细计划：

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”开始。 强烈推荐大家在复杂的后端开发中尝试这套打法，体验真正的丝滑开发。

本文由 mdnice 多平台发布