GitHub Copilot的模型选择器里，出现了一个中国模型。
7月1日，GitHub宣布Kimi K2.7 Code正式在Copilot中登录。
这是Copilot模型选择器里第一个可选的开放权重（open-weight）大模型。
Kimi这次进入的，是Copilot自己的工作流。
开发者在VS Code、Visual Studio、JetBrains、Xcode、Eclipse、Copilot CLI、GitHub.com、GitHub Mobile里，都可能在模型菜单里看到它。
Copilot正在从一个默认助手，变成一张模型菜单。以后开发者要面对的，可能不再是“用不用AI写代码”，而是这次任务到底该交给哪个模型。
GitHub官方公告显示，Kimi K2.7 Code已在GitHub Copilot上线
Copilot的菜单，第一次多了open-weight
GitHub公告给了几条硬信息。
Kimi K2.7 Code由GitHub托管在Microsoft Azure上，按照供应商标价走usage-based billing。
个人侧先向Copilot Pro、Pro+和Max计划逐步推送，企业侧后续扩到Business和Enterprise。
Business和Enterprise默认不开。管理员需要在策略里手动启用。
这个安排非常合理。个人开发者看到的是模型菜单多了一项；公司里的平台团队会先看成本、权限、合规和审计。模型进了Copilot，也就进了企业治理流程。
GitHub为什么要把Kimi加进去
Copilot已经接入过不少前沿模型。GPT、Claude、Gemini都在开发工具里出现过，开发者对切模型也不陌生。
日常编码却不是每一项任务都要动用旗舰模型。
小bug、测试补全、旧代码解释、接口样例、报错分析，讲究的是稳定、速度和价格。Agent一旦跑长任务，工具调用、上下文和反复尝试都会把成本堆起来。
Kimi K2.7 Code适合放在这个位置：高频、偏执行、面向代码。
它不用在所有榜单上压过Claude Opus或GPT-5.5，Copilot需要的是一个能反复调用、成本相对可控的代码模型。
从这个角度看，Kimi进Copilot不只是“国产模型出海”。GitHub在把Copilot做成多模型入口。
复杂判断交给旗舰模型，日常编码交给成本合适的执行模型，这种分工会越来越常见。
Kimi侧重的，是长任务编码
Kimi官方自我定位是coding model。
文档提到，Kimi K2.7 Code相比Kimi K2.6，在长周期编码、指令遵循和Agent能力上有提升，平均减少约30%的过度思考。
HighSpeed版本输出速度约180Tokens/s，短上下文下最高可到260Tokens/s。Kimi K2.7 Code和HighSpeed版本都提供256K上下文窗口。
代码任务很吃上下文。读仓库、看多个文件、做依赖迁移、跟踪一条bug链路，都不是一问一答能解决的事。
Kimi这次主打的，正是这类长链路编码任务。
Kimi官方文档中对Kimi K2.7 Code的定位和能力说明
它更像代码Agent的一颗零件
Hugging Face模型卡里，Kimi K2.7 Code被描述为面向coding-focused agentic tasks的模型。
页面右侧还能看到模型大小约1.1T params，模型卡中列出的激活参数是32B。
这类模型要做的是工程里的脏活：读项目结构、找相关文件、改代码、补测试、看报错。
开发者测试它，也不该只问一道算法题。更适合的方式是把它放进真实仓库里，给一个明确任务：先读README和测试命令，列出修改计划，再动代码，最后贴diff和风险点。
如果一个模型能把这条链路稳定跑完，它就有资格进入Copilot这种开发入口。否则榜单分数再漂亮，也很难变成每天可用的生产力。
Hugging Face上的Kimi K2.7 Code模型卡
Copilot不再只卖一个最强助手，而是在变成一个多模型调度入口。
以前提到GitHub Copilot，开发者想到的是一个AI编程助手。
至于背后用什么模型、怎么调度、成本怎么摊，大多数时候都被产品藏了起来。
Kimi K2.7 Code进入模型选择器后，这层东西被摆到了台前。
Copilot变成一个多模型调度入口。
复杂任务可以交给旗舰模型，日常编码可以交给成本更低的代码模型，企业管理员再决定哪些模型能开、哪些团队能用、哪些任务不能放行。
这才是Kimi这次进入Copilot最值得看的地方。它不是单纯多了一个可选模型，而是让开发者更清楚地看到：AI编程工具后面，正在搭建一套模型分工系统。
企业会拉出账单，选择Kimi
Kimi进入Copilot以后，个人开发者可能最先想到的是“多一个选择”。企业会先看两件事：账单和开关。
GitHub在公告里写了usage-based billing，也写了企业计划默认不开。这个组合很现实。
AI编程工具已经从“每人一个助手”变成了“每个团队一堆模型、每个任务一笔成本”。
一旦Agent开始批量读仓库、跑测试、改文件，模型调用就不再像补全一行代码那么好算。
管理员要知道哪些团队能用、哪些模型能开、哪类任务可以交给open-weight model，哪些场景必须走更受控的模型。
后面Copilot会变复杂。模型越多，选择越自由，治理也越难。对团队来说，模型菜单背后其实是一套成本和权限系统。
社区反应：有人兴奋，也有人先问值不值
这条消息在Hacker News上也引发了讨论。截图里能看到，这个帖子拿到402分，下面有165条评论。
社区反应并不都是“模型厉不厉害”这种单一情绪。
有开发者把话题转到了云端AI产品本身：功能越来越多，价格、可用性、策略变化也越来越多，最后反而让一部分人重新回到本地模型。
这些留言提醒了一点：
开发者不是只看模型名，他们还看成本、稳定性、能不能长期使用，以及今天能用的能力明天会不会突然变策略。
Kimi进Copilot是一个信号。但如果它要成为开发者日常工具，还得回答更朴素的问题：它够不够稳，够不够便宜，跑长任务会不会让人心疼。
Hacker News上关于Kimi进入Copilot的讨论
写在最后
Kimi这次进GitHub ，真正的变化落在Copilot身上：AI编程不能只靠一个最强模型。日常开发里，有的任务要旗舰模型判断，有的任务只需要便宜模型执行，有的任务要看长上下文，有的任务要看企业策略能不能放行。
以后开发者打开Copilot，面对的可能不是一个助手，而是一排模型。
后面拉开差距的，也不只是Prompt写得多漂亮。你得知道什么时候用Kimi，什么时候切Claude，什么时候上GPT，什么时候干脆别让Agent动手。
AI编程进入多模型时代以后，选模型会变成新的工程判断。
参考链接：
https://github.blog/changelog/2026-07-01-kimi-k2-7-is-now-available-in-github-copilot/
