用五条 SQL 复现 24,949 条验证记录的全部数字
这篇给要自己核对数据的人：本文每个数字都能用下面五条 SQL 在同一份生产库上复现，sqlite3 就够。
一、数据源与快照
| 项 | 说明 |
|---|---|
| 数据源 | 生产库 Plugin 表（SQLite，只读打开） |
| 快照时间 | 2026-11-06 06:5x（UTC+8） |
| 样本池 | hidden = 0，24,949 条 |
| 涉及字段 | verifyLevel / verifyStatus / verifyReason / stars / readmeZh |
只读打开很重要：这份库同时服务线上站点，写锁会直接影响访问。用 sqlite3 "file:dev.db?mode=ro"。
二、五条 SQL
SQL 1：验证深度分布
SELECT COALESCE(NULLIF(verifyLevel,''),'（空）') AS lv,
COUNT(*) AS n
FROM Plugin
WHERE hidden = 0
GROUP BY 1
ORDER BY n DESC;
输出：
| lv | n |
|---|---|
| L4 | 16,569 |
| （空） | 5,198 |
| L5 | 3,182 |
SQL 2：深度 × 结果的交叉表
SELECT COALESCE(NULLIF(verifyLevel,''),'（空）') AS lv,
verifyStatus,
COUNT(*) AS n
FROM Plugin
WHERE hidden = 0
GROUP BY 1, 2
ORDER BY 1, 3 DESC;
输出：
| lv | status | n |
|---|---|---|
| L4 | pass | 10,754 |
| L4 | fail | 3,765 |
| L4 | none | 2,050 |
| L5 | pass | 3,182 |
| （空） | none | 4,821 |
| （空） | fail | 377 |
SQL 3：失败归因
SELECT substr(COALESCE(NULLIF(verifyReason,''),'（空）'),1,40) AS reason,
COUNT(*) AS n
FROM Plugin
WHERE hidden = 0 AND verifyStatus = 'fail'
GROUP BY 1
ORDER BY n DESC
LIMIT 10;
输出前八行：
| reason | n |
|---|---|
| unknown | 2,948 |
| dependency_conflict | 816 |
| runtime_smoke_failed | 88 |
| dep_tree_unresolvable | 56 |
| runtime_boot_failed | 55 |
| node_version | 53 |
| runtime_never_loaded | 46 |
| runtime_add_failed | 41 |
SQL 4：汉化覆盖
SELECT CASE WHEN length(COALESCE(readmeZh,'')) > 0
THEN '有汉化' ELSE '无汉化' END AS state,
COUNT(*) AS n
FROM Plugin
WHERE hidden = 0
GROUP BY 1;
输出：有汉化 24,828 / 无汉化 121。
再按星标分档看未汉化的那批（stars >= 100 / 10-99 / <10 三档分组计数）。
输出：0-9 星 118 个、10-99 星 1 个、100+ 星 2 个。
SQL 5：三种分母下的通过率
SELECT
ROUND(100.0 * SUM(CASE WHEN verifyStatus='pass' THEN 1 ELSE 0 END) / COUNT(*), 1) AS pct_all,
ROUND(100.0 * SUM(CASE WHEN verifyStatus='pass' THEN 1 ELSE 0 END)
/ SUM(CASE WHEN verifyStatus IN ('pass','fail') THEN 1 ELSE 0 END), 1) AS pct_attempted,
ROUND(100.0 * SUM(CASE WHEN verifyLevel='L4' AND verifyStatus='pass' THEN 1 ELSE 0 END)
/ SUM(CASE WHEN verifyLevel='L4' THEN 1 ELSE 0 END), 1) AS pct_l4
FROM Plugin
WHERE hidden = 0;
输出：以全量为分母 55.8%、以尝试过验证的为分母 77.1%、以 L4 为分母 65.0%。
这条 SQL 证明的是：同一个库，三个分母能给出三个都很合理的数字——引用任何一个都必须写明分母。
三、在云上跑要注意的三件事
如果你把这套查询放到 ECS / CVM 上跑（比如要定期出一份快照），有三点：
第一，别把库拉到本地跑。 线上服务正在写，拷贝可能拿到不一致的快照。用只读连接直查，或先 VACUUM INTO 出副本再分析。
第二，时间字段格式不统一。 Visit.createdAt 是毫秒整数，Plugin.zhProofreadAt 是文本；跨表按时间过滤时格式对不上会静默返回空结果。
第三，跨表 JOIN 会吃满内存。 Plugin 2.5 万行 × Visit 6 万行做 JOIN，2G 内存实例会被 OOM kill。分别导出聚合结果再本地合并。
四、口径边界
第一，这些数字不代表插件质量。 验证只测装得上、起得来。
第二，none 不是负面信号，只是没测过。
第三，L5 无 fail 是选择效应（跑通了才记）。
第四，unknown 占 71.2%，失败原因这个字段只能覆盖三成样本。
五、数据本身说明的三件事
第一，L4 里 22.7% 是失败的。 标着 L4 不等于通过，这个字段表示深度。
第二，依赖冲突是最大的可归因问题。 816 条占可归因失败的 68%，与 npm 生态的老问题同源。
第三，汉化按星标优先级推进，长尾被跳过。 未汉化的 121 个里 118 个低于 10 星。
六、局限
第一，横截面快照，没有时间序列。 无法判断趋势。
第二，字段有写入延迟。 刚入库的插件状态会变，快照数字只能对应当天。
第三，verifyReason 判定逻辑未公开，不同批次口径可能不一致。
第四，五条 SQL 只覆盖计数，不含分布形状。
七、数据复核
- 按验证档位筛选插件：分类精选页
- 单插件详情页「验证」区块对应
verifyLevel/verifyStatus/verifyReason - 本文五条 SQL 可直接在只读连接上复跑，输出应与上文表格一致
适合与不适合
适合：想自己核对这份数据的工程师；要定期出验证分布快照的运维；需要一套可复现 SQL 做对照分析的人；准备在云上做数据分析、需要知道库结构陷阱的人。
不适合：只想要结论、不打算跑 SQL 的读者；想找「哪些插件好用」的人，这套查询不含功能评价；期待「通过率」有一个标准答案的人，分母不同结论不同。
标签：DeepSeek Harness、SQL、数据核验、验证档位、插件库
本文由 DeepSeek Harness Hub 自动整理，数据来源于站点 2026-11-06 快照。
