GitHub 在 2026 年 9 月 14 日的 changelog 里公布了一件具体的事：Copilot 的 auto model selection 现在提供三个档位——efficiency、balance、intelligence。官方给出的定位很直接：选择一个能反映你希望 auto 如何在成本、质量与响应时间之间做权衡的档位。
这条公告里能被当作事实使用的信息很少，但它把 auto 从一个结果，变成了一个带语义的选择项。
三档命名描述的是偏好，不是模型
官方原文的措辞是 choose the tier that reflects how you want auto to weigh cost, quality, and response time。注意这句话的主语：被选择的是「你希望如何加权」，而不是「使用哪个模型」。
按字面理解，efficiency 落在效率一侧，intelligence 落在能力一侧，balance 居中。这个读法符合命名直觉，但需要明确边界：官方资料没有给出每一档的权重、没有给出任何一档对应的模型、也没有给出任何量化指标。命名是命名，行为是行为，两者之间的对应关系目前只能靠实际验证，不能从单词含义直接推出。
这里真正值得注意的是抽象层级的变化。如果档位直接叫模型名，用户面对的是「用哪个模型」的问题；写成 efficiency / balance / intelligence，用户面对的变成「我愿意为质量多付多少成本、多等多少时间」的问题。从工程角度看，这是把路由决策向上抬高了一层：使用者不必知道候选池里有什么，只需要表达自己的优化目标。至于 Copilot 内部具体如何实现这层选择逻辑，官方资料没有任何描述，不应自行推断。
官方没有说的部分同样重要
围绕这三个档位，公告没有回答的问题至少包括：
- 默认档位是哪一个，是否存在默认值；
- 三档与具体模型之间的映射关系，以及这种映射是否稳定；
- 档位的作用范围——单次会话、账号级，还是可以由组织统一设定；
- 三档之间在计费口径上是否存在差异；
- 该能力的发布状态（公告本身未提供状态描述）。
这些不是可以靠「业界常见做法」填空的地方。对开发团队而言，上面每一条都直接决定接入成本，因此在没有官方说明之前，应把它们当成待确认项，而不是已知前提。
成本、质量、延迟三者本来就无法一次性决定
i-> 需要说明的是，接下来的内容属于工程分析，不是 Copilot 的产品说明。
成本、质量、响应时间这三者在编码助手场景中天然互相拉扯：这是一条通用的工程约束，而不是某个产品的特性。真正的问题在于，这三者的最优组合并不固定，它随任务类型变化。补全式的短片段修改、需要跨文件理解的重构、需要解释和推理的调试问题，对质量和延迟的敏感度完全不同。
一个固定的档位选择意味着对所有任务使用同一套偏好。从工程角度看，可用的做法通常是两类：一是按任务类型区分使用，把高价值、复杂的任务留给质量优先的档位，把机械性、低风险的编辑交给成本优先的档位；二是先在团队内部定义清楚「哪些任务不允许降档」，把它写进规范，而不是交给个人临时判断。
但要提醒的是，如果产品层面不支持在细粒度上区分档位，那么上面第二类做法只能靠人工约束落地，这本身就是需要先确认的事情。
采纳前值得逐条验证的检查项
在把任何一个档位写进团队规范之前，建议先确认：
- 档位的设置入口和作用范围，切换后对当前会话是否立即生效；
- 默认值是什么，以及未显式选择时的行为；
- 是否存在组织级策略可以覆盖成员的个人选择；
- 不同档位在用量统计和计费上是否可区分；
- 用团队自己的任务集做对照：同一批真实问题分别在不同档位下跑一遍，记录结果可用性、需要返工的次数和获取响应的体感；
- 是否具备按档位观测的指标。如果没有分档位的用量、延迟或采纳率数据，降档决策就只能凭感觉，这类决策很难长期坚持。
第 5 条尤其关键。三档命名提供的是方向感，不是可承诺的效果。只有拿自己的代码库和真实任务测过，才知道某个档位在你的场景里省下的是成本，还是返工时间。
一句话判断
这条更新提供的价值不在于三个名字，而在于把「成本—质量—延迟」这组权衡从隐含假设变成了显式选项。它把选择的成本推给了使用者：档位越灵活，团队越需要一套自己的评估口径来兜住它。