GitHub 仍是软件开发中的核心平台。Business Insider 将其称为领先的软件开发平台，并指出微软在 2018 年收购了 GitHub [14]。因此，把眼下的争议概括成“GitHub 要完了”并不准确；更接近事实的说法是：GitHub 正在遭遇信任危机。
过去，很多人讨论 Copilot 时，重点还只是“编辑器里的 AI 自动补全好不好用”。现在，争议已经扩展到仓库协作层面：issue、pull request、代码评审、评论，以及由 @copilot 触发的代理工作流。对项目维护者来说，这些地方不是单纯的工具栏，而是项目治理的一部分 [7][
8]。
证据显示的是愤怒，而不是已被证实的“大迁徙”
目前公开资料更能支持“开发者不满加剧”，而不是“开发者正在大规模离开 GitHub”。
The Register 报道称，一些开发者因为“难以避开的 AI”功能开始考虑替代代码托管平台，尤其是维护者希望能在仓库内阻止或关闭 Copilot 的相关行为 [8]。Slashdot 在概述同一争议时也提到，有说法认为 GitHub 从相对独立的子公司并入微软 CoreAI 体系后，部分开源社区成员从抱怨 Copilot 转向主动离开 GitHub [
1]。
这些都是值得 GitHub 警惕的信号。但它们并不等于“GitHub 被大规模抛弃”的证据。现有来源没有给出迁移总量、企业客户流失数据，或仓库层面的证据来证明 GitHub 的地位已经实质性崩塌。更谨慎的结论是：随着微软把 AI 更深地推入 GitHub，开发者正在重新评估自己愿意把多少不受约束的信任交给这个平台 [8][
14]。
Copilot 为什么成了导火索
这场反弹并不只是围绕“AI 写代码有没有用”。真正的问题是：Copilot 可以在哪里行动、由谁来决定它能不能行动。
The Register 报道称，在过去 12 个月里，GitHub Community 最热门的讨论是要求提供一种方式，阻止 Copilot 在代码仓库中生成 issue 和 pull request [8]。按点赞数计算，第二热门的讨论则要求修复用户无法禁用 Copilot 代码评审的问题 [
8]。
这一区别很关键。一个只在私人编辑器里给出代码建议的助手是一回事；一个出现在 issue 队列、PR 流程和代码评审界面里的 AI 系统，则已经进入了仓库治理空间。对维护者而言，问题不只是 Copilot 生成的代码质量如何，而是项目所有者能否为自己的社区设定边界 [8]。
质量抱怨让“被动接受自动化”显得更冒险
部分不满还来自用户对可靠性的质疑。GitHub Community 上有讨论称，VS Code 中的 Copilot 表现不可靠，并导致项目受损 [9]。这样的帖子当然不能等同于覆盖所有用户和工作流的独立质量评测。但它能解释为什么一些开发者不再把不请自来的 Copilot 活动视为“无伤大雅的自动化” [
9]。
当一个工具既难以避开，又被部分用户认为不够可靠，争论焦点就会从“效率提升”转向“是否经过同意”。
AI 代理的可靠性已经是运维问题
GitHub 自己的状态页说明了为什么代理式工作流会提高风险。2026年4月22日 18:49 至 19:32（UTC），Agent HQ Codex agent 的 Copilot Cloud Agent 会话无法从多个入口启动，包括 issue assignment 和 @copilot 评论提及 [7]。GitHub 称，此次事件影响了 Copilot Cloud Agent 总任务量的 0.5%，约 2,000 个任务失败；Copilot 和其他代理会话未受影响 [
7]。
这不是 GitHub 全平台宕机。但它说明，一旦团队把真实工作交给 AI 代理，Copilot 的可用性就会变成交付计划的一部分。如果开发者把 issue 分派给代理，或通过 PR 评论触发工作，那么 Copilot 的状态就不再只是“辅助工具是否好用”，而是工程流程中的运行依赖 [7]。GitHub 的新闻页面也承认近期出现过可用性事件，并表示这些中断会影响客户 [
10]。
微软的 AI 路线改变了信任关系
Business Insider 报道称，微软正在调整团队以加强 GitHub，并围绕 AI 编码和 AI 代理改造这一平台；与此同时，GitHub 面临 Cursor、Claude Code 等 AI 编程工具的竞争 [14]。从产品战略看，这并不难理解：仓库、PR、issue 和代码评审本来就是编程助手最容易嵌入的地方。
但从开发者文化看，这件事要敏感得多。很多开发者把 GitHub 视为一种共享的软件基础设施。若 Copilot 功能显得难以绕开，维护者就可能不再把它看作可选的效率工具，而会理解为微软借 GitHub 的中心位置推进自己的 AI 战略 [8][
14]。
AI Credits 让边界问题也变成预算问题
GitHub 表示，Copilot 正转向基于用量的计费；从 6月1日起，Copilot 使用量将消耗 GitHub AI Credits [10]。这并不证明每个团队都会付出更多成本。但它意味着组织需要弄清楚：Copilot 可以在哪里运行、谁能够触发它，以及 AI 使用量如何映射到预算 [
10]。
对于那些已经不满 Copilot 出现在共享仓库空间里的团队来说，按量计费会让 GitHub 的方向更像是一个嵌入开发流程的可计费层，而不只是一个可选助手 [8][
10]。
不是所有“反平台”故事都等于离开 GitHub
一些更广泛的“开发者重新掌控基础设施”叙事，容易被混进 GitHub 争议里，但它们并不一定是在说 GitHub。David Heinemeier Hansson 的 HEY 个人资料显示，他是 37signals 的共同所有者兼 CTO，也是 Ruby on Rails 的创建者 [26]。他近期的文章讨论的是 37signals 的“退出云”计划，包括收到 20 台 Dell R7625 服务器，并希望摆脱云基础设施复杂性 [
17][
22]。
这些文章谈的是云基础设施，而不是已经被记录下来的 GitHub 迁移案例。这个区分很重要：开发者对中心化软件平台的怀疑可能正在上升，但这不等于有证据表明他们正在大规模离开 GitHub [17][
22]。
工程团队现在该做什么
现实的应对方式不是恐慌，而是把 GitHub 与 Copilot 的使用边界写清楚。
- 梳理 Copilot 的入口。 检查 Copilot 能在哪些地方出现或行动：issue、pull request、代码评审、评论、issue assignment，以及
@copilot工作流 [7][
8]。
- 制定仓库级策略。 明确哪些 Copilot 功能允许使用、哪些需要限制、哪些应当禁用。开源项目和合规要求较高的仓库尤其需要这样做 [
8]。
- 在 6月1日前复核 AI Credits。 Copilot 使用量将消耗 GitHub AI Credits，工程、平台和财务团队都应理解用量如何计算 [
10]。
- 把 AI 代理故障纳入预案。 如果交付流程依赖 issue assignment、PR 评论或代理会话，就应把 Copilot 可用性视为运维依赖 [
7]。
- 保留简单的非代理回退路径。 关键仓库仍应有明确的人类负责人、文档化的发布流程，以及自动化失效时的恢复办法。
结论：争的不是 AI，而是控制权
“开发者正在大规模抛弃 GitHub”这个说法，目前缺乏足够证据。更有支撑的判断是：GitHub 正在面对一场信任危机。Copilot 正进入共享开发流程，微软据报正在围绕 AI 编码和代理重组 GitHub；当代理承担真实工作时，可靠性事件的影响会更大；而基于用量的 AI 计费也即将到来 [7][
8][
10][
14]。
GitHub 仍然重要。真正悬而未决的问题是：当它越来越像一个主动推进 AI 的平台时，开发者会要求多少控制权。
