Copilot Fusion 将选模型交给任务路由

Copilot Fusion 想替开发者接过一个越来越烦的决定：这次任务该选哪个模型。按原文描述，你只需选择投入档位，系统负责路由、失败升级和模型间审查。作者的结论是，开发者更该练习描述任务和验证结果。

这个方向值得关注，但性能和成本数字目前都是厂商口径。对前端和全栈团队，更有用的问题是：自动选模型之后，怎样定义完成、控制预算，并确认审查真的有效？

不选模型之后，开发者还要决定什么

据原文，GitHub 在 2026 年 10 月 28 日的 GitHub Universe 上公布 Copilot Fusion。它提供 Standard、High、Max 三个投入档位，再把任务分配给不同模型：先尝试成本较低的方案，失败后升级，并安排模型之间互相审查。

这里的编排（orchestration），就是把「谁来做、失败后找谁、结果由谁检查」组织成流程。作者认为，许多编码任务用不上最强模型，浪费来自开发者赶时间时的保守选择：为了保险，每次都选贵的。

但选择权交出去，需求表达的责任仍在开发者手里。

模型路由能优化执行路径，不能替你补齐完成标准。

例如，交给 AI 的任务如果只是「修好这个并发问题」，系统仍然缺少判断依据。你需要交代触发条件、不能破坏的行为，以及怎样证明问题已经解决。作者强调的技能迁移，是从猜模型能力，转向描述意图、约束、验收条件和失败情形。

成本是否下降，要看合并结果和审查效果

原文给出的主要成绩是：Fusion Max 在 Artificial Analysis Coding Agent Index 上得到 60 分，对照组 Claude Code 使用 Opus 5.5 Max，得到 58 分；API 成本和 token 用量约为一半，任务完成速度快 40%。Satya Nadella 另有「以最高降低 77% 的成本获得前沿模型质量」的说法。

这些数字不能混成一组结论。「约一半」与「最高降低 77%」的适用条件，原文没有交代清楚。作者也明确注明：截至 2026 年 10 月 29 日，它们仍是 GitHub、Microsoft 的主张，独立基准测试尚待公布。

作者提出了一个更贴近团队实际的指标：每个最终合并的 PR 花了多少钱。它能把失败尝试、返工和审查开销一起纳入，而不是只看单次调用便宜多少。

投入档位也应按任务安排。原文举例：重命名使用 Standard，并发缺陷使用 Max；还可以按仓库和任务类型设置预算，像管理 CI 预算一样管理 AI 消耗。

另一个关键是模型间审查。多一个模型检查代码会增加调用，却可能提前拦住缺陷。要判断这笔开销值不值，需要看它能否真正拒绝错误代码，而不是只生成一段认可意见。原文没有提供审查拒绝率或缺陷拦截数据。

我的判断

我认同作者把重点放在任务规格和验证上。无论使用哪个模型，清楚的验收条件都能帮助团队判断结果；这部分建议不依赖 Fusion 的跑分成立。

自动路由优于手动选模型，则仍需要证据。原文没有给出作者或他们团队的实测，也没有展示真实仓库中的对照结果。相较于固定使用一个强模型，或者由开发者手动分配任务，Fusion 究竟省下多少总成本，目前不能仅凭这些数字下结论。

计费变化也需要单独看。据原文，GitHub Enterprise 将转向 AI credits，用量覆盖全部 Copilot 功能，无需另行订阅。取消单独订阅不等于账单下降，重度用户是否更划算，要看实际消耗和定价。

作者进一步判断，模型能力会在数月内趋于同质，长期价值留在路由、验证和治理层；他也认为，自托管、执行团队策略的编排系统仍有机会。这是产品方向判断，原文没有给出足以证明它的对照数据。

原文提到 GitHub 有 2.25 亿开发者，其中印度有 3200 万。庞大的用户规模可能加快反馈，但不能替代真实仓库的独立评测。

能拿来做什么

• 给日常 AI 编程任务补上验收条件。前端交互修改要写清触发步骤和预期行为，Node 并发问题要说明复现条件及必须保持的约束，让模型和开发者都有明确的检查依据。
• 按任务类型试用投入档位。可以从原文建议的「重命名用 Standard、并发缺陷用 Max」开始，记录实际消耗、返工和合并结果，再调整分配规则。
• 评估模型审查时，记录它拦住了哪些真实问题，并抽查它放行的代码。审查意见的数量，不能直接当作审查质量。
• 若采用 credits 计费，按仓库持续核算每个已合并 PR 的总成本，再判断账单是否改善。