开源项目也能用AI自动分流GitHub Issues了

Hacktoberfest：Maintainer Spotlight

每个热门仓库都面临同样的问题：新 issue 的堆积速度远超维护者阅读它们的速度，许多 issue 最终被贴错标签，或者无人处理。

laya-triage 是一个 GitHub Action，它能读取每个新 issue 并将其标记为 bug、功能请求、问题或文档问题。如果一份 bug 报告几乎为空，它会向作者询问所缺失的细节。它在你自己托管的 GitHub Actions runner 中运行一个微调后的开源权重模型：无需 API key、零成本，而且 issue 文本永远不会离开 GitHub。

🔗 仓库：https://github.com/elnachto/laya-triage 🛒 Marketplace：https://github.com/marketplace/actions/laya-triage 🤗 模型：https://huggingface.co/elnachto/laya-triage-en

创建 .github/workflows/triage.yml：

name: Triage

on:
  issues:
    types: [opened]

permissions:
  contents: read
  issues: write

jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
      - uses: elnachto/laya-triage@v1

它默认以 dry-run 模式启动，所以只会在 workflow 日志中打印决策结果。当你满意看到的结果后，将 dry-run 设置为 "false"。docs/examples/ 中还有更多可直接拷贝的 workflow 示例。

微调：我在自己的 GPU 上，基于 NLBSE'23 基准测试集中的 100 万条真实 issue，对开源的 Laya decision 模型进行了微调。

我的数据集：我从数千个活跃仓库中收集了近期（2025–2026 年）的 issue，并只保留了维护者手动应用的标签，而非 issue 模板自动添加的标签。

严谨的评测：使用独立的测试集，且该测试集从未用于模型调优。

在 NLBSE'23 上达到 88.8% 的准确率，处于 RoBERTa 研究基线（89.1%）的误差范围内。

在来自 288 个活跃仓库的 10,026 条近期 issue 上达到 79.8%，领先于 Jev（78.1%），后者是一个付费的商业 API。

它能适应每个仓库：复用你现有的标签名称（type: bug、kind/feature……），并从你过去一年标记过的 issue 中学习每种 issue 类型的分布频率。

它永远不会覆盖你或 issue 模板已经设置的标签。

目前仍有一些适合新手的 good first issue 任务开放，而且它们都不需要 GPU：

为模板测试添加 CI workflow。

仓库适配逻辑的单元测试。

将 README 翻译成西班牙语。

最有价值的贡献：将它安装到你的仓库中，并在它标记错误时告诉我（有一个 issue 表单专门用于此用途）。这些报告就是训练下一个模型的数据。

请先阅读贡献指南，并在开始之前在某个 issue 上留言。非常感谢已经提交 pull request 的首批贡献者！Hacktoberfest 快乐 🎃