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 的最大优势在于它的开放性——你可以根据不同的任务阶段,自由路由到最合适的模型。

我总结了一套'架构师 + 工匠'的组合拳:







