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 成本要区分托管分钟、自托管资源和已含额度
- AI Credits 是共享资源，不存在固定的“每次 Autofix 价格”
- 可执行的月度 TCO 公式
- 用仓库分层决定启用范围
- 30 天灰度：先获得自己的数据，再决定扩大、缩小或关闭
- 预算和质量必须同时过关
- 最终决策单位不是席位，而是一个被验证的仓库组合
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，则：
License(E) = P_L × | ⋃ A_r |
按当前公开标价，P_L = 10 美元/月。某位提交者只要其 commit 在最近 90 天内被 push 到启用仓库，就会被视为活跃，不取决于该 commit 最初是什么时候 authored；同一人贡献多个启用仓库或多个组织时，在相应组织或企业计费边界内去重。[S1][S3]
这也给出了新增仓库的边际许可成本。若已经启用仓库集合为 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，后者仍是普通用户账户，不能在预算模型中自行排除。[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 的实际月成本可写为：
Hosted Actions = Σ（各 Runner SKU 的 billable minutes × 对应单价）
这里必须使用 billable minutes，而不是把所有运行分钟直接乘单价。私有仓库通常先消耗套餐所含额度，公共仓库使用标准托管 Runner 通常免费；larger runner、不同操作系统和不同算力规格的单价也不同。当前文档列出的标准 Linux 2-core 基准单价为 0.006 美元/分钟，但发布前仍应以最新账单和价格页为准。[S7]
扫描量由触发次数、单次 Job 时长、语言矩阵、重试、并行 Job 和 Monorepo 范围共同决定：
Raw scan minutes = Σ（扫描次数 × Job 数 × 每个 Job 的运行分钟）
并行只能缩短墙钟时间，不会自动减少总 Runner 分钟。失败后重跑也会把失败部分和重跑部分都计入用量。[S7]
自托管 Runner 则应单独计算：
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]
因此：
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 发票，最小公式是：
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 墙钟时间都当成损失，只统计无法并行工作的实际占用。
下面是一组纯演算示例，不能视为真实账单或官方基准：
| 变量 | 示例假设 | 月成本 |
|---|---|---|
| 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 条修复被接受并合并，则：
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 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，不能靠业务关键度高把总分拉回来。
通过硬条件后，再分别计算价值分和实施分：
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？
不能。公开价格只能给成本起点，收益必须用团队自己的有效发现、修复和流程数据验证。
参考资料
- S1：GitHub Code Quality is now generally available
- S2：About GitHub Code Quality
- S3：GitHub Code Quality billing
- S4：Viewing and managing GitHub Code Quality costs
- S5：GitHub Code Quality license estimate
- S6：Enabling GitHub Code Quality
- S7：GitHub Actions billing
- S8：Usage-based billing for organizations and enterprises
- S9：Setting up budgets
- S10：Rolling out GitHub Code Quality at scale
- S11：Differences between GitHub Apps and OAuth apps
- S12：Setting code quality thresholds for pull requests
- S13：Preventing code quality issues from reaching your default branch
