编辑 | 大石
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/
——好文链接——
刚刚，ZCode 登顶 Hacker News！智谱有自己的 Claude Code，却被网友质疑 " 克隆了 Codex"？
Fable5 杀回来了，但开发者发现不对劲：最强 Claude 被 " 限速 " 了？
Claude Code 创始人和龙虾之父都在用循环工程？Claude 官方给疯狂烧 Token 的 Loop 工程下了一个定义
