English | 简体中文
订阅 → 发现 → 评估 → 动手 → 追踪的完整闭环:每天自动盯订阅仓库,新 issue 经批量分诊、多信号打分后推送到飞书/企业微信;最值得动手的条目直接定位源码文件、给出修复切入点;你提交 PR 之后,它用真实的合并结果反过来校准打分器。 不是又一个 good-first-issue finder——分层调用:批量任务走单次结构化输出,只有多步代码探索才上 ReAct 循环。
| 环节 | 能力 |
|---|---|
| 订阅拉取 | MCP 按 since 游标增量拉取新 issue + 并发水合;规则过滤 bot / >90 天 stale / 已推送(SQLite),0 token |
| 批量分诊 | 单次 json_schema 结构化输出:type · 难度 · 可行性×复杂度双轴 |
| 多信号打分 | 四因子 GFI(clarity / responsiveness / freshness / activity)+ 技术栈偏好加权,每条附证据链:命中哪些信号、各得几分 |
| 修复深潜 | Top-N 可行 issue 浅 clone(--depth 1)→ ReAct 引擎定位真实源码文件、起草修复切入点 |
| 定时推送 | GitHub Actions 每日 cron,Markdown 日报推飞书(主)/ 企业微信(备)群机器人 webhook |
| 追踪校准 | 轮询本人 PR 合并状态,Fixes #N 关联推荐项,分数 vs 合并率相关性 → 权重 v1→v2 |
订阅仓库(config/repos.yaml)
│
▼ 增量拉取(MCP list_issues + since 游标)
[纯 API] 0 token ── 规则过滤:bot / >90 天 stale / 已推送(SQLite)
│
▼
[单次结构化输出] json_schema 强约束
│ 批量分类:type·难度·可行性×复杂度 双轴
▼
[规则打分] 0 token
│ 四因子 GFI 打分(clarity/responsiveness/freshness/activity)
│ + 技术栈偏好加权,每条推荐附证据链:命中哪些信号、各得几分
▼
[ReAct 循环] 仅 Top-N 可行 issue
│ 浅 clone(--depth 1)→ 关键词定位候选文件 → 引擎验证并给出修复切入点
▼
Markdown 日报 ──► 飞书 / 企业微信 群机器人 webhook
│
▼
[追踪校准] tracker 轮询本人 PR(state/merged)→ 分数 vs 合并结果相关性 → 权重 v1→v2
批量结构化任务走 agent 循环费钱且慢(benchmark 实证:multi 查询 p50=57s 中 LLM 占 33s),ReAct 引擎只留给多步代码探索。
| 指标 | 数值 | 来源 |
|---|---|---|
| 类型分类准确率(bug/feature/docs/question) | 98.2%(55/56) | eval/run_eval.py(56 条人工标注集,langchain/ruff/pydantic 三仓库,含"标签与内容不符"对抗样本) |
| ┗ 难度精确匹配 / ±1 档容差 | 66.1% / 98.2% | 同上 |
| 工具并行加速 | 中位 2.0x(1.5–3.2x,网络往返型 2.6–3.2x) | benchmark.py 串并 A/B + 回放法(排除 LLM 与网络抖动) |
| 单忙日全链路 | 225 条新增 issue,134.1s | 生产运行日志 |
| 日均 LLM 成本 | < ¥0.5 | DeepSeek 计费估算(分层过滤后增量才进 LLM) |
口径说明:难度错误几乎全是 easy↔medium 相邻档混淆,无跨档灾难;完整混淆矩阵与 P/R/F1 见 eval/report.md,标注口径见其文件头。
日报输出样例(分数与证据链均为真实输出):
[astral-sh/ruff#26260] Confusing wording and diagnostic range in
D401— 得分 70
- 分类: 缺陷 · 难度 easy · 可行 · 复杂度 low · 创建于 61天
- 打分依据: clarity 21/35(基础分); responsiveness 21/30(2 条讨论); freshness 3/20(发布 61 天); activity 15/15(49287 stars); 偏好+4(Rust); 复杂度low+6
- 分类依据: Bug: confusing wording and diagnostic range in D401; likely simple message/range fix.
- 链接: astral-sh/ruff#26260
深潜示例(文件定位经人工对照真实仓库验证):langchain#39783 反序列化白名单缺失 ImagePromptValue → 命中 libs/core/langchain_core/load/mapping.py;本地关键词候选全噪声时,引擎能经 search_code 自主定位真实规则文件。
# 0. 环境:Python 3.11+,本机需 Docker(GitHub MCP Server 跑在容器里)
pip install -r requirements.txt
# 1. 配置 Key
cp .env.example .env # 填 GITHUB_TOKEN / LLM_API_KEY(LLM_MODEL / LLM_BASE_URL 按供应商填)
# 2. 订阅与偏好:编辑 config/repos.yaml
# repos 列表 + preferences.tech_stack(命中的 issue 在打分时加分)
# 3. 跑一轮完整流水线(fetch → triage → score → deepdive → digest),日报打印到控制台
python firstcatch.py --once
# 4.(可选)追踪本人 PR 合并状态写回 SQLite
python firstcatch.py --track仓库自带 .github/workflows/daily.yml:每日 UTC 01:00(北京 09:00)自动运行并推送,SQLite 状态由 bot commit 回传仓库自带历史。配置以下 Secrets 即可:
GITHUB_TOKEN—— PAT,读订阅仓库 issueLLM_API_KEY/LLM_MODEL/LLM_BASE_URL—— 任意 OpenAI 兼容 APINOTIFY_CHANNEL+FEISHU_WEBHOOK或WECOM_WEBHOOK—— 推送渠道(webhook 属密钥,绝不入库)TRACK_TOKEN(可选)—— 你的用户 PAT,供 PR 追踪用;不配则跳过该步
python eval/run_eval.py # 分诊评测:准确率 + 混淆矩阵写入 eval/report.md(需 LLM Key)
python eval/calibrate.py # 打分校准:分数档合并率 + 点二列相关(样本 ≥5 出结论)
python benchmark.py # 性能基准:端到端延迟 / 串并 A/B / 回放法(--help 看用法)| 项目 | Stars | 形态 | 局限 |
|---|---|---|---|
| cutenode/good-first-issue | 827 | CLI(2018) | 纯标签过滤,无智能 |
| yankeexe/good-first-issues | 153 | CLI(2020) | 同上 |
| drkrillo/good-first-issues | 38 | GitHub Action | 每日扫表,无个性化 |
| issuescout.dev | 8 | Web 平台 | 拉模式,无推送、无深潜 |
| yakub268/good-first-issue | 5 | CLI | 四因子打分(本项目 baseline),有 watch daemon 但无深潜、无反馈校准 |
| 各类 AI triage bot(4 个) | 0–4 | App/Action | 维护者视角,赛道饱和;贡献者视角空位 |
star 数为 2026-08 实测。以上项目均没有:订阅推送制、修复切入点深潜、反馈校准闭环。
- yakub268/good-first-issue —— 四因子打分 baseline(clarity 35% / responsiveness 30% / freshness 20% / activity 15%)
- redhat-et/gha-issue-triage —— 可行性×复杂度双轴设计借鉴
- GitHub MCP Server —— 工具层