https://youdozi.github.io/zh-CN/youdozi's memoryzh-CNMon, 26 Oct 2026 15:42:21 GMThttps://youdozi.github.io/zh-CN/digest/2026-05-09-copilot-grok-code-fast-retirement/https://youdozi.github.io/zh-CN/digest/2026-05-09-copilot-grok-code-fast-retirement/新闻日期 · 2026-05-09 GitHub 宣布计划于 2026-05-15 从 Copilot 中停用 Grok Code Fast 1。此处记录的是公告中的时间安排，并未独立核实停用是否已经完成。 公告称，由于模型提供商弃用该模型，停用日期被提前。<section><h2>Grok Code Fast 1 停用公告明确了 Copilot 范围</h2><p>新闻日期 · 2026-05-09 GitHub 宣布计划于 2026-05-15 从 Copilot 中停用 Grok Code Fast 1。此处记录的是公告中的时间安排，并未独立核实停用是否已经完成。 公告称，由于模型提供商弃用该模型，停用日期被提前。</p><a href="https://github.blog/changelog/2026-05-08-upcoming-deprecation-of-grok-code-fast-1">阅读原报道</a></section>Mon, 26 Oct 2026 15:42:21 GMT2026-10-26T15:42:21.545Zhttps://youdozi.github.io/zh-CN/digest/2026-05-06-codeql-sanitizer-and-validator-models/https://youdozi.github.io/zh-CN/digest/2026-05-06-codeql-sanitizer-and-validator-models/新闻日期 · 2026-05-06 GitHub 介绍了 CodeQL YAML 数据扩展中的声明式净化器与验证器，使用 barrierModel 和 barrierGuardModel。 公告列出的起始可用版本为 CodeQL 2.25.2。这是该历史公告中的最低版本，并非当前的升级建议。<section><h2>CodeQL 的数据式建模新增自定义净化器与验证器</h2><p>新闻日期 · 2026-05-06 GitHub 介绍了 CodeQL YAML 数据扩展中的声明式净化器与验证器，使用 barrierModel 和 barrierGuardModel。 公告列出的起始可用版本为 CodeQL 2.25.2。这是该历史公告中的最低版本，并非当前的升级建议。</p><a href="https://www.infoq.com/news/2026/05/github-codeql-security-modeling/">阅读原报道</a></section>Mon, 26 Oct 2026 15:42:21 GMT2026-10-26T15:42:21.545Zhttps://youdozi.github.io/zh-CN/digest/2026-05-16-copilot-grok-code-fast-retirement-confirmation/https://youdozi.github.io/zh-CN/digest/2026-05-16-copilot-grok-code-fast-retirement-confirmation/新闻日期 · 2026-05-16 GitHub 通报，Grok Code Fast 1 已于 2026-05-15 在其各项 Copilot 体验中弃用。这是产品厂商确认完成停用的公告，有别于此前仅公布停用计划日期的公告。 公告称，Copilot Enterprise 管理员可能需要通过模型策略启用替代模型。<section><h2>GitHub 通报 Grok Code Fast 1 在 Copilot 中的停用</h2><p>新闻日期 · 2026-05-16 GitHub 通报，Grok Code Fast 1 已于 2026-05-15 在其各项 Copilot 体验中弃用。这是产品厂商确认完成停用的公告，有别于此前仅公布停用计划日期的公告。 公告称，Copilot Enterprise 管理员可能需要通过模型策略启用替代模型。</p><a href="https://github.blog/changelog/2026-05-15-grok-code-fast-1-deprecated">阅读原报道</a></section>Mon, 26 Oct 2026 15:42:21 GMT2026-10-26T15:42:21.545Zhttps://youdozi.github.io/zh-CN/digest/2026-07-03-copilot-credit-pools-and-additional-spending/https://youdozi.github.io/zh-CN/digest/2026-07-03-copilot-credit-pools-and-additional-spending/新闻日期 · 2026-07-03 GitHub 宣布在 Enterprise Cloud 上为 Copilot Business 和 Enterprise 提供成本中心 AI 额度池。公告发布时可通过 REST API 配置，而设置界面中的管理功能仍在规划中。 额度池上限限制成本中心可从企业共享的内含额度中使用多少；成本中心预算则管理内含额度池耗尽后的按量计费费用。这些控制措施针对不同的支出阶段，可结合使用。 GitHub 根据已分配的许可证计算额度池上限。达到上限时，企业可以阻止继续使用内含额度，也可以在允许超额使用的情况下放行额外支出，因此额度池并不自动构成所有费用的硬性上限。<section><h2>Copilot 额度池：内含用量与额外支出</h2><p>新闻日期 · 2026-07-03 GitHub 宣布在 Enterprise Cloud 上为 Copilot Business 和 Enterprise 提供成本中心 AI 额度池。公告发布时可通过 REST API 配置，而设置界面中的管理功能仍在规划中。 额度池上限限制成本中心可从企业共享的内含额度中使用多少；成本中心预算则管理内含额度池耗尽后的按量计费费用。这些控制措施针对不同的支出阶段，可结合使用。 GitHub 根据已分配的许可证计算额度池上限。达到上限时，企业可以阻止继续使用内含额度，也可以在允许超额使用的情况下放行额外支出，因此额度池并不自动构成所有费用的硬性上限。</p><a href="https://github.blog/changelog/2026-07-02-cost-centers-now-support-included-usage-caps">阅读原报道</a></section>Mon, 26 Oct 2026 15:42:21 GMT2026-10-26T15:42:21.545Zhttps://youdozi.github.io/zh-CN/digest/2026-05-07-github-security-advisory-search/https://youdozi.github.io/zh-CN/digest/2026-05-07-github-security-advisory-search/新闻日期 · 2026-05-07 GitHub 在仓库的 Security 标签页中直接加入了安全公告搜索和筛选功能。 公告列出的受支持搜索或筛选关键字包括 sort（排序）、package（软件包）、ecosystems（生态系统）和 severity（严重程度）。<section><h2>GitHub 仓库安全公告新增搜索与筛选</h2><p>新闻日期 · 2026-05-07 GitHub 在仓库的 Security 标签页中直接加入了安全公告搜索和筛选功能。 公告列出的受支持搜索或筛选关键字包括 sort（排序）、package（软件包）、ecosystems（生态系统）和 severity（严重程度）。</p><a href="https://github.blog/changelog/2026-05-06-search-and-filter-bar-for-repository-security-advisories">阅读原报道</a></section>Mon, 26 Oct 2026 15:42:21 GMT2026-10-26T15:42:21.545Zhttps://youdozi.github.io/zh-CN/digest/2026-07-12-multi-region-replication-and-failover-trade-offs/https://youdozi.github.io/zh-CN/digest/2026-07-12-multi-region-replication-and-failover-trade-offs/新闻日期 · 2026-07-12 文章作者对比了两种设计：各区域独立提供服务的 active-active 架构，以及在本地处理读取、将远程写入代理到全局写入区域的架构。需要权衡的因素包括复制、冲突处理和跨区域写入延迟。 对于 active-passive 模式，作者描述了由主区域处理流量、备用区域持续接收复制的方式。文章提醒，未经演练的故障转移路径可能在启用时失效，并建议在规划中采用实测的故障转移表现。本文未纳入原文中的成本节省百分比，也未纳入延迟恢复估算。<section><h2>多区域设计：复制、写入与故障转移的权衡</h2><p>新闻日期 · 2026-07-12 文章作者对比了两种设计：各区域独立提供服务的 active-active 架构，以及在本地处理读取、将远程写入代理到全局写入区域的架构。需要权衡的因素包括复制、冲突处理和跨区域写入延迟。 对于 active-passive 模式，作者描述了由主区域处理流量、备用区域持续接收复制的方式。文章提醒，未经演练的故障转移路径可能在启用时失效，并建议在规划中采用实测的故障转移表现。本文未纳入原文中的成本节省百分比，也未纳入延迟恢复估算。</p><a href="https://www.infoq.com/articles/multi-region-latency-cost-tradeoffs/">阅读原报道</a></section>Mon, 26 Oct 2026 15:29:08 GMT2026-10-26T15:29:08.424Z