GitHub Copilot app 新工作区怎样组织跨仓库任务

GitHub 在 2026 年 10 月 28 日的 Universe 发布中，为 Copilot app 带来了 Projects。这个“新工作区”更准确的理解不是一个更大的聊天窗口，而是一个围绕持续目标组织上下文、会话、代理结果和重复任务的容器。它可以关联多个仓库，也可以只放设计稿、会议记录或其他资料，因此适合跨仓库功能、发布准备和需求研究这类不会自然落在一个仓库里的工作。

官方入口：https://github.com/features/copilot

项目文档：https://docs.github.com/en/copilot/how-tos/github-copilot-app/working-with-projects

如果任务只修一个仓库里的一个问题，直接从仓库开启 session 仍然更简单；只有当目标需要跨仓库、跨资料或持续跟进时，才值得建立 Project。Projects 目前是 public preview，适合试用和验证流程，不宜直接当成不变的生产契约。

为什么单仓库 session 会让跨仓库任务变散

传统做法通常是为每个仓库分别开一次 session：前端仓库讨论页面、服务仓库修改接口、文档仓库补说明，设计稿和聊天记录则散在其他工具里。这样做的麻烦不是“不能完成”，而是每次切换都要重新交代目标、约束和上下游关系。一个仓库里的局部结论，也不会自动变成另一个仓库的上下文。

我更愿意把这次变化看成工作边界的调整：session 仍是执行一个局部任务的单元，Project 则负责保存“为什么要做这组任务”。前者适合快速修复，后者适合维护一个会持续数天、涉及多个结果的目标。

新规则：Project 先写目标，再装配上下文

官方文档给出的核心动作很明确：在 Copilot app 侧栏的 Projects 旁边创建 Project，先给它一个聚焦目标，再决定是否添加仓库。创建时可以搜索仓库所有者和名称，也可以暂时不添加仓库，让它先服务于需求分析或资料整理。

目标描述不要写成“帮我处理一下这个功能”。更稳妥的写法是把结果、范围和限制一次说明：

请围绕支付重试改造建立一个项目。
先阅读 Library 中的接口约束和前端交互说明，梳理需要同时变更的仓库。
第一阶段只输出影响范围和风险，不要直接修改代码。
后续每个仓库分别创建任务，并在结果中标明依赖关系。

这个例子里，目标是跨仓库的，第一阶段又明确要求“不改代码”。这样的约束比单独给每个 session 发送一句任务更容易复用，也方便后续追问时保持一致。

把多个仓库和非代码资料放进同一工作范围

创建 Project 后，可以添加一个或多个仓库。仓库是代码上下文，但不是全部上下文：官方文档还支持从 Library 添加文件或文件夹，把设计说明、反馈汇总、接口约定等材料作为项目资料保存。对跨仓库任务来说，建议把资料分成三类：

• 目标资料：需求、验收标准和明确不做的事情。
• 约束资料：接口契约、设计规范、兼容范围和发布窗口。
• 决策资料：会议结论、已知风险和需要人工确认的取舍。

资料不宜无差别堆入 Library。每次分配任务时，应说明 Copilot 需要使用哪一份资料，以及哪些资料只作背景。这样做的目的不是增加管理动作，而是减少“看到了很多材料，却没有判断哪些是本任务依据”的歧义。

怎样拆分 session，才能让 Project 真正可追踪

Project 的价值不在于把所有事情交给一个代理，而在于把大目标拆成可 review 的工作项。可以按下面的边界拆分：

1. 先做范围 session：读取需求和资料，输出涉及的仓库、依赖和未知问题。
2. 再做仓库 session：每个仓库只处理自己的改动，结果带回对应的 Pull Request 或草稿。
3. 最后做整合 session：检查接口、文档和发布顺序是否一致，必要时提出补充任务。

官方文档的 Overview 会把项目工作按 Needs input、Open、Working 和 Done 等状态组织起来。对团队协作而言，Needs input 比“任务失败”更准确：它表示 Copilot 在等待决策、评审或权限，而不是可以无限重试的技术错误。涉及变更合并时，仍应由人检查差异、测试和发布影响。

重复任务适合放进 Project Automations

如果一个项目里有稳定的重复动作，例如功能落地后生成推广视频、每周整理反馈，官方公告和项目文档都把它归入 project automations。使用时要把触发时间、输入资料、输出格式和失败时的处理写清楚，再在 Automations 面板检查计划。

自动化不等于自动批准。涉及写代码、创建 Pull Request 或控制外部应用的任务，仍需要按照组织权限和产品提示进行人工确认。尤其是 public preview 阶段，自动化的可用范围和界面可能变化，关键流程应保留人工兜底。

兼容注意：它不是所有 session 的替代品

这次更新最容易被误解成“以后都应该用 Project”。实际上，官方文档仍然明确区分两种入口：

此外，Projects 目前属于 public preview，功能可能调整。采用时建议先选一个低风险、跨两个仓库的小目标，观察资料组织、状态流转和人工评审是否符合团队习惯，再决定是否迁移更多流程。

我的采用建议

如果你的痛点是“同一功能在多个仓库之间来回解释”，Project 值得试；如果只是想让 Copilot 更快改一处代码，直接 session 更省事。第一次试用时，我会保留三份最小资料：目标说明、仓库关系、验收清单，并把第一项任务限定为影响分析。等上下文和依赖关系稳定后，再让不同 session 各自承担实现、文档和整合工作。

这也解释了“新工作区”的真正变化：它不是把聊天窗口做大，而是把任务的生命周期做长。能否带来收益，取决于团队是否愿意把目标、资料和评审边界写清楚。

相关问题

Project 一定要先添加仓库吗？

不一定。官方文档允许创建不绑定仓库的 Project，适合先做资料研究、需求整理或其他不直接修改代码的任务。

一个 Project 可以放多个仓库吗？

可以。它的用途之一就是把一个持续目标关联到多个仓库，再为不同仓库分配独立 session。

Projects 现在适合直接用于所有生产流程吗？

不建议直接假设稳定。Projects 目前是 public preview，应先用低风险任务验证权限、资料范围和人工评审流程。

单仓库任务还需要 Project 吗？

通常不需要。若任务边界只在一个仓库内，直接从仓库开启 session 更轻量；只有需要跨资料、跨仓库或持续跟进时，Project 才更有价值。