GitHub Copilot 新建聊天后如何继续使用项目上下文？

GitHub Copilot 新建聊天后，可以通过 Copilot Spaces 继续使用项目上下文。Space 把仓库、代码、Pull Request、Issue、笔记、图片和上传文件组织成一个可复用的上下文集合。新聊天不会继承旧聊天的全部消息，但可以在同一 Space 中基于这些持久来源重新提问，因此不必每次从头粘贴项目资料。

Spaces 保存的不是聊天记录

普通聊天的上下文通常由当前消息和临时附加内容组成。新建聊天后，旧对话中的细节不一定继续存在。Copilot Spaces 解决的是另一层问题：把任务需要的知识来源独立保存，让多次聊天都可以访问。

这意味着旧聊天里的临时决定、失败尝试和未写入任何来源的进度仍可能丢失。重要结论应同步到 Issue、Pull Request、项目文档或 Space 的文本笔记中，而不能只依赖聊天历史。

Space 可以包含哪些来源

GitHub 官方文档列出的来源包括仓库、代码、Pull Request、Issue、自由文本内容、图片和文件上传。它们适合承担不同类型的上下文：仓库与代码提供实现事实，Issue 说明需求，Pull Request 展示变更与讨论，文本笔记保存团队约定或会议摘要。

不要为了“上下文越多越好”把所有内容放进一个 Space。来源过多会增加检索噪声和 Token 消耗。更合适的做法是按项目、领域或长期任务创建边界清晰的 Space。

GitHub 来源会自动保持同步

添加到 Space 的 GitHub 文件和其他 GitHub 来源会随源内容变化而自动更新。项目文档、Issue 或代码被修改后，Space 后续使用的是更新内容，因此比复制一份静态文本更适合长期项目。

自动同步并不表示所有外部上传文件也会更新。手工上传的附件和自由文本需要团队主动维护。若同一事实同时存在于仓库文档和上传文件中，可能产生冲突，应选定一个权威来源。

新聊天如何延续上下文

在 GitHub 的 Copilot Chat 中选择目标 Space，再围绕其中资料提问。新聊天会根据 Space 提供的来源生成回答，而不需要把旧聊天重新打开或复制进提示词。

开始时仍应说明当前目标，例如“检查订单退款实现是否符合这个 Space 中的接口约定”。Space 负责提供背景资料，提示词负责限定本次任务。只写“继续”无法告诉新聊天旧会话做到哪一步。

如何设计项目 Space

一个项目 Space 可以包含主仓库、架构文档、关键 Issue、当前 Pull Request 和一份简短的项目说明。说明中写清业务目标、术语和不可违反的限制，但不要复制已经存在于仓库中的全部文档。

对于大型项目，可以按领域拆分，例如认证、计费、数据平台和前端设计系统。一个问题涉及多个领域时，再选择包含必要来源的 Space，或通过跨链接指向相关资料。

任务级 Space 的组织方式

长期项目知识和短期任务进度可以分开。项目 Space 保存稳定架构与规范，任务 Space 保存具体 Issue、实现 PR、验收说明和临时调查笔记。任务完成后，将长期有效的知识回写仓库文档，再归档临时材料。

这种结构避免一个 Space 无限膨胀，也让新聊天更容易拿到与当前任务直接相关的信息。对于一次性小修复，未必需要创建独立 Space；使用 Issue、相关文件和明确提示可能已经足够。

用 Issue 和 Pull Request 保存进度

Issue 适合记录目标、验收条件、已知问题和待办。Pull Request 适合记录实际改动、测试结果、审查意见与尚未解决的讨论。把它们加入 Space 后，新聊天可以同时看到“为什么改”和“已经改了什么”。

聊天结束前，更新 Issue 或 PR 描述，写清完成项、未完成项和下一步。这样下一次即使打开全新聊天，也能从版本化或可审查的状态继续，而不是依赖模型复述。

自由文本适合放什么

自由文本适合短期会议结论、术语解释和尚未进入仓库的业务约束。内容应注明日期、负责人和适用范围，避免几个月后仍被当成当前事实。

稳定技术规则应尽快迁移到仓库文档，任务状态应进入 Issue 或 PR。不要把访问令牌、客户数据和生产秘密写入 Space 笔记，即使 Space 当前设置为私有。

个人 Space 与组织 Space

Space 可以属于个人账户或组织。组织 Space 可向组织成员授予管理员、编辑者或查看者权限，也可以设置为对其他成员不可见。个人 Space 可以保持私有、分享给指定 GitHub 用户，或公开分享。

权限设计应遵循最小授权。需要维护来源的人才获得编辑权限，只使用上下文的人获得查看权限。包含内部代码或业务资料的 Space 不应公开分享。

查看者仍受源权限限制

GitHub 官方文档说明，查看者只能看到自己原本有权限访问的来源。把私有仓库添加到共享 Space，不会自动把仓库权限授予所有 Space 查看者。

这是一项重要边界，但团队仍应测试实际共享效果。公开 Space 中混入私有来源时，要确认标题、笔记或人工摘要没有泄露敏感信息。Space 权限和源权限是两套控制，必须同时正确。

在 IDE 中使用 Space

除 GitHub 网站中的 Copilot Chat 外，官方文档还说明可以在 IDE 中通过 GitHub MCP server 访问 Spaces 上下文。这样编码助手能够在本地开发时查询团队整理的知识。

IDE 接入前要确认 GitHub 身份、MCP 权限和组织策略。Agent 能访问 Space 并不代表有权修改仓库、合并 Pull Request 或执行生产操作，所有写操作仍应遵守原有授权与审批。

一次可靠的新聊天启动模板

当前目标：修复退款任务重复执行
使用上下文：Billing 项目 Space
优先来源：退款 Issue、当前 PR、幂等设计文档
约束：不改变公开 API，不执行生产数据库操作
完成标准：新增回归测试并通过计费模块测试

模板不需要复述整个项目。它告诉 Copilot 本次任务、应优先使用哪些 Space 来源以及如何验收。若旧聊天有未落盘信息，应先写入 Issue 或 PR，再开始新聊天。

如何验证 Copilot 使用了正确上下文

让 Copilot 在回答中指出结论对应的仓库文件、Issue 或 PR，并人工打开来源核对。对代码问题，再通过搜索、测试和本地运行确认。Space 提高相关性，但不能保证回答必然正确。

可以设计几个只有项目资料中存在的问题，分别在普通聊天和 Space 中测试。若 Space 仍频繁引用过期资料，检查源是否同步、是否有冲突副本，以及问题是否选择了正确 Space。

上下文与 Token 消耗

在 Space 中提交的问题仍计入 Copilot Chat 请求，并根据所用模型和处理的 Token 消耗相应额度。Copilot Free 用户受月度聊天限额影响，Business 与 Enterprise 使用则会消耗企业共享的 AI credits。

因此，Space 不应成为资料仓库的无差别镜像。保留高价值、相关且最新的来源，能降低无关上下文带来的成本。不同模型的消耗规则可能变化，应以当前文档和组织控制台为准。

适合跨会话复用的内容

架构决策、领域术语、运行手册、关键接口、当前路线图和活跃任务适合持续复用。自动同步的 GitHub 来源优先于手工复制，因为它们更容易保持最新。

大量日志、临时调试输出、完整聊天转录和已经关闭的旧任务通常不适合长期保留。需要审计时可留在原系统，通过链接或摘要提供入口，而不是全部塞入 Space。

避免上下文污染

同一 Space 中若同时存在旧架构与新架构、相互冲突的需求和多个未标明状态的方案，Copilot 可能无法判断哪个有效。应关闭或标记废弃 Issue，更新文档，并在文本说明中指出权威来源。

定期审查 Space 的来源清单，删除重复和过期资料。一个小而清晰的 Space 通常比一个包罗万象的 Space 更能产生稳定答案。

Spaces 不能替代什么

它不能替代 Git 分支与工作树检查，因为未提交修改可能尚未进入 GitHub。它不能替代测试，因为检索到的设计说明不证明实现正确。它也不能替代审查和权限控制，Copilot 的建议仍需开发者验证。

对于当前本地状态，提示 Copilot读取相关文件、查看 diff 和运行测试；对于跨会话稳定知识，使用 Space；对于任务进度，更新 Issue 和 PR。三者结合才能形成可靠工作流。

团队维护建议

为每个 Space 指定所有者，明确更新频率和归档条件。组织 Space 使用角色权限，重要文本变更由第二人复核。项目重构、仓库迁移和权限变化后，检查来源是否仍有效。

新成员入职时，可使用只读项目 Space 了解架构与活跃工作，但仍要配合正式开发文档和导师审查。Space 是自助入口，不应成为唯一知识副本。

结论

GitHub Copilot 新建聊天后，不会自动记住旧对话的全部细节，但 Copilot Spaces 可以让新聊天继续使用一组持久、可共享且会随 GitHub 来源更新的项目上下文。仓库、代码、Issue、PR 和简短笔记各自承担不同角色。

要获得可靠结果，应按项目或任务控制 Space 边界，及时把聊天结论回写权威来源，严格管理分享权限，并通过文件与测试核验回答。这样跨会话延续的不是一段不可审查的聊天记忆，而是团队共同维护的项目知识。