GitHub Copilot 9 月政策與計費變更：管理員在 9 月 28 日前檢查什麼

先記住三個時間點#

這些是 GitHub 宣布的生效窗口，不是每個帳號都會在同一分鐘切換。尤其 unified experience 使用「不早於 9 月 28 日」的說法，應把 9 月 28 日當成最晚需要完成檢查的準備線，而不是保證所有帳號同時 rollout 的時間。

Business 與 Enterprise 的計費流程會變得更嚴格#

GitHub 表示，從 9 月 1 日起將開始重新開放新客戶使用信用卡或 PayPal 註冊 Copilot Business／Enterprise，並強化帳號 vetting 與 billing experience。新座位要先完成每個 seat 的付款，使用者才會取得 Copilot access；既有客戶則預計從 10 月 1 日起，在下一個 billing cycle 對已分配座位 upfront charge。

管理員不要只把它理解成「價格調漲」。公告同時寫明 Business 與 Enterprise 的價格不變，但以下行為要納入預算預測：

• 超過 included usage 後，自己和使用者可能需要額外付款才能繼續使用 Copilot。
• Included usage 可能依座位成本的 prorated 規則按月分配。
• 取消座位不會產生 prorated refund，移除會反映在下一個月的 billing cycle。
• Billing cycle 中途新增座位仍會依加入日至週期結束的時間 prorate。
• Spend controls、usage tracking 與購買額外 AI credits 的選項仍會保留。

因此，現在應把「座位數」「付款方式」「included usage」「額外使用上限」放在同一份檢查表，而不是只看每月單價。若過去把 Copilot Billing Preview 退役後的 AI usage 與預算當成日常報表入口，也要一起確認文件與 dashboard 連結是否仍指向正式的 Billing settings。

9 月 28 日前要審核 unified Copilot policy#

GitHub 預計不早於 9 月 28 日將 Copilot Chat on github.com、GitHub Mobile Chat 和 Copilot cloud agent 重新整合成單一 Copilot experience。分開的政策會換成單一政策，統一體驗在 launch 後預設啟用；cloud agent 也會使用 Sandbox。

這一段對企業最重要的不是名稱，而是資料與存取邊界：GitHub 說明 github.com 的 chat data 會改以 agent sessions 的方式保存，保存時間從原本的 28 天變成帳號生命週期。若選擇 opt out，launch 後你或團隊會失去 github.com 與 GitHub Mobile 上的 Copilot access。

Business 和 Enterprise 管理員應在期限前：

1. 到 GitHub 的 Copilot settings 查看 cloud agent 將使用的 policy 選項。
2. 把 github.com、Mobile、cloud agent 的資料流、保存需求和成員資格交給安全／合規負責人覆核。
3. 以測試帳號確認開啟、停用或 opt out 後的實際入口，不要只依賴管理頁面上的文字。
4. 更新 onboarding、內部使用規範與資料保存說明，標出「client policy」和 repository permission 的差別。

這不是把所有權限合併成一個開關。若團隊仍在盤點 Copilot app 的入口，可以先看 GitHub Copilot app 的獨立存取政策；該文處理 app 與 CLI 的 client policy，這次公告則進一步影響 cloud agent、github.com 與 Mobile 的統一體驗。

Code Review 的 Default 將改成 Balanced#

GitHub 同時宣布，Copilot Code Review 的預設 review effort level 會從 Lite 改為 Balanced。這裡的關鍵字是 Default：如果 organization 或 repository 仍使用 Default，從 9 月 28 日起它會使用 Balanced；如果已經明確選 Lite，GitHub 表示會保留這項選擇。

Balanced 不等於品質保證，也不是所有 PR 都應該強制使用的模式。可以用 Copilot Code Review 的 Lite 與 Balanced 設定做背景，再依變更風險、延遲、AI credits 與人類 review 能力決定 default。權限、付款、測試與 required approval 仍然是另外的控制面。

如果希望維持 Lite，請在 9 月 28 日前於 organization 或 repository settings 明確選 Lite，不要只留下 Default 後期待未來行為不變。調整後以一個低風險測試 PR 和一個需要深度分析的 PR 驗證 actual level、review time 與 AI usage，並把結果記錄在團隊政策中。

管理員的最小檢查順序#

可以將這次公告拆成四個 owner，各自留下可驗證結果：

1. Billing owner：列出目前 seat assignment、付款方式、下一個 billing cycle、included usage 與超額使用控制。
2. Copilot policy owner：在 9 月 28 日前確認 unified experience 的 opt-in／opt-out 選擇、使用者範圍與資料保存需求。
3. Code review owner：盤點仍使用 Default 的 organization／repository，為不同風險級別選 Lite 或 Balanced。
4. 工程 owner：用測試帳號、測試 repository 與代表性 PR 驗證 access、review level、usage report 和 required checks。

每個變更都保存原本值、調整日期、負責人與回復方式。不要因為公告寫「prices are not changing」就略過預算測試，也不要因為 Balanced 是更深的 review 就把它當成不需要人類核准的自動門檻。

結論是：這次最需要提前處理的是「政策與預設值」，不只是帳單。先在 9 月 28 日前把 unified Copilot policy 和 Code Review effort level 寫成明確決策，再於 10 月 1 日對照 seat billing 與 AI usage，團隊才不會在 access、資料保存或費用出現差異時才臨時追設定。

常見問題#