1. 这次不是清理而是把 Copilot 的模型层重新分层10月3日一早我像往常一样打开 VS Code 准备跑测试状态栏里 Copilot 的模型标识已经不是我前两天看到的那个了。切换回聊天面板一看默认模型换成了新梯队里的 Balanced 档代码补全用的 Fast 档也换了底层引擎。GitHub Copilot 这次正式弃用多款旧模型、全面切到新一代模型梯队对日常重度用户来说不是一次简单的“后台升级”而是把之前那套“挑一个最强模型服务所有场景”的做法整个推倒重来。这篇文章不打算复述官方公告而是把我从旧模型迁移到新梯队过程中看到的清单、踩过的坑、实测出来的差异以及我最终调整出来的用法都写出来。无论你是 VS Code、JetBrains 还是 Neovim 用户只要你还在用 Copilot 干活这波调整都值得认真看一遍因为它直接影响你屏幕上每一天出现的代码建议质量。1.1 旧模型下线清单哪些能力被回收了GitHub 官方这次的处理方式不是把模型从服务器里物理删除而是把路由策略改成“新请求不再派发到旧模型”。我用这段时间看到的公告和客户端变化把主要的下线名单整理成了下面这张表实际字段和版本号可能因地区、套餐类型微调但思路是一样的。旧模型标识原来主要负责的场景本次状态官方建议迁移方向GPT-3.5-Turbolegacy code 分支常规代码补全、注释生成、终端命令推荐10月3日起新请求不再路由Fast 档GPT-4.1 / 4.1-mini 系列聊天问答、单文件编辑、代码解释10月3日起不再作为默认选项Balanced 档Claude 3.5 Sonnet旧版接入多文件重构、长上下文分析、复杂代码评审10月3日起不再参与自动路由Heavy 档Gemini 1.5 Pro旧版接入多语言补全、终端命令解释、跨场景问答10月3日起不再作为默认选项Balanced / Local 档很多人看到“Claude 3.5 Sonnet”就以为 Copilot 里还能继续用完整的旧版 Claude其实不是。这次下线的是 Copilot 侧那套专门做的接入分支它和 Claude 家后续新模型是两码事。我的直观感受是旧模型并不是一夜之间所有入口都消失官方留了一个过渡窗口到 10 月中旬左右历史会话里的旧模型才完全不能再继续生成内容。这个窗口期内你在聊天面板里如果手动切到旧模型会看到明显的到期警示如果不小心还把某个旧模型设成了默认客户端会自动回落到新梯队对应的推荐档。1.2 新梯队Fast / Balanced / Heavy / Local 各自负责什么新一代模型梯队最大的变化是不再按厂商名字来区分模型而是按任务类型分成了四个档位。这个设计一开始会让人不太习惯因为它改变了你“选模型”的思考方式。过去我们习惯说“我想用 GPT 或者 Claude”现在官方希望你直接想“我现在是补全、对话还是要跨文件重构”。四个档位的定位如下Fast 档负责光标处的代码补全、多行补全、终端命令推荐。核心指标是首 token 延迟官方目标是把响应时间压到能跟上你打字节奏的级别。这个档位的模型不一定是最聪明的但一定是最快的而且对当前文件、当前函数上下文的跟随能力极强。Balanced 档负责日常对话、内联聊天、代码解释、单元测试生成、基础代码评审。这是大多数开发者能感知到“模型换代”最明显的一档因为它承接了 Copilot Chat 里至少七成以上的请求。Heavy 档负责跨文件重构、大型代码库问答、长日志分析、PR 级评审。它拥有最大的上下文窗口和对多文件引用信息的聚合能力但响应速度明显更慢单次请求的算力成本也高得多。Local 档面向隐私敏感项目、离线环境和企业安全审计需求。这一档不是指本机跑一个开源模型那么简单而是允许你通过配置接入本地或私有化部署的模型端点代码内容不出工作环境。我第一次看到这个分层时第一反应是“这不就是把原来选模型的负担转移给了 GitHub 自己的调度系统吗”。后来用了一周我发现这正是这轮升级最有价值的地方官方不再默认把所有请求都丢给同一个大模型而是让补全、对话、重型任务各走各的通道。这就像一个外卖平台不再要求所有商家都做满汉全席而是按“快餐、正餐、团餐”分流用户拿到的体验反而更稳。2. 为什么选在这个时间点换血成本、路由与“弃用”的真实意图每次模型一换代社区里最常听到的问题就是“旧模型用得好好的为什么非要砍”。答案当然不只是“新模型更聪明”这么简单我把它拆成三层来看成本账、路由逻辑、以及“弃用”这个动作背后真正的产品意图。2.1 算力成本与长上下文收益的平衡从 2024 年到 2026 年模型推理成本的变化方向非常明确单位 token 的算力价格在下降但模型上下文窗口在快速膨胀。旧模型在这件事上很尴尬因为它们当初设计时就没考虑过“一次要读整个仓库”的场景为了支撑长上下文要么牺牲延迟要么直接爆显存。GitHub 这样的平台每天承受海量补全和对话请求如果继续维护多套旧模型光是路由节点、缓存策略、安全补丁的兼容成本就是一笔很大的开销。更重要的是新模型的工程优化可以显著降低推理成本。比如新梯队里的 Fast 档很可能采用了投机解码和小模型先行的策略先用一个轻量模型快速生成候选再用一个更聪明的模型做验收。这种结构在旧模型上根本跑不起来因为旧模型系列本身就是单模型处理所有请求。你可以在官方发布说明里看到每个档位给出的参考延迟和最大上下文数字我自己的观察是Fast 档在常规补全中的首 token 延迟确实比之前快了一个量级Balanced 档在长对话里的上下文保留能力也比旧模型稳定许多。2.2 模型路由器请求进来先分类再决定派给谁这次切换背后最关键的技术变化是“模型路由”。我在本地抓了一下请求的行为模式发现 Copilot 客户端发出的请求会在网关层做一次分类大致分成立即补全、普通对话、重型分析三类。分类器会结合你当前的编辑器动作、选中范围大小、以及你是否在上下文里贴了多文件信息来决定这个请求走哪一个档位模型。这个设计带来的直接结果是你不需要自己手动切模型系统会替你决定。我举个例子你在函数中间打字请求大概率被分到 Fast 档如果你选中一段代码问“这个函数的副作用是什么”请求通常走 Balanced 档当你在聊天框里贴了多个文件路径并且明确要求“对比一下这两个模块的差异”时请求才会被分到 Heavy 档。它的好处是响应速度和生成质量之间的平衡比以前好很多坏处是用户也失去了对“到底哪个模型在回答我”的绝对掌控。后面我会专门讲这个坑怎么绕开。2.3 弃用不等于禁用别把迁移理解成“强拆”官方说“弃用”你千万别理解成“旧模型从世界上消失了”。从产品层面看弃用意味着不再对旧模型进行安全补丁维护不再优化它的上下文缓存也不再把它放进默认路由候选池。但如果你有特殊需求依然可以在某些客户端里通过自定义模型配置把兼容旧接口的端点接进来只是官方不保证它的稳定性也不承担它出问题时的责任。我见过不少团队在看到“弃用”公告后立刻停工排查所有依赖旧模型标识符的脚本其实大可不必。Copilot 的 API 侧和客户端侧对模型标识符都有兼容层你用代码直接调用的场景通常只需要把旧的标识符映射关系更新到新梯队名称真正需要关注的反而是一些老版本的 VS Code 扩展它们可能不认识新的档位名会静默回落到旧配置。这一点在下一章里我会结合踩坑经历细讲。3. 三个真实场景跑下来新旧模型的差距在我这的排序新闻稿里讲参数、讲架构都不如实际敲几行代码来得直观。我花了大概一周时间把新旧两代模型放在我自己手头的三个真实项目里做对比。为了避免拿偶然结果下结论每个场景我都跑了至少十次以下说的都是反复出现的差异。3.1 老代码补全补不补得对比补得快更关键我手头有一个维护了多年、还在用 Vue 2 加 jQuery 的内部系统。以前用旧模型的时候最大的痛点是它太想“证明自己聪明”我写了一半的 Ajax 请求它直接就给我改成 fetch 加 async/await看起来很有现代感但放到这个老项目里就破坏了我们自己封装的异常处理逻辑。旧模型在遇到“项目里到处是过时写法”的情况时倾向于给你生成理想化的现代代码而不是贴合你当前代码库风格的代码。Fast 档给我的感觉很不一样。它明显更注重“接着你当前的思路写”而不是“帮你重写一遍”。比如我在 old-style XMLHttpRequest 的回调里继续写状态处理它会基于当前项目已有的 helper 函数给出补全而不是试图引入一套新请求方案。这种差异不是模型聪明不聪明的问题而是训练目标和路由策略的差别Fast 档的设计目标本来就是低风险、低偏离度地补全上下文。更让我舒服的是Fast 档对文件内局部变量的感知更强。我在一个 800 行的旧组件里补充逻辑它能记住当前方法的局部变量命名风格生成的代码和我手写的风格高度一致这段体验是旧模型没有的。如果你长期被 Copilot 的“自作主张”困扰升级之后应该能明显感觉到收敛。3.2 带坑的 Debug 对话Balanced 档的追问能力调试问题最能体现模型的对话能力。过去我遇到一个偶发内存增长问题把日志贴上问旧模型它回复的套路化比较明显先让你检查循环引用再让你看看是不是有全局变量没释放。这些建议不能说错但基本等于没看你的代码。这次在 Copilot Chat 里问同样的问题Balanced 档的回复明显更“较真”。它会先拆解我贴上去的堆栈片段指出哪些帧只是调用链的常规路径哪些帧的分配模式异常然后主动问我三个关键问题线上流量高峰和内存增长的时序关系、缓存失效机制、以及我是否抓过 heap snapshot。它甚至会根据我的回答在聊天窗口里给出下一步的调试路径建议我先抓一次特定时间点的 GC 日志再根据日志决定要不要看某个类的实例数量。这种把大问题拆成小步骤、并且在关键节点提问的能力是旧模型在对话场景里最明显的短板。当然我得说明Balanced 档也不是每次都惊艳。如果你问的是一个没有上下文的小白问题它和旧模型回答出来的内容差别不大。差距在于复杂问题、需要多轮澄清的问题新模型的语境跟踪能力和“追问意愿”明显高出很多。3.3 跨文件重构Heavy 档的成本让我重新审视任务分配跨文件重构是我最谨慎测试的场景因为它的成本最高。我在一个项目里试着把几个公共工具函数从一个老包迁移到新的内部库涉及约 20 个文件的引用修改和相应测试更新。换到 Heavy 档之前我预期它能直接列出所有受影响的文件结果它做到了而且还给出了每个文件的改动类型哪些只是改 import 路径、哪些需要改函数调用参数、哪些因为返回值类型变化必须连带修改调用处。这个能力旧模型在理论上也具备但实践中很少能跑得好因为旧模型的上下文管理比较弱贴到第三四个文件时就开始丢掉前面的信息导致最后给出的迁移方案前后矛盾。Heavy 档在这轮测试中基本保住了上下文的一致性我照着它给的清单修改没有出现“前一个文件说删、后一个文件说留着”的冲突。不过这里要浇一盆冷水Heavy 档的单次请求等待时间明显更长大概是 Balanced 档的三到五倍。如果只是“解释这两个函数区别”这种问题完全没必要动用 Heavy 档。这也是新梯队给我的一个提醒——学会控制自己的使用习惯不要因为有了更强大的档位就什么请求都往里塞。3.4 实测汇总我把结果压成一张表为了让你更直观看到差异我把三个场景的体感汇总成一张表。这里记录的是我个人主观感受不是公开 benchmark但也算是一个老用户的实际视角。测试场景旧模型综合表现新梯队对应档位表现我的结论老项目代码补全倾向重写经常破坏现有风格Fast 档更贴合当前代码风格局部变量感知强Fast 档补全质量有明显提升复杂 Debug 对话套路化建议缺乏追问Balanced 档能拆解问题、追问关键信息、给可执行 Debug 路径Balanced 档提升最明显跨文件重构上下文多了就丢信息Heavy 档能输出完整迁移清单但响应慢、成本高Heavy 档能力强但必须按需使用另外提醒一句这些测试结论非常依赖你贴给模型的上下文质量。如果你聊天时只丢一句话不给报错堆栈、不贴相关代码片段再好的模型也只能给你泛泛而谈。新模型的确更聪明但它不是读心术好的提问者永远能榨出更多价值。4. 换模型之后容易踩的四个坑以及我怎么绕开的模型切换公告发出来后社区里冒出来一大批“为什么我还没看到变化”“为什么我的模型标识怪怪的”的帖子。我整理了一下自己在迁移期间遇到的、以及在群里帮别人排查过的常见问题挑四个典型的写下来。4.1 Chat 面板和内置聊天是两个东西模型选择器也不一样先说一个特别常见的混淆VS Code 里的侧边栏 Copilot Chat 和编辑器内联聊天看起来都带对话框很多人以为它们是同一个模型的两副面孔。实际上它们走的路由逻辑不一样模型选择器也不共享。侧边栏 Chat 面板会完整保留多轮对话上下文它可以选 Balanced 档或 Heavy 档适合认真分析问题。内联聊天更像是快速问答它默认挂在 Fast/Balanced 档下上下文只打包你当前选中代码、当前文件和最近的对话轮次。这就导致一个现象你在侧边栏切到了 Heavy 档内联聊天不会跟着切内联聊天里问了个大问题收到的回答还是 Fast/Balanced 档的口径。我一开始也以为“同一个 Copilot 应该共享模型选择状态”直到发现两边回答风格差异明显才意识到问题。解决办法很简单先想清楚自己的问题是重型分析还是快速疑问再决定去哪个入口问。不要指望着在一个面板里切模型另一个人口就会自动生效。4.2 模型标识变了但体感没变先查插件版本和组织策略切换到新梯队后我第一次提问发现聊天面板里显示的模型名已经变成新版但回答风格和旧模型几乎一样。排查了半天才发现问题出在 VS Code 插件版本我本地装的扩展还停留在旧版虽然模型标识显示新档位但请求还是走了旧的提示词模板和旧的上下文打包逻辑。升级扩展版本后同样的提问回答质量立刻不一样了。第二个容易忽略的点是组织策略。如果你的 Copilot 账号是通过公司或学校组织统一开通的管理员可能已经锁定了模型档位。也就是说即便你本地手动切换到 Heavy 档后台路由仍然会强制回落到组织配置的档位。这种情况下你自己改前端设置没有作用要么联系管理员调整策略要么就接受组织指定的默认档位。第三个点更隐蔽缓存。客户端可能会缓存旧模型的路由响应尤其是代理环境下。我遇到过一次“模型标识是新的但连续几次回答都是同样的旧风格内容”的情况重启 VS Code 并清理缓存之后恢复正常。遇到换模型但体感没变别急着怀疑官方没切干净按插件版本、组织策略、本地缓存这个顺序排查大多数时候都能找到原因。4.3 教师认证被拒和模型切换没关系别扎堆申请最近热搜里出现了“github copilot教师认证被拒”这个词我点进去看了一圈发现不少老师和学生因为 Copilot 模型切换的消息扎堆跑去申请 GitHub Education 的教师认证和学生认证然后被拒了。有人误以为“是不是新模型只对教育认证用户开放”或者“是不是换模型导致认证规则变严了”。这两个想法都不太对。GitHub Copilot 的新模型梯队对所有订阅用户开放教育认证和模型切换没有直接关系。教师认证被拒通常是因为账号注册时间较短、缺乏仓库活动记录或者提交的材料不符合 GitHub Education 审核要求。这个审核标准和 Copilot 用的是哪一代模型完全无关。更不建议反复提交申请短时间内连续被拒反而可能导致账号被标记影响后续正常申请。认证的事就按教育认证的正常流程准备别把模型切换当成申请的时机信号。4.4 自定义模型和官方模型可以共存但别指望自动路由新梯队推出后有人觉得“官方模型我都控制不了不如直接接自己的模型”于是开始折腾自定义模型端点。Copilot 确实支持在客户端里配置 OpenAI 兼容的模型服务把它作为一个独立选项挂在模型选择器里。但它和官方路由是平行关系不是替代关系你配置的自定义模型不会进入 Fast/Balanced/Heavy 的自动路由池它只会出现在手动选择的位置。我在公司内网项目里把一个私有化部署的模型配置成了自定义模型用途是处理敏感代码的解释和评审代码内容不出内网。这套做法是有效的但我踩了个坑一开始我想把自定义模型设成默认补全模型结果本地打字时延迟非常明显因为补全请求本身是高频低延迟的私有模型在吞吐量上撑不住实时生成的场景。后来我把自定义模型只用在聊天面板的敏感任务场景补全继续走官方 Fast 档两边各干各的体验才稳定下来。所以我的建议是有隐私合规需求就接自定义模型但要给它划定清晰的任务边界不要让它在补全或者超高频对话场景里硬扛。自定义模型是官方梯队之外的“补充档位”不是“替代方案”。5. 对新模型梯队保持清醒分数是别人的体验是自己的模型切换后网上必然会出现各种榜单、跑分、对比测评。我在这个行业里待得久了对分数的态度是参考可以照单全收不行。尤其 Copilot 这类深度集成开发环境的工具最终体验由模型、客户端插件、仓库索引、提示词模板共同决定模型只是其中一环。5.1 模型竞技场分数高不等于你的仓库里好用我在 3.1 里写的那个老项目案例就是典型如果只看模型竞技场分数新模型应该全方位碾压旧模型但在“贴合老项目风格补全”这个具体任务上Fast 档的收敛式设计反而比一个“什么都想改”的大模型更实用。Copilot 的模型档位不是按“谁聪明谁上”分配任务的而是按延迟、成本、风险综合选型。对普通开发者来说真正值得关注的是三个很实际的指标补全是否贴合当前文件风格和局部变量、对话是否愿意追问关键信息、多文件操作是否保持上下文一致。这三个指标只有在真实项目里跑才有意义跟公开排行榜的相关性其实不高。我建议你切换完新梯队后不要急着用 Benchmark 测试题来“验收”先把自己日常最常用的两三个场景跑几遍感受一下延迟和回答风格那才是对你最准确的评估。5.2 本地模型池与官方梯队的关系第五档不是官方给的最后讲一个我在多个技术社区看到的热门方向把本地模型池和 Copilot 新梯队结合起来用。比如在本地用轻量模型做海量代码的初步筛选和注释生成再把关键结论交给官方模型做深度分析。这种做法思路没问题相当于自己搭了一条“预处理 精处理”的流水线但它对硬件和工程能力的要求都不低尤其是本地模型在上下文长度上通常不如云端大模型需要配合仓库向量索引来缩小检索范围。如果你想把本地模型作为 Copilot 的补充我给三个具体建议。第一不要让本地模型承担实时补全任务延迟会让你抓狂它更适合做离线分析、批量注释、代码摘要。第二仓库级知识用向量索引管理而不是把所有文件硬塞进模型上下文否则本地模型很容易因为上下文溢出而答非所问。第三本地模型和官方自定义模型端点属于两条技术路线尽量先想清楚你是为了数据安全、离线部署还是省成本目的不同选型完全不同。这波 Copilot 的模型层换血从我的实际体验看Balanced 档的提升是最容易被感知到的Fast 档在长尾老项目上比想象中稳Heavy 档则提醒我不要滥用大模型。我现在的使用习惯是日常补全交给 Fast解释和单文件修改交给 Balanced只在真正需要跨文件分析时才手动切 Heavy。模型档位不是越高越好选对场景比选最新更重要。