在 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"开始。 强烈推荐大家在复杂的后端开发中尝试这套打法，体验真正的丝滑开发。
本文由mdnice多平台发布