GitHub Code Quality GA 后，100 名开发者真的只要每月 1000 美元吗？

GitHub Code Quality 已于 2026 年 7 月 20 日正式 GA。最吸引眼球的官方定价是：每位活跃提交者每月 10 美元。

于是，一个看起来很直接的问题就出现了：如果团队有 100 名开发者，是否每月准备 1000 美元就足够？——答案是：通常并没有这么简单。

真实情况是，只有当这 100 人都刚好落在 GitHub 官方定义的活跃提交者范围内时，这 1000 美元才只是最基础的许可费用。它还没有计入确定性扫描消耗的 GitHub Actions、AI 功能消耗的 GitHub AI Credits、自托管 Runner、平台维护、误报处理、修复工时，以及 PR 等待带来的协作成本。GitHub 自身的许可预估说明也明确提示，预估卡片只包含 per-committer 许可，Actions 分钟和 AI 用量并不在其中。

因此，在做采购或预算评估时，不要从“团队人数 × 10 美元”这个公式开始。更合理的出发点应该是五个关键对象：准备启用的仓库范围、这些仓库最近 90 天活跃提交者的并集、扫描工作负载、AI 的实际使用方式，以及能否通过灰度数据验证的增量质量收益。

先弄清楚产品能力和计费边界

Code Quality 是一款独立计费产品，适用于 GitHub Team 和 GitHub Enterprise Cloud，并不是 GitHub Advanced Security 或其他产品的附属功能。GA 首发阶段也不支持 GitHub Enterprise Server。

它整合了多项能力：包括 CodeQL 的确定性质量分析、AI 辅助检测、自动修复建议、组织级看板、Cobertura XML 覆盖率展示，以及通过 rulesets 设置质量与覆盖率门槛。CodeQL 规则分析当前支持 C#、Go、Ja va、Ja vaScript、Python、Ruby 和 TypeScript；AI 分析可覆盖更多语言，但只有受支持的语言才能生成完整的规则型 findings、分数以及相应的阈值效果。

GitHub 官方将产品成本拆分为三类：

1. 启用仓库的 active and unique committers 许可；
2. 确定性 CodeQL 扫描消耗的 GitHub Actions；
3. AI 检测与修复消耗的共享 AI Credits。

这三类成本的计量单位分别是“人”“Runner 用量”和“AI Credits”。它们本质上不是同一个维度，因此不能简单合并成一个“每人固定打包价”。

许可成本看的不是组织总人数，而是仓库集合上的人员并集

假设你计划启用 Code Quality 的仓库集合是 E，每个仓库 r 在最近 90 天内的活跃提交者集合是 A_r，合同中的许可单价是 P_L，那么许可成本可表示为：

License(E) = P_L × | ⋃ A_r |

按照当前公开定价，P_L = 10 美元/月。只要某位提交者的 commit 在最近 90 天内被 push 到启用仓库，就会被认定为活跃提交者，而不取决于该 commit 最初是在什么时候编写的。同一个人如果贡献了多个启用仓库，或出现在多个组织中，在对应的组织或企业计费边界内会被去重。

这也解释了新增仓库时的边际许可成本。如果当前已启用的仓库集合为 E，准备加入仓库 q，那么：

ΔLicense(q) = P_L × | A_q − ⋃ A_r |

真正决定新增费用的，不是仓库 q 一共有多少贡献者，而是其中有多少人还没有被现有启用仓库覆盖。比如，一个拥有 30 名贡献者的仓库，如果其中 28 人已经在其他启用仓库中计费，那么边际许可最多只来自剩余 2 人；反过来，一个只有 12 名贡献者的独立项目，也可能一次性新增 12 个许可。

官方计费页面还说明，活跃提交者可能包括组织成员、Enterprise Managed Users、外部协作者以及处于邀请状态的用户。GitHub App bots 会被忽略，但这并不意味着所有自动化身份都天然免费：GitHub 文档明确区分了 GitHub App bot 和 OAuth 型 machine user，后者本质上仍然是普通用户账号，不能在预算模型里自行剔除。

所以，你第一份需要准备的数据不应该是 HR 人员名单，而应该是“启用仓库—90 天提交者—既有许可覆盖”的映射关系表。Licensing 页面展示的是已经消耗的许可；当你在仓库或组织级别调整启用范围时，也会看到对应的计费影响，但这仍然只反映许可部分，并不是完整的总体拥有成本 TCO。

Actions 成本要分清托管分钟、自托管资源和已含额度

Code Quality 的确定性扫描是通过 GitHub Actions workflow 执行的。使用 GitHub-hosted Runner 会消耗 Actions 用量；使用 self-hosted Runner 虽然不会消耗 GitHub 托管分钟，但这只是费用没有出现在同一张 GitHub 账单上，并不代表它没有成本。

托管 Runner 的实际月成本可以这样估算：

Hosted Actions = Σ（各 Runner SKU 的 billable minutes × 对应单价）

这里必须使用 billable minutes，而不是把所有运行分钟直接乘单价。私有仓库通常会优先消耗套餐自带额度，公共仓库使用标准托管 Runner 通常免费；此外，larger runner、不同操作系统和不同算力规格的价格也并不相同。当前文档中列出的标准 Linux 2-core 基准价格是 0.006 美元/分钟，但在正式评估前，仍应以最新账单和价格页面为准。

扫描负载通常由以下因素共同决定：触发频率、单次 Job 时长、语言矩阵、失败重试、并行 Job 数量以及 Monorepo 扫描范围：

Raw scan minutes = Σ（扫描次数 × Job 数 × 每个 Job 的运行分钟）

并行执行只能减少墙钟时间，并不会自动降低总 Runner 分钟。任务失败后重跑时，失败部分和重跑部分都会被计入总用量。

对于自托管 Runner，则需要单独核算：

Self-hosted Runner= 实例或裸机折旧 + 存储 + 网络 + 空闲容量+ 镜像与补丁 + 编排与弹性 + Runner 运维

自托管可能更适合稳定且高利用率的扫描场景，但“GitHub 不收托管分钟费用”绝不等于“自托管零成本”。它只是把成本与可靠性责任，从 GitHub 转移到了组织自己的基础设施和运维体系上。

AI Credits 是共享池资源，不存在固定的“每次 Autofix 单价”

Code Quality 的 AI 功能是从计费实体的共享 AI Credits 池中扣减，而不是单独附带一份专属的 Code Quality 免费额度。官方定义为 1 AI Credit = 0.01 美元，每次交互根据模型调用实际消耗的 token 计价；Code Quality 使用的是 GitHub 调优后的模型、prompt 与系统行为组合，用户无法自行切换模型。

因此：

AI allocation cost = Code Quality AI Credits × 0.01 美元

但这个公式不能进一步简化成“每次扫描固定 X Credits”或“每次修复固定 Y 美元”。因为上下文长度和实际 token 用量都会变化。即使共享池尚未耗尽，当月没有额外现金账单，Code Quality 依然在占用原本可用于 Copilot 等产品的 AI Credits。所以，建议同时记录两种成本口径：

• 增量现金支出：当月实际 overage；
• 资源分摊成本：Code Quality 消耗的 Credits × 0.01 美元。

成本控制页面还给出了两个关键限制：PR 内的 AI 修复生成功能属于产品运行的一部分，不能单独关闭；可选的 AI findings page 默认关闭，且仍处于 public preview，启用后会额外消耗 Credits。若要彻底停止 Code Quality 的 AI 用量，只能在相应仓库上关闭 Code Quality。

另外，将修复任务委派给 Copilot cloud agent 属于可选能力，需要额外具备相应的 Copilot 许可，并继续消耗 AI Credits。预算模型中应把这部分与 Code Quality 自带的分析和修复建议分开归因，避免把额外的 Copilot 使用误算为基础产品成本。

可执行的月度 TCO 公式

如果只看 GitHub 厂商账单，最小公式是：

Vendor Bill= License+ Hosted Actions Overage+ AI Credits Overage

但对工程负责人来说，更有参考价值的是完整的月度模型：

Monthly TCO= License+ Hosted Actions+ Self-hosted Runner+ AI Credits+ Ops Labor+ Developer Friction

其中：

• Ops Labor：包括启用范围管理、规则集配置、覆盖率上传、成本报表、误报策略、例外审批与审计所需的人力投入；
• Developer Friction：包括 findings 分诊、重复告警确认、修复与复核、扫描失败处理，以及真正造成阻塞的主动等待时间；
• 全成本时薪应包含薪资、福利和组织分摊，但不能把整个 PR 墙钟时间全部当作损失，只统计那些无法并行处理的实际占用时间。

下面是一组纯演算示例，不能视为真实账单或官方基准：

假设这 5 个试点仓库在当月共产生 90 条 findings，经过人工确认后，其中 38 条属于“真实、非重复、值得处理”的有效发现，最终有 24 条修复被接受并合并，那么：

Cost per effective finding = 3,900.40 / 38 = 102.64 美元
Cost per accepted fix = 3,900.40 / 24 = 162.52 美元

这两个数字仍然不能直接视为 ROI。它们更适合用于横向比较不同仓库、不同规则强度以及不同月份的投入效果。真正的收益评估，必须扣除已有 lint、CodeQL、coverage 或其他质量平台原本就能发现的问题；重复发现也不能重复计入价值。

同一个月度数字要保留三种口径

在预算讨论中，最常见的误区就是把“账单没有增加”理解成“没有成本”。对于 Code Quality，至少应同时展示三种口径。

第一种是当月增量现金支出。许可证按合同结算，Actions 只计算超出已含额度后的 billable usage，AI 只计算共享池耗尽后的 overage，自托管资源则可能体现在云厂商账单或内部基础设施成本中。这一口径适合财务付款，但会低估被占用的套餐额度和内部资源。

第二种是资源分摊成本。即便 Actions 还未超出套餐额度，Code Quality 消耗的分钟也会挤占其他 CI 工作流；即便 AI Credits 尚未形成 overage，也会减少 Copilot 等产品可使用的共享池。你可以按官方单价或组织内部转移价格，为这些资源分配一个影子成本，用于横向比较仓库价值，但不要把它误报为实际现金支出。

第三种是工程 TCO，即资源分摊成本再加上平台与开发者人力投入。这一口径最适合用于决定是否启用、缩小范围或彻底关闭。三种口径必须并行保留，不能只挑最小的现金账单，也不能把全部共享额度都当成新增现金支出。

可以把避免的损失单独估算为：

Expected a voided loss= Σ（逃逸概率 × 返工或事故影响 × 工具归因系数 × 置信度）

这些概率和影响值，必须基于组织自己的缺陷历史、事故复盘或专家评估，并做低、中、高三档敏感性分析。不要为了得到更漂亮的 ROI，随意给一次“可能避免的事故”填入夸张金额，也不要承诺启用后一定能显著减少线上缺陷。

用仓库分层来决定启用范围

不建议在整个组织内一键开启。更合理的做法是先从八个维度评估仓库：最近 90 天活跃提交者及其边际许可、变更频率、事故与返工代价、受支持语言覆盖情况、现有 lint/CodeQL/coverage 的重叠度、ruleset 的可落地性、AI 修复的使用概率，以及业务关键程度。

对于已经拥有成熟 lint、CodeQL、coverage 和质量平台的团队，也不应该因为“基础设施已经完备”就默认启用。成熟基线确实会降低接入门槛，但也可能意味着新增 findings 大量重复。对于这类仓库，真正重要的指标是“有效且非重复发现率”，而不是总发现数量。

用“硬条件 + 评分”避免漂亮总分掩盖结构性问题

仓库分层可以采用 0—3 分的简化评分，但前提是先执行硬条件过滤。如果仓库运行在 GitHub Enterprise Server、Actions 被禁用、没有明确责任人、无法获取成本归因数据，或者规则型分析所需语言完全不受支持且 AI/覆盖率也没有清晰用途，那么它就应该直接进入 hold 或 unsuitable，不能因为业务关键度高就硬把总分拉回来。

通过硬条件后，再分别计算价值分和实施分：

Value Score= 变更频率 + 事故/返工代价 + 业务关键度 + 现有质量缺口
Readiness Score= 语言适配 + CI/Runner 就绪 + ruleset 就绪 + 成本可观测性
Cost Pressure= 边际活跃提交者 + 预计扫描负载 + AI 使用概率 + 人力处置量

enable_now 应同时满足高价值、高就绪和可接受成本；高价值但信息不足的仓库进入 evaluate_mode；价值偏低或与现有工具高度重叠的仓库进入 hold。评分的目的，是让不同仓库基于同一套问题做判断，而不是制造一个脱离实际上下文的统一及格线。

尤其要留意两种反直觉场景。第一，低频变更但故障代价极高的仓库，可能适合做定时扫描，却未必适合在每个 PR 上设置强门禁；第二，高频仓库可能产生大量 findings，但如果其中大部分早已被现有 lint 捕获，它的增量价值反而可能低于一个变更不多、却积累了更多历史质量债务的仓库。启用强度必须与风险水平和信号质量匹配，而不是简单跟随仓库热度。

30 天灰度试点：先拿到自己的数据，再决定扩大、缩小还是关闭

建议选择 3—5 个具有代表性的仓库：一个高频核心服务、一个成熟前端仓库、一个数据或自动化仓库、一个低频但事故代价高的系统，再加上一个可选的 Monorepo。注意，不要只挑最容易成功、最“好看”的仓库做试点。

如果组织在 public preview 阶段已经使用过 Code Quality，那么应导出 7 月 20 日 GA 之前的许可、Actions、AI 和 PR 数据作为历史基线；如果之前没有相关数据，就使用“启用前最近 30 天”作为替代基线，并明确标注来源，不能伪造 GA 前的对照样本。

第 1—7 天只做启用和观测：通过 Selected repositories 或自定义属性筛选试点范围；ruleset 保持 Evaluate 模式，先观察哪些 PR 理论上会被拦截，但实际上不做强制阻断。GitHub 官方也建议，先用一到两周的 evaluate-mode 数据来校准阈值。

第 8—14 天完成分诊：将每条 finding 标记为有效非重复、有效但重复、误报、低价值建议或无法判断；同时记录修复是否被接受、Autofix 是否需要改写、人工复核耗时、扫描失败次数以及 P95 检查时长。

第 15—21 天调整范围和阈值：剔除低价值的试点仓库，调整 ruleset 严重度和覆盖率要求，并确认 Code Quality workflow 在 PR 上能够稳定返回结果后，才允许把任一规则从 Evaluate 切换为 Active。否则，ruleset 可能错误地阻断所有 PR。

第 22—27 天只在一个高信号仓库上做有限强制，重点观察紧急绕过、开发者等待和回退情况；其他仓库继续保持 evaluate。第 28—30 天再形成三选一结论：扩大到下一批仓库、缩小到少数高价值仓库，或直接关闭产品。

试点期间必须分别采集：

• 许可：唯一活跃提交者、仓库新增的边际许可；
• Actions：扫描次数、各 SKU billable minutes、失败和重试；
• AI：Code Quality Credits、共享池占用和实际 overage；
• 质量：有效非重复发现、重复发现、误报、修复率和回退；
• 交付：P50/P95 检查时长、PR 主动等待、阻断和例外；
• 人力：平台维护、分诊、修复与复核时间。

仓库级归因应优先依赖 billing usage report；按照官方说明，这是将 Code Quality 支出和 Actions 用量细分到仓库或组织层级的唯一位置，普通 UI 没有完全等价的视图。AI usage 页面则可以按 Product 分组，查看 Code Quality 对共享 AI 池的占用情况。

有效发现必须能追溯到“工具到底新增了什么”

每条 finding 至少应记录仓库、PR、规则或来源、严重度、是否已被既有工具发现、人工判定结果、处置动作、修复提交以及复核时间。只有同时满足“真实问题、非重复、与当前变更相关、最终被修复或形成明确风险接受”的记录，才适合作为增量价值的证据。

对于未修复的真实问题，也不能一律视为工具失败。需要区分“没有优先级”“修复代价过高”“建议不准确”“缺少测试”“等待业务窗口”等不同原因。否则，低修复率可能会被错误归因于发现质量，而真实原因其实是产品排期或技术债务策略。反过来，点击一次自动修复也不能直接算作成功：只有建议经过测试、代码审查并被合并，且没有快速回退，才应计入 accepted fix 分母。

这套记录机制还可以帮助识别开发者疲劳。如果同一规则持续被 dismiss、同类问题反复申请例外，或者开发者只是为了通过检查做机械式改写却没有真正降低风险，那就说明门禁优化的是表面指标，而不是代码质量本身。此时更合理的做法是回到 Evaluate，调整阈值或缩小仓库范围，而不是一味要求团队提升“修复率”。

预算和质量门槛必须同时通过

GitHub 支持为 Code Quality 单独设置预算，而且 Code Quality 预算属于强制 hard stop；共享 AI Credits 也可以设置总预算或 Code Quality SKU 级预算。Actions 预算则应独立配置并评估影响范围，因为设置过宽的 hard stop，可能会连带阻断仓库中的其他托管工作流。

下面是作者建议的试点起始门槛，它不是 GitHub 官方指标，也不适合直接复制成长期 SLO：

停止条件应该在试点启动前就写清楚：例如无法在 7 天内获取仓库级成本数据；Code Quality workflow 不稳定；预算 hard stop 被触发；关键语言无法产出可用规则结果；有效非重复发现率持续过低；例外和误报导致团队频繁绕过门禁；或者新增收益已被现有工具完全覆盖。只要其中任何一个结构性条件成立，都应将仓库归为 hold 或 unsuitable，而不是靠扩大样本来掩盖问题。

最终决策单位不是席位数量，而是被验证过的仓库组合

小团队、低变更仓库，未必值得为了 Code Quality 增加一份独立许可和新的流程复杂度；成熟质量平台可能带来的只是重复信号；低质量告警会持续消耗开发者注意力；自托管 Runner 也不可能凭空消灭基础设施成本。Code Quality 的真实价值，不能从产品功能清单中直接推导，只能从试点仓库的增量发现、修复接受率、交付影响和避免返工的实际证据中验证出来。

所以，“100 名开发者是不是每月 1000 美元”这个问题，更准确的改写方式应该是：

只有当预算门槛和质量门槛都被验证通过，团队才值得继续扩大启用范围。否则，更正确的动作不是继续为全组织采购，而是缩小范围、暂停试点，甚至直接关闭。

FAQ

100 名员工是否一定对应 100 个许可证？

不一定。真正的计费对象是启用仓库中最近 90 天的活跃提交者并集，最终仍应以组织 Licensing 页面显示的数据为准。

自托管 Runner 是否等于没有 Actions 成本？

不是。它通常不会消耗 GitHub 托管分钟，但硬件、排队、运维和机会成本依然存在。

公开价格能否直接拿来计算 ROI？

不能。公开价格只能给出成本的起点，真正的收益必须用团队自己的有效发现、修复结果和流程数据来验证。

参考资料

1. S1：GitHub Code Quality is now generally a vailable
2. S2：About GitHub Code Quality
3. S3：GitHub Code Quality billing
4. S4：Viewing and managing GitHub Code Quality costs
5. S5：GitHub Code Quality license estimate
6. S6：Enabling GitHub Code Quality
7. S7：GitHub Actions billing
8. S8：Usage-based billing for organizations and enterprises
9. S9：Setting up budgets
10. S10：Rolling out GitHub Code Quality at scale
11. S11：Differences between GitHub Apps and OAuth apps
12. S12：Setting code quality thresholds for pull requests
13. S13：Preventing code quality issues from reaching your default branch