我亲手跑了一遍存量统计，兜底类居然排到第二
一、一句话结论
我第一次交出去的数是错的。骨架没歪------24,367 条可见条目、15 个分类------但分母、均值排序、other 该怎么读，这三处我全是按直觉处理的。这篇按「我先怎么算的 → 哪里不对劲 → 改成了什么」讲一遍，返工三次，每一次都是自己打自己脸。
二、怎么算的
流程本身很笨：把生产库的一份副本拉到本机，sqlite3 只读打开，跑一条分组查询，导出 CSV，再对着屏幕一格一格核。
| 项 | 值 |
|---|---|
| 数据源 | 生产库 dev.db 的 Plugin 表，只读副本 |
| 快照时间 | 2026-11-03 06:03（北京时间） |
| 我的环境 | 本机 sqlite3 加 python3，没上任何 BI 工具 |
| 产出 | 15 行分类表、一张均值表、一份发同事的截图 |
第一版连 hidden=0 都没写，就这条：
bash
sqlite3 -readonly dev.db "SELECT category, COUNT(*) FROM Plugin GROUP BY 1 ORDER BY 2 DESC;"跑完看着挺像样，15 行，最大的一行三万多。我当时以为十分钟就完事了。
三、口径边界
有三件事我从一开始就该写在自己脑门上。
第一，条数只说明「收录了多少」，不说明「好不好用」。我最初把条数多直接等同于热门，这是偷懒。
第二，category 是站点自己的单列枚举，不是多标签。一个插件只落一个值，所以一个既能改界面又能记东西的项目，只会在其中一类里出现一次。跨类能力在这张表里根本看不出来。
第三，这是单点快照。我不是在做一个趋势图，只是在一张表上数数，任何「最近在涨」的说法都超出这份数据的范围。
四、完整数据
| 分类 | 条目数 | 占比 | 原始均值 | 剔除最大项后均值 |
|---|---|---|---|---|
| ui | 3,581 | 14.70% | 90.8 | 48.6 |
| other | 3,395 | 13.93% | 11.5 | 6.7 |
| market | 3,048 | 12.51% | 104.0 | 85.2 |
| tool | 2,661 | 10.92% | 27.1 | 24.3 |
| chat | 1,715 | 7.04% | 54.1 | 30.0 |
| model | 1,520 | 6.24% | 6.2 | 5.6 |
| dev | 1,469 | 6.03% | 39.7 | 8.9 |
| browser | 1,351 | 5.54% | 231.1 | 33.6 |
| vision | 1,350 | 5.54% | 202.9 | 124.9 |
| skill | 1,095 | 4.49% | 38.2 | 14.7 |
| security | 1,016 | 4.17% | 512.2 | 96.9 |
| platform | 766 | 3.14% | 78.7 | 51.2 |
| desktop | 704 | 2.89% | 85.9 | 36.9 |
| search | 639 | 2.62% | 95.1 | 38.4 |
| ads | 57 | 0.23% | 17.0 | 5.1 |
| 合计 | 24,367 | 100% | 92.1 | --- |
五、我踩的三个坑
返工一 · 分母里多了一千行
第一版的分母是 25,441，因为我把整张表都数进去了。数据里有一部分条目标了 hidden=1，共 1,074 行，这些在站点上是不展示的。我当时想：「反正分母大一点，比例差不了太多。」
差得了。补上 hidden=0 之后分母变成 24,367，前五类的合计从「六成上下」的模糊印象，落到一个能写进文档的 59.10%。更关键的是态度问题：把看不见的条目算进分母，等于用不存在的供给去解释存在的东西。这一条改完，我重新核了每一行的百分比。
返工二 · 一个项目毁掉整张均值榜
第二版我把星标均值也并进表里，想让结论更丰满一点。跑出来第一眼就看到 security 的 512.2，全场最高。我手都快放到键盘上准备写「安全类最受关注」了。
停下来的原因是这个数高得离谱。我回头查明细：该类里有一个 422,036 星的项目，单它就占了这个分类星标总和的 81.1%。剔掉它，均值从 512.2 掉到 96.9。同样的毛病在 browser 更明显，231.1 掉到 33.6；dev 从 39.7 掉到 8.9。
榜单直接翻过来。按原始均值，vision 202.9 排在 browser 231.1 和 security 512.2 后面；把最大的那个项目剔掉，变成 vision 124.9 高于 security 96.9 高于 browser 33.6。同一批数据，两种口径两个结论。我在笔记里写了一句：均值在长尾数据里不是中心，是最大值的人质。
返工三 · 我把兜底桶当成了功能类
other 3,395 条、13.93%，排第二。
我第一版的备注写的是「杂项需求旺盛，说明用户的长尾需求被低估」。写完自己都觉得飘。后来想明白：other 不是功能分类，是兜底桶------枚举没覆盖到的形态全往这里塞。它排第二，只说明分类体系的边界不够宽，不能说明任何一类需求在涨。
这一条改的是叙述，不是数字。但影响最大：前面两处我改的是分母和排序，这一处改的是我凭什么下结论。
六、局限
我现在能说清的边界就这些：
- 单列枚举会把多能力插件折叠成一个值，跨类组合看不见；
- 星标是累计值，「剔除最大单项目」只是最粗的稳健化，我没取中位数，所以那张均值表只能看趋势，不能当分布；
- 本切面没排除已归档仓库，也没切时间窗口，新收录的和几年前的老项目混在一起；
finalScore我没展开，只在笔记里记了一句：最大 74.4、均值 31.7；- 这是一份单时点快照，跨日对比得再取一份。
七、数据复核
复核我做的是笨办法：把五个数写在纸上，一个一个对。
全表 25,441；hidden=1 是 1,074；两者相减 24,367；分组结果正好 15 行；前五类合计 14,400、59.10%。再加一组：L5 合计 2,453、占 10.07%。
五个数里有一个对不上，我就回头重跑那条查询，而不是去调结论。这一步花的时间比写稿多，但值得------如果没有它，前面三次返工我一个都不会发现。
总结
一篇统计稿真正的工作量不在查询，而在三次自我否定：分母要不要剔隐藏、均值能不能直接排序、兜底桶能不能当功能类。三个问题里任何一个答错，结论都会漂。我最后交出去的那版，数字和第一版差得不多，但每一句都能追溯到一条查询。
八、适合与不适合
适合 ：准备自己做一次同类统计、想先看看别人会在哪里翻车的人；需要向同事解释「为什么这个比例和你算的不一样」的人；习惯先把口径写在文档开头、再写结论的人。 不适合：只想要一个能直接引用的排名的人，这份数据给不了排名；想用它评估插件质量的人，条数不承载质量信息；需要多标签视图的人，单列枚举做不到。
标签：分类统计、DeepSeek Harness、数据复盘、口径纠偏
本文由我亲手实测整理，数据来源于站点档案库的只读查询。