门禁报了十次其中三次被开发者关闭于是报告写“误报率 30%”。关闭可能因为真误报也可能是临时豁免、重复告警或风险被接受。状态按钮不是人工裁决。一份能解释的台账要先分清告警、真实问题、待定项和例外再谈比例。否则模型给出的“准确率”只会让争议变得更难追踪。先写清分母在已裁决告警中误报占比是误报数除以“有效告警加误报告警”。这是告警层面的错误发现比例。统计学里的假阳性率则需要所有真实负例包括没有触发告警的负例不能混用名字。召回率还需要独立问题审计有多少真实问题被规则发现有多少漏掉。只看触发的告警永远看不到漏报。审计样本的抽样方式也要公开专挑已知 bug 的结果不能代表整个仓库。图中的“误报率”特指已裁决告警中的误报占比并非统计学 FPR待定项另列。两类记录分别计算保存为review-ledger.mjs运行node review-ledger.mjs。下方全部是人工构造样例没有对应团队成绩。import assert from node:assert/strict; function alertSummary(alerts) { const count { valid: 0, false: 0, pending: 0 }; const ids new Set(); for (const a of alerts) { if (ids.has(a.id) || ![valid, false, pending].includes(a.verdict)) throw new Error(duplicate or invalid verdict); ids.add(a.id); count[a.verdict]; } const reviewed count.valid count.false; return { ...count, reviewed, falseDiscoveryRatio: reviewed ? count.false / reviewed : null }; } function recallFromIssueAudit(issues) { if (!issues.length) return null; if (issues.some(x typeof x.detected ! boolean)) throw new Error(audit result missing); return issues.filter(x x.detected).length / issues.length; } const alerts [ { id: a, verdict: valid }, { id: b, verdict: valid }, { id: c, verdict: false }, { id: d, verdict: pending } ]; assert.equal(alertSummary(alerts).falseDiscoveryRatio, 1 / 3); assert.equal(alertSummary(alerts).pending, 1); assert.equal(alertSummary([{ id: x, verdict: pending }]).falseDiscoveryRatio, null); assert.equal(recallFromIssueAudit([{ detected: true }, { detected: false }]), 0.5); assert.equal(recallFromIssueAudit([]), null); assert.throws(() alertSummary([...alerts, alerts[0]])); console.log(ledger denominators passed; fixture ratios are not team measurements);待定项不进入已裁决分母同时单独展示数量。若待定占比很高报告要说清楚不能把一个看似漂亮的比例放在首页却藏掉积压。样本少时展示原始数量比保留两位小数更有用。每条告警要能回到原样例最少记录规则 ID 与版本、工具版本、提交、文件位置、原始输入、诊断理由、裁决人、裁决时间和后续动作。规则改版后不要覆盖旧裁决相同样例可以在新版本重新跑形成前后对照。重复告警按独立问题聚合但保留出现次数。临时豁免只表示某个范围暂不阻断不意味着告警是误报基线调整也不是修复。把这些状态分开才能判断问题在规则还是流程。对于语义争议可由第二位审查者独立裁决再记录分歧与最终解释。AI 可以归纳候选与相似案例不应自行把争议改成 valid也不应为了让 CI 通过修改金标准。阻断级别随证据调整确定且高影响的规则可以进入必需检查有价值但边界较多的规则先提醒高噪声规则应补样例或缩小范围。格式、语义和性能波动应分开统计不能把 Lighthouse 噪声直接算成 ESLint 的语义误报。保护分支仍要核对必需检查名称、评审和 bypass 配置。台账完整不代表合并控制已经生效本地报告变绿也不能代替服务端配置验证。本轮已执行 Node v26.3.0 的分母与重复记录测试没有扫描真实仓库没有人工标注团队样本也没有可报告的实际准确率。示例仅证明计算口径不证明某条规则有效。参考资料ESLint 自定义规则滚动文档LHCI 配置滚动文档GitHub 保护分支滚动文档。采用前核对规则与审计样本版本。