访问此页面需要授权。 可以尝试 登录 或 更改目录 。 访问此页面需要授权。 可以尝试 更改目录 。 遵循以下指南，在所有受支持的技术中充分利用 GitHub Copilot 升级，获得最佳效果。 技术特定的包管理器、生成系统和验证工具可能需要进行额外的准备。 在开始升级之前准备项目，以获得最佳结果。 验证您的解决方案是否能成功构建并通过测试 代理通过运行生成和测试来验证其所做的更改。 如果在开始之前解决方案已中断，代理无法区分预先存在的故障及其引入的问题。 记录任何已知的测试失败 scenario-instructions.md ，以便代理知道忽略它们。 从干净的工作目录开始，以避免将未提交的更改与代理的修改混合在一起。 使用干净的基线可以更轻松地查看或还原更改。 该代理还适用于不在源代码管理下的文件夹。 如果您的项目不在 Git 存储库中，代理将跳过分支和提交的操作。 如果是，请在开始之前备份项目文件夹，以便根据需要还原它。 在开始升级之前，请考虑初始化本地 Git 存储库，即使不推送到云提供商也是如此。 通过本地 Git 存储库，可以： 使用 git revert 回滚单个更改。 在提交历史记录中逐步跟踪升级进度。 使原始代码在主分支上安全，而代理在单独的分支上工作。 代理依赖于测试来验证其更改是否不会破坏行为。 具有良好测试覆盖率的项目获得更高的置信度升级。 您不需要百分之百的覆盖率。 专注于升级最有可能更改的代码，例如 API 边界、序列化、数据库访问和身份验证。 如果这是你第一次使用代理，请选择一个小型的低风险项目作为试点。 类库或实用工具项目是理想的。 从小事做起，可以在处理主应用程序之前了解工作流程、建立信心并发现任何仓库特定的问题。 在代理程序执行升级时，请遵循这些准则。 代理支持引导模式和自动模式。 在引导模式下，代理会在关键决策点暂停，等待您的审核和批准。 从引导模式开始，了解代理的作用以及原因。 熟悉工作流后切换到自动模式。 评估是在代理开始进行更改之前捕获问题的最佳机会。 查找： 代理人应该了解您解决方案中的任何异常之处。 如果发现某些问题，请在聊天中告知客服人员，或将信息添加至 scenario-instructions.md 。 直接编辑 assessment.md 以在代理继续规划之前添加上下文、更正错误的项目或标记问题。 代理根据其评估生成计划。 在继续之前查看计划： 是否有代理可能不知道的依赖项？ 是否应以不同的方式排除或处理任何项目？ 要求代理对任务重新排序、跳过项目或更改其方法。 你比代理更了解代码库，因此请使用该知识。 plan.md 直接编辑文件以调整任务顺序、添加任务或删除任务。 直接编辑 plan.md 时请小心。 如果这些更改创建了相互矛盾的指令，代理可能无法完全解释。 例如，在保留依赖于依赖项的项目的同时删除依赖项项目。 代理从会话中的更正学习。 如果代理做出一个你不同意的选择： 立即告诉它： “不要使用该模式，请改用 X。 向 scenario-instructions.md 添加持久指南，以便代理能够在任务和会话之间保持记忆。 执行不是不插手。 在告诉代理开始之前，请查看 tasks.md ： 要求代理调整任务列表，或在执行开始前直接编辑 tasks.md 。 执行启动后，如果代理在任务中途做出错误决策，请立即告知它，它会继续应用更正。 你知道你的代码库比代理更好，因此请在每个阶段使用该知识。 请注意这些常见问题，因为它们可能会减慢或使升级复杂化。 具有 50 多个项目的大型解决方案 代理按项目工作，因此大型解决方案需要时间。 耐心并监视进度。 在提交完整解决方案之前，请考虑从一个具有代表性的项目端到端开始。 单项目试点能及早揭示系统性问题。 对于专用 NuGet 或 npm 源，在开始升级之前进行身份验证。 使用贵组织的凭据提供程序或包管理器的配置。 如果没有身份验证，包还原或安装失败会阻止进度。 复杂的生成自定义（如自定义 MSBuild .targets 文件、包脚本、条件导入或非标准生成工具）可能会混淆评估并导致意外失败。 如果您的项目有这些自定义项，请在聊天中或在 scenario-instructions.md 中提及，以便代理将其考虑在内。 长时间运行的升级可能会跨越多个会话。 代理在 .github/upgrades/ 下的工作流文件中跟踪其进度，以便可以继续从中断处执行。 启动新会话时，请提及你所在的位置： “继续.NET 10 升级。我在 Data.Access 项目中间。“

交互的质量直接影响结果的质量。 你提供的细节越具体，代理的表现就越好。 “我们无法破坏公共 API 的向后兼容性。 “我们在两周内有一个发布截止时间，因此优先考虑 Web 项目。 “应从此升级中排除旧版报告模块。 代理会分析代码结构，但它不知道团队的精神模型。 帮助代理了解： “Project A 是我们的共享库。 B、C 和 D 都依赖于它。 “WebApi 项目是我们面向公众的 API;Internal.Api 仅适用于内部服务。 “模型项目是从 OpenAPI 规范自动生成的。不要直接修改它。 代理可以解释其推理。 如果决策看起来不正确，请问： “你为什么选择自下而上的顺序？ “为什么将此包升级到版本 X 而不是 Y？ “你为什么将此任务分解为子任务？ 了解推理有助于提供更好的反馈。 如果您对编码样式、模式或方法有很强的偏好，请在第一次会话中将其添加到 scenario-instructions.md 中。 此文件在会话之间保留，并且始终位于代理的上下文中，使其成为影响行为的最可靠方法。 当升级未按预期进行时使用这些策略。 告诉代理： “生成在最后一个任务后失败。” 代理分析错误并尝试修复错误。 如果代理无法解决问题： 提供手动修复，并告知代理你执行了什么操作。 代理从修复中学习。 还原提交（ git revert 或重置为上一个提交），让代理尝试不同的方法。 跳过有问题的任务，稍后再处理。 如果代理的总体方法不适用于代码库，请重启规划阶段： “让我们重做计划。 我想先升级 Web 项目，而不是自下而上。 调整策略以一次性升级所有共享库。 如果代理在没有进度的情况下重复相同的修复，请说 “停止” 并描述所观察到的内容，或手动停止会话。 代理可以重置其方法并尝试其他方法。 如果使用 Git 分支进行升级，请切换回原始分支来撤消所有内容： 原始代码未更改。 如果在不使用源代码管理的情况下工作，请从开始之前创建的备份还原。 代码片段 ：GitHub Copilot 根据 GitHub的Copilot隐私政策 处理这些代码片段，不会将其保留超出当前会话。 工作流文件 （ scenario-instructions.md 自定义任务、首选项）会保留在位于存储库中的 .github/upgrades/ 。 GitHub不会将这些文件传输到外部服务。 文件夹 .github/upgrades/ 是存储库的一部分。 提交文件夹，因为它包含升级进度和状态。 代理需要文件夹才能跨会话恢复工作。 升级完成后，可以将其删除。 遥测 ：通过 IDE 的遥测设置禁用。 关闭不必要的文件和选项卡 ：代理分析活动工作区，打开的文件更少意味着噪音更少。 分阶段升级非常大的解决方案 ：而不是一次性升级所有项目，请对其进行批处理。 例如，首先升级所有库，然后升级所有 Web 项目，然后测试。 使用生成缓存 ：代理在验证期间运行许多增量生成。 热构建缓存可显著加快验证速度。 避免在任务执行期间清理生成输出。 什么是GitHub Copilot升级？ 使用 GitHub Copilot Upgrade 升级 .NET 应用 排查 GitHub Copilot 升级问题 想要尝试使用 Ask Learn 阐明或指导你完成本主题？ Last updated on 2026-09-25