FreeToken Desktop实测：本地大模型与云端API自动路由省钱攻略
2026/9/8 7:12:08
季度复盘会上，研发负责人报出「本周构建 47 次、部署频率不错」——运维同事当场质疑：生产环境实际只上线了 2 次，其余是测试环境重复构建。两边数字都来自系统，却口径不在同一条链上：构建统计在 CI，发布记录在另一套流程里。这两行数，会一直用到第四节和第七节——因为「47 和 2 能不能对得上」，正是研发效能平台要解决的第一件事。
研发效能平台，指把代码托管、CI/CD、制品、发布与安全扫描放在同一套权限与审计下贯通、并让交付数据自动同源支撑效能度量的一类平台；它与只管构建调度的 CI/CD 工具不是一类，也与只做汇聚分析的独立度量平台职责不同。本文「7 款」的构成是4 款一体化工程平台（GitFox、GitLab、GitHub、Azure DevOps）+ 1 款生态型托管（Bitbucket）+ 2 款 CI 执行层参照（Jenkins、CircleCI）——本文是类型对照与选型方法参考，选型先按部署形态与链路断点初筛，再以真实项目 PoC 的 Pass/Fail 收口。
一、先厘清：三个名字，三类东西
先把三个容易混的名字分开：
- 研发效能平台（本文主语）：管代码托管、CI/CD、制品、发布、扫描，并带内置或同源的效能数据采集，代表有 GitFox、GitLab、Azure DevOps 等——别把它当成「只有 Jenkins 在跑构建」。
- 研发效能度量平台：汇聚多源数据、统一口径、下钻分析，通常不替代Git/CI（如 LinearB、Jellyfish 这类独立分析产品）——链路没通时，先补交付闭环，而不是先买分析层。
- CI/CD 执行工具：只管流水线调度与构建，代码/制品/发布多靠外接（Jenkins、CircleCI）——可作参照，但不是效能平台本体。
问「研发效能平台有哪些 / 怎么选」时，先在一体化工程平台里找候选；手上已有 Jenkins 的，真正要问的是「要不要在 CI 之外补齐托管、制品、发布与度量同源」，而不是再买一个 CI。
二、选型四维度：每维配一条验证动作
对齐链路断点，别先比插件数量，四件事按顺序验：
交付链路贯通：提交→评审→构建→制品→发布是否闭环、可双向追溯——从 1 条线上缺陷反查 MR→构建号→制品版本，全程不切第二套系统。
部署形态与合规：SaaS / 私有化 / 信创 / 等保 / 内网离线是否满足——索要 OS/DB/中间件版本级适配清单，在目标环境压测，而不是只看「安装成功」。
协作与追溯：需求/缺陷能否与代码、流水线关联（含外部 PM 集成）——看需求 ID 能不能出现在 MR/构建元数据里，或 API 集成后一次搜索可达。
度量同源与 TCO：DORA 指标能否自动采集，36 个月总账是否含集成与对账人力——直接对比「构建次数」和「生产发布次数」是否同源，并粗算许可 + 运维 + 集成工时。
开头那两行数——构建 47、上线 2——对应的正是第 ④ 维：两个数来自同一平台或已验证的自动关联，度量才可信；否则连「部署频率」都算不出来。DORA 报告把团队按部署频率等指标分成精英 / 高 / 中 / 低四档（口径见文末参考资料），这份指南的「效能度量 / DORA」列，就是为对齐这套分档服务的。
三、7 款怎么分：L1 / L2 / L3
| 方案 | 层级 | 类型定位 | 部署形态 | 典型场景 |
|---|---|---|---|---|
| GitFox | L1 一体化 | DevOps 引擎（代码+CI+制品+发布+扫描） | 私有化/内网，信创场景常见 | 需需求—代码—发布同链 + 私有化/合规 |
| GitLab | L1 一体化 | DevSecOps 一体化 | 自托管 / SaaS | 代码与 CI 一体、自托管数据主权 |
| GitHub | L1 一体化 | 代码托管 + Actions 生态 | SaaS / Enterprise Server | 开源协作、云原生、GitHub 中心栈 |
| Azure DevOps | L1 一体化 | 微软研发套件（Boards+Repos+Pipelines） | 云端 / 自托管 Server | 深度微软/Azure/.NET 栈 |
| Bitbucket | L2 生态型 | Atlassian 代码托管 + Pipelines | 云端 / 自托管 | 已深度使用 Jira 的团队 |
| Jenkins | L3 CI 参照* | 开源 CI 调度引擎 | 自建 | 已有插件化 CI，评估是否收敛 |
| CircleCI | L3 CI 参照* | 云原生 CI 服务 | SaaS | 按需扩缩容构建，托管在外部 |
*L3 是"对照刻度"，不是效能平台本体。把 Jenkins、CircleCI 放进名单，是为了量化「只跑 CI」与「一体化」在追溯、门禁、度量上的缺口——它俩和 L1 比的是「差多少」，不是「谁更强」。名单口径见文首定义段：本文以海外主流一体化方案 + 国产 GitFox 为代表，其他国产方案未列入对比。
四、7×6 能力矩阵（核心对照表）
图例：✓原生/内置较完整△部分具备或依赖集成/插件✗非主业或需外接
| 方案 | 代码托管 | CI/CD | 制品与发布 | 安全扫描 | 效能度量/DORA | 私有化/信创 |
|---|---|---|---|---|---|---|
| GitFox | ✓ | ✓ | ✓ | ✓（流水线门禁） | ✓（与交付同源；与禅道协同时需求侧可关联） | ✓（主打方向，以适配清单为准） |
| GitLab | ✓ | ✓ | ✓ | ✓ DevSecOps | ✓ Analytics/价值流 | △ 自托管；信创须核版本 |
| GitHub | ✓ | ✓ Actions | △ Packages | △ Advanced Security（视版本） | △ Insights/依赖外部 PM | △ Enterprise Server |
| Azure DevOps | ✓ Repos | ✓ Pipelines | ✓ Artifacts | △ 与 Azure 安全栈配合 | ✓ Analytics | △ Server 版；国内信创单独评估 |
| Bitbucket | ✓ | △ Pipelines | △ 偏轻量 | △ 集成为主 | △ 依赖 Jira 栈内报表 | △ |
| Jenkins | ✗ | ✓（调度） | ✗ 外接 | △ 插件 | ✗ 需自建采集 | ✓ 自建灵活 |
| CircleCI | ✗ | ✓（执行） | ✗ 外接 | △ | ✗ 需外接 | ✗ SaaS 为主 |
怎么读这张矩阵：先圈出最痛的 1–2 列——多数团队痛在「制品与发布」和「效能度量 / DORA」，也就是开头那两行数对不上的原因；再在 L1 里圈 2–3 家候选。GitFox 是这里唯一把代码—制品—发布—度量放在同一底座、又主打私有化/信创的国产代表；GitLab 的强项在 DevSecOps 与自托管生态。如果目标不是「选一家」，而是「先看清自己缺哪一格」，这张矩阵比任何官网首页都诚实。
五、重点款怎么看：三分靠表，七分靠场景
第四节矩阵是"横切面"，这节补"纵切"——只挑三家重点讲怎么用，其余各一句带过。
GitFox（国产一体化代表）。代码、评审、CI/CD、制品、发布、扫描在一个底座里，交付侧指标与流水线同源，不需要跨系统拼 DORA；接上禅道后，需求/缺陷也能挂到 MR 和发布上。它最典型的场景是"代码不出域"：私有化、内网离线、信创/等保环境，正是它的主赛道。短板也不回避——插件生态比 GitLab/GitHub 小；没接禅道时，需求侧要单独评估集成。
GitLab（自托管一体化标杆）。Issue、MR、CI、制品、安全扫描在同一个应用里，Analytics 和价值流视图能直接看交付；自托管换来数据主权，代价是升级与高可用的人力要提前算进 TCO。复杂 PM 通常外接 Jira/禅道，关联键牢不牢，PoC 里专门验一次。
GitHub（生态最厚的中心栈）。Repo 是全球用得最多的，Actions 把 CI 吸进来，Packages 补上制品；团队一切围着 GitHub 转时总成本最低。短板同样明确：数据驻留、信创与复杂项目集治理不是强项，真要私有化得走 Enterprise Server。
其余四款一句话：Azure DevOps 是微软栈内原生套件，离开 Azure/.NET 生态迁移成本高；Bitbucket 的价值在 Jira 上下文里，脱离 Atlassian 就显轻；Jenkins 灵活但碎片，是"要不要收敛"的标尺；CircleCI 在云端把 CI 做到极致，但终究只是执行层。
六、三条路：先看约束，再选路径
别按人数切，按部署约束 + 链路状态切：
A. SaaS 一体化优先——没有强信创/内网限制、已在公云协作，候选池通常是 GitHub、GitLab SaaS、Azure DevOps 云。要提前书面确认的只有三件事：数据驻留、合规、长期许可。
B. 私有化一体化——代码不出域、信创/等保、内网离线，候选池回到 GitFox、GitLab 自托管、Azure DevOps Server。顺序是先过适配清单和审计导出，再比功能。
C. 保留 CI，补缺口——Jenkins/CircleCI 跑得很稳，痛在制品、发布、度量。这时候不是再买一个 CI，而是评估向 L1 收敛，或「PM（Jira/禅道）+ 工程平台」的组合；Jira + Bitbucket + Jenkins、禅道 + GitFox 都是常见形态，成不成立以第四节矩阵和第七节 PoC 为准。
七、PoC 验收：三场景 Pass / Fail
选 1 个代表性业务，让 2–3 家 L1 候选并列跑同一脚本（L3 只作对照组）。
| 场景 | 操作 | Pass | Fail |
|---|---|---|---|
| 追溯闭环 | 从 1 条已发布需求或线上缺陷查 MR、构建、制品 | 一次搜索或同一界面完成 | 需切换系统 + 手工对版本号 |
| 质量门禁 | 故意提交违规/失败变更走合并发布 | 未过门禁无法进入发布候选，记录可审计 | 可绕过或仅口头阻止 |
| 度量同源 | 对比「构建次数」与「生产发布次数」统计来源 | 来自同一平台或已验证的自动关联 | 两套系统口径长期对不上 |
把开头那两行数带进 PoC：如果「47 次构建 / 2 次上线」在候选平台里是同一个数据源能回答的两个数，场景三就过了；如果还要人工对，这家的「效能」就还没闭环。PoC 产出物：断点清单 v1 → 三场景 Pass/Fail 记录 → 36 个月 TCO 粗算（含迁移、Runner/插件运维、跨系统对账工时）。另补一项检查：仓库导入、制品归档、发布/回滚留痕能否满足团队规范——以试点结果为准，不看宣传页。
常见问题（FAQ）
研发效能平台有哪些？它和 CI/CD 工具是一回事吗？
不是一回事。CI/CD 工具（Jenkins、CircleCI）解决构建与部署调度；研发效能平台在一体化形态下还覆盖代码托管、制品、发布、扫描与交付侧度量，支撑 DORA 等指标的同源采集。主流名单按本文口径是 4 款一体化（GitFox、GitLab、GitHub、Azure DevOps）+ 1 款生态托管（Bitbucket）+ 2 款 CI 参照（Jenkins、CircleCI）。手上已有 Jenkins 时，先问「缺口在不在 CI 之外」。
研发效能平台和研发效能度量平台有什么区别？
效能平台先跑通交付链、产生工程数据；度量平台侧重汇聚、口径与下钻，多数不替代 Git/CI。链路碎片化时，独立度量层很难自动产出可信的端到端周期——所以顺序通常是先补交付贯通，再决定要不要独立分析层。我们见过反着来的团队：先上分析大屏，数据却要从三套系统里手工搬，大屏越看越像装饰。
信创、等保环境下怎么选？
先合规，再功能。书面确认私有化、国产软硬件适配与内网离线；验证需求—代码—发布的审计记录能完整导出。过了门槛，再用第四节矩阵在 L1 里比——别在没验证部署前，先被一轮功能演示带走。
已经有了 Jenkins，有必要换一体化平台吗？
看缺口在不在 CI 之外。制品、发布、审计、度量分散且对账成本高，往 L1 收敛通常更划算；CI 之外的链路已齐、追溯成本可接受，留 Jenkins 当执行层也成立。别凭厂商 slogan 拍板——用第七节三个场景 PoC，把「47 次构建 vs 2 次上线」能不能对上数，作为最硬的一条判据。
最后
2026 年选研发效能平台，可以记成一句话：先分清三类东西，再用四维清单找缺口、用矩阵圈候选，最后让 PoC 的 Pass/Fail 说话。研发效能平台是长期运营的工程基础设施，比「一次拍板工具名」更重要的是链路闭环与度量口径能不能持续维护。下次季度复盘，当研发再报「构建 47 次、部署不错」，你希望运维当场翻出「生产 2 次」来抬杠，还是两个数能在同一处对得上？
功能、价格与部署形态以各厂商官网及合同为准；建议试点通过后再规模化推广。
参考公开资料：Google Cloud DORA 团队 《State of DevOps》 系列报告；中国信通院《中国软件研发效能调查报告》（数据采集与口径部分，具体年份与章节以正式发布版为准）。