Copilot “Plan Mode“ + 多模型协同实战：让复杂项目开发丝滑起飞

优质文章学习记录

10 Apr 2026 — 8 min read

在 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 主动发出提示：