WordPress插件评分规则升级后，前后差异该信哪一版
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /dc73ae95969c.html
📄
WordPress插件评分规则升级后，前后差异该信哪一版
先给判断：升级后评分变了，通常不是插件本身突然变好或变坏，而是同一批检测项被重新加权、阈值被调整，或旧报告里有些项目当时根本没被计分。要解释差异，先把两次评分拆成“检测项清单、每项得分、权重、阈值”四列，再对比哪些项是新增、删除、改权重，而不是直接比较两个总分。只有确认评分口径一致，分数变化才能归因给插件；口径不一致时，差异只能说明规则换了。
先判断两次评分是否可比较
可比较的前提是：检测项集合相同、每项满分相同、权重相同、阈值相同。四个条件里只要有一个变了，总分就没有直接可比性。实际操作中，你可以先做一次“口径对齐”：把旧报告的检测项逐条抄进表格，再把新报告的检测项并排列出，标记出三类别——两边都有的、只在新版出现的、旧版有但新版没有的。
如果三类别里“只在新版出现”或“旧版有但新版没有”的数量超过总项数的两成，那么两次总分差异的主要来源很可能是规则覆盖范围变了，而不是插件行为变了。这时正确的下一步不是解释分数，而是先决定：你是要沿用旧口径看历史趋势，还是接受新口径重新建立基线。
两种做法：沿用旧口径还是接受新基线
第一种做法是沿用旧口径。适用条件是：你需要和过去几个月的历史评分做连续对比，或者团队内部有基于旧评分的验收标准。代价是你得自己维护一份映射表，把新报告里能对应上的项手动折算回旧权重，新增项暂时不计分。这个动作的结果是趋势线保持连续，但你实际上放弃了新规则想强调的检测维度，长期看会漏掉新规则关注的风险点。
第二种做法是接受新基线。适用条件是：旧评分本来就没有对外承诺，或者你更关心当前规则下的真实状态。代价是历史对比断档，旧分数不能再拿来当参照。动作上，你需要把升级后的第一次完整评分定为新基线，记录日期和当时的规则版本，之后所有对比都从这条基线起算。结果是趋势重新可读，但你需要接受一段“没有历史”的空窗期。
选择依据可以简化成一句话：如果旧评分被写进了合同、验收单或对外报告，优先沿用旧口径并保留映射表；如果旧评分只是内部参考，直接接受新基线更省事，也更能反映当前规则的真实要求。
用一组证据区分“规则变了”和“插件变了”
光看总分无法区分这两种原因。可以看三个可观察的信号：
- 单项得分大面积平移：如果多数检测项的得分都朝同一方向小幅移动，更像阈值或权重调整；如果只有少数项剧烈变化，更像插件本身在那几项上出了问题。
- 新增项集中在某一类：如果新增检测项都集中在安全或性能某一类，说明规则在补盲区，总分变化主要来自覆盖范围扩大。
- 同一版本插件在两次规则下重测：假设你保留同一版本插件，分别用旧规则和新规则各跑一次。如果两次结果差异和“升级前后”的差异方向一致，就能基本确认是规则导致的；如果重测结果和升级前接近，那差异更可能来自插件在这期间被改动过。这个例子是假设的比较方法，不是实测结论。
需要提醒的是，重测次数、运行环境、缓存状态都可能影响结果。单次重测只能作为参考信号，不能单独证明规则是唯一原因。如果条件允许，对同一版本插件用两套规则各测两到三次，看差异是否稳定复现，再下结论。
把解释写成可复核的记录
无论选哪种做法，最后都应留下一份简短记录，包含：规则版本或升级日期、两次评分的检测项对照表、你采用的折算方式（如果有）、以及新基线的起始点。这份记录的作用是让后来的人能复现你的判断，而不是只看到一个变了的总分。
如果升级后某项统计归零或大幅下降，先别急着当成“问题已解决”。归零也可能是因为该项在新规则里被合并、被改名、或阈值调高到不再触发。要确认这一点，回到检测项对照表里查该项是否还存在、是否换了名称，而不是只看数字本身。数字下降只是现象，口径变化才是需要先排除的解释。
具体到某个插件的评分工具，其按钮位置、当前计分项和权重属于会随版本变动的信息，需要以你实际使用的那个版本的说明为准，不能套用别处的描述。把口径对齐这一步做扎实，前后差异自然就能落到具体的检测项上，而不是停留在一个说不清的总分变化里。
