一个 bug 从被记下到合入，大半时间不在写代码

真正花在改动代码上的时间，往往只占一整个修复流程的一小段。建分支、写提交信息、推上去、开拉取请求、把改动讲清楚、等评审、按意见再改一轮——这些步骤一件件都不难，叠起来却把节奏切得很碎。GitHub Copilot 的编码智能体瞄准的正是这段被切碎的部分：把任务交给它，剩下的流程由它自己走完。

官方对它的定位不是编辑器里那个等着你提问的对话框，而是一个能在后台独立把任务做完的角色。

把一个 issue 丢过去，等一个 PR 回来

用法很直接：把某个 issue 指派给 Copilot，或者在任意页面的智能体面板发起任务。它会带着 issue 的标题、正文和已有评论开工，在自己的临时开发环境里探索代码、制定计划、动手改动，最后发起一个拉取请求；完成后把你加为审查人并触发通知。这个环境由持续集成能力驱动，可以跑测试、跑 lint，也可以按仓库里预先写好的环境准备脚本先把开发环境搭起来。

改需求时有个细节要注意：指派之后再新增的评论它不会感知，后续要求应当写在它提起的那个拉取请求里。在 PR 里继续留言，它会新开一个会话接着处理；同一条 PR 上过往会话的上下文是保留的，所以追加请求通常更快也更稳。持续集成的工作流跑挂了，同样可以交给它去排查并把修复推上来。

提交之前，先自己过一遍

审查智能体产出最耗神的地方在收尾：改动看着能跑，但没人会那样写。官方的做法是在打开拉取请求之前，先让编码智能体用代码审查能力自查一遍，收到反馈后迭代改进补丁，等你被指派为审查人时已经有人先过了一轮。同时它会在自己的工作流里直接跑代码扫描、密钥扫描和依赖漏洞检查；某个依赖有已知问题，或者代码里出现了像是被提交上来的密钥，都会在 PR 打开之前被标记出来。

把团队的做法写进配置

一句简短的提示词会留下大量需要临场判断的空间，而临场判断未必总跟团队的实际做法一致。自定义智能体就是用来把这部分固化下来的：在仓库里加一个配置文件，就能指定这类任务按什么顺序做。比如一个性能优化智能体可以先做基准测试，再改代码，改完重新测量拿到数据，最后才开 PR；这类配置还能在组织或企业范围内共享，让不同团队用上同一套流程。

桌面端：把会话并列摆开

任务一多，怎么同时推进几件事就成了新的难点。Copilot 桌面端可以从一个问题、一个拉取请求、一句提示或上一次会话发起工作，也可以并行跑多个智能体会话，每个会话各自使用独立的工作树与分支，文件、对话和任务状态彼此隔离，不会互相污染。它提供 Windows、macOS 与 Linux 版本，改动可以在集成终端和浏览器里验证，开出的 PR 沿用团队既有的评审、检查与合并要求。

编码智能体

在后台接手任务，自己建分支、提交并开启拉取请求

交付前自查

先用代码审查迭代改进，并跑代码扫描、密钥扫描与依赖检查

并行会话

桌面端多个会话各占独立工作树与分支，互不干扰

费用怎么算

个人档位从 2026 年 6 月 1 日起改为按用量计费，产品线从免费的 Free 档一直铺到 Pro、Pro+ 与 Max。Free 档包含有限的补全额度以及有限的对话与智能体用量，同时也带上了命令行工具和 agent 模式，想先试水不必先掏钱。付费档的基础额度与订阅价格一比一对应，在此之上还有一份会随成本变化的弹性额度；代码补全与下一步编辑建议在付费档不限量，也不消耗额度。具体档位与额度以官方定价页为准。

把代码写出来只是整件事的一半，另一半是让改动穿过评审、检查与合入——Copilot 这一套把后一半也接了过去，人因此只需要在真正需要判断的地方出现。