评估标准自己看不见的部分

一份脱敏管线 v1 → v2 的修正过程。第一次跑通过 161 篇,各项指标都过门槛 — 但报告本身没问"分母是怎么算出来的"。

基于个人主页 dev-log 管线的真实开发 · 数据来自 stop-loss-review §6.5

这件事的背景

这个个人主页要展示一段时间以来的工作记录:计划文档、报告、心得、设计文档。素材分散在三个本地目录,大约 500 多个 .md 文件。

这些文件里有不能直接放到公开页的内容:项目代号、内部路径、机器可用的凭据形态(私钥头、SSH 公钥头等)。所以中间需要一个脱敏环节,把素材过一遍再写到博客可访问的目录。

v1 规则一眼合理:含敏感词的整篇文件,跳过。

敏感词列表大约是 igame / battle / lilith / D:/P4/ / AIWorkSpace 等几十个。任何文件里出现其中任意一个,整个文件不收录。跑完之后产出报告:

$ build-dev-log-index v1

included = 161   threshold ≥ 50   PASS
skipped  = 523
replaced = 252

各项指标都过门槛。按它自己的衡量方式,这是一次完成。如果只看这份报告,没什么需要回头的。

后来在审查里换了一种衡量方式。原本问的是"扫到多少 .md 里过了多少",分母是"扫到的 .md 总数"。换成问"21 篇手写需求里过了多少"。

21 篇手写需求是这个工作里相对最关键的素材源 — 用户原始写的需求、心得、项目愿景文档,都在这里。报告里把它们跟另外几百篇 plan / spec / 报告混在一个总数里算,通过率看上去过了门槛,但具体核心文档有没有过,报告没问。

实际数出来:21 篇手写需求,11 篇通过,10 篇被整篇跳过。

跳过的 10 篇里包括几个比较具体的:

被跳过的原因都不复杂:这些文档里出现了项目代号或私有路径等关键词,v1 规则不区分"概念性提到敏感词"和"实际含真凭据",一律整篇过滤。

还有一个副现象:通过的 161 篇里,有 16 篇是产线自己写自己的元报告 — 这个脱敏管线自身的迭代报告、wave 流水、诊断结果之类。这些不算真正"用户做过的工作",但都被算进 161 这个分子里,让通过率看上去更可观。

v2 把规则换成三档处理:

触发条件	处理方式
真凭据形态(私钥头、SSH 公钥头、长 base64、`sk-` 开头的 API key 等共 7 条)	整篇跳过
敏感词(项目代号、私有路径、内部环境变量名等约 25 条)	把片段替换为占位符
其他	直接输出

区分的核心是:"概念性提到一个敏感词"和"实际含机器可用的凭据"是两件事。前者可以替换掉就行(原文意思不丢);后者必须整篇剔除(凭据真的能用就是真的能用)。

流程对比:

flow · v1

flow · v2

替换规则举几个具体的:

被滤掉的关键文档全部回来了。312 次替换发生在通过的文章正文里。真凭据扫描跑过一遍没有残留。

"按自己的标准跑出来 PASS,换一种衡量方式就翻盘"这件事,跟具体场景关系不大,跟"自己定的标准自己跑"关系大。脱敏管线本身只是一个偶然的载体 — 如果同样的人定同样的标准跑同样的产物,无论换什么领域,都可能遇到类似问题。

之后的几个加固:

但这不能保证下一次没有新的衡量方式被漏掉。哪些项应该作为评判标准,本身是开放问题。

自审有用。v1 报告里的指标确实跑通了,门槛确实达成。自审在它的标准范围内有效。

但 自审只能审到标准里有的项。标准里没有的项,自审看不见,无论再跑多少次。要让那些项变可见,需要一个不沿用原标准的衡量方式。

这个新的衡量方式不一定来自另一个人。只要切一个新角度,看同一份产出,就可能触发这类检查。但新角度需要被显式提出 — 把"通过率 ≥ 50" 换成 "通过率 ≥ 80" 不算,这只是换数值,衡量的维度没变。把"按 .md 总数算"换成"按手写需求数算"才算,因为它换的是分母本身的定义。