为什么 Copilot Space 会逐渐过时
首先来看看一个空间可以容纳什么。GitHub 列出了“仓库、代码、拉取请求（PR）、议题（Issue）、自由文本内容（如会议记录或笔记）、图像和文件上传”。您添加了两种上下文：指令（被描述为“描述 Copilot 在此空间内应重点关注什么的自由文本”）和数据源。
新鲜度承诺仅限于一种数据源。其措辞非常精确：“添加到空间中的 GitHub 文件和其他基于 GitHub 的数据源在发生变化时会自动更新，使 Copilot 成为您项目中常青的专家。”上传的文件和您粘贴的文本不属于基于 GitHub 的数据源。文档将它们描述为由您添加的内容——“您可以直接从本地机器上传文件”和“您可以输入或粘贴自由文本内容”——并且没有描述它们会自动更新。请将它们视为快照。
代码遵循单一分支。创建指南指出，“空间将始终引用仓库 main 分支上的最新版本代码。”如果您的团队当前的工作位于一个长期运行的开发分支上，那么空间将基于 main 分支进行回答。
仓库和文件的使用方式不同。“当您关联一个仓库时，Copilot 不会将整个项目加载到记忆中。相反，它会搜索仓库并仅检索与您的问题最相关的部分。”相比指下，“当您关联一个文件时，它的全部内容都会被加载到 Copilot 的上下文窗口中，并在该空间中的每一次查询中被予以考虑。”如果您需要 Copilot 每次都遵循某个文档，应该将其作为文件关联，而不是留给搜索去查找。
IDE 看到的内容更少。这是最让人感到意外的规则。GitHub 的说明写道：“在 IDE 中使用 Spaces 时，不支持仓库上下文和上传的文件。”其他所有内容仍然可以传递：您添加的文本内容、GitHub 文件、议题、拉取请求以及空间的指令。一个主要由整个关联仓库和几个上传的 PDF 构建的空间，在 github.com 上看起来可能内容丰富，但在您的编辑器中却显得非常单薄。
从 IDE 访问需要进行设置。Spaces 是通过 GitHub MCP 服务器传递的，并且“Spaces 工具集不包含在默认配置中，因此您必须使用 X-MCP-Toolsets 标头显式启用它。”连接后，“在您的 IDE 中，Spaces 只能在智能体模式下使用，因为空间是通过 GitHub MCP 服务器访问的。”
此外，描述是给人类看的，而不是给 Copilot 看的。GitHub 表示它“不会影响 Copilot 的回答，但可以帮助其他人理解该空间的用途”。
这些都不是缺陷。每条规则都是合理的合理设计选择。它们共同意味着，一个空间的新鲜度和完整度，完全取决于您为其选择的数据源。
人们尝试的其他替代方案
上传导出的文档。 这很快速，而且在第一天非常有效。但它也会将文档冻结在上传的那一刻，并且上传的文件无法在 IDE 中传递给 Copilot。
关联整个仓库并期望 Copilot 了解其中的一切。 关联仓库意味着搜索，而不是完整加载。对于特定问题，重要文档可能会也可能不会被检索到，而且仓库上下文不属于 IDE 使用的一部分。
一次性粘贴一大段笔记。 文本内容确实可以传递到 IDE，这很好。但是几个月前粘贴的笔记会一直被视为最新内容，直到有人去编辑它们。
将上下文写进描述中。 GitHub 表示描述不会影响 Copilot 的回答。
为每个问题构建一个单独的空间。 空间最适合作为系统、工作流或功能的长期集合。许多包含重叠、未维护内容的小空间，其过时速度比一个有人维护的空间要快得多。
解决方案：使用可自动更新的数据源构建空间，并在团队工作的地方进行检查
目标是建立一个空间，其重要内容能够自动刷新，其快照有明确的负责人，并且其上下文既能传递到 github.com，也能传递到 IDE 中。
步骤 1：优先选择 GitHub 文件，并为每个数据源决定是使用文件还是仓库
列出团队成员理解系统所需的内容：架构概述、关键模块、运行手册（runbook）、规范、未解决的设计问题。然后决定每个项目如何进入空间。
如果它存在于仓库中，请将其作为 GitHub 文件添加，而不是上传副本。GitHub 文件是文档中所说的“在发生变化时会自动更新”的数据源，并且它们在 IDE 中可用。如果该项目尚未存在于仓库中但应该存在——例如决策记录、设计说明——请考虑先提交它。这使得它在空间中具有版本控制、可评审且保持最新。
深思熟虑地选择文件或仓库。对于 Copilot 在回答每个问题时都应该考虑的少数文档，请关联单个文件，因为文件的“全部内容都会被加载到 Copilot 的上下文窗口中”。当目标是在 github.com 上回答涉及大量代码或文档的问题时，请关联整个仓库，但要清楚这依赖于搜索且无法在 IDE 中使用。
链接承载实时决策的议题（Issue）和拉取请求（PR）。GitHub 允许您将它们的 URL 作为数据源粘贴，并且它们在 IDE 中可用。
检查分支。如果 main 分支不能反映系统当前的运行方式，请在指令中注明，或者将空间指向 main 分支上最新的文档。
步骤 2：使用指令和文本内容来容纳仓库无法保存的内容，并为其指定负责人
有些上下文不属于仓库：迁移被推迟的原因、API 选择背后的客户限制、评审人员应用的清单。这就是指令和文本内容的用途。
将指令写成给 Copilot 的简要说明。GitHub 的建议是包含“它的专业领域、它应该帮助完成哪些任务，以及它应该避免什么”。保持它们简短并针对空间的特定目的。
将持久的背景信息放在文本内容中，因为它可以传递到 IDE。为每个内容块注明日期并命名维护者。注明日期的笔记能让过时显而易见；未注明日期的笔记则看起来永远都是最新的。
然后设置角色。对于组织拥有的空间，“编辑者（Editor）可以更新空间的附件、描述、名称和指令”，而“查看者（Viewer）可以使用该空间提问并查看包含的附件和指令”。将编辑权限授予拥有快照的人，并将“审查空间”添加到与更新运行手册相同的清单中。GitHub 自己的新手引导示例正是这样建议的：“让其他人成为编辑者，以便任何人都可以更新包含的资源。”
步骤 3：在 IDE 中连接并测试实际传递的内容
设置启用了 Spaces 工具集的远程 GitHub MCP 服务器，然后在智能体模式下打开 Copilot Chat。GitHub 建议确认 get_copilot_space 和 list_copilot_spaces 工具已列出并启用。
现在用两个问题进行测试。问一个答案存在于 GitHub 文件或文本内容中的问题，再问一个答案仅存在于上传的文件或关联仓库中某个地方的问题。在 github.com 和 IDE 中都问这两个问题。两者的差异会向您展示团队在编码时究竟能看到空间的哪些部分。
将任何必不可少的内容移出 IDE 不可见的数据源。如果关键答案仅存在于上传的 PDF 中，请将该内容提交到仓库并作为 GitHub 文件添加，或者将核心部分作为文本内容粘贴。
最后，记住使用额度。在空间中提出的问题“会计入 Copilot Chat 请求，并根据所使用的模型和处理的 token 数量消耗 AI 额度”。一个由精心挑选的文件组成的精简空间，其查询成本比一个塞满所有内容的空间要低。
在 MemoryLake 中进行设置
一个构建良好的空间可以覆盖 GitHub 内部的一个系统。但有些上下文超出了这个范围：影响多个仓库的决策、适用于跨团队的规范、没有任何单一文件记录的选择背后的合理性，以及您的团队成员在 GitHub 之外的工具中所需的相同背景信息。MemoryLake 是保存该层信息的地方，以便它可以传递到您团队使用的每个助手。
您可以用自己的语言亲自编写这些条目。不会从您的 Copilot Spaces、您的仓库或任何供应商的存储中读取、写入或删除任何内容。
步骤 1：创建 API 密钥
登录并从控制面板生成一个密钥。无论团队成员打开哪种工具，该密钥都能让助手读取您编写的条目。
步骤 2：上传您的第一批记忆
从步骤 2 中超出单个空间范围的上下文开始：跨仓库决策、团队规范以及它们背后的原因。每个条目包含一个决策，注明日期，并指定负责人。
步骤 3：连接您的 AI 和智能体
连接 Copilot 以及您团队使用的其他助手。这样，相同的背景信息就可以与空间并存，并在那些从未读取过该空间的工具中可用。
这在实践中带来了什么改变
第一个区别是，对于关键部分，“常青”变成了现实。当关键文档是 GitHub 文件时，空间会随着代码和文档的变化而自动刷新，这正是 GitHub 对这些数据源所承诺的行为。
第二个区别是，IDE 和网页端显示相同的空间。一旦核心上下文存在于 GitHub 文件、议题、拉取请求、文本内容和指令中，开发者在智能体模式下就能获得与在 github.com 上相同的背景支持。
第三个区别是，过时问题有了负责人。注明日期的文本内容和明确的编辑者角色，将“空间已过时”从一句模糊的抱怨变成了一个有人可以承接的任务。这与最初防止 Copilot 遗忘您的代码库上下文 的原则是一样的。
第四个区别是，Spaces 可以与您的其他 Copilot 上下文和谐共存。仓库指令文件决定了 Copilot 在代码中的行为方式；空间决定了它对系统的了解；而 在 VS Code 中设置 Copilot 记忆 则增加了其自身的一层。保持这些角色的独立性可以避免 哪一个 Copilot 指令文件胜出 中所描述的冲突。
Copilot Spaces 的最佳实践
将仓库内容作为 GitHub 文件添加，而不是上传。 基于 GitHub 的数据源是文档中说明会自动更新的数据源。
为 Copilot 必须始终考虑的文档关联文件。 关联的文件会完整加载；关联的仓库则会被搜索。
检查 main 分支的内容。 空间使用 main 分支上的最新代码。
将核心背景信息放在文本内容中，注明日期并指定负责人。 这样它可以传递到 IDE，且日期能让过时显而易见。
在 IDE 中进行测试，而不仅仅是在 github.com 上。 仓库上下文和上传的文件不属于 IDE 使用的一部分。
将描述留给人类。 应该将给 Copilot 的引导写在指令中。
提交属于代码的决策。 将 零散的项目文档转化为 AI 记忆 首先要将它们放到工具可以可靠访问的地方，当您 将 CLAUDE.md 内容迁移到 Copilot 时，同样的直觉也会有所帮助。
结论
Copilot Spaces 是一种实用的方法，可以让 Copilot 和您的团队对系统有一个共同的认识。GitHub 关于空间“随着项目的演进保持同步”的承诺适用于基于 GitHub 的数据源，这些数据源在发生变化时会自动更新。
其余部分则需要精心设计。上传的文件 and 粘贴的文本是快照。空间遵循 main 分支。关联的仓库是被搜索而不是被完整加载，并且在 IDE 中，“不支持仓库上下文和上传的文件”。
尽可能从 GitHub 文件构建，深思熟虑地选择文件或仓库，为快照注明日期并指定负责人，并在 IDE 中测试空间。对于超出单个空间范围的上下文，请将其保存在您团队使用的每个工具都能访问的地方。如果您正在比较该层信息的各种选择，适用于工程团队的代码库记忆工具 涵盖了该领域，而 Copilot 的单次请求工作流 解释了为什么上下文必须存在于任何单次请求之外。