feat: 添加 GitHub Issue 筛选器模板，防止重复/撞车 Issue

[SereinSos]

描述

目前项目缺少有效的 Issue 筛选或相似 Issue 检测机制，导致用户在提交新 Issue 前难以发现已有相关 Issue，频繁出现重复 Issue（撞车），增加维护成本并降低讨论质量。

建议增加 Issue 筛选器（或类似的搜索/推荐机制），帮助贡献者在创建新 Issue 前先检查是否已有相关讨论。

动机

• 减少重复 Issue 和“撞车”现象
• 提升 Issue 列表的整洁度与可发现性
• 帮助新贡献者更容易找到相关讨论
• 降低维护者的 Issue 分类与处理成本

建议方案

可考虑以下一种或多种方式：

1. 创建前搜索提示
   在新建 Issue 时，根据标题和描述展示可能相关的已有 Issue 列表，引导用户先搜索。

2. 增强筛选能力
   优化 Issue 列表的关键词搜索、标签、状态、Milestone 等筛选体验。

3. 结合 GitHub 搜索或第三方工具
   利用 GitHub Search API，或在 Issue 模板中加入搜索引导，或使用机器人检测潜在重复。

4. 重复检测机器人 / Action
   新 Issue 创建后，自动检测高相似度 Issue 并评论提示。

已考虑的替代方案

• 完全依赖贡献者手动搜索（现状，效果较差）
• 事后关闭重复 Issue（被动处理，仍会产生噪音）

补充说明

此功能对 Issue 量较大的项目尤其有帮助。如果维护者感兴趣，我愿意进一步讨论实现细节，或协助提交 PR。

---

请问维护者是否愿意考虑此功能？
是否有偏好的实现方式或需要注意的约束？

[SereinSos]

@tt-a1i
我认领这个任务。
实施计划：

• 调研 3-5 个知名开源项目的 issue 模板实践

• 结合本项目特点进行定制化设计

• 本地测试验证流程完整性

• 提交 PR 并请求 review

预计完成时间：
1 周内（2026-09-05）【最晚】
3天内【最早】

[SereinSos]

进度：调研和方案选型

介绍

Github Issue Checker是一种基于定制Github Actions对开源项目通过工具调用以及内部逻辑实现对Issue List（通过Github公开接口获取）的重复情形进行检测以及处理的Workflow，核心是“引擎”——语义相似度检测的技术方案选择，此外还有一系列发生率一般的边缘问题需要Checker内部做好设计
关于语义相似度检测技术，调研得到了三种方案：

基于词频统计、向量空间距离、关键词匹配实现文本相似度检测

• 优点：零成本；反应速度可达毫秒级别；部署复杂度极低

• 缺陷：多语言语义相同或相似下无法检出；意图相同但表述完全不同时，无法检出（这是AI发起Issue的最常见问题）

基于LLM的语义推理实现文本相似度分析

• 优点：远远强于“基于词频统计”在语义相似度检测之中复杂情况的表现，最明显的区别是支持多语言同义的语义相似判定

• 缺陷：成本和稳定性都由LLM模型供应商决定

基于小型Embedding模型实现文本相似度分析检测（推荐）

• 优点：达成了轻量和效果的平衡。有论文显示”在专门的“重复Bug检测”任务中，Sentence-BERT（SBERT）及其衍生模型已被证明效果显著”

• 缺陷：需要精细考虑其部署在github actions环境的可能性以及对本项目环境造成的内存压力——其处理方案是复杂的，需要探索引入批处理和缓存技术来保证模型在GIthub Action的虚拟环境下稳定安全运行。

• 注：已有开源项目使用这样的方案，不过可能需要针对环境微调

考虑

综合以上信息，我们考虑使用基于LLM的语义推理作为Issue Checker的分析引擎。这是因为考虑当前项目Issues的规模不大，可以利用到Github免费提供的model API 进行推理，以保证该功能的快速上线。

下一步

调研Github Model API的调用方法以及现有使用LLM完成筛选的开源项目实现，参考其逻辑开发出MVP版本并进入测试

实施计划更新

• 调研 3-5 个知名开源项目的 issue 模板实践
• 结合本项目特点进行定制化设计
• 本地测试验证流程完整性
• 提交 PR 并请求 review