引言
在 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 阶段。
这相当于在施工前先签好了图纸,极大地降低了返工率。









