10% 的自动选模折扣，并不等于 Intelligence 一定更贵或 Efficiency 一定更省。 GitHub 官方说明，付费 Copilot 计划使用自动选模时可获得 10% 的模型成本折扣，但实际用量仍按自动路由最终选择的模型计算。(自动选模官方文档)
获胜者：Balance 做团队日常基线；Efficiency 承接低风险、重复性任务；Intelligence 只处理复杂重构、疑难排查和高风险 Agent 任务。 三档共享当前可用模型池，档位只是改变路由偏好，不是三个固定模型套餐。你不能只看档位名称，也不能把 Intelligence 直接理解为“永远调用最强模型”。
这篇文章适合三类人：
- 研发负责人：需要给不同代码任务制定统一、但不过度僵化的选模策略。
- 平台工程师和企业管理员：需要核对模型政策、客户端覆盖、AI credits 和实际运行记录。
- 使用 Agent、CI 或 Xcode 交付的团队：需要把模型响应、远程执行环境、返工和构建结果分开验收。
最后更新于 2026 年 9 月 19 日，数据核实自 GitHub Changelog、自动选模官方文档、支持模型文档、模型权限配置文档及 AI credits 计费说明。
GitHub Copilot 自动选模三档，先按任务复杂度分流
GitHub 在 2026 年 9 月 18 日的 Copilot 周更新中确认，自动选模新增 Efficiency、Balance 和 Intelligence 三档，并向 VS Code、Copilot CLI 与 GitHub Copilot app 推出。(GitHub Changelog 更新)
但三档并不是固定模型映射。官方文档明确说明，三档使用同一组可用模型，差别在于每次提示词的路由偏好：Efficiency 偏向成本，Balance 同时权衡成本、质量和延迟，Intelligence 偏向复杂任务的回答质量。即使选择 Intelligence，简单提示也可能被分配到较轻量模型。
你可以先使用下面的基线：
- ✅ Efficiency：文档补全、测试样例生成、格式调整、变量重命名、小范围可逆修改。
- ✅ Balance：日常功能开发、普通 Bug 修复、单模块测试、代码解释和常规 PR 修改。
- ⚠️ Intelligence：跨文件重构、复杂并发问题、难以复现的故障、架构迁移和需要多轮工具调用的 Agent 任务。
不要按职位统一配置。例如，资深工程师也会处理大量低风险批量修改；初级工程师遇到跨模块故障时，也可能需要更高质量的推理路线。正确单位是“任务类型”，不是“员工级别”。
第一步：把 AI credits 和完整任务成本拆开
AI credits 的关键不是档位，而是最终模型和 Token 数量。GitHub 文档说明，输入 Token、输出 Token 和缓存 Token 都会影响消耗；当前计费规则中，1 AI credit = 0.01 美元。(Copilot 计费与用量文档)
因此，一次看起来便宜的回复，不一定代表整个任务成本低。你至少要记录以下五项：
- 首次回答是否可用。
- 是否需要重复提示或重新描述上下文。
- Agent 是否失败重试。
- 开发者是否需要手动返工。
- 最终测试和构建是否通过。
例如，一个 Efficiency 回复只花少量 credits，但遗漏了接口边界，随后触发三轮补充提示和一次人工重构；另一个 Balance 回复一次完成。前者的单次响应成本更低，完整任务成本却可能更高。
长 Agent 任务尤其不能只看一条消息。GitHub 说明，Agent 模式可能在一个任务中进行多次模型调用；大型代码库、长上下文和复杂工具编排都会增加用量。
你应当把成本分成两本账：
- 模型账：模型、Token、AI credits、重试、上下文长度。
- 执行账：Agent 在线时间、远程工作区、CI、测试机、云端 Mac 和构建队列。
这样才能判断问题究竟是模型选档不合适，还是执行环境容量不足。
第二步：用延迟和失败率决定是否回退
“变慢”不一定是 Intelligence 的责任。至少有四种延迟需要分开：
- 模型生成第一段响应的时间。
- Copilot 服务或模型池的可用性。
- Agent 排队和工作区启动时间。
- 外部工具、依赖安装、测试和构建耗时。
GitHub 的自动选模机制会结合实时系统健康、模型可用性和任务复杂度进行路由；官方也表示，自动选模可以绕开繁忙或降级模型，减少限流和错误。(GitHub 自动选模更新)
但这不是“Intelligence 永远更稳定”的证明。团队应在同一代码库、相同提示词、相同工具权限下记录：
- 简单任务的首字节响应时间。
- 复杂任务的总完成时间。
- Agent 中断、超时和重试次数。
- 高峰期与非高峰期的差异。
- 测试执行前后的额外等待时间。
如果复杂任务主要卡在依赖安装或 Xcode 构建，切到 Efficiency 不会解决根因；如果模型反复误解需求，增加云端 Mac 容量也不会解决根因。你需要先定位等待发生在哪一层。
第三步：核对客户端、计划和管理员政策
自动选模的实际路由范围，会被计划、客户端和管理员策略共同限制。GitHub 官方文档列出，自动选模不会使用以下模型：
- 当前计划不可用的模型。
- 被组织或企业管理员禁用的模型。
- 不符合数据驻留或 FedRAMP 要求的模型。
- 被 Evaluation model 策略排除的模型。
不同入口也不完全相同。当前官方说明，带任务优化的自动选模已覆盖 GitHub 网站、VS Code、Copilot CLI 和 GitHub Copilot app；其中三档自动选模主要出现在 VS Code、Copilot CLI 和 GitHub Copilot app。JetBrains、Eclipse、Xcode 和 Visual Studio 也支持自动选模，但支持形态可能偏向可用性和可靠性优化，而不是完整三档控制。
所以，管理员不能只在企业设置中看一遍模型列表，然后假设所有开发入口一致。你应当让代表性用户在实际客户端完成一次验证：
- 模型选择器是否显示三个档位。
- 回复后是否能查看实际使用模型。
- 企业禁用模型后，自动路由是否真的避开该模型。
- 数据驻留和合规策略是否缩小了模型池。
- usage dashboard 是否能按实际模型归集记录。
GitHub 已支持在使用指标中把原先的“Auto”归因到实际模型名称，方便管理员检查团队到底使用了哪些模型。(Copilot 使用指标更新)
第四步：Agent 交付要经过五层验收
Agent 任务的最终结果，不是“回答看起来合理”，而是代码能否交付。你可以按下面五层检查：
- 响应层：解释是否符合仓库约束，是否引用了正确文件。
- 修改层：变更范围是否可控，是否产生无关文件或危险重构。
- 执行层：依赖安装、脚本、测试和静态检查是否真的运行。
- 协作层：Pull Request、提交信息和审查意见是否可追溯。
- 交付层：构建、签名、打包和部署是否通过。
Intelligence 可能提高复杂任务的路由偏好，但不能替代确定性测试和人工复核。对于 iOS 或 macOS 项目，尤其要把 Xcode 构建放在独立验收层。模型完成代码修改，不代表真实 Mac 环境已经完成：
- Xcode 工程解析。
- 模拟器或真机测试。
- 证书与签名。
- 多架构构建。
- 归档和导出。
- CI 产物检查。
如果你使用云端 Mac，模型消耗和 Mac 工作区占用也要分开记录。一个任务可能 AI credits 不高，却因为等待依赖、并发测试或构建队列而长时间占用工作区；也可能模型返工次数增加，导致工作区在线时间明显上升。只有把两组数据放在一起，才能判断应当切换档位，还是增加执行环境容量。
组织级默认策略：先用 Balance，再按证据切档
下面这张表适合作为团队初始配置，不是永久规则。你需要在一周代表性任务记录后重新评估。
| 任务类型 | 默认档位 | 适合的任务 | 需要观察的证据 |
|---|---|---|---|
| 低风险、重复性任务 | Efficiency | 文档、格式、简单测试、局部补全 | 是否出现重复提示、返工和漏改 |
| 日常开发任务 | Balance | 普通功能、常规 Bug、单模块修改 | 成功率、延迟、AI credits、测试结果 |
| 复杂跨文件任务 | Intelligence | 重构、疑难故障、复杂 Agent 编排 | 是否减少返工，是否真正通过测试与构建 |
| 无法稳定复现收益的任务 | 保持原档或手动选模 | 结果波动大、数据不足的任务 | 是否有同条件回归证据 |
不要把 Intelligence 设成所有人的永久默认值。官方文档虽然把它定义为质量优先，但也明确表示最终费用仍按实际选中的模型计算；模型列表和可用性还会随计划、客户端和政策变化。
决策条件列表
- 若任务是小范围、可回滚、验收简单的修改，先选 Efficiency；如果出现两次以上重复提示或人工返工，再回退到 Balance。
- 若任务是日常功能开发，且需要在速度和质量之间保持平衡，选 Balance；只有连续记录显示复杂任务返工明显，才升级。
- 若任务跨越多个模块，涉及并发、架构或疑难故障，选 Intelligence；如果耗时主要来自测试、依赖或云端 Mac 排队，则不要继续升级模型。
- 若企业政策限制了模型池，先确认实际可用模型，再决定档位；无法查看实际路由时，不要依据名称做成本承诺。
- 若 Agent 任务无法稳定复现，保持原档或改为手动选模，先补齐测试、日志和构建证据。
用两张表完成团队回归验收
第一张表用于记录一次完整任务，而不是单条聊天回复。GitHub 官方建议通过 usage dashboard、模型记录和预算工具观察使用情况；企业还可以按用户、模型、组织或成本中心筛选 AI credits。(Copilot 使用监控文档)
| 记录字段 | Efficiency | Balance | Intelligence | 验收结论 |
|---|---|---|---|---|
| 实际路由模型 | 记录客户端显示值 | 记录客户端显示值 | 记录客户端显示值 | 是否符合政策 |
| AI credits | 记录完整任务用量 | 记录完整任务用量 | 记录完整任务用量 | 是否因返工增加 |
| 首次成功 | 通过／未通过 | 通过／未通过 | 通过／未通过 | 是否需要重复提示 |
| 失败与重试 | 记录次数 | 记录次数 | 记录次数 | 是否出现系统性失败 |
| 人工返工 | 记录修改时间 | 记录修改时间 | 记录修改时间 | 是否抵消模型节省 |
| 测试与构建 | 通过／未通过 | 通过／未通过 | 通过／未通过 | 是否能进入 PR |
第二张表用于判断“换档”还是“换环境”。它尤其适合带 CI、Agent 或云端 Mac 的团队。
| 现象 | 优先检查 | 选档动作 | 环境动作 |
|---|---|---|---|
| 回复快，但代码经常漏边界 | 模型理解和返工 | Efficiency 回退到 Balance | 暂不扩容 |
| 回复慢，但代码一次通过 | 模型生成与上下文 | 保持 Balance 或 Intelligence | 检查服务延迟 |
| Agent 长时间等待测试 | 工具执行和构建队列 | 不因等待切换档位 | 增加隔离工作区或 Mac 容量 |
| AI credits 增长很快 | 模型、上下文和重试 | 低风险任务分流 Efficiency | 设置预算和告警 |
| Xcode 构建失败 | 签名、依赖、架构和工程环境 | 不把问题归因于档位 | 使用真实 Mac 环境验收 |
| Intelligence 没有稳定收益 | 任务是否真的复杂 | 保持 Balance 或手动选模 | 补充回归样本 |
FAQ：团队最容易误判的五个问题
Efficiency、Balance 和 Intelligence 的本质区别是什么？
三档不是固定模型套餐，而是不同的路由偏好。Efficiency 更关注成本，Balance 同时看成本、质量和延迟，Intelligence 更偏向复杂任务质量。由于三档共享可用模型池，最终差异必须用实际模型记录、AI credits、返工和交付结果验证。
选择 Intelligence 是否等于锁定最强模型？
不是。Intelligence 会提高对高质量模型的偏好，但每条提示词仍会被单独评估。简单任务可能继续使用轻量模型，复杂任务才可能进入更高能力路线。你应查看回复旁边、终端或 Agent 记录中的实际模型，而不是从档位名称推断。
三档会不会直接改变 AI credits 规则？
不会按档位固定扣费。AI credits 取决于实际选中的模型和 Token 用量。长上下文、复杂推理、多轮工具调用和失败重试都会增加消耗。付费计划使用自动选模时可享受官方列出的 10% 模型成本折扣，但这不代表 Intelligence 必然贵，也不代表 Efficiency 必然省。
企业默认档位应该怎么设置？
多数团队先用 Balance。它能覆盖日常开发，同时避免把所有请求都推向高成本路线。你可以给低风险批处理配置 Efficiency，为复杂重构和疑难排查保留 Intelligence。管理员还必须核对模型政策、客户端差异和数据驻留限制，否则默认设置可能与开发者实际看到的模型池不同。
长时间编码 Agent 任务适合自动选模吗？
可以试点，但必须把模型质量和执行环境拆开。记录 Agent 的模型调用、工具执行、测试、PR、重试、工作区占用和最终构建。对于 iOS、macOS 项目，还要检查 Xcode、签名和真实 Mac 产物。模型回答更好，不等于任务已经交付。
结尾判断：先优化路由，再决定是否增加 Mac 资源
如果你现在把所有任务都固定在某一档，通常会遇到三个问题：低风险工作消耗了不必要的模型资源，复杂任务又可能因为档位过低而反复返工；另外，团队还容易把 Agent 等待、CI 排队和 Xcode 构建失败误判成模型性能问题。
更稳妥的做法是先导出一周内的代表性 Copilot 任务记录，分别抽取简单修改、日常开发和复杂 Agent 任务，做一次三档小规模回归。若长任务仍受工作区在线时间、并发测试或 Xcode 构建限制，再进一步评估云端 Mac 的容量和隔离方式。相比只调整 Copilot 档位，vmzig 的云端 Mac 方案更适合把真实构建环境、测试资源和 Agent 工作区单独管理；但如果你的团队需要长期稳定的高负载，或必须接入本地物理设备，自购 Mac 仍可能比租赁更合适。
常见问题
GitHub Copilot 的 Efficiency、Balance 和 Intelligence 应该怎么区分？
Efficiency 优先考虑成本和响应速度，适合文档补全、格式调整和小范围可逆修改；Balance 同时权衡质量、延迟与成本，适合作为日常开发默认档；Intelligence 只是提高复杂任务的路由偏好，不代表固定调用某个最强模型，适合跨文件重构、复杂故障排查和高风险 Agent 任务。
Copilot 自动选模使用 Intelligence 会自动调用最强模型吗？
不会。三个档位共享当前账号、客户端和管理员政策允许的模型池，Intelligence 只是更偏向高质量路线。简单提示仍可能被路由到较轻量的模型，最终模型要以客户端显示的响应记录为准，不能从档位名称反推出具体供应商或模型。
GitHub Copilot 自动选模三档会影响 AI credits 消耗吗？
会影响实际消耗，但不是按档位固定扣费。GitHub 按自动路由最终选中的模型和输入、输出、缓存 Token 计算 AI credits。长 Agent 任务还可能产生多次模型调用，因此应比较完整任务的总 credits、重试次数和人工返工，而不能只看一次回复的价格。
企业应该把 Copilot 自动选模默认设成哪一档？
没有统一适合所有企业的答案，但多数研发团队可以先把 Balance 设为默认，把 Efficiency 分配给低风险批处理，把 Intelligence 限定给复杂任务。管理员还要验证计划、客户端、数据驻留和模型政策，否则界面上的档位可能覆盖不到团队实际可用的完整模型范围。
Copilot 自动选模适合长时间编码 Agent 任务吗？
适合试点，但不应只靠 Intelligence 判断能否交付。长 Agent 任务要同时记录模型响应、工具执行、测试、Pull Request、工作区在线时间和最终构建结果。对于 iOS 或 macOS 项目，还要在真实 Mac 环境完成 Xcode 构建、签名和测试验收，不能把模型回答质量当成最终交付证据。