[RFC] 关于推进AstrBot千级插件市场分类标准化的提案 #6728
Description
摘要
当前 AstrBot 插件生态中的 tag 高度依赖作者自定义。
在插件数量较少时，这个问题尚可接受；但在插件市场已经有 1000+ 插件 的情况下，市场侧仍然完全不支持按功能分类浏览，这已经明显影响了插件的发现效率和生态可维护性。
在这个规模下，继续依赖作者自由填写 tag，已经不足以支撑插件市场的发现、筛选和组织。
因此，我建议官方引入一套统一的插件分类体系，将其作为插件市场的主分类依据；作者自定义 tag 也许可以继续保留，用于补充搜索和细粒度描述。
背景
目前插件的 tag 主要由作者自行填写。由于不同作者对 tag 的理解和命名习惯都不一致，同类插件常常使用完全不同的 tag，而不同类型的插件也可能使用相似甚至混杂的 tag。 这使得现有 tag 更像是“作者自述”，而不是一套可用于市场分类和筛选的结构化元数据。
之前被关闭的issue有人提到过 #2011 (comment)
可以直接在现有插件市场里面的tag里面找10个最多使用的作为推荐选项(甚至可以让审核bot来判断)
但现有审核流程中，审核 bot 并不能主动对 tag 提供建议，或者帮作者完成分类归纳，其次最重要的还是目前AstrBot 没有提供统一筛选与插件市场的分类高度耦合的标签体系，最终仍然主要取决于作者个人的填写方式。
提案
建议为插件提交、插件市场提供官方设计的主、次分类。
自由tag也许可以保留作为搜索的关键字。
具体做法
在插件元数据中新增一个官方分类字段，例如：
{
"name": "example_plugin",
"desc": "示例插件",
"author": "example",
"repo": "https://github.com/example/example_plugin",
"category": "query",
（假如保留，或者作为子分类） "tags": ["搜索", "网页", "工具"]
}其中：
category：必填，由官方提供固定选项tags：选填，继续允许作者自由填写
分类字段建议
建议 category 采用单选。
- 更适合为插件市场提供导航功能
- 更方便后续做统计、榜单、推荐
- 可以避免分类泛化和滥用
对于跨类别插件，可以按其核心用途归类。
为什么不能继续只依赖自由 tag
自由 tag 当然有价值，但它更适合做补充描述，而不是承担市场主分类职责。
分类层级设计补充
此外，我认为 category 不一定只能是单层结构，更合适的做法是设计为 主类（Primary Category）+ 次类（Secondary Category） 的两级体系。采用这种方法之后，也许可以更轻松的抛弃自由 tag分类。
主类用于市场首页导航和大类组织，次类用于主类内部的进一步细分。这样既能保证分类体系整体稳定，又能避免一级分类过粗、自由 tag 过散的问题，更适合千级插件规模下的市场组织和筛选。
建议主类保持相对稳定，次类则可根据社区实际需求逐步补充和调整，由官方统一收敛并维护标准。这样既能保证分类语义一致，也能让体系随着生态发展持续演进。
并且实际上，即使是子类也不需要过多细化的分类。设计一个较为完善的标签类别基本足矣满足 AstrBot 社区未来长期的插件生态的使用。
插件市场侧建议
在引入官方分类后，插件市场建议至少支持以下能力：
- 按官方分类根据主类、词类筛选插件
- 选中、多选分类后 + 关键词组合搜索
- 在插件卡片中展示所属分类
- 显示各分类下插件数量
这样做之后，用户进入市场时至少可以先按大类缩小范围，而不是在 1000+ 插件中无结构地查找。
兼容与迁移建议
为了避免一次性改动过大，可以分阶段推进：
第一阶段
- 新增
category字段 - 老插件允许暂时无分类
- 市场中对未填写分类的插件显示为“未分类”
第二阶段
- 逐步为历史插件补充分类
- 优先由维护者或规则映射完成已有插件的归类，可以使用AI辅助分类。
第三阶段
- 新插件发布时要求必须填写
category - 市场默认支持按分类浏览和筛选
预期收益
这个改动可以直接带来几方面收益：
- 提高同类插件的可见性，反哺插件市场的生态
- 降低用户发现插件的成本
- 让插件市场具备基本的结构化浏览能力
- 降低维护侧对自由 tag 的解释成本
- 为后续推荐、榜单、专题页等功能提供基础
关于此提案，有以下问题可以讨论
- 关于自由 tag 的去向？
- 官方分类字段是否应该作为插件元数据的一部分引入？
category主类与子类的想法？- 历史插件的分类迁移的方式？