项目叙事：一个插件发现产品的完整论证

这是本站「为什么这么造」的完整故事。产品在前（首页即用），叙事在后（本页讲清依据）。

① 问题：生态爆发了，发现通道没跟上

DeepSeek Harness 开源几天，GitHub topic「dsh-plugin」从 3351 个仓库涨到 4900+，每天净增千级。 但发现通道还是三样老东西：静态精选列表（约 580 条、人工 PR 更新）、站内市场（目录式浏览）、 按 star 排序的搜索——全部回答「有什么」，没有一个回答「哪个是对的那个」。

② 判断：缺的不是更多列表，是「质量分层 + 可解释推荐」这一层

用户的真实问题不是「找不到插件」，而是「不敢装」——安装插件等于在本机以自己权限运行第三方代码， 而 15.5% 的仓库无许可证、4% 是 NOASSERTION。所以推荐系统必须自带信任信号：它可安装吗？ 被精选收录过吗？许可证干净吗？还在活跃吗？以及最关键的——为什么推荐它。 这是所有纯 star 排序方案（包括已有的 dsh-find-plugin）都缺失的一层。

③ 方案取舍：五个关键决策

3.1 为什么做成插件，而不是只做网站

候选是外部网站（独立域名、集中式推荐接口）。取舍：网站每次推荐都要调一次 LLM API—— 消耗的是我个人的模型额度，而且用户得离开 DSH 去另一个页面；插件形态下，推荐就是 agent 自己那一轮思考（它本来就在用模型回答用户），零额外额度成本，且能直接给出dsh plugin add 安装命令，场景零割裂。分发走官方机制：仓库打 dsh-plugin topic + 向 awesome 精选列表提 PR，人人可装。结论：插件为主，网站保留为可访问的产品演示与叙事载体。

3.2 为什么用规则引擎，而不是 embedding 向量检索

候选是本地 embedding（bge-m3 等）+ 向量检索。取舍：插件语料是开发者的功能描述，字面直白、 高频词就是功能位本身，关键词聚类已能达到 1 秒内 590 条的可解释分组；向量检索需要 1GB+ 模型 或 API 费用，且结果是「一团向量」，无法向用户解释为什么命中。规则引擎零成本、确定性、 可解释。结论：规则先行；等语料规模与口语化程度再上一个量级，embedding 是预留的升级路径。

3.3 为什么「每日索引 + 实时合并」，而不是纯实时搜索

GitHub Search API 有 10–30 次/分钟的限流和单查询 1000 条上限，纯实时搜索在 agent 高频调用下 必然撞墙。取舍：每日离线构建全量索引（含昂贵的 dsh.bundle 可安装探测与质量评分），查询时再 叠加一次 gh 实时搜索做新鲜度兜底，gh 缺失自动降级为纯索引。结论：索引为骨、实时为皮。

3.4 质量分怎么算（0–100）

每个低质量信号（NOASSERTION / 无许可 / 停更 / 未收录）都转成结果里的风险徽章，而不是默默扣分。

3.5 排名公式与中文查询的真实坑

排名 = 质量分 ×0.55 + 词命中（+13/词）+ 功能簇命中（+11/词）+ 命中≥2 的簇一致性加成（+12） + 星标对数权重（≤15）。第一版把中文查询当成整串 token，「给纯文本模型读图片的能力」整句匹配 必然落空、推荐退化成全站高分榜——实测发现后改为 CJK 二元组切分（「读图」就能命中「视觉/读图」簇） 加 20 条同义别名映射（手机→移动、图片→视觉、审批→审批……）。这个 bug 完整写进了⑤ 验证结果 的对照里。

④ 证据：全量数据，而不是抽样印象

所有判断都建立在三次递进的数据工作上：top20 深析（头部是谁）→ 595 条精选列表去重地图（拥挤与真空） → 3804 仓库全量普查（真实结构与错配）。普查用「日期桶 + 星标区间」双维度切片绕过 API 的 1000 条上限， 去重后覆盖全 topic；质量分与功能簇在每一条仓库上落地。

⑤ 验证结果：功能位命中与社区反馈

规则引擎在六组自然语言查询上的实测（2026-08-16，索引 4770 仓库）：

⑥ 下一步

三个预留的升级方向：① embedding 语义检索（语料口语化程度上升后启用）；② 推荐反馈闭环——用户对 推荐结果的「有用/没用」信号回流进质量分；③ 与 dsh-find-plugin 等社区项目协作，把质量分层沉淀为 生态公共能力，而不是私有实现。