规范发布后要复盘执行情况，先要回答一个问题：提交里的工作项编号是“填了”，还是“用上了”。检查代码提交关联规范是否真正被执行，需要固定统计口径，计算关联覆盖率、关联有效率和追溯使用率，再用抽检和交叉验证识别形式化关联。本文给出一套可复算的检查方法，适用于规范发布一段时间后的月度或季度复盘。
要点总览（TL;DR）
- 判断代码提交关联规范是否真正被执行，要分三层看：形式合规（提交带工作项编号）、内容有效（关联指向真实且状态合理的工作项）、环节使用（关联在评审、发布说明、缺陷回溯中被实际引用）。
- 核心指标有三个：关联覆盖率、关联有效率、追溯使用率，分别回答“填了多少”“填得对不对”“有没有被用”，三个指标要同时统计、分别解读。
- 统计前必须固定取数口径：分母选全部提交还是合并请求，无关联、格式错误、关联到不存在工作项分别计数，自动生成提交与依赖升级是否排除，跨仓库多分支按提交哈希去重。
- 识别形式化执行靠抽检：对高覆盖低有效的仓库抽取 20 至 30 条提交，核对关联工作项与代码变更内容是否匹配，并与评审记录、发布记录交叉验证。
- 指标用于复盘与整改，不宜直接挂钩个人绩效；高覆盖率不等于高质量关联，样本量小或仓库差异大时横向比较要谨慎。
评估目标：判断规范是“填了”还是“用上了”
本次检查的对象是代码提交与业务工作项之间的对应关系，要回答的问题是：提交信息中的工作项编号是否真实、准确，并且在实际研发环节中被使用。检查结果用于复盘规范落地情况、发现执行偏差并推动整改，不直接作为个人或团队的考核排名依据。
“真正被执行”可以拆成三层观察，三层依次递进，前一层是后一层的基础：
| 层次 | 判断问题 | 可观察证据 |
|---|---|---|
| 形式合规 | 提交信息里是否带有工作项编号，格式是否符合规范 | 提交记录中的编号字段、格式校验结果 |
| 内容有效 | 编号是否指向真实存在、状态合理的工作项，且与代码变更内容相关 | 工作项是否存在、状态是否匹配、变更内容与工作项描述是否对应 |
| 环节使用 | 关联是否在评审、缺陷回溯、发布说明等环节被实际引用 | 评审记录中的关联引用、发布说明中的工作项清单、回溯记录 |
只统计第一层，容易得到好看的数字却看不出执行质量；三层都看，才能区分“为了合规而填”和“为了协作而用”。检查结论应落到具体偏差类型和整改动作上，例如某仓库关联到已关闭工作项的比例偏高，就对应提交前核对工作项状态的整改项。
指标与范围：覆盖率、有效率与使用率
三个指标分别回答不同问题，需要同时统计、分别解读，不能用一个指标替代另一个。
| 指标 | 计算方式 | 回答的问题 |
|---|---|---|
| 关联覆盖率 | 含工作项编号的提交数 ÷ 统计范围内提交总数 × 100% | 规范在形式上被遵守的范围有多大 |
| 关联有效率 | 关联到真实且状态合理工作项的提交数 ÷ 含关联的提交数 × 100% | 已填的关联中有多少是真实有效的 |
| 追溯使用率 | 评审或发布记录中实际引用关联的变更数 ÷ 应引用关联的变更数 × 100% | 关联信息是否在协作环节被真正使用 |
统计范围需要事先写清楚：时间窗按提交时间还是合并时间截取；统计对象是全部提交、有效提交还是合并请求；覆盖哪些分支和仓库；是否包含特定类型的提交。范围不同，指标数值不可直接比较，跨周期对比时必须保持范围一致。
“状态合理”需要给出可操作的定义，例如关联的工作项在提交时处于进行中或待验证状态，关联到已关闭且与本次变更无关的工作项计为无效。这个定义应在检查前确定并写入口径说明，避免抽检时临时调整标准。
数据口径：分母、缺失值与不可比情形
口径不固定，数据就不可比。检查开始前应形成一份可复算的取数口径说明，至少覆盖以下四类规则。
分母选择
分母可选全部提交、有效提交或合并请求，三者含义不同。以全部提交为分母时，自动生成提交会拉低覆盖率；以合并请求为分母时，一个合并请求包含多次提交，覆盖率反映的是变更粒度而非提交粒度。建议在口径说明中写明选择理由，并在多个周期内保持一致。分母为零时（例如某仓库当期无提交），该仓库不参与比率计算，单独标注为无数据，不按 0% 处理。
缺失值分类
无关联、关联格式错误、关联到不存在的工作项是三种不同情况，应分别计数，不能合并为“未关联”。格式错误说明规范理解或工具校验有问题，关联到不存在的工作项说明编号来源不可靠，两者的整改方向不同。
排除项规则
自动生成提交、依赖升级、回滚提交是否排除，需要在口径中明确。常见做法是自动生成提交和依赖升级提交排除在覆盖率分母之外，回滚提交保留并单独标注，因为回滚往往对应线上问题，其关联信息对追溯有参考价值。排除规则一旦确定，各周期沿用同一规则。
跨仓库与多分支去重
同一变更经多次 cherry-pick 进入不同分支时，按提交哈希去重，避免同一变更被重复计数；跨仓库统计时，先按仓库分别计算再汇总，直接合并所有提交计算总覆盖率会掩盖仓库间差异。
计算与评估步骤：从统计到抽检验证
检查流程分定量统计和定性验证两部分，先算指标，再用抽检确认指标背后的执行质量。
- 按口径说明导出统计范围内的提交记录、工作项状态和评审发布记录，形成检查数据集。
- 计算关联覆盖率、关联有效率和追溯使用率，按仓库和团队分别列出，同时给出总体值。
- 对高覆盖低有效的样本做人工抽检。例如覆盖率超过 90% 但有效率低于 70% 的仓库，抽取 20 至 30 条提交，逐条核对关联工作项与代码变更内容是否匹配。
- 核对关联工作项的状态与变更时间是否合理，识别关联到已关闭、已取消或与变更内容无关工作项的情况。
- 与评审记录、发布记录交叉验证：评审意见中是否引用工作项编号，发布说明中的变更清单是否来自关联工作项，缺陷回溯时能否通过关联快速定位变更。
- 汇总偏差类型和数量，形成检查结论，区分口径问题、工具校验问题和执行习惯问题。
抽检样本量不必追求统计显著性，重点是覆盖不同仓库、不同团队和不同提交类型，让结论能指向具体整改对象。抽检记录应保留样本清单和判断依据，便于复查时复现。
例子：一次月度执行检查的完整演算
以下数字为演示情景，实际检查需替换为真实仓库数据后复算。
某团队当月统计范围内共有 400 次提交，其中自动生成提交和依赖升级提交 40 次，按口径排除后分母为 360 次。含工作项编号的提交 324 次，关联覆盖率为 324 ÷ 360 = 90%。
在 324 次含关联的提交中，关联到真实且状态合理工作项的有 259 次，关联有效率为 259 ÷ 324 ≈ 79.9%。其余 65 次中，关联到不存在工作项 12 次，关联到已关闭且与变更无关工作项 38 次，编号格式错误 15 次。
当月应引用关联的变更（进入评审或发布说明的变更）为 200 次，评审记录或发布说明中实际引用关联的为 130 次，追溯使用率为 130 ÷ 200 = 65%。
抽检选取有效率偏低的两个仓库共 40 条提交，发现 9 条提交的关联工作项与代码变更内容明显不匹配，例如提交修改的是登录模块，关联的却是报表需求；另有 6 条提交在评审意见中未出现任何工作项引用。结合数据可以判断：形式合规程度较高，但关联内容质量和环节使用存在明显偏差，整改方向是提交前核对工作项状态与内容、在评审模板中要求引用工作项编号，并对格式错误集中的仓库检查提交模板配置。
解读与限制：指标能说明什么、不能说明什么
覆盖率、有效率、使用率反映的是关联规范在特定范围和周期内的执行情况，不能直接等同于研发质量或团队绩效。解读时需要注意以下边界。
- 高覆盖率不等于高质量关联。覆盖率只说明提交带了编号，编号是否真实有效要看有效率，是否被使用要看使用率。
- 单指标不能代表整体执行水平。覆盖率 95% 配合有效率 60%，与覆盖率 80% 配合有效率 90%，反映的是不同性质的执行问题，需要分别分析。
- 样本量小或仓库差异大时可比性有限。提交量少的仓库，一两次异常提交就会让比率大幅波动；不同仓库的技术栈和提交习惯不同，横向比较应谨慎。
- 指标宜用于改进反馈。把关联指标直接与个人绩效挂钩，容易诱发为填而填的行为，反而降低关联信息的可信度。
- 关联规范执行得好，也不必然带来更快的交付或更少的缺陷，指标说明的是协作信息的完整程度，不是因果保证。
把检查结果落到协作流程中
检查的价值在于推动整改。复盘会后，应把偏差结论转化为具体整改项：明确问题类型（格式错误、关联无效、评审未引用）、责任仓库或团队、负责人和完成时间，并记录在可跟踪的工作项中，而不是停留在会议纪要里。
整改项需要与原始证据对应，便于复查时核对。例如“某仓库关联到已关闭工作项比例偏高”这一整改项，应附上抽检样本和对应提交记录；复查时按同一口径重新计算该仓库的有效率，对比整改前后的变化。复盘节奏可以按月或按季度固定，每次复查沿用同一份口径说明，口径调整需单独记录并说明原因。
在工具层面，ONES 可以将代码提交与工作项关联，工作项状态和评审记录在同一系统中查看，检查发现的整改项可以直接建为工作项并指派负责人，复查时通过工作项状态和关联记录核对整改进展。这样检查结论、整改动作和复查证据形成一条可追溯的链路，减少在多个系统间手工核对的工作量。
常见问题
规范刚发布一个月，提交量还很少，这时候做执行检查有意义吗？
有意义，但结论的用法要调整。发布初期提交量少，比率类指标波动大，一两次异常提交就可能让覆盖率大幅变化，此时更适合关注偏差类型而不是比率高低。可以先把检查流程跑一遍，确认取数口径、缺失值分类和抽检方法是否可行，同时收集格式错误、关联到不存在工作项等具体问题，反馈给提交模板或工具校验环节。等积累两三个统计周期后再做跨周期对比，结论会更稳定。
合并请求里包含多次提交，按提交统计还是按合并请求统计？
两种口径回答的问题不同。按提交统计反映提交粒度的规范遵守情况，适合检查提交信息本身的质量；按合并请求统计反映变更粒度的关联情况，适合与评审、发布环节对齐。建议在口径说明中明确选择一种作为主口径，并在多个周期内保持一致。如果两种都要看，就分别计算、分别报告，不要混在一起比较。同一变更经 cherry-pick 进入多个分支时，按提交哈希去重，避免重复计数。
提交关联到已关闭的工作项，一定算无效关联吗？
要看具体情况，关键是关联工作项与本次代码变更是否相关。如果提交是对已关闭工作项的补充修复、缺陷回归或文档更新，关联到已关闭工作项是合理的，可以在抽检时单独标注为“合理例外”。如果提交修改的是登录模块，关联的却是几个月前关闭的报表需求，就属于无效关联。建议在检查前把“状态合理”写成可操作的定义，例如关联工作项在提交时处于进行中或待验证状态，例外情形单独记录，避免抽检时临时调整标准。
抽检发现的问题怎么让团队真正改掉，而不是下次检查还出现？
把抽检结论转成具体、可核对的整改项，而不是笼统的“加强规范意识”。每个整改项写清楚问题类型（格式错误、关联无效、评审未引用）、涉及仓库或团队、负责人和完成时间，并附上抽检样本和对应提交记录。复查时按同一口径重新计算该仓库的有效率，对比整改前后的变化。格式错误集中，就检查提交模板配置；关联无效集中，就在提交前增加工作项状态核对；评审未引用，就在评审模板中要求引用工作项编号。整改项建为可跟踪的工作项，复查时通过状态和关联记录核对进展。
关联覆盖率和有效率都不错，是不是说明规范执行到位了？
还要看追溯使用率。覆盖率和有效率说明提交信息填得比较规范、关联内容基本真实，但关联是否在评审、发布说明、缺陷回溯中被实际使用，需要单独统计。如果评审意见里很少出现工作项引用、发布说明的变更清单不来自关联工作项，说明关联信息还停留在记录层面，没有进入协作流程。三个指标配合看，才能判断规范是“填了”还是“用上了”。另外，指标反映的是协作信息的完整程度，不直接等同于交付速度或缺陷数量。
