GitHub Code Quality 许可证用量可下载为 CSV 报告

你现在可以下载 GitHub Code Quality 许可证用量的 CSV 报告，以便将你的许可证数量与你自己的记录进行核对。

每一位消耗 Code Quality 许可证的活跃提交者。

在过去 90 天内收到其提交的仓库。

每位提交者是否唯一归属于单个仓库或组织。

使用唯一提交者明细，识别在何处禁用 Code Quality 可以为下一个计费周期释放许可证，而不改变你当前的许可证费用。

要下载你的报告，请前往你所在组织或企业的 Billing and licensing 页面，打开 Licensing，然后从 Code Quality 卡片下载 CSV。

CSV 下载在 GitHub Team 和 GitHub Enterprise Cloud 上可用。

有关详情，请参阅 Viewing and managing GitHub Code Quality costs。

加入 GitHub Community 的讨论。

GitHub 上线 Code Quality 许可证用量的 CSV 导出能力，组织与企业可下载报告，用唯一提交者明细核对许可证数量、定位可释放的席位。

• GitHub 上线 Code Quality 许可证用量的 CSV 导出能力，组织与企业可下载报告，用唯一提交者明细核对许可证数量、定位可释放的席位。
• 原贴提到：You can now download a CSV report of your GitHub Code Quality license us
• 来源：github.blog

这是什么信号：GitHub 给 Code Quality 补上了一块此前缺失的能力——许可证用量可导出为 CSV。官方描述里给出的字段很具体：哪些活跃提交者在消耗 Code Quality 许可证、哪些仓库在最近 90 天内收到过他们的提交、以及这位提交者是否只归属于单一仓库或组织。入口固定在组织或企业的 Billing and licensing 页，Licensing 下的 Code Quality 卡片。

为什么重要：席位型产品的采购摩擦，往往不在买，而在对账。过去企业要核对 Code Quality 的许可证数量，只能依赖控制台里的汇总数字，和内部资产台账对不上时缺少可落地的凭据。CSV 把「谁在用、在哪个仓库用」这条链路打开了，等于把许可证从一笔黑箱支出变成了可逐人核对的清单。官方还特别点出一个动作：用唯一提交者明细找出哪些地方禁用 Code Quality 可以释放下一计费周期的许可证——这句话本身就说明 GitHub 知道客户在关心「能不能少买」，并愿意把依据交出来。

对谁有价值：直接受益的是企业里的平台工程、开发者体验和 IT 采购/财务协作方。人数规模在几十到上千人的 GitHub Enterprise Cloud 或 Team 组织，通常最需要这类明细：他们既要向财务解释续费金额，也要面对内部「到底有多少人真的在用」的质询。做许可证归因、成本分摊或工具链精简的团队，也可以把这份 CSV 当数据源。

可以怎么行动：第一，先把 CSV 导出来存一份基线，和自家资产系统或 HR 名单做一次人级比对，找出仅消耗未使用的「僵尸席位」。第二，按仓库或组织维度统计提交者分布，识别那些实际用量极低、可以关停 Code Quality 的范围，再评估下一计费周期能省多少。第三，把导出动作纳入定期流程，例如每个计费周期前跑一次，让续费谈判有据可依。第四，检查权限与合规口径：确认由谁持有 Billing 页面访问权、导出的文件如何存放，避免把人员提交信息散落在不受控的表格里。

风险或限制：功能仅在 GitHub Team 和 GitHub Enterprise Cloud 提供，其他版本的组织拿不到这份报告。报告基于最近 90 天的提交活动，意味着刚入职或刚转移仓库的人可能还未被完整计入，判断席位去留时不宜只看单次快照。官方明确该明细用于「下一个计费周期」的释放规划，而不是立即退费，所以不要在财务口径上把它误读为当期账单减免。另外，禁用 Code Quality 本身会带来代码质量能力的缺口，释放许可证与保留能力之间需要业务方权衡，而不是纯粹的成本决策。

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《GitHub Code Quality 许可证用量可下载为 CSV 报告》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。

• Allison 原帖