GitHub 在 9 月 24 日发布了一项影响所有 Copilot Business 和 Enterprise 客户的策略变更：新增一条覆盖「已普遍可用（GA）的 Copilot 功能与受支持的客户端能力」的全局默认策略，位置在企业与组织的 Copilot 设置里。公告同时给了一个明确的时间点——从 10 月 22 日起，这条策略开始生效。
它之所以值得单独拿出来讲，是因为公告里有一句容易被跳过的说明：公告发布后的前 28 天里，管理员可以设置这条策略，但「它暂时不会影响用户的特性访问」。也就是说，现在设置只是在为 10 月 22 日之后的自动生效做准备，而准备好的组织和不做准备的组织，在那一天之后会走向完全不同的状态。
发生了什么：一条全局默认，替代逐功能判断
按公告描述，这条策略管理的是「新功能的默认策略」，配置入口在企业设置的 AI Controls 页面下的 Copilot 子页，选项名称是 Default policy for new features。它覆盖的范围公告写得很具体：企业 Features & clients 页面上管理的合格功能，加上 Agents 页面上的 Copilot Code Review 策略，以及 Copilot 里的 MCP 服务器策略。
公告没有逐条列出受影响的单个功能，而是把合格范围指向 GitHub 关于「默认可用性」的文档。这一点在实操里意味着：想确认某个具体功能是否在范围内，要去文档里对，而不是看公告标题。
三个选项，对应三种完全不同的运维负担
公告原文给出的三个选项是：Enabled——当前和未来合格功能都会默认对用户可用；Disabled——当前合格功能保持不可用，未来的合格功能需要管理员批准；Let organizations decide——由组织管理员自行决定启用或禁用。
这三个选项的差别不在「开还是关」，而在「未来每个新功能由谁负责做决定」。选 Enabled，等于把判断权交给 GitHub 的发布节奏，管理员只在出现问题时才需要动手，代价是任何新功能都会先到用户手里。选 Disabled，等于给每一个未来 GA 的功能都挂上一次审批请求，管理员拿到的是确定性，付出的是持续的人工审核流量。选 Let organizations decide，是把这件事推给组织管理员，适合大型企业里各业务线风险偏好差异大的情况，但代价是治理口径不再统一。
范围内最需要注意的一项是「Copilot 里的 MCP 服务器策略」。MCP 服务器决定了 Copilot 能连到哪些外部系统、能读写什么，它不是普通的功能开关，而是能力边界本身。把它纳入同一条全局默认，意味着如果管理员选择 Enabled 并且不做任何显式配置，未来新增的 MCP 相关能力会沿着同一条默认路径自动放开。对已经在用 MCP 接内部系统的组织来说，这一项比其它功能更值得单独检查一遍。
把它放进一条链路上会更容易判断。假设企业现在维护着一份「已批准功能清单」，做法是每个新功能上线后由安全团队评估再开。选 Disabled 之后，这份清单的工作方式不变，只是从「评估后开启」变成「评估后批准」，工作量没变但多了一道系统内的审批动作。反过来，如果企业过去一直在用「先默认开启、出事再关」，那 Enabled 才是与现状一致的选择——真正需要动作的是那些一直没有明确立场、靠默认值漂着的功能。
时间线：那 28 天窗口在解决什么
公告对生效逻辑的三句话，合起来解释了这个窗口的用途。第一句：从 10 月 22 日起，策略生效。第二句：届时「未配置的合格 GA 功能与能力，会遵循你选择的全局默认」。第三句：显式决策会被保留，预览功能仍然需要主动选择加入。
第三句是这套设计里最人性化的一条：任何已经显式开过或关过的功能，不会被全局默认覆盖。也就是说，管理员不需要在 10 月 22 日之前把所有功能重新过一遍——只需要处理那些「从未显式配置过」的功能。28 天窗口的实际任务不是全量重审，而是把漂着的那些补上明确立场，否则它们会按全局默认自动落地。
边界，以及人必须在哪一步接管
公告本身的信息边界要说清楚：它没有逐条枚举受影响的单个功能，合格范围要对照 GitHub 的默认可用性文档；也没有给出例外情形的完整列表。策略的作用范围限于企业级和组织级设置，个人计划不在其列。生效是「逐步」的措辞，公告写的是合格功能与客户端会逐渐被设为该默认值。
需要人接管的判断至少有两点。第一，这条策略管的是「功能可见性」，不是「数据边界」。把某个功能设为可用，并不意味着它的数据处理方式符合你所在行业的合规要求——这一点要单独核。第二，预览功能保持主动选择加入，这是一个明确的安全垫：团队可以在功能达到 GA 之前先在预览阶段评估，等它转 GA 时已经有结论，避免在 10 月 22 日之后被动接受。把「在功能还在预览时就评估完」写进流程，比在它 GA 之后去追着关要省事得多。
如何配置
企业管理员进入企业设置的 AI Controls 页面，打开 Copilot 子页，在 Default policy for new features 下选择 Enabled、Disabled 或 Let organizations decide。选完之后，建议做两件事：一是对照 GitHub 关于默认可用性的文档，确认当前哪些合格功能仍是未配置状态；二是对其中风险较高的功能显式设置开关，因为显式决策会被保留，不会被全局默认覆盖。10 月 22 日之前完成这两步即可。
信息来源
GitHub Changelog《Default Enablement of Copilot features for Copilot Business and Enterprise》，2026 年 9 月 24 日：
https://github.blog/changelog/2026-09-24-default-enablement-of-copilot-features-for-copilot-business-and-enterprise/
GitHub Docs 中关于 Copilot 功能默认可用性（default availability）与例外情形的章节，为公告正文化合格范围的指向文档。
HiFox：将 Agent 变成真正的队友
另外，我们也在思考，AI 如何从个人提效走进团队协作。
HiFox 是一个让人和 AI Agent 在同一个工作现场协作的平台：你可以像给同事分派任务一样指派 Agent，在任务看板中跟踪进度、查看结果，让 Agent 成为团队里的队友。
👉 立即体验 HiFox：https://hifox.com
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，
欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
