本次变化速览
Google 已停止销售新的 Gemini Code Assist Standard 和 Enterprise 订阅。现有订阅按合同继续运行和获得支持；增加席位与年度续订截至 2027 年 1 月 31 日，月度续订截至 2027 年 12 月 31 日。先核对自己的合同与账单周期，再规划 Gemini Enterprise 和 Antigravity 的迁移。
官方确认了哪些变化？
10 月 9 日发布记录宣布停止新订阅销售；订阅过渡说明给出了现有合同、席位和续订的具体边界。新购资格、续订窗口和合同终止日是不同字段，不应只看“2027 年停止续订”一句概括。
| 动作 | 日期或条件 | 含义 |
|---|---|---|
| 新购 Standard / Enterprise | 2026-10-09 起不可购买 | 不再按旧采购流程新增订阅 |
| 现有订阅使用与支持 | 持续至合同协议结束 | 停止销售不等于当天停用 |
| 增加许可证席位 | 可继续到 2027-01-31 | 之后不能再新增许可证 |
| 年度自动续订 | 可继续到 2027-01-31 | 之后年度订阅不能续订 |
| 月度自动续订 | 可继续到 2027-12-31 | 之后月度订阅不能续订 |
先确认你属于哪一种订阅状态
这里讨论 Google Cloud 的 Standard 和 Enterprise 订阅。个人版、Google AI 订阅与这两个版本不能只凭 Gemini 名称放在同一张账单表里。发布记录另有 6 月 18 日个人相关服务整合的背景，那不是这次 10 月 9 日的新购政策。
Google 把后续智能体编程辅助指向 Gemini Enterprise editions 中的 Antigravity。不能据此推断每个旧合同会自动迁移、每个席位都会自动获得新权限，或者价格和配置完全相同。采购负责人仍需向合同渠道核对适用版本和权益。
阅读规则前先分组
尚未购买
重新核对可采购的产品与实际权益，不再使用旧版购买教程作为结论。
现有年度订阅
记录本合同结束日、下一次续订日和增加席位需求，分别对照期限。
现有月度订阅
记录月度周期与最后可续订窗口，同时安排替代流程，避免等到窗口结束再试。
做一张可核实的合同与工具清单
- 由有权限的负责人打开实际订阅和合同记录，写清产品版本、账单账户、月度或年度、合同结束日和下一次续订日。不要把网页示例日期填成自己的期限。
- 盘点已经分配的许可证与计划增加的人员，把新增订阅和现有订阅增加许可证分开提问。记录合同渠道给出的书面确认。
- 列出团队依赖的编辑器扩展、CLI、组织配置和关键代码任务。用实际工具名称和版本建立清单，避免只写一个泛化的“AI 助手”。
- 给替代试点设置负责人、检查任务和回退方式。需要支持时只提交必要的合同与错误信息，不把仓库密钥、业务代码或凭据附在公开反馈中。
一个年度合同案例：截止点不能替代合同日
下面是原创虚构规划案例，不是 Google 的合同建议：团队 A 有一个年度合同，记录中的结束日为 2027 年 2 月 15 日，预计 2 月初增加两名开发者。负责人应分别确认合同支持区间和新增许可证规则，而不是把两项需求合成一个“届时还能不能用”的问题。
团队 A 的问题拆分
计划 2 月初再增加两个席位，并把 1 月 31 日理解成全部服务统一停止的日期。
核对现有合同能用至何时；新增许可证需求单独对照 1 月 31 日边界；提前完成替代工具试点，并向合同渠道确认续订安排。
迁移验收要覆盖真实工作，不只确认能登录
以下是编辑建议：从一项低风险、可复现的代码任务开始，例如为已有函数补充边界说明并运行原有检查。保留原任务、输入版本、候选补丁、运行结果和人工判断。登录成功只说明入口可访问，不能说明组织配置和日常工作都已迁移。
可复用模型更新的任务评估方法制定验收标准。跨应用工作则参考交付物可追溯的试点方法，但办公跨应用能力不代表 Code Assist 合同自动转换。
迁移试点的交付检查
- 账号、产品权益、编辑器与 CLI 入口按团队实际情况确认。
- 候选修改经过代码审查和项目原有检查，不直接覆盖正式仓库。
- 组织访问、数据范围和必要配置由管理员确认。
- 记录未支持任务、失败步骤和回退方式，再安排扩大范围。
月度续订到年底，不等于年中还能加席位
自编规划场景：一家团队当前有 12 个已分配的月度许可证，预计 2027 年 7 月 1 日加入三人。负责人看到月度自动续订窗口到 2027 年 12 月 31 日，就把迁移排在秋季。但官方增加许可证的窗口在 1 月 31 日结束；月度合同的另一条期限不能覆盖这项扩容需求。
真正要解决的是三名新成员届时使用什么受组织批准的工作流，而不是只证明现有 12 人还能登录。合同负责人应确认实际协议、人员变更安排和替代产品权益。现有许可证能否重新分配、替代产品如何收费或是否延续旧配置，不能从这份停售信息推出来。也不应因一个示例就提前采购未获批的席位。
把在职人员连续使用与新成员入职分成两个交付目标。前者依赖合同与支持期，后者需要替代入口、身份、组织权限和真实任务通过。两者可以有不同切换时间；如果组织不能同时维护两套环境，应更早安排统一试点，而不是等到新员工入职才发现工作说明只适用于旧扩展。
从最早受影响的任务倒排，不从最后续订日倒排
下面是编辑拟定的内部节点，不是 Google 的迁移承诺：1 月 8 日由负责人确认合同与三名新成员所需入口；1 月 15 日让试点人员在获准样例仓库完成一次已有测试驱动的小修复；1 月 22 日由另一人复现并决定是否采用。1 月 31 日是需要对照的官方动作边界，不能把它同时当作团队开始研究的日期。具体节点应按自己的合同与排期重写。
假设 1 月 15 日能登录替代服务，但 IDE 可以编辑、CLI 无法使用组织授权。试点应记为未通过所需工作流，定位到授权或产品入口，交给对应负责人处理。不要把 CLI 步骤从验收清单删掉，就宣布迁移成功；也不要推断旧订阅会自动补足新产品权限。到 1 月 22 日仍未解决，就需要调整新员工的获批工作方式或切换排期，并保留现有合同支持范围内的可行流程。
最后把操作说明、实际使用产品、已通过的任务和未支持步骤一起交接。原始公告能确定停售与续订规则；你的迁移结束，应由下一位成员能完成工作来证明。具体代码任务可沿用模型迁移的固定用例方法，但不能把文章里的案例当成已经完成的企业试点。
把时间节点放进采购计划，并持续复核
建立一个负责人可更新的迁移清单，把合同结束日与官方动作截止点并列。本文依据 10 月 9 日官方资料；采购或续订前再次打开原始说明，确认后续变化。本文不预测退款、价格、地区开放或自动迁移规则，也没有实测企业账号。
官方节点与编辑建议分别标明
- 2026-10-09
新订阅停止销售
官方生效日期；本文发布于 10 月 11 日，不把事件改写成今天发生。
- 2027-01-31
增加席位与年度续订边界
官方规则；自己的合同结束日仍需单独核对。
- 2027-12-31
月度续订边界
官方规则；试点与迁移进度由团队提前安排。
- 团队自定
正式切换验收
编辑建议：结合实际合同与任务结果确定，保留回退计划。
常见问题
停止新订阅是不是现在就不能使用？
不是。官方说明现有订阅持续运行和获得支持至合同协议结束。你的合同结束日与新增、续订截止点要分别核对。
年度与月度续订是同一天结束吗？
不是。官方说明年度自动续订和增加许可证可继续到 2027 年 1 月 31 日，月度自动续订可继续到 2027 年 12 月 31 日。执行前再查看最新原始说明。
旧订阅会自动变成 Antigravity 吗？
这份公告没有提供普遍自动迁移的保证。核对 Gemini Enterprise 版本、合同权益、账号配置和实际工具流程，完成试点后再安排切换。
