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