FMRS 评分方法

评分原则

1. 每个维度独立评分 0–20，并保留文字依据。
2. 缺少证据时扣分，不根据品牌知名度补分。
3. 重大安全问题、权限边界和潜在副作用必须公开显示。
4. 上游元数据与 revision 自动刷新，评分可按最新证据重新生成。

为什么要有这道评分

目录类网站最常见的问题是每一条都差不多——复制一段 README，贴上 star 数，换个名字。FMRS 存在的目的是逼自己写出可核查、可反驳的依据，而不是简单转述来源仓库的自我介绍。

评分只读客观可验证的证据：源仓库本身、发布与提交记录、README、安装清单（manifest）。不读 star 数，不读厂商自我介绍里的形容词，也不接受付费调整——评分原则第 2 条就是为此写的。

证据来自哪里

五个维度的证据全部来自源仓库的公开信息，不使用用户投票、付费评测或第三方评分聚合。

• 仓库结构与安装清单（manifest）
• commit / release 时间线，判断维护是否持续
• README 中关于工具、权限和传输方式的说明
• 已知的安全公告或 Issue 讨论（如果仓库公开）

分数等级怎么划分

总分 85 分及以上记为 A，70–84 为 B，55–69 为 C，55 分以下统一记为 D。

D 不是惩罚，而是「证据不足」的默认结果。很多 D 级项目本身能正常工作，只是 README 没写清楚安装步骤、权限范围或工具清单——评分规则要求没证据就不给分，而不是没证据就按及格算。

常见问题

• 评分和 GitHub star 数有关系吗？ — 没有。star 数只在列表页和详情页单独展示热度，五个维度的打分不读取星数，也不因为项目知名而补分。
• 为什么一些很受欢迎的项目评分不高？ — 受欢迎程度反映的是社区关注，不是评分依据的证据。如果一个项目的 README 没有列出具体工具清单、权限范围或安装步骤，即使它有几万个 star，对应维度依然按证据不足计分。展开任意资料页里的评分依据能看到具体理由。
• 评分多久更新一次？ — 上游仓库的 revision（release / commit）变化后，评分会基于最新证据重新生成，不是发布时算一次就固定不变。
• 发现评分或资料有误怎么办？ — 发到 [email protected]，注明 server 名和你认为有误的具体内容；来自仓库维护者本人的更正请求会优先处理。