Copilot Projects 公开预览：一个活儿横跨多个仓库，终于不用开三个会话了

GitHub 在 2026 年 10 月 28 日的 Universe 大会上，给 Copilot 应用带来了一个新东西：Copilot Projects，现在是公开预览。先把定义说清楚，免得被一堆新名词绕晕。以前你用 Copilot，基本是一个仓库、一次会话：打开一个项目，提一个需求，拿到一段代码或者一个 PR。这次的 Projects 反过来：工作本身才是主角，一个 Project 可以横跨好几个仓库，也可以完全不碰仓库，比如一份上线计划，里面有需求文档、设计稿、素材和待办事项，Copilot 在后台协调多个 Agent，把活干完，再把结果交回来给你审。简单说，以前是你带着 Agent 走进一个仓库，现在是你给 Agent 一个目标，它自己去串起所有相关的东西。

先划一条界，避免混淆：这篇文章说的是 Projects 和 Copilot 应用本身，不是同一天发布的模型路由功能。那是另一回事，计费方式和解决的问题都不一样，不要把两个功能的分数和价格混在一起读。Projects 要解决的不是“选哪个模型更便宜”，而是“一个活儿散在好几个地方，怎么办”。这个区分很重要，因为后面所有判断都建立在它上面：如果你只有一个仓库、一个明确的小任务，Projects 对你基本是多余的；如果你手头的事天然就是跨仓库、跨文档的，它才开始有价值。

它到底怎么干活

按 GitHub 官方 Changelog 的说法，流程是四步。第一步，你新建一个 Project，用一句话说清楚要干成什么。第二步，你把 Copilot 需要的上下文贴进来：相关的仓库、设计稿、Slack 里的讨论串、设计会议的笔记，都可以。第三步，你选模型和工具。第四步，Copilot 根据活儿的需要跑起多个 Agent，在后台并行干活，最后把结果带回来，比如一个个 PR，等你检查。中间它还会主动找你：需要你拍板的时候，它会停下来问，而不是闷头把活儿干完再给你一个“惊喜”。

这个流程里最值得注意的是第二步，也就是上下文。过去 Agent 最常见的失败原因，不是模型不够聪明，而是它不知道背景：不知道这个需求在 Slack 里已经讨论过三轮，不知道设计稿里改过一版，不知道另一个仓库里已经有现成的实现。Projects 把“给上下文”变成了一个正式的环节，而不是每次在对话框里临时补充。这听起来是小改进，实际影响很大：上下文给得越全，Agent 走弯路的概率越低；但反过来，上下文给得越杂，Agent 被带偏的概率也越高。以后用 Projects 的能力高低，很可能就体现在“会不会挑上下文”上，而不是“会不会写提示词”上。

还有一个细节：对于只涉及单个仓库的专注任务，你仍然可以直接从那个仓库开一个会话，不用非得建 Project。GitHub 特意保留了这条轻量路径，这是一个好信号，说明它没有为了推新概念而强迫所有人绕远路。工具设计里，保留“不用新功能也能好好干活”的出口，往往比新功能本身更能说明设计者有没有想清楚。

自动化：把重复活儿变成固定流程

Projects 里还有一个叫 Project Automations 的部分，专门对付重复活儿。GitHub 举的例子是：每当一个功能上线，就自动做一段宣传视频。这类活儿的特点是：本身不难，但每次都要人记得、每次都要花时间，而且容易因为忙而被拖掉。把它变成自动化，价值不在“省了多少分钟”，而在“不会再漏”。对小团队来说，这种“不会漏”的价值经常被低估：上线清单、发布说明、跨仓库同步、文档更新，这些活儿漏一次的代价，远大于每次手动做它的成本。

但自动化也有它的另一面：它会把错误也自动化。一个流程如果本身有问题，自动化只会让它错得更快、错得更整齐。比如宣传视频的模板错了，自动化会一丝不苟地每个版本都错一遍；跨仓库同步的规则写错了，自动化会把错误同步到所有地方。所以上自动化之前，先手动跑两三遍，把流程里的坑踩出来，再把它固定下来，这个顺序不能反。Projects 给了你把流程固定下来的地方，但它不会替你判断这个流程本身对不对。

不止写代码：Slack、Figma 和桌面应用都进来了

这次 Copilot 应用的变化不止 Projects 一个。同一份 Changelog 里还提到三件事：可以用 Slack、Figma 这些已连接工具的上下文来做调研、写需求文档、讨论设计；可以在对话里用自然语言生成和修改图片；还有 Computer Use，也就是让 Copilot 直接操作桌面应用。这三件事放在一起看，意图就很清楚了：GitHub 想让 Copilot 应用从“写代码的工具”变成“干活的入口”，代码只是其中一种产出，文档、设计讨论、图片、甚至桌面软件里的操作流程，都可以是产出。

其中 Computer Use 是最需要冷静看待的一个。按官方说法，它目前也是公开预览，只支持 macOS 和 Windows，能读应用内容、点控件、输入和编辑文字、在多个应用之间切换，哪怕那个应用没有 API、没有命令行、也没有 MCP 集成。举的例子是报销流程这种事。操作之前，Copilot 会先征求你的批准，组织也可以通过管理设置把它关掉。在 macOS 上，还需要你授予无障碍和录屏权限。这些限制条件一个都不能省，因为一个能点鼠标的 Agent 和一个只会改文字的 Agent，风险完全不在一个量级：前者点错一个按钮，可能是在生产控制台里改了一个配置，后者最多是写错一行代码。

对普通开发者来说，Computer Use 现在最适合的定位是“在受控的小任务上试”，而不是“把日常操作全交出去”。比如在一个测试环境里、一个不重要的应用里，先看它会不会按你的意思点、会不会在不确定的地方停下来问你。等你摸清它的脾气，再考虑扩大范围。组织管理员则应该先想清楚：哪些应用允许它碰，哪些绝对不允许，默认策略应该是关掉再按需开，而不是先开着再出事补救。GitHub 给了组织级关闭的开关，这个开关的存在本身就是一种提醒。

会话可以跟着人走，这件事比听起来重要

这次更新里还有一个容易被忽略的点：会话连续性。你可以在 GitHub 应用、VS Code、命令行和网页之间，接着同一个云端 Agent 会话往下走，不用每个地方重新讲一遍背景。对每天在多个设备、多个界面之间切换的人来说，这个体验的价值很实在：早上在网页上提的需求，下午在编辑器里接着改，晚上在命令行里再看一眼结果，上下文不用反复搬运。但它也有代价：会话越长，上下文越臃肿，模型越容易在后半段忘记前半段的约定，或者把旧的决定和新的要求混在一起。所以“能接着走”不等于“应该一直走下去”，一个 Project 或者一个会话做到一定规模，就该收口、归档、开新的，而不是无限续杯。

把这几件事合起来看，GitHub 的意图就完整了：它不是在卖一个更会写代码的模型，而是在搭一个“以工作为中心”的架子。工作有目标、有上下文、有多个 Agent、有自动化、有跨界面的连续性，代码只是流经这个架子的一种材料。这个方向和过去几年 Agent 工具的演变是一致的：从补全一行代码，到完成一个任务，再到协调一堆任务。Projects 是这个演变里的一个节点，不是终点。

给小团队和独立开发者的判断

对小团队和独立开发者来说，Projects 最有用的场景其实很具体。第一种是跨仓库的功能：比如一个功能要改前端仓库、后端仓库和文档仓库，过去你要开三个会话、讲三遍背景，现在可以放在一个 Project 里讲一遍。第二种是不碰代码的上线准备：发布计划、宣传素材、跨团队同步，这些活儿以前散在聊天记录和文档里，现在可以有一个统一的地方。第三种是重复性的收尾活儿：每次上线都要做的那几件事，写成自动化，以后不用再靠记忆。

反过来，有几种情况不适合马上用 Projects。第一，你的活儿就是单个仓库里改一个小功能，直接开会话更快，建 Project 是 overhead。第二，你的上下文本身就是一团乱麻，需求没想清楚、设计稿有三个版本、Slack 里结论互相矛盾，这时候把一团乱麻全塞给 Agent，只会得到一团更大的乱麻，先把上下文理清楚再上工具。第三，你对结果的检查能力跟不上：Projects 一次能带回多个 PR，如果你没有时间一个个认真审，批量产出就等于批量埋雷。Agent 一次能干多少活，取决于你一次能审多少活，这个上限是人的，不是模型的。

还有一个很实际的问题：成本。GitHub 这份 Changelog 里没有公布 Projects 的单独定价，也没有说多 Agent 并行会消耗多少 AI 额度。公开预览阶段，先在小 Project 上实测消耗，再决定要不要扩大，这是唯一稳妥的做法。别在没看到账单之前，就把整个季度的开发计划都押在一个预览功能上。预览的意思就是：能用，但形态、行为和价格都可能变。

真正要过的关：审得过来吗

所有多 Agent 工具最后都会撞上同一个问题：产出速度超过了人的审查速度。Projects 让 Copilot 可以同时跑多个 Agent，带回多个 PR，这听起来很美好，但如果你的团队本来就审 PR 审得很吃力，这个功能只会让审查队列变得更长。更糟糕的是，Agent 产出的 PR 往往看起来很规范：格式整齐、说明完整、测试也附上了，让人很容易放松警惕，点通过的时候比审同事的代码更快。而恰恰是这种“看起来没问题”的 PR，最需要慢下来看：它有没有改动你不希望它碰的地方，有没有引入你没注意到的依赖，有没有在边界情况上想当然。

所以用 Projects 的团队，最好先立两条规矩。第一条，Agent 的 PR 和人的 PR 走同样的审查标准，不因为它是机器生成的就降低要求，也不因为它格式漂亮就高看一眼。第二条，每个 Project 都要有一个明确的负责人，负责最后拍板，出了问题知道找谁，而不是“Agent 干的”就没人负责。工具可以分担执行，但责任分担不了，这是所有 Agent 工具共通的底线，Projects 也不例外。

上下文给多少、给什么，是新的手艺

Projects 把上下文变成正式环节之后，一个新的手艺问题就冒出来了：到底给多少、给什么。给少了，Agent 只能凭空猜，猜错了你还得花时间纠正；给多了，Agent 会在海量信息里抓错重点，甚至把已经作废的旧结论当成最新决定。更麻烦的是，Slack 讨论串和设计会议笔记里经常有“当时那么说、后来又改了”的过程信息，如果不加标注全塞进去，Agent 根本分不清哪句是定论、哪句是被推翻的提议。所以用 Projects 之前，先做一次上下文整理：把定论标出来，把作废的版本拿掉，把还悬而未决的问题单独列出来，让 Agent 在清晰的材料上干活，而不是在考古现场里挖。

这个整理活儿本身就是价值。很多团队第一次用 Projects 时会发现，最大的收获不是 Agent 干了多少活，而是整理上下文的过程逼着团队把需求、结论和待定事项说清楚了。换句话说，Projects 在某种程度上是一个“倒逼想清楚”的工具：你想不清楚，它就给你一堆看起来能用、实际对不上的产出；你想清楚了，它才能把执行部分真正接过去。这个规律对所有 Agent 工具都适用，只不过 Projects 把它放得更明显了，因为它一次能调动的上下文和 Agent 比单个会话多得多，混乱的输入会被放大得更厉害。

还有一个权限层面的提醒：把 Slack 讨论、设计稿、多个仓库一次性交给一个 Project，等于把平时分散在各处的内部信息集中到一个地方。集中带来方便，也带来风险：谁能看这个 Project，谁能改它的上下文，Agent 产出的 PR 会不会把某个仓库的敏感信息带到另一个仓库，这些问题在建第一个 Project 之前就应该想好。GitHub 官方 Changelog 里没有展开这部分的权限细节，团队自己要补上这一课：从最小范围开始，只放完成任务必需的上下文，敏感仓库和频道先不接，等流程跑顺了再逐步扩大。

图片生成和桌面操作，别当成主菜

同一份 Changelog 里提到的图片生成和 Computer Use，很容易抢走注意力，但对开发者来说，它们现阶段更像是配菜，不是主菜。用自然语言生成和修改图片，对做宣传图、示意图、占位图确实方便，但它解决不了设计本身的问题：你要什么风格、给谁看、传达什么信息，这些还是得人先定。Computer Use 能点桌面应用，听起来很科幻，但它目前只是公开预览，而且每一步都要你批准，真正省下的时间可能没有想象中多，引入的风险却一点不少。把这两个功能当成“顺手试试”的加分项就好，别让它们喧宾夺主，盖过 Projects 本身那个更实在的价值：把跨仓库、跨文档的工作组织起来。

判断一个新功能值不值得投入时间，有个简单的标准：它能不能让你少做一次重复劳动，或者少犯一次已经犯过的错。Projects 在跨仓库协作和重复自动化上，至少在逻辑上通过了这个标准；图片生成和桌面操作，现阶段更多是通过“看起来厉害”来吸引注意力，实际省下的时间和承担的风险还不成比例。等它们在预览里打磨几轮、出了更明确的权限和成本说明，再认真评估也不迟。工具箱里不是每个新工具都要第一时间拿起来用，先让子弹飞一会儿，往往是更省钱的做法。

先拿一个真实但不关键的活儿开刀

如果你看完这篇想试试 Projects，最稳妥的开局不是把它直接用在正在赶期的核心功能上，而是挑一个真实但不关键的活儿。比如一次版本发布的收尾清单：更新三个仓库的说明文档、整理一份发布说明、做一张简单的宣传图。这类活儿有几个好处：范围清楚，做不好也不会伤筋动骨，而且正好能测到 Projects 的三个关键点：跨仓库协调顺不顺、上下文给得够不够、自动化会不会漏步骤。跑完一轮，你对它的脾气就有数了，再决定要不要把它用在更重要的地方。

试的过程中，记得记下三组数据：第一，Agent 一次带回几个 PR，你实际花了多久审完；第二，上下文准备花了多久，是不是比直接写提示词更费事；第三，返工率有多高，有多少 PR 是第一版就能用、有多少需要大改。这三组数据比任何宣传文案都更能告诉你，Projects 在你的团队里到底是省时间还是费时间。如果审 PR 的时间超过了它省下的执行时间，那它现阶段对你就是负收益，先放一放，等它更成熟再回来也不迟。工具是为你服务的，不是反过来让你为它加班的。

最后回到一个更大的判断：Copilot 应用正在从“编辑器里的助手”变成“工作台”。这个转变对不对，要看它能不能解决真实工作里的摩擦，而不是看它一次能跑多少个 Agent。Projects 回答了一个真实存在的问题：工作本来就是跨仓库、跨文档、跨工具的，工具却长期被关在单个仓库里。这一步走对了方向。至于它能不能真的帮小团队省下时间、少踩坑，要等公开预览里足够多的人在真实项目上用过、翻过车、总结出用法之后，才会有答案。现在最合适的做法是：找一个真实但不关键的 Project，先小规模试，认真审每一次产出，算清楚成本，再决定它在你的工作流里占多大的位置。