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

事实核验时间：2026 年 7 月 30 日。文中的价格演算均为示例，不是作者账单、客户数据或 GitHub 官方 ROI。
发布边界：公开价、产品支持范围、Runner 单价、AI Credits 与预算行为均为 2026-07-30 快照；示例不是作者账单或官方 ROI，发布前必须复核。

摘要

100 名开发者乘以每人每月 10 美元，只能得到 Code Quality 的许可底价。真正的月度 TCO 还要加入 GitHub Actions、AI Credits、自托管资源和运营成本，并按仓库边际成本与有效发现决定启用范围。本文给出人员并集、三张成本账、四级仓库分层和 30 天灰度方法。

关键词

GitHub Code Quality、Active Committer、GitHub Actions、AI Credits、TCO

先确定产品和计费边界
许可成本不是组织总人数，而是仓库集合上的人员并集
[Actions 成本要区分托管分钟、自托管资源和已含额度](#Actions 成本要区分托管分钟、自托管资源和已含额度 "#Actions-%E6%88%90%E6%9C%AC%E8%A6%81%E5%8C%BA%E5%88%86%E6%89%98%E7%AE%A1%E5%88%86%E9%92%9F%E8%87%AA%E6%89%98%E7%AE%A1%E8%B5%84%E6%BA%90%E5%92%8C%E5%B7%B2%E5%90%AB%E9%A2%9D%E5%BA%A6")
[AI Credits 是共享资源，不存在固定的"每次 Autofix 价格"](#AI Credits 是共享资源，不存在固定的“每次 Autofix 价格” "#AI-Credits-%E6%98%AF%E5%85%B1%E4%BA%AB%E8%B5%84%E6%BA%90%E4%B8%8D%E5%AD%98%E5%9C%A8%E5%9B%BA%E5%AE%9A%E7%9A%84%E6%AF%8F%E6%AC%A1-Autofix-%E4%BB%B7%E6%A0%BC")
[可执行的月度 TCO 公式](#可执行的月度 TCO 公式 "#%E5%8F%AF%E6%89%A7%E8%A1%8C%E7%9A%84%E6%9C%88%E5%BA%A6-TCO-%E5%85%AC%E5%BC%8F")
用仓库分层决定启用范围
[30 天灰度：先获得自己的数据，再决定扩大、缩小或关闭](#30 天灰度：先获得自己的数据，再决定扩大、缩小或关闭 "#30-%E5%A4%A9%E7%81%B0%E5%BA%A6%E5%85%88%E8%8E%B7%E5%BE%97%E8%87%AA%E5%B7%B1%E7%9A%84%E6%95%B0%E6%8D%AE%E5%86%8D%E5%86%B3%E5%AE%9A%E6%89%A9%E5%A4%A7%E7%BC%A9%E5%B0%8F%E6%88%96%E5%85%B3%E9%97%AD")
预算和质量必须同时过关
最终决策单位不是席位，而是一个被验证的仓库组合

GitHub Code Quality 已于 2026 年 7 月 20 日正式 GA。最醒目的价格是：每位 active committer 每月 10 美元。 $S1$

于是，一个看似简单的采购问题出现了：团队有 100 名开发者，是不是每月准备 1000 美元就够了？

不一定。只有当这 100 人都落入官方定义的活跃提交者集合时，1000 美元才是基础许可；它仍未包含确定性扫描消耗的 GitHub Actions、AI 功能消耗的 GitHub AI Credits、自托管 Runner、平台维护、误报处置、修复时间和 PR 等待。GitHub 自己的许可预估说明也明确指出，预估卡片只覆盖 per-committer 许可，不包括 Actions 分钟和 AI 用量。 $S5$

因此，购买决策不能从"团队人数 × 10 美元"开始，而要从五个对象开始：准备启用的仓库集合、这些仓库最近 90 天的活跃提交者并集、扫描工作量、AI 使用方式，以及能够被灰度数据验证的增量质量收益。

先确定产品和计费边界

Code Quality 是独立付费产品，适用于 GitHub Team 和 GitHub Enterprise Cloud；它不是 GitHub Advanced Security 或其他产品许可的附带能力，GA 首发时也不支持 GitHub Enterprise Server。 $S1$ $S3$

它把几种能力放在同一产品里：CodeQL 的确定性质量分析、AI 辅助检测、自动修复建议、组织级看板、Cobertura XML 覆盖率展示，以及通过 rulesets 设置质量和覆盖率要求。CodeQL 规则分析当前支持 C#、Go、Java、JavaScript、Python、Ruby 和 TypeScript；AI 分析可以覆盖更多语言，但只有受支持语言才能产生完整的规则型 findings、分数和相应阈值效果。 $S2$ $S12$

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

启用仓库的 active and unique committers 许可；
确定性 CodeQL 扫描消耗的 GitHub Actions；
AI 检测和修复消耗的共享 AI Credits。 $S3$ $S4$

这三个量的单位分别是"人""Runner 用量"和"AI Credits"。它们不能合成一个"每人固定全包价"。

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

设计划启用 Code Quality 的仓库集合为 E，仓库 r 在最近 90 天内满足官方条件的活跃提交者集合为 A_r，实际合同下每个许可月价为 P_L，则：

text 复制代码

License(E) = P_L × | ⋃ A_r |

按当前公开标价，P_L = 10 美元/月。某位提交者只要其 commit 在最近 90 天内被 push 到启用仓库，就会被视为活跃，不取决于该 commit 最初是什么时候 authored；同一人贡献多个启用仓库或多个组织时，在相应组织或企业计费边界内去重。 $S1$ $S3$

这也给出了新增仓库的边际许可成本。若已经启用仓库集合为 E，准备加入仓库 q，则：

text 复制代码

Δ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，后者仍是普通用户账户，不能在预算模型中自行排除。 $S3$ $S11$

所以，第一份输入数据不应是 HR 名册，而应是"启用仓库---90 天提交者---既有许可覆盖"的关系表。Licensing 页面显示的是已消费许可；仓库或组织级启用变更还会显示相应计费影响，但这仍只是许可部分，不是完整 TCO。 $S3$ $S6$

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

Code Quality 的确定性扫描以 GitHub Actions workflow 运行。GitHub-hosted Runner 会消耗 Actions 用量；self-hosted Runner 不消耗托管分钟，但只代表费用不出现在同一个 SKU 上。 $S3$ $S6$

托管 Runner 的实际月成本可写为：

text 复制代码

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

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

扫描量由触发次数、单次 Job 时长、语言矩阵、重试、并行 Job 和 Monorepo 范围共同决定：

text 复制代码

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

并行只能缩短墙钟时间，不会自动减少总 Runner 分钟。失败后重跑也会把失败部分和重跑部分都计入用量。 $S7$

自托管 Runner 则应单独计算：

text 复制代码

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

自托管可能适合稳定、高利用率的扫描负载，但"GitHub 不收托管分钟"不能推出"自托管免费"。它只是把成本和可靠性责任转移到组织自己的基础设施。

AI Credits 是共享资源，不存在固定的"每次 Autofix 价格"

Code Quality 的 AI 功能从计费实体的共享 AI Credits 池扣减，而不是获得一份独立的 Code Quality 免费额度。官方定义为 1 AI Credit = 0.01 美元，每次交互按模型调用消耗的 token 计价；Code Quality 使用 GitHub 调优后的模型、prompt 和系统行为组合，不支持用户切换模型。 $S3$ $S4$

因此：

text 复制代码

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。 $S4$

另外，委派修复给 Copilot cloud agent 属于可选功能，需要相应 Copilot 许可并继续消耗 AI Credits。预算中应把它与 Code Quality 自带分析和修复建议分开归因，避免把额外 Copilot 使用伪装成基础产品成本。 $S2$ $S13$

可执行的月度 TCO 公式

仅看 GitHub 发票，最小公式是：

text 复制代码

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

工程负责人需要使用更完整的月度模型：

text 复制代码

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

其中：

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

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

变量	示例假设	月成本
License	48 名唯一活跃提交者 × 10 美元	480.00 美元
Hosted Actions	3,400 个 billable Linux 分钟 × 0.006 美元	20.40 美元
Self-hosted Runner	分摊后的实例、存储和空闲容量	180.00 美元
AI Credits	18,000 Credits × 0.01 美元	180.00 美元
Ops Labor	12 小时 × 80 美元全成本时薪	960.00 美元
Developer Friction	26 小时 × 80 美元全成本时薪	2,080.00 美元
Monthly TCO	六项合计	3,900.40 美元

假设这 5 个试点仓库当月产生 90 条 findings，经人工确认后得到 38 条"真实、非重复、值得处理"的有效发现，其中 24 条修复被接受并合并，则：

text 复制代码

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，即资源分摊成本再加上平台和开发者人力。它适合做启用、缩小和关闭决策。三种口径必须同时保留，不能只挑最小的现金账单，也不能把全部共享额度都算成新增现金支出。

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

text 复制代码

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

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

用仓库分层决定启用范围

不应全组织一键开启。先按八个维度评估仓库：最近 90 天活跃提交者及边际许可、变更频率、事故与返工代价、受支持语言覆盖、现有 lint/CodeQL/coverage 重叠、ruleset 可落地性、AI 修复使用概率和业务关键度。

决策	典型条件	处理方式
`enable_now`	高频变更、业务关键、受支持语言占主导；已有 owner、CI 和成本数据；边际许可与 Runner 容量在预算内	小范围启用，先 evaluate，再对高置信规则转 Active
`evaluate_mode`	价值可能较高，但与现有工具重叠度、误报率或 AI 用量未知；仓库具有代表性	纳入 30 天试点，只观察不阻断，完整记录三类官方用量和人力
`hold`	低变更、小团队、缺少 owner、成本无法归因、CI 容量不足、规则集或覆盖率基础未准备好	补齐数据和责任人后再评估，不先付出长期流程复杂度
`unsuitable`	GitHub Enterprise Server；Actions 无法启用；归档、镜像、生成代码仓库；不受支持语言且无法形成有用的 AI/覆盖率路径；无法满足合规或审计要求	不启用，保留现有工具或选择其他方案

已有成熟 lint、CodeQL、coverage 和质量平台的团队不应因为"基础设施已经齐全"就默认启用。成熟基线会降低接入成本，但也可能意味着新增 findings 大量重复。对这类仓库，最重要的指标是"有效且非重复发现率"，不是总发现数。

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

仓库分层可以使用 0---3 分的简化评分，但必须先执行硬条件。若仓库运行在 GitHub Enterprise Server、Actions 被禁用、没有责任人、无法取得成本归因数据，或规则型分析所需语言完全不受支持且 AI/覆盖率也没有明确用途，应直接进入 hold 或 unsuitable，不能靠业务关键度高把总分拉回来。

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

text 复制代码

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 数据校准阈值。 $S10$

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

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

第 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 对共享池的占用。 $S4$

有效发现必须能够追溯到"工具新增了什么"

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

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

这套记录还能识别开发者疲劳。如果相同规则持续被 dismiss、同类问题反复申请例外，或开发者为了通过检查做机械改写却没有改变风险，说明门禁正在优化表面指标而不是代码质量。此时应回到 Evaluate，调整阈值或缩小仓库范围，而不是要求团队提高"修复率"。

预算和质量必须同时过关

GitHub 支持为 Code Quality 设置预算，而且 Code Quality 预算是强制 hard stop；共享 AI Credits 也可以设置总预算或 Code Quality SKU 级预算。Actions 预算应独立配置并评估影响范围，因为过宽的 hard stop 可能同时阻断仓库里的其他托管工作流。 $S4$ $S9$

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

指标	建议起点	未达标动作
月度 TCO	不超过批准的试点上限 `B`	停止扩大，定位许可、AI 或人力主因
有效非重复发现率	≥ 40%	若连续两周低于 25%，缩小或关闭
修复接受率	有效可修复 findings 中 ≥ 50%	检查规则信号、修复质量和团队意愿
重复发现率	≤ 30%	与现有 lint/CodeQL/coverage 去重后再评估
每个有效发现成本	不高于内部同类审查基准	只保留高价值仓库或规则强度
P95 检查时长	不超过现有 CI P95 的 120%，且目标小于 15 分钟	调整 Runner、范围或停止强制
规则例外率	≤ 5%	超过 10% 表明门禁与实际代码库不匹配
PR 主动等待增量	≤ 10%	回到 Evaluate，查找串行阻塞和失败重试

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

最终决策单位不是席位，而是一个被验证的仓库组合

小团队、低变更仓库可能不值得增加一份独立许可和新流程；成熟质量平台可能只得到重复信号；低质量告警会消耗开发者注意力；自托管 Runner 也不会消灭基础设施成本。Code Quality 的价值不能从产品功能表中推导，只能从试点仓库的增量发现、修复接受、交付影响和避免返工证据中确认。

因此，"100 名开发者是不是每月 1000 美元"应被改写为：

哪些仓库值得进入启用集合？这些仓库会引入多少新的 90 天活跃提交者、多少 Runner 工作量和多少 AI Credits？在加入运维与开发者时间后，每个有效非重复发现和每个被接受修复的成本是多少？

只有当预算门槛和质量门槛同时通过，团队才应扩大范围。否则，正确动作不是继续为全组织购买，而是缩小、暂停或关闭。

FAQ

100 名员工是否一定产生 100 个许可证？

不一定。计费对象是启用仓库中 90 天内的活跃提交者并集，仍应以组织 Licensing 页面为准。

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

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

公开价格能否直接算 ROI？

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

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