Copilot应用面向跨仓库与跨会话工作

GitHub Copilot app 正在把 AI 编程的工作单元，从单个仓库里的会话扩展到项目：多个仓库、设计稿、讨论记录、多个 agent 和交付结果，可以放进同一个工作空间，由 Copilot 在后台协调推进。

这次更新还覆盖了代码周边工作，包括使用 Slack、Figma 上下文，生成和编辑图片，以及操作桌面应用。对程序员来说，关键问题是：任务能交出去多远，又该在哪些地方保留人工审核。

跨仓库的任务，为什么需要 Projects

一个功能可能同时涉及前端、后端和其他仓库；一次发布还可能需要规格说明、设计稿和宣传素材，其中一些工作根本不涉及代码仓库。单仓库会话很难自然地容纳这些内容。

Copilot Projects 的做法，是给整件事建立一个共同的工作空间，把上下文、agent 和结果放在一起。

使用流程也围绕任务展开：先创建项目，描述目标，再加入仓库、设计稿、Slack 讨论或设计会议笔记，选择模型和工具。Copilot 根据工作需要运行多个 agent，在后台协调，必要时请求用户介入，最后带回 pull requests 等结果供审核。

Projects 想管理的是一件完整的事，而不只是一次代码对话。

Projects 目前处于 public preview。原文没有交代 agent 数量上限、任务如何拆分、模型如何分工，也没有给出完成率或耗时数据。因此，多 agent 协调是产品提供的工作方式，还不能据此判断它一定比单个 agent 更高效。

对于可重复工作，项目还支持 automations，原文举的例子是每当一个功能落地，就创建新的宣传视频。但具体触发条件、执行流程和失败处理没有展开。

如果任务只涉及一个仓库，仍然可以直接从仓库启动 session，不必先创建项目。

从读设计稿到操作桌面，能力边界扩到了哪里

代码周边的工作，是这次更新的另一条主线。

Copilot 可以使用 Slack、Figma 等已连接工具中的上下文，研究需求、起草规格说明，或结合代码推敲设计。聊天中还支持通过自然语言生成和编辑图片。

这里要区分两种工作方式：连接工具提供上下文，computer use 则让 Copilot 直接操作桌面应用。

Computer use 已在 macOS 和 Windows 进入 public preview，能够读取应用内容、点击控件、输入或修改文本，并在应用之间导航。即使某个应用没有 API、命令行接口或 MCP 集成，也在它描述的操作范围内。原文用报销流程作为例子，没有提供实际成功率。

启用入口是 Settings > Computer Use，打开 Enable Computer Use。macOS 还需要授予 Accessibility 和 Screen Recording 权限。

Copilot 控制应用前会请求批准，组织也可以通过 managed settings 禁用该功能。原文没有说明批准是按应用、会话还是具体动作生效，不能据此推断每一步操作都会单独确认。

我的判断

这次更新抓住了一个真实需求：功能交付需要的信息，经常散落在仓库、设计工具和聊天记录里。把这些材料集中到项目，再统一查看结果，比让开发者反复复制上下文更有吸引力。

但这是更新公告，没有对照实验，也没有团队使用数据。它能说明产品打算怎样组织工作，不能证明跨仓库协作已经足够可靠，更不能证明增加 agent 就能提高交付效率。

Projects 能否发挥作用，还取决于输入材料是否完整、权限是否合适，以及任务有没有清晰的验收标准。上下文放到一起，并不会自动消除需求冲突。

对于已有 API、CLI 或 MCP 接口的流程，我会优先考虑这些接口，方便检查输入、输出和错误。Computer use 更适合补上缺少接口的桌面环节；原文没有给出它与接口调用的可靠性比较，这只是工程取舍。

能拿来做什么

• 当一个功能同时修改前端和后端仓库时，可以试用一个 Project，集中提供需求、设计稿和相关仓库，再按仓库审核返回的 pull requests，观察它能否正确处理接口依赖。
• 对单仓库里的组件修改或明确缺陷，继续直接启动 session 即可。是否创建 Project，应由任务跨度决定。
• 如果团队已经连接 Slack 和 Figma，可以先让 Copilot 整理需求与待确认项，人工核对后再进入编码，尤其检查讨论记录与设计稿是否一致。
• 尝试 project automations 或 computer use 时，先选结果容易检查的重复任务。原文的宣传视频和报销流程可以作为试用方向，但验收要求仍需自己明确。